09:02 < wsa> welcome everyone to the IO meeting! 09:03 < wsa> 1st topic is the missing status updates ;) I didn't get either Geert's reminder nor any update. Is this because of the mailing list switch? 09:03 < wsa> Did you guys get it? 09:04 < neg> Yes 09:04 < marex-cloud> Yes 09:04 < morimoto> Yes 09:04 < geertu> yes 09:04 < uli_> yes 09:04 < wsa> Ha 09:04 < morimoto> Subject: [periperi] 2019-10-10 - Group meeting - Infos & Call for updates 09:04 < morimoto> 09:04 < morimoto> Date: Wed, 9 Oct 2019 10:36:30 +0200 09:04 < morimoto> 09:05 < wsa> Interesting, I only got the one from Shimoda-san because I was on CC there 09:05 < wsa> morimoto: can you check if I am subscribed to the new ML? 09:05 < wsa> It came all via the new ML? 09:06 < geertu> wsa: You also haven't received "[periperi] This is a test email of a new "periperi" mailing list 09:06 < geertu> " from Shimoda-san, I guess? 09:07 < neg> wsa: I have bounced the status update thread to you 09:07 < wsa> geertu: nope :( 09:07 < geertu> Oops 09:07 < geertu> wsa: Nor Kieran's announcement... 09:08 < morimoto> wsa: Now I'm checking ML, indeed you are not listed 09:08 < wsa> darn, seems i missed some stuff 09:08 < morimoto> Which email address you want to register ? 09:08 < morimoto> OK :) 09:09 < wsa> wsa@the-dreams.de 09:09 < wsa> wsa+renesas@sang-engineering.com 09:10 < wsa> neg: thanks for bouncing the mails 09:10 * Marex is here 09:10 < Marex> good morning 09:10 < wsa> May I suggest to switch to the core meeting now, so I have some time to read the status updates? 09:11 < geertu> Fine for me. I guess everyone is here, except for dammsan? ... 09:47 < wsa> IO meetings part 2 09:47 < wsa> I have read the status updates but not combined them into one report yet 09:48 < wsa> BTW here is mine (can't send mails to ML yet): 09:48 < wsa> A) 09:48 < wsa> * refactoring my I2C API patches because of a missing error condition 09:48 < wsa> * went to Kernel recipes and gave a talk about kernel workflow scalability issues 09:48 < wsa> * also talked with Vladimir about I2C multiple times 09:48 < wsa> * picked up again prototype for a minimal SDHI clock to keep SCC active 09:48 < wsa> * reviewed and/or tested SDHI, MMCIF, RIIC & I2C patches 09:48 < wsa> * sent out a marriage request which got accepted 09:48 < wsa> B) 09:48 < wsa> * send out the I2C API conversion patches 09:48 < wsa> * finish SCC clock handling for SDHI 09:48 < wsa> * visit ELCE and give a talk 09:48 < wsa> * update SDHI manual calibration once we get more infos from HW team 09:48 < wsa> * plan a huge party next year 09:48 < wsa> C) 09:48 < wsa> * error condition for minimal SDHI clock is hard to trigger 09:48 < wsa> Marex: thank you for all the PCI work! and congrats for being the new maintiner ;) 09:49 < jmondi> wsa: could you tell us a bit of what you discussed with Vladimir 09:49 < wsa> uli_: i think increasing the buffer size by 30% percent pays off if it saves us all the refactoring complexity 09:49 < jmondi> (and which party are you organizing :) 09:50 < wsa> uli_: have you checked with davem if this is acceptable to him? 09:50 < wsa> jmondi: there is a hint in A) which party it could be ;) 09:50 < uli_> wsa: not yet. i want to send a prototype for local review before engaging in more public discussion 09:50 < wsa> uli_: OK 09:51 < jmondi> wsa: oh man! I missed that! that's big news! 09:51 < geertu> wsa: Congrats! 09:51 < jmondi> congratualtions! 09:51 < neg> wsa: congratulations on your accepted requests ;-) 09:52 < wsa> jmondi: I kinda convinced him about a few things like I am okay with having two ways to address the same client (like 0x50@bus 5 and alias 0x12@ bus 1) 09:52 < pinchartl> wsa: I'm sorry, but are you sure you got it right ? I'm pretty sure I haven't received any request :-) 09:52 < geertu> neg: wsa wrote "request", i.e. singular 09:53 < wsa> Thanks everyone! :D 09:53 < wsa> geertu: Actually, we made multiple requests to each other :) (but always the same girl and me ;)) 09:54 < Marex> wsa: uhhhh ... yeah 09:54 < pinchartl> wsa: did you send it as a git pull request ? :-) 09:54 < wsa> pinchartl: Never been more sure. Sorry ;) 09:55 < jmondi> broadcast marriage request.. seems like a strategy that could work 09:55 < wsa> uuuh, I see quite some merge conflicts there 09:56 < geertu> jmondi: RMS didn't go that far... 09:56 < wsa> (trust someone with experiences in open relationships ;)) 09:57 < jmondi> wsa: that's the kind of merge conflicts that seems hard to solve :) 09:57 < jmondi> surely they need the --patience switch 09:57 < wsa> jmondi: but you surely learn something on the way 09:57 < jmondi> I would not use 'octopus' as merge strategy 09:57 < wsa> RTOFL 09:57 < jmondi> geertu: you're mean 09:57 < jmondi> :) 09:59 < morimoto> \me I finally could understand about party 09:59 < morimoto> wsa: congratulations !! 09:59 < wsa> Thank you everyone for your congratulations! :) 10:00 < wsa> let me just finish my summary about my talks with Vladimir and then I think the IO meeting is done 10:01 < wsa> So, Vladimir wanted me to review his patches as-is. I told him that I don't think they are a good representation of the actual HW. 10:01 < Marex> wsa: congratulations! 10:01 < Marex> wsa: I had some "fun" with FPDlink this week too 10:01 < Marex> wsa: I studied the datasheets quite thoroughly, there's a LOT of weird junk 10:01 < Marex> wsa: and yes, it can do multi-master on _both_ ends of the link 10:02 < wsa> I told him that we worked out in Lisbon that the key difference between GMSL and FPD (when it comes to the I2C core) is when they need the dynamically assigned address 10:02 < wsa> probe-time vs. device creation time 10:03 < wsa> I first want to think about this. To understand what could be generic and what should be specific 10:03 < jmondi> did you get why he -really- does not want to create adapters for the remote devices ? 10:03 < wsa> And then, we can talk about implementations. 10:04 < Marex> wsa: FYI, one funny observation which might be useful for you 10:04 < wsa> He wants to hardcode everything because it is most simple 10:04 < Marex> wsa: the FPDlink de-serializer has actual PHYSICAL I2C master in it 10:05 < Marex> wsa: so, when you talk to the serializer (connected to your CPU), it just listens on the I2C bus and does some marshalling, but on the other side, the deserializer is a kind-of separate I2C bus altogether 10:05 < wsa> jmondi: he wants the deserializer to have 10 addresses and that's it. No locking issues, not much new code needed 10:05 < Marex> it can even run at different clock rate (!) 10:05 < wsa> Marex: thanks 10:05 < Marex> wsa: just dumping the info while it's still hot in cache 10:05 < wsa> Marex: yes, the fact that it can run at a different clock rate was used as an argument that it really should be a seperate bus 10:06 < Marex> wsa: well since it's an actual full I2C master, it probably should ? 10:06 < wsa> Marex: talk to Vladimir about that :) 10:06 < Marex> wsa: is he gonna be at ELCE ? 10:06 < Marex> wsa: CC me on that discussion 10:06 < wsa> i think so 10:07 < jmondi> Marex: you have a serializer connected to your CPU and a remote deserializer ? 10:07 < jmondi> I assume you're working with displays then ? 10:07 < wsa> Marex: will do 10:08 < Marex> jmondi: yes 10:08 < jmondi> that would be interesting to explore, as we're considering the case where the deserializer is the local end 10:08 < jmondi> local = connected to the CPU 10:08 < Marex> jmondi: I have display + i2c touch and a few other remote components 10:09 < jmondi> https://lore.kernel.org/patchwork/cover/1030123/ 10:09 < jmondi> that's the latest proposal from Luca. I think the discussion has some pointers, and in the end there are links to the notes taken during the BoF by Kieran and Luca 10:11 < Marex> jmondi: well, you should consider using it the other way around too :) 10:12 < Marex> wsa: there's another bizzare thing, FPDlink supports hotplug :-D 10:12 < jmondi> Marex: ah yes indeed, I think nobody in that discussion has yet had a use case for this 10:12 < Marex> wsa: you can yank the cable out and you get hotplug event on the controller 10:12 < Marex> jmondi: with display, that might actually make a bit of sense 10:13 < wsa> luca wants hotplug 10:13 < wsa> however, this is probably more a v4l2 thing than I2C 10:13 < wsa> however, no need to respin the whole discussion here 10:14 < wsa> the thread is out there 10:14 < Marex> I want to believe 10:14 < wsa> and there will likely be another one 10:14 < jmondi> x-files music plays in the back of my head now 10:14 < wsa> anything else we need to discuss right now? 10:15 < jmondi> wsa: just to know if you have plans to start looking into i2c address assignment, and if you need support 10:15 < jmondi> but it can be taken offline to the mailing list maybe 10:15 < wsa> jmondi: i got 5 days as an add. task for it \o/ 10:16 < wsa> I will think about the probe-timing vs. device-creation timing 10:16 < wsa> first 10:16 < wsa> I will let you know if I need add. thoughts and/or input 10:16 < jmondi> wsa: good! I think we really need to get a spin for having at least max9286 driver in, and additional work around it might help 10:16 < Marex> wsa: luckily, the FPDlink can also work in full passthrough mode 10:17 < wsa> It is an action item 10:17 < jmondi> wsa: thanks! 10:17 < wsa> yes, sure thing. and thanks for Renesas to fund this add. task! 10:17 < wsa> with that, I think we are done 10:18 < geertu> jmondi: Any plans to fix max9611? 10:18 < wsa> pinchartl: your turn now! 10:18 < pinchartl> thank you