1 Media Subsystem Profile
2 =======================
3
4 Overview
5 --------
6
7 The media subsystem covers support for a varie
8 capture, analog and digital TV streams, camera
9 and media pipeline control.
10
11 It covers, mainly, the contents of those direc
12
13 - drivers/media
14 - drivers/staging/media
15 - Documentation/admin-guide/media
16 - Documentation/driver-api/media
17 - Documentation/userspace-api/media
18 - Documentation/devicetree/bindings/media/\
19 - include/media
20
21 .. [1] Device tree bindings are maintained by
22 OPEN FIRMWARE AND FLATTENED DEVICE TREE
23 (see the MAINTAINERS file). So, changes
24 by them before being merged via the med
25 tree.
26
27 Both media userspace and Kernel APIs are docum
28 must be kept in sync with the API changes. It
29 add new features to the subsystem must also br
30 corresponding API files.
31
32 Due to the size and wide scope of the media su
33 maintainership model is to have sub-maintainer
34 knowledge of a specific aspect of the subsyste
35 task to review the patches, providing feedback
36 following the subsystem rules and are properly
37 userspace APIs.
38
39 Patches for the media subsystem must be sent t
40 at linux-media@vger.kernel.org as plain text o
41 HTML will be automatically rejected by the mai
42 to also copy the sub-maintainer(s).
43
44 Media's workflow is heavily based on Patchwork
45 is submitted, the e-mail will first be accepte
46 server, and, after a while, it should appear a
47
48 - https://patchwork.linuxtv.org/project/lin
49
50 If it doesn't automatically appear there after
51 probably something went wrong on your submissi
52 email is in plain text\ [2]_ only and if your
53 whitespaces before complaining or submitting t
54
55 You can check if the mailing list server accep
56
57 - https://lore.kernel.org/linux-media/
58
59 .. [2] If your email contains HTML, the mailin
60 drop it, without any further notice.
61
62
63 Media maintainers
64 +++++++++++++++++
65
66 At the media subsystem, we have a group of sen
67 are responsible for doing the code reviews at
68 sub-maintainers), and another senior developer
69 subsystem as a whole. For core changes, whenev
70 media maintainers do the review.
71
72 The media maintainers that work on specific ar
73
74 - Remote Controllers (infrared):
75 Sean Young <sean@mess.org>
76
77 - HDMI CEC:
78 Hans Verkuil <hverkuil@xs4all.nl>
79
80 - Media controller drivers:
81 Laurent Pinchart <laurent.pinchart@ideasonb
82
83 - ISP, v4l2-async, v4l2-fwnode, v4l2-flash-led
84 Sakari Ailus <sakari.ailus@linux.intel.com>
85
86 - V4L2 drivers and core V4L2 frameworks:
87 Hans Verkuil <hverkuil@xs4all.nl>
88
89 The subsystem maintainer is:
90 Mauro Carvalho Chehab <mchehab@kernel.org>
91
92 Media maintainers may delegate a patch to othe
93 On such case, checkpatch's ``delegate`` field
94 responsible for reviewing a patch.
95
96 Submit Checklist Addendum
97 -------------------------
98
99 Patches that change the Open Firmware/Device T
100 reviewed by the Device Tree maintainers. So, D
101 Cc:ed when those are submitted via devicetree@
102 list.
103
104 There is a set of compliance tools at https://
105 that should be used in order to check if the d
106 implementing the media APIs:
107
108 ==================== ======================
109 Type Tool
110 ==================== ======================
111 V4L2 drivers\ [3]_ ``v4l2-compliance``
112 V4L2 virtual drivers ``contrib/test/test-me
113 CEC drivers ``cec-compliance``
114 ==================== ======================
115
116 .. [3] The ``v4l2-compliance`` also covers the
117 V4L2 drivers.
118
119 Other compilance tools are under development t
120 subsystem.
121
122 Those tests need to pass before the patches go
123
124 Also, please notice that we build the Kernel w
125
126 make CF=-D__CHECK_ENDIAN__ CONFIG_DEBU
127
128 Where the check script is::
129
130 #!/bin/bash
131 /devel/smatch/smatch -p=kernel $@ >&2
132 /devel/sparse/sparse $@ >&2
133
134 Be sure to not introduce new warnings on your
135 very good reason.
136
137 Style Cleanup Patches
138 +++++++++++++++++++++
139
140 Style cleanups are welcome when they come toge
141 at the files where the style changes will affe
142
143 We may accept pure standalone style cleanups,
144 be one patch for the whole subsystem (if the c
145 or at least be grouped per directory. So, for
146 big cleanup change set at drivers under driver
147 patch for all drivers under drivers/media/pci,
148 drivers/media/usb and so on.
149
150 Coding Style Addendum
151 +++++++++++++++++++++
152
153 Media development uses ``checkpatch.pl`` on st
154 style, e.g.::
155
156 $ ./scripts/checkpatch.pl --strict --m
157
158 In principle, patches should follow the coding
159 are allowed if there are good reasons. On such
160 may question about the rationale for not addre
161
162 Please notice that the goal here is to improve
163 a few cases, ``checkpatch.pl`` may actually po
164 look worse. So, you should use good sense.
165
166 Note that addressing one ``checkpatch.pl`` iss
167 to having longer lines than 80 characters per
168 strictly prohibited, efforts should be made to
169 characters per line. This could include using
170 to less indentation, shorter variable or funct
171 least, simply wrapping the lines.
172
173 In particular, we accept lines with more than
174
175 - on strings, as they shouldn't be broken
176 - when a function or variable name need to
177 which keeps hard to honor the 80 columns
178 - on arithmetic expressions, when breaking
179 read;
180 - when they avoid a line to end with an op
181 bracket.
182
183 Key Cycle Dates
184 ---------------
185
186 New submissions can be sent at any time, but i
187 next merge window they should be sent before -
188 in the linux-media branch by -rc6.
189
190 Review Cadence
191 --------------
192
193 Provided that your patch is at https://patchwo
194 be sooner or later handled, so you don't need
195
196 Except for bug fixes, we don't usually add new
197 tree between -rc6 and the next -rc1.
198
199 Please notice that the media subsystem is a hi
200 could take a while for us to be able to review
201 to ping if you don't get a feedback in a coupl
202 other developers to publicly add Reviewed-by a
203 ``Tested-by:`` tags.
204
205 Please note that we expect a detailed descript
206 identifying what boards were used at the test
Linux® is a registered trademark of Linus Torvalds in the United States and other countries.
TOMOYO® is a registered trademark of NTT DATA CORPORATION.