Skip to content

Commit b3491d8

Browse files
committed
Merge tag 'media/v4.20-2' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media
Pull new experimental media request API from Mauro Carvalho Chehab: "A new media request API This API is needed to support device drivers that can dynamically change their parameters for each new frame. The latest versions of Google camera and codec HAL depends on such feature. At this stage, it supports only stateless codecs. It has been discussed for a long time (at least over the last 3-4 years), and we finally reached to something that seem to work. This series contain both the API and core changes required to support it and a new m2m decoder driver (cedrus). As the current API is still experimental, the only real driver using it (cedrus) was added at staging[1]. We intend to keep it there for a while, in order to test the API. Only when we're sure that this API works for other cases (like encoders), we'll move this driver out of staging and set the API into a stone. [1] We added support for the vivid virtual driver (used only for testing) to it too, as it makes easier to test the API for the ones that don't have the cedrus hardware" * tag 'media/v4.20-2' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media: (53 commits) media: dt-bindings: Document the Rockchip VPU bindings media: platform: Add Cedrus VPU decoder driver media: dt-bindings: media: Document bindings for the Cedrus VPU driver media: v4l: Add definition for the Sunxi tiled NV12 format media: v4l: Add definitions for MPEG-2 slice format and metadata media: videobuf2-core: Rework and rename helper for request buffer count media: v4l2-ctrls.c: initialize an error return code with zero media: v4l2-compat-ioctl32.c: add missing documentation for a field media: media-request: update documentation media: media-request: EPERM -> EACCES/EBUSY media: v4l2-ctrls: improve media_request_(un)lock_for_update media: v4l2-ctrls: use media_request_(un)lock_for_access media: media-request: add media_request_(un)lock_for_access media: vb2: set reqbufs/create_bufs capabilities media: videodev2.h: add new capabilities for buffer types media: buffer.rst: only set V4L2_BUF_FLAG_REQUEST_FD for QBUF media: v4l2-ctrls: return -EACCES if request wasn't completed media: media-request: return -EINVAL for invalid request_fds media: vivid: add request support media: vivid: add mc ...
2 parents 59fc453 + e4183d3 commit b3491d8

File tree

102 files changed

+6166
-385
lines changed

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

102 files changed

+6166
-385
lines changed
Lines changed: 54 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,54 @@
1+
Device-tree bindings for the VPU found in Allwinner SoCs, referred to as the
2+
Video Engine (VE) in Allwinner literature.
3+
4+
The VPU can only access the first 256 MiB of DRAM, that are DMA-mapped starting
5+
from the DRAM base. This requires specific memory allocation and handling.
6+
7+
Required properties:
8+
- compatible : must be one of the following compatibles:
9+
- "allwinner,sun4i-a10-video-engine"
10+
- "allwinner,sun5i-a13-video-engine"
11+
- "allwinner,sun7i-a20-video-engine"
12+
- "allwinner,sun8i-a33-video-engine"
13+
- "allwinner,sun8i-h3-video-engine"
14+
- reg : register base and length of VE;
15+
- clocks : list of clock specifiers, corresponding to entries in
16+
the clock-names property;
17+
- clock-names : should contain "ahb", "mod" and "ram" entries;
18+
- resets : phandle for reset;
19+
- interrupts : VE interrupt number;
20+
- allwinner,sram : SRAM region to use with the VE.
21+
22+
Optional properties:
23+
- memory-region : CMA pool to use for buffers allocation instead of the
24+
default CMA pool.
25+
26+
Example:
27+
28+
reserved-memory {
29+
#address-cells = <1>;
30+
#size-cells = <1>;
31+
ranges;
32+
33+
/* Address must be kept in the lower 256 MiBs of DRAM for VE. */
34+
cma_pool: cma@4a000000 {
35+
compatible = "shared-dma-pool";
36+
size = <0x6000000>;
37+
alloc-ranges = <0x4a000000 0x6000000>;
38+
reusable;
39+
linux,cma-default;
40+
};
41+
};
42+
43+
video-codec@1c0e000 {
44+
compatible = "allwinner,sun7i-a20-video-engine";
45+
reg = <0x01c0e000 0x1000>;
46+
47+
clocks = <&ccu CLK_AHB_VE>, <&ccu CLK_VE>,
48+
<&ccu CLK_DRAM_VE>;
49+
clock-names = "ahb", "mod", "ram";
50+
51+
resets = <&ccu RST_VE>;
52+
interrupts = <GIC_SPI 53 IRQ_TYPE_LEVEL_HIGH>;
53+
allwinner,sram = <&ve_sram 1>;
54+
};
Lines changed: 29 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,29 @@
1+
device-tree bindings for rockchip VPU codec
2+
3+
Rockchip (Video Processing Unit) present in various Rockchip platforms,
4+
such as RK3288 and RK3399.
5+
6+
Required properties:
7+
- compatible: value should be one of the following
8+
"rockchip,rk3288-vpu";
9+
"rockchip,rk3399-vpu";
10+
- interrupts: encoding and decoding interrupt specifiers
11+
- interrupt-names: should be "vepu" and "vdpu"
12+
- clocks: phandle to VPU aclk, hclk clocks
13+
- clock-names: should be "aclk" and "hclk"
14+
- power-domains: phandle to power domain node
15+
- iommus: phandle to a iommu node
16+
17+
Example:
18+
SoC-specific DT entry:
19+
vpu: video-codec@ff9a0000 {
20+
compatible = "rockchip,rk3288-vpu";
21+
reg = <0x0 0xff9a0000 0x0 0x800>;
22+
interrupts = <GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH>,
23+
<GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH>;
24+
interrupt-names = "vepu", "vdpu";
25+
clocks = <&cru ACLK_VCODEC>, <&cru HCLK_VCODEC>;
26+
clock-names = "aclk", "hclk";
27+
power-domains = <&power RK3288_PD_VIDEO>;
28+
iommus = <&vpu_mmu>;
29+
};

