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
|
<pinchartl> welcome to the multimedia group meeting
<jmondi> pinchartl: hello [17:05]
<pinchartl> Topic 1. Status Check for the Multimedia Tasks
<pinchartl> * Jacopo
<pinchartl> Since last meeting:
<pinchartl> - Linux Plumbers Conference
<pinchartl> - DT bindings image sensor conversion
<pinchartl> Converted mt9v111, imx214, ov5670 and ov772x
<pinchartl> - max9286 format configuration
<pinchartl> To prepare for upstreaming support for RDACM21, the max9286 driver
<pinchartl> has to be adapted to support different receivers.
<pinchartl> [PATCH 0/4] media: i2c: max9286: Use remote endpoint image format
<pinchartl> The series was not exactly apreciated, so a different solution is
<pinchartl> required.
<pinchartl> - Patch review
<pinchartl> Reviewed Prabhakar'd ov772x and ov5640 patches for Renesas G1H dev
<pinchartl> boards.
<pinchartl> Until next meeting:
<pinchartl> - Re-think how to handle formats for max9286
<pinchartl> - Resume GMSL reverse channel configuration discussion
<pinchartl> - Re-send dt-bindings now that we have clarified how to handle
<pinchartl> endpoints
<pinchartl> Issues and blockers: None
<pinchartl> jmondi: you can go first :-) any comment ?
<jmondi> not really, I think I need to re-look at format handlin on max9286
[17:06]
<jmondi> but no comment on the current status update thanks
<pinchartl> ok, thanks
<pinchartl> regarding format handling, would you like to discuss during this
meeting, or do you need to look at it first ? [17:07]
<jmondi> pinchartl: if we have 5 minutes at the end, let's discuss it
<pinchartl> ok, I'll add it to the discussion points
<jmondi> it shouldn't be long after all, I just need to convince you and
Sakari... it's gonna be like 5 minutes, right ? =) [17:08]
<pinchartl> * Kieran
<pinchartl> Since last meeting:
<pinchartl> - Linux Plumbers Conference
<pinchartl> - Patch review
<pinchartl> - GMSL reviews/fixups
<pinchartl> - ADV748x audio input
<pinchartl> Failed to successfully capture anything. Responded to author, not
sure
<pinchartl> if the test procedure is wrong or if the problem lies elsewhere.
<pinchartl> Until next meeting:
<pinchartl> - Aim to finish/resolve the ADV748x audio tests
<pinchartl> - Work towards DT integration/overlays for GMSL
<pinchartl> - Look at V4L2 Multiplex streams topics for GMSL
<pinchartl> Issues and blockers: None
<pinchartl> Kieran asked to be excused as he's stuck babysitting today
<pinchartl> * Laurent
<pinchartl> Since last meeting:
<pinchartl> - Linux Plumbers Conference
<pinchartl> Participated (among other topics) in the dmabuf heaps and
userspace
<pinchartl> buffer allocation library discussions.
<pinchartl> - DISCOM CRC calculation tool
<pinchartl> Implemented a tool to calculate the CRC of an image using the same
<pinchartl> algorithm as the DISCOM, and integrated it in the DU test
suite. This
<pinchartl> exposed a crash in the DU driver, developed and posted a fix.
<pinchartl> - V4L2 async subdev allocation fixes
<pinchartl> Posted fixes for V4L2 async subdev allocation in the various
Renesas
<pinchartl> V4L2 drivers. The fix for VIN has been superseded by patches from
<pinchartl> Niklas. The fix for DRIF is pending testing from the Renesas UK
team. [17:09]
<pinchartl> - Patch review
<pinchartl> Among other things, Renesas UK has provided the schematics for the
iWave
<pinchartl> board, which unblocked review of the DT integration.
<pinchartl> Until next meeting:
<pinchartl> - Follow-up on pending patch series
<pinchartl> Get pending patches merged, pinging maintainers where needed.
<pinchartl> - Help with debugging the DU + CMM suspend/resume crash if needed
<pinchartl> - Move forward with the V4L2 multiplexed streams proposal
<pinchartl> Issues and Blockers: None
<pinchartl> any question ?
<moriperi> Thank you for DISCOM tool
<pinchartl> you're welcome [17:10]
<pinchartl> * Morimoto-san
<pinchartl> Since last meeting:
<pinchartl> - Post Renesas menu Kconfig patch
<pinchartl> v3 may be needed.
<pinchartl> - Continue posting ALSA SoC cleanup patches
<pinchartl> - Complex connection handling in ALSA SoC
<pinchartl> Current ALSA SoC has 2 generic sound card (= glue for SoC / Codec)
<pinchartl> driver, and one of them is for OF-graph. Current ALSA SoC
maintainer is
<pinchartl> recommending to use it. But unfortunately, it can't handle complex
<pinchartl> connection for now. But in these days, at least 2 vendors want to
use
<pinchartl> complex connections by using this generic driver. One of them has
posted
<pinchartl> *hack* patches. Thus I started to think about *non-hack* expansion
for
<pinchartl> it.
<pinchartl> Until next meeting:
<pinchartl> - Create dummy test driver to develop complex connection handling
<pinchartl> - Continue posting ALSA SoC cleanup patches
<pinchartl> Issues and Blockers: None
<pinchartl> moriperi: any comment ?
<moriperi> thanks. no comment, but have question. later this. [17:11]
<pinchartl> ok
<pinchartl> * Niklas
<pinchartl> Since last meeting:
<pinchartl> - [PATCH 0/2] v4l: async: Switch to endpoint node matching
<pinchartl> - [PATCH 0/2] rcar-vin: Fix issues with partial probed media
graphs
<pinchartl> - Summer vacation, back in office Monday the 7th
<pinchartl> Until next meeting:
<pinchartl> - Post second round of improvements for VIN and V4L2 lifetime
issues
<pinchartl> - Backlog cleaning
<pinchartl> Issues and blockers: None
<pinchartl> Niklas asked to be excuse as he's travelling back to Germany
<pinchartl> Topic 2. Discussions
<pinchartl> moriperi: you said you have a question for later. I think later
could be now :-) [17:12]
<moriperi> jacopo first is oK
<pinchartl> ok :-)
<pinchartl> MAX9286 format handlign then
<pinchartl> jmondi: ?
<jmondi> yup [17:13]
<jmondi> well, I think the deser should reflect the remote's format, you and
Sakari think not
<jmondi> I think it boils down to that, right ? :)
<pinchartl> pretty much :-) [17:14]
<pinchartl> the design idea behind MC drivers is that format propagation
should be handled by userspace
<pinchartl> for multiplexed streams, we may do otherwise
<pinchartl> but the GMSL link isn't multiplexed, it carries a single stream
[17:15]
<jmondi> I don't see it being related to multiplexed, but more specifically on
what the de-serializer does
<jmondi> you can say it's not different from any other bridge
$protocol-to-csi2
<pinchartl> correct [17:16]
<jmondi> I see
<pinchartl> and if you look at a parallel to CSI-2 chips, they don't fetch the
remote format on the parallel sink
<pinchartl> userspace propagates the format on the parallel side
<jmondi> and indeed format can be set on the sink pads
<jmondi> so it's maybe better handled by updating the vin-test scripts [17:17]
<jmondi> parsing the remote format and apply it on the deser sink pads
<pinchartl> media-ctl will do it for you [17:18]
<pinchartl> if you set the format on a source pad that has a connected link,
it will automatically set it on the remote sink pad
<jmondi> across links ? [17:19]
<jmondi> I never noticed that :/
<pinchartl> yes, across links
<jmondi> good to know, now I should check why it doesn't happen then
<jmondi> anyway, let's defer to userspace
<pinchartl> ok [17:20]
<jmondi> thanks, moriperi please go ahead then
<pinchartl> another discussion point, DU + CMM suspend/resume crash
<jmondi> ah
<jmondi> I'm at "please rest (for now)" [17:21]
<pinchartl> moriperi: you mentioned in an e-mail that you would check with the
customer whether we need to look into this
<jmondi> any update ?
<pinchartl> do you have any update on that ?
<moriperi> no update if my memroy was correct [17:22]
<pinchartl> should we still wait ? I'd like to raise the issue with the PM
core developers, as I think the problem would be fixed if they
didn't forcefully PM-runtime-resume devices needlessly at system
suspend
<geertu> The person from Renesas EU who contacted me regards this issue, had
told me he pinged Eugeniu. [17:24]
<geertu> But so far no response from Eugeniu, AFAIK
<pinchartl> I propose initiating the PM discussion, as these matters may take
time
<moriperi> I don't remember detail, but DU also has bind/unbind issue ?
[17:25]
<pinchartl> is that a separate issue ?
<moriperi> oops ? please ignore, my fault maybe [17:26]
<pinchartl> it could just be me misremembering it :-)
<pinchartl> jmondi: does it ring a bell ? [17:27]
<jmondi> bind/unbind not really :( [17:28]
<moriperi> So is it my turn ?
<pinchartl> yes :-)
<jmondi> moriperi: please go ahead!
<moriperi> Thanks
<moriperi> About OF-graph
<moriperi> I know we can use "ports" for "port" groups
<moriperi> ports - port - endpoint
<moriperi> port - endpoint
<moriperi> ...
<moriperi> But now, I want to have sub-groups, like this
<moriperi> ports - port - endpoint
<moriperi> - port - endpoint
<moriperi>
<moriperi> - ports - port - endpoint <= [17:29]
<moriperi> - port - endpoint <=
<moriperi> I think OF-graph doesn't support it, right ?
<pinchartl> correct
<moriperi> Do you know someone who has same issue/idea ?
<pinchartl> not really, no
<pinchartl> what do you want to use that for ?
<moriperi> now I nama it as port3, port4.
<moriperi> s/nama/name [17:30]
<moriperi> port3, and port4 are separate device, but want to use in the same
time as same interface
<moriperi> thus we want to group [17:31]
<pinchartl> I don't know of anyone who would have tried to do that
<pinchartl> maybe the best option would be to post an RFC to explain the
problem and the proposed solution ?
<pinchartl> it would be helpful if it explained the hardware architecture and
gave a corresponding DT example [17:32]
<moriperi> Yes maybe. Or I already have other idea. but in that, the graph
will be very huge :(
<moriperi> but it is ok for now, not a big-deal. thanks [17:33]
<moriperi> pinchartl: ahhh, about bind/unbind, it was for VIN, not for DU
[17:34]
<pinchartl> you're welcome. I'd be happy to help if I can, please just let me
know :-)
<moriperi> sorry for my noise
<pinchartl> yes, for VIN we clearly had issues
<pinchartl> no worries
<pinchartl> any other discussion point for today ?
<moriperi> not from me [17:35]
<jmondi> pinchartl: one last thing
<jmondi> i2c sensor yaml :) (I know..)
<wsa> next meeting on October, 1st?
<jmondi> we decided to defer to of-graph.yaml ports/endpoint/remote-endpoint
<jmondi> but what if I have endpoint properties to document ?
<pinchartl> in that case you should have the endpoints in your bindings
[17:36]
<pinchartl> it's only for the case where nothing else needs to be documented
that you can drop them
<pinchartl> basically, of-graph.yaml will take care of the schema for
ports/port/endpoint/remote-endpoint [17:37]
<pinchartl> so it doesn't have to be duplicated everywhere
<pinchartl> but the rest needs to be handled manually
<pinchartl> any question still about this ? [17:39]
<jmondi> on
<jmondi> no
<jmondi> just wanted to make sure so next iteration is ok
<jmondi> thanks for the answer
<pinchartl> you're welcome [17:41]
<pinchartl> any other discussion topic ?
<wsa> next meeting on October, 1st?
<pinchartl> :-)
<pinchartl> works for me
<geertu> #metoo [17:42]
<shimoda> works for me
<pinchartl> I propose adjourning the multimedia meeting
<pinchartl> does anyone second ?
<wsa> good, then it is decided [17:43]
<geertu> third?
<jmondi> seconded! [17:44]
<pinchartl> meeting adjourned. thank you all for attending [17:45]
<pinchartl> have a nice day
<jmondi> thank you all
<damm> thanks guys [17:46]
<shimoda> thanks! [17:47]
|
