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