1 files changed, 159 insertions, 0 deletions
diff --git a/wiki/Chat_log/20190523-io-chatlog b/wiki/Chat_log/20190523-io-chatlog
new file mode 100644
index 0000000..77f60b7
--- /dev/null
+++ b/wiki/Chat_log/20190523-io-chatlog
@@ -0,0 +1,159 @@
+09:02 < wsa> let's start with the IO meeting then
+09:02 < jmondi> Hello, good morning
+09:02 < wsa> usual status updates
+09:02 < wsa> A - what have I done since last time
+09:02 < wsa> ------------------------------------
+09:02 < wsa> Kaneko-san
+09:02 < wsa> : posted v3 of update calculation formula for Gen3 Thermal
+09:02 < wsa> Niklas
+09:02 < wsa> : investigated Geert's comments on SDHI PM issue and came to an agreement
+09:02 < wsa> Shimoda-san
+09:02 < wsa> : sent patches for USB and SDHI with IOMMU support, reviewed a lot of USB
+09:02 < wsa>   patches as well as SDHI and SCIF patches
+09:02 < wsa> Simon
+09:02 < wsa> : posted v3 of H3 IPA support and dynamic power coefficient patches, tested
+09:02 < wsa>   v3 of update calculation formula for Gen3 Thermal
+09:02 < wsa> Ulrich
+09:02 < wsa> : sent RAVB patch to implement MTU change while device is up and investigated
+09:02 < wsa>   review comments
+09:02 < wsa> Wolfram
+09:02 < wsa> : sent and merged better API for i2c_new_device and i2c_new_dummy, sent a 
+09:02 < wsa>   watchdog cleanup series, resent DA9063 cleanup patches after rc1, tried to
+09:02 < wsa>   reproduce an OOPS, upported patch avoiding SDHI CRC error, reviewed SDHI and
+09:02 < wsa>   SCIF and I2C slave support patches, submitted talk proposal for plumbers
+09:02 < wsa> B - what I want to do until next time
+09:02 < wsa> -------------------------------------
+09:02 < wsa> Kaneko-san
+09:02 < wsa> : wants to keep at update calculation formula for Gen3 Thermal
+09:02 < wsa> Shimoda-san
+09:02 < wsa> : wants to continue discussions about SDHI with IOMMU support, Gen2 ethernet
+09:02 < wsa>   driver, SCIF with DMAC issue, send patches for USB, remove some meanwhile
+09:02 < wsa>   obsolete USB stuff and revise USB2 phy nodes for Gen3
+09:02 < wsa> Simon
+09:02 < wsa> : wants to send v4 of H3 IPA support and dynamic power coefficient patches,
+09:02 < wsa>   and follow up on RAVB on E3/D3 Errata
+09:02 < wsa> Ulrich
+09:02 < wsa> : wants to send v2 of RAVB patch to implement MTU change while device is up
+09:02 < wsa> Wolfram
+09:02 < wsa> : wants to upport new SDHI HS400 patch, start converting i2c_new_* users,
+09:02 < wsa>   handle 'arbitration lost' better with the IIC core, investigate SDR104
+09:02 < wsa>   regression with SDIO
+09:02 < wsa> C - problems I currently have
+09:02 < wsa> -----------------------------
+09:02 < wsa> Niklas
+09:02 < wsa> : needs review tags for his SDHI PM patch
+09:02 < wsa> Wolfram
+09:02 < wsa> : had no success in reproducing the OOPS so far
+09:02 < wsa> let me know if it needs updates
+09:03 < wsa> neg, geertu: can you give me a short summary of your agreement? Were the things Geert was seeing another issue?
+09:04 < wsa> kbingham: you there already?
+09:05 < neg> wsa: In short, geertu noticed more clock imbalances which turned out to be caused by other drivers (and non sdhi related clocks)
+09:05 < geertu> wsa: my suspend script changed pm_qos_resume_latency_us, which caused some issues
+09:05 < geertu> Changing pm_qos_resume_latency_us used to be needed, but apparently it now works without
+09:05 < geertu> hence the issues caused by it are gon
+09:05 < geertu> s/gon/gone/
+09:06 < geertu> So while SDHI is fine, there's another issue in MMCIF
+09:06 < wsa> neg: maybe it is a good idea to resend the patch then, and geert gives a tag for that resend
+09:06 < wsa> should make it more visible to Ulf
+09:07 < neg> geertu: thanks again for your effort working with this patch
+09:07 < wsa> geertu: only with APE6 or with Gen2 as well?
+09:07 < neg> wsa: OK, sounds good I will resend the patch
+09:07 < geertu> wsa: Only on older SH/R-Mobile
+09:08 < wsa> Does it look complicated?
+09:08 < geertu> MMC is always complicated ;-)
+09:08 < wsa> :D
+09:09 < neg> +1 ;-)
+09:10 < neg> Clocks that show imbalance are mmcif and sys-dmac
+09:10 < wsa> Well, if it is kinda simple, I'd like to ask neg to handle it somewhen in his base time. If it is complicated, then I think it is not worth it for that old platform.
+09:10 < neg> I only looked into mmcif, and I'm not sure it's a issue and might even be expected behavior
+09:11 < neg> Did not dig into sys-dmac after confirmed it was not related to the SDHI driver
+09:12 < wsa> I think Geert should have an opinion if that is expected behaviour? ;)
+09:12 < neg> I added it to my list of tasks to potentially work on as it's old boards. The SDHI fix seemed to be more important as it also effects Gen3
+09:12 < wsa> But I let you decide if it is worth the effort...
+09:12 < wsa> I'm all happy that the SDHI patch works as is :)
+09:13 < wsa> Thanks for working on that (with all the APE6 trouble), Niklas and Geert.
+09:13 < wsa> ok
+09:14 < geertu> the sys-dmac imbalance is on gen3
+09:14 < wsa> kbingham seems not here yet, I wanted to ask him about potential preferences for i2c_new_* conversion
+09:14 < wsa> will do that later today
+09:14 < wsa> any questions / comments from your side?
+09:15 < Marex> yep
+09:15 < geertu> I'll have a deeper look at the sys-dmac issue
+09:15 < Marex> I just learnt this https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-bsp.git/commit/?h=v4.14.75-ltsi/rcar-3.9.5.rc2&id=a0d396ede95a55a4dff6aa15ea314a3d35e2e842 patch might be limited to M3W only
+09:15 < Marex> just FYI
+09:16 < wsa> argh
+09:16 < wsa> all of M3-W?
+09:16 < horms> ouch!
+09:16 < Marex> wsa: I mean, I hope I wasnt off topic and that was a general question/comment call
+09:16 < wsa> "might" means we still need confirmation from the HW team?
+09:17 < wsa> definately on topic
+09:17 < Marex> wsa: I submitted similar patch to U-Boot, but Goda-san told me REL is working on confirming it on other SoCs and that it's confirmed on M3W only for now
+09:17 < wsa> good to know
+09:17 < Marex> wsa: that is all I know
+09:17 < kbingham> wsa, Hola
+09:17 < kbingham> Sorry - just saw your message :)
+09:17 < Marex> wsa: I said I'll wait for further information
+09:17 < kbingham> Oh - it wasn't even that long ago :)
+09:18 < Marex> wsa: will keep you updated
+09:18 < wsa> I'll postpone my todo-item for that patch, then
+09:18 < wsa> Marex: thanks for the heads up!
+09:18 < wsa> hi kbingham!
+09:18 < kbingham> wsa, Heya!
+09:18 < kbingham> Seems I forgot today was meeting day :)
+09:18 < wsa> kbingham: dunno if you saw it but i2c_new_dummy and _device now return errnos
+09:18 < Marex> wsa: feels like E3 might also be affected
+09:18 < wsa> you once requested that ont he I2c list, too
+09:18 < kbingham> wsa, I reviewed the patches didn't I :)
+09:18 < Marex> wsa: but that's just my guess
+09:18 < wsa> right
+09:19 < wsa> Marex: ok, will wait for official confirmation from Renesas
+09:19 < shimoda> Marek: all Gen3 SoCs has the HS400 correction issue. but we can look the issue on M3-W easily
+09:19 < shimoda> for some reason
+09:20 < wsa> kbingham: in that old mail, you said you were also interested in i2c_new_secondary_device() returning errno. Is that still needed?
+09:20 < shimoda> anyway, the correction feature is corrupt on the SoCs, BSP team made a kernel patch that Marek-san shows
+09:20 < kbingham> wsa, Hrm... new me doesn't remember what long ago me said - I'll go see.
+09:21 < wsa> kbingham: the thread was "i2c_new_{secondary_device,dummy,device}() return type."
+09:21 < Marex> shimoda: sooooo, how shall we proceed ? :)
+09:21 < wsa> shimoda: what would be your suggestion then? Should I upport that patch for Linux or wait until we have more information?
+09:22 < Marex> wsa: +1
+09:23 < kbingham> wsa, Aha, wow - old thread :) I do indeed make a lot of use of i2c_new_secondary_device() so Yes, i would also like to see that be converted.
+09:23 < shimoda> Marex: wsa: sorry for lack conclution. we should upport the patch for Linux.
+09:23 < kbingham> I think the number of users of i2c_new_secondary_device() are probably low enough that it could be converted directly ?
+09:23 < wsa> kbingham: yes
+09:23 < kbingham> (now that we have the return types on the other apis
+09:23 < kbingham> )
+09:23 < kbingham> Is that something you would like me to tackle ?
+09:24 < kbingham> Seems you have now done the blocking work that was necessary from my original request.
+09:24 < wsa> kbingham: there a lot of ways to start, so I wanted to ask you which would be most benefitial to you :)
+09:24 < wsa> kbingham: I'll do it
+09:24 < Marex> shimoda: is that OK with Goda-san too ?
+09:24 < wsa> shimoda: thanks for the conclusion
+09:25 < wsa> shimoda: I will work on upporting the patch, then. It needs a bit of preparational refactoring first, anyhow
+09:25 < kbingham> wsa, My usage is in "drivers/media/i2c/adv748x/adv748x-core.c:186""
+09:25 < shimoda> Marex: let me talk with goda-san now. please wait for a while
+09:26 < kbingham> And it seems there are only 5 users of the call ... so it should be an easy conversion.
+09:26 < wsa> yup
+09:26 < Marex> shimoda: thank you :)
+09:26 < wsa> "adv748x_initialise_clients"
+09:27 < wsa> ?
+09:27 < wsa> is that OK in English?
+09:27 < kbingham> "Initialise the client" with an adv748x prefix ?
+09:28 < Marex> kbingham: s/s/z/ probably ?
+09:28 < wsa> i thought it must be "initialize"
+09:28 < pinchartl> wsa: British English vs. American English :-)
+09:29 < kbingham> https://simple.wikipedia.org/wiki/British_English
+09:29 < geertu> wsa: That's US English, isn't it?
+09:29 < kbingham>     Some words in British English use "-ise" where "-ize" is used in American English. Spelling them with "-ize" is also done in Britain sometimes. However, this is very much frowned upon and would not be considered acceptable if writing for a British audience.
+09:29 < kbingham> :)
+09:29 < wsa> Good, so I learned something today
+09:29 < pinchartl> kbingham: I'm afraid that function names in the kernel use american english...
+09:29 < kbingham> (I had that page up already while writing a review to Neg :D heheh)
+09:29 < Marex> kbingham: but kernel is written in simplified English, so -ize ?
+09:29  * geertu realizes Trump wants a Brekzit
+09:30 < geertu> simplified -> "init"
+09:30 < pinchartl> you could make everybody happy with adv748x_init_clients()
+09:30 < shimoda> Marex: wsa: I'm sorry. my understanding is wrong. As goda-san said, we should wait for hw team conclusion because hw team still investigate this root cause. So, our upstream team also should wait.
+09:30 < wsa> shimoda: fine, too. will do
+09:30 < Marex> shimoda: will do, thank you for checking :-)
+09:31 < shimoda> Marex: wsa: thanks!
+09:31 < wsa> ok, I think we are done with IO