1 files changed, 94 insertions, 0 deletions
diff --git a/wiki/Chat_log/20201126-io-chatlog b/wiki/Chat_log/20201126-io-chatlog
new file mode 100644
index 0000000..69049e5
--- /dev/null
+++ b/wiki/Chat_log/20201126-io-chatlog
@@ -0,0 +1,94 @@
+09:05 < wsa> welcome to the IO meeting
+09:05 < wsa> hope you are all well (again)
+09:05 < wsa> here are the status updates
+09:05 < wsa> Status updates
+09:05 < wsa> ==============
+09:05 < wsa> A - what have I done since last time
+09:05 < wsa> ------------------------------------
+09:05 < wsa> Geert
+09:05 < wsa> : enabled and tested MSIOF on R-Car V3U with manual pinctrl
+09:05 < wsa> Niklas
+09:05 < wsa> : had an initial look at Thermal support for V3U
+09:05 < wsa> Shimoda-san
+09:05 < wsa> : investigated the issues of the SDHI driver with Wolfram, and additionally sent patches to clean up resources in the SDHI driver, discussed using MMC aliases in DT, resent SCIF bindings for V3U, and discussed sending a power off notification in the MMC core
+09:05 < wsa> Wolfram
+09:05 < wsa> : worked on a lot of SDHI related issues: sent series to remove the hw_reset workaround by properly resetting the SCC which fixes the SD card insertion regression, sent series to reset SCC only when available, updated the "refactor SCC reset" series, sent cleanup series made possible by the previous refactoring, upported BSP patch to clear stale IRQs on errors, sent out series
+09:05 < wsa>  for proper max_busy_timeout handling, worked on a patch for resetting via reset controller, discussed how to handle SDHn clocks better nad how to handle data timeouts
+09:05 < wsa> B - what I want to do until next time
+09:05 < wsa> -------------------------------------
+09:05 < wsa> Geert
+09:05 < wsa> : wants to retest MSIOF when R-Car V3U pinctrl driver is posted
+09:05 < wsa> Niklas
+09:05 < wsa> : wants to test if V3U thermal can be supported with existing driver with small changes in polling mode, and work on the additional task about timers
+09:05 < wsa> Shimoda-san
+09:05 < wsa> : wants to collect more information about R-Car Gen3e, continue to develop R-Car S4 Ethernet driver, continue to investigate SDHI driver's issues, add some pages about eMMC (block merging and PARTUUID) to the elinux wiki
+09:05 < wsa> Ulrich
+09:05 < wsa> : wants to implement atomic transfers for I2C
+09:05 < wsa> Wolfram
+09:05 < wsa> : wants to keep working on the open SDHI tickets, enable and test V3U IO devices, guide increase of I2C_M_RECV_LEN length to 255 and upstream R-Car support for it, resend WDT patch to fix scheduling while atomic, start with isolated CPUs as logic analyzers
+09:06 < wsa> C - problems I currently have
+09:06 < wsa> -----------------------------
+09:06 < wsa> Geert
+09:06 < wsa> : notes that MSIOF external loopback test fails on R-Car V3U/Falcon, and got no feedback on an IIC patch for the suspended state
+09:06 < wsa> geertu: reading A) and C) I didn't really get if MSIOF testing was a success or not?
+09:07 < wsa> geertu: and sorry for the i2c-sh_mobile delay. I plan to have a non-SDHI week next week
+09:08 <@geertu> wsa: it worked in the sense that the driver didn't complain (e.g no hardware timeout), but the received data over loopback was wrong
+09:08 < wsa> marex: lorenzo responded to your PCIe patch. IIRC he asked an outdated question, or?
+09:08 < wsa> geertu: and the idea is to wait for the PFC driver to see if it works then?
+09:09 < marex> wsa: I still need to read that email
+09:09 <@geertu> wsa: Indeed. I may have overlooked something in my manual pinctrl config
+09:09 <@geertu> marex: We want it as a fix for v5.9^Wv5.10, no?
+09:09 < wsa> marex: ok
+09:09 < marex> geertu: it -- the pcie 32bit thing ?
+09:10 < wsa> geertu: ok, makes sense
+09:10 < wsa> shimoday: I'd like to recap the open SDHI issues, so we know if we are aligned
+09:11 < shimoday> wsa: i got it. may i recap open SDHI issues on an email later?
+09:12 < wsa> there is the SDHn discussion, where Geert made an interesting suggestion. However, IIUC you implemented an clock framework abuse because it is simpler?
+09:12 < wsa> you = you / or the BSP team
+09:13 < wsa> and then, there is the open issue of resetting via the reset controller; we have a prototype but are waiting for feedback from the HW team
+09:14 < shimoday> wsa: about SDHn, yes, bsp team tried it because it seems easy than Geert-san's suggestion
+09:15 < wsa> I hope the "max_busy_timeout" issue is solved with my latest series; we could honor "cmd->busy_timeout" from the MMC core, but this is an additional optimization, something like the cherry on top. Not urgent
+09:15 < shimoday> wsa: about reset controller for SDHI, I'm asking hw team but I got any feedback yet
+09:16 < shimoday> wsa: about max_busy_timeout, I'm testing it and seems OK
+09:16 < wsa> and then, we need to take care of data timeout; I still have to dive into your last email again, but it seems more refactoring of the BSP patch is needed
+09:17 < wsa> these are the open issues I have on my list, if you have more, please tell :)
+09:18 < shimoday> wsa: about data timeout, yes, i also think we need more refactoring to follow both mmc_test #15 and SDHI manual (retuning)
+09:19 < wsa> shimoday: but are you okay that we try Geert's suggestion for upstream (SDHn clock)
+09:19 < wsa> ?
+09:20 < shimoday> wsa: i have one more thing from bsp team, but I don't ask you yet :)
+09:20 < shimoday> bsp team said the mmc performance on v5.4 is lower than v4.14.
+09:21 < shimoday> i tried to investiagte this a little, but I'm not sure this is really sdhi driver issue or not
+09:22 < shimoday> so, I'll investigate this by myself (sorry, I should report this on today's report)
+09:22 < wsa> shimoday: yes, it is hard to say if it is SDHI or MMC core
+09:22 < wsa> without specific testing
+09:23 < wsa> is it significant?
+09:24 < shimoday> wsa: perhaps, it's significant because I guess customer will ask Renesas about this after provided the v5.4 base BSP
+09:25 < wsa> yeah, it is important, that is for sure
+09:25 < wsa> I mean is the performance loss like 50% or more like 5% or 0.5%?
+09:26 < shimoday> according to bsp team report, on v4.14 = 240MB/s (read), on v5.4 = 173MB/s (read)
+09:27 < shimoday> if we use IPMMU, on v4.14 = 270MB/s, on v5.4 = 240MB/s
+09:27 < shimoday> so, BSP team is worries about non-IPMMU speed
+09:28 < wsa> 240 -> 173, that is significant
+09:28 <@geertu> sounds like some bounce-buffering is involved if the IPMMU is not used
+09:28 < wsa> I'll check why I never noticed sth like that
+09:29 < wsa> are there any other questions from you guys?
+09:29 < marex> wsa: 173 is HS200, 240 is HS400 ...
+09:29 < marex> wsa: so likely HS400 calibration failed
+09:29 < shimoday> wsa: thanks!
+09:30 < wsa> marex: interestig pointer
+09:30 < wsa> thanks!
+09:30 <@geertu> marex: Hmm, IPMMU or not should not impact HS400 calib
+09:30 < shimoday> marex: i'm sorry, my report "on v4.14" and "on v5.4" are BSPs
+09:31 < shimoday> v4.14 means rcar-3.9.x, v5.4 means rcar-4.1.0.rc1
+09:31 < shimoday> so, bsp team use HS400 on these kernel versions i think
+09:34 < wsa> okay, let's see if I can reproduce the results
+09:34 < marex> shimoday: the thing is, if you do sustained block read in HS200, the bus tops at ~170 MiB/s, for HS400 the bus tops at 350 MiB/s , but the card does at 240 MiB/s
+09:35 < marex> so the numbers provided would indicate HS400 mode problem
+09:35 < marex> probably cat /sys/kernel/debug/mmc*/ios would give you some input quickly
+09:36 < marex> geertu: the IPMMU difference is likely due to the buffers being above 32bit boundary, with IPMMU they dont have to be copied back and forth
+09:37 <@geertu> marex: yeah, bounce buffers. but v5.4+ipmmu does should hs400 speeds
+09:37 <@geertu> s/should/show/
+09:39 < marex> geertu: aha, thats a valid point
+09:42 < shimoday> marex: thanks. I think so about these speeds. i'll check the ios later
+09:42 < wsa> okay
+09:42 < wsa> shall we move to core then?