Sakari Ailus [Tue, 29 Sep 2020 09:34:42 +0000 (11:34 +0200)]
media: ccs: Add support for obtaining C-PHY configuration from firmware
Try parsing the firmware also as C-PHY. Do this only after D-PHY as older
firmware may not explicitly specify bus-type in which case D-PHY is the
default.
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Sakari Ailus [Tue, 15 Sep 2020 18:53:26 +0000 (20:53 +0200)]
media: ccs-pll: Add trivial dual PLL support
Add support for sensors that have separate VT and OP domain PLLs.
This support is trivial in the sense that it aims for the same VT pixel
rate than that on the CSI-2 bus. The vast majority of sensors is better
supported by higher frequencies in VT domain in binned and possibly scaled
configurations.
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The PLL calculator only searched even total divisor values apart from one,
but this is wrong: the total divisor is odd in cases where system divisor
is one. Fix this by including odd total PLL values where system divisor is
one to the search.
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Sakari Ailus [Wed, 9 Sep 2020 12:15:48 +0000 (14:15 +0200)]
media: ccs-pll: Print relevant information on PLL tree
Print information on PLL tree configuration based on the flags. This also
adds support for printing dual PLL trees, and better separates between OP
and VT PLL trees.
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Sakari Ailus [Fri, 28 Aug 2020 06:24:18 +0000 (08:24 +0200)]
media: ccs-pll: Check for derating and overrating, support non-derating sensors
Some sensors support derating (VT domain speed faster than OP) or
overrating (VT domain speed slower than OP). While this was supported for
the driver, the hardware support for the feature was never verified. Do
that now, and for those devices without that support, VT and OP speeds
have to match.
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Sakari Ailus [Tue, 25 Aug 2020 20:23:43 +0000 (22:23 +0200)]
media: ccs-pll: Split off VT subtree calculation
Split off the VT sub clock tree calculation from the rest, into its own
function. Also call the op_pll_fr argument pll_fr, since soon these may
not be OP tree values.
This paves way for additional features in the future such as dual PLL
support.
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Sakari Ailus [Fri, 7 Aug 2020 09:07:14 +0000 (11:07 +0200)]
media: ccs-pll: Add support flexible OP PLL pixel clock divider
Flexible OP PLL pixel clock divider allows a higher OP pixel clock than
what the bus can transfer. This generally makes it easier to select pixel
clock dividers.
This changes how the pixel rate on the bus and minimum VT divisor are
calculated, as the pixel rate is no longer directly determined by the
OP pixel clock and the number of the lanes.
Also add a sanity check for sensors that do not support flexible OP PLL
pixel clock divider. This could have caused the PLL calculator to come up
with an invalid configuration for those devices.
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Sakari Ailus [Tue, 23 Jun 2020 11:40:32 +0000 (13:40 +0200)]
media: ccs-pll: Add support for extended input PLL clock divider
CCS allows odd PLL dividers other than 1, granted that the corresponding
capability bit is set. Support this both in the PLL calculator and the CCS
driver.
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Sakari Ailus [Thu, 18 Jun 2020 10:39:44 +0000 (12:39 +0200)]
media: ccs-pll: Add support for decoupled OP domain calculation
Add support for decoupled OP domain clock calculation. This means that the
number of VT and OP domain clocks are no longer dependent on the number of
CSI-2 lanes in the lane speed mode.
The support also replaces the existing quirk flag to calculate OP domain
clocks per lane.
Also support decoupled OP domain calculation in the CCS driver.
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Sakari Ailus [Wed, 23 Sep 2020 10:16:03 +0000 (12:16 +0200)]
media: ccs: Add support for lane speed model
Convey the relevant PLL flags to the PLL calculator. Also the lane speed
model affects how the link rate is calculated on the CSI-2 bus, as the
rate is total of all lanes.
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Sakari Ailus [Tue, 7 Jul 2020 13:24:09 +0000 (15:24 +0200)]
media: ccs-pll: Fix check for PLL multiplier upper bound
The additional multiplier (for higher VT timing) of the PLL multiplier was
checked against the upper limit but the result was rounded up, possibly
producing too high additional multiplier. Round down instead to keep
within hardware limits.
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Sakari Ailus [Tue, 7 Jul 2020 08:31:56 +0000 (10:31 +0200)]
media: ccs-pll: Avoid overflow in pre-PLL divisor lower bound search
The external clock frequency times the PLL multiplier may exceed the value
range of 32-bit unsigned integers. Instead perform the same calculation y
using two divisions.
The result has some potential to be different, but that's ok: this number
is used to limit the range of pre-PLL divisors to find optimal values. So
the effect of the rare case of a different result here would mean an
invalid pre-PLL divisor is tried. That will be found out a little later in
any case.
Also guard against dividing by zero if the external clock frequency is
higher than the maximum OP PLL output clock --- a rather improbable case.
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Sakari Ailus [Tue, 7 Jul 2020 08:08:01 +0000 (10:08 +0200)]
media: ccs-pll: Fix condition for pre-PLL divider lower bound
The lower bound of the pre-PLL divider was calculated based on OP SYS
clock frequency which is also affected by the OP SYS clock divider. This
is wrong. The right clock frequency is that of the PLL output clock.
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Sakari Ailus [Fri, 26 Jun 2020 09:56:47 +0000 (11:56 +0200)]
media: ccs-pll: Begin calculation from OP system clock frequency
The OP system clock frequency defines the CSI-2 bus clock frequency, not
the PLL output clock frequency. Both values were overwritten in the end,
but the wrong limit value was used for the OP system clock frequency,
possibly leading to too high frequencies being used.
Also remove now duplicated calculation of OP system clock frequency later
in the PLL calculator.
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Sakari Ailus [Mon, 8 Jun 2020 12:16:29 +0000 (14:16 +0200)]
media: ccs-pll: Document the structs in the header as well as the function
The CCS pll is used by the CCS driver at the moment, but documenting the
interface makes sense. It's non-trivial and the calculator could be used
elsewhere.
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Sakari Ailus [Tue, 1 Sep 2020 11:11:11 +0000 (13:11 +0200)]
media: ccs-pll: End search if there are no better values available
The VT divisor search can be ended if we've already found the value that
corresponds exactly the total divisor, as there are no better (lower)
values available.
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Sakari Ailus [Tue, 1 Sep 2020 11:08:26 +0000 (13:08 +0200)]
media: ccs-pll: Use correct VT divisor for calculating VT SYS divisor
Use the correct video timing divisor to calculate the SYS divisor. Instead
of the current value, the minimum was used. This could have resulted in a
too low SYS divisor.
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Hans Verkuil [Tue, 1 Dec 2020 12:44:40 +0000 (13:44 +0100)]
media: vivid: fix 'disconnect' error injection
The 'disconnect' error injection functionality suffered from bit rot.
New device nodes were added without updating vivid_user_gen_s_ctrl(), so
that function had to be updated for the new device nodes.
Also, vivid didn't check if specific device nodes were actually ever
created, so the vivid_is_last_user() would fail on that (it would return
true instead of false in that case).
Finally, selecting Disconnect, then unbind the vivid driver would fail
since the remove() would think that the device nodes were already
unregistered. Keep track of whether disconnect was pressed and re-register
the device nodes in remove() before doing the real unregister.
[hverkuil: unsigned uses -> unsigned int uses]
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Jacopo Mondi [Thu, 26 Nov 2020 07:47:57 +0000 (08:47 +0100)]
media: rcar-vin: Mask VNCSI_IFMD register
The VNCSI_IFMD register controls the data expansion mode and the
channel routing between the CSI-2 receivers and VIN instances.
According to the chip manual revision 2.20 not all fields are available
for all the SoCs:
- V3M, V3H and E3 do not support the DES1 field has they do not feature
a CSI20 receiver.
- D3 only supports parallel input, and the whole register shall always
be written as 0.
Inspect the per-SoC channel routing table where the available CSI-2
instances are reported and configure VNCSI_IFMD accordingly.
This patch supports this BSP change commit:
https://github.com/renesas-rcar/linux-bsp/commit/f54697394457
("media: rcar-vin: Fix VnCSI_IFMD register access for r8a77990")
Neil Armstrong [Wed, 2 Dec 2020 17:44:15 +0000 (18:44 +0100)]
media: meson: Add M2M driver for the Amlogic GE2D Accelerator Unit
The GE2D is a 2D accelerator with various features like configurable
blitter with alpha blending, frame rotation, scaling, format conversion
and colorspace conversion.
The driver implements a Memory2Memory VB2 V4L2 streaming device permitting:
- 0, 90, 180, 270deg rotation
- horizontal/vertical flipping
- source cropping
- destination compositing
- 32bit/24bit/16bit format conversion
This adds the support for the GE2D version found in the AXG SoCs Family.
The missing features are:
- Source scaling
- Colorspace conversion
- Advanced alpha blending & blitting options
Neil Armstrong [Wed, 2 Dec 2020 17:44:14 +0000 (18:44 +0100)]
media: dt-bindings: media: Add bindings for the Amlogic GE2D Accelerator Unit
The GE2D is a 2D accelerator with various features like configurable blitter
with alpha blending, frame rotation, scaling, format conversion and colorspace
conversion.
This adds the bindings for the GE2D version found in the AXG SoCs Family.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Jernej Skrabec [Wed, 2 Dec 2020 17:44:13 +0000 (18:44 +0100)]
media: cedrus: Make VP8 codec as capability
Commit 31d9b9ef8564 ("media: cedrus: Register all codecs as capability")
makes separate capability flags for each codec. However, VP8 codec was
merged at the same time as mentioned patch, so there is no capability
flag for it.
This patch adds capability flag for VP8 and enables it for all variants
except for V3s.
Alan Stern [Wed, 2 Dec 2020 17:20:04 +0000 (18:20 +0100)]
media: gspca: Fix memory leak in probe
The gspca driver leaks memory when a probe fails. gspca_dev_probe2()
calls v4l2_device_register(), which takes a reference to the
underlying device node (in this case, a USB interface). But the
failure pathway neglects to call v4l2_device_unregister(), the routine
responsible for dropping this reference. Consequently the memory for
the USB interface and its device never gets released.
This patch adds the missing function call.
Reported-and-tested-by: syzbot+44e64397bd81d5e84cba@syzkaller.appspotmail.com Signed-off-by: Alan Stern <stern@rowland.harvard.edu> CC: <stable@vger.kernel.org> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Laurent Pinchart [Sun, 6 Dec 2020 23:03:16 +0000 (00:03 +0100)]
media: doc: pixfmt-yuv: Move all planar YUV formats to common file
Planar pixel formats are documented in separate files. This duplicates
information, as those formats share comon traits. Consolidate them in a
single file and summarize their descriptions in a single table.
Laurent Pinchart [Sun, 6 Dec 2020 23:03:15 +0000 (00:03 +0100)]
media: doc: pixfmt-yuv: Move all semi-planar YUV formats to common file
Semi-planar pixel formats are documented in separate files. This
duplicates information, as those formats share comon traits. Consolidate
them in a single file and summarize their descriptions in a single
table.
Laurent Pinchart [Sun, 6 Dec 2020 23:03:14 +0000 (00:03 +0100)]
media: doc: pixfmt-yuv: Move all luma-only YUV formats to common file
Luma-only pixel formats are documented in separate files. This
duplicates information, as those formats share comon traits. Consolidate
them in a single file and describe them in a single table.
Laurent Pinchart [Sun, 6 Dec 2020 23:03:12 +0000 (00:03 +0100)]
media: doc: pixfmt-packed-yuv: Express 4:4:4 formats in a more compact way
The 4:4:4 packed YUV formats are documented with a bit-level
representation, which creates a wide table. Switch to a byte-oriented
representation to make it more compact. This prepares for the addition
of formats with more than 8 bits per component, that would make the
table way too wide.
Laurent Pinchart [Sun, 6 Dec 2020 23:03:11 +0000 (00:03 +0100)]
media: doc: pixfmt-packed-yuv: Fill padding bits with 'X'
The padding bits are left blank, which look weird in the XYUV format,
and, worse, may lead to the VUYX format to be understand as consuming 3
bytes per pixel. Add 'X' for padding bits as we do for RGB formats.
Laurent Pinchart [Sun, 6 Dec 2020 23:03:10 +0000 (00:03 +0100)]
media: doc: pixfmt-yuv: Move all packed YUV formats to common file
The pixfmt-packed-yuv.rst file documents packed YUV 4:4:4 formats, but
is titled generically as "Packed YUV formats". 4:2:2 and 4:1:1 packed
YUV formats are documented in separate files, which can be confusing.
Group all packed YUV formats in pixfmt-packed-yuv.rst, which allows
documenting the 4:2:2 formats in a more concise way.
Laurent Pinchart [Sun, 6 Dec 2020 23:03:09 +0000 (00:03 +0100)]
media: doc: pixfmt-yuv: Document subsampling in more details
Document YUV subsampling, including chroma spatial siting, and replace
the siting examples in individual formats by references to the common
documentation.
Laurent Pinchart [Sun, 6 Dec 2020 23:03:07 +0000 (00:03 +0100)]
media: doc: pixfmt-rgb: Make 8 bits per component table more compact
All formats using 8 bits per component can be described with a byte
granularity instead of a bit granularity without loss of precision. This
makes the corresponding table more compact and easier to read.
Laurent Pinchart [Sun, 6 Dec 2020 23:03:06 +0000 (00:03 +0100)]
media: doc: pixfmt-rgb: Clarify naming scheme for RGB formats
The naming scheme for the RGB pixel formats has been developed
organically, and isn't consistent between formats using less than 8 bits
per pixels (mostly stored in 1 or 2 bytes per pixel, except for RGB666
that uses 4 bytes per pixel) and formats with 8 bits per pixel (stored
in 3 or 4 bytes). For the latter category, the names use a components
order convention that is the opposite of the first category, and the
opposite of DRM pixel formats. This has led to lots of confusion in the
past, and would really benefit from being explained more precisely. Do
so, which also prepares for the addition of additional RGB pixels
formats.
Laurent Pinchart [Sun, 6 Dec 2020 23:03:04 +0000 (00:03 +0100)]
media: doc: pixfmt-rgb: Remove layout table for packed RGB formats
The packed RGB formats documentation includes a layout table without any
context. This doesn't bring much useful information, and is confusing at
best. Remove it.
Laurent Pinchart [Sun, 6 Dec 2020 23:03:03 +0000 (00:03 +0100)]
media: videodev2.h: Move HM12 format to YUV semi-planar section
V4L2_PIX_FMT_HM12 is a YUV semi-planar macro-block format. Move it from
the packed YUV formats section where it was misplaced to the YUV
semi-planar formats section.
Laurent Pinchart [Sun, 6 Dec 2020 23:03:02 +0000 (00:03 +0100)]
media: videodev2.h: Move HI240 format to vendor-specific section
V4L2_PIX_FMT_HI240 is a 8-bit dithered RGB format specific to BTTV. Move
it from the packed YUV formats section where it was misplaced to the
vendor-specific formats section.
Laurent Pinchart [Sun, 6 Dec 2020 23:03:01 +0000 (00:03 +0100)]
media: videodev2.h: Remove unneeded comment about 4CC value
The V4L2_PIX_FMT_BGRA444 format has a comment that explains why its 4CC
value is GA12. This explains the development history and isn't of much
interest to readers, it should have been part of a commit message
instead. Drop the comment, anyone interested in history can turn to git.
Sakari Ailus [Fri, 4 Dec 2020 11:46:56 +0000 (12:46 +0100)]
media: ccs: Fix return value from probe
rval wasn't set, resulting in probe returning zero instead of an error.
Fixes: de10c1619c48 ("[media] smiapp: Get clock rate if it's not available through DT") Reported-by: Zhang Changzhong <zhangchangzhong@huawei.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Arnd Bergmann [Thu, 3 Dec 2020 22:28:16 +0000 (23:28 +0100)]
media: ccs: avoid printing an uninitialized variable
There is no intialization for the 'reg' variable, so printing
it produces undefined behavior as well as a compile-time warning:
drivers/media/i2c/ccs/ccs-core.c:314:49: error: variable 'reg' is uninitialized when used here [-Werror,-Wuninitialized]
"0x%8.8x %s pixels: %d %s (pixelcode %u)\n", reg,
Arnd Bergmann [Fri, 4 Dec 2020 08:20:14 +0000 (09:20 +0100)]
media: i2c: fix an uninitialized error code
Clang points out that the error handling in ov02a10_s_stream() is
broken, and just returns a random error code:
drivers/media/i2c/ov02a10.c:537:6: warning: variable 'ret' is used uninitialized whenever 'if' condition is true [-Wsometimes-uninitialized]
if (ov02a10->streaming == on)
^~~~~~~~~~~~~~~~~~~~~~~~
drivers/media/i2c/ov02a10.c:568:9: note: uninitialized use occurs here
return ret;
^~~
drivers/media/i2c/ov02a10.c:537:2: note: remove the 'if' if its condition is always false
if (ov02a10->streaming == on)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If streaming is already on, leave it that way and return success.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Signed-off-by: Christian Hewitt <christianshewitt@gmail.com> Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
media: pixfmt-meta-rkisp1.rst: fix two build warnings
With Sphinx 2.x: those two warnings are produced:
/devel/v4l/docs/sphinx2/Documentation/output/videodev2.h.rst:6: WARNING: undefined label: v4l2-meta-fmt-rk-isp1-params (if the link has no caption the label must precede a section header)
/devel/v4l/docs/sphinx2/Documentation/output/videodev2.h.rst:6: WARNING: undefined label: v4l2-meta-fmt-rk-isp1-stat-3a (if the link has no caption the label must precede a section header)
The reason is that there's no blank line between the two
identifiers.
Hans Verkuil [Thu, 26 Nov 2020 13:08:36 +0000 (14:08 +0100)]
media: ext-ctrls-codec.rst: move FWHT docs to ext-ctrls-codec-stateless.rst
Move the documentation for the stateless FWHT codec to
ext-ctrls-codec-stateless.rst since that is the proper place
for the stable stateless API documentation.
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Hans Verkuil [Thu, 26 Nov 2020 13:02:18 +0000 (14:02 +0100)]
media: vicodec: mark the stateless FWHT API as stable
The FWHT stateless 'uAPI' was staging and marked explicitly in the
V4L2 specification that it will change and is unstable.
Note that these control IDs were never exported as a public API,
they were only defined in kernel-local headers (fwht-ctrls.h).
Now, the FWHT stateless controls is ready to be part
of the stable uAPI.
While not too late:
- Rename V4L2_CID_MPEG_VIDEO_FWHT_PARAMS to V4L2_CID_STATELESS_FWHT_PARAMS.
- Move the contents of fwht-ctrls.h to v4l2-controls.h.
- Move the public parts of drivers/media/test-drivers/vicodec/codec-fwht.h
to v4l2-controls.h.
- Add V4L2_CTRL_TYPE_FWHT_PARAMS control initialization and validation.
- Add p_fwht_params to struct v4l2_ext_control.
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Hans Verkuil [Thu, 26 Nov 2020 12:58:20 +0000 (13:58 +0100)]
media: vicodec: add V4L2_ prefix before FWHT_VERSION and FWHT_FL_*
The FWHT stateless 'uAPI' was staging and marked explicitly in the
V4L2 specification that it will change and is unstable.
Note that these control IDs were never exported as a public API,
they were only defined at the driver's code.
While not too late, let's rename them is preparation for promoting
the stateless FWHT codec API as a public API.
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The v4l2_area struct was not documented in the media documentation,
which meant that references to that struct elsewhere in the documentation
never linked to anything.
Helen Koike [Wed, 18 Nov 2020 14:24:00 +0000 (15:24 +0100)]
media: admin-guide/pixfmt-meta-rkisp1.rst: pixfmt reference conforming with macro
Fix warnings from make htmlddocs:
Documentation/output/videodev2.h.rst:6: WARNING: undefined label: v4l2-meta-fmt-rk-isp1-params (if the link has no caption the label must precede a section header)
Documentation/output/videodev2.h.rst:6: WARNING: undefined label: v4l2-meta-fmt-rk-isp1-stat-3a (if the link has no caption the label must precede a section header)
Fixes: df22026aebd8 ("media: videodev2.h, v4l2-ioctl: add rkisp1 meta buffer format") Signed-off-by: Helen Koike <helen.koike@collabora.com> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Ezequiel Garcia [Thu, 26 Nov 2020 09:36:17 +0000 (10:36 +0100)]
media: uapi: move H264 stateless controls out of staging
The H.264 stateless 'uAPI' was staging and marked explicitly in the
V4L2 specification that it will change and is unstable.
Note that these control IDs were never exported as a public API,
they were only defined in kernel-local headers (h264-ctrls.h).
Now, the H264 stateless controls is ready to be part
of the stable uAPI.
While not too late, let's rename them and re-number their
control IDs, moving them to the newly created stateless
control class, and updating all the drivers accordingly.
Ezequiel Garcia [Thu, 26 Nov 2020 09:36:16 +0000 (10:36 +0100)]
media: controls: Log H264 stateless controls in .std_log
For now, only print the type of the control. In the future,
we might want to be able to print the values of all
the stateless codec controls currently set in the control handler,
which should be useful for debugging reasons.
Ezequiel Garcia [Thu, 26 Nov 2020 09:36:09 +0000 (10:36 +0100)]
media: Rename stateful codec control macros
For historical reasons, stateful codec controls are named
as {}_MPEG_{}. While we can't at this point sanely
change all control IDs (such as V4L2_CID_MPEG_VIDEO_VP8_FRAME_HEADER),
we can least change the more meaningful macros such as classes
macros.
Jonas Karlman [Thu, 26 Nov 2020 09:36:07 +0000 (10:36 +0100)]
media: rkvdec: h264: Support profile and level controls
The Rockchip Video Decoder used in RK3399 supports H.264 profiles from
Baseline to High 4:2:2 up to Level 5.1, except for the Extended profile.
Expose the V4L2_CID_MPEG_VIDEO_H264_PROFILE and the
V4L2_CID_MPEG_VIDEO_H264_LEVEL control, so that userspace can query the
driver for the list of supported profiles and level.
For now, we don't expose 4:2:2 since the driver doesn't
implement the required support.
[Ezequiel: Don't expose 4:2:2 profile for now]
Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Add a debug message for control validation (validate_new)
failures. This is useful to debug issues with ioctls such
as VIDIOC_TRY_EXT_CTRLS and VIDIOC_S_EXT_CTRLS.
Sakari Ailus [Fri, 18 Sep 2020 09:36:38 +0000 (11:36 +0200)]
media: ccs: Wrap long lines, unwrap short ones
Over the years (and renaming) some lines that may well be wrapped ended up
being over 80 characters, likewise there are shorter lines that can be
merged. Do that.
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Sakari Ailus [Fri, 18 Sep 2020 09:23:39 +0000 (11:23 +0200)]
media: ccs: Clean up runtime PM usage
If pm_runtime_get_sync() fails, there's no need to set the device active
again. Also, in the same case to return the usage_count to zero,
pm_runtime_put_noidle() is enough.
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
projects / users / jedix / linux-maple.git / log