summaryrefslogtreecommitdiff
path: root/wiki/Chat_log/20210218-mm-chatlog
blob: 5dd1e46142e661e5bb35224efbc85671a4b0b36f (plain)
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
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
< pinchartl> welcome to the multimedia group chat meeting
< pinchartl> Topic 1. Status Check for the Multimedia Tasks	        [18:03]
< pinchartl> * Geert
<pinchartl> Since last meeting:
<pinchartl> - Alternative version to support ov7725 sensors on
	    r8a7742-iwg21d-q7-dbcm
<pinchartl> No feedback from Prabhakar
<pinchartl> Until next meeting: None
<pinchartl> Issues and blockers: None
<pinchartl> geertu: any comment ?
<geertu> pinchartl: no comments					        [18:04]
<geertu> will ping Prabhakar
<pinchartl> I haven't followed, why was an alternative version needed ? is
	    there anything we need to discuss ?
<geertu> pinchartl: The original patch was not very flexible. The user can mix
	 and match cameras on all 4 interfaces, so I wanted to support that.
								        [18:05]
<pinchartl> ok
<pinchartl> thanks
<pinchartl> * Jacopo
<pinchartl> Since last meeting:
<pinchartl> - RDACM21 support merged (in v5.12 ;D ) with a bit of pushing [1]
<pinchartl> - Eagle GMSL DT integration sent
<pinchartl> - GMSL reliability testing
<pinchartl> Run hundreds of boot cycles test to assest GMSL initialization
	    reliability abusing Kieran's remote lab :)
<pinchartl> [PATCH 00/16] media: i2c: GMSL reliability improvements
<pinchartl> Until next meeting:
<pinchartl> - Investigate Mauro's request to make max9271 an i2c driver
<pinchartl> - periject BSP ticket patch sweep
<pinchartl> - Investigate IMR patches in the new ticket
<pinchartl> Issues and blockers: None
<pinchartl> jmondi: any comment ?
<jmondi> not really, we can discuss mauro's request
<pinchartl> I'll add it to discussion points			        [18:06]
<pinchartl> thanks
<jmondi> and I will have questions for japeri about IMR, but that's better
	 handled by email
<pinchartl> * Kieran
<pinchartl> Since last meeting:
<pinchartl> - Identified CMA memory leak introduced in v5.11-rcX
<pinchartl> Issue bisected, reported, and fix tested.
<pinchartl> - GMSL testing and review
<pinchartl> - V3U received, and set up - and running on BristolBoardFarm
<pinchartl> Access already provided to Geert and Jacopo. Others can be set up,
<pinchartl> please ask.
<pinchartl> - Initial testing on V3U
<pinchartl> - Looked into GMSL2 and cabling requirements for V3U
<pinchartl> Until next meeting:
<pinchartl> - Further testing and completion of the V3U VSP/DU integration
<pinchartl> Issues and blockers: None
<pinchartl> kbingham: any comment ?
<kbingham> That will do ;-)
<pinchartl> thanks
<pinchartl> * Laurent
<pinchartl> Since last meeting:
<pinchartl> - Improved V4L2 async notifier API
<pinchartl> - Resumed V4L2 multiplexed streams development
<pinchartl> - GMSL2 planning discussions			        [18:07]
<pinchartl> - Found distributor for GMSL2 quad HFM cables
<pinchartl> - Shipped V3U board to Kieran
<pinchartl> Morimoto-san isn't our only paperwork person anymore.
<pinchartl> Until next meeting:
<pinchartl> - Follow up on 3D LUT API proposal for DRM/KMS
<pinchartl> - Periject triage for display
<pinchartl> - GMSL2 planning
<pinchartl> Issues and blockers: None
<pinchartl> any question ?
<moriperi> Nice paperwork :)
<kbingham> You mean you are also the paperwork guy?
<kbingham> I had to pay VAT on the import but no duties and customs, so I
	   think your paperwork was successful ;-)
<pinchartl> * Morimoto-san					        [18:09]
<pinchartl> Since last meeting:
<pinchartl> - Posting ALSA SoC cleanup patches
<pinchartl> It is almost in the final stage, finally.
<pinchartl> - Brush up new sound card driver
<pinchartl> - Request new sound test command to Ulrich		        [18:10]
<pinchartl> Ulrich has previously created a sound test, but it stopped working
	    at
