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
|
< pinchartl> welcome to the multimedia meeting
< pinchartl> Topic 1. Status Check for the Multimedia Tasks
<pinchartl> * Geert
<pinchartl> Since last meeting:
<pinchartl> - Investigated an ADV7511 s2ram crash, to discover a DRM EDID bug
<pinchartl> Until next meeting: None
<pinchartl> Issues and blockers: None
<pinchartl> geertu: any comment ?
<geertu> It seems the i2c bus is locked up
<geertu> and on subsequent reset, EDID cannot be read, too [17:06]
<pinchartl> Wolfram mentioned he would investigate on the I2C side
<pinchartl> I have another display bug reported by Morimoto-san to handle
<pinchartl> so I'll happily ignore the adv7511 for now :-) until Wolfram
completes his investigations (or I fix the other bug) [17:07]
<geertu> Yeah, I saw that. Could that be fw_devlink?
<pinchartl> I doubt it [17:08]
<wsa> pinchartl: that will be an interesting race :)
<pinchartl> :-) [17:09]
<pinchartl> * Jacopo
<pinchartl> Since last meeting:
<pinchartl> - V4L2 multiplexed streams support for GMSL - review and
discussion of v4l2-mux support from Tomi - R-Car CSI-2 + GMSL
ported to v4l2-mux
<pinchartl> - R-Car ISP review
<pinchartl> Until next meeting:
<pinchartl> - New version of v4l2-mux with VIN channels properly handled
<pinchartl> Issues and blockers: None
<pinchartl> jmondi: any comment ?
<jmondi> pinchartl: not really, apart from the point I mentioned in C)
<pinchartl> I've added it to the discussion points
<jmondi> thanks
<pinchartl> thank you
<jmondi> let's keep it for later [17:10]
<pinchartl> * Kieran
<pinchartl> Since last meeting:
<pinchartl> - Investigate V3U display timings
<pinchartl> Until next meeting:
<pinchartl> - Investigate V3U display timings
<pinchartl> Peripheral clock confirmed, but still need to dig in and verify
things here.
<pinchartl> Issues and blockers: None
<pinchartl> Kieran is on vacation this week, I don't think he's with us today
<pinchartl> I've been working with him on the V3U display, so I can try to
answer questions if there are any
<pinchartl> * Laurent [17:11]
<pinchartl> Since last meeting:
<pinchartl> - Upstreamed pending patches
<pinchartl> Most notably, sent pull requests for V3U support in DU, and for
non-contiguous buffer import.
<pinchartl> - V4L2 multiplexed streams development
<pinchartl> Continued working with Tomi Valkeinen. Still work in progress (v9
is out). Reviewed Jacopo's MAX9286 multiplexed streams support.
<pinchartl> - Tested HDMI probe issue with v5.15-rc1
<pinchartl> Couldn't reproduce on M3-N Salvator-XS, will test on ULCB next.
<pinchartl> Until next meeting:
<pinchartl> - Debug HDMI probe issue on v5.15-rc1
<pinchartl> - V4L2 multiplexed streams development
<pinchartl> Issues and blockers: None
<pinchartl> any question ?
<moriperi> thank you for checking HDMI issue [17:12]
<pinchartl> you're welcome. now I have to dust my ULCB :-)
<pinchartl> * Morimoto-san
<pinchartl> Since last meeting:
<pinchartl> - Posted ALSA SoC new generic sound card driver
<pinchartl> Maintainer said basically OK, got some feedback about from
non-maintainer, posted v4.
<pinchartl> Until next meeting:
<pinchartl> - Continue ALSA SoC work
<pinchartl> Issues and Blockers:
<pinchartl> - v5.15-rc1 doesn't probe HDMI
<pinchartl> Issue reported to Laurent and to mailing list.
<pinchartl> moriperi: any comment ?
<moriperi> nothing, thanks
*** damm (~damm@167.99.4.198) has quit: Remote host closed the connection
[17:13]
*** damm (~damm@167.99.4.198) has joined channel #periperi
<pinchartl> * Niklas
<pinchartl> Since last meeting:
<pinchartl> - [PATCH] media: rcar-vin: Use user proved buffers when starting
<pinchartl> - [PATCH v3] media: staging: max96712: Add basic support for
MAX96712 GMSL2 deserializer
<pinchartl> - [PATCH v5] media: rcar-isp: Add Renesas R-Car Image Signal
Processor driver
<pinchartl> - [PATCH v2 0/2] rcar-csi2: Serialize format cfg and improve mutex
handling
<pinchartl> - [PATCH v6] media: rcar-isp: Add Renesas R-Car Image Signal
Processor driver
<pinchartl> Until next meeting:
<pinchartl> - Follow up pending patches
<pinchartl> Issues and blockers: None
<pinchartl> neg: any comment ?
<neg> No comment
<pinchartl> thank you [17:14]
<pinchartl> that's it for the MM status update unless I've forgotten someone
<pinchartl> Topic 2. Discussions
<pinchartl> - R-Car VIN channel handling for v4l2-mux [17:15]
<pinchartl> jmondi: what is that about ?
<jmondi> so, I've implemented support for multiplxing and CSI-2 VC routing on
max9286 and R-Car CSI-2
<jmondi> the part I am missing, and from a brief discussion we had I am
probably misunderstanding, is the VIN part [17:16]
<jmondi> as we all know VIN has a CHSEL register with a fixed number of
combinations
<jmondi> it is currently populated inspecting the enabled links between CSI-2
and the VIN instances which are used to build a mask of enabled
routes [17:17]
<jmondi> afaiu this does not take into account which VC is routed to the CSI-2
source pad linked to the VIN instance at hand [17:18]
<jmondi> I can make an example
<neg> From a multiplexed stream PoV just ignore that the CHSEL register exists
;-)
<jmondi> how so ?
<neg> The documentation is missleading and it have nothing to do with VC, it
just configure which parallel bus on the CSI-2 soruce side is routed to
which VIN instance [17:19]
<jmondi> from what I see empirically, it also have an impact on filtering
<jmondi> I can make an example
<neg> VC only exists on the CSI-2 sink pad and inside the CSI-2 driver where a
VC is routed to a physical source pad (aka parallel bus) that faces the
VIN [17:20]
<jmondi> on V3M, have a look at the chsel table (page 2006 of datasheet 2.20)
<jmondi> I am configuring the CSI-2 interface to route VC0 on source pad#1 and
VC1 to source pad #4 [17:21]
<jmondi> this in my understanding corresponds to the first row of the chsel
table
<jmondi> the way the chsel mask building procedure works leads to a chsel mask
of value 0x3 [17:22]
<jmondi> which expects VC3 to be on pad #4, not VC1
<jmondi> in my mind that could be solved by inspecting the CSI-2 frame desc,
and configuring the mask accordingly [17:23]
<jmondi> but I got from the two of you that chsel should not be involved with
routing
<jmondi> unfortunately, if I stick with the computed chsel=0x3 VIN3 output is
blank [17:24]
<jmondi> if I instead use a chsel value of 0x00 I get good images
<neg> The CHSEL value calculation don't care about VC, it only looks at the
media graph links [17:26]
<jmondi> I understand, and that's the culprit of my issues, but I got from our
previous discussions that the mask building procedure should not be
changed [17:27]
<neg> If you first disable all MC links and then enable CSI40.sourcepad0 ->
VIN0 and CSI40.sourcepad4 -> VIN3 and don't get a CHSEL value of 0x00
there is a bug in VIN
<neg> and that of course shall be fixed
<neg> But this bug would then exists today and would not depend on any
multiplexed stream work [17:28]
<jmondi> I don't think it's a bug, I think the current procedure assumes
CSI40.sourcepad4 = VC3
*** wsa (~wsa@p54b33006.dip0.t-ipconnect.de) has quit: Quit: cya! [17:29]
<neg> d00h, yes I got confused that in your multiplexed work you break that
assumtion ;-) [17:32]
<jmondi> and also, inspecting the enabled links is not enough, as in example
to dishern if (in the same example I've given) on CSI40.pad#4 you
have VC1 or embedded data. you should inspect the frame desc
<neg> But this is good news then, I had been mening to try if what you
descirbe here works
<jmondi> (even if I don't get why VC and datatype are mixed there)
<jmondi> I mean, we might assume the [VC, CSI source pad] association is fixed
[17:33]
<neg> Because if it do we could simplify the VIN routing I think, as we could
allow any VIN to be routed to any VC
<jmondi> but it would limit the HW supported features
<jmondi> yeah, well, considering the limited number of possible routes each
SoC supports :) [17:34]
<neg> I'm thinking a hardcoded CHSEL value and immutable links between CSI-2
and VIN. The routing of VC to VIN is controlled by the multiplexed API
inside the CSI-2 [17:35]
<pinchartl> can that be done ? [17:36]
<pinchartl> are the other options than CHSEL to control routing ?
<jmondi> didn't get the question :)
<pinchartl> s/are the/are there/ [17:37]
<neg> If I understood Jacopo this is what he does in his multiplexed stream
series and this is why he see this issue
<jmondi> my understanding is that CHSEL does not control routing but rather
filtering [17:38]
<neg> As he "routes VC1 to source pad #4" he breaks the assumtion we had that
each VC was mapped to a fixed pad VCn -> source pad n
<jmondi> and that surprises me as it means the VIN has the notion of VC/DT
<jmondi> while I always assumed there's just a parallel data bus between VIN
and CSI-2 [17:39]
<pinchartl> how do you control routing within the CSI-2 receiver ?
<jmondi> through which registers you mean ?
<pinchartl> yes
<neg> VCDT and VCDT2
<neg> SEL_VC - These bits specify the virtual channels for channel 0 to
capture. SEL_VC2 - These bits specify the virtual channels for channel 1
to capture. [17:41]
<jmondi> give me a sec I should re-look into my patches
<jmondi> I think Laurent is asking how this is handled according to the
routing API
<pinchartl> that is interesting indeed [17:42]
<pinchartl> especially the mention of the TAG signal
<pinchartl> which would imply that the output of the CSI-2 has a tag for each
sample
<neg> So with a multiplexd stream API we could set what VC to output for which
channel and have a fixed immutable CSI-2 to VIN remving much of the need
for the horrible VIN group design
<pinchartl> I still think the CHSEL routes CSI-2 channels, not CSI-2 VC/DT
<pinchartl> would it be fair to conclude that more tests are needed ? [17:44]
<pinchartl> to check more combinations of parameter
<neg> I think so, but it's an interesting find
<pinchartl> s
<jmondi> I would welcome a shared testing strategy [17:46]
<pinchartl> how so ? by sharing testing, or by discussing the strategy ?
[17:47]
*** damm (~damm@167.99.4.198) has quit: Remote host closed the connection
[17:48]
*** damm (~damm@167.99.4.198) has joined channel #periperi
<neg> I thought about this a while back and wanted to start to test if what
Jacopo now reports even was possibe using VCDT [17:49]
<jmondi> I'm thinking about a shared plan about -what- to test [17:50]
<neg> The next step was my dream of removing the horrid routing limitations
between VIN and CSI-2, back then I thought about using media links, but
if multiplexed streams is on the way maybe S/G_ROUTING would have been
my first experiment as I think it would be simpler [17:51]
<neg> If I where to test this I would force a static CHSEL from VIN, one CSI-2
output channel to each VIN and then see if I can using VCDT route a
single VC to each VIN and if that works move on to use more streams
[17:52]
*** damm (~damm@167.99.4.198) has quit: Ping timeout: 256 seconds [17:53]
<neg> If that works I think we can start to bikeshed about how to best make
use of it. But I think a first step is to make sure it works as a
prototype
<pinchartl> could the two of you coordinate on the test strategy then ?
[17:54]
<jmondi> sure
<jmondi> if there's any interest in me continuing with this activty ofc
<pinchartl> I'm certainly interested :-) [17:55]
<pinchartl> we have an odd hardware setup, and making sure it can be properly
supported with the new API is important
<jmondi> ok then
<jmondi> I think it's mostly about me and niklas agreeing on a time to work
together on this if he has bandwidth [17:56]
<neg> I'm extatic about anything that can reduce the complexity and get rid of
the VIN groups ;-) [17:57]
<jmondi> ok, so let's sync to do some work and discussions on this then
<neg> sounds good
<jmondi> thanks
<pinchartl> :-) [17:58]
<pinchartl> thank you
<pinchartl> any other discussion topic for today ?
<jmondi> no thanks :)
<jmondi> at least not from me ?
<neg> I'm good
<pinchartl> I thus propose adjourning the meeting. does anyone second ?
[17:59]
<neg> +1
<jmondi> +1 thank you all [18:00]
<neg> Thanks all have a great day
<pinchartl> meeting adjourned
<pinchartl> thank you all for attending
<shimoday> thank you all. bye! [18:02]
|
