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
|
< geertu> pinchartl: mic [17:18]
< pinchartl> thank you
<pinchartl> welcome to the multimedia meeting
<pinchartl> we have 12 minutes ;-)
<pinchartl> Topic 1. Status Check for the Multimedia Tasks
<pinchartl> * Jacopo [17:19]
<pinchartl> Since last meeting:
<pinchartl> - V6 of max9286 integration on Eagle and Condor
<pinchartl> [PATCH v6 0/8] arm64: dts: renesas: Enable GMSL on Eagle and
Condor
<pinchartl> - MAX9271 as a proper subdevice driver
<pinchartl> [RFC 0/5] media: i2c: Add MAX9271 subdevice driver
<pinchartl> - Investigated IMR support with a V4L2 M2M driver
<pinchartl> Until next meeting:
<pinchartl> - If Mauro replies, continue MAX9271 breakout
<pinchartl> - Make a plan for IMR ?
<pinchartl> Issues and blockers: None
<pinchartl> jmondi: any comment ? I've added IMR as a discussion point
<pinchartl> Since last meeting:
<pinchartl> - V3U display investigations
<pinchartl> - V3U DU v2
<pinchartl> - Supporting Wolfram with V3U access (fun poking CN4 pins)
<pinchartl> - Misc review
<pinchartl> Until next meeting:
<pinchartl> - Investigate V3U display timings
<pinchartl> Not happy at 4k resolution
<pinchartl> -
https://lore.kernel.org/r/CAMuHMdWSeeifBLqi4S6LrgcQg9E_1xFXzLzBBBqMf1Fc0kbMhg@mail.gmail.com/
<pinchartl> Issues and blockers: None
<pinchartl> kbingham: any comment ?
<pinchartl> (missing the header with your name, oops, sorry)
<pinchartl> * Laurent [17:20]
<pinchartl> Since last meeting:
<pinchartl> - V4L2 multiplexed streams development
<pinchartl> Continued working with Tomi Valkeinen. Still work in progress (v8
is out).
<pinchartl> - Resuscitated non-contiguous DMABUF import for DU
<pinchartl> No review received so far, which is good as it means nobody
objects (or maybe the patch went under the radar). Still, a review
before merging would be good.
<pinchartl> Added support for buffer sharing between V4L2 and DRM to the
excellent 'cam' tool from libcamera, highly recommended for
testing ;-)
<pinchartl> - Fixed DU regression on Draak/Ebisu
<pinchartl> Will be integrated in v5.16.
<pinchartl> Until next meeting:
<pinchartl> - Upstream pending patches
<pinchartl> - V4L2 multiplexed streams development
<pinchartl> - If time permits, fix known issues with V3U displa
<pinchartl> Issues and blockers: None
<pinchartl> any question ?
<pinchartl> * Morimoto-san
<pinchartl> Since last meeting:
<pinchartl> - Plenty of cool non-multimedia things
<pinchartl> Until next meeting:
<pinchartl> - Resume ALSA work
<pinchartl> Issues and Blockers: None
<pinchartl> moriperi: any comment ?
<pinchartl> * Niklas
<kbingham> Only that I wonder if I need to buy ... another DisplayPort monitor
- or a DisplayPort/HDMI analsyzer... I know which one is cheaper,
and I know which one has more guaranteed results ...
<pinchartl> Since last meeting:
<pinchartl> - [PATCH 0/3] rcar-csi2: Improve link frequency selection
<pinchartl> - [PATCH 0/2] rcar-csi2: Serialize format cfg and improve mutex
handling
<pinchartl> - Tested and rebased work on-top the async rework/rename
<pinchartl> Until next meeting:
<pinchartl> - Follow up pending patches [17:21]
<pinchartl> Issues and blockers: None
<pinchartl> neg: any comment ?
<pinchartl> (trying to pipeline the status reports this time, let's see if it
helps)
<pinchartl> the latter costs and arm and a leg
<pinchartl> and the soul of a few children
<kbingham> Yes, I'm aware of the costs ;-)
<kbingham> I have two child souls available, but I don't own the rights to
disperse their souls, so I can't use them as payment. [17:22]
<damm> how about some sort of exchange? [17:24]
<kbingham> haha ;-)
<damm> =)
<pinchartl> any other comment ? [17:25]
<kbingham> not here
<pinchartl> Topic 2. Discussions [17:26]
<pinchartl> - IMR development
<pinchartl> jmondi: did you want to discuss this ?
<jmondi> I would like to, yes
<jmondi> mostly to confirm it's a viable plan
<pinchartl> viable in what sense ? :-)
<jmondi> that it makes sense to upstream it [17:27]
<jmondi> considering how tightly it is connected to the userpsace application
exercizing it [17:28]
<jmondi> to which, afaict, we have no access to ?
<pinchartl> I think it makes sense [17:29]
<pinchartl> but it means we'll have to create an application using it
<jmondi> then there's the discussion about which subsytem to use
<jmondi> cogent went up to v7 using the v4l2 m2m API
<jmondi> my understanding is that DRM would be more appropriate [17:30]
<jmondi> what do you think ?
<pinchartl> I think DRM would be better, yes [17:31]
<damm> if you can't decide then how about putting the driver in user space (if
possible with IOMMU of course)
<damm> obviously a proper subsystem is better
<pinchartl> it's not just that it's an accelerator (see
https://lwn.net/Articles/867168/ for context) [17:32]
<pinchartl> but it's a rendering engine
<pinchartl> the device takes textures + command buffer in, and outputs an
image
<jmondi> damm: with UIO you mean ?
<pinchartl> conceptually, that's like a GPU
<jmondi> so, the current implementation from cogent is much like the
HanbanaLab thing the article references to [17:33]
<damm> jmondi: if doing a user space driver is the best option then perhaps
UIO is good, but other more suitable options may exist too
<jmondi> a custom IOCTL to have the driver swallow a command set and apply it
to the HW [17:34]
<pinchartl> damm: I think DRM is better than a userspace driver in this case
<damm> pinchartl: most likely yes =)
<jmondi> I'm surprised they went up to v7 without getting a nack, as even with
v4l2 m2m a different mechanism might be more opportune
<jmondi> like a set of v4l2-ctl like we have for codecs [17:35]
<damm> i suppose the documentation is not public which means it is hard to get
the details for people reviewing?
<pinchartl> damm: that's why we would need to provide an open-source userspace
application that actually uses the device [17:36]
<pinchartl> it moves the burden of creating a standard userspace API from the
kernel to userspace
<damm> yeah makes sense
<pinchartl> I've discussed this with Daniel Vetter, and it would be enough to
satisfy the DRM upstreaming criteria, provided that the
application would be structured as a library with the
device-dependent code, and the application on top [17:37]
<pinchartl> then when the next similar device gets upstream support, we can
turn the application into a proper framework
<jmondi> where would you see that userspace code living ?
<jmondi> I assume it cannot be a 'main.c + Makefile' in some random git tree
<pinchartl> fd.o [17:39]
<pinchartl> and it should be a lib + main.c
<pinchartl> a framework for dewarp engines in a sense
<pinchartl> but as a prototype
<pinchartl> we can defer making it a real framework until a second driver gets
upstreamed [17:40]
<pinchartl> but it should be architectured in that way to facilitate the
transition
<damm> can we take commands and textures and store then in DT somehow? =)
[17:41]
<damm> to make it side-ways compatible somehow
<pinchartl> if you want the output of the device to be static then yes
<pinchartl> but in that case I'd prerender the output and use that :-)
<damm> maybe different DT information could be overlaid during runtime?
[17:42]
<damm> (sorry i will stop now) [17:43]
<pinchartl> :-)
<jmondi> :)
<pinchartl> so it seems we have a plan
<jmondi> I admit the userspace part is kind of scary
<pinchartl> a fun research project :-)
<jmondi> the driver part is too, but I can cope
<jmondi> I'm afraid the acceptance criteria for userspace can quickly escalate
to "implement it in weston" or similar [17:44]
<pinchartl> that's why I've discussed it with Daniel
<pinchartl> implementing it in mesa doesn't make too much sense
<pinchartl> and creating the mesa of dewarp engines with a single device as an
example isn't a good idea
<jmondi> am I wrong assuming that if I do enbark in this 'reserach project' I
will fill up my time up to the next year ?
<pinchartl> so making a prototype for such a framework is enough
<pinchartl> next year is fairly soon [17:45]
<jmondi> I meant end of Q12022
<jmondi> maybe it's even too optimistic
<wsa> I gotta leave now. Have a nice day everyone! [17:46]
*** wsa (~wsa@mue-88-130-48-230.dsl.tropolys.de) has quit: Quit: ...
<pinchartl> any other discussion topic for today ? [17:49]
|
