From e70b223b65e4199a4fecb83158f9a37a51eab9ca Mon Sep 17 00:00:00 2001 From: Kuninori Morimoto Date: Thu, 3 Sep 2020 18:15:06 +0900 Subject: wiki: add IO chatlog from 20200903 Signed-off-by: Kuninori Morimoto --- wiki/Chat_log/20200903-io-chatlog | 175 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 175 insertions(+) create mode 100644 wiki/Chat_log/20200903-io-chatlog diff --git a/wiki/Chat_log/20200903-io-chatlog b/wiki/Chat_log/20200903-io-chatlog new file mode 100644 index 0000000..8d4e6a7 --- /dev/null +++ b/wiki/Chat_log/20200903-io-chatlog @@ -0,0 +1,175 @@ + 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 + :) -- cgit v1.2.3