diff options
Diffstat (limited to 'wiki/Chat_log')
| -rw-r--r-- | wiki/Chat_log/20200903-io-chatlog | 298 |
1 files changed, 123 insertions, 175 deletions
diff --git a/wiki/Chat_log/20200903-io-chatlog b/wiki/Chat_log/20200903-io-chatlog index 8d4e6a7..0acacb9 100644 --- a/wiki/Chat_log/20200903-io-chatlog +++ b/wiki/Chat_log/20200903-io-chatlog @@ -1,175 +1,123 @@ -<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> :) +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? |