<pinchartl> some point. A new test has been requested (which may be a simpler
	    tool).
<pinchartl> Until next meeting:
<pinchartl> - Port ALSA cleanup patches
<pinchartl> - Brush up new sound card driver
<pinchartl> Issues and Blockers: None
<pinchartl> moriperi: any comment ?
<moriperi> nothing, thanks
<pinchartl> thank you
<pinchartl> * Niklas
<pinchartl> Since last meeting:
<pinchartl> [PATCH v2 0/4] rcar-csi2: Update handling of transfer error
<pinchartl> Until next meeting:
<pinchartl> - Sort out pending patches and triage periject
<pinchartl> - Start VIN, CSI-2 and ISP capture prototype for V3U
<pinchartl> Issues and blockers: None
<pinchartl> neg: any comment ?
<neg> I have no comments at this time :-)
<pinchartl> thanks :-)						        [18:11]
<pinchartl> * Ulrich
<pinchartl> Since last meeting: None
<pinchartl> Until next meeting:
<pinchartl> - atest improvements
<pinchartl> Add support for more than 2 channels and sample sizes != 16 bits.
<pinchartl> Issues and blockers: None
<pinchartl> uli__: any comment ?
<uli__> moriperi: is the dependency on libsndfile a problem for your use case?
<uli__> if so, i can add it to the repo and statically link it, or use
	something else altogether				        [18:12]
<uli__> i'd just like to know before i continue
<pinchartl> I've captured that in the notes, let's move on until Morimoto-san
	    finds his keyboard again :-)			        [18:14]
<pinchartl> Topic 2. Discussions
<pinchartl> - GMSL2 cables
<moriperi> uli__: I'm not sure which one is related to the previous atest
<pinchartl> we now have a relatively cheap option for GMSL2 cable
<pinchartl> damm: we need an answer from you on this topic
<uli__> moriperi: the new atest uses libsndfile to read/write files
<moriperi> I'm using buildroot mainly. It is useful for me if new one works on
	   it.							        [18:15]
<uli__> should be ok then. i'll check, though.			        [18:16]
<uli__> thanks
<moriperi> thanks
<pinchartl> and while waiting for Magnus to get the keyboard back from
	    Morimoto-san,
<pinchartl> - I2C driver for MAX9271
<pinchartl> jmondi: feel free to speak
<damm> hi guys, so for the cables, can you tell us the estimated total cost
       here?							        [18:17]
<damm> that way mori/shimo can give ack/nack			        [18:18]
<jmondi> pinchartl: I'll let the cable discussion end first :)
<kbingham> ~$200 per board plus shipping, ?
<pinchartl> damm:
	    https://www.avnet.com/shop/us/products/avnet-engineering-services/l02-027-1000-z-zzzz-v2-3074457345635644755/
<damm> sorry i dont recall the total number of boards
<kbingham> 1 here, and don't you have one damm ?
<pinchartl> $69 / cable + shipping				        [18:19]
<pinchartl> up to 3 cables per V3U
<damm> yeah and some board is in transit
<damm> so 3 boards and 3 cables - a total of 10 would suffice?
<pinchartl> it should, yes					        [18:20]
<damm> so shall we make two orders of 6 cables to have a bit of failover?
<damm> or four orders of 3 cables
<kbingham> it probably makes sense to get cables ordered directly to where
	   they are needed.
<pinchartl> it would likely be cheaper for each board owner to buy their own
	    cables
<damm> or one order of 12 =)
<pinchartl> otherwise we'll have to ship them ourselves, and that's usually
	    more expensive
<damm> ok lets decide that
<pinchartl> so green light for Kieran to order 3 cables ?	        [18:21]
<damm> from my side for sure
<pinchartl> and invoicing it to Jinzai ? :-)
<damm> i'll make sure to order cables for the other ones
<damm> good question =)						        [18:22]
<damm> do we have any multimedia member that has a contract with opensource
       ab?
