welcome everyone, hope you are fine here are the collected status updates Status updates ============== A - what have I done since last time ------------------------------------ Geert : 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 Niklas : unsuccessfully tested SDIO WiFi with Koelsch on Gen2. Probably because of a too long cable. He will try a shorter one. Shimoda-san : 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 Ulrich : sent "watchdog: da9063: wake up parent ahead of reboot" to enable late atomic transfers with IIC [16:01] Wolfram : 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 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 B - what I want to do until next time ------------------------------------- Shimoda-san : wants to convert rcar-pci dt doc to json-schema, and ping the serial gadget patch I have submitted Ulrich : wants to address feedback for "watchdog: da9063: wake up parent ahead of reboot", and implement atomic transfers for i2c-rcar Wolfram : 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 C - problems I currently have ----------------------------- Geert : wonders how to avoid PCIe s2ram crash on R-Car Gen2 Wolfram : 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 If you have questions or comments, please fire away 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? [16:02] I was about to ask the same wsa: marex: It's the same issue as on R-Car Gen3. But on arm64, it was fixed in ATF (by marex-san) geertu: thats on RZ then ? marex: No, R-Car Gen2 (koelsch). But RZ/G1 should be affected, too. [16:03] ah sigh https://github.com/ARM-software/arm-trusted-firmware/commit/0969397f295621aa26b3d14b76dd397d22be58bf [16:04] On arm32, we need to hook up something into the exception handling in Linux? geertu: so is linux able to get the fault and fix it up ? marex: Currently not [16:05] geertu: I suspect you might just need to do as iMX6 does geertu: that one did generate some faults when PCIe went nuts too geertu: and there both U-Boot and Linux hooked the fault handler geertu: what is missing for Linux? [16:06] wsa: the same workaround as in TFA apparently marex: Sounds like a good job for the PCI DRIVER FOR RENESAS R-CAR maintainer? ;-) wsa: except implemented via the fault hooks [16:07] wsa: that is , IFF , the gen2 generates such a fault instead of locking up needs to be checked marex: It generates such a fault ok, that's sounds doable? I understood Geert's comment that way that Linux is missing some prerequisite to handle it [16:08] wsa: nope So, on Gen3, why did we chose the ATF way instead of pure Linux? wsa: the stuff should be all there wsa: because on Gen3, you get a fault in EL3 [16:09] Unhandled fault: asynchronous external abort (0x1211) at 0x00000000 ok (that line is from M2-W) geertu: hold on, I need some coffee first ok, I'll wait for Marex to get some coffee and _then_ ask him if he is interested in tackling it ;) [16:11] shimoda: thanks for the quick testing of my SDHI patches I really hope we have no more stalled SCC problems anymore wsa: you're welcome! i'll review manual calib patches later [16:12] 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 shimoda: Awesome, thanks! [16:13] geertu: drivers/pci/controller/dwc/pci-imx6.c 1300 hook_fault_code(8, imx6q_pcie_abort_handler, SIGBUS, 0, 1301 "external abort on non-linefetch"); look ^ so we'll need similar "workaround" 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? [16:15] wsa: No SPI devices, AFAIK uli___: seems that Guenter missed that there is no RPM that late, or? geertu: ah, okay. well, you would have known if there are any ;) [16:16] i don't mind hooking up stuff if needed wsa: I think he doesn't know much about RPM in general wsa: just needs a little explaining, I guess [16:17] damm: that's great! next one will be the CAN devices ;) damm: Perhaps just a wire? Then we can do SPI loopback tests damm: so, get your car close to the lab great! I need an extension cable to be able to reach all the way to the car =) :) send me an email with details please [16:18] if you do it today EU time then I can finish it this week otherwise it will have to wait for a couple of weeks magnus is going to okinawa? [16:19] just leaving the remote access location for a while [16:20] damm: would you still be able to reinstate and/or install ssh keys ? yeah that i can do remotely marex: As you're mostly familiar with the PCIe issue, can you please handle it? cables are more difficult =) marex: that would be great, in deed [16:21] yeah awesome, thanks! [16:22] this is all from my side, any question left? not the case [16:23] geertu: ready for core? wsa: But but... it's not yet hh:30? IO group is in HS400 mode [16:24] please retune now ;-) uh oh [16:25] wsa: 1 thing from me geertu: downshift to MMC52 is hard, dont torture them geertu triggerd a halted system again, great! ;) moriperi: what is it? Now BSP team is tring to enable I2C on V3U board, but has timeout error. But, it started works if some delay was added, they said. [16:26] 1 concern is that V3U is *almost* same as previous SoC, but in my understanding, previous SoC needed some workaround. If V3U was fixed around I2C, workaround might be not needed anymore. Now BSP team is investigating / confirming. So nothing to do today, but just information for you. OK We will ask something to you if V3U board was ready that's all from me, thanks [16:27] I'll just wait I can't recall any workaround or additional delay from the top of my head, but we will see... real shame there's no OSSJ this year, we could've done V3U peripericon and bring it all up marex: virtual peripericon? [16:28] Time to launch core? geertu: someone would have to write a qemulation of v3u oh ... can't we go to Japan just for V3U bringup :)