path: root/wiki/Chat_log/20190523-io-chatlog

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