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.