<neg> We do :-)							        [18:23]
<damm> if so the cost can just be added to the invoice
<neg> Silly question, do the RDACM2{0,1} modules fit the new cables ?
<pinchartl> neg: yes they do
<damm> is it possible for neg and pinchartl to figure out the money situation
       if neg sends an invoice?					        [18:24]
<neg> Sure we figure it
<pinchartl> so is the recommendation for Niklas to order the cables with
	    Kieran's address as the destination ?
<damm> interesting
<pinchartl> that minimzes paperwork
<damm> i'd like to route them through a french speaking country to reduce
       potential complexity					        [18:25]
<damm> just kidding
<pinchartl> can't help with that I'm afraid, Finland is still not French
	    speaking despite my efforts
<neg> I was hoping to hand carry them thru the Caribbeans
<jmondi> I can throw the italian postal service in the mix if you want to
	 reduce the potential shipment complexity
<damm> i think niklas can decide to ship them wherever he wants	        [18:26]
<neg> Guess I can pick the French side of St Marten
<damm> just give a receipt with the invoice
<neg> damm: Will do
<damm> that should solve the cable situation for EU side?
<damm> thanks
<pinchartl> yep
<damm> neg: let me know what you end up ordering		        [18:27]
<pinchartl> jmondi: back to MAX9271
<neg> damm: Sure, aim is to get 3 cables directly shipped to kbingham
<jmondi> sure							        [18:28]
<jmondi> well, you know the issue
<jmondi> (apart from me breaking -next two times :)
<kbingham> only twice ?
<jmondi> in a row!
<pinchartl> anything to discuss ? or will you just investigate first ?
<jmondi> quick recap: Mauro wants the max9271 to be made a full i2c driver
								        [18:29]
<jmondi> with the camera modules instantiating a new i2c device for that, and
	 communication with the serializer implemented used a regular kAPI
<jmondi> instead of function calls
<jmondi> I don't see any real gain if not pleasing him, but I understand the
	 current design is 'unusual'				        [18:30]
<jmondi> ack to investigate on that side ?
<pinchartl> I think it would make sense to have such a design for cameras that
	    are saner (no MCU). investigating what could be done in that case
	    is a good idea					        [18:31]
<pinchartl> then the investigation could be pushed to see if we could also
	    address the rdacm20 and rdacm21
<pinchartl> or if we need to keep the current architecture for those
<pinchartl> does it make sense ?
<jmondi> the part that worries me is the reprogramming of the i2c address more
	 than the MCU						        [18:32]
<pinchartl> the goal of the investigation is to figure out if there are
	    blockers :-)					        [18:33]
<jmondi> and the fact that to configure the gmsl specific paramters the
	 current v4l2-subdev kAPI might not be enough
<jmondi> so yeah, trying to see how it pans out makes sense imho
<pinchartl> the V4L2 subdev API could be extended if needed
<pinchartl> let's investigate to see what would be needed	        [18:34]
<jmondi> yep
<pinchartl> and then we can decide if it's worth the effort
<pinchartl> still on the topic of GMSL
<pinchartl> jmondi: you have reported three issues last time:
<pinchartl> - MAX9271 probe issue (where reprogramming the chip wasn't enough
	    to recover from failures)
<pinchartl> - RDACM20 startup (circular dependency between regulator and GPIO
	    controller)						        [18:35]
<pinchartl> - RDACM20 startup delay (which seemed not to be needed on Eagle)
<pinchartl> have those been investigated and/or solved ?
<jmondi> yes, investigate for sure				        [18:36]
<jmondi> it's in the "GMSL reliability
<jmondi> sorry, "GMSL reliability testing" part
<jmondi> the series I've sent tries to reduce the part of initialization which
	 is run without noise immunit protection activated
<jmondi> and even if not perfect, on a 50 boot cycle tests I had 6 failures
	 iirc							        [18:37]
<pinchartl> that's way too high
<jmondi> it was 20%
<pinchartl> and I'm not sure if noise immunity is really the culprit here
<pinchartl> are you in an environment so noisy that the camera would fail in
	    12% of the tests ? :-)				        [18:38]
<jmondi> ask Kieran, board is in his lab :)
<jmondi> remember powering goes through the same cables that transport data
<geertu> jmondi: Does the driver notice the failure? Can it retry? Does it
	 succeed on retry?					        [18:39]