Documentation/media/kapi/mc-core.rst

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -262,3 +262,5 @@ in the end provide a way to use driver-specific callbacks.
262262
.. kernel-doc:: include/media/media-devnode.h
263263

264264
.. kernel-doc:: include/media/media-entity.h
265+
266+
.. kernel-doc:: include/media/media-request.h

Documentation/media/uapi/mediactl/media-controller.rst

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -21,6 +21,7 @@ Part IV - Media Controller API
2121
media-controller-intro
2222
media-controller-model
2323
media-types
24+
request-api
2425
media-funcs
2526
media-header
2627

Documentation/media/uapi/mediactl/media-funcs.rst

Lines changed: 6 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -16,3 +16,9 @@ Function Reference
1616
media-ioc-enum-entities
1717
media-ioc-enum-links
1818
media-ioc-setup-link
19+
media-ioc-request-alloc
20+
request-func-close
21+
request-func-ioctl
22+
request-func-poll
23+
media-request-ioc-queue
24+
media-request-ioc-reinit
Lines changed: 66 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,66 @@
1+
.. SPDX-License-Identifier: GPL-2.0 OR GFDL-1.1-or-later WITH no-invariant-sections
2+
3+
.. _media_ioc_request_alloc:
4+
5+
*****************************
6+
ioctl MEDIA_IOC_REQUEST_ALLOC
7+
*****************************
8+
9+
Name
10+
====
11+
12+
MEDIA_IOC_REQUEST_ALLOC - Allocate a request
13+
14+
15+
Synopsis
16+
========
17+
18+
.. c:function:: int ioctl( int fd, MEDIA_IOC_REQUEST_ALLOC, int *argp )
19+
:name: MEDIA_IOC_REQUEST_ALLOC
20+
21+
22+
Arguments
23+
=========
24+
25+
``fd``
26+
File descriptor returned by :ref:`open() <media-func-open>`.
27+
28+
``argp``
29+
Pointer to an integer.
30+
31+
32+
Description
33+
===========
34+
35+
If the media device supports :ref:`requests <media-request-api>`, then
36+
this ioctl can be used to allocate a request. If it is not supported, then
37+
``errno`` is set to ``ENOTTY``. A request is accessed through a file descriptor
38+
that is returned in ``*argp``.
39+
40+
If the request was successfully allocated, then the request file descriptor
41+
can be passed to the :ref:`VIDIOC_QBUF <VIDIOC_QBUF>`,
42+
:ref:`VIDIOC_G_EXT_CTRLS <VIDIOC_G_EXT_CTRLS>`,
43+
:ref:`VIDIOC_S_EXT_CTRLS <VIDIOC_G_EXT_CTRLS>` and
44+
:ref:`VIDIOC_TRY_EXT_CTRLS <VIDIOC_G_EXT_CTRLS>` ioctls.
45+
46+
In addition, the request can be queued by calling
47+
:ref:`MEDIA_REQUEST_IOC_QUEUE` and re-initialized by calling
48+
:ref:`MEDIA_REQUEST_IOC_REINIT`.
49+
50+
Finally, the file descriptor can be :ref:`polled <request-func-poll>` to wait
51+
for the request to complete.
52+
53+
The request will remain allocated until all the file descriptors associated
54+
with it are closed by :ref:`close() <request-func-close>` and the driver no
55+
longer uses the request internally. See also
56+
:ref:`here <media-request-life-time>` for more information.
57+
58+
Return Value
59+
============
60+
61+
On success 0 is returned, on error -1 and the ``errno`` variable is set
62+
appropriately. The generic error codes are described at the
63+
:ref:`Generic Error Codes <gen-errors>` chapter.
64+
65+
ENOTTY
66+
The driver has no support for requests.
Lines changed: 78 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,78 @@
1+
.. SPDX-License-Identifier: GPL-2.0 OR GFDL-1.1-or-later WITH no-invariant-sections
2+
3+
.. _media_request_ioc_queue:
4+
5+
*****************************
6+
ioctl MEDIA_REQUEST_IOC_QUEUE
7+
*****************************
8+
9+
Name
10+
====
11+
12+
MEDIA_REQUEST_IOC_QUEUE - Queue a request
13+
14+
15+
Synopsis
16+
========
17+
18+
.. c:function:: int ioctl( int request_fd, MEDIA_REQUEST_IOC_QUEUE )
19+
:name: MEDIA_REQUEST_IOC_QUEUE
20+
21+
22+
Arguments
23+
=========
24+
25+
``request_fd``
26+
File descriptor returned by :ref:`MEDIA_IOC_REQUEST_ALLOC`.
27+
28+
29+
Description
30+
===========
31+
32+
If the media device supports :ref:`requests <media-request-api>`, then
33+
this request ioctl can be used to queue a previously allocated request.
34+
35+
If the request was successfully queued, then the file descriptor can be
36+
:ref:`polled <request-func-poll>` to wait for the request to complete.
37+
38+
If the request was already queued before, then ``EBUSY`` is returned.
39+
Other errors can be returned if the contents of the request contained
40+
invalid or inconsistent data, see the next section for a list of
41+
common error codes. On error both the request and driver state are unchanged.
42+
43+
Once a request is queued, then the driver is required to gracefully handle
44+
errors that occur when the request is applied to the hardware. The
45+
exception is the ``EIO`` error which signals a fatal error that requires
46+
the application to stop streaming to reset the hardware state.
47+
48+
It is not allowed to mix queuing requests with queuing buffers directly
49+
(without a request). ``EBUSY`` will be returned if the first buffer was
50+
queued directly and you next try to queue a request, or vice versa.
51+
52+
A request must contain at least one buffer, otherwise this ioctl will
53+
return an ``ENOENT`` error.
54+
55+
Return Value
56+
============
57+
58+
On success 0 is returned, on error -1 and the ``errno`` variable is set
59+
appropriately. The generic error codes are described at the
60+
:ref:`Generic Error Codes <gen-errors>` chapter.
61+
62+
EBUSY
63+
The request was already queued or the application queued the first
64+
buffer directly, but later attempted to use a request. It is not permitted
65+
to mix the two APIs.
66+
ENOENT
67+
The request did not contain any buffers. All requests are required
68+
to have at least one buffer. This can also be returned if some required
69+
configuration is missing in the request.
70+
ENOMEM
71+
Out of memory when allocating internal data structures for this
72+
request.
73+
EINVAL
74+
The request has invalid data.
75+
EIO
76+
The hardware is in a bad state. To recover, the application needs to
77+
stop streaming to reset the hardware state and then try to restart
78+
streaming.
Lines changed: 51 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,51 @@
1+
.. SPDX-License-Identifier: GPL-2.0 OR GFDL-1.1-or-later WITH no-invariant-sections
2+
3+
.. _media_request_ioc_reinit:
4+
5+
******************************
6+
ioctl MEDIA_REQUEST_IOC_REINIT
7+
******************************
8+
9+
Name
10+
====
11+
12+
MEDIA_REQUEST_IOC_REINIT - Re-initialize a request
13+
14+
15+
Synopsis
16+
========
17+
18+
.. c:function:: int ioctl( int request_fd, MEDIA_REQUEST_IOC_REINIT )
19+
:name: MEDIA_REQUEST_IOC_REINIT
20+
21+
22+
Arguments
23+
=========
24+
25+
``request_fd``
26+
File descriptor returned by :ref:`MEDIA_IOC_REQUEST_ALLOC`.
27+
28+
Description
29+
===========
30+
31+
If the media device supports :ref:`requests <media-request-api>`, then
32+
this request ioctl can be used to re-initialize a previously allocated
33+
request.
34+
35+
Re-initializing a request will clear any existing data from the request.
36+
This avoids having to :ref:`close() <request-func-close>` a completed
37+
request and allocate a new request. Instead the completed request can just
38+
be re-initialized and it is ready to be used again.
39+
40+
A request can only be re-initialized if it either has not been queued
41+
yet, or if it was queued and completed. Otherwise it will set ``errno``
42+
to ``EBUSY``. No other error codes can be returned.
43+
44+
Return Value
45+
============
46+
47+
On success 0 is returned, on error -1 and the ``errno`` variable is set
48+
appropriately.
49+
50+
EBUSY
51+
The request is queued but not yet completed.

0 commit comments

Comments
 (0)