1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
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
|
