1 files changed, 144 insertions, 0 deletions
diff --git a/wiki/Chat_log/20180509-io-chatlog b/wiki/Chat_log/20180509-io-chatlog
new file mode 100644
index 0000000..6752037
--- /dev/null
+++ b/wiki/Chat_log/20180509-io-chatlog
@@ -0,0 +1,144 @@
+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