<pinchartl> yes, and that's by design
<pinchartl> it's supposed to work
<geertu> It's coax, so it should be fairly immune to noise
<pinchartl> geertu: it's the first issue I've listed, retrying doesn't work
<pinchartl> or didn't work at least
<jmondi> geertu: the driver notices the failure, but the error seems to be
	 unrecoverable
<pinchartl> jmondi: are the three issues still affecting us then ?
<jmondi> I've never been able to recover a failure on identifying max9271
								        [18:40]
<jmondi> also, the time between power-on and power-off seems to play a role
<jmondi> pinchartl: failure in identifying max9271 are still not recoverable,
	 but I haven't seen any with the new design
<jmondi> the circular dependency on regulator and GPIO controller has been
	 solved with a gpio hog as it was done in Kieran's early integration
								        [18:41]
<pinchartl> didn't you say you saw 6 failures in 50 boots ?
<jmondi> the startup delay on Salvator-x is not needed
<kbingham> I love that the startup delay is no longer needed.
<kbingham> (Though very curious how we'll handle that in the full 8 camera
	   case)						        [18:42]
<jmondi> pinchartl: yes, but there might be different failures :) max9271
	 identification, image sensor programming, ISP id reading
<jmondi> currently I got most failures on a single camera, always the same
	 one, so it might as well be HW related
<pinchartl> the startup delay seems *very* fishy. we know there's an MCU that
	    issues I2C transactions. if we open the I2C link over GMSL before
	    the MCU is done, how can this work ?
<jmondi> I tried also reading the MCU content and tried to estimante the delay
	 it takes to startup, which is not documented		        [18:43]
<neg> IIRC the delay was also needed as the boot sequence for H3 ES1.0 setup
      was that the daughterboard should be powerd on after the main board
<jmondi> for 1.5 seconds I cannot access the MCU, but that might be due to the
	 i2c traffic it generates				        [18:44]
<jmondi> I don't know how an 8 seconds delay was estimated in first place
<pinchartl> jmondi: does this mean the delay can be reduced to 1.5s instead of
	    8s, but is still needed ?				        [18:45]
<jmondi> no, I removed delay ocmpletely				        [18:46]
<jmondi> completely
<pinchartl> how is it supposed to work if you start programming the MAX9271
	    while the MCU is also programming it ?
<jmondi> the MCU sends 3 messages to the serializer at startup	        [18:47]
<pinchartl> how do you ensure it doesn't race with the driver programming the
	    MAX9271 ?
<jmondi> the camera gets powered by a gpio hog as soon as the gpio controller
	 is registered						        [18:48]
<jmondi> which happens before we get to open channels one by one
<pinchartl> that sounds like a hack
<jmondi> there's no synchronization, but it doesn't seem worse than an
	 arbitrary delay
<jmondi> rdamc20 is very stable
<jmondi> rdacm21 is less stable
<pinchartl> we'll need to handle power management of cameras	        [18:49]
<pinchartl> keeping them powered on all the time isn't an option
<pinchartl> with a gpio hog we can't control them at runtime
<jmondi> that goes back to the fact we can't control the GPIO that powers the
	 camera with a regulator
<jmondi> due to the circular dependncy
<pinchartl> it's an issue on this platform, yes			        [18:50]
<pinchartl> but there are other GMSL boards where the power to the camera is
	    controlled by a regulator that is actually controllable :-)
<pinchartl> and on some systems, the power to each camera is controllable
	    individually
<jmondi> I think Salvator-X is one of them			        [18:51]
<jmondi> not on out platforms, but I guess it's possible
<pinchartl> not something we have to support right now, but we need to make
	    sure we don't go in a direction that will prevent this from being
	    implemented
<jmondi> ok, I don't think there's anything preventing it from happening
								        [18:53]
<pinchartl> ok
<pinchartl> anything else to discuss ?				        [18:54]
<neg> Not from me
<jmondi> not here
<pinchartl> let's adjourn the meeting then			        [18:55]
<pinchartl> thank you everybody for attending
<pinchartl> have a nice day
<jmondi> thanks
<shimoday> thanks
<neg> Thanks all, have nice day/evening
<shimoday> have a nice day. bye!