09:03 < wsa> OK, let's get started with the IO meeting 09:03 < wsa> welcome everyone, hope you are fine 09:03 < wsa> here are the collected status updates 09:03 < wsa> Status updates 09:03 < wsa> ============== 09:03 < wsa> A - what have I done since last time 09:03 < wsa> ------------------------------------ 09:03 < wsa> Geert 09:03 < wsa> : did regression tests for SCIF with SH4 based hardware, fixed a few other issues on the way, tested suspend/resume with PCIe and investigated the problems, reposted RSPI bit rate improvements, posted v3 of generic bindings for Ethernet MAC explicit internal delay setting, implemented by RAVB, posted a revert for linkwatch after some more investigation 09:03 < wsa> Niklas 09:03 < wsa> : unsuccessfully tested SDIO WiFi with Koelsch on Gen2. Probably because of a too long cable. He will try a shorter one. 09:03 < wsa> Shimoda-san 09:03 < wsa> : sent a patch fixing the suspend handling of the USB serial gadget, reviewed and tested Wolfram's SDHI patches about the stalled SCC and the reset refactoring and the card reset after IP reset, also reviewed lots of bindings for r8a774...- SoCs as well as USB bindings 09:03 < wsa> Ulrich 09:03 < wsa> : sent "watchdog: da9063: wake up parent ahead of reboot" to enable late atomic transfers with IIC 09:03 < wsa> Wolfram 09:03 < wsa> : refactored SDHI driver to use 'reset' and 'hw_reset' as intended by the MMC subsystem, sent out a fix to reset the card after the IP core was reset (needs follow up), finally was able to reproduce and inject the stalled SCC case, reworked series 'fix stalled SCC' and 'implement manual calibration' for SDHI and sent out, tried to add bus recovery to the IIC module based on 09:03 < wsa> generic pinctrl bus recovery, refactored timeout handling in the I2C driver, both for bus recovery and when resetting the IP core, sent patch to correctly handle FNA bit of the I2C module, updated i2ctransfer to support I2C_M_RECV_LEN, sent minor fixes along the way all over the place 09:03 < wsa> B - what I want to do until next time 09:03 < wsa> ------------------------------------- 09:03 < wsa> Shimoda-san 09:03 < wsa> : wants to convert rcar-pci dt doc to json-schema, and ping the serial gadget patch I have submitted 09:03 < wsa> Ulrich 09:03 < wsa> : wants to address feedback for "watchdog: da9063: wake up parent ahead of reboot", and implement atomic transfers for i2c-rcar 09:03 < wsa> Wolfram 09:03 < wsa> : wants to upstream SMBus emulation binding, core HostNotify support, and R-Car support for HostNotify, upstream I2C slave testunit, guide the increase of I2C_M_RECV_LEN length to 255 and upstream R-Car support for it 09:03 < wsa> C - problems I currently have 09:03 < wsa> ----------------------------- 09:03 < wsa> Geert 09:03 < wsa> : wonders how to avoid PCIe s2ram crash on R-Car Gen2 09:03 < wsa> Wolfram 09:03 < wsa> : found out that adding bus recovery to IIC not possible at the moment because we cannot switch to/from GPIO state using pinctrl_set_state(). Might be a task for the core group because PWM could use it, too, for zero duty-cycles. However, for IIC it is low priority because bus recovery is mostly useful on Gen2. Another issue is that there is no response from Rob about the SMBus emulation binding 09:04 < wsa> If you have questions or comments, please fire away 09:04 < wsa> I'll start with asking geertu a one-line summary for the PCIe crash? Is there something in the s2ram which gets lost during suspend? 09:05 < marex> I was about to ask the same 09:05 < geertu> wsa: marex: It's the same issue as on R-Car Gen3. 09:05 < geertu> But on arm64, it was fixed in ATF (by marex-san) 09:05 < marex> geertu: thats on RZ then ? 09:06 < geertu> marex: No, R-Car Gen2 (koelsch). But RZ/G1 should be affected, too. 09:06 < marex> ah sigh 09:07 < geertu> https://github.com/ARM-software/arm-trusted-firmware/commit/0969397f295621aa26b3d14b76dd397d22be58bf 09:07 < geertu> On arm32, we need to hook up something into the exception handling in Linux? 09:07 < marex> geertu: so is linux able to get the fault and fix it up ? 09:07 < geertu> marex: Currently not 09:08 < marex> geertu: I suspect you might just need to do as iMX6 does 09:08 < marex> geertu: that one did generate some faults when PCIe went nuts too 09:08 < marex> geertu: and there both U-Boot and Linux hooked the fault handler 09:09 < wsa> geertu: what is missing for Linux? 09:09 < marex> wsa: the same workaround as in TFA apparently 09:09 < geertu> marex: Sounds like a good job for the PCI DRIVER FOR RENESAS R-CAR maintainer? ;-) 09:09 < marex> wsa: except implemented via the fault hooks 09:10 < marex> wsa: that is , IFF , the gen2 generates such a fault instead of locking up 09:10 < marex> needs to be checked 09:10 < geertu> marex: It generates such a fault 09:11 < wsa> ok, that's sounds doable? I understood Geert's comment that way that Linux is missing some prerequisite to handle it 09:11 < marex> wsa: nope 09:11 < wsa> So, on Gen3, why did we chose the ATF way instead of pure Linux? 09:11 < marex> wsa: the stuff should be all there 09:11 < marex> wsa: because on Gen3, you get a fault in EL3 09:11 < geertu> Unhandled fault: asynchronous external abort (0x1211) at 0x00000000 09:12 < wsa> ok 09:12 < geertu> (that line is from M2-W) 09:12 < marex> geertu: hold on, I need some coffee first 09:13 < wsa> ok, I'll wait for Marex to get some coffee and _then_ ask him if he is interested in tackling it ;) 09:14 < wsa> shimoda: thanks for the quick testing of my SDHI patches 09:14 < wsa> I really hope we have no more stalled SCC problems anymore 09:15 < shimoda> wsa: you're welcome! i'll review manual calib patches later 09:15 < wsa> Though, the fact that it stalled when switching the divider was interesting, but as said, I don't fully get it from the documentation I have 09:15 < wsa> shimoda: Awesome, thanks! 09:16 < marex> geertu: drivers/pci/controller/dwc/pci-imx6.c 09:16 < marex> 1300 hook_fault_code(8, imx6q_pcie_abort_handler, SIGBUS, 0, 09:16 < marex> 1301 "external abort on non-linefetch"); 09:16 < marex> look ^ 09:16 < marex> so we'll need similar "workaround" 09:18 < wsa> geertu: the 77961-io todo mentions adding cmt and sh-msiof. Is there a chance to get this added via remote access? Didn't damm have some SPI device to connect or am I remembering wrong? 09:18 < geertu> wsa: No SPI devices, AFAIK 09:18 < wsa> uli___: seems that Guenter missed that there is no RPM that late, or? 09:19 < wsa> geertu: ah, okay. well, you would have known if there are any ;) 09:19 < damm> i don't mind hooking up stuff if needed 09:19 < geertu> wsa: I think he doesn't know much about RPM in general 09:20 < uli___> wsa: just needs a little explaining, I guess 09:20 < wsa> damm: that's great! next one will be the CAN devices ;) 09:20 < geertu> damm: Perhaps just a wire? Then we can do SPI loopback tests 09:20 < wsa> damm: so, get your car close to the lab 09:20 < damm> great! I need an extension cable to be able to reach all the way to the car =) 09:20 < wsa> :) 09:21 < damm> send me an email with details please 09:21 < damm> if you do it today EU time then I can finish it this week 09:21 < damm> otherwise it will have to wait for a couple of weeks 09:22 < wsa> magnus is going to okinawa? 09:22 < damm> just leaving the remote access location for a while 09:23 < marex> damm: would you still be able to reinstate and/or install ssh keys ? 09:23 < damm> yeah that i can do remotely 09:23 < geertu> marex: As you're mostly familiar with the PCIe issue, can you please handle it? 09:23 < damm> cables are more difficult =) 09:24 < wsa> marex: that would be great, in deed 09:24 < marex> yeah 09:24 < wsa> awesome, thanks! 09:25 < wsa> this is all from my side, any question left? 09:26 < wsa> not the case 09:26 < wsa> geertu: ready for core? 09:26 < geertu> wsa: But but... it's not yet hh:30? 09:27 < wsa> IO group is in HS400 mode 09:27 < geertu> please retune now ;-) 09:27 < wsa> uh oh 09:28 < moriperi> wsa: 1 thing from me 09:28 < marex> geertu: downshift to MMC52 is hard, dont torture them 09:28 < wsa> geertu triggerd a halted system again, great! ;) 09:28 < wsa> moriperi: what is it? 09:28 < moriperi> Now BSP team is tring to enable I2C on V3U board, but has timeout error. 09:28 < moriperi> But, it started works if some delay was added, they said. 09:28 < moriperi> 1 concern is that V3U is *almost* same as previous SoC, but in my understanding, previous SoC needed some workaround. 09:29 < moriperi> If V3U was fixed around I2C, workaround might be not needed anymore. 09:29 < moriperi> Now BSP team is investigating / confirming. 09:29 < moriperi> So nothing to do today, but just information for you. 09:29 < wsa> OK 09:29 < moriperi> We will ask something to you if V3U board was ready 09:30 < moriperi> that's all from me, thanks 09:30 < wsa> I'll just wait 09:30 < wsa> I can't recall any workaround or additional delay from the top of my head, but we will see... 09:30 < marex> real shame there's no OSSJ this year, we could've done V3U peripericon and bring it all up 09:30 < geertu> marex: virtual peripericon? 09:30 < geertu> Time to launch core?