* [PATCH v7 0/2] add dm365 specific media formats
@ 2012-07-27 10:55 Prabhakar Lad
2012-07-27 10:55 ` [PATCH v7 1/2] media: add new mediabus format enums for dm365 Prabhakar Lad
` (2 more replies)
0 siblings, 3 replies; 15+ messages in thread
From: Prabhakar Lad @ 2012-07-27 10:55 UTC (permalink / raw)
To: LMML; +Cc: dlos, Prabhakar Lad
add mediabus formats and pixel formats supported
as part of dm365 vpfe device.
The device supports media formats(transfer and storage)
which include-
1: ALAW compressed bayer.
2: UV interleaved without Y (for resizer).
3: YDYU
Changes for v7:
1: Fixed a comment from Laurent, removed subscript for
dummy tags.
2: Fixed a comment from Sakari, used the same order for
ALAW pix fmt according to Documentation/video4linux/4CCs.txt.
Changes for v6:
1: Fixed a comment from Hans, replaced "YUYDYDYV and YVYDYDYU"
to "YUYDYVYD and YVYDYUYD".
Changes for v5:
1: Fixed comment from Laurent, moved ALAW format above DPCM
format to keep the alphabetically sorted, grouped textual
description for ALAW and DPCM compression, as they're mutally
exclusive, Changed V4L2_MBUS_FMT_YDYC8_1X16 to
V4L2_MBUS_FMT_YDYUYDYV8_1X16.
Changes for v4:
1: Rebased the patch set on Sakari's branch
(http://git.linuxtv.org/sailus/media_tree.git/shortlog/refs/heads/media-for-3.4)
mainly because of this patch
<URL:http://www.spinics.net/lists/linux-media/msg44871.html>
2: Fixed comments from Sakari, changed description for
UV8, and re-arranged &sub-uv8; in
Documentation/DocBook/media/v4l/pixfmt.xml file.
Changes for v3:
1: Added 4cc code for A-law compressed format as per
specified in documentation,
http://www.spinics.net/lists/linux-media/msg43890.html
Changes for v2:
1: Added entries in subdev-formats.xml for
V4L2_MBUS_FMT_YDYC8_1X16, V4L2_MBUS_FMT_UV8_1X8,
V4L2_MBUS_FMT_SBGGR10_ALAW8_1X8,
V4L2_MBUS_FMT_SGBRG10_ALAW8_1X8,
V4L2_MBUS_FMT_SGRBG10_ALAW8_1X8,
V4L2_MBUS_FMT_SRGGB10_ALAW8_1X8.
2: Added documentation of ALAW and UV8 pix format.
Manjunath Hadli (2):
media: add new mediabus format enums for dm365
v4l2: add new pixel formats supported on dm365
.../DocBook/media/v4l/pixfmt-srggb10alaw8.xml | 34 +++
Documentation/DocBook/media/v4l/pixfmt-uv8.xml | 62 +++++
Documentation/DocBook/media/v4l/pixfmt.xml | 2 +
Documentation/DocBook/media/v4l/subdev-formats.xml | 250 +++++++++++++++++++-
include/linux/v4l2-mediabus.h | 10 +-
include/linux/videodev2.h | 8 +
6 files changed, 358 insertions(+), 8 deletions(-)
create mode 100644 Documentation/DocBook/media/v4l/pixfmt-srggb10alaw8.xml
create mode 100644 Documentation/DocBook/media/v4l/pixfmt-uv8.xml
^ permalink raw reply [flat|nested] 15+ messages in thread* [PATCH v7 1/2] media: add new mediabus format enums for dm365 2012-07-27 10:55 [PATCH v7 0/2] add dm365 specific media formats Prabhakar Lad @ 2012-07-27 10:55 ` Prabhakar Lad 2012-07-27 22:01 ` Sakari Ailus 2012-07-27 10:55 ` [PATCH v7 2/2] v4l2: add new pixel formats supported on dm365 Prabhakar Lad 2012-07-27 11:30 ` [PATCH v7 0/2] add dm365 specific media formats Laurent Pinchart 2 siblings, 1 reply; 15+ messages in thread From: Prabhakar Lad @ 2012-07-27 10:55 UTC (permalink / raw) To: LMML Cc: dlos, Manjunath Hadli, Lad, Prabhakar, Sakari Ailus, Guennadi Liakhovetski From: Manjunath Hadli <manjunath.hadli@ti.com> add new enum entries for supporting the media-bus formats on dm365. These include some bayer and some non-bayer formats. V4L2_MBUS_FMT_YDYUYDYV8_1X16 and V4L2_MBUS_FMT_UV8_1X8 are used internal to the hardware by the resizer. V4L2_MBUS_FMT_SBGGR10_ALAW8_1X8 represents the bayer ALAW format that is supported by dm365 hardware. Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Manjunath Hadli <manjunath.hadli@ti.com> Signed-off-by: Lad, Prabhakar <prabhakar.lad@ti.com> Cc: Sakari Ailus <sakari.ailus@iki.fi> Cc: Guennadi Liakhovetski <g.liakhovetski@gmx.de> --- Documentation/DocBook/media/v4l/subdev-formats.xml | 250 +++++++++++++++++++- include/linux/v4l2-mediabus.h | 10 +- 2 files changed, 252 insertions(+), 8 deletions(-) diff --git a/Documentation/DocBook/media/v4l/subdev-formats.xml b/Documentation/DocBook/media/v4l/subdev-formats.xml index 49c532e..75dc275 100644 --- a/Documentation/DocBook/media/v4l/subdev-formats.xml +++ b/Documentation/DocBook/media/v4l/subdev-formats.xml @@ -353,9 +353,9 @@ <listitem><para>The number of bits per pixel component. All components are transferred on the same number of bits. Common values are 8, 10 and 12.</para> </listitem> - <listitem><para>If the pixel components are DPCM-compressed, a mention of the - DPCM compression and the number of bits per compressed pixel component.</para> - </listitem> + <listitem><para>The compression (optional). If the pixel components are + ALAW- or DPCM-compressed, a mention of the compression scheme and the + number of bits per compressed pixel component.</para></listitem> <listitem><para>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.</para></listitem> @@ -504,6 +504,74 @@ <entry>r<subscript>1</subscript></entry> <entry>r<subscript>0</subscript></entry> </row> + <row id="V4L2-MBUS-FMT-SBGGR10-ALAW8-1X8"> + <entry>V4L2_MBUS_FMT_SBGGR10_ALAW8_1X8</entry> + <entry>0x3015</entry> + <entry></entry> + <entry>-</entry> + <entry>-</entry> + <entry>-</entry> + <entry>-</entry> + <entry>b<subscript>7</subscript></entry> + <entry>b<subscript>6</subscript></entry> + <entry>b<subscript>5</subscript></entry> + <entry>b<subscript>4</subscript></entry> + <entry>b<subscript>3</subscript></entry> + <entry>b<subscript>2</subscript></entry> + <entry>b<subscript>1</subscript></entry> + <entry>b<subscript>0</subscript></entry> + </row> + <row id="V4L2-MBUS-FMT-SGBRG10-ALAW8-1X8"> + <entry>V4L2_MBUS_FMT_SGBRG10_ALAW8_1X8</entry> + <entry>0x3016</entry> + <entry></entry> + <entry>-</entry> + <entry>-</entry> + <entry>-</entry> + <entry>-</entry> + <entry>g<subscript>7</subscript></entry> + <entry>g<subscript>6</subscript></entry> + <entry>g<subscript>5</subscript></entry> + <entry>g<subscript>4</subscript></entry> + <entry>g<subscript>3</subscript></entry> + <entry>g<subscript>2</subscript></entry> + <entry>g<subscript>1</subscript></entry> + <entry>g<subscript>0</subscript></entry> + </row> + <row id="V4L2-MBUS-FMT-SGRBG10-ALAW8-1X8"> + <entry>V4L2_MBUS_FMT_SGRBG10_ALAW8_1X8</entry> + <entry>0x3017</entry> + <entry></entry> + <entry>-</entry> + <entry>-</entry> + <entry>-</entry> + <entry>-</entry> + <entry>g<subscript>7</subscript></entry> + <entry>g<subscript>6</subscript></entry> + <entry>g<subscript>5</subscript></entry> + <entry>g<subscript>4</subscript></entry> + <entry>g<subscript>3</subscript></entry> + <entry>g<subscript>2</subscript></entry> + <entry>g<subscript>1</subscript></entry> + <entry>g<subscript>0</subscript></entry> + </row> + <row id="V4L2-MBUS-FMT-SRGGB10-ALAW8-1X8"> + <entry>V4L2_MBUS_FMT_SRGGB10_ALAW8_1X8</entry> + <entry>0x3018</entry> + <entry></entry> + <entry>-</entry> + <entry>-</entry> + <entry>-</entry> + <entry>-</entry> + <entry>r<subscript>7</subscript></entry> + <entry>r<subscript>6</subscript></entry> + <entry>r<subscript>5</subscript></entry> + <entry>r<subscript>4</subscript></entry> + <entry>r<subscript>3</subscript></entry> + <entry>r<subscript>2</subscript></entry> + <entry>r<subscript>1</subscript></entry> + <entry>r<subscript>0</subscript></entry> + </row> <row id="V4L2-MBUS-FMT-SBGGR10-DPCM8-1X8"> <entry>V4L2_MBUS_FMT_SBGGR10_DPCM8_1X8</entry> <entry>0x300b</entry> @@ -853,10 +921,16 @@ <title>Packed YUV Formats</title> <para>Those data formats transfer pixel data as (possibly downsampled) Y, U - and V components. The format code is made of the following information. + and V components. Some formats include dummy bits in some of their samples + and are collectively referred to as "YDYC" (Y-Dummy-Y-Chroma) formats. + One cannot rely on the values of these dummy bits as those are undefined. + </para> + <para>The format code is made of the following information. <itemizedlist> <listitem><para>The Y, U and V components order code, as transferred on the - bus. Possible values are YUYV, UYVY, YVYU and VYUY.</para></listitem> + bus. Possible values are YUYV, UYVY, YVYU and VYUY for formats with no + dummy bit, and YDYUYDYV, YDYVYDYU, YUYDYVYD and YVYDYUYD for YDYC formats. + </para></listitem> <listitem><para>The number of bits per pixel component. All components are transferred on the same number of bits. Common values are 8, 10 and 12.</para> </listitem> @@ -877,7 +951,21 @@ U, Y, V, Y order will be named <constant>V4L2_MBUS_FMT_UYVY8_2X8</constant>. </para> - <para>The following table lisst existing packet YUV formats.</para> + <para><xref linkend="v4l2-mbus-pixelcode-yuv8"/> list existing packet YUV + formats and describes the organization of each pixel data in each sample. + When a format pattern is split across multiple samples each of the samples + in the pattern is described.</para> + + <para>The role of each bit transferred over the bus is identified by one + of the following codes.</para> + + <itemizedlist> + <listitem><para>y<subscript>x</subscript> for luma component bit number x</para></listitem> + <listitem><para>u<subscript>x</subscript> for blue chroma component bit number x</para></listitem> + <listitem><para>v<subscript>x</subscript> for red chroma component bit number x</para></listitem> + <listitem><para>- for non-available bits (for positions higher than the bus width)</para></listitem> + <listitem><para>d for dummy bits</para></listitem> + </itemizedlist> <table pgwide="0" frame="none" id="v4l2-mbus-pixelcode-yuv8"> <title>YUV Formats</title> @@ -965,6 +1053,56 @@ <entry>y<subscript>1</subscript></entry> <entry>y<subscript>0</subscript></entry> </row> + <row id="V4L2-MBUS-FMT-UV8-1X8"> + <entry>V4L2_MBUS_FMT_UV8_1X8</entry> + <entry>0x2015</entry> + <entry></entry> + <entry>-</entry> + <entry>-</entry> + <entry>-</entry> + <entry>-</entry> + <entry>-</entry> + <entry>-</entry> + <entry>-</entry> + <entry>-</entry> + <entry>-</entry> + <entry>-</entry> + <entry>-</entry> + <entry>-</entry> + <entry>u<subscript>7</subscript></entry> + <entry>u<subscript>6</subscript></entry> + <entry>u<subscript>5</subscript></entry> + <entry>u<subscript>4</subscript></entry> + <entry>u<subscript>3</subscript></entry> + <entry>u<subscript>2</subscript></entry> + <entry>u<subscript>1</subscript></entry> + <entry>u<subscript>0</subscript></entry> + </row> + <row> + <entry></entry> + <entry></entry> + <entry></entry> + <entry>-</entry> + <entry>-</entry> + <entry>-</entry> + <entry>-</entry> + <entry>-</entry> + <entry>-</entry> + <entry>-</entry> + <entry>-</entry> + <entry>-</entry> + <entry>-</entry> + <entry>-</entry> + <entry>-</entry> + <entry>v<subscript>7</subscript></entry> + <entry>v<subscript>6</subscript></entry> + <entry>v<subscript>5</subscript></entry> + <entry>v<subscript>4</subscript></entry> + <entry>v<subscript>3</subscript></entry> + <entry>v<subscript>2</subscript></entry> + <entry>v<subscript>1</subscript></entry> + <entry>v<subscript>0</subscript></entry> + </row> <row id="V4L2-MBUS-FMT-UYVY8-1_5X8"> <entry>V4L2_MBUS_FMT_UYVY8_1_5X8</entry> <entry>0x2002</entry> @@ -2415,6 +2553,106 @@ <entry>u<subscript>1</subscript></entry> <entry>u<subscript>0</subscript></entry> </row> + <row id="V4L2-MBUS-FMT-YDYUYDYV8-1X16"> + <entry>V4L2_MBUS_FMT_YDYUYDYV8_1X16</entry> + <entry>0x2014</entry> + <entry></entry> + <entry>-</entry> + <entry>-</entry> + <entry>-</entry> + <entry>-</entry> + <entry>y<subscript>7</subscript></entry> + <entry>y<subscript>6</subscript></entry> + <entry>y<subscript>5</subscript></entry> + <entry>y<subscript>4</subscript></entry> + <entry>y<subscript>3</subscript></entry> + <entry>y<subscript>2</subscript></entry> + <entry>y<subscript>1</subscript></entry> + <entry>y<subscript>0</subscript></entry> + <entry>d</entry> + <entry>d</entry> + <entry>d</entry> + <entry>d</entry> + <entry>d</entry> + <entry>d</entry> + <entry>d</entry> + <entry>d</entry> + </row> + <row> + <entry></entry> + <entry></entry> + <entry></entry> + <entry>-</entry> + <entry>-</entry> + <entry>-</entry> + <entry>-</entry> + <entry>y<subscript>7</subscript></entry> + <entry>y<subscript>6</subscript></entry> + <entry>y<subscript>5</subscript></entry> + <entry>y<subscript>4</subscript></entry> + <entry>y<subscript>3</subscript></entry> + <entry>y<subscript>2</subscript></entry> + <entry>y<subscript>1</subscript></entry> + <entry>y<subscript>0</subscript></entry> + <entry>u<subscript>7</subscript></entry> + <entry>u<subscript>6</subscript></entry> + <entry>u<subscript>5</subscript></entry> + <entry>u<subscript>4</subscript></entry> + <entry>u<subscript>3</subscript></entry> + <entry>u<subscript>2</subscript></entry> + <entry>u<subscript>1</subscript></entry> + <entry>u<subscript>0</subscript></entry> + </row> + <row> + <entry></entry> + <entry></entry> + <entry></entry> + <entry>-</entry> + <entry>-</entry> + <entry>-</entry> + <entry>-</entry> + <entry>y<subscript>7</subscript></entry> + <entry>y<subscript>6</subscript></entry> + <entry>y<subscript>5</subscript></entry> + <entry>y<subscript>4</subscript></entry> + <entry>y<subscript>3</subscript></entry> + <entry>y<subscript>2</subscript></entry> + <entry>y<subscript>1</subscript></entry> + <entry>y<subscript>0</subscript></entry> + <entry>d</entry> + <entry>d</entry> + <entry>d</entry> + <entry>d</entry> + <entry>d</entry> + <entry>d</entry> + <entry>d</entry> + <entry>d</entry> + </row> + <row> + <entry></entry> + <entry></entry> + <entry></entry> + <entry>-</entry> + <entry>-</entry> + <entry>-</entry> + <entry>-</entry> + <entry>y<subscript>7</subscript></entry> + <entry>y<subscript>6</subscript></entry> + <entry>y<subscript>5</subscript></entry> + <entry>y<subscript>4</subscript></entry> + <entry>y<subscript>3</subscript></entry> + <entry>y<subscript>2</subscript></entry> + <entry>y<subscript>1</subscript></entry> + <entry>y<subscript>0</subscript></entry> + <entry>v<subscript>7</subscript></entry> + <entry>v<subscript>6</subscript></entry> + <entry>v<subscript>5</subscript></entry> + <entry>v<subscript>4</subscript></entry> + <entry>v<subscript>3</subscript></entry> + <entry>v<subscript>2</subscript></entry> + <entry>v<subscript>1</subscript></entry> + <entry>v<subscript>0</subscript></entry> + </row> <row id="V4L2-MBUS-FMT-YUYV10-1X20"> <entry>V4L2_MBUS_FMT_YUYV10_1X20</entry> <entry>0x200d</entry> diff --git a/include/linux/v4l2-mediabus.h b/include/linux/v4l2-mediabus.h index 5ea7f75..a871a4a 100644 --- a/include/linux/v4l2-mediabus.h +++ b/include/linux/v4l2-mediabus.h @@ -47,8 +47,9 @@ enum v4l2_mbus_pixelcode { V4L2_MBUS_FMT_RGB565_2X8_BE = 0x1007, V4L2_MBUS_FMT_RGB565_2X8_LE = 0x1008, - /* YUV (including grey) - next is 0x2014 */ + /* YUV (including grey) - next is 0x2016 */ V4L2_MBUS_FMT_Y8_1X8 = 0x2001, + V4L2_MBUS_FMT_UV8_1X8 = 0x2015, V4L2_MBUS_FMT_UYVY8_1_5X8 = 0x2002, V4L2_MBUS_FMT_VYUY8_1_5X8 = 0x2003, V4L2_MBUS_FMT_YUYV8_1_5X8 = 0x2004, @@ -65,14 +66,19 @@ enum v4l2_mbus_pixelcode { V4L2_MBUS_FMT_VYUY8_1X16 = 0x2010, V4L2_MBUS_FMT_YUYV8_1X16 = 0x2011, V4L2_MBUS_FMT_YVYU8_1X16 = 0x2012, + V4L2_MBUS_FMT_YDYUYDYV8_1X16 = 0x2014, V4L2_MBUS_FMT_YUYV10_1X20 = 0x200d, V4L2_MBUS_FMT_YVYU10_1X20 = 0x200e, - /* Bayer - next is 0x3015 */ + /* Bayer - next is 0x3019 */ V4L2_MBUS_FMT_SBGGR8_1X8 = 0x3001, V4L2_MBUS_FMT_SGBRG8_1X8 = 0x3013, V4L2_MBUS_FMT_SGRBG8_1X8 = 0x3002, V4L2_MBUS_FMT_SRGGB8_1X8 = 0x3014, + V4L2_MBUS_FMT_SBGGR10_ALAW8_1X8 = 0x3015, + V4L2_MBUS_FMT_SGBRG10_ALAW8_1X8 = 0x3016, + V4L2_MBUS_FMT_SGRBG10_ALAW8_1X8 = 0x3017, + V4L2_MBUS_FMT_SRGGB10_ALAW8_1X8 = 0x3018, V4L2_MBUS_FMT_SBGGR10_DPCM8_1X8 = 0x300b, V4L2_MBUS_FMT_SGBRG10_DPCM8_1X8 = 0x300c, V4L2_MBUS_FMT_SGRBG10_DPCM8_1X8 = 0x3009, -- 1.7.0.4 ^ permalink raw reply related [flat|nested] 15+ messages in thread
* Re: [PATCH v7 1/2] media: add new mediabus format enums for dm365 2012-07-27 10:55 ` [PATCH v7 1/2] media: add new mediabus format enums for dm365 Prabhakar Lad @ 2012-07-27 22:01 ` Sakari Ailus 2012-07-30 18:36 ` Hans Verkuil 0 siblings, 1 reply; 15+ messages in thread From: Sakari Ailus @ 2012-07-27 22:01 UTC (permalink / raw) To: Prabhakar Lad; +Cc: LMML, dlos, Manjunath Hadli, Guennadi Liakhovetski Hi Prabhakar, Thanks for the patch, and my apologies for delayed answer! On Fri, Jul 27, 2012 at 04:25:04PM +0530, Prabhakar Lad wrote: > From: Manjunath Hadli <manjunath.hadli@ti.com> > > add new enum entries for supporting the media-bus formats on dm365. > These include some bayer and some non-bayer formats. > V4L2_MBUS_FMT_YDYUYDYV8_1X16 and V4L2_MBUS_FMT_UV8_1X8 are used > internal to the hardware by the resizer. > V4L2_MBUS_FMT_SBGGR10_ALAW8_1X8 represents the bayer ALAW format > that is supported by dm365 hardware. > > Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> > Acked-by: Hans Verkuil <hans.verkuil@cisco.com> > Signed-off-by: Manjunath Hadli <manjunath.hadli@ti.com> > Signed-off-by: Lad, Prabhakar <prabhakar.lad@ti.com> > Cc: Sakari Ailus <sakari.ailus@iki.fi> > Cc: Guennadi Liakhovetski <g.liakhovetski@gmx.de> > --- > Documentation/DocBook/media/v4l/subdev-formats.xml | 250 +++++++++++++++++++- > include/linux/v4l2-mediabus.h | 10 +- > 2 files changed, 252 insertions(+), 8 deletions(-) > > diff --git a/Documentation/DocBook/media/v4l/subdev-formats.xml b/Documentation/DocBook/media/v4l/subdev-formats.xml > index 49c532e..75dc275 100644 > --- a/Documentation/DocBook/media/v4l/subdev-formats.xml > +++ b/Documentation/DocBook/media/v4l/subdev-formats.xml > @@ -353,9 +353,9 @@ > <listitem><para>The number of bits per pixel component. All components are > transferred on the same number of bits. Common values are 8, 10 and 12.</para> > </listitem> > - <listitem><para>If the pixel components are DPCM-compressed, a mention of the > - DPCM compression and the number of bits per compressed pixel component.</para> > - </listitem> > + <listitem><para>The compression (optional). If the pixel components are > + ALAW- or DPCM-compressed, a mention of the compression scheme and the > + number of bits per compressed pixel component.</para></listitem> > <listitem><para>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.</para></listitem> > @@ -504,6 +504,74 @@ > <entry>r<subscript>1</subscript></entry> > <entry>r<subscript>0</subscript></entry> > </row> > + <row id="V4L2-MBUS-FMT-SBGGR10-ALAW8-1X8"> > + <entry>V4L2_MBUS_FMT_SBGGR10_ALAW8_1X8</entry> > + <entry>0x3015</entry> > + <entry></entry> > + <entry>-</entry> > + <entry>-</entry> > + <entry>-</entry> > + <entry>-</entry> > + <entry>b<subscript>7</subscript></entry> > + <entry>b<subscript>6</subscript></entry> > + <entry>b<subscript>5</subscript></entry> > + <entry>b<subscript>4</subscript></entry> > + <entry>b<subscript>3</subscript></entry> > + <entry>b<subscript>2</subscript></entry> > + <entry>b<subscript>1</subscript></entry> > + <entry>b<subscript>0</subscript></entry> > + </row> > + <row id="V4L2-MBUS-FMT-SGBRG10-ALAW8-1X8"> > + <entry>V4L2_MBUS_FMT_SGBRG10_ALAW8_1X8</entry> > + <entry>0x3016</entry> > + <entry></entry> > + <entry>-</entry> > + <entry>-</entry> > + <entry>-</entry> > + <entry>-</entry> > + <entry>g<subscript>7</subscript></entry> > + <entry>g<subscript>6</subscript></entry> > + <entry>g<subscript>5</subscript></entry> > + <entry>g<subscript>4</subscript></entry> > + <entry>g<subscript>3</subscript></entry> > + <entry>g<subscript>2</subscript></entry> > + <entry>g<subscript>1</subscript></entry> > + <entry>g<subscript>0</subscript></entry> > + </row> > + <row id="V4L2-MBUS-FMT-SGRBG10-ALAW8-1X8"> > + <entry>V4L2_MBUS_FMT_SGRBG10_ALAW8_1X8</entry> > + <entry>0x3017</entry> > + <entry></entry> > + <entry>-</entry> > + <entry>-</entry> > + <entry>-</entry> > + <entry>-</entry> > + <entry>g<subscript>7</subscript></entry> > + <entry>g<subscript>6</subscript></entry> > + <entry>g<subscript>5</subscript></entry> > + <entry>g<subscript>4</subscript></entry> > + <entry>g<subscript>3</subscript></entry> > + <entry>g<subscript>2</subscript></entry> > + <entry>g<subscript>1</subscript></entry> > + <entry>g<subscript>0</subscript></entry> > + </row> > + <row id="V4L2-MBUS-FMT-SRGGB10-ALAW8-1X8"> > + <entry>V4L2_MBUS_FMT_SRGGB10_ALAW8_1X8</entry> > + <entry>0x3018</entry> > + <entry></entry> > + <entry>-</entry> > + <entry>-</entry> > + <entry>-</entry> > + <entry>-</entry> > + <entry>r<subscript>7</subscript></entry> > + <entry>r<subscript>6</subscript></entry> > + <entry>r<subscript>5</subscript></entry> > + <entry>r<subscript>4</subscript></entry> > + <entry>r<subscript>3</subscript></entry> > + <entry>r<subscript>2</subscript></entry> > + <entry>r<subscript>1</subscript></entry> > + <entry>r<subscript>0</subscript></entry> > + </row> > <row id="V4L2-MBUS-FMT-SBGGR10-DPCM8-1X8"> > <entry>V4L2_MBUS_FMT_SBGGR10_DPCM8_1X8</entry> > <entry>0x300b</entry> > @@ -853,10 +921,16 @@ > <title>Packed YUV Formats</title> > > <para>Those data formats transfer pixel data as (possibly downsampled) Y, U > - and V components. The format code is made of the following information. > + and V components. Some formats include dummy bits in some of their samples > + and are collectively referred to as "YDYC" (Y-Dummy-Y-Chroma) formats. > + One cannot rely on the values of these dummy bits as those are undefined. > + </para> > + <para>The format code is made of the following information. > <itemizedlist> > <listitem><para>The Y, U and V components order code, as transferred on the > - bus. Possible values are YUYV, UYVY, YVYU and VYUY.</para></listitem> > + bus. Possible values are YUYV, UYVY, YVYU and VYUY for formats with no > + dummy bit, and YDYUYDYV, YDYVYDYU, YUYDYVYD and YVYDYUYD for YDYC formats. > + </para></listitem> > <listitem><para>The number of bits per pixel component. All components are > transferred on the same number of bits. Common values are 8, 10 and 12.</para> > </listitem> I dicussed dummy vs. padding (zeros) with Laurent and we concluded we should use zero padding instead. The difference is that when processing the pixels no extra operations are necessary to get rid of the dummy data when the dummy bits are actually zero --- which in practice always is the case. I'm not aware of hardware that would assign padding bits (in this very purpose) that are a part of writes the width of bus width something else than zeros. It wouldn't make much sense either. So I suggest that dummy is replaced by padding which is defined to be zero. The letter in the format name could be 'Z', for example. Hans: what do you think? Kind regards, -- Sakari Ailus e-mail: sakari.ailus@iki.fi jabber/XMPP/Gmail: sailus@retiisi.org.uk ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH v7 1/2] media: add new mediabus format enums for dm365 2012-07-27 22:01 ` Sakari Ailus @ 2012-07-30 18:36 ` Hans Verkuil 2012-07-30 19:06 ` Laurent Pinchart 0 siblings, 1 reply; 15+ messages in thread From: Hans Verkuil @ 2012-07-30 18:36 UTC (permalink / raw) To: Sakari Ailus Cc: Prabhakar Lad, LMML, dlos, Manjunath Hadli, Guennadi Liakhovetski On Sat July 28 2012 00:01:24 Sakari Ailus wrote: > Hi Prabhakar, > > Thanks for the patch, and my apologies for delayed answer! > > On Fri, Jul 27, 2012 at 04:25:04PM +0530, Prabhakar Lad wrote: > > From: Manjunath Hadli <manjunath.hadli@ti.com> > > > > add new enum entries for supporting the media-bus formats on dm365. > > These include some bayer and some non-bayer formats. > > V4L2_MBUS_FMT_YDYUYDYV8_1X16 and V4L2_MBUS_FMT_UV8_1X8 are used > > internal to the hardware by the resizer. > > V4L2_MBUS_FMT_SBGGR10_ALAW8_1X8 represents the bayer ALAW format > > that is supported by dm365 hardware. > > > > Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> > > Acked-by: Hans Verkuil <hans.verkuil@cisco.com> > > Signed-off-by: Manjunath Hadli <manjunath.hadli@ti.com> > > Signed-off-by: Lad, Prabhakar <prabhakar.lad@ti.com> > > Cc: Sakari Ailus <sakari.ailus@iki.fi> > > Cc: Guennadi Liakhovetski <g.liakhovetski@gmx.de> > > --- > > Documentation/DocBook/media/v4l/subdev-formats.xml | 250 +++++++++++++++++++- > > include/linux/v4l2-mediabus.h | 10 +- > > 2 files changed, 252 insertions(+), 8 deletions(-) > > > > diff --git a/Documentation/DocBook/media/v4l/subdev-formats.xml b/Documentation/DocBook/media/v4l/subdev-formats.xml > > index 49c532e..75dc275 100644 > > --- a/Documentation/DocBook/media/v4l/subdev-formats.xml > > +++ b/Documentation/DocBook/media/v4l/subdev-formats.xml > > @@ -353,9 +353,9 @@ > > <listitem><para>The number of bits per pixel component. All components are > > transferred on the same number of bits. Common values are 8, 10 and 12.</para> > > </listitem> > > - <listitem><para>If the pixel components are DPCM-compressed, a mention of the > > - DPCM compression and the number of bits per compressed pixel component.</para> > > - </listitem> > > + <listitem><para>The compression (optional). If the pixel components are > > + ALAW- or DPCM-compressed, a mention of the compression scheme and the > > + number of bits per compressed pixel component.</para></listitem> > > <listitem><para>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.</para></listitem> > > @@ -504,6 +504,74 @@ > > <entry>r<subscript>1</subscript></entry> > > <entry>r<subscript>0</subscript></entry> > > </row> > > + <row id="V4L2-MBUS-FMT-SBGGR10-ALAW8-1X8"> > > + <entry>V4L2_MBUS_FMT_SBGGR10_ALAW8_1X8</entry> > > + <entry>0x3015</entry> > > + <entry></entry> > > + <entry>-</entry> > > + <entry>-</entry> > > + <entry>-</entry> > > + <entry>-</entry> > > + <entry>b<subscript>7</subscript></entry> > > + <entry>b<subscript>6</subscript></entry> > > + <entry>b<subscript>5</subscript></entry> > > + <entry>b<subscript>4</subscript></entry> > > + <entry>b<subscript>3</subscript></entry> > > + <entry>b<subscript>2</subscript></entry> > > + <entry>b<subscript>1</subscript></entry> > > + <entry>b<subscript>0</subscript></entry> > > + </row> > > + <row id="V4L2-MBUS-FMT-SGBRG10-ALAW8-1X8"> > > + <entry>V4L2_MBUS_FMT_SGBRG10_ALAW8_1X8</entry> > > + <entry>0x3016</entry> > > + <entry></entry> > > + <entry>-</entry> > > + <entry>-</entry> > > + <entry>-</entry> > > + <entry>-</entry> > > + <entry>g<subscript>7</subscript></entry> > > + <entry>g<subscript>6</subscript></entry> > > + <entry>g<subscript>5</subscript></entry> > > + <entry>g<subscript>4</subscript></entry> > > + <entry>g<subscript>3</subscript></entry> > > + <entry>g<subscript>2</subscript></entry> > > + <entry>g<subscript>1</subscript></entry> > > + <entry>g<subscript>0</subscript></entry> > > + </row> > > + <row id="V4L2-MBUS-FMT-SGRBG10-ALAW8-1X8"> > > + <entry>V4L2_MBUS_FMT_SGRBG10_ALAW8_1X8</entry> > > + <entry>0x3017</entry> > > + <entry></entry> > > + <entry>-</entry> > > + <entry>-</entry> > > + <entry>-</entry> > > + <entry>-</entry> > > + <entry>g<subscript>7</subscript></entry> > > + <entry>g<subscript>6</subscript></entry> > > + <entry>g<subscript>5</subscript></entry> > > + <entry>g<subscript>4</subscript></entry> > > + <entry>g<subscript>3</subscript></entry> > > + <entry>g<subscript>2</subscript></entry> > > + <entry>g<subscript>1</subscript></entry> > > + <entry>g<subscript>0</subscript></entry> > > + </row> > > + <row id="V4L2-MBUS-FMT-SRGGB10-ALAW8-1X8"> > > + <entry>V4L2_MBUS_FMT_SRGGB10_ALAW8_1X8</entry> > > + <entry>0x3018</entry> > > + <entry></entry> > > + <entry>-</entry> > > + <entry>-</entry> > > + <entry>-</entry> > > + <entry>-</entry> > > + <entry>r<subscript>7</subscript></entry> > > + <entry>r<subscript>6</subscript></entry> > > + <entry>r<subscript>5</subscript></entry> > > + <entry>r<subscript>4</subscript></entry> > > + <entry>r<subscript>3</subscript></entry> > > + <entry>r<subscript>2</subscript></entry> > > + <entry>r<subscript>1</subscript></entry> > > + <entry>r<subscript>0</subscript></entry> > > + </row> > > <row id="V4L2-MBUS-FMT-SBGGR10-DPCM8-1X8"> > > <entry>V4L2_MBUS_FMT_SBGGR10_DPCM8_1X8</entry> > > <entry>0x300b</entry> > > @@ -853,10 +921,16 @@ > > <title>Packed YUV Formats</title> > > > > <para>Those data formats transfer pixel data as (possibly downsampled) Y, U > > - and V components. The format code is made of the following information. > > + and V components. Some formats include dummy bits in some of their samples > > + and are collectively referred to as "YDYC" (Y-Dummy-Y-Chroma) formats. > > + One cannot rely on the values of these dummy bits as those are undefined. > > + </para> > > + <para>The format code is made of the following information. > > <itemizedlist> > > <listitem><para>The Y, U and V components order code, as transferred on the > > - bus. Possible values are YUYV, UYVY, YVYU and VYUY.</para></listitem> > > + bus. Possible values are YUYV, UYVY, YVYU and VYUY for formats with no > > + dummy bit, and YDYUYDYV, YDYVYDYU, YUYDYVYD and YVYDYUYD for YDYC formats. > > + </para></listitem> > > <listitem><para>The number of bits per pixel component. All components are > > transferred on the same number of bits. Common values are 8, 10 and 12.</para> > > </listitem> > > I dicussed dummy vs. padding (zeros) with Laurent and we concluded we should > use zero padding instead. The difference is that when processing the pixels > no extra operations are necessary to get rid of the dummy data when the > dummy bits are actually zero --- which in practice always is the case. > > I'm not aware of hardware that would assign padding bits (in this very > purpose) that are a part of writes the width of bus width something else > than zeros. It wouldn't make much sense either. > > So I suggest that dummy is replaced by padding which is defined to be zero. > > The letter in the format name could be 'Z', for example. > > Hans: what do you think? Bad idea. First of all, some hardware or FPGA can insert different values there. It's something that Cisco uses in some cases: it makes it easier to identify the dummy values if they have a non-zero fixed value. Another reason for not doing this is when such formats are used to display video: you don't want to force the software to fill in the dummy values with a specific value for no good reason. That would only cost extra CPU cycles. Regards, Hans > > Kind regards, > > ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH v7 1/2] media: add new mediabus format enums for dm365 2012-07-30 18:36 ` Hans Verkuil @ 2012-07-30 19:06 ` Laurent Pinchart 2012-07-30 19:19 ` Hans Verkuil 2012-07-30 19:24 ` Sylwester Nawrocki 0 siblings, 2 replies; 15+ messages in thread From: Laurent Pinchart @ 2012-07-30 19:06 UTC (permalink / raw) To: davinci-linux-open-source Cc: Hans Verkuil, Sakari Ailus, LMML, Guennadi Liakhovetski Hi Hans, On Monday 30 July 2012 20:36:36 Hans Verkuil wrote: > On Sat July 28 2012 00:01:24 Sakari Ailus wrote: > > On Fri, Jul 27, 2012 at 04:25:04PM +0530, Prabhakar Lad wrote: > > > From: Manjunath Hadli <manjunath.hadli@ti.com> > > > > > > add new enum entries for supporting the media-bus formats on dm365. > > > These include some bayer and some non-bayer formats. > > > V4L2_MBUS_FMT_YDYUYDYV8_1X16 and V4L2_MBUS_FMT_UV8_1X8 are used > > > internal to the hardware by the resizer. > > > V4L2_MBUS_FMT_SBGGR10_ALAW8_1X8 represents the bayer ALAW format > > > that is supported by dm365 hardware. > > > > > > Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> > > > Acked-by: Hans Verkuil <hans.verkuil@cisco.com> > > > Signed-off-by: Manjunath Hadli <manjunath.hadli@ti.com> > > > Signed-off-by: Lad, Prabhakar <prabhakar.lad@ti.com> > > > Cc: Sakari Ailus <sakari.ailus@iki.fi> > > > Cc: Guennadi Liakhovetski <g.liakhovetski@gmx.de> > > > --- > > > > > > Documentation/DocBook/media/v4l/subdev-formats.xml | 250 > > > +++++++++++++++++++- include/linux/v4l2-mediabus.h > > > | 10 +- > > > 2 files changed, 252 insertions(+), 8 deletions(-) > > > > > > diff --git a/Documentation/DocBook/media/v4l/subdev-formats.xml > > > b/Documentation/DocBook/media/v4l/subdev-formats.xml index > > > 49c532e..75dc275 100644 > > > --- a/Documentation/DocBook/media/v4l/subdev-formats.xml > > > +++ b/Documentation/DocBook/media/v4l/subdev-formats.xml > > > @@ -353,9 +353,9 @@ > > > > > > <listitem><para>The number of bits per pixel component. All components > > > are > > > transferred on the same number of bits. Common values are 8, 10 and > > > 12.</para> </listitem> > > > > > > - <listitem><para>If the pixel components are DPCM-compressed, a mention > > > of the - DPCM compression and the number of bits per compressed pixel > > > component.</para> - </listitem> > > > + <listitem><para>The compression (optional). If the pixel components > > > are > > > + ALAW- or DPCM-compressed, a mention of the compression scheme and the > > > + number of bits per compressed pixel component.</para></listitem> > > > > > > <listitem><para>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.</para></listitem> > > > > > > @@ -504,6 +504,74 @@ > > > > > > <entry>r<subscript>1</subscript></entry> > > > <entry>r<subscript>0</subscript></entry> > > > > > > </row> > > > > > > + <row id="V4L2-MBUS-FMT-SBGGR10-ALAW8-1X8"> > > > + <entry>V4L2_MBUS_FMT_SBGGR10_ALAW8_1X8</entry> > > > + <entry>0x3015</entry> > > > + <entry></entry> > > > + <entry>-</entry> > > > + <entry>-</entry> > > > + <entry>-</entry> > > > + <entry>-</entry> > > > + <entry>b<subscript>7</subscript></entry> > > > + <entry>b<subscript>6</subscript></entry> > > > + <entry>b<subscript>5</subscript></entry> > > > + <entry>b<subscript>4</subscript></entry> > > > + <entry>b<subscript>3</subscript></entry> > > > + <entry>b<subscript>2</subscript></entry> > > > + <entry>b<subscript>1</subscript></entry> > > > + <entry>b<subscript>0</subscript></entry> > > > + </row> > > > + <row id="V4L2-MBUS-FMT-SGBRG10-ALAW8-1X8"> > > > + <entry>V4L2_MBUS_FMT_SGBRG10_ALAW8_1X8</entry> > > > + <entry>0x3016</entry> > > > + <entry></entry> > > > + <entry>-</entry> > > > + <entry>-</entry> > > > + <entry>-</entry> > > > + <entry>-</entry> > > > + <entry>g<subscript>7</subscript></entry> > > > + <entry>g<subscript>6</subscript></entry> > > > + <entry>g<subscript>5</subscript></entry> > > > + <entry>g<subscript>4</subscript></entry> > > > + <entry>g<subscript>3</subscript></entry> > > > + <entry>g<subscript>2</subscript></entry> > > > + <entry>g<subscript>1</subscript></entry> > > > + <entry>g<subscript>0</subscript></entry> > > > + </row> > > > + <row id="V4L2-MBUS-FMT-SGRBG10-ALAW8-1X8"> > > > + <entry>V4L2_MBUS_FMT_SGRBG10_ALAW8_1X8</entry> > > > + <entry>0x3017</entry> > > > + <entry></entry> > > > + <entry>-</entry> > > > + <entry>-</entry> > > > + <entry>-</entry> > > > + <entry>-</entry> > > > + <entry>g<subscript>7</subscript></entry> > > > + <entry>g<subscript>6</subscript></entry> > > > + <entry>g<subscript>5</subscript></entry> > > > + <entry>g<subscript>4</subscript></entry> > > > + <entry>g<subscript>3</subscript></entry> > > > + <entry>g<subscript>2</subscript></entry> > > > + <entry>g<subscript>1</subscript></entry> > > > + <entry>g<subscript>0</subscript></entry> > > > + </row> > > > + <row id="V4L2-MBUS-FMT-SRGGB10-ALAW8-1X8"> > > > + <entry>V4L2_MBUS_FMT_SRGGB10_ALAW8_1X8</entry> > > > + <entry>0x3018</entry> > > > + <entry></entry> > > > + <entry>-</entry> > > > + <entry>-</entry> > > > + <entry>-</entry> > > > + <entry>-</entry> > > > + <entry>r<subscript>7</subscript></entry> > > > + <entry>r<subscript>6</subscript></entry> > > > + <entry>r<subscript>5</subscript></entry> > > > + <entry>r<subscript>4</subscript></entry> > > > + <entry>r<subscript>3</subscript></entry> > > > + <entry>r<subscript>2</subscript></entry> > > > + <entry>r<subscript>1</subscript></entry> > > > + <entry>r<subscript>0</subscript></entry> > > > + </row> > > > > > > <row id="V4L2-MBUS-FMT-SBGGR10-DPCM8-1X8"> > > > > > > <entry>V4L2_MBUS_FMT_SBGGR10_DPCM8_1X8</entry> > > > <entry>0x300b</entry> > > > > > > @@ -853,10 +921,16 @@ > > > > > > <title>Packed YUV Formats</title> > > > > > > <para>Those data formats transfer pixel data as (possibly > > > downsampled) Y, U > > > > > > - and V components. The format code is made of the following > > > information. + and V components. Some formats include dummy bits > > > in some of their samples + and are collectively referred to as > > > "YDYC" (Y-Dummy-Y-Chroma) formats. + One cannot rely on the values > > > of these dummy bits as those are undefined. + </para> > > > + <para>The format code is made of the following information. > > > > > > <itemizedlist> > > > > > > <listitem><para>The Y, U and V components order code, as transferred > > > on the > > > > > > - bus. Possible values are YUYV, UYVY, YVYU and VYUY.</para></listitem> > > > + bus. Possible values are YUYV, UYVY, YVYU and VYUY for formats with no > > > + dummy bit, and YDYUYDYV, YDYVYDYU, YUYDYVYD and YVYDYUYD for YDYC > > > formats. + </para></listitem> > > > > > > <listitem><para>The number of bits per pixel component. All components > > > are > > > transferred on the same number of bits. Common values are 8, 10 and > > > 12.</para> </listitem> > > > > I dicussed dummy vs. padding (zeros) with Laurent and we concluded we > > should use zero padding instead. The difference is that when processing > > the pixels no extra operations are necessary to get rid of the dummy data > > when the dummy bits are actually zero --- which in practice always is the > > case. > > > > I'm not aware of hardware that would assign padding bits (in this very > > purpose) that are a part of writes the width of bus width something else > > than zeros. It wouldn't make much sense either. > > > > So I suggest that dummy is replaced by padding which is defined to be > > zero. > > > > The letter in the format name could be 'Z', for example. > > > > Hans: what do you think? > > Bad idea. First of all, some hardware or FPGA can insert different values > there. It's something that Cisco uses in some cases: it makes it easier to > identify the dummy values if they have a non-zero fixed value. > > Another reason for not doing this is when such formats are used to display > video: you don't want to force the software to fill in the dummy values > with a specific value for no good reason. That would only cost extra CPU > cycles. On the other hand, when you process data that includes dummy bits stored in memory, knowing that the dummy bits are zero can save a mask operation. I don't have a strong opinion whether we should use zero or dummy bits for media bus formats. For memory formats I'd be inclined to use zero bits (at least when capturing). -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH v7 1/2] media: add new mediabus format enums for dm365 2012-07-30 19:06 ` Laurent Pinchart @ 2012-07-30 19:19 ` Hans Verkuil 2012-07-31 11:17 ` Sakari Ailus 2012-07-30 19:24 ` Sylwester Nawrocki 1 sibling, 1 reply; 15+ messages in thread From: Hans Verkuil @ 2012-07-30 19:19 UTC (permalink / raw) To: Laurent Pinchart Cc: davinci-linux-open-source, Sakari Ailus, LMML, Guennadi Liakhovetski On Mon July 30 2012 21:06:33 Laurent Pinchart wrote: > Hi Hans, > > On Monday 30 July 2012 20:36:36 Hans Verkuil wrote: > > On Sat July 28 2012 00:01:24 Sakari Ailus wrote: > > > On Fri, Jul 27, 2012 at 04:25:04PM +0530, Prabhakar Lad wrote: > > > > From: Manjunath Hadli <manjunath.hadli@ti.com> > > > > > > > > add new enum entries for supporting the media-bus formats on dm365. > > > > These include some bayer and some non-bayer formats. > > > > V4L2_MBUS_FMT_YDYUYDYV8_1X16 and V4L2_MBUS_FMT_UV8_1X8 are used > > > > internal to the hardware by the resizer. > > > > V4L2_MBUS_FMT_SBGGR10_ALAW8_1X8 represents the bayer ALAW format > > > > that is supported by dm365 hardware. > > > > > > > > Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> > > > > Acked-by: Hans Verkuil <hans.verkuil@cisco.com> > > > > Signed-off-by: Manjunath Hadli <manjunath.hadli@ti.com> > > > > Signed-off-by: Lad, Prabhakar <prabhakar.lad@ti.com> > > > > Cc: Sakari Ailus <sakari.ailus@iki.fi> > > > > Cc: Guennadi Liakhovetski <g.liakhovetski@gmx.de> > > > > --- > > > > > > > > Documentation/DocBook/media/v4l/subdev-formats.xml | 250 > > > > +++++++++++++++++++- include/linux/v4l2-mediabus.h > > > > | 10 +- > > > > 2 files changed, 252 insertions(+), 8 deletions(-) > > > > > > > > diff --git a/Documentation/DocBook/media/v4l/subdev-formats.xml > > > > b/Documentation/DocBook/media/v4l/subdev-formats.xml index > > > > 49c532e..75dc275 100644 > > > > --- a/Documentation/DocBook/media/v4l/subdev-formats.xml > > > > +++ b/Documentation/DocBook/media/v4l/subdev-formats.xml > > > > @@ -353,9 +353,9 @@ > > > > > > > > <listitem><para>The number of bits per pixel component. All > components > > > > are > > > > transferred on the same number of bits. Common values are 8, 10 and > > > > 12.</para> </listitem> > > > > > > > > - <listitem><para>If the pixel components are DPCM-compressed, a > mention > > > > of the - DPCM compression and the number of bits per compressed pixel > > > > component.</para> - </listitem> > > > > + <listitem><para>The compression (optional). If the pixel components > > > > are > > > > + ALAW- or DPCM-compressed, a mention of the compression scheme and the > > > > + number of bits per compressed pixel component.</para></listitem> > > > > > > > > <listitem><para>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.</para></listitem> > > > > > > > > @@ -504,6 +504,74 @@ > > > > > > > > <entry>r<subscript>1</subscript></entry> > > > > <entry>r<subscript>0</subscript></entry> > > > > > > > > </row> > > > > > > > > + <row id="V4L2-MBUS-FMT-SBGGR10-ALAW8-1X8"> > > > > + <entry>V4L2_MBUS_FMT_SBGGR10_ALAW8_1X8</entry> > > > > + <entry>0x3015</entry> > > > > + <entry></entry> > > > > + <entry>-</entry> > > > > + <entry>-</entry> > > > > + <entry>-</entry> > > > > + <entry>-</entry> > > > > + <entry>b<subscript>7</subscript></entry> > > > > + <entry>b<subscript>6</subscript></entry> > > > > + <entry>b<subscript>5</subscript></entry> > > > > + <entry>b<subscript>4</subscript></entry> > > > > + <entry>b<subscript>3</subscript></entry> > > > > + <entry>b<subscript>2</subscript></entry> > > > > + <entry>b<subscript>1</subscript></entry> > > > > + <entry>b<subscript>0</subscript></entry> > > > > + </row> > > > > + <row id="V4L2-MBUS-FMT-SGBRG10-ALAW8-1X8"> > > > > + <entry>V4L2_MBUS_FMT_SGBRG10_ALAW8_1X8</entry> > > > > + <entry>0x3016</entry> > > > > + <entry></entry> > > > > + <entry>-</entry> > > > > + <entry>-</entry> > > > > + <entry>-</entry> > > > > + <entry>-</entry> > > > > + <entry>g<subscript>7</subscript></entry> > > > > + <entry>g<subscript>6</subscript></entry> > > > > + <entry>g<subscript>5</subscript></entry> > > > > + <entry>g<subscript>4</subscript></entry> > > > > + <entry>g<subscript>3</subscript></entry> > > > > + <entry>g<subscript>2</subscript></entry> > > > > + <entry>g<subscript>1</subscript></entry> > > > > + <entry>g<subscript>0</subscript></entry> > > > > + </row> > > > > + <row id="V4L2-MBUS-FMT-SGRBG10-ALAW8-1X8"> > > > > + <entry>V4L2_MBUS_FMT_SGRBG10_ALAW8_1X8</entry> > > > > + <entry>0x3017</entry> > > > > + <entry></entry> > > > > + <entry>-</entry> > > > > + <entry>-</entry> > > > > + <entry>-</entry> > > > > + <entry>-</entry> > > > > + <entry>g<subscript>7</subscript></entry> > > > > + <entry>g<subscript>6</subscript></entry> > > > > + <entry>g<subscript>5</subscript></entry> > > > > + <entry>g<subscript>4</subscript></entry> > > > > + <entry>g<subscript>3</subscript></entry> > > > > + <entry>g<subscript>2</subscript></entry> > > > > + <entry>g<subscript>1</subscript></entry> > > > > + <entry>g<subscript>0</subscript></entry> > > > > + </row> > > > > + <row id="V4L2-MBUS-FMT-SRGGB10-ALAW8-1X8"> > > > > + <entry>V4L2_MBUS_FMT_SRGGB10_ALAW8_1X8</entry> > > > > + <entry>0x3018</entry> > > > > + <entry></entry> > > > > + <entry>-</entry> > > > > + <entry>-</entry> > > > > + <entry>-</entry> > > > > + <entry>-</entry> > > > > + <entry>r<subscript>7</subscript></entry> > > > > + <entry>r<subscript>6</subscript></entry> > > > > + <entry>r<subscript>5</subscript></entry> > > > > + <entry>r<subscript>4</subscript></entry> > > > > + <entry>r<subscript>3</subscript></entry> > > > > + <entry>r<subscript>2</subscript></entry> > > > > + <entry>r<subscript>1</subscript></entry> > > > > + <entry>r<subscript>0</subscript></entry> > > > > + </row> > > > > > > > > <row id="V4L2-MBUS-FMT-SBGGR10-DPCM8-1X8"> > > > > > > > > <entry>V4L2_MBUS_FMT_SBGGR10_DPCM8_1X8</entry> > > > > <entry>0x300b</entry> > > > > > > > > @@ -853,10 +921,16 @@ > > > > > > > > <title>Packed YUV Formats</title> > > > > > > > > <para>Those data formats transfer pixel data as (possibly > > > > downsampled) Y, U > > > > > > > > - and V components. The format code is made of the following > > > > information. + and V components. Some formats include dummy bits > > > > in some of their samples + and are collectively referred to as > > > > "YDYC" (Y-Dummy-Y-Chroma) formats. + One cannot rely on the values > > > > of these dummy bits as those are undefined. + </para> > > > > + <para>The format code is made of the following information. > > > > > > > > <itemizedlist> > > > > > > > > <listitem><para>The Y, U and V components order code, as transferred > > > > on the > > > > > > > > - bus. Possible values are YUYV, UYVY, YVYU and VYUY.</para></listitem> > > > > + bus. Possible values are YUYV, UYVY, YVYU and VYUY for formats with > no > > > > + dummy bit, and YDYUYDYV, YDYVYDYU, YUYDYVYD and YVYDYUYD for YDYC > > > > formats. + </para></listitem> > > > > > > > > <listitem><para>The number of bits per pixel component. All > components > > > > are > > > > transferred on the same number of bits. Common values are 8, 10 and > > > > 12.</para> </listitem> > > > > > > I dicussed dummy vs. padding (zeros) with Laurent and we concluded we > > > should use zero padding instead. The difference is that when processing > > > the pixels no extra operations are necessary to get rid of the dummy data > > > when the dummy bits are actually zero --- which in practice always is the > > > case. > > > > > > I'm not aware of hardware that would assign padding bits (in this very > > > purpose) that are a part of writes the width of bus width something else > > > than zeros. It wouldn't make much sense either. > > > > > > So I suggest that dummy is replaced by padding which is defined to be > > > zero. > > > > > > The letter in the format name could be 'Z', for example. > > > > > > Hans: what do you think? > > > > Bad idea. First of all, some hardware or FPGA can insert different values > > there. It's something that Cisco uses in some cases: it makes it easier to > > identify the dummy values if they have a non-zero fixed value. > > > > Another reason for not doing this is when such formats are used to display > > video: you don't want to force the software to fill in the dummy values > > with a specific value for no good reason. That would only cost extra CPU > > cycles. > > On the other hand, when you process data that includes dummy bits stored in > memory, knowing that the dummy bits are zero can save a mask operation. > > I don't have a strong opinion whether we should use zero or dummy bits for > media bus formats. For memory formats I'd be inclined to use zero bits (at > least when capturing). And make a new pixel format if you have hardware that doesn't use zero? I think it's overkill IMHO. Regards, Hans ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH v7 1/2] media: add new mediabus format enums for dm365 2012-07-30 19:19 ` Hans Verkuil @ 2012-07-31 11:17 ` Sakari Ailus 2012-07-31 11:28 ` Hans Verkuil 0 siblings, 1 reply; 15+ messages in thread From: Sakari Ailus @ 2012-07-31 11:17 UTC (permalink / raw) To: Hans Verkuil Cc: Laurent Pinchart, davinci-linux-open-source, LMML, Guennadi Liakhovetski Hi Hans and Laurent, On Mon, Jul 30, 2012 at 09:19:13PM +0200, Hans Verkuil wrote: > On Mon July 30 2012 21:06:33 Laurent Pinchart wrote: > > Hi Hans, > > > > On Monday 30 July 2012 20:36:36 Hans Verkuil wrote: > > > On Sat July 28 2012 00:01:24 Sakari Ailus wrote: > > > > On Fri, Jul 27, 2012 at 04:25:04PM +0530, Prabhakar Lad wrote: > > > > > From: Manjunath Hadli <manjunath.hadli@ti.com> > > > > > > > > > > add new enum entries for supporting the media-bus formats on dm365. > > > > > These include some bayer and some non-bayer formats. > > > > > V4L2_MBUS_FMT_YDYUYDYV8_1X16 and V4L2_MBUS_FMT_UV8_1X8 are used > > > > > internal to the hardware by the resizer. > > > > > V4L2_MBUS_FMT_SBGGR10_ALAW8_1X8 represents the bayer ALAW format > > > > > that is supported by dm365 hardware. > > > > > > > > > > Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> > > > > > Acked-by: Hans Verkuil <hans.verkuil@cisco.com> > > > > > Signed-off-by: Manjunath Hadli <manjunath.hadli@ti.com> > > > > > Signed-off-by: Lad, Prabhakar <prabhakar.lad@ti.com> > > > > > Cc: Sakari Ailus <sakari.ailus@iki.fi> > > > > > Cc: Guennadi Liakhovetski <g.liakhovetski@gmx.de> > > > > > --- > > > > > > > > > > Documentation/DocBook/media/v4l/subdev-formats.xml | 250 > > > > > +++++++++++++++++++- include/linux/v4l2-mediabus.h > > > > > | 10 +- > > > > > 2 files changed, 252 insertions(+), 8 deletions(-) > > > > > > > > > > diff --git a/Documentation/DocBook/media/v4l/subdev-formats.xml > > > > > b/Documentation/DocBook/media/v4l/subdev-formats.xml index > > > > > 49c532e..75dc275 100644 > > > > > --- a/Documentation/DocBook/media/v4l/subdev-formats.xml > > > > > +++ b/Documentation/DocBook/media/v4l/subdev-formats.xml > > > > > @@ -353,9 +353,9 @@ > > > > > > > > > > <listitem><para>The number of bits per pixel component. All > > components > > > > > are > > > > > transferred on the same number of bits. Common values are 8, 10 and > > > > > 12.</para> </listitem> > > > > > > > > > > - <listitem><para>If the pixel components are DPCM-compressed, a > > mention > > > > > of the - DPCM compression and the number of bits per compressed pixel > > > > > component.</para> - </listitem> > > > > > + <listitem><para>The compression (optional). If the pixel components > > > > > are > > > > > + ALAW- or DPCM-compressed, a mention of the compression scheme and the > > > > > + number of bits per compressed pixel component.</para></listitem> > > > > > > > > > > <listitem><para>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.</para></listitem> > > > > > > > > > > @@ -504,6 +504,74 @@ > > > > > > > > > > <entry>r<subscript>1</subscript></entry> > > > > > <entry>r<subscript>0</subscript></entry> > > > > > > > > > > </row> > > > > > > > > > > + <row id="V4L2-MBUS-FMT-SBGGR10-ALAW8-1X8"> > > > > > + <entry>V4L2_MBUS_FMT_SBGGR10_ALAW8_1X8</entry> > > > > > + <entry>0x3015</entry> > > > > > + <entry></entry> > > > > > + <entry>-</entry> > > > > > + <entry>-</entry> > > > > > + <entry>-</entry> > > > > > + <entry>-</entry> > > > > > + <entry>b<subscript>7</subscript></entry> > > > > > + <entry>b<subscript>6</subscript></entry> > > > > > + <entry>b<subscript>5</subscript></entry> > > > > > + <entry>b<subscript>4</subscript></entry> > > > > > + <entry>b<subscript>3</subscript></entry> > > > > > + <entry>b<subscript>2</subscript></entry> > > > > > + <entry>b<subscript>1</subscript></entry> > > > > > + <entry>b<subscript>0</subscript></entry> > > > > > + </row> > > > > > + <row id="V4L2-MBUS-FMT-SGBRG10-ALAW8-1X8"> > > > > > + <entry>V4L2_MBUS_FMT_SGBRG10_ALAW8_1X8</entry> > > > > > + <entry>0x3016</entry> > > > > > + <entry></entry> > > > > > + <entry>-</entry> > > > > > + <entry>-</entry> > > > > > + <entry>-</entry> > > > > > + <entry>-</entry> > > > > > + <entry>g<subscript>7</subscript></entry> > > > > > + <entry>g<subscript>6</subscript></entry> > > > > > + <entry>g<subscript>5</subscript></entry> > > > > > + <entry>g<subscript>4</subscript></entry> > > > > > + <entry>g<subscript>3</subscript></entry> > > > > > + <entry>g<subscript>2</subscript></entry> > > > > > + <entry>g<subscript>1</subscript></entry> > > > > > + <entry>g<subscript>0</subscript></entry> > > > > > + </row> > > > > > + <row id="V4L2-MBUS-FMT-SGRBG10-ALAW8-1X8"> > > > > > + <entry>V4L2_MBUS_FMT_SGRBG10_ALAW8_1X8</entry> > > > > > + <entry>0x3017</entry> > > > > > + <entry></entry> > > > > > + <entry>-</entry> > > > > > + <entry>-</entry> > > > > > + <entry>-</entry> > > > > > + <entry>-</entry> > > > > > + <entry>g<subscript>7</subscript></entry> > > > > > + <entry>g<subscript>6</subscript></entry> > > > > > + <entry>g<subscript>5</subscript></entry> > > > > > + <entry>g<subscript>4</subscript></entry> > > > > > + <entry>g<subscript>3</subscript></entry> > > > > > + <entry>g<subscript>2</subscript></entry> > > > > > + <entry>g<subscript>1</subscript></entry> > > > > > + <entry>g<subscript>0</subscript></entry> > > > > > + </row> > > > > > + <row id="V4L2-MBUS-FMT-SRGGB10-ALAW8-1X8"> > > > > > + <entry>V4L2_MBUS_FMT_SRGGB10_ALAW8_1X8</entry> > > > > > + <entry>0x3018</entry> > > > > > + <entry></entry> > > > > > + <entry>-</entry> > > > > > + <entry>-</entry> > > > > > + <entry>-</entry> > > > > > + <entry>-</entry> > > > > > + <entry>r<subscript>7</subscript></entry> > > > > > + <entry>r<subscript>6</subscript></entry> > > > > > + <entry>r<subscript>5</subscript></entry> > > > > > + <entry>r<subscript>4</subscript></entry> > > > > > + <entry>r<subscript>3</subscript></entry> > > > > > + <entry>r<subscript>2</subscript></entry> > > > > > + <entry>r<subscript>1</subscript></entry> > > > > > + <entry>r<subscript>0</subscript></entry> > > > > > + </row> > > > > > > > > > > <row id="V4L2-MBUS-FMT-SBGGR10-DPCM8-1X8"> > > > > > > > > > > <entry>V4L2_MBUS_FMT_SBGGR10_DPCM8_1X8</entry> > > > > > <entry>0x300b</entry> > > > > > > > > > > @@ -853,10 +921,16 @@ > > > > > > > > > > <title>Packed YUV Formats</title> > > > > > > > > > > <para>Those data formats transfer pixel data as (possibly > > > > > downsampled) Y, U > > > > > > > > > > - and V components. The format code is made of the following > > > > > information. + and V components. Some formats include dummy bits > > > > > in some of their samples + and are collectively referred to as > > > > > "YDYC" (Y-Dummy-Y-Chroma) formats. + One cannot rely on the values > > > > > of these dummy bits as those are undefined. + </para> > > > > > + <para>The format code is made of the following information. > > > > > > > > > > <itemizedlist> > > > > > > > > > > <listitem><para>The Y, U and V components order code, as transferred > > > > > on the > > > > > > > > > > - bus. Possible values are YUYV, UYVY, YVYU and VYUY.</para></listitem> > > > > > + bus. Possible values are YUYV, UYVY, YVYU and VYUY for formats with > > no > > > > > + dummy bit, and YDYUYDYV, YDYVYDYU, YUYDYVYD and YVYDYUYD for YDYC > > > > > formats. + </para></listitem> > > > > > > > > > > <listitem><para>The number of bits per pixel component. All > > components > > > > > are > > > > > transferred on the same number of bits. Common values are 8, 10 and > > > > > 12.</para> </listitem> > > > > > > > > I dicussed dummy vs. padding (zeros) with Laurent and we concluded we > > > > should use zero padding instead. The difference is that when processing > > > > the pixels no extra operations are necessary to get rid of the dummy data > > > > when the dummy bits are actually zero --- which in practice always is the > > > > case. > > > > > > > > I'm not aware of hardware that would assign padding bits (in this very > > > > purpose) that are a part of writes the width of bus width something else > > > > than zeros. It wouldn't make much sense either. > > > > > > > > So I suggest that dummy is replaced by padding which is defined to be > > > > zero. > > > > > > > > The letter in the format name could be 'Z', for example. > > > > > > > > Hans: what do you think? > > > > > > Bad idea. First of all, some hardware or FPGA can insert different values > > > there. It's something that Cisco uses in some cases: it makes it easier to > > > identify the dummy values if they have a non-zero fixed value. One should use the pixel format field for that. Besides, dummy bits can be anything; the user shoudn't expect a particular fixed value. That'd make the application specific to that device. > > > Another reason for not doing this is when such formats are used to display > > > video: you don't want to force the software to fill in the dummy values > > > with a specific value for no good reason. That would only cost extra CPU > > > cycles. > > > > On the other hand, when you process data that includes dummy bits stored in > > memory, knowing that the dummy bits are zero can save a mask operation. > > > > I don't have a strong opinion whether we should use zero or dummy bits for > > media bus formats. For memory formats I'd be inclined to use zero bits (at > > least when capturing). > > And make a new pixel format if you have hardware that doesn't use zero? I think > it's overkill IMHO. Could be. But I've seen only zero being used. Applications that need to process raw bayer images optimally are often very hardware specific anyway, adding the assumption that the dummy bits are zero isn't a big deal. The same might not apply as universally to yuv colour space but on the other hand one extra and operation just won't take that much time either. I'm fine with defining the bits are dummy. I just wanted we make an informed decision on this, and as far as I see that's now been reached. Acked-by: Sakari Ailus <sakari.ailus@iki.fi> Kind regards, -- Sakari Ailus e-mail: sakari.ailus@iki.fi jabber/XMPP/Gmail: sailus@retiisi.org.uk ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH v7 1/2] media: add new mediabus format enums for dm365 2012-07-31 11:17 ` Sakari Ailus @ 2012-07-31 11:28 ` Hans Verkuil 2012-07-31 11:41 ` Sakari Ailus 0 siblings, 1 reply; 15+ messages in thread From: Hans Verkuil @ 2012-07-31 11:28 UTC (permalink / raw) To: Sakari Ailus Cc: Laurent Pinchart, davinci-linux-open-source, LMML, Guennadi Liakhovetski On Tue 31 July 2012 13:17:50 Sakari Ailus wrote: > Hi Hans and Laurent, > > On Mon, Jul 30, 2012 at 09:19:13PM +0200, Hans Verkuil wrote: > > On Mon July 30 2012 21:06:33 Laurent Pinchart wrote: > > > Hi Hans, > > > > > > On Monday 30 July 2012 20:36:36 Hans Verkuil wrote: > > > > On Sat July 28 2012 00:01:24 Sakari Ailus wrote: > > > > > On Fri, Jul 27, 2012 at 04:25:04PM +0530, Prabhakar Lad wrote: > > > > > > From: Manjunath Hadli <manjunath.hadli@ti.com> > > > > > > > > > > > > add new enum entries for supporting the media-bus formats on dm365. > > > > > > These include some bayer and some non-bayer formats. > > > > > > V4L2_MBUS_FMT_YDYUYDYV8_1X16 and V4L2_MBUS_FMT_UV8_1X8 are used > > > > > > internal to the hardware by the resizer. > > > > > > V4L2_MBUS_FMT_SBGGR10_ALAW8_1X8 represents the bayer ALAW format > > > > > > that is supported by dm365 hardware. > > > > > > > > > > > > Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> > > > > > > Acked-by: Hans Verkuil <hans.verkuil@cisco.com> > > > > > > Signed-off-by: Manjunath Hadli <manjunath.hadli@ti.com> > > > > > > Signed-off-by: Lad, Prabhakar <prabhakar.lad@ti.com> > > > > > > Cc: Sakari Ailus <sakari.ailus@iki.fi> > > > > > > Cc: Guennadi Liakhovetski <g.liakhovetski@gmx.de> > > > > > > --- > > > > > > > > > > > > Documentation/DocBook/media/v4l/subdev-formats.xml | 250 > > > > > > +++++++++++++++++++- include/linux/v4l2-mediabus.h > > > > > > | 10 +- > > > > > > 2 files changed, 252 insertions(+), 8 deletions(-) > > > > > > > > > > > > diff --git a/Documentation/DocBook/media/v4l/subdev-formats.xml > > > > > > b/Documentation/DocBook/media/v4l/subdev-formats.xml index > > > > > > 49c532e..75dc275 100644 > > > > > > --- a/Documentation/DocBook/media/v4l/subdev-formats.xml > > > > > > +++ b/Documentation/DocBook/media/v4l/subdev-formats.xml > > > > > > @@ -353,9 +353,9 @@ > > > > > > > > > > > > <listitem><para>The number of bits per pixel component. All > > > components > > > > > > are > > > > > > transferred on the same number of bits. Common values are 8, 10 and > > > > > > 12.</para> </listitem> > > > > > > > > > > > > - <listitem><para>If the pixel components are DPCM-compressed, a > > > mention > > > > > > of the - DPCM compression and the number of bits per compressed pixel > > > > > > component.</para> - </listitem> > > > > > > + <listitem><para>The compression (optional). If the pixel components > > > > > > are > > > > > > + ALAW- or DPCM-compressed, a mention of the compression scheme and the > > > > > > + number of bits per compressed pixel component.</para></listitem> > > > > > > > > > > > > <listitem><para>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.</para></listitem> > > > > > > > > > > > > @@ -504,6 +504,74 @@ > > > > > > > > > > > > <entry>r<subscript>1</subscript></entry> > > > > > > <entry>r<subscript>0</subscript></entry> > > > > > > > > > > > > </row> > > > > > > > > > > > > + <row id="V4L2-MBUS-FMT-SBGGR10-ALAW8-1X8"> > > > > > > + <entry>V4L2_MBUS_FMT_SBGGR10_ALAW8_1X8</entry> > > > > > > + <entry>0x3015</entry> > > > > > > + <entry></entry> > > > > > > + <entry>-</entry> > > > > > > + <entry>-</entry> > > > > > > + <entry>-</entry> > > > > > > + <entry>-</entry> > > > > > > + <entry>b<subscript>7</subscript></entry> > > > > > > + <entry>b<subscript>6</subscript></entry> > > > > > > + <entry>b<subscript>5</subscript></entry> > > > > > > + <entry>b<subscript>4</subscript></entry> > > > > > > + <entry>b<subscript>3</subscript></entry> > > > > > > + <entry>b<subscript>2</subscript></entry> > > > > > > + <entry>b<subscript>1</subscript></entry> > > > > > > + <entry>b<subscript>0</subscript></entry> > > > > > > + </row> > > > > > > + <row id="V4L2-MBUS-FMT-SGBRG10-ALAW8-1X8"> > > > > > > + <entry>V4L2_MBUS_FMT_SGBRG10_ALAW8_1X8</entry> > > > > > > + <entry>0x3016</entry> > > > > > > + <entry></entry> > > > > > > + <entry>-</entry> > > > > > > + <entry>-</entry> > > > > > > + <entry>-</entry> > > > > > > + <entry>-</entry> > > > > > > + <entry>g<subscript>7</subscript></entry> > > > > > > + <entry>g<subscript>6</subscript></entry> > > > > > > + <entry>g<subscript>5</subscript></entry> > > > > > > + <entry>g<subscript>4</subscript></entry> > > > > > > + <entry>g<subscript>3</subscript></entry> > > > > > > + <entry>g<subscript>2</subscript></entry> > > > > > > + <entry>g<subscript>1</subscript></entry> > > > > > > + <entry>g<subscript>0</subscript></entry> > > > > > > + </row> > > > > > > + <row id="V4L2-MBUS-FMT-SGRBG10-ALAW8-1X8"> > > > > > > + <entry>V4L2_MBUS_FMT_SGRBG10_ALAW8_1X8</entry> > > > > > > + <entry>0x3017</entry> > > > > > > + <entry></entry> > > > > > > + <entry>-</entry> > > > > > > + <entry>-</entry> > > > > > > + <entry>-</entry> > > > > > > + <entry>-</entry> > > > > > > + <entry>g<subscript>7</subscript></entry> > > > > > > + <entry>g<subscript>6</subscript></entry> > > > > > > + <entry>g<subscript>5</subscript></entry> > > > > > > + <entry>g<subscript>4</subscript></entry> > > > > > > + <entry>g<subscript>3</subscript></entry> > > > > > > + <entry>g<subscript>2</subscript></entry> > > > > > > + <entry>g<subscript>1</subscript></entry> > > > > > > + <entry>g<subscript>0</subscript></entry> > > > > > > + </row> > > > > > > + <row id="V4L2-MBUS-FMT-SRGGB10-ALAW8-1X8"> > > > > > > + <entry>V4L2_MBUS_FMT_SRGGB10_ALAW8_1X8</entry> > > > > > > + <entry>0x3018</entry> > > > > > > + <entry></entry> > > > > > > + <entry>-</entry> > > > > > > + <entry>-</entry> > > > > > > + <entry>-</entry> > > > > > > + <entry>-</entry> > > > > > > + <entry>r<subscript>7</subscript></entry> > > > > > > + <entry>r<subscript>6</subscript></entry> > > > > > > + <entry>r<subscript>5</subscript></entry> > > > > > > + <entry>r<subscript>4</subscript></entry> > > > > > > + <entry>r<subscript>3</subscript></entry> > > > > > > + <entry>r<subscript>2</subscript></entry> > > > > > > + <entry>r<subscript>1</subscript></entry> > > > > > > + <entry>r<subscript>0</subscript></entry> > > > > > > + </row> > > > > > > > > > > > > <row id="V4L2-MBUS-FMT-SBGGR10-DPCM8-1X8"> > > > > > > > > > > > > <entry>V4L2_MBUS_FMT_SBGGR10_DPCM8_1X8</entry> > > > > > > <entry>0x300b</entry> > > > > > > > > > > > > @@ -853,10 +921,16 @@ > > > > > > > > > > > > <title>Packed YUV Formats</title> > > > > > > > > > > > > <para>Those data formats transfer pixel data as (possibly > > > > > > downsampled) Y, U > > > > > > > > > > > > - and V components. The format code is made of the following > > > > > > information. + and V components. Some formats include dummy bits > > > > > > in some of their samples + and are collectively referred to as > > > > > > "YDYC" (Y-Dummy-Y-Chroma) formats. + One cannot rely on the values > > > > > > of these dummy bits as those are undefined. + </para> > > > > > > + <para>The format code is made of the following information. > > > > > > > > > > > > <itemizedlist> > > > > > > > > > > > > <listitem><para>The Y, U and V components order code, as transferred > > > > > > on the > > > > > > > > > > > > - bus. Possible values are YUYV, UYVY, YVYU and VYUY.</para></listitem> > > > > > > + bus. Possible values are YUYV, UYVY, YVYU and VYUY for formats with > > > no > > > > > > + dummy bit, and YDYUYDYV, YDYVYDYU, YUYDYVYD and YVYDYUYD for YDYC > > > > > > formats. + </para></listitem> > > > > > > > > > > > > <listitem><para>The number of bits per pixel component. All > > > components > > > > > > are > > > > > > transferred on the same number of bits. Common values are 8, 10 and > > > > > > 12.</para> </listitem> > > > > > > > > > > I dicussed dummy vs. padding (zeros) with Laurent and we concluded we > > > > > should use zero padding instead. The difference is that when processing > > > > > the pixels no extra operations are necessary to get rid of the dummy data > > > > > when the dummy bits are actually zero --- which in practice always is the > > > > > case. > > > > > > > > > > I'm not aware of hardware that would assign padding bits (in this very > > > > > purpose) that are a part of writes the width of bus width something else > > > > > than zeros. It wouldn't make much sense either. > > > > > > > > > > So I suggest that dummy is replaced by padding which is defined to be > > > > > zero. > > > > > > > > > > The letter in the format name could be 'Z', for example. > > > > > > > > > > Hans: what do you think? > > > > > > > > Bad idea. First of all, some hardware or FPGA can insert different values > > > > there. It's something that Cisco uses in some cases: it makes it easier to > > > > identify the dummy values if they have a non-zero fixed value. > > One should use the pixel format field for that. Besides, dummy bits can be > anything; the user shoudn't expect a particular fixed value. That'd make the > application specific to that device. It's used for debugging: by giving dummy fields a non-zero fixed value they are easy to identify when doing a memory dump. > > > > Another reason for not doing this is when such formats are used to display > > > > video: you don't want to force the software to fill in the dummy values > > > > with a specific value for no good reason. That would only cost extra CPU > > > > cycles. > > > > > > On the other hand, when you process data that includes dummy bits stored in > > > memory, knowing that the dummy bits are zero can save a mask operation. > > > > > > I don't have a strong opinion whether we should use zero or dummy bits for > > > media bus formats. For memory formats I'd be inclined to use zero bits (at > > > least when capturing). > > > > And make a new pixel format if you have hardware that doesn't use zero? I think > > it's overkill IMHO. > > Could be. But I've seen only zero being used. > > Applications that need to process raw bayer images optimally are often very > hardware specific anyway, adding the assumption that the dummy bits are zero > isn't a big deal. The same might not apply as universally to yuv colour > space but on the other hand one extra and operation just won't take that > much time either. My experience is with encoders and decoders. Anyway, we're not using this format, and neither will we ever upstream a pixel or mbus format since it is all highly specific to our products, so there is no point in upstreaming. So I am actually OK with saying that these bits should be 0, provided 'D' is replaced by 'Z'. But I still think keeping it 'D' and allowing for any value is more generic and I expect that it is sufficient. > I'm fine with defining the bits are dummy. I just wanted we make an informed > decision on this, and as far as I see that's now been reached. > > Acked-by: Sakari Ailus <sakari.ailus@iki.fi> OK, then we all agree to keep PATCHv7 as is? Regards, Hans > > Kind regards, > > ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH v7 1/2] media: add new mediabus format enums for dm365 2012-07-31 11:28 ` Hans Verkuil @ 2012-07-31 11:41 ` Sakari Ailus 0 siblings, 0 replies; 15+ messages in thread From: Sakari Ailus @ 2012-07-31 11:41 UTC (permalink / raw) To: Hans Verkuil Cc: Laurent Pinchart, davinci-linux-open-source, LMML, Guennadi Liakhovetski Hi Hans, Hans Verkuil wrote: > On Tue 31 July 2012 13:17:50 Sakari Ailus wrote: >> Hi Hans and Laurent, >> >> On Mon, Jul 30, 2012 at 09:19:13PM +0200, Hans Verkuil wrote: ... >>> And make a new pixel format if you have hardware that doesn't use zero? I think >>> it's overkill IMHO. >> >> Could be. But I've seen only zero being used. >> >> Applications that need to process raw bayer images optimally are often very >> hardware specific anyway, adding the assumption that the dummy bits are zero >> isn't a big deal. The same might not apply as universally to yuv colour >> space but on the other hand one extra and operation just won't take that >> much time either. > > My experience is with encoders and decoders. Anyway, we're not using this format, > and neither will we ever upstream a pixel or mbus format since it is all highly > specific to our products, so there is no point in upstreaming. So I am actually > OK with saying that these bits should be 0, provided 'D' is replaced by 'Z'. > > But I still think keeping it 'D' and allowing for any value is more generic > and I expect that it is sufficient. > >> I'm fine with defining the bits are dummy. I just wanted we make an informed >> decision on this, and as far as I see that's now been reached. >> >> Acked-by: Sakari Ailus <sakari.ailus@iki.fi> > > OK, then we all agree to keep PATCHv7 as is? Yes. If we later see that we need to use the format (I was thinking in-memory formats instead of media bus pixel codes, but apparently replied to this patch instead) to tell especially the unused bits are zero we can start creating more formats, but I feel it's unlikely we'd get there. Kind regards, -- Sakari Ailus sakari.ailus@iki.fi ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH v7 1/2] media: add new mediabus format enums for dm365 2012-07-30 19:06 ` Laurent Pinchart 2012-07-30 19:19 ` Hans Verkuil @ 2012-07-30 19:24 ` Sylwester Nawrocki 1 sibling, 0 replies; 15+ messages in thread From: Sylwester Nawrocki @ 2012-07-30 19:24 UTC (permalink / raw) To: Laurent Pinchart Cc: davinci-linux-open-source, Hans Verkuil, Sakari Ailus, LMML, Guennadi Liakhovetski Hi Laurent, On 07/30/2012 09:06 PM, Laurent Pinchart wrote: >>>> - bus. Possible values are YUYV, UYVY, YVYU and VYUY.</para></listitem> >>>> + bus. Possible values are YUYV, UYVY, YVYU and VYUY for formats with > no >>>> + dummy bit, and YDYUYDYV, YDYVYDYU, YUYDYVYD and YVYDYUYD for YDYC >>>> formats. + </para></listitem> >>>> >>>> <listitem><para>The number of bits per pixel component. All > components >>>> are >>>> transferred on the same number of bits. Common values are 8, 10 and >>>> 12.</para> </listitem> >>> >>> I dicussed dummy vs. padding (zeros) with Laurent and we concluded we >>> should use zero padding instead. The difference is that when processing >>> the pixels no extra operations are necessary to get rid of the dummy data >>> when the dummy bits are actually zero --- which in practice always is the >>> case. >>> >>> I'm not aware of hardware that would assign padding bits (in this very >>> purpose) that are a part of writes the width of bus width something else >>> than zeros. It wouldn't make much sense either. >>> >>> So I suggest that dummy is replaced by padding which is defined to be >>> zero. >>> >>> The letter in the format name could be 'Z', for example. >>> >>> Hans: what do you think? >> >> Bad idea. First of all, some hardware or FPGA can insert different values >> there. It's something that Cisco uses in some cases: it makes it easier to >> identify the dummy values if they have a non-zero fixed value. >> >> Another reason for not doing this is when such formats are used to display >> video: you don't want to force the software to fill in the dummy values >> with a specific value for no good reason. That would only cost extra CPU >> cycles. > > On the other hand, when you process data that includes dummy bits stored in > memory, knowing that the dummy bits are zero can save a mask operation. > > I don't have a strong opinion whether we should use zero or dummy bits for > media bus formats. For memory formats I'd be inclined to use zero bits (at > least when capturing). Perhaps it would make sense to assume those dummy bits have undefined value and add some other API for retrieving/setting them where possible, e.g. a v4l2 control ? It just feels like an unnecessary API limitation to assume those dummy bits are always zero. -- Regards, Sylwester ^ permalink raw reply [flat|nested] 15+ messages in thread
* [PATCH v7 2/2] v4l2: add new pixel formats supported on dm365 2012-07-27 10:55 [PATCH v7 0/2] add dm365 specific media formats Prabhakar Lad 2012-07-27 10:55 ` [PATCH v7 1/2] media: add new mediabus format enums for dm365 Prabhakar Lad @ 2012-07-27 10:55 ` Prabhakar Lad 2012-08-02 0:29 ` Sakari Ailus 2012-07-27 11:30 ` [PATCH v7 0/2] add dm365 specific media formats Laurent Pinchart 2 siblings, 1 reply; 15+ messages in thread From: Prabhakar Lad @ 2012-07-27 10:55 UTC (permalink / raw) To: LMML Cc: dlos, Manjunath Hadli, Lad, Prabhakar, Laurent Pinchart, Sakari Ailus, Hans Verkuil, Guennadi Liakhovetski From: Manjunath Hadli <manjunath.hadli@ti.com> add new macro V4L2_PIX_FMT_SGRBG10ALAW8 and associated formats to represent Bayer format frames compressed by A-LAW algorithm, add V4L2_PIX_FMT_UV8 to represent storage of CbCr data (UV interleaved) only. Signed-off-by: Manjunath Hadli <manjunath.hadli@ti.com> Signed-off-by: Lad, Prabhakar <prabhakar.lad@ti.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Sakari Ailus <sakari.ailus@iki.fi> Cc: Hans Verkuil <hans.verkuil@cisco.com> Cc: Guennadi Liakhovetski <g.liakhovetski@gmx.de> --- .../DocBook/media/v4l/pixfmt-srggb10alaw8.xml | 34 +++++++++++ Documentation/DocBook/media/v4l/pixfmt-uv8.xml | 62 ++++++++++++++++++++ Documentation/DocBook/media/v4l/pixfmt.xml | 2 + include/linux/videodev2.h | 8 +++ 4 files changed, 106 insertions(+), 0 deletions(-) create mode 100644 Documentation/DocBook/media/v4l/pixfmt-srggb10alaw8.xml create mode 100644 Documentation/DocBook/media/v4l/pixfmt-uv8.xml diff --git a/Documentation/DocBook/media/v4l/pixfmt-srggb10alaw8.xml b/Documentation/DocBook/media/v4l/pixfmt-srggb10alaw8.xml new file mode 100644 index 0000000..c934192 --- /dev/null +++ b/Documentation/DocBook/media/v4l/pixfmt-srggb10alaw8.xml @@ -0,0 +1,34 @@ + <refentry> + <refmeta> + <refentrytitle> + V4L2_PIX_FMT_SBGGR10ALAW8 ('aBA8'), + V4L2_PIX_FMT_SGBRG10ALAW8 ('aGA8'), + V4L2_PIX_FMT_SGRBG10ALAW8 ('agA8'), + V4L2_PIX_FMT_SRGGB10ALAW8 ('aRA8'), + </refentrytitle> + &manvol; + </refmeta> + <refnamediv> + <refname id="V4L2-PIX-FMT-SBGGR10ALAW8"> + <constant>V4L2_PIX_FMT_SBGGR10ALAW8</constant> + </refname> + <refname id="V4L2-PIX-FMT-SGBRG10ALAW8"> + <constant>V4L2_PIX_FMT_SGBRG10ALAW8</constant> + </refname> + <refname id="V4L2-PIX-FMT-SGRBG10ALAW8"> + <constant>V4L2_PIX_FMT_SGRBG10ALAW8</constant> + </refname> + <refname id="V4L2-PIX-FMT-SRGGB10ALAW8"> + <constant>V4L2_PIX_FMT_SRGGB10ALAW8</constant> + </refname> + <refpurpose>10-bit Bayer formats compressed to 8 bits</refpurpose> + </refnamediv> + <refsect1> + <title>Description</title> + <para>The following four pixel formats are raw sRGB / Bayer + formats with 10 bits per color compressed to 8 bits each, + using the A-LAW algorithm. Each color component consumes 8 + bits of memory. In other respects this format is similar to + <xref linkend="V4L2-PIX-FMT-SRGGB8">.</xref></para> + </refsect1> + </refentry> diff --git a/Documentation/DocBook/media/v4l/pixfmt-uv8.xml b/Documentation/DocBook/media/v4l/pixfmt-uv8.xml new file mode 100644 index 0000000..c507c1f --- /dev/null +++ b/Documentation/DocBook/media/v4l/pixfmt-uv8.xml @@ -0,0 +1,62 @@ + <refentry id="V4L2-PIX-FMT-UV8"> + <refmeta> + <refentrytitle>V4L2_PIX_FMT_UV8 ('UV8')</refentrytitle> + &manvol; + </refmeta> + <refnamediv> + <refname><constant>V4L2_PIX_FMT_UV8</constant></refname> + <refpurpose>UV plane interleaved</refpurpose> + </refnamediv> + <refsect1> + <title>Description</title> + <para>In this format there is no Y plane, Only CbCr plane. ie + (UV interleaved)</para> + <example> + <title> + <constant>V4L2_PIX_FMT_UV8</constant> + pixel image + </title> + + <formalpara> + <title>Byte Order.</title> + <para>Each cell is one byte. + <informaltable frame="none"> + <tgroup cols="5" align="center"> + <colspec align="left" colwidth="2*" /> + <tbody valign="top"> + <row> + <entry>start + 0:</entry> + <entry>Cb<subscript>00</subscript></entry> + <entry>Cr<subscript>00</subscript></entry> + <entry>Cb<subscript>01</subscript></entry> + <entry>Cr<subscript>01</subscript></entry> + </row> + <row> + <entry>start + 4:</entry> + <entry>Cb<subscript>10</subscript></entry> + <entry>Cr<subscript>10</subscript></entry> + <entry>Cb<subscript>11</subscript></entry> + <entry>Cr<subscript>11</subscript></entry> + </row> + <row> + <entry>start + 8:</entry> + <entry>Cb<subscript>20</subscript></entry> + <entry>Cr<subscript>20</subscript></entry> + <entry>Cb<subscript>21</subscript></entry> + <entry>Cr<subscript>21</subscript></entry> + </row> + <row> + <entry>start + 12:</entry> + <entry>Cb<subscript>30</subscript></entry> + <entry>Cr<subscript>30</subscript></entry> + <entry>Cb<subscript>31</subscript></entry> + <entry>Cr<subscript>31</subscript></entry> + </row> + </tbody> + </tgroup> + </informaltable> + </para> + </formalpara> + </example> + </refsect1> + </refentry> diff --git a/Documentation/DocBook/media/v4l/pixfmt.xml b/Documentation/DocBook/media/v4l/pixfmt.xml index e58934c..930f55d 100644 --- a/Documentation/DocBook/media/v4l/pixfmt.xml +++ b/Documentation/DocBook/media/v4l/pixfmt.xml @@ -673,6 +673,7 @@ access the palette, this must be done with ioctls of the Linux framebuffer API.< &sub-srggb8; &sub-sbggr16; &sub-srggb10; + &sub-srggb10alaw8; &sub-srggb10dpcm8; &sub-srggb12; </section> @@ -701,6 +702,7 @@ information.</para> &sub-y12; &sub-y10b; &sub-y16; + &sub-uv8; &sub-yuyv; &sub-uyvy; &sub-yvyu; diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h index 5d78910..2cdf2c1 100644 --- a/include/linux/videodev2.h +++ b/include/linux/videodev2.h @@ -329,6 +329,9 @@ struct v4l2_pix_format { /* Palette formats */ #define V4L2_PIX_FMT_PAL8 v4l2_fourcc('P', 'A', 'L', '8') /* 8 8-bit palette */ +/* Chrominance formats */ +#define V4L2_PIX_FMT_UV8 v4l2_fourcc('U', 'V', '8', ' ') /* 8 UV 4:4 */ + /* Luminance+Chrominance formats */ #define V4L2_PIX_FMT_YVU410 v4l2_fourcc('Y', 'V', 'U', '9') /* 9 YVU 4:1:0 */ #define V4L2_PIX_FMT_YVU420 v4l2_fourcc('Y', 'V', '1', '2') /* 12 YVU 4:2:0 */ @@ -378,6 +381,11 @@ struct v4l2_pix_format { #define V4L2_PIX_FMT_SGBRG12 v4l2_fourcc('G', 'B', '1', '2') /* 12 GBGB.. RGRG.. */ #define V4L2_PIX_FMT_SGRBG12 v4l2_fourcc('B', 'A', '1', '2') /* 12 GRGR.. BGBG.. */ #define V4L2_PIX_FMT_SRGGB12 v4l2_fourcc('R', 'G', '1', '2') /* 12 RGRG.. GBGB.. */ + /* 10bit raw bayer a-law compressed to 8 bits */ +#define V4L2_PIX_FMT_SBGGR10ALAW8 v4l2_fourcc('a', 'B', 'A', '8') +#define V4L2_PIX_FMT_SGBRG10ALAW8 v4l2_fourcc('a', 'G', 'A', '8') +#define V4L2_PIX_FMT_SGRBG10ALAW8 v4l2_fourcc('a', 'g', 'A', '8') +#define V4L2_PIX_FMT_SRGGB10ALAW8 v4l2_fourcc('a', 'R', 'A', '8') /* 10bit raw bayer DPCM compressed to 8 bits */ #define V4L2_PIX_FMT_SBGGR10DPCM8 v4l2_fourcc('b', 'B', 'A', '8') #define V4L2_PIX_FMT_SGBRG10DPCM8 v4l2_fourcc('b', 'G', 'A', '8') -- 1.7.0.4 ^ permalink raw reply related [flat|nested] 15+ messages in thread
* Re: [PATCH v7 2/2] v4l2: add new pixel formats supported on dm365 2012-07-27 10:55 ` [PATCH v7 2/2] v4l2: add new pixel formats supported on dm365 Prabhakar Lad @ 2012-08-02 0:29 ` Sakari Ailus 2012-08-02 6:49 ` Prabhakar Lad 0 siblings, 1 reply; 15+ messages in thread From: Sakari Ailus @ 2012-08-02 0:29 UTC (permalink / raw) To: Prabhakar Lad Cc: LMML, dlos, Manjunath Hadli, Laurent Pinchart, Hans Verkuil, Guennadi Liakhovetski Hi Prabhakar, Thanks for the patch. On Fri, Jul 27, 2012 at 04:25:05PM +0530, Prabhakar Lad wrote: > From: Manjunath Hadli <manjunath.hadli@ti.com> > > add new macro V4L2_PIX_FMT_SGRBG10ALAW8 and associated formats > to represent Bayer format frames compressed by A-LAW algorithm, > add V4L2_PIX_FMT_UV8 to represent storage of CbCr data (UV interleaved) > only. > > Signed-off-by: Manjunath Hadli <manjunath.hadli@ti.com> > Signed-off-by: Lad, Prabhakar <prabhakar.lad@ti.com> > Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> > Cc: Sakari Ailus <sakari.ailus@iki.fi> > Cc: Hans Verkuil <hans.verkuil@cisco.com> > Cc: Guennadi Liakhovetski <g.liakhovetski@gmx.de> > --- > .../DocBook/media/v4l/pixfmt-srggb10alaw8.xml | 34 +++++++++++ > Documentation/DocBook/media/v4l/pixfmt-uv8.xml | 62 ++++++++++++++++++++ > Documentation/DocBook/media/v4l/pixfmt.xml | 2 + > include/linux/videodev2.h | 8 +++ > 4 files changed, 106 insertions(+), 0 deletions(-) > create mode 100644 Documentation/DocBook/media/v4l/pixfmt-srggb10alaw8.xml > create mode 100644 Documentation/DocBook/media/v4l/pixfmt-uv8.xml > > diff --git a/Documentation/DocBook/media/v4l/pixfmt-srggb10alaw8.xml b/Documentation/DocBook/media/v4l/pixfmt-srggb10alaw8.xml > new file mode 100644 > index 0000000..c934192 > --- /dev/null > +++ b/Documentation/DocBook/media/v4l/pixfmt-srggb10alaw8.xml > @@ -0,0 +1,34 @@ > + <refentry> > + <refmeta> > + <refentrytitle> > + V4L2_PIX_FMT_SBGGR10ALAW8 ('aBA8'), > + V4L2_PIX_FMT_SGBRG10ALAW8 ('aGA8'), > + V4L2_PIX_FMT_SGRBG10ALAW8 ('agA8'), > + V4L2_PIX_FMT_SRGGB10ALAW8 ('aRA8'), > + </refentrytitle> > + &manvol; > + </refmeta> > + <refnamediv> > + <refname id="V4L2-PIX-FMT-SBGGR10ALAW8"> > + <constant>V4L2_PIX_FMT_SBGGR10ALAW8</constant> > + </refname> > + <refname id="V4L2-PIX-FMT-SGBRG10ALAW8"> > + <constant>V4L2_PIX_FMT_SGBRG10ALAW8</constant> > + </refname> > + <refname id="V4L2-PIX-FMT-SGRBG10ALAW8"> > + <constant>V4L2_PIX_FMT_SGRBG10ALAW8</constant> > + </refname> > + <refname id="V4L2-PIX-FMT-SRGGB10ALAW8"> > + <constant>V4L2_PIX_FMT_SRGGB10ALAW8</constant> > + </refname> > + <refpurpose>10-bit Bayer formats compressed to 8 bits</refpurpose> > + </refnamediv> > + <refsect1> > + <title>Description</title> > + <para>The following four pixel formats are raw sRGB / Bayer > + formats with 10 bits per color compressed to 8 bits each, > + using the A-LAW algorithm. Each color component consumes 8 > + bits of memory. In other respects this format is similar to > + <xref linkend="V4L2-PIX-FMT-SRGGB8">.</xref></para> > + </refsect1> > + </refentry> > diff --git a/Documentation/DocBook/media/v4l/pixfmt-uv8.xml b/Documentation/DocBook/media/v4l/pixfmt-uv8.xml > new file mode 100644 > index 0000000..c507c1f > --- /dev/null > +++ b/Documentation/DocBook/media/v4l/pixfmt-uv8.xml > @@ -0,0 +1,62 @@ > + <refentry id="V4L2-PIX-FMT-UV8"> > + <refmeta> > + <refentrytitle>V4L2_PIX_FMT_UV8 ('UV8')</refentrytitle> > + &manvol; > + </refmeta> > + <refnamediv> > + <refname><constant>V4L2_PIX_FMT_UV8</constant></refname> > + <refpurpose>UV plane interleaved</refpurpose> > + </refnamediv> > + <refsect1> > + <title>Description</title> > + <para>In this format there is no Y plane, Only CbCr plane. ie > + (UV interleaved)</para> > + <example> > + <title> > + <constant>V4L2_PIX_FMT_UV8</constant> > + pixel image > + </title> > + > + <formalpara> > + <title>Byte Order.</title> > + <para>Each cell is one byte. > + <informaltable frame="none"> > + <tgroup cols="5" align="center"> > + <colspec align="left" colwidth="2*" /> > + <tbody valign="top"> > + <row> > + <entry>start + 0:</entry> > + <entry>Cb<subscript>00</subscript></entry> > + <entry>Cr<subscript>00</subscript></entry> > + <entry>Cb<subscript>01</subscript></entry> > + <entry>Cr<subscript>01</subscript></entry> > + </row> > + <row> > + <entry>start + 4:</entry> > + <entry>Cb<subscript>10</subscript></entry> > + <entry>Cr<subscript>10</subscript></entry> > + <entry>Cb<subscript>11</subscript></entry> > + <entry>Cr<subscript>11</subscript></entry> > + </row> > + <row> > + <entry>start + 8:</entry> > + <entry>Cb<subscript>20</subscript></entry> > + <entry>Cr<subscript>20</subscript></entry> > + <entry>Cb<subscript>21</subscript></entry> > + <entry>Cr<subscript>21</subscript></entry> > + </row> > + <row> > + <entry>start + 12:</entry> > + <entry>Cb<subscript>30</subscript></entry> > + <entry>Cr<subscript>30</subscript></entry> > + <entry>Cb<subscript>31</subscript></entry> > + <entry>Cr<subscript>31</subscript></entry> > + </row> > + </tbody> > + </tgroup> > + </informaltable> > + </para> > + </formalpara> > + </example> > + </refsect1> > + </refentry> > diff --git a/Documentation/DocBook/media/v4l/pixfmt.xml b/Documentation/DocBook/media/v4l/pixfmt.xml > index e58934c..930f55d 100644 > --- a/Documentation/DocBook/media/v4l/pixfmt.xml > +++ b/Documentation/DocBook/media/v4l/pixfmt.xml > @@ -673,6 +673,7 @@ access the palette, this must be done with ioctls of the Linux framebuffer API.< > &sub-srggb8; > &sub-sbggr16; > &sub-srggb10; > + &sub-srggb10alaw8; > &sub-srggb10dpcm8; > &sub-srggb12; > </section> > @@ -701,6 +702,7 @@ information.</para> > &sub-y12; > &sub-y10b; > &sub-y16; > + &sub-uv8; > &sub-yuyv; > &sub-uyvy; > &sub-yvyu; > diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h > index 5d78910..2cdf2c1 100644 > --- a/include/linux/videodev2.h > +++ b/include/linux/videodev2.h > @@ -329,6 +329,9 @@ struct v4l2_pix_format { > /* Palette formats */ > #define V4L2_PIX_FMT_PAL8 v4l2_fourcc('P', 'A', 'L', '8') /* 8 8-bit palette */ > > +/* Chrominance formats */ > +#define V4L2_PIX_FMT_UV8 v4l2_fourcc('U', 'V', '8', ' ') /* 8 UV 4:4 */ Is that an extra space I see on the line above? :) Now that you're defining a new kind of a format, could you add a few lines about it to Documentation/video4linux/4CCs.txt, please? That may be a separate patch if you wish. > /* Luminance+Chrominance formats */ > #define V4L2_PIX_FMT_YVU410 v4l2_fourcc('Y', 'V', 'U', '9') /* 9 YVU 4:1:0 */ > #define V4L2_PIX_FMT_YVU420 v4l2_fourcc('Y', 'V', '1', '2') /* 12 YVU 4:2:0 */ > @@ -378,6 +381,11 @@ struct v4l2_pix_format { > #define V4L2_PIX_FMT_SGBRG12 v4l2_fourcc('G', 'B', '1', '2') /* 12 GBGB.. RGRG.. */ > #define V4L2_PIX_FMT_SGRBG12 v4l2_fourcc('B', 'A', '1', '2') /* 12 GRGR.. BGBG.. */ > #define V4L2_PIX_FMT_SRGGB12 v4l2_fourcc('R', 'G', '1', '2') /* 12 RGRG.. GBGB.. */ > + /* 10bit raw bayer a-law compressed to 8 bits */ > +#define V4L2_PIX_FMT_SBGGR10ALAW8 v4l2_fourcc('a', 'B', 'A', '8') > +#define V4L2_PIX_FMT_SGBRG10ALAW8 v4l2_fourcc('a', 'G', 'A', '8') > +#define V4L2_PIX_FMT_SGRBG10ALAW8 v4l2_fourcc('a', 'g', 'A', '8') > +#define V4L2_PIX_FMT_SRGGB10ALAW8 v4l2_fourcc('a', 'R', 'A', '8') > /* 10bit raw bayer DPCM compressed to 8 bits */ > #define V4L2_PIX_FMT_SBGGR10DPCM8 v4l2_fourcc('b', 'B', 'A', '8') > #define V4L2_PIX_FMT_SGBRG10DPCM8 v4l2_fourcc('b', 'G', 'A', '8') Kind regards, -- Sakari Ailus e-mail: sakari.ailus@iki.fi jabber/XMPP/Gmail: sailus@retiisi.org.uk ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH v7 2/2] v4l2: add new pixel formats supported on dm365 2012-08-02 0:29 ` Sakari Ailus @ 2012-08-02 6:49 ` Prabhakar Lad 0 siblings, 0 replies; 15+ messages in thread From: Prabhakar Lad @ 2012-08-02 6:49 UTC (permalink / raw) To: Sakari Ailus Cc: LMML, dlos, Manjunath Hadli, Laurent Pinchart, Hans Verkuil, Guennadi Liakhovetski Hi Sakari, Thanks for the review. On Thursday 02 August 2012 05:59 AM, Sakari Ailus wrote: > Hi Prabhakar, > > Thanks for the patch. > > On Fri, Jul 27, 2012 at 04:25:05PM +0530, Prabhakar Lad wrote: >> From: Manjunath Hadli <manjunath.hadli@ti.com> >> >> add new macro V4L2_PIX_FMT_SGRBG10ALAW8 and associated formats >> to represent Bayer format frames compressed by A-LAW algorithm, >> add V4L2_PIX_FMT_UV8 to represent storage of CbCr data (UV interleaved) >> only. >> >> Signed-off-by: Manjunath Hadli <manjunath.hadli@ti.com> >> Signed-off-by: Lad, Prabhakar <prabhakar.lad@ti.com> >> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> >> Cc: Sakari Ailus <sakari.ailus@iki.fi> >> Cc: Hans Verkuil <hans.verkuil@cisco.com> >> Cc: Guennadi Liakhovetski <g.liakhovetski@gmx.de> >> --- >> .../DocBook/media/v4l/pixfmt-srggb10alaw8.xml | 34 +++++++++++ >> Documentation/DocBook/media/v4l/pixfmt-uv8.xml | 62 ++++++++++++++++++++ >> Documentation/DocBook/media/v4l/pixfmt.xml | 2 + >> include/linux/videodev2.h | 8 +++ >> 4 files changed, 106 insertions(+), 0 deletions(-) >> create mode 100644 Documentation/DocBook/media/v4l/pixfmt-srggb10alaw8.xml >> create mode 100644 Documentation/DocBook/media/v4l/pixfmt-uv8.xml >> >> diff --git a/Documentation/DocBook/media/v4l/pixfmt-srggb10alaw8.xml b/Documentation/DocBook/media/v4l/pixfmt-srggb10alaw8.xml >> new file mode 100644 >> index 0000000..c934192 >> --- /dev/null >> +++ b/Documentation/DocBook/media/v4l/pixfmt-srggb10alaw8.xml >> @@ -0,0 +1,34 @@ >> + <refentry> >> + <refmeta> >> + <refentrytitle> >> + V4L2_PIX_FMT_SBGGR10ALAW8 ('aBA8'), >> + V4L2_PIX_FMT_SGBRG10ALAW8 ('aGA8'), >> + V4L2_PIX_FMT_SGRBG10ALAW8 ('agA8'), >> + V4L2_PIX_FMT_SRGGB10ALAW8 ('aRA8'), >> + </refentrytitle> >> + &manvol; >> + </refmeta> >> + <refnamediv> >> + <refname id="V4L2-PIX-FMT-SBGGR10ALAW8"> >> + <constant>V4L2_PIX_FMT_SBGGR10ALAW8</constant> >> + </refname> >> + <refname id="V4L2-PIX-FMT-SGBRG10ALAW8"> >> + <constant>V4L2_PIX_FMT_SGBRG10ALAW8</constant> >> + </refname> >> + <refname id="V4L2-PIX-FMT-SGRBG10ALAW8"> >> + <constant>V4L2_PIX_FMT_SGRBG10ALAW8</constant> >> + </refname> >> + <refname id="V4L2-PIX-FMT-SRGGB10ALAW8"> >> + <constant>V4L2_PIX_FMT_SRGGB10ALAW8</constant> >> + </refname> >> + <refpurpose>10-bit Bayer formats compressed to 8 bits</refpurpose> >> + </refnamediv> >> + <refsect1> >> + <title>Description</title> >> + <para>The following four pixel formats are raw sRGB / Bayer >> + formats with 10 bits per color compressed to 8 bits each, >> + using the A-LAW algorithm. Each color component consumes 8 >> + bits of memory. In other respects this format is similar to >> + <xref linkend="V4L2-PIX-FMT-SRGGB8">.</xref></para> >> + </refsect1> >> + </refentry> >> diff --git a/Documentation/DocBook/media/v4l/pixfmt-uv8.xml b/Documentation/DocBook/media/v4l/pixfmt-uv8.xml >> new file mode 100644 >> index 0000000..c507c1f >> --- /dev/null >> +++ b/Documentation/DocBook/media/v4l/pixfmt-uv8.xml >> @@ -0,0 +1,62 @@ >> + <refentry id="V4L2-PIX-FMT-UV8"> >> + <refmeta> >> + <refentrytitle>V4L2_PIX_FMT_UV8 ('UV8')</refentrytitle> >> + &manvol; >> + </refmeta> >> + <refnamediv> >> + <refname><constant>V4L2_PIX_FMT_UV8</constant></refname> >> + <refpurpose>UV plane interleaved</refpurpose> >> + </refnamediv> >> + <refsect1> >> + <title>Description</title> >> + <para>In this format there is no Y plane, Only CbCr plane. ie >> + (UV interleaved)</para> >> + <example> >> + <title> >> + <constant>V4L2_PIX_FMT_UV8</constant> >> + pixel image >> + </title> >> + >> + <formalpara> >> + <title>Byte Order.</title> >> + <para>Each cell is one byte. >> + <informaltable frame="none"> >> + <tgroup cols="5" align="center"> >> + <colspec align="left" colwidth="2*" /> >> + <tbody valign="top"> >> + <row> >> + <entry>start + 0:</entry> >> + <entry>Cb<subscript>00</subscript></entry> >> + <entry>Cr<subscript>00</subscript></entry> >> + <entry>Cb<subscript>01</subscript></entry> >> + <entry>Cr<subscript>01</subscript></entry> >> + </row> >> + <row> >> + <entry>start + 4:</entry> >> + <entry>Cb<subscript>10</subscript></entry> >> + <entry>Cr<subscript>10</subscript></entry> >> + <entry>Cb<subscript>11</subscript></entry> >> + <entry>Cr<subscript>11</subscript></entry> >> + </row> >> + <row> >> + <entry>start + 8:</entry> >> + <entry>Cb<subscript>20</subscript></entry> >> + <entry>Cr<subscript>20</subscript></entry> >> + <entry>Cb<subscript>21</subscript></entry> >> + <entry>Cr<subscript>21</subscript></entry> >> + </row> >> + <row> >> + <entry>start + 12:</entry> >> + <entry>Cb<subscript>30</subscript></entry> >> + <entry>Cr<subscript>30</subscript></entry> >> + <entry>Cb<subscript>31</subscript></entry> >> + <entry>Cr<subscript>31</subscript></entry> >> + </row> >> + </tbody> >> + </tgroup> >> + </informaltable> >> + </para> >> + </formalpara> >> + </example> >> + </refsect1> >> + </refentry> >> diff --git a/Documentation/DocBook/media/v4l/pixfmt.xml b/Documentation/DocBook/media/v4l/pixfmt.xml >> index e58934c..930f55d 100644 >> --- a/Documentation/DocBook/media/v4l/pixfmt.xml >> +++ b/Documentation/DocBook/media/v4l/pixfmt.xml >> @@ -673,6 +673,7 @@ access the palette, this must be done with ioctls of the Linux framebuffer API.< >> &sub-srggb8; >> &sub-sbggr16; >> &sub-srggb10; >> + &sub-srggb10alaw8; >> &sub-srggb10dpcm8; >> &sub-srggb12; >> </section> >> @@ -701,6 +702,7 @@ information.</para> >> &sub-y12; >> &sub-y10b; >> &sub-y16; >> + &sub-uv8; >> &sub-yuyv; >> &sub-uyvy; >> &sub-yvyu; >> diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h >> index 5d78910..2cdf2c1 100644 >> --- a/include/linux/videodev2.h >> +++ b/include/linux/videodev2.h >> @@ -329,6 +329,9 @@ struct v4l2_pix_format { >> /* Palette formats */ >> #define V4L2_PIX_FMT_PAL8 v4l2_fourcc('P', 'A', 'L', '8') /* 8 8-bit palette */ >> >> +/* Chrominance formats */ >> +#define V4L2_PIX_FMT_UV8 v4l2_fourcc('U', 'V', '8', ' ') /* 8 UV 4:4 */ > > Is that an extra space I see on the line above? :) > Uhh missed it , I'll fix that for v8. With that fix can I add your Ack? > Now that you're defining a new kind of a format, could you add a few lines > about it to Documentation/video4linux/4CCs.txt, please? That may be a > separate patch if you wish. > Yes sure, we will keep it as a separate patch. I need suggestion for this (Hans, Laurent, Guennadi your views please). Thx, --Prabhakar Lad >> /* Luminance+Chrominance formats */ >> #define V4L2_PIX_FMT_YVU410 v4l2_fourcc('Y', 'V', 'U', '9') /* 9 YVU 4:1:0 */ >> #define V4L2_PIX_FMT_YVU420 v4l2_fourcc('Y', 'V', '1', '2') /* 12 YVU 4:2:0 */ >> @@ -378,6 +381,11 @@ struct v4l2_pix_format { >> #define V4L2_PIX_FMT_SGBRG12 v4l2_fourcc('G', 'B', '1', '2') /* 12 GBGB.. RGRG.. */ >> #define V4L2_PIX_FMT_SGRBG12 v4l2_fourcc('B', 'A', '1', '2') /* 12 GRGR.. BGBG.. */ >> #define V4L2_PIX_FMT_SRGGB12 v4l2_fourcc('R', 'G', '1', '2') /* 12 RGRG.. GBGB.. */ >> + /* 10bit raw bayer a-law compressed to 8 bits */ >> +#define V4L2_PIX_FMT_SBGGR10ALAW8 v4l2_fourcc('a', 'B', 'A', '8') >> +#define V4L2_PIX_FMT_SGBRG10ALAW8 v4l2_fourcc('a', 'G', 'A', '8') >> +#define V4L2_PIX_FMT_SGRBG10ALAW8 v4l2_fourcc('a', 'g', 'A', '8') >> +#define V4L2_PIX_FMT_SRGGB10ALAW8 v4l2_fourcc('a', 'R', 'A', '8') >> /* 10bit raw bayer DPCM compressed to 8 bits */ >> #define V4L2_PIX_FMT_SBGGR10DPCM8 v4l2_fourcc('b', 'B', 'A', '8') >> #define V4L2_PIX_FMT_SGBRG10DPCM8 v4l2_fourcc('b', 'G', 'A', '8') > > Kind regards, > ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH v7 0/2] add dm365 specific media formats 2012-07-27 10:55 [PATCH v7 0/2] add dm365 specific media formats Prabhakar Lad 2012-07-27 10:55 ` [PATCH v7 1/2] media: add new mediabus format enums for dm365 Prabhakar Lad 2012-07-27 10:55 ` [PATCH v7 2/2] v4l2: add new pixel formats supported on dm365 Prabhakar Lad @ 2012-07-27 11:30 ` Laurent Pinchart 2012-07-27 11:41 ` Laurent Pinchart 2 siblings, 1 reply; 15+ messages in thread From: Laurent Pinchart @ 2012-07-27 11:30 UTC (permalink / raw) To: davinci-linux-open-source; +Cc: Prabhakar Lad, LMML On Friday 27 July 2012 16:25:03 Prabhakar Lad wrote: > add mediabus formats and pixel formats supported > as part of dm365 vpfe device. > The device supports media formats(transfer and storage) > which include- > 1: ALAW compressed bayer. > 2: UV interleaved without Y (for resizer). > 3: YDYU Acked-by: Prabhakar Lad <prabhakar.lad@ti.com> -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH v7 0/2] add dm365 specific media formats 2012-07-27 11:30 ` [PATCH v7 0/2] add dm365 specific media formats Laurent Pinchart @ 2012-07-27 11:41 ` Laurent Pinchart 0 siblings, 0 replies; 15+ messages in thread From: Laurent Pinchart @ 2012-07-27 11:41 UTC (permalink / raw) To: davinci-linux-open-source; +Cc: Prabhakar Lad, LMML On Friday 27 July 2012 13:30:15 Laurent Pinchart wrote: > On Friday 27 July 2012 16:25:03 Prabhakar Lad wrote: > > add mediabus formats and pixel formats supported > > as part of dm365 vpfe device. > > The device supports media formats(transfer and storage) > > which include- > > 1: ALAW compressed bayer. > > 2: UV interleaved without Y (for resizer). > > 3: YDYU > > Acked-by: Prabhakar Lad <prabhakar.lad@ti.com> This is obviously a bad copy & paste. Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2012-08-02 6:50 UTC | newest] Thread overview: 15+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-07-27 10:55 [PATCH v7 0/2] add dm365 specific media formats Prabhakar Lad 2012-07-27 10:55 ` [PATCH v7 1/2] media: add new mediabus format enums for dm365 Prabhakar Lad 2012-07-27 22:01 ` Sakari Ailus 2012-07-30 18:36 ` Hans Verkuil 2012-07-30 19:06 ` Laurent Pinchart 2012-07-30 19:19 ` Hans Verkuil 2012-07-31 11:17 ` Sakari Ailus 2012-07-31 11:28 ` Hans Verkuil 2012-07-31 11:41 ` Sakari Ailus 2012-07-30 19:24 ` Sylwester Nawrocki 2012-07-27 10:55 ` [PATCH v7 2/2] v4l2: add new pixel formats supported on dm365 Prabhakar Lad 2012-08-02 0:29 ` Sakari Ailus 2012-08-02 6:49 ` Prabhakar Lad 2012-07-27 11:30 ` [PATCH v7 0/2] add dm365 specific media formats Laurent Pinchart 2012-07-27 11:41 ` Laurent Pinchart
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).