1 files changed, 98 insertions, 0 deletions
diff --git a/wiki/Chat_log/20190620-io-chatlog b/wiki/Chat_log/20190620-io-chatlog
new file mode 100644
index 0000000..affed2d
--- /dev/null
+++ b/wiki/Chat_log/20190620-io-chatlog
@@ -0,0 +1,98 @@
+09:04 < wsa> then, let's start the IO meeting
+09:05 < wsa> first 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> : started looking into sh-sci tx_dma_len == 0 issue
+09:05 < wsa> Kaneko-san
+09:05 < wsa> : got "rcar_gen3_thermal: Update calculation" merged
+09:05 < wsa> Shimoda-san
+09:05 < wsa> : sent new versions of the SDHI & IOMMU patch series and a DMA documentation
+09:05 < wsa>   fix, sent USB patches about removing memcpy and an unbalanced flag and
+09:05 < wsa>   adding a limitation, reviewed USB binding documentation changes
+09:05 < wsa> Simon
+09:05 < wsa> : posted patches renaming bindings documentation to a common pattern
+09:05 < wsa> Wolfram
+09:05 < wsa> : converted i2c_new_dummy() calls and i2c_new_secondary_device()  to new API,
+09:05 < wsa>   updated SDHI HS400 quirk patches and got them merged, worked on upporting
+09:05 < wsa>   SDHI manual calibration offsets, sent two treewide series fixing an awkward
+09:05 < wsa>   way to determine the adapter of an I2C client, smaller cleanup patches to the
+09:05 < wsa>   I2C + MFD + and media subsystems, reviewed Shimoda-san's next version of the
+09:05 < wsa>   SHDI IOMMU series + watchdog delay patches and some SDHI DTS patches, sent
+09:05 < wsa>   talk proposal for ELCE in Lyon
+09:05 < wsa> B - what I want to do until next time
+09:05 < wsa> -------------------------------------
+09:05 < wsa> Geert
+09:05 < wsa> : wants to fix sh-sci tx_dma_len == 0 issue
+09:05 < wsa> Shimoda-san
+09:05 < wsa> : wants to keep working on the SDHI & IOMMU patch series, refactor the struct
+09:05 < wsa>   members of the usbhs driver, and keep an eye on upstream patches to avoid
+09:05 < wsa>   using virt_boundary_mask API
+09:05 < wsa> Simon
+09:05 < wsa> : wants to address review comments
+09:05 < wsa> Wolfram
+09:05 < wsa> : wants to continue working on upporting SDHI manual calibration offsets,
+09:05 < wsa>   upport more SDHI patches, continue working on I2C API changes, resend patch
+09:05 < wsa>   to handle watchdog handover from bootloader
+09:05 < wsa> C - problems I currently have
+09:05 < wsa> -----------------------------
+09:05 < wsa> Ulrich
+09:05 < wsa> : didn't get a reply from Dave Miller about the RAVB MTU change implementation
+09:05 < wsa> Wolfram
+09:05 < wsa> : needs to delay the i2c_new_dummy() conversion because of a missing declaration
+09:05 < wsa>   in the i2c headers, and suffers from a lagging buildbot with lots of incomplete
+09:05 < wsa>   builds delaying the build tests of the I2C API changes
+09:06 < wsa> uli__: what about just sending the patch and asking the questions again next to the patch description?
+09:07 < wsa> horms: what happened to the "follow up on RAVB on E3/D3 Errata" task?
+09:07 < wsa> any patches I missed there?
+09:07 < horms> oops, let me add that back on the list
+09:08 < uli__> wsa: do you suggest to re-send the patch as is, or to implement the rollback somehow and ask if that's ok?
+09:09 < horms> I believe that the status is that we need to verify if setting tx timing delays in the phy is sufficient to miliate against the errata. The likely answer is no and thus we will be back to updating the driver/DT
+09:09 < wsa> uli__: I thought of trying the latter... unless you or others here have a different opinion?
+09:10 < uli__> no, i think that makes sense
+09:10 < wsa> cool
+09:11 < wsa> then, about the HS400 tap auto correction issue.. we still don't have further information from the HW team
+09:11 < wsa> yet, it causes troubles on at least my M3-N
+09:12 < wsa> troubles == WARNs and OOPSes
+09:13 < Marex> wsa: which patch is that ?
+09:13 < wsa> If we don't get the information very soon(tm), I think we should disable HS400 until we got more information
+09:13 < horms> wsa: I agree
+09:14 < wsa> Marex: the one you already implemented for U-Boot and then we got advised to wait for more details
+09:14 < horms> Would it only be disabled on M3-N, or more widely?
+09:14 < shimoda> wsa: about hs400 issue, the bsp commit e6a40476f25287eb6e6df5c4 seems a workaround code, but I'll ask someone that is final decision or not
+09:14 < Marex> wsa: OK, that one
+09:15 < wsa> horms: I think we should first test on various SoCs again. I prefer "per-SoC", but if we can't get a clear picture, we need to disable it globally
+09:15 < horms> wsa: that sounds reasonable to me
+09:15 < Marex> wsa: I _think_ it improved the HS400 calibration behavior on E3, but I might be wrong
+09:16 -!- damm [~damm@s214090.ppp.asahi-net.or.jp] has joined #periperi
+09:16 < wsa> shimoda: thanks for asking them!
+09:18 < wsa> That being said: I really wonder about the WARNings and OOPSes. I'd think we can fail more gracefully if the tuning is out-of-sync, but there seem to be competing workqueue issues
+09:18 < wsa> I didn't have time to follow up on those, though. So, I wonder if there is someone interested to have a look at that?
+09:19 < wsa> uli__ maybe? or kaneko maybe?
+09:19 < Marex> wsa: maybe the whole calibration code needs a once-over? It seems like a convoluted mess :)
+09:20 < geertu> How come you get an OOPS if tuning fails?
+09:20 < horms> wsa: I would be happy to take a look into this
+09:20 < horms> if no one else wants it / you think that is appropriate
+09:21 < wsa> horms: sure, I just thougth you might be busy, but if you have the time I'd be happy if you have a look
+09:22 < horms> I expect to have a bit of time next quarter, which is coming up pretty soon now
+09:22 < wsa> On my M3-N, it shows by booting recent upstream kernel with renesas_defconfig and wait for 4 minutes or so
+09:22 < wsa> if it doesn't show on your M3-N, I can give you a .config we could try
+09:23 < horms> ok, sure
+09:23 < wsa> horms: first thing would be to check if you can reproduce it
+09:23 < horms> so I boot, then wait for mahem?
+09:23 < shimoda> wsa: I asked Goda-san about HS400 issue, Renesas needs to continue investigate the issue. This means the BSP patch I indicated is still not good unfortunately..
+09:24 < wsa> yup, I can mail you some logs with stuff I was seeing
+09:24 < wsa> so you know what to look for
+09:24 < horms> thanks, that would be helpful
+09:24 < wsa> shimoda: thanks for checking!
+09:24 < wsa> shimoda: do you agree that we need to disable HS400 if we don't get the information in time for v5.2?
+09:25 < Marex> indeed, I will hold off the U-Boot patch too
+09:26 < wsa> are there other questions / requests from your side?
+09:27 < shimoda> wsa: now i am working for eMMC + IOMMU patch series, if possible, i'd like to keep HS400 mode as-is
+09:29 < wsa> then, for now, let's just hope we will get more details in time :)
+09:29 < wsa> so, i think this was it for the IO meeting?
+09:30 < wsa> geertu: you are ready?
+09:30  * geertu is ready
+09:30 < wsa> then, thank you all for this meeting!