wiki: add IO chatlog from 20200903

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>

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> :)