From c4c0a78d459f2e4fcc7c4f3621a34e71ec7970d0 Mon Sep 17 00:00:00 2001 From: Pawel Osciak Date: Wed, 12 Jan 2011 05:57:26 -0300 Subject: [media] Fix mmap() example in the V4L2 API DocBook Correct ioctl return value handling and fix coding style issues. [mchehab@redhat.com: return -1 is OK, according with ioctl manpages. Reverting ioctl changes] Signed-off-by: Pawel Osciak Signed-off-by: Mauro Carvalho Chehab --- Documentation/DocBook/v4l/io.xml | 36 ++++++++++++++++++------------------ 1 file changed, 18 insertions(+), 18 deletions(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/v4l/io.xml b/Documentation/DocBook/v4l/io.xml index d424886beda0..a9750437000c 100644 --- a/Documentation/DocBook/v4l/io.xml +++ b/Documentation/DocBook/v4l/io.xml @@ -141,63 +141,63 @@ struct { } *buffers; unsigned int i; -memset (&reqbuf, 0, sizeof (reqbuf)); +memset(&reqbuf, 0, sizeof(reqbuf)); reqbuf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE; reqbuf.memory = V4L2_MEMORY_MMAP; reqbuf.count = 20; if (-1 == ioctl (fd, &VIDIOC-REQBUFS;, &reqbuf)) { if (errno == EINVAL) - printf ("Video capturing or mmap-streaming is not supported\n"); + printf("Video capturing or mmap-streaming is not supported\n"); else - perror ("VIDIOC_REQBUFS"); + perror("VIDIOC_REQBUFS"); - exit (EXIT_FAILURE); + exit(EXIT_FAILURE); } /* We want at least five buffers. */ if (reqbuf.count < 5) { /* You may need to free the buffers here. */ - printf ("Not enough buffer memory\n"); - exit (EXIT_FAILURE); + printf("Not enough buffer memory\n"); + exit(EXIT_FAILURE); } -buffers = calloc (reqbuf.count, sizeof (*buffers)); -assert (buffers != NULL); +buffers = calloc(reqbuf.count, sizeof(*buffers)); +assert(buffers != NULL); for (i = 0; i < reqbuf.count; i++) { &v4l2-buffer; buffer; - memset (&buffer, 0, sizeof (buffer)); + memset(&buffer, 0, sizeof(buffer)); buffer.type = reqbuf.type; buffer.memory = V4L2_MEMORY_MMAP; buffer.index = i; if (-1 == ioctl (fd, &VIDIOC-QUERYBUF;, &buffer)) { - perror ("VIDIOC_QUERYBUF"); - exit (EXIT_FAILURE); + perror("VIDIOC_QUERYBUF"); + exit(EXIT_FAILURE); } buffers[i].length = buffer.length; /* remember for munmap() */ - buffers[i].start = mmap (NULL, buffer.length, - PROT_READ | PROT_WRITE, /* recommended */ - MAP_SHARED, /* recommended */ - fd, buffer.m.offset); + buffers[i].start = mmap(NULL, buffer.length, + PROT_READ | PROT_WRITE, /* recommended */ + MAP_SHARED, /* recommended */ + fd, buffer.m.offset); if (MAP_FAILED == buffers[i].start) { /* If you do not exit here you should unmap() and free() the buffers mapped so far. */ - perror ("mmap"); - exit (EXIT_FAILURE); + perror("mmap"); + exit(EXIT_FAILURE); } } /* Cleanup. */ for (i = 0; i < reqbuf.count; i++) - munmap (buffers[i].start, buffers[i].length); + munmap(buffers[i].start, buffers[i].length); -- cgit v1.2.3 From 53b5d5749b6fcca37c7ad60cd40feafadd390b70 Mon Sep 17 00:00:00 2001 From: Pawel Osciak Date: Fri, 7 Jan 2011 01:41:33 -0300 Subject: [media] Add multi-planar API documentation Add DocBook documentation for the new multi-planar API extensions to the Video for Linux 2 API DocBook. Signed-off-by: Pawel Osciak Signed-off-by: Mauro Carvalho Chehab --- Documentation/DocBook/media-entities.tmpl | 4 + Documentation/DocBook/v4l/common.xml | 2 + Documentation/DocBook/v4l/compat.xml | 11 ++ Documentation/DocBook/v4l/dev-capture.xml | 13 +- Documentation/DocBook/v4l/dev-output.xml | 13 +- Documentation/DocBook/v4l/func-mmap.xml | 10 +- Documentation/DocBook/v4l/func-munmap.xml | 3 +- Documentation/DocBook/v4l/io.xml | 247 ++++++++++++++++++++++---- Documentation/DocBook/v4l/pixfmt.xml | 116 +++++++++++- Documentation/DocBook/v4l/planar-apis.xml | 81 +++++++++ Documentation/DocBook/v4l/v4l2.xml | 21 ++- Documentation/DocBook/v4l/vidioc-enum-fmt.xml | 2 + Documentation/DocBook/v4l/vidioc-g-fmt.xml | 15 +- Documentation/DocBook/v4l/vidioc-qbuf.xml | 24 ++- Documentation/DocBook/v4l/vidioc-querybuf.xml | 14 +- Documentation/DocBook/v4l/vidioc-querycap.xml | 24 ++- 16 files changed, 530 insertions(+), 70 deletions(-) create mode 100644 Documentation/DocBook/v4l/planar-apis.xml (limited to 'Documentation') diff --git a/Documentation/DocBook/media-entities.tmpl b/Documentation/DocBook/media-entities.tmpl index be34dcbe0d90..74923d745535 100644 --- a/Documentation/DocBook/media-entities.tmpl +++ b/Documentation/DocBook/media-entities.tmpl @@ -129,6 +129,7 @@ v4l2_audioout"> v4l2_bt_timings"> v4l2_buffer"> +v4l2_plane"> v4l2_capability"> v4l2_captureparm"> v4l2_clip"> @@ -167,6 +168,8 @@ v4l2_output"> v4l2_outputparm"> v4l2_pix_format"> +v4l2_pix_format_mplane"> +v4l2_plane_pix_format"> v4l2_queryctrl"> v4l2_querymenu"> v4l2_rect"> @@ -202,6 +205,7 @@ + diff --git a/Documentation/DocBook/v4l/common.xml b/Documentation/DocBook/v4l/common.xml index cea23e1c4fc6..dbab79c215c1 100644 --- a/Documentation/DocBook/v4l/common.xml +++ b/Documentation/DocBook/v4l/common.xml @@ -846,6 +846,8 @@ conversion routine or library for integration into applications. + &sub-planar-apis; +
Image Cropping, Insertion and Scaling diff --git a/Documentation/DocBook/v4l/compat.xml b/Documentation/DocBook/v4l/compat.xml index c9ce61d981f5..223c24c536b7 100644 --- a/Documentation/DocBook/v4l/compat.xml +++ b/Documentation/DocBook/v4l/compat.xml @@ -2353,6 +2353,17 @@ that used it. It was originally scheduled for removal in 2.6.35.
+
+ V4L2 in Linux 2.6.38 + + + Multi-planar API added. Does not affect the compatibility of + current drivers and applications. See + multi-planar API + for details. + + +
Relation of V4L2 to other Linux multimedia APIs diff --git a/Documentation/DocBook/v4l/dev-capture.xml b/Documentation/DocBook/v4l/dev-capture.xml index 32807e43f170..2237c661f26a 100644 --- a/Documentation/DocBook/v4l/dev-capture.xml +++ b/Documentation/DocBook/v4l/dev-capture.xml @@ -18,7 +18,8 @@ files are used for video output devices. Querying Capabilities Devices supporting the video capture interface set the -V4L2_CAP_VIDEO_CAPTURE flag in the +V4L2_CAP_VIDEO_CAPTURE or +V4L2_CAP_VIDEO_CAPTURE_MPLANE flag in the capabilities field of &v4l2-capability; returned by the &VIDIOC-QUERYCAP; ioctl. As secondary device functions they may also support the video overlay @@ -64,9 +65,11 @@ linkend="crop" />. To query the current image format applications set the type field of a &v4l2-format; to -V4L2_BUF_TYPE_VIDEO_CAPTURE and call the +V4L2_BUF_TYPE_VIDEO_CAPTURE or +V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE and call the &VIDIOC-G-FMT; ioctl with a pointer to this structure. Drivers fill -the &v4l2-pix-format; pix member of the +the &v4l2-pix-format; pix or the +&v4l2-pix-format-mplane; pix_mp member of the fmt union. To request different parameters applications set the @@ -84,8 +87,8 @@ adjust the parameters and finally return the actual parameters as without disabling I/O or possibly time consuming hardware preparations. - The contents of &v4l2-pix-format; are discussed in . See also the specification of the + The contents of &v4l2-pix-format; and &v4l2-pix-format-mplane; +are discussed in . See also the specification of the VIDIOC_G_FMT, VIDIOC_S_FMT and VIDIOC_TRY_FMT ioctls for details. Video capture devices must implement both the diff --git a/Documentation/DocBook/v4l/dev-output.xml b/Documentation/DocBook/v4l/dev-output.xml index 63c3c20e5a72..919e22c53854 100644 --- a/Documentation/DocBook/v4l/dev-output.xml +++ b/Documentation/DocBook/v4l/dev-output.xml @@ -17,7 +17,8 @@ files are used for video capture devices. Querying Capabilities Devices supporting the video output interface set the -V4L2_CAP_VIDEO_OUTPUT flag in the +V4L2_CAP_VIDEO_OUTPUT or +V4L2_CAP_VIDEO_OUTPUT_MPLANE flag in the capabilities field of &v4l2-capability; returned by the &VIDIOC-QUERYCAP; ioctl. As secondary device functions they may also support the raw VBI @@ -60,9 +61,11 @@ linkend="crop" />. To query the current image format applications set the type field of a &v4l2-format; to -V4L2_BUF_TYPE_VIDEO_OUTPUT and call the +V4L2_BUF_TYPE_VIDEO_OUTPUT or +V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE and call the &VIDIOC-G-FMT; ioctl with a pointer to this structure. Drivers fill -the &v4l2-pix-format; pix member of the +the &v4l2-pix-format; pix or the +&v4l2-pix-format-mplane; pix_mp member of the fmt union. To request different parameters applications set the @@ -80,8 +83,8 @@ adjust the parameters and finally return the actual parameters as without disabling I/O or possibly time consuming hardware preparations. - The contents of &v4l2-pix-format; are discussed in . See also the specification of the + The contents of &v4l2-pix-format; and &v4l2-pix-format-mplane; +are discussed in . See also the specification of the VIDIOC_G_FMT, VIDIOC_S_FMT and VIDIOC_TRY_FMT ioctls for details. Video output devices must implement both the diff --git a/Documentation/DocBook/v4l/func-mmap.xml b/Documentation/DocBook/v4l/func-mmap.xml index 2e2fc3933aea..786732b64bbd 100644 --- a/Documentation/DocBook/v4l/func-mmap.xml +++ b/Documentation/DocBook/v4l/func-mmap.xml @@ -45,7 +45,10 @@ just specify a NULL pointer here. Length of the memory area to map. This must be the same value as returned by the driver in the &v4l2-buffer; -length field. +length field for the +single-planar API, and the same value as returned by the driver +in the &v4l2-plane; length field for the +multi-planar API. @@ -106,7 +109,10 @@ flag. Offset of the buffer in device memory. This must be the same value as returned by the driver in the &v4l2-buffer; -m union offset field. +m union offset field for +the single-planar API, and the same value as returned by the driver +in the &v4l2-plane; m union +mem_offset field for the multi-planar API. diff --git a/Documentation/DocBook/v4l/func-munmap.xml b/Documentation/DocBook/v4l/func-munmap.xml index 502ed49323b0..e2c4190f9bb6 100644 --- a/Documentation/DocBook/v4l/func-munmap.xml +++ b/Documentation/DocBook/v4l/func-munmap.xml @@ -37,7 +37,8 @@ Length of the mapped buffer. This must be the same value as given to mmap() and returned by the driver in the &v4l2-buffer; length -field. +field for the single-planar API and in the &v4l2-plane; +length field for the multi-planar API. diff --git a/Documentation/DocBook/v4l/io.xml b/Documentation/DocBook/v4l/io.xml index a9750437000c..227e7ac45a06 100644 --- a/Documentation/DocBook/v4l/io.xml +++ b/Documentation/DocBook/v4l/io.xml @@ -121,18 +121,22 @@ mapped. Before applications can access the buffers they must map them into their address space with the &func-mmap; function. The location of the buffers in device memory can be determined with the -&VIDIOC-QUERYBUF; ioctl. The m.offset and -length returned in a &v4l2-buffer; are -passed as sixth and second parameter to the -mmap() function. The offset and length values -must not be modified. Remember the buffers are allocated in physical -memory, as opposed to virtual memory which can be swapped out to disk. -Applications should free the buffers as soon as possible with the -&func-munmap; function. +&VIDIOC-QUERYBUF; ioctl. In the single-planar API case, the +m.offset and length +returned in a &v4l2-buffer; are passed as sixth and second parameter to the +mmap() function. When using the multi-planar API, +struct &v4l2-buffer; contains an array of &v4l2-plane; structures, each +containing its own m.offset and +length. When using the multi-planar API, every +plane of every buffer has to be mapped separately, so the number of +calls to &func-mmap; should be equal to number of buffers times number of +planes in each buffer. The offset and length values must not be modified. +Remember, the buffers are allocated in physical memory, as opposed to virtual +memory, which can be swapped out to disk. Applications should free the buffers +as soon as possible with the &func-munmap; function. - Mapping buffers - + Mapping buffers in the single-planar API &v4l2-requestbuffers; reqbuf; struct { @@ -201,6 +205,88 @@ for (i = 0; i < reqbuf.count; i++) + + Mapping buffers in the multi-planar API + +&v4l2-requestbuffers; reqbuf; +/* Our current format uses 3 planes per buffer */ +#define FMT_NUM_PLANES = 3; + +struct { + void *start[FMT_NUM_PLANES]; + size_t length[FMT_NUM_PLANES]; +} *buffers; +unsigned int i, j; + +memset(&reqbuf, 0, sizeof(reqbuf)); +reqbuf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE; +reqbuf.memory = V4L2_MEMORY_MMAP; +reqbuf.count = 20; + +if (ioctl(fd, &VIDIOC-REQBUFS;, &reqbuf) < 0) { + if (errno == EINVAL) + printf("Video capturing or mmap-streaming is not supported\n"); + else + perror("VIDIOC_REQBUFS"); + + exit(EXIT_FAILURE); +} + +/* We want at least five buffers. */ + +if (reqbuf.count < 5) { + /* You may need to free the buffers here. */ + printf("Not enough buffer memory\n"); + exit(EXIT_FAILURE); +} + +buffers = calloc(reqbuf.count, sizeof(*buffers)); +assert(buffers != NULL); + +for (i = 0; i < reqbuf.count; i++) { + &v4l2-buffer; buffer; + &v4l2-plane; planes[FMT_NUM_PLANES]; + + memset(&buffer, 0, sizeof(buffer)); + buffer.type = reqbuf.type; + buffer.memory = V4L2_MEMORY_MMAP; + buffer.index = i; + /* length in struct v4l2_buffer in multi-planar API stores the size + * of planes array. */ + buffer.length = FMT_NUM_PLANES; + buffer.m.planes = planes; + + if (ioctl(fd, &VIDIOC-QUERYBUF;, &buffer) < 0) { + perror("VIDIOC_QUERYBUF"); + exit(EXIT_FAILURE); + } + + /* Every plane has to be mapped separately */ + for (j = 0; j < FMT_NUM_PLANES; j++) { + buffers[i].length[j] = buffer.m.planes[j].length; /* remember for munmap() */ + + buffers[i].start[j] = mmap(NULL, buffer.m.planes[j].length, + PROT_READ | PROT_WRITE, /* recommended */ + MAP_SHARED, /* recommended */ + fd, buffer.m.planes[j].m.offset); + + if (MAP_FAILED == buffers[i].start[j]) { + /* If you do not exit here you should unmap() and free() + the buffers and planes mapped so far. */ + perror("mmap"); + exit(EXIT_FAILURE); + } + } +} + +/* Cleanup. */ + +for (i = 0; i < reqbuf.count; i++) + for (j = 0; j < FMT_NUM_PLANES; j++) + munmap(buffers[i].start[j], buffers[i].length[j]); + + + Conceptually streaming drivers maintain two buffer queues, an incoming and an outgoing queue. They separate the synchronous capture or output operation locked to a video clock from the application which is @@ -286,13 +372,13 @@ pointer method (not only memory mapping) is supported must be determined by calling the &VIDIOC-REQBUFS; ioctl. This I/O method combines advantages of the read/write and -memory mapping methods. Buffers are allocated by the application +memory mapping methods. Buffers (planes) are allocated by the application itself, and can reside for example in virtual or shared memory. Only pointers to data are exchanged, these pointers and meta-information -are passed in &v4l2-buffer;. The driver must be switched -into user pointer I/O mode by calling the &VIDIOC-REQBUFS; with the -desired buffer type. No buffers are allocated beforehands, -consequently they are not indexed and cannot be queried like mapped +are passed in &v4l2-buffer; (or in &v4l2-plane; in the multi-planar API case). +The driver must be switched into user pointer I/O mode by calling the +&VIDIOC-REQBUFS; with the desired buffer type. No buffers (planes) are allocated +beforehand, consequently they are not indexed and cannot be queried like mapped buffers with the VIDIOC_QUERYBUF ioctl. @@ -316,7 +402,7 @@ if (ioctl (fd, &VIDIOC-REQBUFS;, &reqbuf) == -1) { - Buffer addresses and sizes are passed on the fly with the + Buffer (plane) addresses and sizes are passed on the fly with the &VIDIOC-QBUF; ioctl. Although buffers are commonly cycled, applications can pass different addresses and sizes at each VIDIOC_QBUF call. If required by the hardware the @@ -396,11 +482,18 @@ rest should be evident. Buffers A buffer contains data exchanged by application and -driver using one of the Streaming I/O methods. Only pointers to -buffers are exchanged, the data itself is not copied. These pointers, -together with meta-information like timestamps or field parity, are -stored in a struct v4l2_buffer, argument to -the &VIDIOC-QUERYBUF;, &VIDIOC-QBUF; and &VIDIOC-DQBUF; ioctl. +driver using one of the Streaming I/O methods. In the multi-planar API, the +data is held in planes, while the buffer structure acts as a container +for the planes. Only pointers to buffers (planes) are exchanged, the data +itself is not copied. These pointers, together with meta-information like +timestamps or field parity, are stored in a struct +v4l2_buffer, argument to +the &VIDIOC-QUERYBUF;, &VIDIOC-QBUF; and &VIDIOC-DQBUF; ioctl. +In the multi-planar API, some plane-specific members of struct +v4l2_buffer, such as pointers and sizes for each +plane, are stored in struct v4l2_plane instead. +In that case, struct v4l2_buffer contains an array of +plane structures. Nominally timestamps refer to the first data byte transmitted. In practice however the wide range of hardware covered by the V4L2 API @@ -551,26 +644,40 @@ in accordance with the selected I/O method. __u32 offset - When memory is -V4L2_MEMORY_MMAP this is the offset of the buffer -from the start of the device memory. The value is returned by the -driver and apart of serving as parameter to the &func-mmap; function -not useful for applications. See for details. + For the single-planar API and when +memory is V4L2_MEMORY_MMAP this +is the offset of the buffer from the start of the device memory. The value is +returned by the driver and apart of serving as parameter to the &func-mmap; +function not useful for applications. See for details + unsigned long userptr - When memory is -V4L2_MEMORY_USERPTR this is a pointer to the -buffer (casted to unsigned long type) in virtual memory, set by the -application. See for details. + For the single-planar API and when +memory is V4L2_MEMORY_USERPTR +this is a pointer to the buffer (casted to unsigned long type) in virtual +memory, set by the application. See for details. + + + + + struct v4l2_plane + *planes + When using the multi-planar API, contains a userspace pointer + to an array of &v4l2-plane;. The size of the array should be put + in the length field of this + v4l2_buffer structure. __u32 length - Size of the buffer (not the payload) in bytes. + Size of the buffer (not the payload) in bytes for the + single-planar API. For the multi-planar API should contain the + number of elements in the planes array. + __u32 @@ -596,6 +703,66 @@ should set this to 0. + + struct <structname>v4l2_plane</structname> + + &cs-ustr; + + + __u32 + bytesused + + The number of bytes occupied by data in the plane + (its payload). + + + __u32 + length + + Size in bytes of the plane (not its payload). + + + union + m + + + + + + __u32 + mem_offset + When the memory type in the containing &v4l2-buffer; is + V4L2_MEMORY_MMAP, this is the value that + should be passed to &func-mmap;, similar to the + offset field in &v4l2-buffer;. + + + + __unsigned long + userptr + When the memory type in the containing &v4l2-buffer; is + V4L2_MEMORY_USERPTR, this is a userspace + pointer to the memory allocated for this plane by an application. + + + + __u32 + data_offset + + Offset in bytes to video data in the plane, if applicable. + + + + __u32 + reserved[11] + + Reserved for future use. Should be zeroed by an + application. + + + +
+ enum v4l2_buf_type @@ -604,13 +771,27 @@ should set this to 0. V4L2_BUF_TYPE_VIDEO_CAPTURE 1 - Buffer of a video capture stream, see Buffer of a single-planar video capture stream, see . + + + V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE + + 9 + Buffer of a multi-planar video capture stream, see . V4L2_BUF_TYPE_VIDEO_OUTPUT 2 - Buffer of a video output stream, see Buffer of a single-planar video output stream, see . + + + V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE + + 10 + Buffer of a multi-planar video output stream, see . diff --git a/Documentation/DocBook/v4l/pixfmt.xml b/Documentation/DocBook/v4l/pixfmt.xml index cfffc88d7383..28f9c700f752 100644 --- a/Documentation/DocBook/v4l/pixfmt.xml +++ b/Documentation/DocBook/v4l/pixfmt.xml @@ -2,12 +2,16 @@ The V4L2 API was primarily designed for devices exchanging image data with applications. The -v4l2_pix_format structure defines the format -and layout of an image in memory. Image formats are negotiated with -the &VIDIOC-S-FMT; ioctl. (The explanations here focus on video +v4l2_pix_format and v4l2_pix_format_mplane + structures define the format and layout of an image in memory. +The former is used with the single-planar API, while the latter is used with the +multi-planar version (see ). Image formats are +negotiated with the &VIDIOC-S-FMT; ioctl. (The explanations here focus on video capturing and output, for overlay frame buffer formats see also &VIDIOC-G-FBUF;.) +
+ Single-planar format structure
struct <structname>v4l2_pix_format</structname> @@ -106,6 +110,98 @@ set this field to zero.
+
+ +
+ Multi-planar format structures + The v4l2_plane_pix_format structures define + size and layout for each of the planes in a multi-planar format. + The v4l2_pix_format_mplane structure contains + information common to all planes (such as image width and height) and + an array of v4l2_plane_pix_format structures, + describing all planes of that format. + + struct <structname>vl42_plane_pix_format</structname> + + &cs-str; + + + __u32 + sizeimage + Maximum size in bytes required for image data in this plane. + + + + __u16 + bytesperline + Distance in bytes between the leftmost pixels in two adjacent + lines. + + + __u16 + reserved[7] + Reserved for future extensions. Should be zeroed by the + application. + + + +
+ + struct <structname>v4l2_pix_format_mplane</structname> + + &cs-str; + + + __u32 + width + Image width in pixels. + + + __u32 + height + Image height in pixels. + + + __u32 + pixelformat + The pixel format. Both single- and multi-planar four character +codes can be used. + + + &v4l2-field; + field + See &v4l2-pix-format;. + + + &v4l2-colorspace; + colorspace + See &v4l2-pix-format;. + + + &v4l2-plane-pix-format; + plane_fmt[VIDEO_MAX_PLANES] + An array of structures describing format of each plane this + pixel format consists of. The number of valid entries in this array + has to be put in the num_planes + field. + + + __u8 + num_planes + Number of planes (i.e. separate memory buffers) for this format + and the number of valid entries in the + plane_fmt array. + + + __u8 + reserved[11] + Reserved for future extensions. Should be zeroed by the + application. + + + +
+
Standard Image Formats @@ -142,11 +238,19 @@ leftmost pixel of the second row from the top, and so on. The last row has just as many pad bytes after it as the other rows. In V4L2 each format has an identifier which looks like -PIX_FMT_XXX, defined in the videodev2.h -header file. These identifiers -represent four character codes +PIX_FMT_XXX, defined in the videodev.h header file. These identifiers +represent four character (FourCC) codes which are also listed below, however they are not the same as those used in the Windows world. + + For some formats, data is stored in separate, discontiguous +memory buffers. Those formats are identified by a separate set of FourCC codes +and are referred to as "multi-planar formats". For example, a YUV422 frame is +normally stored in one memory buffer, but it can also be placed in two or three +separate buffers, with Y component in one buffer and CbCr components in another +in the 2-planar version or with each component in its own buffer in the +3-planar case. Those sub-buffers are referred to as "planes".
diff --git a/Documentation/DocBook/v4l/planar-apis.xml b/Documentation/DocBook/v4l/planar-apis.xml new file mode 100644 index 000000000000..8be7552b37de --- /dev/null +++ b/Documentation/DocBook/v4l/planar-apis.xml @@ -0,0 +1,81 @@ +
+ Single- and multi-planar APIs + + Some devices require data for each input or output video frame + to be placed in discontiguous memory buffers. In such cases one + video frame has to be addressed using more than one memory address, i.e. one + pointer per "plane". A plane is a sub-buffer of current frame. For examples + of such formats see . + + Initially, V4L2 API did not support multi-planar buffers and a set of + extensions has been introduced to handle them. Those extensions constitute + what is being referred to as the "multi-planar API". + + Some of the V4L2 API calls and structures are interpreted differently, + depending on whether single- or multi-planar API is being used. An application + can choose whether to use one or the other by passing a corresponding buffer + type to its ioctl calls. Multi-planar versions of buffer types are suffixed with + an `_MPLANE' string. For a list of available multi-planar buffer types + see &v4l2-buf-type;. + + +
+ Multi-planar formats + Multi-planar API introduces new multi-planar formats. Those formats + use a separate set of FourCC codes. It is important to distinguish between + the multi-planar API and a multi-planar format. Multi-planar API calls can + handle all single-planar formats as well, while the single-planar API cannot + handle multi-planar formats. Applications do not have to switch between APIs + when handling both single- and multi-planar devices and should use the + multi-planar API version for both single- and multi-planar formats. + Drivers that do not support multi-planar API can still be handled with it, + utilizing a compatibility layer built into standard V4L2 ioctl handling. + +
+ +
+ Single and multi-planar API compatibility layer + In most casesThe compatibility layer does not cover + drivers that do not use video_ioctl2() call., applications + can use the multi-planar API with older drivers that support + only its single-planar version and vice versa. Appropriate conversion is + done seamlessly for both applications and drivers in the V4L2 core. The + general rule of thumb is: as long as an application uses formats that + a driver supports, it can use either API (although use of multi-planar + formats is only possible with the multi-planar API). The list of formats + supported by a driver can be obtained using the &VIDIOC-ENUM-FMT; call. + It is possible, but discouraged, for a driver or an application to support + and use both versions of the API. +
+ +
+ Calls that distinguish between single and multi-planar APIs + + + &VIDIOC-QUERYCAP; + Two additional multi-planar capabilities are added. They can + be set together with non-multi-planar ones for devices that handle + both single- and multi-planar formats. + + + &VIDIOC-G-FMT;, &VIDIOC-S-FMT;, &VIDIOC-TRY-FMT; + New structures for describing multi-planar formats are added: + &v4l2-pix-format-mplane; and &v4l2-plane-pix-format;. Drivers may + define new multi-planar formats, which have distinct FourCC codes from + the existing single-planar ones. + + + + &VIDIOC-QBUF;, &VIDIOC-DQBUF;, &VIDIOC-QUERYBUF; + A new &v4l2-plane; structure for describing planes is added. + Arrays of this structure are passed in the new + m.planes field of &v4l2-buffer;. + + + + &VIDIOC-REQBUFS; + Will allocate multi-planar buffers as requested. + + +
+
diff --git a/Documentation/DocBook/v4l/v4l2.xml b/Documentation/DocBook/v4l/v4l2.xml index 9288af96de34..9c7a1751ba1e 100644 --- a/Documentation/DocBook/v4l/v4l2.xml +++ b/Documentation/DocBook/v4l/v4l2.xml @@ -85,6 +85,17 @@ Remote Controller chapter. + + + Pawel + Osciak + Designed and documented the multi-planar API. + +
+ pawel AT osciak.com +
+ + @@ -102,7 +113,8 @@ Remote Controller chapter. 2010 2011 Bill Dirks, Michael H. Schimek, Hans Verkuil, Martin -Rubli, Andy Walls, Muralidharan Karicheri, Mauro Carvalho Chehab +Rubli, Andy Walls, Muralidharan Karicheri, Mauro Carvalho Chehab, + Pawel Osciak Except when explicitly stated as GPL, programming examples within @@ -115,6 +127,13 @@ structs, ioctls) must be noted in more detail in the history chapter (compat.xml), along with the possible impact on existing drivers and applications. --> + + 2.6.38 + po + Added the multi-planar API. + + + 2.6.37 2010-08-06 diff --git a/Documentation/DocBook/v4l/vidioc-enum-fmt.xml b/Documentation/DocBook/v4l/vidioc-enum-fmt.xml index 960d44615ca6..71d373b6d36a 100644 --- a/Documentation/DocBook/v4l/vidioc-enum-fmt.xml +++ b/Documentation/DocBook/v4l/vidioc-enum-fmt.xml @@ -76,7 +76,9 @@ pixelformat field. Type of the data stream, set by the application. Only these types are valid here: V4L2_BUF_TYPE_VIDEO_CAPTURE, +V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE, V4L2_BUF_TYPE_VIDEO_OUTPUT, +V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE, V4L2_BUF_TYPE_VIDEO_OVERLAY, and custom (driver defined) types with code V4L2_BUF_TYPE_PRIVATE and higher. diff --git a/Documentation/DocBook/v4l/vidioc-g-fmt.xml b/Documentation/DocBook/v4l/vidioc-g-fmt.xml index 7c7d1b72c40d..a4ae59b664eb 100644 --- a/Documentation/DocBook/v4l/vidioc-g-fmt.xml +++ b/Documentation/DocBook/v4l/vidioc-g-fmt.xml @@ -60,11 +60,13 @@ application. type field of a struct v4l2_format to the respective buffer (stream) type. For example video capture devices use -V4L2_BUF_TYPE_VIDEO_CAPTURE. When the application +V4L2_BUF_TYPE_VIDEO_CAPTURE or +V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE. When the application calls the VIDIOC_G_FMT ioctl with a pointer to this structure the driver fills the respective member of the fmt union. In case of video capture devices -that is the &v4l2-pix-format; pix member. +that is either the &v4l2-pix-format; pix or +the &v4l2-pix-format-mplane; pix_mp member. When the requested buffer type is not supported drivers return an &EINVAL;. @@ -131,6 +133,15 @@ this ioctl. Definition of an image format, see , used by video capture and output devices. + + + + &v4l2-pix-format-mplane; + pix_mp + Definition of an image format, see , used by video capture and output +devices that support the multi-planar +version of the API. diff --git a/Documentation/DocBook/v4l/vidioc-qbuf.xml b/Documentation/DocBook/v4l/vidioc-qbuf.xml index ab691ebf3b93..f2b11f8a4031 100644 --- a/Documentation/DocBook/v4l/vidioc-qbuf.xml +++ b/Documentation/DocBook/v4l/vidioc-qbuf.xml @@ -64,7 +64,8 @@ zero to the number of buffers allocated with &VIDIOC-REQBUFS; contents of the struct v4l2_buffer returned by a &VIDIOC-QUERYBUF; ioctl will do as well. When the buffer is intended for output (type is -V4L2_BUF_TYPE_VIDEO_OUTPUT or +V4L2_BUF_TYPE_VIDEO_OUTPUT, +V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE, or V4L2_BUF_TYPE_VBI_OUTPUT) applications must also initialize the bytesused, field and @@ -75,7 +76,11 @@ supports capturing from specific video inputs and you want to specify a video input, then flags should be set to V4L2_BUF_FLAG_INPUT and the field input must be initialized to the desired input. -The reserved field must be set to 0. +The reserved field must be set to 0. When using +the multi-planar API, the +m.planes field must contain a userspace pointer +to a filled-in array of &v4l2-plane; and the length +field must be set to the number of elements in that array. To enqueue a memory mapped @@ -93,10 +98,13 @@ structure the driver sets the buffer applications set the memory field to V4L2_MEMORY_USERPTR, the m.userptr field to the address of the -buffer and length to its size. -When VIDIOC_QBUF is called with a pointer to this -structure the driver sets the V4L2_BUF_FLAG_QUEUED -flag and clears the V4L2_BUF_FLAG_MAPPED and +buffer and length to its size. When the multi-planar +API is used, m.userptr and +length members of the passed array of &v4l2-plane; +have to be used instead. When VIDIOC_QBUF is called with +a pointer to this structure the driver sets the +V4L2_BUF_FLAG_QUEUED flag and clears the +V4L2_BUF_FLAG_MAPPED and V4L2_BUF_FLAG_DONE flags in the flags field, or it returns an error code. This ioctl locks the memory pages of the buffer in physical memory, @@ -115,7 +123,9 @@ remaining fields or returns an error code. The driver may also set V4L2_BUF_FLAG_ERROR in the flags field. It indicates a non-critical (recoverable) streaming error. In such case the application may continue as normal, but should be aware that data in the -dequeued buffer might be corrupted. +dequeued buffer might be corrupted. When using the multi-planar API, the +planes array does not have to be passed; the m.planes +member must be set to NULL in that case. By default VIDIOC_DQBUF blocks when no buffer is in the outgoing queue. When the diff --git a/Documentation/DocBook/v4l/vidioc-querybuf.xml b/Documentation/DocBook/v4l/vidioc-querybuf.xml index e649805a4908..5c104d42d31c 100644 --- a/Documentation/DocBook/v4l/vidioc-querybuf.xml +++ b/Documentation/DocBook/v4l/vidioc-querybuf.xml @@ -61,6 +61,10 @@ buffer at any time after buffers have been allocated with the to the number of buffers allocated with &VIDIOC-REQBUFS; (&v4l2-requestbuffers; count) minus one. The reserved field should to set to 0. +When using the multi-planar API, the +m.planes field must contain a userspace pointer to an +array of &v4l2-plane; and the length field has +to be set to the number of elements in that array. After calling VIDIOC_QUERYBUF with a pointer to this structure drivers return an error code or fill the rest of the structure. @@ -70,11 +74,13 @@ the structure. V4L2_BUF_FLAG_QUEUED and V4L2_BUF_FLAG_DONE flags will be valid. The memory field will be set to the current -I/O method, the m.offset +I/O method. For the single-planar API, the m.offset contains the offset of the buffer from the start of the device memory, -the length field its size. The driver may -or may not set the remaining fields and flags, they are meaningless in -this context. +the length field its size. For the multi-planar API, +fields m.mem_offset and +length in the m.planes +array elements will be used instead. The driver may or may not set the remaining +fields and flags, they are meaningless in this context. The v4l2_buffer structure is specified in . diff --git a/Documentation/DocBook/v4l/vidioc-querycap.xml b/Documentation/DocBook/v4l/vidioc-querycap.xml index d499da93a450..93699769cd07 100644 --- a/Documentation/DocBook/v4l/vidioc-querycap.xml +++ b/Documentation/DocBook/v4l/vidioc-querycap.xml @@ -142,14 +142,30 @@ this array to zero. V4L2_CAP_VIDEO_CAPTURE 0x00000001 - The device supports the Video Capture interface. + The device supports single-planar formats through the Video Capture interface. An application can use either +the single or the multi-planar API. + + + V4L2_CAP_VIDEO_CAPTURE_MPLANE + 0x00001000 + The device supports multi-planar formats through the Video Capture interface. An application has to use the +multi-planar API. V4L2_CAP_VIDEO_OUTPUT 0x00000002 - The device supports the Video Output interface. + The device supports single-planar formats through the Video Output interface. An application can use either +the single or the multi-planar API. + + + V4L2_CAP_VIDEO_OUTPUT_MPLANE + 0x00002000 + The device supports multi-planar formats through the Video Output interface. An application has to use the +multi-planar API. V4L2_CAP_VIDEO_OVERLAY -- cgit v1.2.3 From 269da4027c9a3466150308a9fe5f2a3a58336cd8 Mon Sep 17 00:00:00 2001 From: Sylwester Nawrocki Date: Sun, 9 Jan 2011 09:01:10 -0300 Subject: [media] v4l: Add DocBook documentation for YU12M, NV12M image formats Signed-off-by: Sylwester Nawrocki Signed-off-by: Mauro Carvalho Chehab --- Documentation/DocBook/media-entities.tmpl | 4 + Documentation/DocBook/v4l/pixfmt-nv12m.xml | 154 +++++++++++++++++++++++++ Documentation/DocBook/v4l/pixfmt-yuv420m.xml | 162 +++++++++++++++++++++++++++ Documentation/DocBook/v4l/pixfmt.xml | 2 + 4 files changed, 322 insertions(+) create mode 100644 Documentation/DocBook/v4l/pixfmt-nv12m.xml create mode 100644 Documentation/DocBook/v4l/pixfmt-yuv420m.xml (limited to 'Documentation') diff --git a/Documentation/DocBook/media-entities.tmpl b/Documentation/DocBook/media-entities.tmpl index 74923d745535..d2f99e5a3a2f 100644 --- a/Documentation/DocBook/media-entities.tmpl +++ b/Documentation/DocBook/media-entities.tmpl @@ -237,6 +237,7 @@ + @@ -251,6 +252,7 @@ + @@ -337,6 +339,7 @@ + @@ -351,6 +354,7 @@ + diff --git a/Documentation/DocBook/v4l/pixfmt-nv12m.xml b/Documentation/DocBook/v4l/pixfmt-nv12m.xml new file mode 100644 index 000000000000..c9e166d9ded8 --- /dev/null +++ b/Documentation/DocBook/v4l/pixfmt-nv12m.xml @@ -0,0 +1,154 @@ + + + V4L2_PIX_FMT_NV12M ('NV12M') + &manvol; + + + V4L2_PIX_FMT_NV12M + Variation of V4L2_PIX_FMT_NV12 with planes + non contiguous in memory. + + + Description + + This is a multi-planar, two-plane version of the YUV 4:2:0 format. +The three components are separated into two sub-images or planes. +V4L2_PIX_FMT_NV12M differs from V4L2_PIX_FMT_NV12 + in that the two planes are non-contiguous in memory, i.e. the chroma +plane do not necessarily immediately follows the luma plane. +The luminance data occupies the first plane. The Y plane has one byte per pixel. +In the second plane there is a chrominance data with alternating chroma samples. +The CbCr plane is the same width, in bytes, as the Y plane (and of the image), +but is half as tall in pixels. Each CbCr pair belongs to four pixels. For example, +Cb0/Cr0 belongs to +Y'00, Y'01, +Y'10, Y'11. + + V4L2_PIX_FMT_NV12M is intended to be +used only in drivers and applications that support the multi-planar API, +described in . + + If the Y plane has pad bytes after each row, then the +CbCr plane has as many pad bytes after its rows. + + + <constant>V4L2_PIX_FMT_NV12M</constant> 4 × 4 pixel image + + + Byte Order. + Each cell is one byte. + + + + + + start0 + 0: + Y'00 + Y'01 + Y'02 + Y'03 + + + start0 + 4: + Y'10 + Y'11 + Y'12 + Y'13 + + + start0 + 8: + Y'20 + Y'21 + Y'22 + Y'23 + + + start0 + 12: + Y'30 + Y'31 + Y'32 + Y'33 + + + + + + start1 + 0: + Cb00 + Cr00 + Cb01 + Cr01 + + + start1 + 4: + Cb10 + Cr10 + Cb11 + Cr11 + + + + + + + + + Color Sample Location. + + + + + + + 01 + 23 + + + 0 + YY + YY + + + + C + C + + + 1 + YY + YY + + + + + + 2 + YY + YY + + + + C + C + + + 3 + YY + YY + + + + + + + + + + + diff --git a/Documentation/DocBook/v4l/pixfmt-yuv420m.xml b/Documentation/DocBook/v4l/pixfmt-yuv420m.xml new file mode 100644 index 000000000000..f5d8f57495c8 --- /dev/null +++ b/Documentation/DocBook/v4l/pixfmt-yuv420m.xml @@ -0,0 +1,162 @@ + + + V4L2_PIX_FMT_YUV420M ('YU12M') + &manvol; + + + V4L2_PIX_FMT_YUV420M + Variation of V4L2_PIX_FMT_YUV420 + with planes non contiguous in memory. + + + + Description + + This is a multi-planar format, as opposed to a packed format. +The three components are separated into three sub- images or planes. + +The Y plane is first. The Y plane has one byte per pixel. The Cb data +constitutes the second plane which is half the width and half +the height of the Y plane (and of the image). Each Cb belongs to four +pixels, a two-by-two square of the image. For example, +Cb0 belongs to Y'00, +Y'01, Y'10, and +Y'11. The Cr data, just like the Cb plane, is +in the third plane. + + If the Y plane has pad bytes after each row, then the Cb +and Cr planes have half as many pad bytes after their rows. In other +words, two Cx rows (including padding) is exactly as long as one Y row +(including padding). + + V4L2_PIX_FMT_NV12M is intended to be +used only in drivers and applications that support the multi-planar API, +described in . + + + <constant>V4L2_PIX_FMT_YVU420M</constant> 4 × 4 +pixel image + + + Byte Order. + Each cell is one byte. + + + + + + start0 + 0: + Y'00 + Y'01 + Y'02 + Y'03 + + + start0 + 4: + Y'10 + Y'11 + Y'12 + Y'13 + + + start0 + 8: + Y'20 + Y'21 + Y'22 + Y'23 + + + start0 + 12: + Y'30 + Y'31 + Y'32 + Y'33 + + + + start1 + 0: + Cb00 + Cb01 + + + start1 + 2: + Cb10 + Cb11 + + + + start2 + 0: + Cr00 + Cr01 + + + start2 + 2: + Cr10 + Cr11 + + + + + + + + + Color Sample Location. + + + + + + + 01 + 23 + + + 0 + YY + YY + + + + C + C + + + 1 + YY + YY + + + + + + 2 + YY + YY + + + + C + C + + + 3 + YY + YY + + + + + + + + + + + diff --git a/Documentation/DocBook/v4l/pixfmt.xml b/Documentation/DocBook/v4l/pixfmt.xml index 28f9c700f752..f8436dcb7414 100644 --- a/Documentation/DocBook/v4l/pixfmt.xml +++ b/Documentation/DocBook/v4l/pixfmt.xml @@ -703,10 +703,12 @@ information. &sub-vyuy; &sub-y41p; &sub-yuv420; + &sub-yuv420m; &sub-yuv410; &sub-yuv422p; &sub-yuv411p; &sub-nv12; + &sub-nv12m; &sub-nv16;
-- cgit v1.2.3 From f33de4aa24646b445f4dd52ebd57e322730644b2 Mon Sep 17 00:00:00 2001 From: Oliver Endriss Date: Mon, 10 Jan 2011 06:36:19 -0300 Subject: [media] get_dvb_firmware: ngene_18.fw added Add download link for ngene firmware rev 18. Signed-off-by: Oliver Endriss Signed-off-by: Mauro Carvalho Chehab --- Documentation/dvb/get_dvb_firmware | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/dvb/get_dvb_firmware b/Documentation/dvb/get_dvb_firmware index 59690de8ebfe..3348d313fbe0 100644 --- a/Documentation/dvb/get_dvb_firmware +++ b/Documentation/dvb/get_dvb_firmware @@ -556,6 +556,9 @@ sub ngene { my $hash1 = "d798d5a757121174f0dbc5f2833c0c85"; my $file2 = "ngene_17.fw"; my $hash2 = "26b687136e127b8ac24b81e0eeafc20b"; + my $url2 = "http://l4m-daten.de/downloads/firmware/dvb-s2/linux/all/"; + my $file3 = "ngene_18.fw"; + my $hash3 = "ebce3ea769a53e3e0b0197c3b3f127e3"; checkstandard(); @@ -565,7 +568,10 @@ sub ngene { wgetfile($file2, $url . $file2); verify($file2, $hash2); - "$file1, $file2"; + wgetfile($file3, $url2 . $file3); + verify($file3, $hash3); + + "$file1, $file2, $file3"; } sub az6027{ -- cgit v1.2.3 From db4d56835e07ec793f143431170ba2fc17bf0191 Mon Sep 17 00:00:00 2001 From: Hans Verkuil Date: Sun, 16 Jan 2011 17:21:02 -0300 Subject: [media] DocBook/v4l: fix validation errors Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- Documentation/DocBook/v4l/planar-apis.xml | 14 +++++++------- Documentation/DocBook/v4l/v4l2.xml | 1 + 2 files changed, 8 insertions(+), 7 deletions(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/v4l/planar-apis.xml b/Documentation/DocBook/v4l/planar-apis.xml index 8be7552b37de..7f3f5527057e 100644 --- a/Documentation/DocBook/v4l/planar-apis.xml +++ b/Documentation/DocBook/v4l/planar-apis.xml @@ -53,28 +53,28 @@ &VIDIOC-QUERYCAP; - Two additional multi-planar capabilities are added. They can + Two additional multi-planar capabilities are added. They can be set together with non-multi-planar ones for devices that handle - both single- and multi-planar formats. + both single- and multi-planar formats. &VIDIOC-G-FMT;, &VIDIOC-S-FMT;, &VIDIOC-TRY-FMT; - New structures for describing multi-planar formats are added: + New structures for describing multi-planar formats are added: &v4l2-pix-format-mplane; and &v4l2-plane-pix-format;. Drivers may define new multi-planar formats, which have distinct FourCC codes from - the existing single-planar ones. + the existing single-planar ones. &VIDIOC-QBUF;, &VIDIOC-DQBUF;, &VIDIOC-QUERYBUF; - A new &v4l2-plane; structure for describing planes is added. + A new &v4l2-plane; structure for describing planes is added. Arrays of this structure are passed in the new - m.planes field of &v4l2-buffer;. + m.planes field of &v4l2-buffer;. &VIDIOC-REQBUFS; - Will allocate multi-planar buffers as requested. + Will allocate multi-planar buffers as requested. diff --git a/Documentation/DocBook/v4l/v4l2.xml b/Documentation/DocBook/v4l/v4l2.xml index 9c7a1751ba1e..c3d699173c17 100644 --- a/Documentation/DocBook/v4l/v4l2.xml +++ b/Documentation/DocBook/v4l/v4l2.xml @@ -129,6 +129,7 @@ applications. --> 2.6.38 + 2011-01-16 po Added the multi-planar API. -- cgit v1.2.3 From d39155d91d034e2b2c9154892e29c8a8eb193b7f Mon Sep 17 00:00:00 2001 From: Pawel Osciak Date: Sun, 16 Jan 2011 13:53:31 -0300 Subject: [media] Remove compatibility layer from multi-planar API documentation This feature will probably be moved to libv4l2. Signed-off-by: Pawel Osciak Signed-off-by: Mauro Carvalho Chehab --- Documentation/DocBook/v4l/planar-apis.xml | 35 ++++++--------------------- Documentation/DocBook/v4l/vidioc-querycap.xml | 22 ++++++++--------- 2 files changed, 18 insertions(+), 39 deletions(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/v4l/planar-apis.xml b/Documentation/DocBook/v4l/planar-apis.xml index 7f3f5527057e..878ce2040488 100644 --- a/Documentation/DocBook/v4l/planar-apis.xml +++ b/Documentation/DocBook/v4l/planar-apis.xml @@ -2,10 +2,10 @@ Single- and multi-planar APIs Some devices require data for each input or output video frame - to be placed in discontiguous memory buffers. In such cases one + to be placed in discontiguous memory buffers. In such cases, one video frame has to be addressed using more than one memory address, i.e. one - pointer per "plane". A plane is a sub-buffer of current frame. For examples - of such formats see . + pointer per "plane". A plane is a sub-buffer of the current frame. For + examples of such formats see . Initially, V4L2 API did not support multi-planar buffers and a set of extensions has been introduced to handle them. Those extensions constitute @@ -14,8 +14,8 @@ Some of the V4L2 API calls and structures are interpreted differently, depending on whether single- or multi-planar API is being used. An application can choose whether to use one or the other by passing a corresponding buffer - type to its ioctl calls. Multi-planar versions of buffer types are suffixed with - an `_MPLANE' string. For a list of available multi-planar buffer types + type to its ioctl calls. Multi-planar versions of buffer types are suffixed + with an `_MPLANE' string. For a list of available multi-planar buffer types see &v4l2-buf-type;. @@ -24,28 +24,9 @@ Multi-planar API introduces new multi-planar formats. Those formats use a separate set of FourCC codes. It is important to distinguish between the multi-planar API and a multi-planar format. Multi-planar API calls can - handle all single-planar formats as well, while the single-planar API cannot - handle multi-planar formats. Applications do not have to switch between APIs - when handling both single- and multi-planar devices and should use the - multi-planar API version for both single- and multi-planar formats. - Drivers that do not support multi-planar API can still be handled with it, - utilizing a compatibility layer built into standard V4L2 ioctl handling. - - - -
- Single and multi-planar API compatibility layer - In most casesThe compatibility layer does not cover - drivers that do not use video_ioctl2() call., applications - can use the multi-planar API with older drivers that support - only its single-planar version and vice versa. Appropriate conversion is - done seamlessly for both applications and drivers in the V4L2 core. The - general rule of thumb is: as long as an application uses formats that - a driver supports, it can use either API (although use of multi-planar - formats is only possible with the multi-planar API). The list of formats - supported by a driver can be obtained using the &VIDIOC-ENUM-FMT; call. - It is possible, but discouraged, for a driver or an application to support - and use both versions of the API. + handle all single-planar formats as well (as long as they are passed in + multi-planar API structures), while the single-planar API cannot + handle multi-planar formats.
diff --git a/Documentation/DocBook/v4l/vidioc-querycap.xml b/Documentation/DocBook/v4l/vidioc-querycap.xml index 93699769cd07..f29f1b86213c 100644 --- a/Documentation/DocBook/v4l/vidioc-querycap.xml +++ b/Documentation/DocBook/v4l/vidioc-querycap.xml @@ -142,30 +142,28 @@ this array to zero. V4L2_CAP_VIDEO_CAPTURE 0x00000001 - The device supports single-planar formats through the Video Capture interface. An application can use either -the single or the multi-planar API. + The device supports the single-planar API through the Video Capture interface. V4L2_CAP_VIDEO_CAPTURE_MPLANE 0x00001000 - The device supports multi-planar formats through the Video Capture interface. An application has to use the -multi-planar API. + The device supports the + multi-planar API through the + Video Capture interface. V4L2_CAP_VIDEO_OUTPUT 0x00000002 - The device supports single-planar formats through the Video Output interface. An application can use either -the single or the multi-planar API. + The device supports the single-planar API through the Video Output interface. V4L2_CAP_VIDEO_OUTPUT_MPLANE 0x00002000 - The device supports multi-planar formats through the Video Output interface. An application has to use the -multi-planar API. + The device supports the + multi-planar API through the + Video Output interface. V4L2_CAP_VIDEO_OVERLAY -- cgit v1.2.3 From 458efe2d558b51fff38026e8ede9374899340e60 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jean-Fran=C3=A7ois=20Moine?= Date: Thu, 10 Feb 2011 10:11:04 -0300 Subject: [media] gspca - ov534: Add the webcam 06f8:3002 and sensor ov767x MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: Jean-François Moine Signed-off-by: Mauro Carvalho Chehab --- Documentation/video4linux/gspca.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/video4linux/gspca.txt b/Documentation/video4linux/gspca.txt index 261776e0c5e1..dc72fff2eb12 100644 --- a/Documentation/video4linux/gspca.txt +++ b/Documentation/video4linux/gspca.txt @@ -199,6 +199,7 @@ spca500 06bd:0404 Agfa CL20 spca500 06be:0800 Optimedia sunplus 06d6:0031 Trust 610 LCD PowerC@m Zoom spca506 06e1:a190 ADS Instant VCD +ov534 06f8:3002 Hercules Blog Webcam ov534_9 06f8:3003 Hercules Dualpix HD Weblog sonixj 06f8:3004 Hercules Classic Silver sonixj 06f8:3008 Hercules Deluxe Optical Glass -- cgit v1.2.3 From b287db119edb92548b53f63f05fd593c43cba200 Mon Sep 17 00:00:00 2001 From: Hans Verkuil Date: Sat, 5 Feb 2011 09:25:02 -0300 Subject: [media] se401: remove last V4L1 driver This driver is for obsolete hardware that the old maintainer didn't care (or not have the hardware anymore), and that no other developer could find any hardware to buy. The V4L1 API is no longer supported, and since nobody stepped in to convert them to V4L2 the decision was made to remove them. Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- Documentation/feature-removal-schedule.txt | 15 --------------- 1 file changed, 15 deletions(-) (limited to 'Documentation') diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt index b3f35e5f9c95..08e0df12df37 100644 --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt @@ -97,21 +97,6 @@ Who: Pavel Machek --------------------------- -What: Video4Linux obsolete drivers using V4L1 API -When: kernel 2.6.39 -Files: drivers/staging/se401/* drivers/staging/usbvideo/* -Check: drivers/staging/se401/se401.c drivers/staging/usbvideo/usbvideo.c -Why: There are some drivers still using V4L1 API, despite all efforts we've done - to migrate. Those drivers are for obsolete hardware that the old maintainer - didn't care (or not have the hardware anymore), and that no other developer - could find any hardware to buy. They probably have no practical usage today, - and people with such old hardware could probably keep using an older version - of the kernel. Those drivers will be moved to staging on 2.6.38 and, if nobody - cares enough to port and test them with V4L2 API, they'll be removed on 2.6.39. -Who: Mauro Carvalho Chehab - ---------------------------- - What: Video4Linux: Remove obsolete ioctl's When: kernel 2.6.39 Files: include/media/videodev2.h -- cgit v1.2.3 From 7ee40aadabd59b6cab60835f0ef9cdbe385df438 Mon Sep 17 00:00:00 2001 From: Hans Verkuil Date: Sat, 5 Feb 2011 10:10:38 -0300 Subject: [media] v4l: removal of old, obsolete ioctls Some ioctl's were defined wrong on 2.6.2 and 2.6.6, using the wrong type of R/W arguments. They were fixed, but the old ioctl names are still there, maintained to avoid breaking binary compatibility: There's no sense on preserving those forever, as it is very doubtful that someone would try to use a such old binary with a modern kernel. Removing them will allow us to remove some magic done at the V4L ioctl handler. Note that any application compiled with a videodev2.h from 2.6.7 or later will be using the correct ioctls. Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- Documentation/feature-removal-schedule.txt | 21 --------------------- 1 file changed, 21 deletions(-) (limited to 'Documentation') diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt index 08e0df12df37..61fb823e5a95 100644 --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt @@ -97,27 +97,6 @@ Who: Pavel Machek --------------------------- -What: Video4Linux: Remove obsolete ioctl's -When: kernel 2.6.39 -Files: include/media/videodev2.h -Why: Some ioctl's were defined wrong on 2.6.2 and 2.6.6, using the wrong - type of R/W arguments. They were fixed, but the old ioctl names are - still there, maintained to avoid breaking binary compatibility: - #define VIDIOC_OVERLAY_OLD _IOWR('V', 14, int) - #define VIDIOC_S_PARM_OLD _IOW('V', 22, struct v4l2_streamparm) - #define VIDIOC_S_CTRL_OLD _IOW('V', 28, struct v4l2_control) - #define VIDIOC_G_AUDIO_OLD _IOWR('V', 33, struct v4l2_audio) - #define VIDIOC_G_AUDOUT_OLD _IOWR('V', 49, struct v4l2_audioout) - #define VIDIOC_CROPCAP_OLD _IOR('V', 58, struct v4l2_cropcap) - There's no sense on preserving those forever, as it is very doubtful - that someone would try to use a such old binary with a modern kernel. - Removing them will allow us to remove some magic done at the V4L ioctl - handler. - -Who: Mauro Carvalho Chehab - ---------------------------- - What: sys_sysctl When: September 2010 Option: CONFIG_SYSCTL_SYSCALL -- cgit v1.2.3 From e45c2be9704381971d78d711e58dec35b1c4cf6f Mon Sep 17 00:00:00 2001 From: Paul Cassella Date: Tue, 8 Feb 2011 21:07:00 -0300 Subject: [media] Documentation: README.ivtv: Remove note that ivtvfb is not yet in the kernel ivtvfb is now in the kernel, so stop saying it's not. Signed-off-by: Paul Cassella Signed-off-by: Andy Walls Signed-off-by: Mauro Carvalho Chehab --- Documentation/video4linux/README.ivtv | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/video4linux/README.ivtv b/Documentation/video4linux/README.ivtv index 42b06686eb78..2579b5b709ed 100644 --- a/Documentation/video4linux/README.ivtv +++ b/Documentation/video4linux/README.ivtv @@ -36,8 +36,7 @@ Additional features for the PVR-350 (CX23415 based): * Provides comprehensive OSD (On Screen Display: ie. graphics overlaying the video signal) * Provides a framebuffer (allowing X applications to appear on the video - device) (this framebuffer is not yet part of the kernel. In the meantime it - is available from www.ivtvdriver.org). + device) * Supports raw YUV output. IMPORTANT: In case of problems first read this page: -- cgit v1.2.3 From f6a373fb0569c98d6a44108f5e879f06abd46df3 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Tue, 1 Mar 2011 09:48:27 -0300 Subject: [media] videodev2.h.xml: Update to reflect videodev2.h changes A few changes happened at videodev2.h: - Addition of multiplane API; - removal of VIDIOC_*_OLD ioctls; - a few more video standards. Update the file to reflect the latest changes. Signed-off-by: Mauro Carvalho Chehab --- Documentation/DocBook/v4l/videodev2.h.xml | 141 +++++++++++++++++++++++++++--- 1 file changed, 129 insertions(+), 12 deletions(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/v4l/videodev2.h.xml b/Documentation/DocBook/v4l/videodev2.h.xml index 325b23b6964c..2b796a2ee98a 100644 --- a/Documentation/DocBook/v4l/videodev2.h.xml +++ b/Documentation/DocBook/v4l/videodev2.h.xml @@ -71,6 +71,7 @@ * Moved from videodev.h */ #define VIDEO_MAX_FRAME 32 +#define VIDEO_MAX_PLANES 8 #ifndef __KERNEL__ @@ -158,9 +159,23 @@ enum v4l2_buf_type { /* Experimental */ V4L2_BUF_TYPE_VIDEO_OUTPUT_OVERLAY = 8, #endif + V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE = 9, + V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE = 10, V4L2_BUF_TYPE_PRIVATE = 0x80, }; +#define V4L2_TYPE_IS_MULTIPLANAR(type) \ + ((type) == V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE \ + || (type) == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) + +#define V4L2_TYPE_IS_OUTPUT(type) \ + ((type) == V4L2_BUF_TYPE_VIDEO_OUTPUT \ + || (type) == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE \ + || (type) == V4L2_BUF_TYPE_VIDEO_OVERLAY \ + || (type) == V4L2_BUF_TYPE_VIDEO_OUTPUT_OVERLAY \ + || (type) == V4L2_BUF_TYPE_VBI_OUTPUT \ + || (type) == V4L2_BUF_TYPE_SLICED_VBI_OUTPUT) + enum v4l2_tuner_type { V4L2_TUNER_RADIO = 1, V4L2_TUNER_ANALOG_TV = 2, @@ -246,6 +261,11 @@ struct v4l2_capability { #define V4L2_CAP_HW_FREQ_SEEK 0x00000400 /* Can do hardware frequency seek */ #define V4L2_CAP_RDS_OUTPUT 0x00000800 /* Is an RDS encoder */ +/* Is a video capture device that supports multiplanar formats */ +#define V4L2_CAP_VIDEO_CAPTURE_MPLANE 0x00001000 +/* Is a video output device that supports multiplanar formats */ +#define V4L2_CAP_VIDEO_OUTPUT_MPLANE 0x00002000 + #define V4L2_CAP_TUNER 0x00010000 /* has a tuner */ #define V4L2_CAP_AUDIO 0x00020000 /* has audio support */ #define V4L2_CAP_RADIO 0x00040000 /* is a radio device */ @@ -320,6 +340,13 @@ struct v4l2_pix_format { #define V4L2_PIX_FMT_NV16 v4l2_fourcc('N', 'V', '1', '6') /* 16 Y/CbCr 4:2:2 */ #define V4L2_PIX_FMT_NV61 v4l2_fourcc('N', 'V', '6', '1') /* 16 Y/CrCb 4:2:2 */ +/* two non contiguous planes - one Y, one Cr + Cb interleaved */ +#define V4L2_PIX_FMT_NV12M v4l2_fourcc('N', 'M', '1', '2') /* 12 Y/CbCr 4:2:0 */ +#define V4L2_PIX_FMT_NV12MT v4l2_fourcc('T', 'M', '1', '2') /* 12 Y/CbCr 4:2:0 64x32 macroblocks */ + +/* three non contiguous planes - Y, Cb, Cr */ +#define V4L2_PIX_FMT_YUV420M v4l2_fourcc('Y', 'M', '1', '2') /* 12 YUV420 planar */ + /* Bayer formats - see http://www.siliconimaging.com/RGB%20Bayer.htm */ #define V4L2_PIX_FMT_SBGGR8 v4l2_fourcc('B', 'A', '8', '1') /* 8 BGBG.. GRGR.. */ #define V4L2_PIX_FMT_SGBRG8 v4l2_fourcc('G', 'B', 'R', 'G') /* 8 GBGB.. RGRG.. */ @@ -518,6 +545,62 @@ struct v4l2_requestbuffers { __u32 reserved[2]; }; +/** + * struct v4l2_plane - plane info for multi-planar buffers + * @bytesused: number of bytes occupied by data in the plane (payload) + * @length: size of this plane (NOT the payload) in bytes + * @mem_offset: when memory in the associated struct v4l2_buffer is + * V4L2_MEMORY_MMAP, equals the offset from the start of + * the device memory for this plane (or is a "cookie" that + * should be passed to mmap() called on the video node) + * @userptr: when memory is V4L2_MEMORY_USERPTR, a userspace pointer + * pointing to this plane + * @data_offset: offset in the plane to the start of data; usually 0, + * unless there is a header in front of the data + * + * Multi-planar buffers consist of one or more planes, e.g. an YCbCr buffer + * with two planes can have one plane for Y, and another for interleaved CbCr + * components. Each plane can reside in a separate memory buffer, or even in + * a completely separate memory node (e.g. in embedded devices). + */ +struct v4l2_plane { + __u32 bytesused; + __u32 length; + union { + __u32 mem_offset; + unsigned long userptr; + } m; + __u32 data_offset; + __u32 reserved[11]; +}; + +/** + * struct v4l2_buffer - video buffer info + * @index: id number of the buffer + * @type: buffer type (type == *_MPLANE for multiplanar buffers) + * @bytesused: number of bytes occupied by data in the buffer (payload); + * unused (set to 0) for multiplanar buffers + * @flags: buffer informational flags + * @field: field order of the image in the buffer + * @timestamp: frame timestamp + * @timecode: frame timecode + * @sequence: sequence count of this frame + * @memory: the method, in which the actual video data is passed + * @offset: for non-multiplanar buffers with memory == V4L2_MEMORY_MMAP; + * offset from the start of the device memory for this plane, + * (or a "cookie" that should be passed to mmap() as offset) + * @userptr: for non-multiplanar buffers with memory == V4L2_MEMORY_USERPTR; + * a userspace pointer pointing to this buffer + * @planes: for multiplanar buffers; userspace pointer to the array of plane + * info structs for this buffer + * @length: size in bytes of the buffer (NOT its payload) for single-plane + * buffers (when type != *_MPLANE); number of elements in the + * planes array for multi-plane buffers + * @input: input number from which the video data has has been captured + * + * Contains data exchanged by application and driver using one of the Streaming + * I/O methods. + */ struct v4l2_buffer { __u32 index; enum v4l2_buf_type type; @@ -533,6 +616,7 @@ struct v4l2_buffer { union { __u32 offset; unsigned long userptr; + struct v4l2_plane *planes; } m; __u32 length; __u32 input; @@ -1623,12 +1707,56 @@ struct v4l2_mpeg_vbi_fmt_ivtv { * A G G R E G A T E S T R U C T U R E S */ -/* Stream data format +/** + * struct v4l2_plane_pix_format - additional, per-plane format definition + * @sizeimage: maximum size in bytes required for data, for which + * this plane will be used + * @bytesperline: distance in bytes between the leftmost pixels in two + * adjacent lines + */ +struct v4l2_plane_pix_format { + __u32 sizeimage; + __u16 bytesperline; + __u16 reserved[7]; +} __attribute__ ((packed)); + +/** + * struct v4l2_pix_format_mplane - multiplanar format definition + * @width: image width in pixels + * @height: image height in pixels + * @pixelformat: little endian four character code (fourcc) + * @field: field order (for interlaced video) + * @colorspace: supplemental to pixelformat + * @plane_fmt: per-plane information + * @num_planes: number of planes for this format + */ +struct v4l2_pix_format_mplane { + __u32 width; + __u32 height; + __u32 pixelformat; + enum v4l2_field field; + enum v4l2_colorspace colorspace; + + struct v4l2_plane_pix_format plane_fmt[VIDEO_MAX_PLANES]; + __u8 num_planes; + __u8 reserved[11]; +} __attribute__ ((packed)); + +/** + * struct v4l2_format - stream data format + * @type: type of the data stream + * @pix: definition of an image format + * @pix_mp: definition of a multiplanar image format + * @win: definition of an overlaid image + * @vbi: raw VBI capture or output parameters + * @sliced: sliced VBI capture or output parameters + * @raw_data: placeholder for future extensions and custom formats */ struct v4l2_format { enum v4l2_buf_type type; union { struct v4l2_pix_format pix; /* V4L2_BUF_TYPE_VIDEO_CAPTURE */ + struct v4l2_pix_format_mplane pix_mp; /* V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE */ struct v4l2_window win; /* V4L2_BUF_TYPE_VIDEO_OVERLAY */ struct v4l2_vbi_format vbi; /* V4L2_BUF_TYPE_VBI_CAPTURE */ struct v4l2_sliced_vbi_format sliced; /* V4L2_BUF_TYPE_SLICED_VBI_CAPTURE */ @@ -1636,7 +1764,6 @@ struct v4l2_format { } fmt; }; - /* Stream type-dependent parameters */ struct v4l2_streamparm { @@ -1809,16 +1936,6 @@ struct v4l2_dbg_chip_ident { /* Reminder: when adding new ioctls please add support for them to drivers/media/video/v4l2-compat-ioctl32.c as well! */ -#ifdef __OLD_VIDIOC_ -/* for compatibility, will go away some day */ -#define VIDIOC_OVERLAY_OLD _IOWR('V', 14, int) -#define VIDIOC_S_PARM_OLD _IOW('V', 22, struct v4l2_streamparm) -#define VIDIOC_S_CTRL_OLD _IOW('V', 28, struct v4l2_control) -#define VIDIOC_G_AUDIO_OLD _IOWR('V', 33, struct v4l2_audio) -#define VIDIOC_G_AUDOUT_OLD _IOWR('V', 49, struct v4l2_audioout) -#define VIDIOC_CROPCAP_OLD _IOR('V', 58, struct v4l2_cropcap) -#endif - #define BASE_VIDIOC_PRIVATE 192 /* 192-255 are private */ #endif /* __LINUX_VIDEODEV2_H */ -- cgit v1.2.3 From a602d520acd331ba8bbc02aacccb5e9a0f561f25 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Tue, 1 Mar 2011 10:12:36 -0300 Subject: [media] DocBook: Document the removal of the old VIDIOC_*_OLD ioctls Those ioctls passed away. Properly documented it. Signed-off-by: Mauro Carvalho Chehab --- Documentation/DocBook/v4l/compat.xml | 20 ++++++++++++++------ 1 file changed, 14 insertions(+), 6 deletions(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/v4l/compat.xml b/Documentation/DocBook/v4l/compat.xml index 223c24c536b7..4d74bf24e114 100644 --- a/Documentation/DocBook/v4l/compat.xml +++ b/Documentation/DocBook/v4l/compat.xml @@ -1711,8 +1711,8 @@ ioctl would enumerate the available audio inputs. An ioctl to determine the current audio input, if more than one combines with the current video input, did not exist. So VIDIOC_G_AUDIO was renamed to -VIDIOC_G_AUDIO_OLD, this ioctl will be removed in -the future. The &VIDIOC-ENUMAUDIO; ioctl was added to enumerate +VIDIOC_G_AUDIO_OLD, this ioctl was removed on +Kernel 2.6.39. The &VIDIOC-ENUMAUDIO; ioctl was added to enumerate audio inputs, while &VIDIOC-G-AUDIO; now reports the current audio input. The same changes were made to &VIDIOC-G-AUDOUT; and @@ -1726,7 +1726,7 @@ must be updated to successfully compile again. The &VIDIOC-OVERLAY; ioctl was incorrectly defined with write-read parameter. It was changed to write-only, while the write-read version was renamed to VIDIOC_OVERLAY_OLD. The old -ioctl will be removed in the future. Until further the "videodev" +ioctl was removed on Kernel 2.6.39. Until further the "videodev" kernel module will automatically translate to the new version, so drivers must be recompiled, but not applications. @@ -1744,7 +1744,7 @@ surface can be seen. defined with write-only parameter, inconsistent with other ioctls modifying their argument. They were changed to write-read, while a _OLD suffix was added to the write-only versions. -The old ioctls will be removed in the future. Drivers and +The old ioctls were removed on Kernel 2.6.39. Drivers and applications assuming a constant parameter need an update. @@ -1815,8 +1815,8 @@ yet to be addressed, for details see The &VIDIOC-CROPCAP; ioctl was incorrectly defined with read-only parameter. It is now defined as write-read ioctl, while the read-only version was renamed to -VIDIOC_CROPCAP_OLD. The old ioctl will be removed -in the future. +VIDIOC_CROPCAP_OLD. The old ioctl was removed +on Kernel 2.6.39.
@@ -2364,6 +2364,14 @@ that used it. It was originally scheduled for removal in 2.6.35. +
+ V4L2 in Linux 2.6.39 + + + The old VIDIOC_*_OLD symbols and V4L1 support were removed. + + +
Relation of V4L2 to other Linux multimedia APIs -- cgit v1.2.3 From 3822f18d8f1c2cf13ade623b2bba6d4a7a1a3f53 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Tue, 1 Mar 2011 16:03:11 -0300 Subject: [media] DocBook/v4l2.xml: Update version of the spec Signed-off-by: Mauro Carvalho Chehab --- Documentation/DocBook/v4l/v4l2.xml | 8 ++++++++ 1 file changed, 8 insertions(+) (limited to 'Documentation') diff --git a/Documentation/DocBook/v4l/v4l2.xml b/Documentation/DocBook/v4l/v4l2.xml index c3d699173c17..7859d7d9da39 100644 --- a/Documentation/DocBook/v4l/v4l2.xml +++ b/Documentation/DocBook/v4l/v4l2.xml @@ -127,6 +127,14 @@ structs, ioctls) must be noted in more detail in the history chapter (compat.xml), along with the possible impact on existing drivers and applications. --> + + 2.6.39 + 2011-03-01 + mcc + Removed VIDIOC_*_OLD from videodev2.h header and update it to reflect latest changes. + + + 2.6.38 2011-01-16 -- cgit v1.2.3 From 2096a5dcf9704f5a86ecba37169eb813aaf0431c Mon Sep 17 00:00:00 2001 From: Laurent Pinchart Date: Wed, 9 Dec 2009 08:38:49 -0300 Subject: [media] v4l: subdev: Add device node support Create a device node named subdevX for every registered subdev. As the device node is registered before the subdev core::s_config function is called, return -EGAIN on open until initialization completes. Signed-off-by: Laurent Pinchart Signed-off-by: Vimarsh Zutshi Acked-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- Documentation/video4linux/v4l2-framework.txt | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) (limited to 'Documentation') diff --git a/Documentation/video4linux/v4l2-framework.txt b/Documentation/video4linux/v4l2-framework.txt index f22f35c271f3..8b358710b2f7 100644 --- a/Documentation/video4linux/v4l2-framework.txt +++ b/Documentation/video4linux/v4l2-framework.txt @@ -319,6 +319,22 @@ controlled through GPIO pins. This distinction is only relevant when setting up the device, but once the subdev is registered it is completely transparent. +V4L2 sub-device userspace API +----------------------------- + +Beside exposing a kernel API through the v4l2_subdev_ops structure, V4L2 +sub-devices can also be controlled directly by userspace applications. + +Device nodes named v4l-subdevX can be created in /dev to access sub-devices +directly. If a sub-device supports direct userspace configuration it must set +the V4L2_SUBDEV_FL_HAS_DEVNODE flag before being registered. + +After registering sub-devices, the v4l2_device driver can create device nodes +for all registered sub-devices marked with V4L2_SUBDEV_FL_HAS_DEVNODE by calling +v4l2_device_register_subdev_nodes(). Those device nodes will be automatically +removed when sub-devices are unregistered. + + I2C sub-device drivers ---------------------- -- cgit v1.2.3 From ea8aa4349e11c62242a8908fc172de27d7a151d7 Mon Sep 17 00:00:00 2001 From: Laurent Pinchart Date: Wed, 9 Dec 2009 08:39:54 -0300 Subject: [media] v4l: subdev: Control ioctls support Pass the control-related ioctls to the subdev driver through the control framework. Signed-off-by: Laurent Pinchart Acked-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- Documentation/video4linux/v4l2-framework.txt | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) (limited to 'Documentation') diff --git a/Documentation/video4linux/v4l2-framework.txt b/Documentation/video4linux/v4l2-framework.txt index 8b358710b2f7..1feecfc59c3d 100644 --- a/Documentation/video4linux/v4l2-framework.txt +++ b/Documentation/video4linux/v4l2-framework.txt @@ -334,6 +334,22 @@ for all registered sub-devices marked with V4L2_SUBDEV_FL_HAS_DEVNODE by calling v4l2_device_register_subdev_nodes(). Those device nodes will be automatically removed when sub-devices are unregistered. +The device node handles a subset of the V4L2 API. + +VIDIOC_QUERYCTRL +VIDIOC_QUERYMENU +VIDIOC_G_CTRL +VIDIOC_S_CTRL +VIDIOC_G_EXT_CTRLS +VIDIOC_S_EXT_CTRLS +VIDIOC_TRY_EXT_CTRLS + + The controls ioctls are identical to the ones defined in V4L2. They + behave identically, with the only exception that they deal only with + controls implemented in the sub-device. Depending on the driver, those + controls can be also be accessed through one (or several) V4L2 device + nodes. + I2C sub-device drivers ---------------------- -- cgit v1.2.3 From 02adb1cc765b8c29dc83c6602bda19003cce62f1 Mon Sep 17 00:00:00 2001 From: Sakari Ailus Date: Wed, 3 Mar 2010 12:49:38 -0300 Subject: [media] v4l: subdev: Events support Provide v4l2_subdevs with v4l2_event support. Subdev drivers only need very little to support events. Signed-off-by: Sakari Ailus Signed-off-by: David Cohen Signed-off-by: Laurent Pinchart Acked-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- Documentation/video4linux/v4l2-framework.txt | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) (limited to 'Documentation') diff --git a/Documentation/video4linux/v4l2-framework.txt b/Documentation/video4linux/v4l2-framework.txt index 1feecfc59c3d..eb8479565dc4 100644 --- a/Documentation/video4linux/v4l2-framework.txt +++ b/Documentation/video4linux/v4l2-framework.txt @@ -350,6 +350,24 @@ VIDIOC_TRY_EXT_CTRLS controls can be also be accessed through one (or several) V4L2 device nodes. +VIDIOC_DQEVENT +VIDIOC_SUBSCRIBE_EVENT +VIDIOC_UNSUBSCRIBE_EVENT + + The events ioctls are identical to the ones defined in V4L2. They + behave identically, with the only exception that they deal only with + events generated by the sub-device. Depending on the driver, those + events can also be reported by one (or several) V4L2 device nodes. + + Sub-device drivers that want to use events need to set the + V4L2_SUBDEV_USES_EVENTS v4l2_subdev::flags and initialize + v4l2_subdev::nevents to events queue depth before registering the + sub-device. After registration events can be queued as usual on the + v4l2_subdev::devnode device node. + + To properly support events, the poll() file operation is also + implemented. + I2C sub-device drivers ---------------------- -- cgit v1.2.3 From 176fb0d108f7495ccf9aa127e1342a1a0d87e004 Mon Sep 17 00:00:00 2001 From: Laurent Pinchart Date: Wed, 9 Dec 2009 08:39:58 -0300 Subject: [media] media: Media device The media_device structure abstracts functions common to all kind of media devices (v4l2, dvb, alsa, ...). It manages media entities and offers a userspace API to discover and configure the media device internal topology. Signed-off-by: Laurent Pinchart Acked-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- Documentation/ABI/testing/sysfs-bus-media | 6 +++ Documentation/DocBook/media-entities.tmpl | 2 + Documentation/DocBook/media.tmpl | 3 ++ Documentation/DocBook/v4l/media-controller.xml | 56 +++++++++++++++++++++ Documentation/media-framework.txt | 67 ++++++++++++++++++++++++++ 5 files changed, 134 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-bus-media create mode 100644 Documentation/DocBook/v4l/media-controller.xml create mode 100644 Documentation/media-framework.txt (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-bus-media b/Documentation/ABI/testing/sysfs-bus-media new file mode 100644 index 000000000000..7057e574154a --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-media @@ -0,0 +1,6 @@ +What: /sys/bus/media/devices/.../model +Date: January 2011 +Contact: Laurent Pinchart + linux-media@vger.kernel.org +Description: Contains the device model name in UTF-8. The device version is + is not be appended to the model name. diff --git a/Documentation/DocBook/media-entities.tmpl b/Documentation/DocBook/media-entities.tmpl index d2f99e5a3a2f..c47897f046b1 100644 --- a/Documentation/DocBook/media-entities.tmpl +++ b/Documentation/DocBook/media-entities.tmpl @@ -327,6 +327,8 @@ + + diff --git a/Documentation/DocBook/media.tmpl b/Documentation/DocBook/media.tmpl index a99088aae1aa..88f2cc680cc2 100644 --- a/Documentation/DocBook/media.tmpl +++ b/Documentation/DocBook/media.tmpl @@ -106,6 +106,9 @@ Foundation. A copy of the license is included in the chapter entitled &sub-remote_controllers; + +&sub-media-controller; + &sub-fdl-appendix; diff --git a/Documentation/DocBook/v4l/media-controller.xml b/Documentation/DocBook/v4l/media-controller.xml new file mode 100644 index 000000000000..253ddb4426c9 --- /dev/null +++ b/Documentation/DocBook/v4l/media-controller.xml @@ -0,0 +1,56 @@ + + + + Laurent + Pinchart +
laurent.pinchart@ideasonboard.com
 + Initial version. + + + + 2010 + Laurent Pinchart + + + + + + 1.0.0 + 2010-11-10 + lp + Initial revision + + + + +Media Controller API + + + Media Controller + +
+ Introduction + Media devices increasingly handle multiple related functions. Many USB + cameras include microphones, video capture hardware can also output video, + or SoC camera interfaces also perform memory-to-memory operations similar to + video codecs. + Independent functions, even when implemented in the same hardware, can + be modelled as separate devices. A USB camera with a microphone will be + presented to userspace applications as V4L2 and ALSA capture devices. The + devices' relationships (when using a webcam, end-users shouldn't have to + manually select the associated USB microphone), while not made available + directly to applications by the drivers, can usually be retrieved from + sysfs. + With more and more advanced SoC devices being introduced, the current + approach will not scale. Device topologies are getting increasingly complex + and can't always be represented by a tree structure. Hardware blocks are + shared between different functions, creating dependencies between seemingly + unrelated devices. + Kernel abstraction APIs such as V4L2 and ALSA provide means for + applications to access hardware parameters. As newer hardware expose an + increasingly high number of those parameters, drivers need to guess what + applications really require based on limited information, thereby + implementing policies that belong to userspace. + The media controller API aims at solving those problems. +
+ diff --git a/Documentation/media-framework.txt b/Documentation/media-framework.txt new file mode 100644 index 000000000000..1844c3f10728 --- /dev/null +++ b/Documentation/media-framework.txt @@ -0,0 +1,67 @@ +Linux kernel media framework +============================ + +This document describes the Linux kernel media framework, its data structures, +functions and their usage. + + +Introduction +------------ + +The media controller API is documented in DocBook format in +Documentation/DocBook/v4l/media-controller.xml. This document will focus on +the kernel-side implementation of the media framework. + + +Media device +------------ + +A media device is represented by a struct media_device instance, defined in +include/media/media-device.h. Allocation of the structure is handled by the +media device driver, usually by embedding the media_device instance in a +larger driver-specific structure. + +Drivers register media device instances by calling + + media_device_register(struct media_device *mdev); + +The caller is responsible for initializing the media_device structure before +registration. The following fields must be set: + + - dev must point to the parent device (usually a pci_dev, usb_interface or + platform_device instance). + + - model must be filled with the device model name as a NUL-terminated UTF-8 + string. The device/model revision must not be stored in this field. + +The following fields are optional: + + - serial is a unique serial number stored as a NUL-terminated ASCII string. + The field is big enough to store a GUID in text form. If the hardware + doesn't provide a unique serial number this field must be left empty. + + - bus_info represents the location of the device in the system as a + NUL-terminated ASCII string. For PCI/PCIe devices bus_info must be set to + "PCI:" (or "PCIe:") followed by the value of pci_name(). For USB devices, + the usb_make_path() function must be used. This field is used by + applications to distinguish between otherwise identical devices that don't + provide a serial number. + + - hw_revision is the hardware device revision in a driver-specific format. + When possible the revision should be formatted with the KERNEL_VERSION + macro. + + - driver_version is formatted with the KERNEL_VERSION macro. The version + minor must be incremented when new features are added to the userspace API + without breaking binary compatibility. The version major must be + incremented when binary compatibility is broken. + +Upon successful registration a character device named media[0-9]+ is created. +The device major and minor numbers are dynamic. The model name is exported as +a sysfs attribute. + +Drivers unregister media device instances by calling + + media_device_unregister(struct media_device *mdev); + +Unregistering a media device that hasn't been registered is *NOT* safe. -- cgit v1.2.3 From 53e269c102fbaf77e7dc526b1606ad4a48e57200 Mon Sep 17 00:00:00 2001 From: Laurent Pinchart Date: Wed, 9 Dec 2009 08:40:00 -0300 Subject: [media] media: Entities, pads and links As video hardware pipelines become increasingly complex and configurable, the current hardware description through v4l2 subdevices reaches its limits. In addition to enumerating and configuring subdevices, video camera drivers need a way to discover and modify at runtime how those subdevices are connected. This is done through new elements called entities, pads and links. An entity is a basic media hardware building block. It can correspond to a large variety of logical blocks such as physical hardware devices (CMOS sensor for instance), logical hardware devices (a building block in a System-on-Chip image processing pipeline), DMA channels or physical connectors. A pad is a connection endpoint through which an entity can interact with other entities. Data (not restricted to video) produced by an entity flows from the entity's output to one or more entity inputs. Pads should not be confused with physical pins at chip boundaries. A link is a point-to-point oriented connection between two pads, either on the same entity or on different entities. Data flows from a source pad to a sink pad. Links are stored in the source entity. To make backwards graph walk faster, a copy of all links is also stored in the sink entity. The copy is known as a backlink and is only used to help graph traversal. The entity API is made of three functions: - media_entity_init() initializes an entity. The caller must provide an array of pads as well as an estimated number of links. The links array is allocated dynamically and will be reallocated if it grows beyond the initial estimate. - media_entity_cleanup() frees resources allocated for an entity. It must be called during the cleanup phase after unregistering the entity and before freeing it. - media_entity_create_link() creates a link between two entities. An entry in the link array of each entity is allocated and stores pointers to source and sink pads. When a media device is unregistered, all its entities are unregistered automatically. The code is based on Hans Verkuil initial work. Signed-off-by: Laurent Pinchart Signed-off-by: Sakari Ailus Acked-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- Documentation/DocBook/v4l/media-controller.xml | 20 ++++ Documentation/media-framework.txt | 151 +++++++++++++++++++++++++ 2 files changed, 171 insertions(+) (limited to 'Documentation') diff --git a/Documentation/DocBook/v4l/media-controller.xml b/Documentation/DocBook/v4l/media-controller.xml index 253ddb4426c9..f89228d3ec2a 100644 --- a/Documentation/DocBook/v4l/media-controller.xml +++ b/Documentation/DocBook/v4l/media-controller.xml @@ -53,4 +53,24 @@ implementing policies that belong to userspace. The media controller API aims at solving those problems.
+ +
+ Media device model + Discovering a device internal topology, and configuring it at runtime, + is one of the goals of the media controller API. To achieve this, hardware + devices are modelled as an oriented graph of building blocks called entities + connected through pads. + An entity is a basic media hardware or software building block. It can + correspond to a large variety of logical blocks such as physical hardware + devices (CMOS sensor for instance), logical hardware devices (a building + block in a System-on-Chip image processing pipeline), DMA channels or + physical connectors. + A pad is a connection endpoint through which an entity can interact + with other entities. Data (not restricted to video) produced by an entity + flows from the entity's output to one or more entity inputs. Pads should not + be confused with physical pins at chip boundaries. + A link is a point-to-point oriented connection between two pads, + either on the same entity or on different entities. Data flows from a source + pad to a sink pad. +
diff --git a/Documentation/media-framework.txt b/Documentation/media-framework.txt index 1844c3f10728..0257bad2a104 100644 --- a/Documentation/media-framework.txt +++ b/Documentation/media-framework.txt @@ -13,6 +13,30 @@ Documentation/DocBook/v4l/media-controller.xml. This document will focus on the kernel-side implementation of the media framework. +Abstract media device model +--------------------------- + +Discovering a device internal topology, and configuring it at runtime, is one +of the goals of the media framework. To achieve this, hardware devices are +modeled as an oriented graph of building blocks called entities connected +through pads. + +An entity is a basic media hardware building block. It can correspond to +a large variety of logical blocks such as physical hardware devices +(CMOS sensor for instance), logical hardware devices (a building block +in a System-on-Chip image processing pipeline), DMA channels or physical +connectors. + +A pad is a connection endpoint through which an entity can interact with +other entities. Data (not restricted to video) produced by an entity +flows from the entity's output to one or more entity inputs. Pads should +not be confused with physical pins at chip boundaries. + +A link is a point-to-point oriented connection between two pads, either +on the same entity or on different entities. Data flows from a source +pad to a sink pad. + + Media device ------------ @@ -65,3 +89,130 @@ Drivers unregister media device instances by calling media_device_unregister(struct media_device *mdev); Unregistering a media device that hasn't been registered is *NOT* safe. + + +Entities, pads and links +------------------------ + +- Entities + +Entities are represented by a struct media_entity instance, defined in +include/media/media-entity.h. The structure is usually embedded into a +higher-level structure, such as a v4l2_subdev or video_device instance, +although drivers can allocate entities directly. + +Drivers initialize entities by calling + + media_entity_init(struct media_entity *entity, u16 num_pads, + struct media_pad *pads, u16 extra_links); + +The media_entity name, type, flags, revision and group_id fields can be +initialized before or after calling media_entity_init. Entities embedded in +higher-level standard structures can have some of those fields set by the +higher-level framework. + +As the number of pads is known in advance, the pads array is not allocated +dynamically but is managed by the entity driver. Most drivers will embed the +pads array in a driver-specific structure, avoiding dynamic allocation. + +Drivers must set the direction of every pad in the pads array before calling +media_entity_init. The function will initialize the other pads fields. + +Unlike the number of pads, the total number of links isn't always known in +advance by the entity driver. As an initial estimate, media_entity_init +pre-allocates a number of links equal to the number of pads plus an optional +number of extra links. The links array will be reallocated if it grows beyond +the initial estimate. + +Drivers register entities with a media device by calling + + media_device_register_entity(struct media_device *mdev, + struct media_entity *entity); + +Entities are identified by a unique positive integer ID. Drivers can provide an +ID by filling the media_entity id field prior to registration, or request the +media controller framework to assign an ID automatically. Drivers that provide +IDs manually must ensure that all IDs are unique. IDs are not guaranteed to be +contiguous even when they are all assigned automatically by the framework. + +Drivers unregister entities by calling + + media_device_unregister_entity(struct media_entity *entity); + +Unregistering an entity will not change the IDs of the other entities, and the +ID will never be reused for a newly registered entity. + +When a media device is unregistered, all its entities are unregistered +automatically. No manual entities unregistration is then required. + +Drivers free resources associated with an entity by calling + + media_entity_cleanup(struct media_entity *entity); + +This function must be called during the cleanup phase after unregistering the +entity. Note that the media_entity instance itself must be freed explicitly by +the driver if required. + +Entities have flags that describe the entity capabilities and state. + + MEDIA_ENT_FL_DEFAULT indicates the default entity for a given type. + This can be used to report the default audio and video devices or the + default camera sensor. + +Logical entity groups can be defined by setting the group ID of all member +entities to the same non-zero value. An entity group serves no purpose in the +kernel, but is reported to userspace during entities enumeration. The group_id +field belongs to the media device driver and must not by touched by entity +drivers. + +Media device drivers should define groups if several entities are logically +bound together. Example usages include reporting + + - ALSA, VBI and video nodes that carry the same media stream + - lens and flash controllers associated with a sensor + +- Pads + +Pads are represented by a struct media_pad instance, defined in +include/media/media-entity.h. Each entity stores its pads in a pads array +managed by the entity driver. Drivers usually embed the array in a +driver-specific structure. + +Pads are identified by their entity and their 0-based index in the pads array. +Both information are stored in the media_pad structure, making the media_pad +pointer the canonical way to store and pass link references. + +Pads have flags that describe the pad capabilities and state. + + MEDIA_PAD_FL_SINK indicates that the pad supports sinking data. + MEDIA_PAD_FL_SOURCE indicates that the pad supports sourcing data. + +One and only one of MEDIA_PAD_FL_SINK and MEDIA_PAD_FL_SOURCE must be set for +each pad. + +- Links + +Links are represented by a struct media_link instance, defined in +include/media/media-entity.h. Each entity stores all links originating at or +targetting any of its pads in a links array. A given link is thus stored +twice, once in the source entity and once in the target entity. The array is +pre-allocated and grows dynamically as needed. + +Drivers create links by calling + + media_entity_create_link(struct media_entity *source, u16 source_pad, + struct media_entity *sink, u16 sink_pad, + u32 flags); + +An entry in the link array of each entity is allocated and stores pointers +to source and sink pads. + +Links have flags that describe the link capabilities and state. + + MEDIA_LNK_FL_ENABLED indicates that the link is enabled and can be used + to transfer media data. When two or more links target a sink pad, only + one of them can be enabled at a time. + MEDIA_LNK_FL_IMMUTABLE indicates that the link enabled state can't be + modified at runtime. If MEDIA_LNK_FL_IMMUTABLE is set, then + MEDIA_LNK_FL_ENABLED must also be set since an immutable link is always + enabled. -- cgit v1.2.3 From a5ccc48a7c48610e7f92fa599406738d69195d51 Mon Sep 17 00:00:00 2001 From: Sakari Ailus Date: Sun, 7 Mar 2010 16:14:14 -0300 Subject: [media] media: Entity graph traversal Add media entity graph traversal. The traversal follows enabled links by depth first. Traversing graph backwards is prevented by comparing the next possible entity in the graph with the previous one. Multiply connected graphs are thus not supported. Signed-off-by: Sakari Ailus Signed-off-by: Laurent Pinchart Signed-off-by: Vimarsh Zutshi Acked-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- Documentation/media-framework.txt | 42 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 42 insertions(+) (limited to 'Documentation') diff --git a/Documentation/media-framework.txt b/Documentation/media-framework.txt index 0257bad2a104..ab17f33ddedc 100644 --- a/Documentation/media-framework.txt +++ b/Documentation/media-framework.txt @@ -216,3 +216,45 @@ Links have flags that describe the link capabilities and state. modified at runtime. If MEDIA_LNK_FL_IMMUTABLE is set, then MEDIA_LNK_FL_ENABLED must also be set since an immutable link is always enabled. + + +Graph traversal +--------------- + +The media framework provides APIs to iterate over entities in a graph. + +To iterate over all entities belonging to a media device, drivers can use the +media_device_for_each_entity macro, defined in include/media/media-device.h. + + struct media_entity *entity; + + media_device_for_each_entity(entity, mdev) { + /* entity will point to each entity in turn */ + ... + } + +Drivers might also need to iterate over all entities in a graph that can be +reached only through enabled links starting at a given entity. The media +framework provides a depth-first graph traversal API for that purpose. + +Note that graphs with cycles (whether directed or undirected) are *NOT* +supported by the graph traversal API. To prevent infinite loops, the graph +traversal code limits the maximum depth to MEDIA_ENTITY_ENUM_MAX_DEPTH, +currently defined as 16. + +Drivers initiate a graph traversal by calling + + media_entity_graph_walk_start(struct media_entity_graph *graph, + struct media_entity *entity); + +The graph structure, provided by the caller, is initialized to start graph +traversal at the given entity. + +Drivers can then retrieve the next entity by calling + + media_entity_graph_walk_next(struct media_entity_graph *graph); + +When the graph traversal is complete the function will return NULL. + +Graph traversal can be interrupted at any moment. No cleanup function call is +required and the graph structure can be freed normally. -- cgit v1.2.3 From 503c3d829eaf48837dd5bff5d97ad66369bb955a Mon Sep 17 00:00:00 2001 From: Laurent Pinchart Date: Sun, 7 Mar 2010 15:04:59 -0300 Subject: [media] media: Entity use count Due to the wide differences between drivers regarding power management needs, the media controller does not implement power management. However, the media_entity structure includes a use_count field that media drivers can use to track the number of users of every entity for power management needs. The use_count field is owned by media drivers and must not be touched by entity drivers. Access to the field must be protected by the media device graph_mutex lock. Signed-off-by: Laurent Pinchart Acked-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- Documentation/media-framework.txt | 13 +++++++++++++ 1 file changed, 13 insertions(+) (limited to 'Documentation') diff --git a/Documentation/media-framework.txt b/Documentation/media-framework.txt index ab17f33ddedc..78ae02095372 100644 --- a/Documentation/media-framework.txt +++ b/Documentation/media-framework.txt @@ -258,3 +258,16 @@ When the graph traversal is complete the function will return NULL. Graph traversal can be interrupted at any moment. No cleanup function call is required and the graph structure can be freed normally. + + +Use count and power handling +---------------------------- + +Due to the wide differences between drivers regarding power management needs, +the media controller does not implement power management. However, the +media_entity structure includes a use_count field that media drivers can use to +track the number of users of every entity for power management needs. + +The use_count field is owned by media drivers and must not be touched by entity +drivers. Access to the field must be protected by the media device graph_mutex +lock. -- cgit v1.2.3 From 140d88165c25137e871f9559e67986ed89251105 Mon Sep 17 00:00:00 2001 From: Laurent Pinchart Date: Wed, 18 Aug 2010 11:41:22 -0300 Subject: [media] media: Media device information query Create the following ioctl and implement it at the media device level to query device information. - MEDIA_IOC_DEVICE_INFO: Query media device information The ioctl and its data structure are defined in the new kernel header linux/media.h available to userspace applications. Signed-off-by: Laurent Pinchart Acked-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- Documentation/DocBook/media-entities.tmpl | 12 ++ Documentation/DocBook/v4l/media-controller.xml | 10 ++ Documentation/DocBook/v4l/media-func-close.xml | 59 +++++++++ Documentation/DocBook/v4l/media-func-ioctl.xml | 116 ++++++++++++++++++ Documentation/DocBook/v4l/media-func-open.xml | 94 +++++++++++++++ .../DocBook/v4l/media-ioc-device-info.xml | 132 +++++++++++++++++++++ 6 files changed, 423 insertions(+) create mode 100644 Documentation/DocBook/v4l/media-func-close.xml create mode 100644 Documentation/DocBook/v4l/media-func-ioctl.xml create mode 100644 Documentation/DocBook/v4l/media-func-open.xml create mode 100644 Documentation/DocBook/v4l/media-ioc-device-info.xml (limited to 'Documentation') diff --git a/Documentation/DocBook/media-entities.tmpl b/Documentation/DocBook/media-entities.tmpl index c47897f046b1..034f891399ed 100644 --- a/Documentation/DocBook/media-entities.tmpl +++ b/Documentation/DocBook/media-entities.tmpl @@ -11,6 +11,10 @@ select()"> write()"> +close()"> +ioctl()"> +open()"> + VIDIOC_CROPCAP"> VIDIOC_DBG_G_CHIP_IDENT"> @@ -87,6 +91,8 @@ VIDIOC_TRY_FMT"> VIDIOC_UNSUBSCRIBE_EVENT"> +MEDIA_IOC_DEVICE_INFO"> + v4l2_std_id"> @@ -184,6 +190,8 @@ v4l2_vbi_format"> v4l2_window"> +media_device_info"> + EACCES error code"> EAGAIN error code"> @@ -328,6 +336,10 @@ + + + + diff --git a/Documentation/DocBook/v4l/media-controller.xml b/Documentation/DocBook/v4l/media-controller.xml index f89228d3ec2a..a46b786e9f2b 100644 --- a/Documentation/DocBook/v4l/media-controller.xml +++ b/Documentation/DocBook/v4l/media-controller.xml @@ -74,3 +74,13 @@ pad to a sink pad. + + + Function Reference + + &sub-media-open; + &sub-media-close; + &sub-media-ioctl; + + &sub-media-ioc-device-info; + diff --git a/Documentation/DocBook/v4l/media-func-close.xml b/Documentation/DocBook/v4l/media-func-close.xml new file mode 100644 index 000000000000..be149c802aeb --- /dev/null +++ b/Documentation/DocBook/v4l/media-func-close.xml @@ -0,0 +1,59 @@ + + + media close() + &manvol; + + + + media-close + Close a media device + + + + + #include <unistd.h> + + int close + int fd + + + + + + Arguments + + + + fd + + &fd; + + + + + + + Description + + Closes the media device. Resources associated with the file descriptor + are freed. The device configuration remain unchanged. + + + + Return Value + + close returns 0 on success. On error, -1 is + returned, and errno is set appropriately. Possible error + codes are: + + + + EBADF + + fd is not a valid open file descriptor. + + + + + + diff --git a/Documentation/DocBook/v4l/media-func-ioctl.xml b/Documentation/DocBook/v4l/media-func-ioctl.xml new file mode 100644 index 000000000000..bda8604de15c --- /dev/null +++ b/Documentation/DocBook/v4l/media-func-ioctl.xml @@ -0,0 +1,116 @@ + + + media ioctl() + &manvol; + + + + media-ioctl + Control a media device + + + + + #include <sys/ioctl.h> + + int ioctl + int fd + int request + void *argp + + + + + + Arguments + + + + fd + + &fd; + + + + request + + Media ioctl request code as defined in the media.h header file, + for example MEDIA_IOC_SETUP_LINK. + + + + argp + + Pointer to a request-specific structure. + + + + + + + Description + The ioctl() function manipulates media device + parameters. The argument fd must be an open file + descriptor. + The ioctl request code specifies the media + function to be called. It has encoded in it whether the argument is an + input, output or read/write parameter, and the size of the argument + argp in bytes. + Macros and structures definitions specifying media ioctl requests and + their parameters are located in the media.h header file. All media ioctl + requests, their respective function and parameters are specified in + . + + + + Return Value + + ioctl() returns 0 on + success. On failure, -1 is returned, and the + errno variable is set appropriately. Generic error codes + are listed below, and request-specific error codes are listed in the + individual requests descriptions. + When an ioctl that takes an output or read/write parameter fails, + the parameter remains unmodified. + + + + EBADF + + fd is not a valid open file descriptor. + + + + + EFAULT + + argp references an inaccessible memory + area. + + + + EINVAL + + The request or the data pointed to by + argp is not valid. This is a very common error + code, see the individual ioctl requests listed in + for actual causes. + + + + ENOMEM + + Insufficient kernel memory was available to complete the + request. + + + + ENOTTY + + fd is not associated with a character + special device. + + + + + diff --git a/Documentation/DocBook/v4l/media-func-open.xml b/Documentation/DocBook/v4l/media-func-open.xml new file mode 100644 index 000000000000..f7df034dc9ed --- /dev/null +++ b/Documentation/DocBook/v4l/media-func-open.xml @@ -0,0 +1,94 @@ + + + media open() + &manvol; + + + + media-open + Open a media device + + + + + #include <fcntl.h> + + int open + const char *device_name + int flags + + + + + + Arguments + + + + device_name + + Device to be opened. + + + + flags + + Open flags. Access mode must be either O_RDONLY + or O_RDWR. Other flags have no effect. + + + + + + Description + To open a media device applications call open() + with the desired device name. The function has no side effects; the device + configuration remain unchanged. + When the device is opened in read-only mode, attemps to modify its + configuration will result in an error, and errno will be + set to EBADF. + + + Return Value + + open returns the new file descriptor on success. + On error, -1 is returned, and errno is set appropriately. + Possible error codes are: + + + + EACCES + + The requested access to the file is not allowed. + + + + EMFILE + + The process already has the maximum number of files open. + + + + + ENFILE + + The system limit on the total number of open files has been + reached. + + + + ENOMEM + + Insufficient kernel memory was available. + + + + ENXIO + + No device corresponding to this device special file exists. + + + + + + diff --git a/Documentation/DocBook/v4l/media-ioc-device-info.xml b/Documentation/DocBook/v4l/media-ioc-device-info.xml new file mode 100644 index 000000000000..278a3120ee2e --- /dev/null +++ b/Documentation/DocBook/v4l/media-ioc-device-info.xml @@ -0,0 +1,132 @@ + + + ioctl MEDIA_IOC_DEVICE_INFO + &manvol; + + + + MEDIA_IOC_DEVICE_INFO + Query device information + + + + + + int ioctl + int fd + int request + struct media_device_info *argp + + + + + + Arguments + + + + fd + + &fd; + + + + request + + MEDIA_IOC_DEVICE_INFO + + + + argp + + + + + + + + + Description + + All media devices must support the MEDIA_IOC_DEVICE_INFO + ioctl. To query device information, applications call the ioctl with a + pointer to a &media-device-info;. The driver fills the structure and returns + the information to the application. + The ioctl never fails. + + + struct <structname>media_device_info</structname> + + &cs-str; + + + char + driver[16] + Name of the driver implementing the media API as a + NUL-terminated ASCII string. The driver version is stored in the + driver_version field. + Driver specific applications can use this information to + verify the driver identity. It is also useful to work around + known bugs, or to identify drivers in error reports. + + + char + model[32] + Device model name as a NUL-terminated UTF-8 string. The + device version is stored in the device_version + field and is not be appended to the model name. + + + char + serial[40] + Serial number as a NUL-terminated ASCII string. + + + char + bus_info[32] + Location of the device in the system as a NUL-terminated + ASCII string. This includes the bus type name (PCI, USB, ...) and a + bus-specific identifier. + + + __u32 + media_version + Media API version, formatted with the + KERNEL_VERSION() macro. + + + __u32 + hw_revision + Hardware device revision in a driver-specific format. + + + __u32 + media_version + Media device driver version, formatted with the + KERNEL_VERSION() macro. Together with the + driver field this identifies a particular + driver. + + + __u32 + reserved[31] + Reserved for future extensions. Drivers and applications must + set this array to zero. + + + +
+ The serial and bus_info + fields can be used to distinguish between multiple instances of otherwise + identical hardware. The serial number takes precedence when provided and can + be assumed to be unique. If the serial number is an empty string, the + bus_info field can be used instead. The + bus_info field is guaranteed to be unique, but + can vary across reboots or device unplug/replug. + + + + Return value + This function doesn't return specific error codes. + + -- cgit v1.2.3 From 1651333b09743887bc2dd3d158a11853a2be3fe7 Mon Sep 17 00:00:00 2001 From: Laurent Pinchart Date: Wed, 9 Dec 2009 08:40:01 -0300 Subject: [media] media: Entities, pads and links enumeration Create the following two ioctls and implement them at the media device level to enumerate entities, pads and links. - MEDIA_IOC_ENUM_ENTITIES: Enumerate entities and their properties - MEDIA_IOC_ENUM_LINKS: Enumerate all pads and links for a given entity Entity IDs can be non-contiguous. Userspace applications should enumerate entities using the MEDIA_ENT_ID_FLAG_NEXT flag. When the flag is set in the entity ID, the MEDIA_IOC_ENUM_ENTITIES will return the next entity with an ID bigger than the requested one. Only forward links that originate at one of the entity's source pads are returned during the enumeration process. Signed-off-by: Laurent Pinchart Signed-off-by: Sakari Ailus Acked-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- Documentation/DocBook/media-entities.tmpl | 8 + Documentation/DocBook/v4l/media-controller.xml | 2 + .../DocBook/v4l/media-ioc-device-info.xml | 3 +- .../DocBook/v4l/media-ioc-enum-entities.xml | 308 +++++++++++++++++++++ Documentation/DocBook/v4l/media-ioc-enum-links.xml | 202 ++++++++++++++ 5 files changed, 522 insertions(+), 1 deletion(-) create mode 100644 Documentation/DocBook/v4l/media-ioc-enum-entities.xml create mode 100644 Documentation/DocBook/v4l/media-ioc-enum-links.xml (limited to 'Documentation') diff --git a/Documentation/DocBook/media-entities.tmpl b/Documentation/DocBook/media-entities.tmpl index 034f891399ed..2bd7b27f8553 100644 --- a/Documentation/DocBook/media-entities.tmpl +++ b/Documentation/DocBook/media-entities.tmpl @@ -92,6 +92,8 @@ VIDIOC_UNSUBSCRIBE_EVENT"> MEDIA_IOC_DEVICE_INFO"> +MEDIA_IOC_ENUM_ENTITIES"> +MEDIA_IOC_ENUM_LINKS"> v4l2_std_id"> @@ -191,6 +193,10 @@ v4l2_window"> media_device_info"> +media_entity_desc"> +media_links_enum"> +media_pad_desc"> +media_link_desc"> EACCES error code"> @@ -340,6 +346,8 @@ + + diff --git a/Documentation/DocBook/v4l/media-controller.xml b/Documentation/DocBook/v4l/media-controller.xml index a46b786e9f2b..2c4fd2b27683 100644 --- a/Documentation/DocBook/v4l/media-controller.xml +++ b/Documentation/DocBook/v4l/media-controller.xml @@ -83,4 +83,6 @@ &sub-media-ioctl; &sub-media-ioc-device-info; + &sub-media-ioc-enum-entities; + &sub-media-ioc-enum-links; diff --git a/Documentation/DocBook/v4l/media-ioc-device-info.xml b/Documentation/DocBook/v4l/media-ioc-device-info.xml index 278a3120ee2e..1f3237351bba 100644 --- a/Documentation/DocBook/v4l/media-ioc-device-info.xml +++ b/Documentation/DocBook/v4l/media-ioc-device-info.xml @@ -27,7 +27,8 @@ fd - &fd; + File descriptor returned by + open(). diff --git a/Documentation/DocBook/v4l/media-ioc-enum-entities.xml b/Documentation/DocBook/v4l/media-ioc-enum-entities.xml new file mode 100644 index 000000000000..13d0cc44865a --- /dev/null +++ b/Documentation/DocBook/v4l/media-ioc-enum-entities.xml @@ -0,0 +1,308 @@ + + + ioctl MEDIA_IOC_ENUM_ENTITIES + &manvol; + + + + MEDIA_IOC_ENUM_ENTITIES + Enumerate entities and their properties + + + + + + int ioctl + int fd + int request + struct media_entity_desc *argp + + + + + + Arguments + + + + fd + + File descriptor returned by + open(). + + + + request + + MEDIA_IOC_ENUM_ENTITIES + + + + argp + + + + + + + + + Description + To query the attributes of an entity, applications set the id field + of a &media-entity-desc; structure and call the MEDIA_IOC_ENUM_ENTITIES + ioctl with a pointer to this structure. The driver fills the rest of the + structure or returns an &EINVAL; when the id is invalid. + Entities can be enumerated by or'ing the id with the + MEDIA_ENT_ID_FLAG_NEXT flag. The driver will return + information about the entity with the smallest id strictly larger than the + requested one ('next entity'), or the &EINVAL; if there is none. + Entity IDs can be non-contiguous. Applications must + not try to enumerate entities by calling + MEDIA_IOC_ENUM_ENTITIES with increasing id's until they get an error. + Two or more entities that share a common non-zero + group_id value are considered as logically + grouped. Groups are used to report + + ALSA, VBI and video nodes that carry the same media + stream + lens and flash controllers associated with a sensor + + + + + struct <structname>media_entity_desc</structname> + + + + + + + + + __u32 + id + + + Entity id, set by the application. When the id is or'ed with + MEDIA_ENT_ID_FLAG_NEXT, the driver clears the + flag and returns the first entity with a larger id. + + + char + name[32] + + + Entity name as an UTF-8 NULL-terminated string. + + + __u32 + type + + + Entity type, see for details. + + + __u32 + revision + + + Entity revision in a driver/hardware specific format. + + + __u32 + flags + + + Entity flags, see for details. + + + __u32 + group_id + + + Entity group ID + + + __u16 + pads + + + Number of pads + + + __u16 + links + + + Total number of outbound links. Inbound links are not counted + in this field. + + + union + + + + struct + v4l + + Valid for V4L sub-devices and nodes only. + + + + + __u32 + major + V4L device node major number. For V4L sub-devices with no + device node, set by the driver to 0. + + + + + __u32 + minor + V4L device node minor number. For V4L sub-devices with no + device node, set by the driver to 0. + + + + struct + fb + + Valid for frame buffer nodes only. + + + + + __u32 + major + Frame buffer device node major number. + + + + + __u32 + minor + Frame buffer device node minor number. + + + + struct + alsa + + Valid for ALSA devices only. + + + + + __u32 + card + ALSA card number + + + + + __u32 + device + ALSA device number + + + + + __u32 + subdevice + ALSA sub-device number + + + + int + dvb + + DVB card number + + + + __u8 + raw[180] + + + + + +
+ + + Media entity types + + + + + + MEDIA_ENT_T_DEVNODE + Unknown device node + + + MEDIA_ENT_T_DEVNODE_V4L + V4L video, radio or vbi device node + + + MEDIA_ENT_T_DEVNODE_FB + Frame buffer device node + + + MEDIA_ENT_T_DEVNODE_ALSA + ALSA card + + + MEDIA_ENT_T_DEVNODE_DVB + DVB card + + + MEDIA_ENT_T_V4L2_SUBDEV + Unknown V4L sub-device + + + MEDIA_ENT_T_V4L2_SUBDEV_SENSOR + Video sensor + + + MEDIA_ENT_T_V4L2_SUBDEV_FLASH + Flash controller + + + MEDIA_ENT_T_V4L2_SUBDEV_LENS + Lens controller + + + +
+ + + Media entity flags + + + + + + MEDIA_ENT_FL_DEFAULT + Default entity for its type. Used to discover the default + audio, VBI and video devices, the default camera sensor, ... + + + +
+ + + + &return-value; + + + + EINVAL + + The &media-entity-desc; id references + a non-existing entity. + + + + + diff --git a/Documentation/DocBook/v4l/media-ioc-enum-links.xml b/Documentation/DocBook/v4l/media-ioc-enum-links.xml new file mode 100644 index 000000000000..6da884159cab --- /dev/null +++ b/Documentation/DocBook/v4l/media-ioc-enum-links.xml @@ -0,0 +1,202 @@ + + + ioctl MEDIA_IOC_ENUM_LINKS + &manvol; + + + + MEDIA_IOC_ENUM_LINKS + Enumerate all pads and links for a given entity + + + + + + int ioctl + int fd + int request + struct media_links_enum *argp + + + + + + Arguments + + + + fd + + File descriptor returned by + open(). + + + + request + + MEDIA_IOC_ENUM_LINKS + + + + argp + + + + + + + + + Description + + To enumerate pads and/or links for a given entity, applications set + the entity field of a &media-links-enum; structure and initialize the + &media-pad-desc; and &media-link-desc; structure arrays pointed by the + pads and links fields. + They then call the MEDIA_IOC_ENUM_LINKS ioctl with a pointer to this + structure. + If the pads field is not NULL, the driver + fills the pads array with information about the + entity's pads. The array must have enough room to store all the entity's + pads. The number of pads can be retrieved with the &MEDIA-IOC-ENUM-ENTITIES; + ioctl. + If the links field is not NULL, the driver + fills the links array with information about the + entity's outbound links. The array must have enough room to store all the + entity's outbound links. The number of outbound links can be retrieved with + the &MEDIA-IOC-ENUM-ENTITIES; ioctl. + Only forward links that originate at one of the entity's source pads + are returned during the enumeration process. + + + struct <structname>media_links_enum</structname> + + &cs-str; + + + __u32 + entity + Entity id, set by the application. + + + struct &media-pad-desc; + *pads + Pointer to a pads array allocated by the application. Ignored + if NULL. + + + struct &media-link-desc; + *links + Pointer to a links array allocated by the application. Ignored + if NULL. + + + + + + + struct <structname>media_pad_desc</structname> + + &cs-str; + + + __u32 + entity + ID of the entity this pad belongs to. + + + __u16 + index + 0-based pad index. + + + __u32 + flags + Pad flags, see for more details. + + + +
+ + + Media pad flags + + + + + + MEDIA_PAD_FL_SINK + Input pad, relative to the entity. Input pads sink data and + are targets of links. + + + MEDIA_PAD_FL_SOURCE + Output pad, relative to the entity. Output pads source data + and are origins of links. + + + +
+ + + struct <structname>media_links_desc</structname> + + &cs-str; + + + struct &media-pad-desc; + source + Pad at the origin of this link. + + + struct &media-pad-desc; + sink + Pad at the target of this link. + + + __u32 + flags + Link flags, see for more details. + + + + + + + Media link flags + + + + + + MEDIA_LNK_FL_ENABLED + The link is enabled and can be used to transfer media data. + When two or more links target a sink pad, only one of them can be + enabled at a time. + + + MEDIA_LNK_FL_IMMUTABLE + The link enabled state can't be modified at runtime. An + immutable link is always enabled. + + + + + One and only one of MEDIA_PAD_FL_SINK and + MEDIA_PAD_FL_SOURCE must be set for every pad. + + + + &return-value; + + + + EINVAL + + The &media-links-enum; id references + a non-existing entity. + + + + + -- cgit v1.2.3 From 97548ed4c4661502cdfd1aabd5d3876fa4f5cc2e Mon Sep 17 00:00:00 2001 From: Laurent Pinchart Date: Wed, 9 Dec 2009 08:40:03 -0300 Subject: [media] media: Links setup Create the following ioctl and implement it at the media device level to setup links. - MEDIA_IOC_SETUP_LINK: Modify the properties of a given link The only property that can currently be modified is the ENABLED link flag to enable/disable a link. Links marked with the IMMUTABLE link flag can not be enabled or disabled. Enabling or disabling a link has effects on entities' use count. Those changes are automatically propagated through the graph. Signed-off-by: Laurent Pinchart Signed-off-by: Stanimir Varbanov Signed-off-by: Sakari Ailus Acked-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- Documentation/DocBook/media-entities.tmpl | 2 + Documentation/DocBook/v4l/media-controller.xml | 1 + Documentation/DocBook/v4l/media-ioc-setup-link.xml | 90 ++++++++++++++++++++++ Documentation/media-framework.txt | 42 ++++++++++ 4 files changed, 135 insertions(+) create mode 100644 Documentation/DocBook/v4l/media-ioc-setup-link.xml (limited to 'Documentation') diff --git a/Documentation/DocBook/media-entities.tmpl b/Documentation/DocBook/media-entities.tmpl index 2bd7b27f8553..121db1549244 100644 --- a/Documentation/DocBook/media-entities.tmpl +++ b/Documentation/DocBook/media-entities.tmpl @@ -94,6 +94,7 @@ MEDIA_IOC_DEVICE_INFO"> MEDIA_IOC_ENUM_ENTITIES"> MEDIA_IOC_ENUM_LINKS"> +MEDIA_IOC_SETUP_LINK"> v4l2_std_id"> @@ -348,6 +349,7 @@ + diff --git a/Documentation/DocBook/v4l/media-controller.xml b/Documentation/DocBook/v4l/media-controller.xml index 2c4fd2b27683..2dc25e1d4089 100644 --- a/Documentation/DocBook/v4l/media-controller.xml +++ b/Documentation/DocBook/v4l/media-controller.xml @@ -85,4 +85,5 @@ &sub-media-ioc-device-info; &sub-media-ioc-enum-entities; &sub-media-ioc-enum-links; + &sub-media-ioc-setup-link; diff --git a/Documentation/DocBook/v4l/media-ioc-setup-link.xml b/Documentation/DocBook/v4l/media-ioc-setup-link.xml new file mode 100644 index 000000000000..09ab3d2b3a52 --- /dev/null +++ b/Documentation/DocBook/v4l/media-ioc-setup-link.xml @@ -0,0 +1,90 @@ + + + ioctl MEDIA_IOC_SETUP_LINK + &manvol; + + + + MEDIA_IOC_SETUP_LINK + Modify the properties of a link + + + + + + int ioctl + int fd + int request + struct media_link_desc *argp + + + + + + Arguments + + + + fd + + File descriptor returned by + open(). + + + + request + + MEDIA_IOC_ENUM_LINKS + + + + argp + + + + + + + + + Description + + To change link properties applications fill a &media-link-desc; with + link identification information (source and sink pad) and the new requested + link flags. They then call the MEDIA_IOC_SETUP_LINK ioctl with a pointer to + that structure. + The only configurable property is the ENABLED + link flag to enable/disable a link. Links marked with the + IMMUTABLE link flag can not be enabled or disabled. + + Link configuration has no side effect on other links. If an enabled + link at the sink pad prevents the link from being enabled, the driver + returns with an &EBUSY;. + If the specified link can't be found the driver returns with an + &EINVAL;. + + + + &return-value; + + + + EBUSY + + The link properties can't be changed because the link is + currently busy. This can be caused, for instance, by an active media + stream (audio or video) on the link. The ioctl shouldn't be retried if + no other action is performed before to fix the problem. + + + + EINVAL + + The &media-link-desc; references a non-existing link, or the + link is immutable and an attempt to modify its configuration was made. + + + + + + diff --git a/Documentation/media-framework.txt b/Documentation/media-framework.txt index 78ae02095372..4809221c0ff9 100644 --- a/Documentation/media-framework.txt +++ b/Documentation/media-framework.txt @@ -259,6 +259,16 @@ When the graph traversal is complete the function will return NULL. Graph traversal can be interrupted at any moment. No cleanup function call is required and the graph structure can be freed normally. +Helper functions can be used to find a link between two given pads, or a pad +connected to another pad through an enabled link + + media_entity_find_link(struct media_pad *source, + struct media_pad *sink); + + media_entity_remote_source(struct media_pad *pad); + +Refer to the kerneldoc documentation for more information. + Use count and power handling ---------------------------- @@ -271,3 +281,35 @@ track the number of users of every entity for power management needs. The use_count field is owned by media drivers and must not be touched by entity drivers. Access to the field must be protected by the media device graph_mutex lock. + + +Links setup +----------- + +Link properties can be modified at runtime by calling + + media_entity_setup_link(struct media_link *link, u32 flags); + +The flags argument contains the requested new link flags. + +The only configurable property is the ENABLED link flag to enable/disable a +link. Links marked with the IMMUTABLE link flag can not be enabled or disabled. + +When a link is enabled or disabled, the media framework calls the +link_setup operation for the two entities at the source and sink of the link, +in that order. If the second link_setup call fails, another link_setup call is +made on the first entity to restore the original link flags. + +Media device drivers can be notified of link setup operations by setting the +media_device::link_notify pointer to a callback function. If provided, the +notification callback will be called before enabling and after disabling +links. + +Entity drivers must implement the link_setup operation if any of their links +is non-immutable. The operation must either configure the hardware or store +the configuration information to be applied later. + +Link configuration must not have any side effect on other links. If an enabled +link at a sink pad prevents another link at the same pad from being disabled, +the link_setup operation must return -EBUSY and can't implicitly disable the +first enabled link. -- cgit v1.2.3 From e02188c90f6ef61f0844c42508fe603c5d4fa42b Mon Sep 17 00:00:00 2001 From: Laurent Pinchart Date: Wed, 25 Aug 2010 09:00:41 -0300 Subject: [media] media: Pipelines and media streams Drivers often need to associate pipeline objects to entities, and to take stream state into account when configuring entities and links. The pipeline API helps drivers manage that information. When starting streaming, drivers call media_entity_pipeline_start(). The function marks all entities connected to the given entity through enabled links, either directly or indirectly, as streaming. Similarly, when stopping the stream, drivers call media_entity_pipeline_stop(). The media_entity_pipeline_start() function takes a pointer to a media pipeline and stores it in every entity in the graph. Drivers should embed the media_pipeline structure in higher-level pipeline structures and can then access the pipeline through the media_entity structure. Link configuration will fail with -EBUSY by default if either end of the link is a streaming entity, unless the link is marked with the MEDIA_LNK_FL_DYNAMIC flag. Signed-off-by: Laurent Pinchart Acked-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- Documentation/DocBook/v4l/media-ioc-enum-links.xml | 5 +++ Documentation/DocBook/v4l/media-ioc-setup-link.xml | 3 ++ Documentation/media-framework.txt | 38 ++++++++++++++++++++++ 3 files changed, 46 insertions(+) (limited to 'Documentation') diff --git a/Documentation/DocBook/v4l/media-ioc-enum-links.xml b/Documentation/DocBook/v4l/media-ioc-enum-links.xml index 6da884159cab..d2fc73ef8d56 100644 --- a/Documentation/DocBook/v4l/media-ioc-enum-links.xml +++ b/Documentation/DocBook/v4l/media-ioc-enum-links.xml @@ -179,6 +179,11 @@ The link enabled state can't be modified at runtime. An immutable link is always enabled. + + MEDIA_LNK_FL_DYNAMIC + The link enabled state can be modified during streaming. This + flag is set by drivers and is read-only for applications. + diff --git a/Documentation/DocBook/v4l/media-ioc-setup-link.xml b/Documentation/DocBook/v4l/media-ioc-setup-link.xml index 09ab3d2b3a52..2331e76ded17 100644 --- a/Documentation/DocBook/v4l/media-ioc-setup-link.xml +++ b/Documentation/DocBook/v4l/media-ioc-setup-link.xml @@ -60,6 +60,9 @@ Link configuration has no side effect on other links. If an enabled link at the sink pad prevents the link from being enabled, the driver returns with an &EBUSY;. + Only links marked with the DYNAMIC link flag can + be enabled/disabled while streaming media data. Attempting to enable or + disable a streaming non-dynamic link will return an &EBUSY;. If the specified link can't be found the driver returns with an &EINVAL;. diff --git a/Documentation/media-framework.txt b/Documentation/media-framework.txt index 4809221c0ff9..fd48add02cb0 100644 --- a/Documentation/media-framework.txt +++ b/Documentation/media-framework.txt @@ -313,3 +313,41 @@ Link configuration must not have any side effect on other links. If an enabled link at a sink pad prevents another link at the same pad from being disabled, the link_setup operation must return -EBUSY and can't implicitly disable the first enabled link. + + +Pipelines and media streams +--------------------------- + +When starting streaming, drivers must notify all entities in the pipeline to +prevent link states from being modified during streaming by calling + + media_entity_pipeline_start(struct media_entity *entity, + struct media_pipeline *pipe); + +The function will mark all entities connected to the given entity through +enabled links, either directly or indirectly, as streaming. + +The media_pipeline instance pointed to by the pipe argument will be stored in +every entity in the pipeline. Drivers should embed the media_pipeline structure +in higher-level pipeline structures and can then access the pipeline through +the media_entity pipe field. + +Calls to media_entity_pipeline_start() can be nested. The pipeline pointer must +be identical for all nested calls to the function. + +When stopping the stream, drivers must notify the entities with + + media_entity_pipeline_stop(struct media_entity *entity); + +If multiple calls to media_entity_pipeline_start() have been made the same +number of media_entity_pipeline_stop() calls are required to stop streaming. The +media_entity pipe field is reset to NULL on the last nested stop call. + +Link configuration will fail with -EBUSY by default if either end of the link is +a streaming entity. Links that can be modified while streaming must be marked +with the MEDIA_LNK_FL_DYNAMIC flag. + +If other operations need to be disallowed on streaming entities (such as +changing entities configuration parameters) drivers can explictly check the +media_entity stream_count field to find out if an entity is streaming. This +operation must be done with the media_device graph_mutex held. -- cgit v1.2.3 From 95db3a60e0652a52df145aacade1a88c5acef659 Mon Sep 17 00:00:00 2001 From: Laurent Pinchart Date: Wed, 9 Dec 2009 08:40:05 -0300 Subject: [media] v4l: Add a media_device pointer to the v4l2_device structure The pointer will later be used to register/unregister media entities when registering/unregistering a v4l2_subdev or a video_device. With the introduction of media devices, device drivers need to store a pointer to a driver-specific structure in the device's drvdata. v4l2_device can't claim ownership of the drvdata anymore. To maintain compatibility with drivers that rely on v4l2_device storing a pointer to itself in the device's drvdata, v4l2_device_register() will keep doing so if the drvdata is NULL. Signed-off-by: Laurent Pinchart Acked-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- Documentation/video4linux/v4l2-framework.txt | 17 ++++++++++++----- 1 file changed, 12 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/video4linux/v4l2-framework.txt b/Documentation/video4linux/v4l2-framework.txt index eb8479565dc4..7de55cfae04e 100644 --- a/Documentation/video4linux/v4l2-framework.txt +++ b/Documentation/video4linux/v4l2-framework.txt @@ -83,11 +83,17 @@ You must register the device instance: v4l2_device_register(struct device *dev, struct v4l2_device *v4l2_dev); -Registration will initialize the v4l2_device struct and link dev->driver_data -to v4l2_dev. If v4l2_dev->name is empty then it will be set to a value derived -from dev (driver name followed by the bus_id, to be precise). If you set it -up before calling v4l2_device_register then it will be untouched. If dev is -NULL, then you *must* setup v4l2_dev->name before calling v4l2_device_register. +Registration will initialize the v4l2_device struct. If the dev->driver_data +field is NULL, it will be linked to v4l2_dev. Drivers that use the media +device framework in addition to the V4L2 framework need to set +dev->driver_data manually to point to the driver-specific device structure +that embed the struct v4l2_device instance. This is achieved by a +dev_set_drvdata() call before registering the V4L2 device instance. + +If v4l2_dev->name is empty then it will be set to a value derived from dev +(driver name followed by the bus_id, to be precise). If you set it up before +calling v4l2_device_register then it will be untouched. If dev is NULL, then +you *must* setup v4l2_dev->name before calling v4l2_device_register. You can use v4l2_device_set_name() to set the name based on a driver name and a driver-global atomic_t instance. This will generate names like ivtv0, ivtv1, @@ -108,6 +114,7 @@ You unregister with: v4l2_device_unregister(struct v4l2_device *v4l2_dev); +If the dev->driver_data field points to v4l2_dev, it will be reset to NULL. Unregistering will also automatically unregister all subdevs from the device. If you have a hotpluggable device (e.g. a USB device), then when a disconnect -- cgit v1.2.3 From 2c0ab67be1b4197a4effac89bb0604832e38be8d Mon Sep 17 00:00:00 2001 From: Laurent Pinchart Date: Wed, 9 Dec 2009 08:40:10 -0300 Subject: [media] v4l: Make video_device inherit from media_entity V4L2 devices are media entities. As such they need to inherit from (include) the media_entity structure. When registering/unregistering the device, the media entity is automatically registered/unregistered. The entity is acquired on device open and released on device close. Signed-off-by: Laurent Pinchart Signed-off-by: Sakari Ailus Acked-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- Documentation/video4linux/v4l2-framework.txt | 38 +++++++++++++++++++++++++--- 1 file changed, 35 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/video4linux/v4l2-framework.txt b/Documentation/video4linux/v4l2-framework.txt index 7de55cfae04e..062708169def 100644 --- a/Documentation/video4linux/v4l2-framework.txt +++ b/Documentation/video4linux/v4l2-framework.txt @@ -71,6 +71,10 @@ sub-device instances, the video_device struct stores V4L2 device node data and in the future a v4l2_fh struct will keep track of filehandle instances (this is not yet implemented). +The V4L2 framework also optionally integrates with the media framework. If a +driver sets the struct v4l2_device mdev field, sub-devices and video nodes +will automatically appear in the media framework as entities. + struct v4l2_device ------------------ @@ -84,11 +88,14 @@ You must register the device instance: v4l2_device_register(struct device *dev, struct v4l2_device *v4l2_dev); Registration will initialize the v4l2_device struct. If the dev->driver_data -field is NULL, it will be linked to v4l2_dev. Drivers that use the media -device framework in addition to the V4L2 framework need to set +field is NULL, it will be linked to v4l2_dev. + +Drivers that want integration with the media device framework need to set dev->driver_data manually to point to the driver-specific device structure that embed the struct v4l2_device instance. This is achieved by a -dev_set_drvdata() call before registering the V4L2 device instance. +dev_set_drvdata() call before registering the V4L2 device instance. They must +also set the struct v4l2_device mdev field to point to a properly initialized +and registered media_device instance. If v4l2_dev->name is empty then it will be set to a value derived from dev (driver name followed by the bus_id, to be precise). If you set it up before @@ -530,6 +537,21 @@ If you use v4l2_ioctl_ops, then you should set either .unlocked_ioctl or The v4l2_file_operations struct is a subset of file_operations. The main difference is that the inode argument is omitted since it is never used. +If integration with the media framework is needed, you must initialize the +media_entity struct embedded in the video_device struct (entity field) by +calling media_entity_init(): + + struct media_pad *pad = &my_vdev->pad; + int err; + + err = media_entity_init(&vdev->entity, 1, pad, 0); + +The pads array must have been previously initialized. There is no need to +manually set the struct media_entity type and name fields. + +A reference to the entity will be automatically acquired/released when the +video device is opened/closed. + v4l2_file_operations and locking -------------------------------- @@ -559,6 +581,9 @@ for you. return err; } +If the v4l2_device parent device has a non-NULL mdev field, the video device +entity will be automatically registered with the media device. + Which device is registered depends on the type argument. The following types exist: @@ -634,6 +659,13 @@ release, of course) will return an error as well. When the last user of the video device node exits, then the vdev->release() callback is called and you can do the final cleanup there. +Don't forget to cleanup the media entity associated with the video device if +it has been initialized: + + media_entity_cleanup(&vdev->entity); + +This can be done from the release callback. + video_device helper functions ----------------------------- -- cgit v1.2.3 From 61f5db549dde43fb91a8b337f3a4096e4076c2d9 Mon Sep 17 00:00:00 2001 From: Laurent Pinchart Date: Wed, 9 Dec 2009 08:40:08 -0300 Subject: [media] v4l: Make v4l2_subdev inherit from media_entity V4L2 subdevices are media entities. As such they need to inherit from (include) the media_entity structure. When registering/unregistering the subdevice, the media entity is automatically registered/unregistered. The entity is acquired on device open and released on device close. Signed-off-by: Laurent Pinchart Signed-off-by: Sakari Ailus Acked-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- Documentation/video4linux/v4l2-framework.txt | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+) (limited to 'Documentation') diff --git a/Documentation/video4linux/v4l2-framework.txt b/Documentation/video4linux/v4l2-framework.txt index 062708169def..77d96f4e3f50 100644 --- a/Documentation/video4linux/v4l2-framework.txt +++ b/Documentation/video4linux/v4l2-framework.txt @@ -268,6 +268,26 @@ A sub-device driver initializes the v4l2_subdev struct using: Afterwards you need to initialize subdev->name with a unique name and set the module owner. This is done for you if you use the i2c helper functions. +If integration with the media framework is needed, you must initialize the +media_entity struct embedded in the v4l2_subdev struct (entity field) by +calling media_entity_init(): + + struct media_pad *pads = &my_sd->pads; + int err; + + err = media_entity_init(&sd->entity, npads, pads, 0); + +The pads array must have been previously initialized. There is no need to +manually set the struct media_entity type and name fields, but the revision +field must be initialized if needed. + +A reference to the entity will be automatically acquired/released when the +subdev device node (if any) is opened/closed. + +Don't forget to cleanup the media entity before the sub-device is destroyed: + + media_entity_cleanup(&sd->entity); + A device (bridge) driver needs to register the v4l2_subdev with the v4l2_device: @@ -277,6 +297,9 @@ This can fail if the subdev module disappeared before it could be registered. After this function was called successfully the subdev->dev field points to the v4l2_device. +If the v4l2_device parent device has a non-NULL mdev field, the sub-device +entity will be automatically registered with the media device. + You can unregister a sub-device using: v4l2_device_unregister_subdev(sd); -- cgit v1.2.3 From d3a7ed99759b18e4fd19b8ddd226f8085b8bd975 Mon Sep 17 00:00:00 2001 From: Laurent Pinchart Date: Tue, 16 Mar 2010 00:26:04 +0100 Subject: [media] v4l: v4l2_subdev userspace format API - documentation binary files Add images used by the V4L2 subdev userspace format API documentation. Signed-off-by: Laurent Pinchart Acked-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- Documentation/DocBook/v4l/bayer.pdf | Bin 0 -> 12116 bytes Documentation/DocBook/v4l/bayer.png | Bin 0 -> 9725 bytes Documentation/DocBook/v4l/pipeline.pdf | Bin 0 -> 20276 bytes Documentation/DocBook/v4l/pipeline.png | Bin 0 -> 12130 bytes 4 files changed, 0 insertions(+), 0 deletions(-) create mode 100644 Documentation/DocBook/v4l/bayer.pdf create mode 100644 Documentation/DocBook/v4l/bayer.png create mode 100644 Documentation/DocBook/v4l/pipeline.pdf create mode 100644 Documentation/DocBook/v4l/pipeline.png (limited to 'Documentation') diff --git a/Documentation/DocBook/v4l/bayer.pdf b/Documentation/DocBook/v4l/bayer.pdf new file mode 100644 index 000000000000..905e60e6cd42 Binary files /dev/null and b/Documentation/DocBook/v4l/bayer.pdf differ diff --git a/Documentation/DocBook/v4l/bayer.png b/Documentation/DocBook/v4l/bayer.png new file mode 100644 index 000000000000..9b15fb22e817 Binary files /dev/null and b/Documentation/DocBook/v4l/bayer.png differ diff --git a/Documentation/DocBook/v4l/pipeline.pdf b/Documentation/DocBook/v4l/pipeline.pdf new file mode 100644 index 000000000000..ee3e37f04b6a Binary files /dev/null and b/Documentation/DocBook/v4l/pipeline.pdf differ diff --git a/Documentation/DocBook/v4l/pipeline.png b/Documentation/DocBook/v4l/pipeline.png new file mode 100644 index 000000000000..f19b86c2c24d Binary files /dev/null and b/Documentation/DocBook/v4l/pipeline.png differ -- cgit v1.2.3 From 333c8b97785d5afd5085ba3720b4d259623290f6 Mon Sep 17 00:00:00 2001 From: Laurent Pinchart Date: Mon, 15 Mar 2010 20:26:04 -0300 Subject: [media] v4l: v4l2_subdev userspace format API Add a userspace API to get, set and enumerate the media format on a subdev pad. The format at the output of a subdev usually depends on the format at its input(s). The try format operation is thus not suitable for probing format at individual pads, as it can't modify the device state and thus can't remember the format tried at the input to compute the output format. To fix the problem, pass an extra argument to the get/set format operations to select the 'try' or 'active' format. The try format is used when probing the subdev. Setting the try format must not change the device configuration but can store data for later reuse. Data storage is provided at the file-handle level so applications probing the subdev concurently won't interfere with each other. The active format is used when configuring the subdev. It's identical to the format handled by the usual get/set operations. Signed-off-by: Laurent Pinchart Signed-off-by: Stanimir Varbanov Signed-off-by: Sakari Ailus Acked-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- Documentation/DocBook/Makefile | 5 +- Documentation/DocBook/media-entities.tmpl | 16 + Documentation/DocBook/v4l/dev-subdev.xml | 280 +++ Documentation/DocBook/v4l/subdev-formats.xml | 2416 ++++++++++++++++++++ Documentation/DocBook/v4l/v4l2.xml | 4 + Documentation/DocBook/v4l/vidioc-streamon.xml | 9 + .../DocBook/v4l/vidioc-subdev-enum-frame-size.xml | 154 ++ .../DocBook/v4l/vidioc-subdev-enum-mbus-code.xml | 119 + Documentation/DocBook/v4l/vidioc-subdev-g-fmt.xml | 180 ++ 9 files changed, 3182 insertions(+), 1 deletion(-) create mode 100644 Documentation/DocBook/v4l/dev-subdev.xml create mode 100644 Documentation/DocBook/v4l/subdev-formats.xml create mode 100644 Documentation/DocBook/v4l/vidioc-subdev-enum-frame-size.xml create mode 100644 Documentation/DocBook/v4l/vidioc-subdev-enum-mbus-code.xml create mode 100644 Documentation/DocBook/v4l/vidioc-subdev-g-fmt.xml (limited to 'Documentation') diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile index 8b6e00a71034..2deb069aedf1 100644 --- a/Documentation/DocBook/Makefile +++ b/Documentation/DocBook/Makefile @@ -53,7 +53,10 @@ MAN := $(patsubst %.xml, %.9, $(BOOKS)) mandocs: $(MAN) build_images = mkdir -p $(objtree)/Documentation/DocBook/media/ && \ - cp $(srctree)/Documentation/DocBook/dvb/*.png $(srctree)/Documentation/DocBook/v4l/*.gif $(objtree)/Documentation/DocBook/media/ + cp $(srctree)/Documentation/DocBook/dvb/*.png \ + $(srctree)/Documentation/DocBook/v4l/*.gif \ + $(srctree)/Documentation/DocBook/v4l/*.png \ + $(objtree)/Documentation/DocBook/media/ xmldoclinks: ifneq ($(objtree),$(srctree)) diff --git a/Documentation/DocBook/media-entities.tmpl b/Documentation/DocBook/media-entities.tmpl index 121db1549244..dbb9cb2e1ec6 100644 --- a/Documentation/DocBook/media-entities.tmpl +++ b/Documentation/DocBook/media-entities.tmpl @@ -86,6 +86,10 @@ VIDIOC_S_PRIORITY"> VIDIOC_S_STD"> VIDIOC_S_TUNER"> +VIDIOC_SUBDEV_ENUM_FRAME_SIZE"> +VIDIOC_SUBDEV_ENUM_MBUS_CODE"> +VIDIOC_SUBDEV_G_FMT"> +VIDIOC_SUBDEV_S_FMT"> VIDIOC_TRY_ENCODER_CMD"> VIDIOC_TRY_EXT_CTRLS"> VIDIOC_TRY_FMT"> @@ -107,6 +111,7 @@ v4l2_field"> v4l2_frmivaltypes"> v4l2_frmsizetypes"> +v4l2_mbus_pixelcode"> v4l2_memory"> v4l2_mpeg_audio_ac3_bitrate"> v4l2_mpeg_audio_crc"> @@ -130,6 +135,7 @@ v4l2_mpeg_video_encoding"> v4l2_power_line_frequency"> v4l2_priority"> +v4l2_subdev_format_whence"> v4l2_tuner_type"> v4l2_preemphasis"> @@ -172,6 +178,7 @@ v4l2_hw_freq_seek"> v4l2_input"> v4l2_jpegcompression"> +v4l2_mbus_framefmt"> v4l2_modulator"> v4l2_mpeg_vbi_fmt_ivtv"> v4l2_output"> @@ -186,6 +193,9 @@ v4l2_sliced_vbi_cap"> v4l2_sliced_vbi_data"> v4l2_sliced_vbi_format"> +v4l2_subdev_frame_size_enum"> +v4l2_subdev_format"> +v4l2_subdev_mbus_code_enum"> v4l2_standard"> v4l2_streamparm"> v4l2_timecode"> @@ -215,6 +225,7 @@ ENXIO error code"> EMFILE error code"> EPERM error code"> +EPIPE error code"> ERANGE error code"> @@ -234,6 +245,7 @@ + @@ -319,6 +331,10 @@ + + + + diff --git a/Documentation/DocBook/v4l/dev-subdev.xml b/Documentation/DocBook/v4l/dev-subdev.xml new file mode 100644 index 000000000000..fc62e65f45ef --- /dev/null +++ b/Documentation/DocBook/v4l/dev-subdev.xml @@ -0,0 +1,280 @@ + Sub-device Interface + + + Experimental + This is an experimental + interface and may change in the future. + + + The complex nature of V4L2 devices, where hardware is often made of + several integrated circuits that need to interact with each other in a + controlled way, leads to complex V4L2 drivers. The drivers usually reflect + the hardware model in software, and model the different hardware components + as software blocks called sub-devices. + + V4L2 sub-devices are usually kernel-only objects. If the V4L2 driver + implements the media device API, they will automatically inherit from media + entities. Applications will be able to enumerate the sub-devices and discover + the hardware topology using the media entities, pads and links enumeration + API. + + In addition to make sub-devices discoverable, drivers can also choose + to make them directly configurable by applications. When both the sub-device + driver and the V4L2 device driver support this, sub-devices will feature a + character device node on which ioctls can be called to + + query, read and write sub-devices controls + subscribe and unsubscribe to events and retrieve them + negotiate image formats on individual pads + + + + Sub-device character device nodes, conventionally named + /dev/v4l-subdev*, use major number 81. + +
+ Controls + Most V4L2 controls are implemented by sub-device hardware. Drivers + usually merge all controls and expose them through video device nodes. + Applications can control all sub-devices through a single interface. + + Complex devices sometimes implement the same control in different + pieces of hardware. This situation is common in embedded platforms, where + both sensors and image processing hardware implement identical functions, + such as contrast adjustment, white balance or faulty pixels correction. As + the V4L2 controls API doesn't support several identical controls in a single + device, all but one of the identical controls are hidden. + + Applications can access those hidden controls through the sub-device + node with the V4L2 control API described in . The + ioctls behave identically as when issued on V4L2 device nodes, with the + exception that they deal only with controls implemented in the sub-device. + + + Depending on the driver, those controls might also be exposed through + one (or several) V4L2 device nodes. +
+ +
+ Events + V4L2 sub-devices can notify applications of events as described in + . The API behaves identically as when used on V4L2 + device nodes, with the exception that it only deals with events generated by + the sub-device. Depending on the driver, those events might also be reported + on one (or several) V4L2 device nodes. +
+ +
+ Pad-level Formats + + Pad-level formats are only applicable to very complex device that + need to expose low-level format configuration to user space. Generic V4L2 + applications do not need to use the API described in + this section. + + For the purpose of this section, the term + format means the combination of media bus data + format, frame width and frame height. + + Image formats are typically negotiated on video capture and output + devices using the cropping and scaling ioctls. + The driver is responsible for configuring every block in the video pipeline + according to the requested format at the pipeline input and/or + output. + + For complex devices, such as often found in embedded systems, + identical image sizes at the output of a pipeline can be achieved using + different hardware configurations. One such exemple is shown on + , where + image scaling can be performed on both the video sensor and the host image + processing hardware. + +
+ Image Format Negotation on Pipelines + + + + + + + + + High quality and high speed pipeline configuration + + +
+ + The sensor scaler is usually of less quality than the host scaler, but + scaling on the sensor is required to achieve higher frame rates. Depending + on the use case (quality vs. speed), the pipeline must be configured + differently. Applications need to configure the formats at every point in + the pipeline explicitly. + + Drivers that implement the media + API can expose pad-level image format configuration to applications. + When they do, applications can use the &VIDIOC-SUBDEV-G-FMT; and + &VIDIOC-SUBDEV-S-FMT; ioctls. to negotiate formats on a per-pad basis. + + Applications are responsible for configuring coherent parameters on + the whole pipeline and making sure that connected pads have compatible + formats. The pipeline is checked for formats mismatch at &VIDIOC-STREAMON; + time, and an &EPIPE; is then returned if the configuration is + invalid. + + Pad-level image format configuration support can be tested by calling + the &VIDIOC-SUBDEV-G-FMT; ioctl on pad 0. If the driver returns an &EINVAL; + pad-level format configuration is not supported by the sub-device. + +
+ Format Negotiation + + Acceptable formats on pads can (and usually do) depend on a number + of external parameters, such as formats on other pads, active links, or + even controls. Finding a combination of formats on all pads in a video + pipeline, acceptable to both application and driver, can't rely on formats + enumeration only. A format negotiation mechanism is required. + + Central to the format negotiation mechanism are the get/set format + operations. When called with the which argument + set to V4L2_SUBDEV_FORMAT_TRY, the + &VIDIOC-SUBDEV-G-FMT; and &VIDIOC-SUBDEV-S-FMT; ioctls operate on a set of + formats parameters that are not connected to the hardware configuration. + Modifying those 'try' formats leaves the device state untouched (this + applies to both the software state stored in the driver and the hardware + state stored in the device itself). + + While not kept as part of the device state, try formats are stored + in the sub-device file handles. A &VIDIOC-SUBDEV-G-FMT; call will return + the last try format set on the same sub-device file + handle. Several applications querying the same sub-device at + the same time will thus not interact with each other. + + To find out whether a particular format is supported by the device, + applications use the &VIDIOC-SUBDEV-S-FMT; ioctl. Drivers verify and, if + needed, change the requested format based on + device requirements and return the possibly modified value. Applications + can then choose to try a different format or accept the returned value and + continue. + + Formats returned by the driver during a negotiation iteration are + guaranteed to be supported by the device. In particular, drivers guarantee + that a returned format will not be further changed if passed to an + &VIDIOC-SUBDEV-S-FMT; call as-is (as long as external parameters, such as + formats on other pads or links' configuration are not changed). + + Drivers automatically propagate formats inside sub-devices. When a + try or active format is set on a pad, corresponding formats on other pads + of the same sub-device can be modified by the driver. Drivers are free to + modify formats as required by the device. However, they should comply with + the following rules when possible: + + Formats should be propagated from sink pads to source pads. + Modifying a format on a source pad should not modify the format on any + sink pad. + Sub-devices that scale frames using variable scaling factors + should reset the scale factors to default values when sink pads formats + are modified. If the 1:1 scaling ratio is supported, this means that + source pads formats should be reset to the sink pads formats. + + + + Formats are not propagated across links, as that would involve + propagating them from one sub-device file handle to another. Applications + must then take care to configure both ends of every link explicitly with + compatible formats. Identical formats on the two ends of a link are + guaranteed to be compatible. Drivers are free to accept different formats + matching device requirements as being compatible. + + + shows a sample configuration sequence for the pipeline described in + (table + columns list entity names and pad numbers). + + + Sample Pipeline Configuration + + + + + + + + + + + Sensor/0 + Frontend/0 + Frontend/1 + Scaler/0 + Scaler/1 + + + + + Initial state + 2048x1536 + - + - + - + - + + + Configure frontend input + 2048x1536 + 2048x1536 + 2046x1534 + - + - + + + Configure scaler input + 2048x1536 + 2048x1536 + 2046x1534 + 2046x1534 + 2046x1534 + + + Configure scaler output + 2048x1536 + 2048x1536 + 2046x1534 + 2046x1534 + 1280x960 + + + +
+ + + + Initial state. The sensor output is set to its native 3MP + resolution. Resolutions on the host frontend and scaler input and output + pads are undefined. + The application configures the frontend input pad resolution to + 2048x1536. The driver propagates the format to the frontend output pad. + Note that the propagated output format can be different, as in this case, + than the input format, as the hardware might need to crop pixels (for + instance when converting a Bayer filter pattern to RGB or YUV). + The application configures the scaler input pad resolution to + 2046x1534 to match the frontend output resolution. The driver propagates + the format to the scaler output pad. + The application configures the scaler output pad resolution to + 1280x960. + + + + When satisfied with the try results, applications can set the active + formats by setting the which argument to + V4L2_SUBDEV_FORMAT_TRY. Active formats are changed + exactly as try formats by drivers. To avoid modifying the hardware state + during format negotiation, applications should negotiate try formats first + and then modify the active settings using the try formats returned during + the last negotiation iteration. This guarantees that the active format + will be applied as-is by the driver without being modified. + +
+ +
+ + &sub-subdev-formats; diff --git a/Documentation/DocBook/v4l/subdev-formats.xml b/Documentation/DocBook/v4l/subdev-formats.xml new file mode 100644 index 000000000000..0cae57207006 --- /dev/null +++ b/Documentation/DocBook/v4l/subdev-formats.xml @@ -0,0 +1,2416 @@ +
+ Media Bus Formats + + + struct <structname>v4l2_mbus_framefmt</structname> + + &cs-str; + + + __u32 + width + Image width, in pixels. + + + __u32 + height + Image height, in pixels. + + + __u32 + code + Format code, from &v4l2-mbus-pixelcode;. + + + __u32 + field + Field order, from &v4l2-field;. See + for details. + + + __u32 + colorspace + Image colorspace, from &v4l2-colorspace;. See + for details. + + + __u32 + reserved[7] + Reserved for future extensions. Applications and drivers must + set the array to zero. + + + +
+ +
+ Media Bus Pixel Codes + + The media bus pixel codes describe image formats as flowing over + physical busses (both between separate physical components and inside SoC + devices). This should not be confused with the V4L2 pixel formats that + describe, using four character codes, image formats as stored in memory. + + + While there is a relationship between image formats on busses and + image formats in memory (a raw Bayer image won't be magically converted to + JPEG just by storing it to memory), there is no one-to-one correspondance + between them. + +
+ Packed RGB Formats + + Those formats transfer pixel data as red, green and blue components. + The format code is made of the following information. + + The red, green and blue components order code, as encoded in a + pixel sample. Possible values are RGB and BGR. + The number of bits per component, for each component. The values + can be different for all components. Common values are 555 and 565. + + The number of bus samples per pixel. Pixels that are wider than + the bus width must be transferred in multiple samples. Common values are + 1 and 2. + The bus width. + For formats where the total number of bits per pixel is smaller + than the number of bus samples per pixel times the bus width, a padding + value stating if the bytes are padded in their most high order bits + (PADHI) or low order bits (PADLO). + For formats where the number of bus samples per pixel is larger + than 1, an endianness value stating if the pixel is transferred MSB first + (BE) or LSB first (LE). + + + + For instance, a format where pixels are encoded as 5-bits red, 5-bits + green and 5-bit blue values padded on the high bit, transferred as 2 8-bit + samples per pixel with the most significant bits (padding, red and half of + the green value) transferred first will be named + V4L2_MBUS_FMT_RGB555_2X8_PADHI_BE. + + + The following tables list existing packet RGB formats. + + + RGB formats + + + + + + + + + + + + + + + + Identifier + Code + + Data organization + + + + + Bit + 7 + 6 + 5 + 4 + 3 + 2 + 1 + 0 + + + + + V4L2_MBUS_FMT_RGB444_2X8_PADHI_BE + 0x1001 + + 0 + 0 + 0 + 0 + r3 + r2 + r1 + r0 + + + + + + g3 + g2 + g1 + g0 + b3 + b2 + b1 + b0 + + + V4L2_MBUS_FMT_RGB444_2X8_PADHI_LE + 0x1002 + + g3 + g2 + g1 + g0 + b3 + b2 + b1 + b0 + + + + + + 0 + 0 + 0 + 0 + r3 + r2 + r1 + r0 + + + V4L2_MBUS_FMT_RGB555_2X8_PADHI_BE + 0x1003 + + 0 + r4 + r3 + r2 + r1 + r0 + g4 + g3 + + + + + + g2 + g1 + g0 + b4 + b3 + b2 + b1 + b0 + + + V4L2_MBUS_FMT_RGB555_2X8_PADHI_LE + 0x1004 + + g2 + g1 + g0 + b4 + b3 + b2 + b1 + b0 + + + + + + 0 + r4 + r3 + r2 + r1 + r0 + g4 + g3 + + + V4L2_MBUS_FMT_BGR565_2X8_BE + 0x1005 + + b4 + b3 + b2 + b1 + b0 + g5 + g4 + g3 + + + + + + g2 + g1 + g0 + r4 + r3 + r2 + r1 + r0 + + + V4L2_MBUS_FMT_BGR565_2X8_LE + 0x1006 + + g2 + g1 + g0 + r4 + r3 + r2 + r1 + r0 + + + + + + b4 + b3 + b2 + b1 + b0 + g5 + g4 + g3 + + + V4L2_MBUS_FMT_RGB565_2X8_BE + 0x1007 + + r4 + r3 + r2 + r1 + r0 + g5 + g4 + g3 + + + + + + g2 + g1 + g0 + b4 + b3 + b2 + b1 + b0 + + + V4L2_MBUS_FMT_RGB565_2X8_LE + 0x1008 + + g2 + g1 + g0 + b4 + b3 + b2 + b1 + b0 + + + + + + r4 + r3 + r2 + r1 + r0 + g5 + g4 + g3 + + + +
+
+ +
+ Bayer Formats + + Those formats transfer pixel data as red, green and blue components. + The format code is made of the following information. + + The red, green and blue components order code, as encoded in a + pixel sample. The possible values are shown in . + The number of bits per pixel component. All components are + transferred on the same number of bits. Common values are 8, 10 and 12. + + If the pixel components are DPCM-compressed, a mention of the + DPCM compression and the number of bits per compressed pixel component. + + The number of bus samples per pixel. Pixels that are wider than + the bus width must be transferred in multiple samples. Common values are + 1 and 2. + The bus width. + For formats where the total number of bits per pixel is smaller + than the number of bus samples per pixel times the bus width, a padding + value stating if the bytes are padded in their most high order bits + (PADHI) or low order bits (PADLO). + For formats where the number of bus samples per pixel is larger + than 1, an endianness value stating if the pixel is transferred MSB first + (BE) or LSB first (LE). + + + + For instance, a format with uncompressed 10-bit Bayer components + arranged in a red, green, green, blue pattern transferred as 2 8-bit + samples per pixel with the least significant bits transferred first will + be named V4L2_MBUS_FMT_SRGGB10_2X8_PADHI_LE. + + +
+ Bayer Patterns + + + + + + + + + Bayer filter color patterns + + +
+ + The following table lists existing packet Bayer formats. The data + organization is given as an example for the first pixel only. + + + Bayer Formats + + + + + + + + + + + + + + + + + + + + Identifier + Code + + Data organization + + + + + Bit + 11 + 10 + 9 + 8 + 7 + 6 + 5 + 4 + 3 + 2 + 1 + 0 + + + + + V4L2_MBUS_FMT_SBGGR8_1X8 + 0x3001 + + - + - + - + - + b7 + b6 + b5 + b4 + b3 + b2 + b1 + b0 + + + V4L2_MBUS_FMT_SGRBG8_1X8 + 0x3002 + + - + - + - + - + g7 + g6 + g5 + g4 + g3 + g2 + g1 + g0 + + + V4L2_MBUS_FMT_SBGGR10_DPCM8_1X8 + 0x300b + + - + - + - + - + b7 + b6 + b5 + b4 + b3 + b2 + b1 + b0 + + + V4L2_MBUS_FMT_SGBRG10_DPCM8_1X8 + 0x300c + + - + - + - + - + g7 + g6 + g5 + g4 + g3 + g2 + g1 + g0 + + + V4L2_MBUS_FMT_SGRBG10_DPCM8_1X8 + 0x3009 + + - + - + - + - + g7 + g6 + g5 + g4 + g3 + g2 + g1 + g0 + + + V4L2_MBUS_FMT_SRGGB10_DPCM8_1X8 + 0x300d + + - + - + - + - + r7 + r6 + r5 + r4 + r3 + r2 + r1 + r0 + + + V4L2_MBUS_FMT_SBGGR10_2X8_PADHI_BE + 0x3003 + + - + - + - + - + 0 + 0 + 0 + 0 + 0 + 0 + b9 + b8 + + + + + + - + - + - + - + b7 + b6 + b5 + b4 + b3 + b2 + b1 + b0 + + + V4L2_MBUS_FMT_SBGGR10_2X8_PADHI_LE + 0x3004 + + - + - + - + - + b7 + b6 + b5 + b4 + b3 + b2 + b1 + b0 + + + + + + - + - + - + - + 0 + 0 + 0 + 0 + 0 + 0 + b9 + b8 + + + V4L2_MBUS_FMT_SBGGR10_2X8_PADLO_BE + 0x3005 + + - + - + - + - + b9 + b8 + b7 + b6 + b5 + b4 + b3 + b2 + + + + + + - + - + - + - + b1 + b0 + 0 + 0 + 0 + 0 + 0 + 0 + + + V4L2_MBUS_FMT_SBGGR10_2X8_PADLO_LE + 0x3006 + + - + - + - + - + b1 + b0 + 0 + 0 + 0 + 0 + 0 + 0 + + + + + + - + - + - + - + b9 + b8 + b7 + b6 + b5 + b4 + b3 + b2 + + + V4L2_MBUS_FMT_SBGGR10_1X10 + 0x3007 + + - + - + b9 + b8 + b7 + b6 + b5 + b4 + b3 + b2 + b1 + b0 + + + V4L2_MBUS_FMT_SGBRG10_1X10 + 0x300e + + - + - + g9 + g8 + g7 + g6 + g5 + g4 + g3 + g2 + g1 + g0 + + + V4L2_MBUS_FMT_SGRBG10_1X10 + 0x300a + + - + - + g9 + g8 + g7 + g6 + g5 + g4 + g3 + g2 + g1 + g0 + + + V4L2_MBUS_FMT_SRGGB10_1X10 + 0x300f + + - + - + r9 + r8 + r7 + r6 + r5 + r4 + r3 + r2 + r1 + r0 + + + V4L2_MBUS_FMT_SBGGR12_1X12 + 0x3008 + + b11 + b10 + b9 + b8 + b7 + b6 + b5 + b4 + b3 + b2 + b1 + b0 + + + +
+
+ +
+ Packed YUV Formats + + Those data formats transfer pixel data as (possibly downsampled) Y, U + and V components. The format code is made of the following information. + + The Y, U and V components order code, as transferred on the + bus. Possible values are YUYV, UYVY, YVYU and VYUY. + The number of bits per pixel component. All components are + transferred on the same number of bits. Common values are 8, 10 and 12. + + The number of bus samples per pixel. Pixels that are wider than + the bus width must be transferred in multiple samples. Common values are + 1, 1.5 (encoded as 1_5) and 2. + The bus width. When the bus width is larger than the number of + bits per pixel component, several components are packed in a single bus + sample. The components are ordered as specified by the order code, with + components on the left of the code transferred in the high order bits. + Common values are 8 and 16. + + + + + For instance, a format where pixels are encoded as 8-bit YUV values + downsampled to 4:2:2 and transferred as 2 8-bit bus samples per pixel in the + U, Y, V, Y order will be named V4L2_MBUS_FMT_UYVY8_2X8. + + + The following table lisst existing packet YUV formats. + + + YUV Formats + + + + + + + + + + + + + + + + + + + + + + + + + + + + Identifier + Code + + Data organization + + + + + Bit + 19 + 18 + 17 + 16 + 15 + 14 + 13 + 12 + 11 + 10 + 9 + 8 + 7 + 6 + 5 + 4 + 3 + 2 + 1 + 0 + + + + + V4L2_MBUS_FMT_Y8_1X8 + 0x2001 + + - + - + - + - + - + - + - + - + - + - + - + - + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + + + V4L2_MBUS_FMT_UYVY8_1_5X8 + 0x2002 + + - + - + - + - + - + - + - + - + - + - + - + - + u7 + u6 + u5 + u4 + u3 + u2 + u1 + u0 + + + + + + - + - + - + - + - + - + - + - + - + - + - + - + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + + + + + + - + - + - + - + - + - + - + - + - + - + - + - + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + + + + + + - + - + - + - + - + - + - + - + - + - + - + - + v7 + v6 + v5 + v4 + v3 + v2 + v1 + v0 + + + + + + - + - + - + - + - + - + - + - + - + - + - + - + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + + + + + + - + - + - + - + - + - + - + - + - + - + - + - + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + + + V4L2_MBUS_FMT_VYUY8_1_5X8 + 0x2003 + + - + - + - + - + - + - + - + - + - + - + - + - + v7 + v6 + v5 + v4 + v3 + v2 + v1 + v0 + + + + + + - + - + - + - + - + - + - + - + - + - + - + - + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + + + + + + - + - + - + - + - + - + - + - + - + - + - + - + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + + + + + + - + - + - + - + - + - + - + - + - + - + - + - + u7 + u6 + u5 + u4 + u3 + u2 + u1 + u0 + + + + + + - + - + - + - + - + - + - + - + - + - + - + - + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + + + + + + - + - + - + - + - + - + - + - + - + - + - + - + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + + + V4L2_MBUS_FMT_YUYV8_1_5X8 + 0x2004 + + - + - + - + - + - + - + - + - + - + - + - + - + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + + + + + + - + - + - + - + - + - + - + - + - + - + - + - + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + + + + + + - + - + - + - + - + - + - + - + - + - + - + - + u7 + u6 + u5 + u4 + u3 + u2 + u1 + u0 + + + + + + - + - + - + - + - + - + - + - + - + - + - + - + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + + + + + + - + - + - + - + - + - + - + - + - + - + - + - + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + + + + + + - + - + - + - + - + - + - + - + - + - + - + - + v7 + v6 + v5 + v4 + v3 + v2 + v1 + v0 + + + V4L2_MBUS_FMT_YVYU8_1_5X8 + 0x2005 + + - + - + - + - + - + - + - + - + - + - + - + - + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + + + + + + - + - + - + - + - + - + - + - + - + - + - + - + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + + + + + + - + - + - + - + - + - + - + - + - + - + - + - + v7 + v6 + v5 + v4 + v3 + v2 + v1 + v0 + + + + + + - + - + - + - + - + - + - + - + - + - + - + - + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + + + + + + - + - + - + - + - + - + - + - + - + - + - + - + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + + + + + + - + - + - + - + - + - + - + - + - + - + - + - + u7 + u6 + u5 + u4 + u3 + u2 + u1 + u0 + + + V4L2_MBUS_FMT_UYVY8_2X8 + 0x2006 + + - + - + - + - + - + - + - + - + - + - + - + - + u7 + u6 + u5 + u4 + u3 + u2 + u1 + u0 + + + + + + - + - + - + - + - + - + - + - + - + - + - + - + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + + + + + + - + - + - + - + - + - + - + - + - + - + - + - + v7 + v6 + v5 + v4 + v3 + v2 + v1 + v0 + + + + + + - + - + - + - + - + - + - + - + - + - + - + - + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + + + V4L2_MBUS_FMT_VYUY8_2X8 + 0x2007 + + - + - + - + - + - + - + - + - + - + - + - + - + v7 + v6 + v5 + v4 + v3 + v2 + v1 + v0 + + + + + + - + - + - + - + - + - + - + - + - + - + - + - + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + + + + + + - + - + - + - + - + - + - + - + - + - + - + - + u7 + u6 + u5 + u4 + u3 + u2 + u1 + u0 + + + + + + - + - + - + - + - + - + - + - + - + - + - + - + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + + + V4L2_MBUS_FMT_YUYV8_2X8 + 0x2008 + + - + - + - + - + - + - + - + - + - + - + - + - + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + + + + + + - + - + - + - + - + - + - + - + - + - + - + - + u7 + u6 + u5 + u4 + u3 + u2 + u1 + u0 + + + + + + - + - + - + - + - + - + - + - + - + - + - + - + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + + + + + + - + - + - + - + - + - + - + - + - + - + - + - + v7 + v6 + v5 + v4 + v3 + v2 + v1 + v0 + + + V4L2_MBUS_FMT_YVYU8_2X8 + 0x2009 + + - + - + - + - + - + - + - + - + - + - + - + - + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + + + + + + - + - + - + - + - + - + - + - + - + - + - + - + v7 + v6 + v5 + v4 + v3 + v2 + v1 + v0 + + + + + + - + - + - + - + - + - + - + - + - + - + - + - + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + + + + + + - + - + - + - + - + - + - + - + - + - + - + - + u7 + u6 + u5 + u4 + u3 + u2 + u1 + u0 + + + V4L2_MBUS_FMT_Y10_1X10 + 0x200a + + - + - + - + - + - + - + - + - + - + - + y9 + y8 + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + + + V4L2_MBUS_FMT_YUYV10_2X10 + 0x200b + + - + - + - + - + - + - + - + - + - + - + y9 + y8 + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + + + + + + - + - + - + - + - + - + - + - + - + - + u9 + u8 + u7 + u6 + u5 + u4 + u3 + u2 + u1 + u0 + + + + + + - + - + - + - + - + - + - + - + - + - + y9 + y8 + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + + + + + + - + - + - + - + - + - + - + - + - + - + v9 + v8 + v7 + v6 + v5 + v4 + v3 + v2 + v1 + v0 + + + V4L2_MBUS_FMT_YVYU10_2X10 + 0x200c + + - + - + - + - + - + - + - + - + - + - + y9 + y8 + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + + + + + + - + - + - + - + - + - + - + - + - + - + v9 + v8 + v7 + v6 + v5 + v4 + v3 + v2 + v1 + v0 + + + + + + - + - + - + - + - + - + - + - + - + - + y9 + y8 + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + + + + + + - + - + - + - + - + - + - + - + - + - + u9 + u8 + u7 + u6 + u5 + u4 + u3 + u2 + u1 + u0 + + + V4L2_MBUS_FMT_UYVY8_1X16 + 0x200f + + - + - + - + - + u7 + u6 + u5 + u4 + u3 + u2 + u1 + u0 + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + + + + + + - + - + - + - + v7 + v6 + v5 + v4 + v3 + v2 + v1 + v0 + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + + + V4L2_MBUS_FMT_VYUY8_1X16 + 0x2010 + + - + - + - + - + v7 + v6 + v5 + v4 + v3 + v2 + v1 + v0 + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + + + + + + - + - + - + - + u7 + u6 + u5 + u4 + u3 + u2 + u1 + u0 + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + + + V4L2_MBUS_FMT_YUYV8_1X16 + 0x2011 + + - + - + - + - + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + u7 + u6 + u5 + u4 + u3 + u2 + u1 + u0 + + + + + + - + - + - + - + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + v7 + v6 + v5 + v4 + v3 + v2 + v1 + v0 + + + V4L2_MBUS_FMT_YVYU8_1X16 + 0x2012 + + - + - + - + - + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + v7 + v6 + v5 + v4 + v3 + v2 + v1 + v0 + + + + + + - + - + - + - + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + u7 + u6 + u5 + u4 + u3 + u2 + u1 + u0 + + + V4L2_MBUS_FMT_YUYV10_1X20 + 0x200d + + y9 + y8 + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + u9 + u8 + u7 + u6 + u5 + u4 + u3 + u2 + u1 + u0 + + + + + + y9 + y8 + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + v9 + v8 + v7 + v6 + v5 + v4 + v3 + v2 + v1 + v0 + + + V4L2_MBUS_FMT_YVYU10_1X20 + 0x200e + + y9 + y8 + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + v9 + v8 + v7 + v6 + v5 + v4 + v3 + v2 + v1 + v0 + + + + + + y9 + y8 + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + u9 + u8 + u7 + u6 + u5 + u4 + u3 + u2 + u1 + u0 + + + +
+
+
+
diff --git a/Documentation/DocBook/v4l/v4l2.xml b/Documentation/DocBook/v4l/v4l2.xml index 7859d7d9da39..2ada2f86bb54 100644 --- a/Documentation/DocBook/v4l/v4l2.xml +++ b/Documentation/DocBook/v4l/v4l2.xml @@ -439,6 +439,7 @@ and discussions on the V4L mailing list.
&sub-dev-radio;
&sub-dev-rds;
&sub-dev-event;
+
&sub-dev-subdev;
@@ -506,6 +507,9 @@ and discussions on the V4L mailing list. &sub-reqbufs; &sub-s-hw-freq-seek; &sub-streamon; + &sub-subdev-enum-frame-size; + &sub-subdev-enum-mbus-code; + &sub-subdev-g-fmt; &sub-subscribe-event; &sub-mmap; diff --git a/Documentation/DocBook/v4l/vidioc-streamon.xml b/Documentation/DocBook/v4l/vidioc-streamon.xml index e42bff1f2c0a..75ed39bf4d2b 100644 --- a/Documentation/DocBook/v4l/vidioc-streamon.xml +++ b/Documentation/DocBook/v4l/vidioc-streamon.xml @@ -93,6 +93,15 @@ synchronize with other events. been allocated (memory mapping) or enqueued (output) yet. + + EPIPE + + The driver implements pad-level format configuration and + the pipeline configuration is invalid. + + + diff --git a/Documentation/DocBook/v4l/vidioc-subdev-enum-frame-size.xml b/Documentation/DocBook/v4l/vidioc-subdev-enum-frame-size.xml new file mode 100644 index 000000000000..79ce42b7c60c --- /dev/null +++ b/Documentation/DocBook/v4l/vidioc-subdev-enum-frame-size.xml @@ -0,0 +1,154 @@ + + + ioctl VIDIOC_SUBDEV_ENUM_FRAME_SIZE + &manvol; + + + + VIDIOC_SUBDEV_ENUM_FRAME_SIZE + Enumerate media bus frame sizes + + + + + + int ioctl + int fd + int request + struct v4l2_subdev_frame_size_enum * + argp + + + + + + Arguments + + + + fd + + &fd; + + + + request + + VIDIOC_SUBDEV_ENUM_FRAME_SIZE + + + + argp + + + + + + + + + Description + + + Experimental + This is an experimental + interface and may change in the future. + + + This ioctl allows applications to enumerate all frame sizes + supported by a sub-device on the given pad for the given media bus format. + Supported formats can be retrieved with the &VIDIOC-SUBDEV-ENUM-MBUS-CODE; + ioctl. + + To enumerate frame sizes applications initialize the + pad, code and + index fields of the + &v4l2-subdev-mbus-code-enum; and call the + VIDIOC_SUBDEV_ENUM_FRAME_SIZE ioctl with a pointer to + the structure. Drivers fill the minimum and maximum frame sizes or return + an &EINVAL; if one of the input parameters is invalid. + + Sub-devices that only support discrete frame sizes (such as most + sensors) will return one or more frame sizes with identical minimum and + maximum values. + + Not all possible sizes in given [minimum, maximum] ranges need to be + supported. For instance, a scaler that uses a fixed-point scaling ratio + might not be able to produce every frame size between the minimum and + maximum values. Applications must use the &VIDIOC-SUBDEV-S-FMT; ioctl to + try the sub-device for an exact supported frame size. + + Available frame sizes may depend on the current 'try' formats at other + pads of the sub-device, as well as on the current active links and the + current values of V4L2 controls. See &VIDIOC-SUBDEV-G-FMT; for more + information about try formats. + + + struct <structname>v4l2_subdev_frame_size_enum</structname> + + &cs-str; + + + __u32 + index + Number of the format in the enumeration, set by the + application. + + + __u32 + pad + Pad number as reported by the media controller API. + + + __u32 + code + The media bus format code, as defined in + . + + + __u32 + min_width + Minimum frame width, in pixels. + + + __u32 + max_width + Maximum frame width, in pixels. + + + __u32 + min_height + Minimum frame height, in pixels. + + + __u32 + max_height + Maximum frame height, in pixels. + + + __u32 + reserved[9] + Reserved for future extensions. Applications and drivers must + set the array to zero. + + + +
+ + + + &return-value; + + + + EINVAL + + The &v4l2-subdev-frame-size-enum; pad + references a non-existing pad, the code is + invalid for the given pad or the index + field is out of bounds. + + + + + diff --git a/Documentation/DocBook/v4l/vidioc-subdev-enum-mbus-code.xml b/Documentation/DocBook/v4l/vidioc-subdev-enum-mbus-code.xml new file mode 100644 index 000000000000..a6b3432449f6 --- /dev/null +++ b/Documentation/DocBook/v4l/vidioc-subdev-enum-mbus-code.xml @@ -0,0 +1,119 @@ + + + ioctl VIDIOC_SUBDEV_ENUM_MBUS_CODE + &manvol; + + + + VIDIOC_SUBDEV_ENUM_MBUS_CODE + Enumerate media bus formats + + + + + + int ioctl + int fd + int request + struct v4l2_subdev_mbus_code_enum * + argp + + + + + + Arguments + + + + fd + + &fd; + + + + request + + VIDIOC_SUBDEV_ENUM_MBUS_CODE + + + + argp + + + + + + + + + Description + + + Experimental + This is an experimental + interface and may change in the future. + + + To enumerate media bus formats available at a given sub-device pad + applications initialize the pad and + index fields of &v4l2-subdev-mbus-code-enum; and + call the VIDIOC_SUBDEV_ENUM_MBUS_CODE ioctl with a + pointer to this structure. Drivers fill the rest of the structure or return + an &EINVAL; if either the pad or + index are invalid. All media bus formats are + enumerable by beginning at index zero and incrementing by one until + EINVAL is returned. + + Available media bus formats may depend on the current 'try' formats + at other pads of the sub-device, as well as on the current active links. See + &VIDIOC-SUBDEV-G-FMT; for more information about the try formats. + + + struct <structname>v4l2_subdev_mbus_code_enum</structname> + + &cs-str; + + + __u32 + pad + Pad number as reported by the media controller API. + + + __u32 + index + Number of the format in the enumeration, set by the + application. + + + __u32 + code + The media bus format code, as defined in + . + + + __u32 + reserved[9] + Reserved for future extensions. Applications and drivers must + set the array to zero. + + + +
+ + + + &return-value; + + + + EINVAL + + The &v4l2-subdev-mbus-code-enum; pad + references a non-existing pad, or the index + field is out of bounds. + + + + + diff --git a/Documentation/DocBook/v4l/vidioc-subdev-g-fmt.xml b/Documentation/DocBook/v4l/vidioc-subdev-g-fmt.xml new file mode 100644 index 000000000000..f367c570c530 --- /dev/null +++ b/Documentation/DocBook/v4l/vidioc-subdev-g-fmt.xml @@ -0,0 +1,180 @@ + + + ioctl VIDIOC_SUBDEV_G_FMT, VIDIOC_SUBDEV_S_FMT + &manvol; + + + + VIDIOC_SUBDEV_G_FMT + VIDIOC_SUBDEV_S_FMT + Get or set the data format on a subdev pad + + + + + + int ioctl + int fd + int request + struct v4l2_subdev_format *argp + + + + + + + Arguments + + + + fd + + &fd; + + + + request + + VIDIOC_SUBDEV_G_FMT, VIDIOC_SUBDEV_S_FMT + + + + argp + + + + + + + + + Description + + + Experimental + This is an experimental + interface and may change in the future. + + + These ioctls are used to negotiate the frame format at specific + subdev pads in the image pipeline. + + To retrieve the current format applications set the + pad field of a &v4l2-subdev-format; to the + desired pad number as reported by the media API and the + which field to + V4L2_SUBDEV_FORMAT_ACTIVE. When they call the + VIDIOC_SUBDEV_G_FMT ioctl with a pointer to this + structure the driver fills the members of the format + field. + + To change the current format applications set both the + pad and which fields + and all members of the format field. When they + call the VIDIOC_SUBDEV_S_FMT ioctl with a pointer to this + structure the driver verifies the requested format, adjusts it based on the + hardware capabilities and configures the device. Upon return the + &v4l2-subdev-format; contains the current format as would be returned by a + VIDIOC_SUBDEV_G_FMT call. + + Applications can query the device capabilities by setting the + which to + V4L2_SUBDEV_FORMAT_TRY. When set, 'try' formats are not + applied to the device by the driver, but are changed exactly as active + formats and stored in the sub-device file handle. Two applications querying + the same sub-device would thus not interact with each other. + + For instance, to try a format at the output pad of a sub-device, + applications would first set the try format at the sub-device input with the + VIDIOC_SUBDEV_S_FMT ioctl. They would then either + retrieve the default format at the output pad with the + VIDIOC_SUBDEV_G_FMT ioctl, or set the desired output + pad format with the VIDIOC_SUBDEV_S_FMT ioctl and check + the returned value. + + Try formats do not depend on active formats, but can depend on the + current links configuration or sub-device controls value. For instance, a + low-pass noise filter might crop pixels at the frame boundaries, modifying + its output frame size. + + Drivers must not return an error solely because the requested format + doesn't match the device capabilities. They must instead modify the format + to match what the hardware can provide. The modified format should be as + close as possible to the original request. + + + struct <structname>v4l2_subdev_format</structname> + + &cs-str; + + + __u32 + pad + Pad number as reported by the media controller API. + + + __u32 + which + Format to modified, from &v4l2-subdev-format-whence;. + + + &v4l2-mbus-framefmt; + format + Definition of an image format, see for details. + + + __u32 + reserved[8] + Reserved for future extensions. Applications and drivers must + set the array to zero. + + + +
+ + + enum <structname>v4l2_subdev_format_whence</structname> + + &cs-def; + + + V4L2_SUBDEV_FORMAT_TRY + 0 + Try formats, used for querying device capabilities. + + + V4L2_SUBDEV_FORMAT_ACTIVE + 1 + Active formats, applied to the hardware. + + + +
+ + + + &return-value; + + + + EBUSY + + The format can't be changed because the pad is currently busy. + This can be caused, for instance, by an active video stream on the + pad. The ioctl must not be retried without performing another action + to fix the problem first. Only returned by + VIDIOC_SUBDEV_S_FMT + + + + EINVAL + + The &v4l2-subdev-format; pad + references a non-existing pad, or the which + field references a non-existing format. + + + + + -- cgit v1.2.3 From 35c3017a29d278c4405a7f3ab30b814999d156d3 Mon Sep 17 00:00:00 2001 From: Laurent Pinchart Date: Wed, 5 May 2010 11:38:35 -0300 Subject: [media] v4l: v4l2_subdev userspace frame interval API The three new ioctl VIDIOC_SUBDEV_ENUM_FRAME_INTERVAL, VIDIOC_SUBDEV_G_FRAME_INTERVAL and VIDIOC_SUBDEV_S_FRAME_INTERVAL can be used to enumerate and configure a subdev's frame rate from userspace. Two new video::g/s_frame_interval subdev operations are introduced to support those ioctls. The existing video::g/s_parm operations are deprecated and shouldn't be used anymore. Signed-off-by: Laurent Pinchart Signed-off-by: Sakari Ailus Acked-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- Documentation/DocBook/media-entities.tmpl | 6 + Documentation/DocBook/v4l/v4l2.xml | 2 + .../v4l/vidioc-subdev-enum-frame-interval.xml | 152 +++++++++++++++++++++ .../DocBook/v4l/vidioc-subdev-g-frame-interval.xml | 141 +++++++++++++++++++ 4 files changed, 301 insertions(+) create mode 100644 Documentation/DocBook/v4l/vidioc-subdev-enum-frame-interval.xml create mode 100644 Documentation/DocBook/v4l/vidioc-subdev-g-frame-interval.xml (limited to 'Documentation') diff --git a/Documentation/DocBook/media-entities.tmpl b/Documentation/DocBook/media-entities.tmpl index dbb9cb2e1ec6..a95eb5783760 100644 --- a/Documentation/DocBook/media-entities.tmpl +++ b/Documentation/DocBook/media-entities.tmpl @@ -89,7 +89,9 @@ VIDIOC_SUBDEV_ENUM_FRAME_SIZE"> VIDIOC_SUBDEV_ENUM_MBUS_CODE"> VIDIOC_SUBDEV_G_FMT"> +VIDIOC_SUBDEV_G_FRAME_INTERVAL"> VIDIOC_SUBDEV_S_FMT"> +VIDIOC_SUBDEV_S_FRAME_INTERVAL"> VIDIOC_TRY_ENCODER_CMD"> VIDIOC_TRY_EXT_CTRLS"> VIDIOC_TRY_FMT"> @@ -193,6 +195,8 @@ v4l2_sliced_vbi_cap"> v4l2_sliced_vbi_data"> v4l2_sliced_vbi_format"> +v4l2_subdev_frame_interval"> +v4l2_subdev_frame_interval_enum"> v4l2_subdev_frame_size_enum"> v4l2_subdev_format"> v4l2_subdev_mbus_code_enum"> @@ -331,10 +335,12 @@ + + diff --git a/Documentation/DocBook/v4l/v4l2.xml b/Documentation/DocBook/v4l/v4l2.xml index 2ada2f86bb54..a436716ef3bc 100644 --- a/Documentation/DocBook/v4l/v4l2.xml +++ b/Documentation/DocBook/v4l/v4l2.xml @@ -507,9 +507,11 @@ and discussions on the V4L mailing list. &sub-reqbufs; &sub-s-hw-freq-seek; &sub-streamon; + &sub-subdev-enum-frame-interval; &sub-subdev-enum-frame-size; &sub-subdev-enum-mbus-code; &sub-subdev-g-fmt; + &sub-subdev-g-frame-interval; &sub-subscribe-event; &sub-mmap; diff --git a/Documentation/DocBook/v4l/vidioc-subdev-enum-frame-interval.xml b/Documentation/DocBook/v4l/vidioc-subdev-enum-frame-interval.xml new file mode 100644 index 000000000000..2f8f4f0a0235 --- /dev/null +++ b/Documentation/DocBook/v4l/vidioc-subdev-enum-frame-interval.xml @@ -0,0 +1,152 @@ + + + ioctl VIDIOC_SUBDEV_ENUM_FRAME_INTERVAL + &manvol; + + + + VIDIOC_SUBDEV_ENUM_FRAME_INTERVAL + Enumerate frame intervals + + + + + + int ioctl + int fd + int request + struct v4l2_subdev_frame_interval_enum * + argp + + + + + + Arguments + + + + fd + + &fd; + + + + request + + VIDIOC_SUBDEV_ENUM_FRAME_INTERVAL + + + + argp + + + + + + + + + Description + + + Experimental + This is an experimental + interface and may change in the future. + + + This ioctl lets applications enumerate available frame intervals on a + given sub-device pad. Frame intervals only makes sense for sub-devices that + can control the frame period on their own. This includes, for instance, + image sensors and TV tuners. + + For the common use case of image sensors, the frame intervals + available on the sub-device output pad depend on the frame format and size + on the same pad. Applications must thus specify the desired format and size + when enumerating frame intervals. + + To enumerate frame intervals applications initialize the + index, pad, + code, width and + height fields of + &v4l2-subdev-frame-interval-enum; and call the + VIDIOC_SUBDEV_ENUM_FRAME_INTERVAL ioctl with a pointer + to this structure. Drivers fill the rest of the structure or return + an &EINVAL; if one of the input fields is invalid. All frame intervals are + enumerable by beginning at index zero and incrementing by one until + EINVAL is returned. + + Available frame intervals may depend on the current 'try' formats + at other pads of the sub-device, as well as on the current active links. See + &VIDIOC-SUBDEV-G-FMT; for more information about the try formats. + + Sub-devices that support the frame interval enumeration ioctl should + implemented it on a single pad only. Its behaviour when supported on + multiple pads of the same sub-device is not defined. + + + struct <structname>v4l2_subdev_frame_interval_enum</structname> + + &cs-str; + + + __u32 + index + Number of the format in the enumeration, set by the + application. + + + __u32 + pad + Pad number as reported by the media controller API. + + + __u32 + code + The media bus format code, as defined in + . + + + __u32 + width + Frame width, in pixels. + + + __u32 + height + Frame height, in pixels. + + + &v4l2-fract; + interval + Period, in seconds, between consecutive video frames. + + + __u32 + reserved[9] + Reserved for future extensions. Applications and drivers must + set the array to zero. + + + +
+ + + + &return-value; + + + + EINVAL + + The &v4l2-subdev-frame-interval-enum; + pad references a non-existing pad, one of + the code, width + or height fields are invalid for the given + pad or the index field is out of bounds. + + + + + + diff --git a/Documentation/DocBook/v4l/vidioc-subdev-g-frame-interval.xml b/Documentation/DocBook/v4l/vidioc-subdev-g-frame-interval.xml new file mode 100644 index 000000000000..0bc3ea22d31f --- /dev/null +++ b/Documentation/DocBook/v4l/vidioc-subdev-g-frame-interval.xml @@ -0,0 +1,141 @@ + + + ioctl VIDIOC_SUBDEV_G_FRAME_INTERVAL, VIDIOC_SUBDEV_S_FRAME_INTERVAL + &manvol; + + + + VIDIOC_SUBDEV_G_FRAME_INTERVAL + VIDIOC_SUBDEV_S_FRAME_INTERVAL + Get or set the frame interval on a subdev pad + + + + + + int ioctl + int fd + int request + struct v4l2_subdev_frame_interval *argp + + + + + + + Arguments + + + + fd + + &fd; + + + + request + + VIDIOC_SUBDEV_G_FRAME_INTERVAL, VIDIOC_SUBDEV_S_FRAME_INTERVAL + + + + argp + + + + + + + + + Description + + + Experimental + This is an experimental + interface and may change in the future. + + + These ioctls are used to get and set the frame interval at specific + subdev pads in the image pipeline. The frame interval only makes sense for + sub-devices that can control the frame period on their own. This includes, + for instance, image sensors and TV tuners. Sub-devices that don't support + frame intervals must not implement these ioctls. + + To retrieve the current frame interval applications set the + pad field of a &v4l2-subdev-frame-interval; to + the desired pad number as reported by the media controller API. When they + call the VIDIOC_SUBDEV_G_FRAME_INTERVAL ioctl with a + pointer to this structure the driver fills the members of the + interval field. + + To change the current frame interval applications set both the + pad field and all members of the + interval field. When they call the + VIDIOC_SUBDEV_S_FRAME_INTERVAL ioctl with a pointer to + this structure the driver verifies the requested interval, adjusts it based + on the hardware capabilities and configures the device. Upon return the + &v4l2-subdev-frame-interval; contains the current frame interval as would be + returned by a VIDIOC_SUBDEV_G_FRAME_INTERVAL call. + + + Drivers must not return an error solely because the requested interval + doesn't match the device capabilities. They must instead modify the interval + to match what the hardware can provide. The modified interval should be as + close as possible to the original request. + + Sub-devices that support the frame interval ioctls should implement + them on a single pad only. Their behaviour when supported on multiple pads + of the same sub-device is not defined. + + + struct <structname>v4l2_subdev_frame_interval</structname> + + &cs-str; + + + __u32 + pad + Pad number as reported by the media controller API. + + + &v4l2-fract; + interval + Period, in seconds, between consecutive video frames. + + + __u32 + reserved[9] + Reserved for future extensions. Applications and drivers must + set the array to zero. + + + +
+ + + + &return-value; + + + + EBUSY + + The frame interval can't be changed because the pad is currently + busy. This can be caused, for instance, by an active video stream on + the pad. The ioctl must not be retried without performing another + action to fix the problem first. Only returned by + VIDIOC_SUBDEV_S_FRAME_INTERVAL + + + + EINVAL + + The &v4l2-subdev-frame-interval; pad + references a non-existing pad, or the pad doesn't support frame + intervals. + + + + + -- cgit v1.2.3 From f6a5cb1be894468cdc69ec557d47f40c28f64642 Mon Sep 17 00:00:00 2001 From: Antti Koskipaa Date: Wed, 23 Jun 2010 05:03:42 -0300 Subject: [media] v4l: v4l2_subdev userspace crop API This patch adds the VIDIOC_SUBDEV_S_CROP and G_CROP ioctls to the userland API. CROPCAP is not implemented because it's redundant. Signed-off-by: Antti Koskipaa Signed-off-by: Laurent Pinchart Acked-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- Documentation/DocBook/media-entities.tmpl | 4 + Documentation/DocBook/v4l/dev-subdev.xml | 33 +++++ Documentation/DocBook/v4l/v4l2.xml | 1 + Documentation/DocBook/v4l/vidioc-subdev-g-crop.xml | 155 +++++++++++++++++++++ 4 files changed, 193 insertions(+) create mode 100644 Documentation/DocBook/v4l/vidioc-subdev-g-crop.xml (limited to 'Documentation') diff --git a/Documentation/DocBook/media-entities.tmpl b/Documentation/DocBook/media-entities.tmpl index a95eb5783760..40158ee3d369 100644 --- a/Documentation/DocBook/media-entities.tmpl +++ b/Documentation/DocBook/media-entities.tmpl @@ -88,8 +88,10 @@ VIDIOC_S_TUNER"> VIDIOC_SUBDEV_ENUM_FRAME_SIZE"> VIDIOC_SUBDEV_ENUM_MBUS_CODE"> +VIDIOC_SUBDEV_G_CROP"> VIDIOC_SUBDEV_G_FMT"> VIDIOC_SUBDEV_G_FRAME_INTERVAL"> +VIDIOC_SUBDEV_S_CROP"> VIDIOC_SUBDEV_S_FMT"> VIDIOC_SUBDEV_S_FRAME_INTERVAL"> VIDIOC_TRY_ENCODER_CMD"> @@ -198,6 +200,7 @@ v4l2_subdev_frame_interval"> v4l2_subdev_frame_interval_enum"> v4l2_subdev_frame_size_enum"> +v4l2_subdev_crop"> v4l2_subdev_format"> v4l2_subdev_mbus_code_enum"> v4l2_standard"> @@ -339,6 +342,7 @@ + diff --git a/Documentation/DocBook/v4l/dev-subdev.xml b/Documentation/DocBook/v4l/dev-subdev.xml index fc62e65f45ef..e9eb8af0f303 100644 --- a/Documentation/DocBook/v4l/dev-subdev.xml +++ b/Documentation/DocBook/v4l/dev-subdev.xml @@ -275,6 +275,39 @@ +
+ Cropping and scaling + + Many sub-devices support cropping frames on their input or output + pads (or possible even on both). Cropping is used to select the area of + interest in an image, typically on a video sensor or video decoder. It can + also be used as part of digital zoom implementations to select the area of + the image that will be scaled up. + + Crop settings are defined by a crop rectangle and represented in a + &v4l2-rect; by the coordinates of the top left corner and the rectangle + size. Both the coordinates and sizes are expressed in pixels. + + The crop rectangle is retrieved and set using the + &VIDIOC-SUBDEV-G-CROP; and &VIDIOC-SUBDEV-S-CROP; ioctls. Like for pad + formats, drivers store try and active crop rectangles. The format + negotiation mechanism applies to crop settings as well. + + On input pads, cropping is applied relatively to the current pad + format. The pad format represents the image size as received by the + sub-device from the previous block in the pipeline, and the crop rectangle + represents the sub-image that will be transmitted further inside the + sub-device for processing. The crop rectangle be entirely containted + inside the input image size. + + Input crop rectangle are reset to their default value when the input + image format is modified. Drivers should use the input image size as the + crop rectangle default value, but hardware requirements may prevent this. + + + Cropping behaviour on output pads is not defined. + +
&sub-subdev-formats; diff --git a/Documentation/DocBook/v4l/v4l2.xml b/Documentation/DocBook/v4l/v4l2.xml index a436716ef3bc..3a6e3b5c0944 100644 --- a/Documentation/DocBook/v4l/v4l2.xml +++ b/Documentation/DocBook/v4l/v4l2.xml @@ -510,6 +510,7 @@ and discussions on the V4L mailing list. &sub-subdev-enum-frame-interval; &sub-subdev-enum-frame-size; &sub-subdev-enum-mbus-code; + &sub-subdev-g-crop; &sub-subdev-g-fmt; &sub-subdev-g-frame-interval; &sub-subscribe-event; diff --git a/Documentation/DocBook/v4l/vidioc-subdev-g-crop.xml b/Documentation/DocBook/v4l/vidioc-subdev-g-crop.xml new file mode 100644 index 000000000000..06197323a8cc --- /dev/null +++ b/Documentation/DocBook/v4l/vidioc-subdev-g-crop.xml @@ -0,0 +1,155 @@ + + + ioctl VIDIOC_SUBDEV_G_CROP, VIDIOC_SUBDEV_S_CROP + &manvol; + + + + VIDIOC_SUBDEV_G_CROP + VIDIOC_SUBDEV_S_CROP + Get or set the crop rectangle on a subdev pad + + + + + + int ioctl + int fd + int request + struct v4l2_subdev_crop *argp + + + + + int ioctl + int fd + int request + const struct v4l2_subdev_crop *argp + + + + + + Arguments + + + + fd + + &fd; + + + + request + + VIDIOC_SUBDEV_G_CROP, VIDIOC_SUBDEV_S_CROP + + + + argp + + + + + + + + + Description + + + Experimental + This is an experimental + interface and may change in the future. + + + To retrieve the current crop rectangle applications set the + pad field of a &v4l2-subdev-crop; to the + desired pad number as reported by the media API and the + which field to + V4L2_SUBDEV_FORMAT_ACTIVE. They then call the + VIDIOC_SUBDEV_G_CROP ioctl with a pointer to this + structure. The driver fills the members of the rect + field or returns &EINVAL; if the input arguments are invalid, or if cropping + is not supported on the given pad. + + To change the current crop rectangle applications set both the + pad and which fields + and all members of the rect field. They then call + the VIDIOC_SUBDEV_S_CROP ioctl with a pointer to this + structure. The driver verifies the requested crop rectangle, adjusts it + based on the hardware capabilities and configures the device. Upon return + the &v4l2-subdev-crop; contains the current format as would be returned + by a VIDIOC_SUBDEV_G_CROP call. + + Applications can query the device capabilities by setting the + which to + V4L2_SUBDEV_FORMAT_TRY. When set, 'try' crop + rectangles are not applied to the device by the driver, but are mangled + exactly as active crop rectangles and stored in the sub-device file handle. + Two applications querying the same sub-device would thus not interact with + each other. + + Drivers must not return an error solely because the requested crop + rectangle doesn't match the device capabilities. They must instead modify + the rectangle to match what the hardware can provide. The modified format + should be as close as possible to the original request. + + + struct <structname>v4l2_subdev_crop</structname> + + &cs-str; + + + __u32 + pad + Pad number as reported by the media framework. + + + __u32 + which + Crop rectangle to get or set, from + &v4l2-subdev-format-whence;. + + + &v4l2-rect; + rect + Crop rectangle boundaries, in pixels. + + + __u32 + reserved[8] + Reserved for future extensions. Applications and drivers must + set the array to zero. + + + +
+ + + + &return-value; + + + + EBUSY + + The crop rectangle can't be changed because the pad is currently + busy. This can be caused, for instance, by an active video stream on + the pad. The ioctl must not be retried without performing another + action to fix the problem first. Only returned by + VIDIOC_SUBDEV_S_CROP + + + + EINVAL + + The &v4l2-subdev-crop; pad + references a non-existing pad, the which + field references a non-existing format, or cropping is not supported + on the given subdev pad. + + + + + -- cgit v1.2.3 From 7140c55738561907a1f66abf533d6358bf69ed9f Mon Sep 17 00:00:00 2001 From: Laurent Pinchart Date: Thu, 23 Dec 2010 11:14:49 -0300 Subject: [media] v4l: Add missing 12 bits bayer media bus formats Add codes and documentation for the following media bus formats: - V4L2_MBUS_FMT_SGBRG12_1X12 - V4L2_MBUS_FMT_SGRBG12_1X12 - V4L2_MBUS_FMT_SRGGB12_1X12 Signed-off-by: Laurent Pinchart Acked-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- Documentation/DocBook/v4l/subdev-formats.xml | 51 ++++++++++++++++++++++++++++ 1 file changed, 51 insertions(+) (limited to 'Documentation') diff --git a/Documentation/DocBook/v4l/subdev-formats.xml b/Documentation/DocBook/v4l/subdev-formats.xml index 0cae57207006..b5376e263d10 100644 --- a/Documentation/DocBook/v4l/subdev-formats.xml +++ b/Documentation/DocBook/v4l/subdev-formats.xml @@ -762,6 +762,57 @@ b1 b0 + + V4L2_MBUS_FMT_SGBRG12_1X12 + 0x3010 + + g11 + g10 + g9 + g8 + g7 + g6 + g5 + g4 + g3 + g2 + g1 + g0 + + + V4L2_MBUS_FMT_SGRBG12_1X12 + 0x3011 + + g11 + g10 + g9 + g8 + g7 + g6 + g5 + g4 + g3 + g2 + g1 + g0 + + + V4L2_MBUS_FMT_SRGGB12_1X12 + 0x3012 + + r11 + r10 + r9 + r8 + r7 + r6 + r5 + r4 + r3 + r2 + r1 + r0 + -- cgit v1.2.3 From 39187e177dc6372a967aa17a49a79189dc4fa8de Mon Sep 17 00:00:00 2001 From: Laurent Pinchart Date: Thu, 23 Dec 2010 11:14:50 -0300 Subject: [media] v4l: Add 12 bits bayer pixel formats Add FCCs for the following pixel formats: - V4L2_PIX_FMT_SBGGR12 - V4L2_PIX_FMT_SGBRG12 - V4L2_PIX_FMT_SGRBG12 - V4L2_PIX_FMT_SRGGB12 Signed-off-by: Laurent Pinchart Acked-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- Documentation/DocBook/v4l/pixfmt-srggb12.xml | 90 ++++++++++++++++++++++++++++ 1 file changed, 90 insertions(+) create mode 100644 Documentation/DocBook/v4l/pixfmt-srggb12.xml (limited to 'Documentation') diff --git a/Documentation/DocBook/v4l/pixfmt-srggb12.xml b/Documentation/DocBook/v4l/pixfmt-srggb12.xml new file mode 100644 index 000000000000..9ba4fb690bc0 --- /dev/null +++ b/Documentation/DocBook/v4l/pixfmt-srggb12.xml @@ -0,0 +1,90 @@ + + + V4L2_PIX_FMT_SRGGB12 ('RG12'), + V4L2_PIX_FMT_SGRBG12 ('BA12'), + V4L2_PIX_FMT_SGBRG12 ('GB12'), + V4L2_PIX_FMT_SBGGR12 ('BG12'), + + &manvol; + + + V4L2_PIX_FMT_SRGGB12 + V4L2_PIX_FMT_SGRBG12 + V4L2_PIX_FMT_SGBRG12 + V4L2_PIX_FMT_SBGGR12 + 12-bit Bayer formats expanded to 16 bits + + + Description + + The following four pixel formats are raw sRGB / Bayer formats with +12 bits per colour. Each colour component is stored in a 16-bit word, with 6 +unused high bits filled with zeros. Each n-pixel row contains n/2 green samples +and n/2 blue or red samples, with alternating red and blue rows. Bytes are +stored in memory in little endian order. They are conventionally described +as GRGR... BGBG..., RGRG... GBGB..., etc. Below is an example of one of these +formats + + + <constant>V4L2_PIX_FMT_SBGGR12</constant> 4 × 4 +pixel image + + + Byte Order. + Each cell is one byte, high 6 bits in high bytes are 0. + + + + + + start + 0: + B00low + B00high + G01low + G01high + B02low + B02high + G03low + G03high + + + start + 8: + G10low + G10high + R11low + R11high + G12low + G12high + R13low + R13high + + + start + 16: + B20low + B20high + G21low + G21high + B22low + B22high + G23low + G23high + + + start + 24: + G30low + G30high + R31low + R31high + G32low + G32high + R33low + R33high + + + + + + + + + -- cgit v1.2.3 From c30b46e58b31a0fc420049e21117444862fc7cb7 Mon Sep 17 00:00:00 2001 From: Laurent Pinchart Date: Fri, 26 Feb 2010 12:23:10 -0300 Subject: [media] v4l: subdev: Generic ioctl support Instead of returning an error when receiving an ioctl call with an unsupported command, forward the call to the subdev core::ioctl handler. Signed-off-by: Laurent Pinchart Acked-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- Documentation/video4linux/v4l2-framework.txt | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'Documentation') diff --git a/Documentation/video4linux/v4l2-framework.txt b/Documentation/video4linux/v4l2-framework.txt index 77d96f4e3f50..f2df31b088c6 100644 --- a/Documentation/video4linux/v4l2-framework.txt +++ b/Documentation/video4linux/v4l2-framework.txt @@ -405,6 +405,11 @@ VIDIOC_UNSUBSCRIBE_EVENT To properly support events, the poll() file operation is also implemented. +Private ioctls + + All ioctls not in the above list are passed directly to the sub-device + driver through the core::ioctl operation. + I2C sub-device drivers ---------------------- -- cgit v1.2.3 From 474966ee01cc877e28abed3ada5b48a963c58695 Mon Sep 17 00:00:00 2001 From: Laurent Pinchart Date: Sat, 5 Mar 2011 17:14:33 -0300 Subject: [media] media: Pick a free ioctls range Pick an unused range of ioctls in Documentation/ioctl/ioctl-number.txt and use it for the MEDIA_IOC_* ioctls. Signed-off-by: Laurent Pinchart Signed-off-by: Mauro Carvalho Chehab --- Documentation/ioctl/ioctl-number.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/ioctl/ioctl-number.txt b/Documentation/ioctl/ioctl-number.txt index ac293e955308..2b8c0592b519 100644 --- a/Documentation/ioctl/ioctl-number.txt +++ b/Documentation/ioctl/ioctl-number.txt @@ -272,6 +272,7 @@ Code Seq#(hex) Include File Comments 'z' 40-7F CAN bus card conflict! 'z' 10-4F drivers/s390/crypto/zcrypt_api.h conflict! +'|' 00-7F linux/media.h 0x80 00-1F linux/fb.h 0x89 00-06 arch/x86/include/asm/sockios.h 0x89 0B-DF linux/sockios.h -- cgit v1.2.3 From e83dd485ed04b21215c1283042e8d4712ab1a675 Mon Sep 17 00:00:00 2001 From: Sakari Ailus Date: Mon, 7 Mar 2011 14:20:52 -0300 Subject: [media] omap3isp: Add documentation Add documentation on the OMAP 3 ISP driver. Document the subdevs, V4L2 events and private IOCTLs the driver implements Signed-off-by: Sakari Ailus Signed-off-by: David Cohen Signed-off-by: Mauro Carvalho Chehab --- Documentation/video4linux/omap3isp.txt | 278 +++++++++++++++++++++++++++++++++ 1 file changed, 278 insertions(+) create mode 100644 Documentation/video4linux/omap3isp.txt (limited to 'Documentation') diff --git a/Documentation/video4linux/omap3isp.txt b/Documentation/video4linux/omap3isp.txt new file mode 100644 index 000000000000..69be2c782b98 --- /dev/null +++ b/Documentation/video4linux/omap3isp.txt @@ -0,0 +1,278 @@ +OMAP 3 Image Signal Processor (ISP) driver + +Copyright (C) 2010 Nokia Corporation +Copyright (C) 2009 Texas Instruments, Inc. + +Contacts: Laurent Pinchart + Sakari Ailus + David Cohen + + +Introduction +============ + +This file documents the Texas Instruments OMAP 3 Image Signal Processor (ISP) +driver located under drivers/media/video/omap3isp. The original driver was +written by Texas Instruments but since that it has been rewritten (twice) at +Nokia. + +The driver has been successfully used on the following versions of OMAP 3: + + 3430 + 3530 + 3630 + +The driver implements V4L2, Media controller and v4l2_subdev interfaces. +Sensor, lens and flash drivers using the v4l2_subdev interface in the kernel +are supported. + + +Split to subdevs +================ + +The OMAP 3 ISP is split into V4L2 subdevs, each of the blocks inside the ISP +having one subdev to represent it. Each of the subdevs provide a V4L2 subdev +interface to userspace. + + OMAP3 ISP CCP2 + OMAP3 ISP CSI2a + OMAP3 ISP CCDC + OMAP3 ISP preview + OMAP3 ISP resizer + OMAP3 ISP AEWB + OMAP3 ISP AF + OMAP3 ISP histogram + +Each possible link in the ISP is modelled by a link in the Media controller +interface. For an example program see [2]. + + +Controlling the OMAP 3 ISP +========================== + +In general, the settings given to the OMAP 3 ISP take effect at the beginning +of the following frame. This is done when the module becomes idle during the +vertical blanking period on the sensor. In memory-to-memory operation the pipe +is run one frame at a time. Applying the settings is done between the frames. + +All the blocks in the ISP, excluding the CSI-2 and possibly the CCP2 receiver, +insist on receiving complete frames. Sensors must thus never send the ISP +partial frames. + +Autoidle does have issues with some ISP blocks on the 3430, at least. +Autoidle is only enabled on 3630 when the omap3isp module parameter autoidle +is non-zero. + + +Events +====== + +The OMAP 3 ISP driver does support the V4L2 event interface on CCDC and +statistics (AEWB, AF and histogram) subdevs. + +The CCDC subdev produces V4L2_EVENT_OMAP3ISP_HS_VS type event on HS_VS +interrupt which is used to signal frame start. The event is triggered exactly +when the reception of the first line of the frame starts in the CCDC module. +The event can be subscribed on the CCDC subdev. + +(When using parallel interface one must pay account to correct configuration +of the VS signal polarity. This is automatically correct when using the serial +receivers.) + +Each of the statistics subdevs is able to produce events. An event is +generated whenever a statistics buffer can be dequeued by a user space +application using the VIDIOC_OMAP3ISP_STAT_REQ IOCTL. The events available +are: + + V4L2_EVENT_OMAP3ISP_AEWB + V4L2_EVENT_OMAP3ISP_AF + V4L2_EVENT_OMAP3ISP_HIST + +The type of the event data is struct omap3isp_stat_event_status for these +ioctls. If there is an error calculating the statistics, there will be an +event as usual, but no related statistics buffer. In this case +omap3isp_stat_event_status.buf_err is set to non-zero. + + +Private IOCTLs +============== + +The OMAP 3 ISP driver supports standard V4L2 IOCTLs and controls where +possible and practical. Much of the functions provided by the ISP, however, +does not fall under the standard IOCTLs --- gamma tables and configuration of +statistics collection are examples of such. + +In general, there is a private ioctl for configuring each of the blocks +containing hardware-dependent functions. + +The following private IOCTLs are supported: + + VIDIOC_OMAP3ISP_CCDC_CFG + VIDIOC_OMAP3ISP_PRV_CFG + VIDIOC_OMAP3ISP_AEWB_CFG + VIDIOC_OMAP3ISP_HIST_CFG + VIDIOC_OMAP3ISP_AF_CFG + VIDIOC_OMAP3ISP_STAT_REQ + VIDIOC_OMAP3ISP_STAT_EN + +The parameter structures used by these ioctls are described in +include/linux/omap3isp.h. The detailed functions of the ISP itself related to +a given ISP block is described in the Technical Reference Manuals (TRMs) --- +see the end of the document for those. + +While it is possible to use the ISP driver without any use of these private +IOCTLs it is not possible to obtain optimal image quality this way. The AEWB, +AF and histogram modules cannot be used without configuring them using the +appropriate private IOCTLs. + + +CCDC and preview block IOCTLs +============================= + +The VIDIOC_OMAP3ISP_CCDC_CFG and VIDIOC_OMAP3ISP_PRV_CFG IOCTLs are used to +configure, enable and disable functions in the CCDC and preview blocks, +respectively. Both IOCTLs control several functions in the blocks they +control. VIDIOC_OMAP3ISP_CCDC_CFG IOCTL accepts a pointer to struct +omap3isp_ccdc_update_config as its argument. Similarly VIDIOC_OMAP3ISP_PRV_CFG +accepts a pointer to struct omap3isp_prev_update_config. The definition of +both structures is available in [1]. + +The update field in the structures tells whether to update the configuration +for the specific function and the flag tells whether to enable or disable the +function. + +The update and flag bit masks accept the following values. Each separate +functions in the CCDC and preview blocks is associated with a flag (either +disable or enable; part of the flag field in the structure) and a pointer to +configuration data for the function. + +Valid values for the update and flag fields are listed here for +VIDIOC_OMAP3ISP_CCDC_CFG. Values may be or'ed to configure more than one +function in the same IOCTL call. + + OMAP3ISP_CCDC_ALAW + OMAP3ISP_CCDC_LPF + OMAP3ISP_CCDC_BLCLAMP + OMAP3ISP_CCDC_BCOMP + OMAP3ISP_CCDC_FPC + OMAP3ISP_CCDC_CULL + OMAP3ISP_CCDC_CONFIG_LSC + OMAP3ISP_CCDC_TBL_LSC + +The corresponding values for the VIDIOC_OMAP3ISP_PRV_CFG are here: + + OMAP3ISP_PREV_LUMAENH + OMAP3ISP_PREV_INVALAW + OMAP3ISP_PREV_HRZ_MED + OMAP3ISP_PREV_CFA + OMAP3ISP_PREV_CHROMA_SUPP + OMAP3ISP_PREV_WB + OMAP3ISP_PREV_BLKADJ + OMAP3ISP_PREV_RGB2RGB + OMAP3ISP_PREV_COLOR_CONV + OMAP3ISP_PREV_YC_LIMIT + OMAP3ISP_PREV_DEFECT_COR + OMAP3ISP_PREV_GAMMABYPASS + OMAP3ISP_PREV_DRK_FRM_CAPTURE + OMAP3ISP_PREV_DRK_FRM_SUBTRACT + OMAP3ISP_PREV_LENS_SHADING + OMAP3ISP_PREV_NF + OMAP3ISP_PREV_GAMMA + +The associated configuration pointer for the function may not be NULL when +enabling the function. When disabling a function the configuration pointer is +ignored. + + +Statistic blocks IOCTLs +======================= + +The statistics subdevs do offer more dynamic configuration options than the +other subdevs. They can be enabled, disable and reconfigured when the pipeline +is in streaming state. + +The statistics blocks always get the input image data from the CCDC (as the +histogram memory read isn't implemented). The statistics are dequeueable by +the user from the statistics subdev nodes using private IOCTLs. + +The private IOCTLs offered by the AEWB, AF and histogram subdevs are heavily +reflected by the register level interface offered by the ISP hardware. There +are aspects that are purely related to the driver implementation and these are +discussed next. + +VIDIOC_OMAP3ISP_STAT_EN +----------------------- + +This private IOCTL enables/disables a statistic module. If this request is +done before streaming, it will take effect as soon as the pipeline starts to +stream. If the pipeline is already streaming, it will take effect as soon as +the CCDC becomes idle. + +VIDIOC_OMAP3ISP_AEWB_CFG, VIDIOC_OMAP3ISP_HIST_CFG and VIDIOC_OMAP3ISP_AF_CFG +----------------------------------------------------------------------------- + +Those IOCTLs are used to configure the modules. They require user applications +to have an in-depth knowledge of the hardware. Most of the fields explanation +can be found on OMAP's TRMs. The two following fields common to all the above +configure private IOCTLs require explanation for better understanding as they +are not part of the TRM. + +omap3isp_[h3a_af/h3a_aewb/hist]_config.buf_size: + +The modules handle their buffers internally. The necessary buffer size for the +module's data output depends on the requested configuration. Although the +driver supports reconfiguration while streaming, it does not support a +reconfiguration which requires bigger buffer size than what is already +internally allocated if the module is enabled. It will return -EBUSY on this +case. In order to avoid such condition, either disable/reconfigure/enable the +module or request the necessary buffer size during the first configuration +while the module is disabled. + +The internal buffer size allocation considers the requested configuration's +minimum buffer size and the value set on buf_size field. If buf_size field is +out of [minimum, maximum] buffer size range, it's clamped to fit in there. +The driver then selects the biggest value. The corrected buf_size value is +written back to user application. + +omap3isp_[h3a_af/h3a_aewb/hist]_config.config_counter: + +As the configuration doesn't take effect synchronously to the request, the +driver must provide a way to track this information to provide more accurate +data. After a configuration is requested, the config_counter returned to user +space application will be an unique value associated to that request. When +user application receives an event for buffer availability or when a new +buffer is requested, this config_counter is used to match a buffer data and a +configuration. + +VIDIOC_OMAP3ISP_STAT_REQ +------------------------ + +Send to user space the oldest data available in the internal buffer queue and +discards such buffer afterwards. The field omap3isp_stat_data.frame_number +matches with the video buffer's field_count. + + +Technical reference manuals (TRMs) and other documentation +========================================================== + +OMAP 3430 TRM: + +Referenced 2011-03-05. + +OMAP 35xx TRM: + Referenced 2011-03-05. + +OMAP 3630 TRM: + +Referenced 2011-03-05. + +DM 3730 TRM: + Referenced 2011-03-06. + + +References +========== + +[1] include/linux/omap3isp.h + +[2] http://git.ideasonboard.org/?p=media-ctl.git;a=summary -- cgit v1.2.3 From bd08a0cd5f546916a9454ae2c35756ed77957458 Mon Sep 17 00:00:00 2001 From: Kamil Debski Date: Fri, 11 Mar 2011 06:16:22 -0300 Subject: [media] v4l: Documentation for the NV12MT format Added documentation for V4L2_PIX_FMT_NV12MT format. This is a YUV 4:2:0 format with macro block size of 64x32 and specific order of macro blocks in the memory. Signed-off-by: Kamil Debski Signed-off-by: Kyungmin Park Signed-off-by: Mauro Carvalho Chehab --- Documentation/DocBook/media-entities.tmpl | 1 + Documentation/DocBook/v4l/nv12mt.gif | Bin 0 -> 2108 bytes Documentation/DocBook/v4l/nv12mt_example.gif | Bin 0 -> 6858 bytes Documentation/DocBook/v4l/pixfmt-nv12mt.xml | 74 +++++++++++++++++++++++++++ Documentation/DocBook/v4l/pixfmt.xml | 1 + 5 files changed, 76 insertions(+) create mode 100644 Documentation/DocBook/v4l/nv12mt.gif create mode 100644 Documentation/DocBook/v4l/nv12mt_example.gif create mode 100644 Documentation/DocBook/v4l/pixfmt-nv12mt.xml (limited to 'Documentation') diff --git a/Documentation/DocBook/media-entities.tmpl b/Documentation/DocBook/media-entities.tmpl index 40158ee3d369..5d259c632cdf 100644 --- a/Documentation/DocBook/media-entities.tmpl +++ b/Documentation/DocBook/media-entities.tmpl @@ -272,6 +272,7 @@ + diff --git a/Documentation/DocBook/v4l/nv12mt.gif b/Documentation/DocBook/v4l/nv12mt.gif new file mode 100644 index 000000000000..ef2d4cf8367b Binary files /dev/null and b/Documentation/DocBook/v4l/nv12mt.gif differ diff --git a/Documentation/DocBook/v4l/nv12mt_example.gif b/Documentation/DocBook/v4l/nv12mt_example.gif new file mode 100644 index 000000000000..df81d68108ee Binary files /dev/null and b/Documentation/DocBook/v4l/nv12mt_example.gif differ diff --git a/Documentation/DocBook/v4l/pixfmt-nv12mt.xml b/Documentation/DocBook/v4l/pixfmt-nv12mt.xml new file mode 100644 index 000000000000..5cb5bec8b653 --- /dev/null +++ b/Documentation/DocBook/v4l/pixfmt-nv12mt.xml @@ -0,0 +1,74 @@ + + + V4L2_PIX_FMT_NV12MT ('TM12') + &manvol; + + + V4L2_PIX_FMT_NV12MT + + Formats with ½ horizontal and vertical +chroma resolution. This format has two planes - one for luminance and one for +chrominance. Chroma samples are interleaved. The difference to +V4L2_PIX_FMT_NV12 is the memory layout. Pixels are +grouped in macroblocks of 64x32 size. The order of macroblocks in memory is +also not standard. + + + + Description + + This is the two-plane versions of the YUV 4:2:0 format where data +is grouped into 64x32 macroblocks. The three components are separated into two +sub-images or planes. The Y plane has one byte per pixel and pixels are grouped +into 64x32 macroblocks. The CbCr plane has the same width, in bytes, as the Y +plane (and the image), but is half as tall in pixels. The chroma plane is also +grouped into 64x32 macroblocks. + Width of the buffer has to be aligned to the multiple of 128, and +height alignment is 32. Every four adjactent buffers - two horizontally and two +vertically are grouped together and are located in memory in Z or flipped Z +order. + Layout of macroblocks in memory is presented in the following +figure. +
+ <constant>V4L2_PIX_FMT_NV12MT</constant> macroblock Z shape +memory layout + + + + + +
+ The requirement that width is multiple of 128 is implemented because, +the Z shape cannot be cut in half horizontally. In case the vertical resolution +of macroblocks is odd then the last row of macroblocks is arranged in a linear +order. + In case of chroma the layout is identical. Cb and Cr samples are +interleaved. Height of the buffer is aligned to 32. + + + Memory layout of macroblocks in <constant>V4L2_PIX_FMT_NV12 +</constant> format pixel image - extreme case + +
+ Example <constant>V4L2_PIX_FMT_NV12MT</constant> memory +layout of macroblocks + + + + + +
+ Memory layout of macroblocks of V4L2_PIX_FMT_NV12MT + format in most extreme case. + + + + + + diff --git a/Documentation/DocBook/v4l/pixfmt.xml b/Documentation/DocBook/v4l/pixfmt.xml index f8436dcb7414..c6fdcbbd1b41 100644 --- a/Documentation/DocBook/v4l/pixfmt.xml +++ b/Documentation/DocBook/v4l/pixfmt.xml @@ -709,6 +709,7 @@ information. &sub-yuv411p; &sub-nv12; &sub-nv12m; + &sub-nv12mt; &sub-nv16; -- cgit v1.2.3 From 665bf368fdc1e7afc9616eda128fe83d6053d5bc Mon Sep 17 00:00:00 2001 From: Hans Verkuil Date: Fri, 11 Mar 2011 16:22:21 -0300 Subject: [media] V4L doc fixes The xmlto validation produced a number of errors that are now fixed. Sadly, the DocBook/Makefile still adds --skip-validation to xmlto, so these errors are missed during a normal compile. Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- Documentation/DocBook/v4l/dev-subdev.xml | 46 ++++++++-------- .../DocBook/v4l/media-ioc-enum-entities.xml | 6 +- Documentation/DocBook/v4l/subdev-formats.xml | 64 +++++++++++----------- 3 files changed, 58 insertions(+), 58 deletions(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/v4l/dev-subdev.xml b/Documentation/DocBook/v4l/dev-subdev.xml index e9eb8af0f303..21caff6d159b 100644 --- a/Documentation/DocBook/v4l/dev-subdev.xml +++ b/Documentation/DocBook/v4l/dev-subdev.xml @@ -23,9 +23,9 @@ driver and the V4L2 device driver support this, sub-devices will feature a character device node on which ioctls can be called to - query, read and write sub-devices controls - subscribe and unsubscribe to events and retrieve them - negotiate image formats on individual pads + query, read and write sub-devices controls + subscribe and unsubscribe to events and retrieve them + negotiate image formats on individual pads @@ -67,14 +67,14 @@
Pad-level Formats - Pad-level formats are only applicable to very complex device that + Pad-level formats are only applicable to very complex device that need to expose low-level format configuration to user space. Generic V4L2 applications do not need to use the API described in - this section. + this section. - For the purpose of this section, the term + For the purpose of this section, the term format means the combination of media bus data - format, frame width and frame height. + format, frame width and frame height. Image formats are typically negotiated on video capture and output devices using the cropping and scaling ioctls. @@ -84,8 +84,8 @@ For complex devices, such as often found in embedded systems, identical image sizes at the output of a pipeline can be achieved using - different hardware configurations. One such exemple is shown on - , where + different hardware configurations. One such example is shown on + , where image scaling can be performed on both the video sensor and the host image processing hardware. @@ -168,13 +168,13 @@ modify formats as required by the device. However, they should comply with the following rules when possible: - Formats should be propagated from sink pads to source pads. + Formats should be propagated from sink pads to source pads. Modifying a format on a source pad should not modify the format on any - sink pad. - Sub-devices that scale frames using variable scaling factors + sink pad. + Sub-devices that scale frames using variable scaling factors should reset the scale factors to default values when sink pads formats are modified. If the 1:1 scaling ratio is supported, this means that - source pads formats should be reset to the sink pads formats. + source pads formats should be reset to the sink pads formats. @@ -185,9 +185,9 @@ guaranteed to be compatible. Drivers are free to accept different formats matching device requirements as being compatible. - + shows a sample configuration sequence for the pipeline described in - (table + (table columns list entity names and pad numbers). @@ -248,19 +248,19 @@ - Initial state. The sensor output is set to its native 3MP + Initial state. The sensor output is set to its native 3MP resolution. Resolutions on the host frontend and scaler input and output - pads are undefined. - The application configures the frontend input pad resolution to + pads are undefined. + The application configures the frontend input pad resolution to 2048x1536. The driver propagates the format to the frontend output pad. Note that the propagated output format can be different, as in this case, than the input format, as the hardware might need to crop pixels (for - instance when converting a Bayer filter pattern to RGB or YUV). - The application configures the scaler input pad resolution to + instance when converting a Bayer filter pattern to RGB or YUV). + The application configures the scaler input pad resolution to 2046x1534 to match the frontend output resolution. The driver propagates - the format to the scaler output pad. - The application configures the scaler output pad resolution to - 1280x960. + the format to the scaler output pad. + The application configures the scaler output pad resolution to + 1280x960. diff --git a/Documentation/DocBook/v4l/media-ioc-enum-entities.xml b/Documentation/DocBook/v4l/media-ioc-enum-entities.xml index 13d0cc44865a..576b68b33f2c 100644 --- a/Documentation/DocBook/v4l/media-ioc-enum-entities.xml +++ b/Documentation/DocBook/v4l/media-ioc-enum-entities.xml @@ -63,9 +63,9 @@ group_id value are considered as logically grouped. Groups are used to report - ALSA, VBI and video nodes that carry the same media - stream - lens and flash controllers associated with a sensor + ALSA, VBI and video nodes that carry the same media + stream + lens and flash controllers associated with a sensor diff --git a/Documentation/DocBook/v4l/subdev-formats.xml b/Documentation/DocBook/v4l/subdev-formats.xml index b5376e263d10..7041127d6dfc 100644 --- a/Documentation/DocBook/v4l/subdev-formats.xml +++ b/Documentation/DocBook/v4l/subdev-formats.xml @@ -63,22 +63,22 @@ Those formats transfer pixel data as red, green and blue components. The format code is made of the following information. - The red, green and blue components order code, as encoded in a - pixel sample. Possible values are RGB and BGR. - The number of bits per component, for each component. The values - can be different for all components. Common values are 555 and 565. + The red, green and blue components order code, as encoded in a + pixel sample. Possible values are RGB and BGR. + The number of bits per component, for each component. The values + can be different for all components. Common values are 555 and 565. - The number of bus samples per pixel. Pixels that are wider than + The number of bus samples per pixel. Pixels that are wider than the bus width must be transferred in multiple samples. Common values are - 1 and 2. - The bus width. - For formats where the total number of bits per pixel is smaller + 1 and 2. + The bus width. + For formats where the total number of bits per pixel is smaller than the number of bus samples per pixel times the bus width, a padding value stating if the bytes are padded in their most high order bits - (PADHI) or low order bits (PADLO). - For formats where the number of bus samples per pixel is larger + (PADHI) or low order bits (PADLO). + For formats where the number of bus samples per pixel is larger than 1, an endianness value stating if the pixel is transferred MSB first - (BE) or LSB first (LE). + (BE) or LSB first (LE). @@ -347,26 +347,26 @@ Those formats transfer pixel data as red, green and blue components. The format code is made of the following information. - The red, green and blue components order code, as encoded in a + The red, green and blue components order code, as encoded in a pixel sample. The possible values are shown in . - The number of bits per pixel component. All components are - transferred on the same number of bits. Common values are 8, 10 and 12. + linkend="bayer-patterns" />. + The number of bits per pixel component. All components are + transferred on the same number of bits. Common values are 8, 10 and 12. - If the pixel components are DPCM-compressed, a mention of the - DPCM compression and the number of bits per compressed pixel component. + If the pixel components are DPCM-compressed, a mention of the + DPCM compression and the number of bits per compressed pixel component. - The number of bus samples per pixel. Pixels that are wider than + The number of bus samples per pixel. Pixels that are wider than the bus width must be transferred in multiple samples. Common values are - 1 and 2. - The bus width. - For formats where the total number of bits per pixel is smaller + 1 and 2. + The bus width. + For formats where the total number of bits per pixel is smaller than the number of bus samples per pixel times the bus width, a padding value stating if the bytes are padded in their most high order bits - (PADHI) or low order bits (PADLO). - For formats where the number of bus samples per pixel is larger + (PADHI) or low order bits (PADLO). + For formats where the number of bus samples per pixel is larger than 1, an endianness value stating if the pixel is transferred MSB first - (BE) or LSB first (LE). + (BE) or LSB first (LE). @@ -824,19 +824,19 @@ Those data formats transfer pixel data as (possibly downsampled) Y, U and V components. The format code is made of the following information. - The Y, U and V components order code, as transferred on the - bus. Possible values are YUYV, UYVY, YVYU and VYUY. - The number of bits per pixel component. All components are - transferred on the same number of bits. Common values are 8, 10 and 12. + The Y, U and V components order code, as transferred on the + bus. Possible values are YUYV, UYVY, YVYU and VYUY. + The number of bits per pixel component. All components are + transferred on the same number of bits. Common values are 8, 10 and 12. - The number of bus samples per pixel. Pixels that are wider than + The number of bus samples per pixel. Pixels that are wider than the bus width must be transferred in multiple samples. Common values are - 1, 1.5 (encoded as 1_5) and 2. - The bus width. When the bus width is larger than the number of + 1, 1.5 (encoded as 1_5) and 2. + The bus width. When the bus width is larger than the number of bits per pixel component, several components are packed in a single bus sample. The components are ordered as specified by the order code, with components on the left of the code transferred in the high order bits. - Common values are 8 and 16. + Common values are 8 and 16. -- cgit v1.2.3 From 6e5b55fbdab3845bfb328f986f58e85d43cee59e Mon Sep 17 00:00:00 2001 From: Hans Verkuil Date: Fri, 11 Mar 2011 16:25:23 -0300 Subject: [media] V4L DocBook: update V4L2 version Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- Documentation/DocBook/v4l/v4l2.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/v4l/v4l2.xml b/Documentation/DocBook/v4l/v4l2.xml index 3a6e3b5c0944..ae7a069d61d5 100644 --- a/Documentation/DocBook/v4l/v4l2.xml +++ b/Documentation/DocBook/v4l/v4l2.xml @@ -410,7 +410,7 @@ and discussions on the V4L mailing list. Video for Linux Two API Specification - Revision 2.6.38 + Revision 2.6.39 &sub-common; -- cgit v1.2.3 From 34fd68bc03c8d656f991bd4f1646ec773179521b Mon Sep 17 00:00:00 2001 From: Hans Verkuil Date: Fri, 11 Mar 2011 18:18:54 -0300 Subject: [media] Fix 'ID nv12mt already defined' error DocBook validation fix. Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- Documentation/DocBook/v4l/pixfmt-nv12mt.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/v4l/pixfmt-nv12mt.xml b/Documentation/DocBook/v4l/pixfmt-nv12mt.xml index 5cb5bec8b653..7a2855a526c1 100644 --- a/Documentation/DocBook/v4l/pixfmt-nv12mt.xml +++ b/Documentation/DocBook/v4l/pixfmt-nv12mt.xml @@ -49,7 +49,7 @@ interleaved. Height of the buffer is aligned to 32. Memory layout of macroblocks in <constant>V4L2_PIX_FMT_NV12 </constant> format pixel image - extreme case -
+
Example <constant>V4L2_PIX_FMT_NV12MT</constant> memory layout of macroblocks -- cgit v1.2.3 From ce5b2acce60405b938d1f1f994024cde4e2cdd7e Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jean-Fran=C3=A7ois=20Moine?= Date: Mon, 14 Mar 2011 08:49:28 -0300 Subject: [media] gspca - nw80x: New subdriver for Divio based webcams MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit [mchehab@redhat.com: Fix a few CodingStyle issues] Tested-by: Kjell Claesson Tested-by: Hans de Goede Signed-off-by: Jean-François Moine Signed-off-by: Mauro Carvalho Chehab --- Documentation/video4linux/gspca.txt | 9 +++++++++ 1 file changed, 9 insertions(+) (limited to 'Documentation') diff --git a/Documentation/video4linux/gspca.txt b/Documentation/video4linux/gspca.txt index dc72fff2eb12..5c542e60f51d 100644 --- a/Documentation/video4linux/gspca.txt +++ b/Documentation/video4linux/gspca.txt @@ -103,6 +103,7 @@ spca561 046d:092d Logitech QC Elch2 spca561 046d:092e Logitech QC Elch2 spca561 046d:092f Logitech QuickCam Express Plus sunplus 046d:0960 Logitech ClickSmart 420 +nw80x 046d:d001 Logitech QuickCam Pro (dark focus ring) sunplus 0471:0322 Philips DMVC1300K zc3xx 0471:0325 Philips SPC 200 NC zc3xx 0471:0326 Philips SPC 300 NC @@ -150,10 +151,12 @@ sunplus 04fc:5330 Digitrex 2110 sunplus 04fc:5360 Sunplus Generic spca500 04fc:7333 PalmPixDC85 sunplus 04fc:ffff Pure DigitalDakota +nw80x 0502:d001 DVC V6 spca501 0506:00df 3Com HomeConnect Lite sunplus 052b:1507 Megapixel 5 Pretec DC-1007 sunplus 052b:1513 Megapix V4 sunplus 052b:1803 MegaImage VI +nw80x 052b:d001 EZCam Pro p35u tv8532 0545:808b Veo Stingray tv8532 0545:8333 Veo Stingray sunplus 0546:3155 Polaroid PDC3070 @@ -177,6 +180,7 @@ sunplus 055f:c530 Mustek Gsmart LCD 3 sunplus 055f:c540 Gsmart D30 sunplus 055f:c630 Mustek MDC4000 sunplus 055f:c650 Mustek MDC5500Z +nw80x 055f:d001 Mustek Wcam 300 mini zc3xx 055f:d003 Mustek WCam300A zc3xx 055f:d004 Mustek WCam300 AN conex 0572:0041 Creative Notebook cx11646 @@ -195,8 +199,12 @@ gl860 05e3:0503 Genesys Logic PC Camera gl860 05e3:f191 Genesys Logic PC Camera spca561 060b:a001 Maxell Compact Pc PM3 zc3xx 0698:2003 CTX M730V built in +nw80x 06a5:0000 Typhoon Webcam 100 USB +nw80x 06a5:d001 Divio based webcams +nw80x 06a5:d800 Divio Chicony TwinkleCam, Trust SpaceCam spca500 06bd:0404 Agfa CL20 spca500 06be:0800 Optimedia +nw80x 06be:d001 EZCam Pro p35u sunplus 06d6:0031 Trust 610 LCD PowerC@m Zoom spca506 06e1:a190 ADS Instant VCD ov534 06f8:3002 Hercules Blog Webcam @@ -204,6 +212,7 @@ ov534_9 06f8:3003 Hercules Dualpix HD Weblog sonixj 06f8:3004 Hercules Classic Silver sonixj 06f8:3008 Hercules Deluxe Optical Glass pac7302 06f8:3009 Hercules Classic Link +nw80x 0728:d001 AVerMedia Camguard spca508 0733:0110 ViewQuest VQ110 spca501 0733:0401 Intel Create and Share spca501 0733:0402 ViewQuest M318B -- cgit v1.2.3 From f0e3b646ccce66c9e878966227ce8415d3c11c2a Mon Sep 17 00:00:00 2001 From: Pawel Osciak Date: Sun, 13 Mar 2011 15:20:22 -0300 Subject: [media] Make 2.6.39 not 2.6.38 the version when Multi-planar API was added Multi-planar API was added to 2.6.39 version of Video for Linux 2 API. Signed-off-by: Pawel Osciak Signed-off-by: Mauro Carvalho Chehab --- Documentation/DocBook/v4l/compat.xml | 13 ++++--------- Documentation/DocBook/v4l/v4l2.xml | 13 ++----------- 2 files changed, 6 insertions(+), 20 deletions(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/v4l/compat.xml b/Documentation/DocBook/v4l/compat.xml index 4d74bf24e114..9f7cd4f25792 100644 --- a/Documentation/DocBook/v4l/compat.xml +++ b/Documentation/DocBook/v4l/compat.xml @@ -2354,8 +2354,11 @@ that used it. It was originally scheduled for removal in 2.6.35.
- V4L2 in Linux 2.6.38 + V4L2 in Linux 2.6.39 + + The old VIDIOC_*_OLD symbols and V4L1 support were removed. + Multi-planar API added. Does not affect the compatibility of current drivers and applications. See @@ -2364,14 +2367,6 @@ that used it. It was originally scheduled for removal in 2.6.35.
-
- V4L2 in Linux 2.6.39 - - - The old VIDIOC_*_OLD symbols and V4L1 support were removed. - - -
Relation of V4L2 to other Linux multimedia APIs diff --git a/Documentation/DocBook/v4l/v4l2.xml b/Documentation/DocBook/v4l/v4l2.xml index ae7a069d61d5..a7fd76d0dac1 100644 --- a/Documentation/DocBook/v4l/v4l2.xml +++ b/Documentation/DocBook/v4l/v4l2.xml @@ -130,17 +130,8 @@ applications. --> 2.6.39 2011-03-01 - mcc - Removed VIDIOC_*_OLD from videodev2.h header and update it to reflect latest changes. - - - - - 2.6.38 - 2011-01-16 - po - Added the multi-planar API. - + mcc, po + Removed VIDIOC_*_OLD from videodev2.h header and update it to reflect latest changes. Added the multi-planar API. -- cgit v1.2.3 From 3286dac1ca34b85b069c409414a3e51a9217b159 Mon Sep 17 00:00:00 2001 From: Malcolm Priestley Date: Sat, 12 Feb 2011 22:38:47 -0300 Subject: [media] DM04 LME2510(C) Sharp BS2F7HZ0194 Firmware Information DM04 LME2510(C) Sharp BS2F7HZ0194 Firmware Information Signed-off-by: Malcolm Priestley Signed-off-by: Mauro Carvalho Chehab --- Documentation/dvb/lmedm04.txt | 16 ++++++++++++++-- 1 file changed, 14 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/dvb/lmedm04.txt b/Documentation/dvb/lmedm04.txt index 641886504201..10b5f0411386 100644 --- a/Documentation/dvb/lmedm04.txt +++ b/Documentation/dvb/lmedm04.txt @@ -4,7 +4,7 @@ following file(s) to this directory. for DM04+/QQBOX LME2510C (Sharp 7395 Tuner) ------------------------------------------- -The Sharp 7395 driver can be found in windows/system32/driver +The Sharp 7395 driver can be found in windows/system32/drivers US2A0D.sys (dated 17 Mar 2009) @@ -44,7 +44,7 @@ and run Other LG firmware can be extracted manually from US280D.sys -only found in windows/system32/driver. +only found in windows/system32/drivers dd if=US280D.sys ibs=1 skip=42360 count=3924 of=dvb-usb-lme2510-lg.fw @@ -55,4 +55,16 @@ dd if=US280D.sys ibs=1 skip=35200 count=3850 of=dvb-usb-lme2510c-lg.fw --------------------------------------------------------------------- +The Sharp 0194 tuner driver can be found in windows/system32/drivers + +US290D.sys (dated 09 Apr 2009) + +For LME2510 +dd if=US290D.sys ibs=1 skip=36856 count=3976 of=dvb-usb-lme2510-s0194.fw + + +For LME2510C +dd if=US290D.sys ibs=1 skip=33152 count=3697 of=dvb-usb-lme2510c-s0194.fw + + Copy the firmware file(s) to /lib/firmware -- cgit v1.2.3 From 6e29ad50b4d688b1d18e2d255e31676c7ee46d3d Mon Sep 17 00:00:00 2001 From: Hans Verkuil Date: Thu, 24 Feb 2011 10:58:13 -0300 Subject: [media] v4l2-framework.txt: improve v4l2_fh/priority documentation Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- Documentation/video4linux/v4l2-framework.txt | 120 +++++++++++++++++++-------- 1 file changed, 87 insertions(+), 33 deletions(-) (limited to 'Documentation') diff --git a/Documentation/video4linux/v4l2-framework.txt b/Documentation/video4linux/v4l2-framework.txt index f2df31b088c6..1c8d4492f5c7 100644 --- a/Documentation/video4linux/v4l2-framework.txt +++ b/Documentation/video4linux/v4l2-framework.txt @@ -549,6 +549,10 @@ You should also set these fields: Otherwise you give it a pointer to a struct mutex_lock and before any of the v4l2_file_operations is called this lock will be taken by the core and released afterwards. +- prio: keeps track of the priorities. Used to implement VIDIOC_G/S_PRIORITY. + If left to NULL, then it will use the struct v4l2_prio_state in v4l2_device. + If you want to have a separate priority state per (group of) device node(s), + then you can point it to your own struct v4l2_prio_state. - parent: you only set this if v4l2_device was registered with NULL as the parent device struct. This only happens in cases where one hardware device has multiple PCI devices that all share the same v4l2_device core. @@ -559,8 +563,10 @@ You should also set these fields: PCI device it is setup without a parent device. But when the struct video_device is setup you do know which parent PCI device to use. -If you use v4l2_ioctl_ops, then you should set either .unlocked_ioctl or -.ioctl to video_ioctl2 in your v4l2_file_operations struct. +If you use v4l2_ioctl_ops, then you should set .unlocked_ioctl to video_ioctl2 +in your v4l2_file_operations struct. + +Do not use .ioctl! This is deprecated and will go away in the future. The v4l2_file_operations struct is a subset of file_operations. The main difference is that the inode argument is omitted since it is never used. @@ -753,39 +759,24 @@ struct v4l2_fh -------------- struct v4l2_fh provides a way to easily keep file handle specific data -that is used by the V4L2 framework. Using v4l2_fh is optional for -drivers. +that is used by the V4L2 framework. New drivers must use struct v4l2_fh +since it is also used to implement priority handling (VIDIOC_G/S_PRIORITY). The users of v4l2_fh (in the V4L2 framework, not the driver) know whether a driver uses v4l2_fh as its file->private_data pointer by -testing the V4L2_FL_USES_V4L2_FH bit in video_device->flags. - -Useful functions: - -- v4l2_fh_init() - - Initialise the file handle. This *MUST* be performed in the driver's - v4l2_file_operations->open() handler. - -- v4l2_fh_add() +testing the V4L2_FL_USES_V4L2_FH bit in video_device->flags. This bit is +set whenever v4l2_fh_init() is called. - Add a v4l2_fh to video_device file handle list. May be called after - initialising the file handle. - -- v4l2_fh_del() - - Unassociate the file handle from video_device(). The file handle - exit function may now be called. +struct v4l2_fh is allocated as a part of the driver's own file handle +structure and file->private_data is set to it in the driver's open +function by the driver. -- v4l2_fh_exit() +In many cases the struct v4l2_fh will be embedded in a larger structure. +In that case you should call v4l2_fh_init+v4l2_fh_add in open() and +v4l2_fh_del+v4l2_fh_exit in release(). - Uninitialise the file handle. After uninitialisation the v4l2_fh - memory can be freed. - -struct v4l2_fh is allocated as a part of the driver's own file handle -structure and is set to file->private_data in the driver's open -function by the driver. Drivers can extract their own file handle -structure by using the container_of macro. Example: +Drivers can extract their own file handle structure by using the container_of +macro. Example: struct my_fh { int blah; @@ -802,15 +793,21 @@ int my_open(struct file *file) ... + my_fh = kzalloc(sizeof(*my_fh), GFP_KERNEL); + + ... + ret = v4l2_fh_init(&my_fh->fh, vfd); - if (ret) + if (ret) { + kfree(my_fh); return ret; + } - v4l2_fh_add(&my_fh->fh); + ... file->private_data = &my_fh->fh; - - ... + v4l2_fh_add(&my_fh->fh); + return 0; } int my_release(struct file *file) @@ -819,8 +816,65 @@ int my_release(struct file *file) struct my_fh *my_fh = container_of(fh, struct my_fh, fh); ... + v4l2_fh_del(&my_fh->fh); + v4l2_fh_exit(&my_fh->fh); + kfree(my_fh); + return 0; } +Below is a short description of the v4l2_fh functions used: + +int v4l2_fh_init(struct v4l2_fh *fh, struct video_device *vdev) + + Initialise the file handle. This *MUST* be performed in the driver's + v4l2_file_operations->open() handler. + +void v4l2_fh_add(struct v4l2_fh *fh) + + Add a v4l2_fh to video_device file handle list. Must be called once the + file handle is completely initialized. + +void v4l2_fh_del(struct v4l2_fh *fh) + + Unassociate the file handle from video_device(). The file handle + exit function may now be called. + +void v4l2_fh_exit(struct v4l2_fh *fh) + + Uninitialise the file handle. After uninitialisation the v4l2_fh + memory can be freed. + + +If struct v4l2_fh is not embedded, then you can use these helper functions: + +int v4l2_fh_open(struct file *filp) + + This allocates a struct v4l2_fh, initializes it and adds it to the struct + video_device associated with the file struct. + +int v4l2_fh_release(struct file *filp) + + This deletes it from the struct video_device associated with the file + struct, uninitialised the v4l2_fh and frees it. + +These two functions can be plugged into the v4l2_file_operation's open() and +release() ops. + + +Several drivers need to do something when the first file handle is opened and +when the last file handle closes. Two helper functions were added to check +whether the v4l2_fh struct is the only open filehandle of the associated +device node: + +int v4l2_fh_is_singular(struct v4l2_fh *fh) + + Returns 1 if the file handle is the only open file handle, else 0. + +int v4l2_fh_is_singular_file(struct file *filp) + + Same, but it calls v4l2_fh_is_singular with filp->private_data. + + V4L2 events ----------- -- cgit v1.2.3 From 2335e2b817186cf79a07311f14560ef8b30f6a9a Mon Sep 17 00:00:00 2001 From: Hans Verkuil Date: Thu, 24 Feb 2011 06:28:46 -0300 Subject: [media] v4l2-framework.txt: document new v4l2_device release() callback Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- Documentation/video4linux/v4l2-framework.txt | 15 +++++++++++++++ 1 file changed, 15 insertions(+) (limited to 'Documentation') diff --git a/Documentation/video4linux/v4l2-framework.txt b/Documentation/video4linux/v4l2-framework.txt index 1c8d4492f5c7..7d09114af00b 100644 --- a/Documentation/video4linux/v4l2-framework.txt +++ b/Documentation/video4linux/v4l2-framework.txt @@ -181,6 +181,21 @@ static int __devinit drv_probe(struct pci_dev *pdev, state->instance = atomic_inc_return(&drv_instance) - 1; } +If you have multiple device nodes then it can be difficult to know when it is +safe to unregister v4l2_device. For this purpose v4l2_device has refcounting +support. The refcount is increased whenever video_register_device is called and +it is decreased whenever that device node is released. When the refcount reaches +zero, then the v4l2_device release() callback is called. You can do your final +cleanup there. + +If other device nodes (e.g. ALSA) are created, then you can increase and +decrease the refcount manually as well by calling: + +void v4l2_device_get(struct v4l2_device *v4l2_dev); + +or: + +int v4l2_device_put(struct v4l2_device *v4l2_dev); struct v4l2_subdev ------------------ -- cgit v1.2.3 From b1a873a37b6551a214ad37d1eee7654a9d65fd6e Mon Sep 17 00:00:00 2001 From: Hans Verkuil Date: Tue, 22 Mar 2011 10:14:07 -0300 Subject: [media] v4l2: use new flag to enable core priority handling Rather than guess which driver supports core priority handling, require drivers that do to explicitly set the V4L2_FL_USE_FH_PRIO flag in video_device. Updated the core prio handling accordingly and set the flag in the three drivers that do. Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- Documentation/video4linux/v4l2-framework.txt | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/video4linux/v4l2-framework.txt b/Documentation/video4linux/v4l2-framework.txt index 7d09114af00b..3b15608ee070 100644 --- a/Documentation/video4linux/v4l2-framework.txt +++ b/Documentation/video4linux/v4l2-framework.txt @@ -577,6 +577,10 @@ You should also set these fields: (cx8802). Since the v4l2_device cannot be associated with a particular PCI device it is setup without a parent device. But when the struct video_device is setup you do know which parent PCI device to use. +- flags: optional. Set to V4L2_FL_USE_FH_PRIO if you want to let the framework + handle the VIDIOC_G/S_PRIORITY ioctls. This requires that you use struct + v4l2_fh. Eventually this flag will disappear once all drivers use the core + priority handling. But for now it has to be set explicitly. If you use v4l2_ioctl_ops, then you should set .unlocked_ioctl to video_ioctl2 in your v4l2_file_operations struct. @@ -775,7 +779,8 @@ struct v4l2_fh struct v4l2_fh provides a way to easily keep file handle specific data that is used by the V4L2 framework. New drivers must use struct v4l2_fh -since it is also used to implement priority handling (VIDIOC_G/S_PRIORITY). +since it is also used to implement priority handling (VIDIOC_G/S_PRIORITY) +if the video_device flag V4L2_FL_USE_FH_PRIO is also set. The users of v4l2_fh (in the V4L2 framework, not the driver) know whether a driver uses v4l2_fh as its file->private_data pointer by -- cgit v1.2.3 From fe06b11dea74d53156d4116dcd518193a2e42ba4 Mon Sep 17 00:00:00 2001 From: Jarod Wilson Date: Mon, 24 Jan 2011 18:22:12 -0300 Subject: [media] docs: fix typo in lirc_device_interface.xml Reported-by: Daniel Burr Signed-off-by: Jarod Wilson Signed-off-by: Mauro Carvalho Chehab --- Documentation/DocBook/v4l/lirc_device_interface.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/v4l/lirc_device_interface.xml b/Documentation/DocBook/v4l/lirc_device_interface.xml index 68134c0ab4d1..0e0453f39e73 100644 --- a/Documentation/DocBook/v4l/lirc_device_interface.xml +++ b/Documentation/DocBook/v4l/lirc_device_interface.xml @@ -45,7 +45,7 @@ describing an IR signal are read from the chardev. The data written to the chardev is a pulse/space sequence of integer values. Pulses and spaces are only marked implicitly by their position. The data must start and end with a pulse, therefore, the data must always include -an unevent number of samples. The write function must block until the data has +an uneven number of samples. The write function must block until the data has been transmitted by the hardware.
-- cgit v1.2.3