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
|
< pinchartl> welcome to the multimedia meeting
< pinchartl> Topic 1. Status Check for the Multimedia Tasks
< pinchartl> * Jacopo
<pinchartl> Since last meeting:
<pinchartl> - GMSL reliability (v5)
<pinchartl> - MAX9286 integration on Eagle (v3)
<pinchartl> Until next meeting:
<pinchartl> - Complete RDACM20 stress tests after having validated RDACM21
<pinchartl> - max9271 to be turned into an I2C driver
<pinchartl> Issues and blockers: None
<pinchartl> jmondi: any comment ?
<jmondi> not really [16:48]
<pinchartl> thank you
<pinchartl> * Kieran
<pinchartl> Since last meeting:
<pinchartl> - GMSL review and support
<pinchartl> - GP LED support integrated for V3U
<pinchartl> - V3U FCPVD and VSPD support posted.
<pinchartl> - Rebased and pushing the DU group rework
<pinchartl> Until next meeting:
<jmondi> maybe geertu can explain me what he meant with 'gpio-hog' style
<pinchartl> - Further development on VSPD/DU for V3U
<jmondi> but later
<pinchartl> Issues and blockers: None [16:49]
<pinchartl> kbingham: any comment ?
<kbingham> No
<pinchartl> thank you
<pinchartl> * Laurent
<pinchartl> Since last meeting:
<pinchartl> - V4L2 multiplexed streams development
<pinchartl> - Periject triage for display (complete)
<pinchartl> - Upported and submitted DU driver fixes
<pinchartl> - SN65DSI86 upporting
<pinchartl> Upporting complete, with RFC patch series sent. The code can't be
tested yet, as VSP, DU and DSI are needed. Upstreaming is thus on
hold.
<pinchartl> - DSI driver upporting
<pinchartl> Work in progress.
<pinchartl> Until next meeting:
<pinchartl> - V4L2 multiplexed streams development
<pinchartl> Patches should be posted within the next month.
<pinchartl> - DSI driver upporting
<pinchartl> - DU driver upporting
<pinchartl> This will enable testing of the whole display chain, once VSP is
ready.
<pinchartl> - Display drivers upstreaming
<pinchartl> Tentative, if testing (and bug fixing) can be completed on time.
<pinchartl> Issues and blockers: None
<pinchartl> any question ?
<pinchartl> * Morimoto-san [16:50]
<pinchartl> Since last meeting:
<pinchartl> - ALSA Framework cleanup is finally done !
<pinchartl> - Started to post new generic sound card driver
<pinchartl> - Creating sound autotest environment by using Ulrich's atest
<pinchartl> It's not the best match to the test environment, asked Ulrich to
add new features.
<pinchartl> Until next meeting:
<pinchartl> - Continue to posting patch ot ALSA
<pinchartl> - Update Sound autotest environment by using Ulrich's atest
<pinchartl> Issues and Blockers:
<pinchartl> - Ulrich's atest sometimes fails, the reason is unknown
<pinchartl> morimoto: any comment ?
<morimoto> I want to talk to Ulrich about atest
<morimoto> about others, no comment. thanks
<uli__> yes?
<morimoto> On Email, OK ? [16:51]
<uli__> sure
<morimoto> Thanks a lot
<pinchartl> thank you
<pinchartl> * Niklas
<pinchartl> Since last meeting:
<pinchartl> - [PATCH] rcar-csi2: Add support for Y10 and Y8
<pinchartl> - [PATCH] media: dt-bindings: media: renesas,csi2: Node port@0 is
not mandatory
<pinchartl> - [PATCH] arm64: dts: renesas: aistarvision-mipi-adapter-2.1:
Explicitly state csi40 port
<pinchartl> - [PATCH] media: staging: max96712: Add basic support for MAX96712
GMSL2 deserializer
<pinchartl> - [PATCH] media: dt-bindings: media: renesas,csi2: Add r8a779a0
support
<pinchartl> - [PATCH] rcar-csi2: Add r8a779a0 support [16:52]
<pinchartl> - [PATCH] media: dt-bindings: media: renesas,isp: Add bindings for
ISP Channel Selector
<pinchartl> - [PATCH] media: rcar-isp: Add Renesas R-Car Image Signal
Processor driver
<pinchartl> - [PATCH] media: dt-bindings: media: renesas,vin: Add r8a779a0
support
<pinchartl> - [PATCH 00/11] rcar-vin: Add r8a779a0 support
<pinchartl> - [PATCH] arm64: dts: renesas: falcon-csi-dsi: Add GPIO extenders
<pinchartl> - [PATCH 0/2] arm64: dts: renesas: falcon: Wire up MAX96712
<pinchartl> - Video capture on V3U work in Japan lab
<pinchartl> This uses the MAX96712 and R-Car ISP drivers.
<pinchartl> media graph: https://www.ragnatech.se/~neg/v3u/mc-graph.png
patterns captured:
https://www.ragnatech.se/~neg/v3u/checkerboard.png
https://www.ragnatech.se/~neg/v3u/gradient.png
<pinchartl> Until next meeting:
<pinchartl> - Follow up pending patches
<pinchartl> - Finish a set of cleanup patches found while working on V3U
<pinchartl> Issues and blockers:
<pinchartl> - Need GMSL2 cameras (ideally locally, worst case remotely)
<pinchartl> neg: any comment ?
<pinchartl> I have a few questions. the test patterns are generated by the
MAX96712, right ?
<neg> yes
<neg> the patterns are generated by the MAX96712, no I don't have any comments
;-) [16:53]
<pinchartl> :-)
<kbingham> neg, I have GMSL1 (RDACM21) cameras attached to the v3u here. But
RDACM21 != GMSL2.
<pinchartl> I suppose that's running the BSP code ?
<neg> nope
<neg> I wrote a new driver
<pinchartl> ah, nice
<pinchartl> with the ISP in bypass mode ? [16:54]
<neg> No the ISP is used for channel selection
<pinchartl> I mean the ISP core
<neg> Ahh yes [16:55]
<pinchartl> now that you've had a chance to play with this, does the datasheet
provide all the information we need, or at there missing parts, or
parts that are unclear ? [16:56]
<neg> For MAX96712 i think we have all we need if we want to take it
further. For the ISP I think my knowledge about real world ISP is the
limiting factor to awnser that [16:57]
<pinchartl> we know we don't have information about the ISP core
<neg> My current plan is to extend the ISP channel selection to allow routing
VC/DT freely, but I will not do that before we have a multiplexed stream
poc
<pinchartl> ok [16:58]
<neg> and for that I think we have enough information, anything more advanced
that that I have not really checked or thought about
<pinchartl> but you haven't noticed clearly missing information when it comes
to configuration of the routing (still with the ISP core bypassed)
?
<neg> So far I only have one bit of information missing [16:59]
<pinchartl> what is it ?
<neg> Each ISP is connected to two CSI-2 recivers, which the first one is is
clear, but for each ISP which the second one is missing in the datasheet
[17:00]
<neg> or at least I have not found it
<neg> I managed to figure out what was needed for V3U by trail and error, but
it should ideally be confirmed in a datasheet at some point [17:01]
<pinchartl> ok
<pinchartl> thanks for the information
<pinchartl> and nice work !
<neg> thanks
<neg> IMHO all of the current work is ready to be consumed [17:02]
<pinchartl> * Ulrich
<pinchartl> Since last meeting:
<pinchartl> - Fixed another bug in atest, applied Morimoto-san's patches
<pinchartl> Until next meeting:
<pinchartl> - Fix more issues in atest
<pinchartl> Issues and blockers: None
<pinchartl> uli__: any comment ?
<uli__> nope [17:03]
<neg> the MAX96712 is placed in staging in an attempt to avoid the huge amount
of fun we had with the out-of-tree GMSL1 series ;-)
<pinchartl> thank you
<pinchartl> Topic 2. Discussions
<pinchartl> any discussion topic for today ? [17:04]
<neg> kbingham: GMSL1 cams can also be useful, but it's more or less split
brain inside the MAX96712 between GMSL1 and GMSL2 as far as I can tell
<kbingham> neg, Does the MAX96712 need separate configuration to support both?
[17:05]
<neg> kbingham: Also for totally understandable reasons the fire board is not
reachable during my office hours ;-)
<kbingham> neg You could stay up 'late' one night hehehe
<kbingham> but indeed.
<kbingham> neg, Let me know if you want me to test things though. [17:06]
<neg> kbingham: Not sure all I know is from looking at the block diagrams and
parts I read in the docs by mistake. GMSL2 looks much more fun then
GMSL1
<neg> kbingham: Absolutely, thanks!
<kbingham> neg, but the driver will be able to support both right?
<neg> yes [17:07]
<kbingham> or is it 'a separate' driver ... a la gen2/gen3 vin :-)
<neg> from what I think now there will be two code paths in the driver, one
for GMSL1 and one for GMSL2. And I'm not sure if one can mix and match
between the two
<neg> but it would not surprise me, but maybe we don't need to start out by
considering that ;-0 [17:08]
<kbingham> :-)
<wsa> kbingham: you rather have the board on fire when you sleep??
<kbingham> wsa, No ;-) Neg staying up late pushes him into my office hours ;-)
[17:09]
<neg> wsa: I can't really function before 23pm :-)
<wsa> oh, that are your office hours then... [17:10]
<neg> That's it from me, sorry to drag on
<pinchartl> no worries
<pinchartl> if there's no other discussion topic, I propose adjourning the
meeting. does anyone second ?
<jmondi> o/
<neg> +1 [17:11]
<pinchartl> meeting adjourned. thank you for attending everybody
<neg> have a nice day
<morimoto> have a nice day EuroPeri [17:12]
<uli__> see you
ERC>
|
