09:03 < wsa_> welcome to this io meeting
09:03 -!- morimoto [~user@relprex3.renesas.com] has joined #periperi
09:03 < wsa_> agenda will be status updates and open questions
09:04 < wsa_> here are my collected status updates:
09:04 < wsa_> A - what have I done since last time
09:04 < wsa_> ------------------------------------
09:04 < wsa_> Geert
09:04 < wsa_> : updated the Gen2 watchdog blacklist
09:04 < wsa_> Kaneko-san
09:04 < wsa_> : posted series for M3-N SDHI support
09:04 < wsa_> Niklas
09:04 < wsa_> : got most thermal patches merged, did M3-N I2C enablement
09:04 < wsa_> Shimoda-san
09:04 < wsa_> : got upstream feedback about USB role switch, debugged suspend/resume issue
09:04 < wsa_> Simon
09:04 < wsa_> : sent out some DTS and defconfig patches
09:04 < wsa_> Ulrich
09:04 < wsa_> : checked BSP patch about RPM with SCIF
09:04 < wsa_> Wolfram
09:04 < wsa_> : started upstream discussions about I2C core PM and MMC/SD fallback for highspeed modes,
09:04 < wsa_>   sent out patches for I2C PM & M3-N WDT & EEPROMs on Gen3 + Alt & documentation for i2c-rcar,
09:04 < wsa_>   analyzed and reported back a breakage of a BSP patch for i2c-rcar, discussed periject, tested
09:04 < wsa_>   M3-N SDHI, and sent out two tree-wide cleanup series
09:04 < wsa_> B - what I want to do until next time
09:04 < wsa_> -------------------------------------
09:04 < wsa_> Kaneko-san
09:04 < wsa_> : wants to send next version of D3 thermal series and M3-N SDHI support
09:04 < wsa_> Niklas
09:04 < wsa_> : wants to resume SDHI upporting work
09:04 < wsa_> Shimoda-san
09:04 < wsa_> : wants to keep at the USB role switch topic, continue with the suspend/resume issue, and implement
09:04 < wsa_>   PHY GPIO support for E3 as well as Ethernet support for E3
09:04 < wsa_> Simon
09:04 < wsa_> : wants to continue HS400 support, follow up on RAVB upporting, and update QEMU performance testing report
09:04 < wsa_> Ulrich
09:04 < wsa_> : wants to ask BSP team about the SCIF patch
09:04 < wsa_> Wolfram
09:04 < wsa_> : wants to keep up with the started discussions, do more BSP upporting, implement QEMU VIRTIO
09:04 < wsa_>   passthrough for I2C clients
09:04 < wsa_> C - problems I currently have
09:04 < wsa_> -----------------------------
09:04 < wsa_> Niklas:
09:04 < wsa_> : lagged with SDHI work because of other stuff, still needs HW for Gen3 thermal fuses 
09:04 < wsa_> Ulrich:
09:04 < wsa_> : needs decision how to handle DMA for SCIF2 on Gen3
09:04 < wsa_> Wolfram
09:04 < wsa_> : couldn't find a non-VIRTIO solution for QEMU I2C passthrough because of the a-priori-knowledge problem
09:04 < wsa_> Please let me know if I missed / misinterpreted something
09:05 < wsa_> About I2C on M3-N, it seems we need conflict management here ;)
09:06 < wsa_> Niklas did it already because he needed it for MM work, but it was scheduled for Kaneko-san
09:06 < wsa_> However, there seems to be more testing missing
09:06 < geertu> wsa_: Same for M3-N WDT?
09:07 < neg> I'm happy to drop my patches as long as M3-N I2C4 are in next renesas-drivers ;-)
09:07 < wsa_> horms: did Kaneko-san already starte with I2C on M3-N?
09:07 < horms> wsa_: I asked him to but I doubt he has
09:08 < horms> likewise for WDT
09:08 < horms> the usual pattern is that I ping him after these meetings and magically patches appear
09:09 < horms> So how about I ask Kaneko-san to handle WDT and drop I2C?
09:09 < wsa_> so, maybe Niklas can post the patches as RFT and Kaneko-san can review/test them? Do you think this would work?
09:09 < geertu> Testing patches is always a good thing to do...
09:11 < horms> wsa_: well, the testing-arm of the Kaneko-san operation is me. but yes, that sounds like a good plan
09:11 < wsa_> about WDT: I only sent out the bindings, but didn't update the DTS etc...
09:11 < wsa_> or did someone do this and I missed it?
09:12 < wsa_> neg: can you post the patch as RFT then?
09:12 < horms> WDT: How about I check and task Kaneko-san with doing whatever is missing
09:12 < neg> wsa_: will do
09:12 < wsa_> horms: perfect
09:13 < wsa_> about the SCIF2 DMA issue
09:13 < wsa_> that came up before, no?
09:13 < wsa_> I think we know it is there but it is not official
09:14 < geertu> I've justed checked rev 1.00
09:14 < geertu> SCIF2 exists in the SCIF section
09:14 < uli___> so it officially exists now?
09:14 < geertu> SCIF2 interrupt is now documented as SCIF2 (I think it wasn't in some older rev)
09:14 < geertu> SCIF2 module clock is now documented as SCIF2 (I think it wasn't in some older rev)
09:15 < geertu> SCIF2 DMA is not documented.
09:15 < geertu> Note that the interrupt, module clock, and DMA channel numbers are "odd", and may related to another undocumented module (irda?)
09:16 < wsa_> but it does work as a SCIF?
09:16 < geertu> IIRC, in the first rev SCIF2 didn't exist at all, but it obviously works, as it's the consle
09:16 < geertu> s/consle/console/
09:16 < wsa_> that answers :)
09:17 < wsa_> well, let's stick to the documentation I'd say
09:17 < geertu> And DMA works, too. It doesn't work when you use the "expected" (check the holes in the datasheet) DMA channel numbers
09:17 -!- dammsan [~dammsan@s214090.ppp.asahi-net.or.jp] has joined #periperi
09:17 -!- horms_ [~horms@a80-127-179-77.adsl.xs4all.nl] has joined #periperi
09:18 -!- horms [~horms@2001:982:756:1:c685:8ff:fe7c:9971] has quit Quit: Leaving
09:18 -!- horms_ is now known as horms
09:18 < wsa_> uli___: so, I'd think no DMA for SCIF2 as of nwo
09:18 < wsa_> now
09:18 < geertu> Note: With "exist" I mean "documented"
09:19 < geertu> We have it enabled, and it works?
09:19 < geertu> on H3
09:19 < geertu> not yet on M3-W (but I have it enabled in my local tree since the beginning)
09:20 < uli___> it's enabled on d3 as well, iirc
09:20 < geertu> Yep, D3 too
09:20 < wsa_> I currently get a number of requests from Renesas to make the drivers work like the documentation says
09:20 < wsa_> although they work as is
09:21 < wsa_> and having witnessed some safety workshops recently I know there are people taking care of using only documented things :)
09:22 < wsa_> we can ask why this is not documented
09:22 < horms> So the idea is to implement the driver as per the documentation. Does this usually not change the observed behaviour of the driver?
09:22 < wsa_> it sometimes does
09:23 < wsa_> I will have this discussion with the BSP team about the patch breaking REP_START on I2C
09:23 < wsa_> It will be interesting
09:23 < wsa_> I assume there can be exceptions to the rule
09:24 < wsa_> but not mentioning DMA channels is trivial, or?
09:25 < wsa_> or even better:
09:25 < wsa_> ask the HW team if we can use it in upstream kernels
09:26 < wsa_> and if so, add a comment where we got this add. information
09:27 < wsa_> uli___: can you do that?
09:27 < geertu> I think it was documented as the irda DMA channel in early datasheets
09:27 < uli___> so we leave the dmas in, but document that they are undocumented?
09:27 < wsa_> we ask the HW team if we can use these DMA channels in upstream which "work for us"
09:28 < uli___> ah, ok
09:28 < wsa_> although undocumented
09:28 < wsa_> and let's see what they say
09:28 < uli___> yes, i can do that
09:28 < wsa_> thx
09:29 < wsa_> short about SDHI
09:30 < wsa_> horms: about the core changes, I was hoping for Ulf to comment
09:30 < wsa_> I can have another look but I am not sure I can add much
09:30 < wsa_> I'd like to know Ulf's opinion because he knows way more MMC hardware
09:30 < horms> Ok, maybe I can ping him
09:31 < horms> I understand he wants us to use hooks
09:31 < wsa_> yes, please try
09:31 < horms> But as you can see from the patch I found the existing hooks inadequate
09:31 < horms> And then found myself guessing how he would like new hooks to look
09:31 < horms> Ok, will do
09:32 < wsa_> in general, what neg said is true for SDHI in general: it is a bit lagging; for me, too, since I did majorly I2C the last period
09:32 < horms> I think we can upstream M3-N (non HS400) SDHI support sooner than later, do you agree?
09:32 < wsa_> horms: certainly
09:33 < wsa_> so maybe we all can give it some more love in the next period (me included)
09:34 < horms> agreed
09:34 < wsa_> so, one more little wish: if you are on holidays, please mark it in the B) section of your report
09:34 < horms> by next period do you mean between now and the next meeting?
09:34 < wsa_> then i know better where to find it
09:34 < wsa_> horms: yes
09:35 < wsa_> for now ;)
09:35 < wsa_> it will need more love in general
09:35 < wsa_> this was it from my side, any topics from your side?
09:36 < wsa_> nope
09:36 < wsa_> geertu: then, I'll hand over to you
09:36 < wsa_> Thanks for this meeting!
09:37 < geertu> wsa_: Thanks!
09:37 < wsa_> enjoy the rest of the day