summaryrefslogtreecommitdiff
path: root/wiki/Chat_log/20200903-io-chatlog
diff options
context:
space:
mode:
Diffstat (limited to 'wiki/Chat_log/20200903-io-chatlog')
-rw-r--r--wiki/Chat_log/20200903-io-chatlog175
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> :)