1 files changed, 88 insertions, 0 deletions
diff --git a/wiki/Chat_log/20200514-io-chatlog b/wiki/Chat_log/20200514-io-chatlog
new file mode 100644
index 0000000..5af33ab
--- /dev/null
+++ b/wiki/Chat_log/20200514-io-chatlog
@@ -0,0 +1,88 @@
+09:04 < wsa> welcome back, morimoto-san!
+09:04 < wsa> so, here are the status updates
+09:04 < wsa> Status updates
+09:04 < wsa> ==============
+09:04 < wsa> A - what have I done since last time
+09:04 < wsa> ------------------------------------
+09:04 < wsa> Geert
+09:04 < wsa> : did DT binding doc conversion to json-schema for CMT, OSTM, TMU, WDT, and fixed the DMA boundary mask for SATA
+09:04 < wsa> Marek
+09:04 < wsa> : fixed bugs in R-Car PCIe suspend/resume path
+09:04 < wsa> Niklas
+09:04 < wsa> : did DT binding doc conversion to json-schema for Thermal, also a cleanup for the thermal driver
+09:04 < wsa> Shimoda-san
+09:04 < wsa> : submitted patches to enable PWM and PCIE on R8A77961, reviewed PCIe endpoint support
+09:04 < wsa> Ulrich
+09:04 < wsa> : sent a new version of the never-disable-WDT-clock series, and worked on atomic_xfer support for i2c-sh_mobile
+09:04 < wsa> Wolfram
+09:04 < wsa> : upported SDHI patch to avoid bad TAPs with HS400, debugged an SDHI clock imbalance regression found by Geert and sent a fix and another clock related improvement, pushed the final changes of I2C API conversion, guided a bit of discussions about blocked I2C devices and refactored the documentation for generic I2C bindings as a preparation, minor changes to SDHI, CSI2, DRM, I2C,
+09:04 < wsa>  reviewed upstream changes to the i2c-slave interface
+09:04 < wsa> B - what I want to do until next time
+09:04 < wsa> -------------------------------------
+09:04 < wsa> Geert
+09:04 < wsa> : wants to do more DT binding doc conversions to json-schema, and check for RSPI improvements
+09:04 < wsa> Shimoda-san
+09:04 < wsa> : wants to check a BSP team's report about dma map/unmap unbalance in the error path of the SDHI driver, continue to collect information about "R-Car Gen4" hardware IPs, continue to make a plan how to implement the Gen4 Ethernet HW IP driver, and update renesas_sdhi_sys_dmac patches if possible
+09:04 < wsa> Ulrich
+09:04 < wsa> : wants to finish i2c-sh_mobile and implement i2c-rcar atomic_xfer support
+09:04 < wsa> Wolfram
+09:04 < wsa> : wants to debug OOPSes when NON_REMOVABLE workaround for SDHI is removed, get the series about blocked I2C devices in DT applied, review Ulrich's new WDT clock patches
+09:04 < morimoto> geertu: thanks. Yes, Now I'm OK
+09:05 < wsa> C - problems I currently have
+09:05 < wsa> -----------------------------
+09:05 < wsa> everyone
+09:05 < wsa> : covid19 restrictions everywhere
+09:05 < wsa> questions I have
+09:06 < wsa> uli__: was it possible to kind of reuse the non-atomic xfer function for the atomic one? Or does it need a seperate function?
+09:06 < uli__> for sh_mobile, it's possible to reuse what is there
+09:06 < uli__> rcar is a bit more convoluted, i still have to look into that
+09:06 < wsa> shimoda: I forgot, "update renesas_sdhi_sys_dmac patches if possible", what kind of issue is fixed by these patches?
+09:07 < wsa> uli__: well, still, a good start for sh_mobile then. Good news!
+09:08 < wsa> shimoda: also looking forward to the new DMA imbalance thing for SDHI ;)
+09:08 < shimoda> wsa: this is related to performance problem. but, today, i don't have any compline from a reporter. so, we can postpone I think :)
+09:09 < wsa> shimoda: okay
+09:09 < shimoda> wsa: yes, i got this imbalance report on 12th May, but this report is in Japanese. I cannot forward it to EuroPeri now...
+09:10 < wsa> After the clk and RPM updates to the SDHI driver (posted yesterday), I know get interesting OOPSes when I try to revert the NON_REMOVABLE workaround we still have in the driver
+09:10 < wsa> s/know/now/
+09:10 < wsa> which is nice because I always suspected them to be RPM related
+09:11 < geertu> wsa: you mean they might be DMA related?
+09:11 < wsa> geertu: DMA?
+09:12 < geertu> wsa: ^ DMA imbalance
+09:12 < shimoda> imbalance issue seems to be possible to happen. but, there is difficult to reproduce, i guess.
+09:12 < wsa> nope, the DMA imbalance seems to be in the error path of probe
+09:12 < geertu> wsa: I agree it's good to have a reliable reproducer
+09:13 < wsa> yeah, I will have a close look the next days
+09:14 < wsa> i think this is it from my side...
+09:14 < wsa> anything to discuss on your side?
+09:14 < wsa> like people volunteering to do more DT binding conversions? ;)
+09:15 < neg> :-)
+09:15 < geertu> wsa: I'll give your SDHI patches a try on the other platforms
+09:15 < wsa> geertu: much appreciated, thanks!
+09:15 < geertu> The _noidle one looks like a nice catch
+09:16 < geertu> wsa: Just wondering, why do you still need renesas_sdhi_clk_{en,di}sable()?
+09:16 < wsa> yes, well hidden within all these RPM calls
+09:16 < wsa> the TMIO core calls it
+09:17 < shimoda> ah, btw, do you know whether ethernet driver causes tx watchdog timeout?
+09:17 < shimoda> s/whether/how to cause/
+09:17 < geertu> wsa: Let me rephrase: why didn't you make renesas_sdhi_clk_{en,di}sable() empty?
+09:18 < shimoda> https://marc.info/?l=linux-renesas-soc&m=158641874314353&w=2
+09:18 < geertu> shimoda: Doesn't that mean the packet couldn't be sent, e.g. due to bad cable, or corrupted TX ring buffer?
+09:19 < wsa> geertu: I don't get what you mean. It is needed when the TMIO core calls suspend/resume
+09:20 < wsa> geertu: both runtime and system
+09:20 < geertu> wsa: Shouldn't RPM take care of the actual clocks?
+09:20 < geertu> shimoda: That email doesn't mention tx watchdog timeout, is it related?
+09:21 < wsa> shimoda: maybe we can ask him how he got this panic?
+09:23 < wsa> geertu: the RPM stuff for TMIO is from 2011. So, I don't know if all drivers using the TMIO core have their clocks managed via RPM
+09:23 < shimoda> geertu: ravb e6800000.ethernet ethernet: transmit timed out, status 00000000, resetting... is related to tx watchdog timeout
+09:25 < geertu> shimoda: thx, missed that. I believe last time I wrote an Ethernet driver, it still included "watchdog" in the error message ;-)
+09:25 < shimoda> wsa: you're right. but, renesas internal support team also got this report internaly. But, they doesn't have such information..
+09:25 < geertu> wsa: But renesas_sdhi_clk_{en,di}sable() is not core mmio, so we can do whatever we want in that function
+09:26 < geertu> incl. not touching clocks directly
+09:26 < wsa> I can check
+09:26 < shimoda> anyway, ask how to reproduce is better.
+09:26 < shimoda> thanks!
+09:27 < wsa> shimoda: let's hope he can provide an answer then
+09:27 < wsa> okay, I guess this was it for today?
+09:27 < wsa> last call
+09:28 < wsa> so, thank you for the meeting today!
+09:28 < wsa> and have a nice continued day