Merge remote-tracking branch 'gitlab/wiki' into HEAD

1 files changed, 150 insertions, 0 deletions

diff --git a/wiki/Chat_log/20191010-io-chatlog b/wiki/Chat_log/20191010-io-chatlog
new file mode 100644
index 0000000..c785ab3
--- /dev/null
+++ b/wiki/Chat_log/20191010-io-chatlog
@@ -0,0 +1,150 @@
+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