[PATCH 0/2] add dm365 specific media formats

[PATCH 0/2] add dm365 specific media formats

[Manjunath Hadli]

add mediabus formats and pixel formats suported 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. NV12

Manjunath Hadli (2):
  media: add new mediabus format enums for dm365
  v4l2: add new pixel formats supported on dm365

 include/linux/v4l2-mediabus.h |   10 ++++++++--
 include/linux/videodev2.h     |    6 ++++++
 2 files changed, 14 insertions(+), 2 deletions(-)

[PATCH 1/2] media: add new mediabus format enums for dm365

[Manjunath Hadli]

add new enum entry V4L2_MBUS_FMT_SGRBG10_ALAW8_1X8 into mbus_pixel_code
to represent A-LAW compressed Bayer format. This corresponds to pixel
format - V4L2_PIX_FMT_SGRBG10ALAW8.
add UV8 and NV12 ( Y and C separate with UV interleaved) which are supported
on dm365.

Signed-off-by: Manjunath Hadli <manjunath.hadli@ti.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
 include/linux/v4l2-mediabus.h |   10 ++++++++--
 1 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/include/linux/v4l2-mediabus.h b/include/linux/v4l2-mediabus.h
index 5ea7f75..d408654 100644
--- a/include/linux/v4l2-mediabus.h
+++ b/include/linux/v4l2-mediabus.h
@@ -47,7 +47,7 @@ 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_UYVY8_1_5X8 = 0x2002,
 	V4L2_MBUS_FMT_VYUY8_1_5X8 = 0x2003,
@@ -67,8 +67,10 @@ enum v4l2_mbus_pixelcode {
 	V4L2_MBUS_FMT_YVYU8_1X16 = 0x2012,
 	V4L2_MBUS_FMT_YUYV10_1X20 = 0x200d,
 	V4L2_MBUS_FMT_YVYU10_1X20 = 0x200e,
+	V4L2_MBUS_FMT_NV12_1X20 = 0x2014,
+	V4L2_MBUS_FMT_UV8_1X8 = 0x2015,
 
-	/* 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,
@@ -89,6 +91,10 @@ enum v4l2_mbus_pixelcode {
 	V4L2_MBUS_FMT_SGBRG12_1X12 = 0x3010,
 	V4L2_MBUS_FMT_SGRBG12_1X12 = 0x3011,
 	V4L2_MBUS_FMT_SRGGB12_1X12 = 0x3012,
+	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,
 
 	/* JPEG compressed formats - next is 0x4002 */
 	V4L2_MBUS_FMT_JPEG_1X8 = 0x4001,
-- 
1.6.2.4

Re: [PATCH 1/2] media: add new mediabus format enums for dm365

[Laurent Pinchart]

Hi Manhunath,

Thanks for the patch.

On Thursday 15 December 2011 13:24:57 Manjunath Hadli wrote:
> add new enum entry V4L2_MBUS_FMT_SGRBG10_ALAW8_1X8 into mbus_pixel_code
> to represent A-LAW compressed Bayer format. This corresponds to pixel
> format - V4L2_PIX_FMT_SGRBG10ALAW8.
> add UV8 and NV12 ( Y and C separate with UV interleaved) which are
> supported on dm365.
> 
> Signed-off-by: Manjunath Hadli <manjunath.hadli@ti.com>
> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
>  include/linux/v4l2-mediabus.h |   10 ++++++++--
>  1 files changed, 8 insertions(+), 2 deletions(-)

Please also update the documentation in Documentation/DocBook/media/v4l.

> diff --git a/include/linux/v4l2-mediabus.h b/include/linux/v4l2-mediabus.h
> index 5ea7f75..d408654 100644
> --- a/include/linux/v4l2-mediabus.h
> +++ b/include/linux/v4l2-mediabus.h
> @@ -47,7 +47,7 @@ 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_UYVY8_1_5X8 = 0x2002,
>  	V4L2_MBUS_FMT_VYUY8_1_5X8 = 0x2003,
> @@ -67,8 +67,10 @@ enum v4l2_mbus_pixelcode {
>  	V4L2_MBUS_FMT_YVYU8_1X16 = 0x2012,
>  	V4L2_MBUS_FMT_YUYV10_1X20 = 0x200d,
>  	V4L2_MBUS_FMT_YVYU10_1X20 = 0x200e,
> +	V4L2_MBUS_FMT_NV12_1X20 = 0x2014,
> +	V4L2_MBUS_FMT_UV8_1X8 = 0x2015,

NV12, on the bus ? How does that work ? (The documentation should answer my 
question :-))

> -	/* 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,
> @@ -89,6 +91,10 @@ enum v4l2_mbus_pixelcode {
>  	V4L2_MBUS_FMT_SGBRG12_1X12 = 0x3010,
>  	V4L2_MBUS_FMT_SGRBG12_1X12 = 0x3011,
>  	V4L2_MBUS_FMT_SRGGB12_1X12 = 0x3012,
> +	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,

Please keep the names sorted as described in the comment at the beginning of 
the file.

> 
>  	/* JPEG compressed formats - next is 0x4002 */
>  	V4L2_MBUS_FMT_JPEG_1X8 = 0x4001,

-- 
Regards,

Laurent Pinchart

RE: [PATCH 1/2] media: add new mediabus format enums for dm365

[Hadli, Manjunath]

Laurent,
 Thank you for the comments.
On Thu, Dec 15, 2011 at 18:32:44, Laurent Pinchart wrote:
> Hi Manhunath,
> 
> Thanks for the patch.
> 
> On Thursday 15 December 2011 13:24:57 Manjunath Hadli wrote:
> > add new enum entry V4L2_MBUS_FMT_SGRBG10_ALAW8_1X8 into 
> > mbus_pixel_code to represent A-LAW compressed Bayer format. This 
> > corresponds to pixel format - V4L2_PIX_FMT_SGRBG10ALAW8.
> > add UV8 and NV12 ( Y and C separate with UV interleaved) which are 
> > supported on dm365.
> > 
> > Signed-off-by: Manjunath Hadli <manjunath.hadli@ti.com>
> > Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> > ---
> >  include/linux/v4l2-mediabus.h |   10 ++++++++--
> >  1 files changed, 8 insertions(+), 2 deletions(-)
> 
> Please also update the documentation in Documentation/DocBook/media/v4l.
> 
> > diff --git a/include/linux/v4l2-mediabus.h 
> > b/include/linux/v4l2-mediabus.h index 5ea7f75..d408654 100644
> > --- a/include/linux/v4l2-mediabus.h
> > +++ b/include/linux/v4l2-mediabus.h
> > @@ -47,7 +47,7 @@ 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_UYVY8_1_5X8 = 0x2002,
> >  	V4L2_MBUS_FMT_VYUY8_1_5X8 = 0x2003,
> > @@ -67,8 +67,10 @@ enum v4l2_mbus_pixelcode {
> >  	V4L2_MBUS_FMT_YVYU8_1X16 = 0x2012,
> >  	V4L2_MBUS_FMT_YUYV10_1X20 = 0x200d,
> >  	V4L2_MBUS_FMT_YVYU10_1X20 = 0x200e,
> > +	V4L2_MBUS_FMT_NV12_1X20 = 0x2014,
> > +	V4L2_MBUS_FMT_UV8_1X8 = 0x2015,
> 
> NV12, on the bus ? How does that work ? (The documentation should answer my question :-))
Well, this is on the internal bus not exposed outside, but nevertheless bus
between two subdevs or two independent hardware blocks. For example Resizer supports NV12 on its pad. Is there any other way to treat this? 

Thx,
-Manju
> 
> > -	/* 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,
> > @@ -89,6 +91,10 @@ enum v4l2_mbus_pixelcode {
> >  	V4L2_MBUS_FMT_SGBRG12_1X12 = 0x3010,
> >  	V4L2_MBUS_FMT_SGRBG12_1X12 = 0x3011,
> >  	V4L2_MBUS_FMT_SRGGB12_1X12 = 0x3012,
> > +	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,
> 
> Please keep the names sorted as described in the comment at the beginning of the file.
> 
> > 
> >  	/* JPEG compressed formats - next is 0x4002 */
> >  	V4L2_MBUS_FMT_JPEG_1X8 = 0x4001,
> 
> --
> Regards,
> 
> Laurent Pinchart
> 

Re: [PATCH 1/2] media: add new mediabus format enums for dm365

[Laurent Pinchart]

Hi Manju,

On Friday 16 December 2011 15:20:24 Hadli, Manjunath wrote:
> On Thu, Dec 15, 2011 at 18:32:44, Laurent Pinchart wrote:
> > On Thursday 15 December 2011 13:24:57 Manjunath Hadli wrote:
> > > add new enum entry V4L2_MBUS_FMT_SGRBG10_ALAW8_1X8 into
> > > mbus_pixel_code to represent A-LAW compressed Bayer format. This
> > > corresponds to pixel format - V4L2_PIX_FMT_SGRBG10ALAW8.
> > > add UV8 and NV12 ( Y and C separate with UV interleaved) which are
> > > supported on dm365.
> > > 
> > > Signed-off-by: Manjunath Hadli <manjunath.hadli@ti.com>
> > > Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> > > ---
> > > 
> > >  include/linux/v4l2-mediabus.h |   10 ++++++++--
> > >  1 files changed, 8 insertions(+), 2 deletions(-)
> > 
> > Please also update the documentation in Documentation/DocBook/media/v4l.
> > 
> > > diff --git a/include/linux/v4l2-mediabus.h
> > > b/include/linux/v4l2-mediabus.h index 5ea7f75..d408654 100644
> > > --- a/include/linux/v4l2-mediabus.h
> > > +++ b/include/linux/v4l2-mediabus.h
> > > @@ -47,7 +47,7 @@ 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_UYVY8_1_5X8 = 0x2002,
> > >  	V4L2_MBUS_FMT_VYUY8_1_5X8 = 0x2003,
> > > 
> > > @@ -67,8 +67,10 @@ enum v4l2_mbus_pixelcode {
> > > 
> > >  	V4L2_MBUS_FMT_YVYU8_1X16 = 0x2012,
> > >  	V4L2_MBUS_FMT_YUYV10_1X20 = 0x200d,
> > >  	V4L2_MBUS_FMT_YVYU10_1X20 = 0x200e,
> > > 
> > > +	V4L2_MBUS_FMT_NV12_1X20 = 0x2014,
> > > +	V4L2_MBUS_FMT_UV8_1X8 = 0x2015,
> > 
> > NV12, on the bus ? How does that work ? (The documentation should answer
> > my question :-))
> 
> Well, this is on the internal bus not exposed outside, but nevertheless bus
> between two subdevs or two independent hardware blocks. For example Resizer
> supports NV12 on its pad. Is there any other way to treat this?

How is NV12 transferred on the bus in that case ? Are all luma samples 
transferred first, followed by all chroma samples ?

> > > -	/* 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,
> > > 
> > > @@ -89,6 +91,10 @@ enum v4l2_mbus_pixelcode {
> > > 
> > >  	V4L2_MBUS_FMT_SGBRG12_1X12 = 0x3010,
> > >  	V4L2_MBUS_FMT_SGRBG12_1X12 = 0x3011,
> > >  	V4L2_MBUS_FMT_SRGGB12_1X12 = 0x3012,
> > > 
> > > +	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,
> > 
> > Please keep the names sorted as described in the comment at the beginning
> > of the file.
> > 
> > >  	/* JPEG compressed formats - next is 0x4002 */
> > >  	V4L2_MBUS_FMT_JPEG_1X8 = 0x4001,

-- 
Regards,

Laurent Pinchart

RE: [PATCH 1/2] media: add new mediabus format enums for dm365

[Hadli, Manjunath]

Laurent,
On Wed, Dec 21, 2011 at 05:28:31, Laurent Pinchart wrote:
> Hi Manju,
> 
> On Friday 16 December 2011 15:20:24 Hadli, Manjunath wrote:
> > On Thu, Dec 15, 2011 at 18:32:44, Laurent Pinchart wrote:
> > > On Thursday 15 December 2011 13:24:57 Manjunath Hadli wrote:
> > > > add new enum entry V4L2_MBUS_FMT_SGRBG10_ALAW8_1X8 into 
> > > > mbus_pixel_code to represent A-LAW compressed Bayer format. This 
> > > > corresponds to pixel format - V4L2_PIX_FMT_SGRBG10ALAW8.
> > > > add UV8 and NV12 ( Y and C separate with UV interleaved) which are 
> > > > supported on dm365.
> > > > 
> > > > Signed-off-by: Manjunath Hadli <manjunath.hadli@ti.com>
> > > > Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> > > > ---
> > > > 
> > > >  include/linux/v4l2-mediabus.h |   10 ++++++++--
> > > >  1 files changed, 8 insertions(+), 2 deletions(-)
> > > 
> > > Please also update the documentation in Documentation/DocBook/media/v4l.
> > > 
> > > > diff --git a/include/linux/v4l2-mediabus.h 
> > > > b/include/linux/v4l2-mediabus.h index 5ea7f75..d408654 100644
> > > > --- a/include/linux/v4l2-mediabus.h
> > > > +++ b/include/linux/v4l2-mediabus.h
> > > > @@ -47,7 +47,7 @@ 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_UYVY8_1_5X8 = 0x2002,
> > > >  	V4L2_MBUS_FMT_VYUY8_1_5X8 = 0x2003,
> > > > 
> > > > @@ -67,8 +67,10 @@ enum v4l2_mbus_pixelcode {
> > > > 
> > > >  	V4L2_MBUS_FMT_YVYU8_1X16 = 0x2012,
> > > >  	V4L2_MBUS_FMT_YUYV10_1X20 = 0x200d,
> > > >  	V4L2_MBUS_FMT_YVYU10_1X20 = 0x200e,
> > > > 
> > > > +	V4L2_MBUS_FMT_NV12_1X20 = 0x2014,
> > > > +	V4L2_MBUS_FMT_UV8_1X8 = 0x2015,
> > > 
> > > NV12, on the bus ? How does that work ? (The documentation should 
> > > answer my question :-))
> > 
> > Well, this is on the internal bus not exposed outside, but 
> > nevertheless bus between two subdevs or two independent hardware 
> > blocks. For example Resizer supports NV12 on its pad. Is there any other way to treat this?
> 
> How is NV12 transferred on the bus in that case ? Are all luma samples transferred first, followed by all chroma samples ?
It uses parallel bus of 16 bits, where Y and C are transmitted simultaneously on 8 bits each. NV12 uses a dummy C byte for every
valid one.
So I guess we call it V4L2_MBUS_FMT_YDYC_1X16 or V4L2_MBUS_FMT_YCYD_1X16?
That way we will be able to document the format in the documentation also.

Thx,
-Manju
> 
> > > > -	/* 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,
> > > > 
> > > > @@ -89,6 +91,10 @@ enum v4l2_mbus_pixelcode {
> > > > 
> > > >  	V4L2_MBUS_FMT_SGBRG12_1X12 = 0x3010,
> > > >  	V4L2_MBUS_FMT_SGRBG12_1X12 = 0x3011,
> > > >  	V4L2_MBUS_FMT_SRGGB12_1X12 = 0x3012,
> > > > 
> > > > +	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,
> > > 
> > > Please keep the names sorted as described in the comment at the 
> > > beginning of the file.
> > > 
> > > >  	/* JPEG compressed formats - next is 0x4002 */
> > > >  	V4L2_MBUS_FMT_JPEG_1X8 = 0x4001,
> 
> --
> Regards,
> 
> Laurent Pinchart
> 

Re: [PATCH 1/2] media: add new mediabus format enums for dm365

[Laurent Pinchart]

Hi Manju,

On Wednesday 21 December 2011 14:54:18 Hadli, Manjunath wrote:
> On Wed, Dec 21, 2011 at 05:28:31, Laurent Pinchart wrote:
> > On Friday 16 December 2011 15:20:24 Hadli, Manjunath wrote:
> > > On Thu, Dec 15, 2011 at 18:32:44, Laurent Pinchart wrote:
> > > > On Thursday 15 December 2011 13:24:57 Manjunath Hadli wrote:
> > > > > add new enum entry V4L2_MBUS_FMT_SGRBG10_ALAW8_1X8 into
> > > > > mbus_pixel_code to represent A-LAW compressed Bayer format. This
> > > > > corresponds to pixel format - V4L2_PIX_FMT_SGRBG10ALAW8.
> > > > > add UV8 and NV12 ( Y and C separate with UV interleaved) which are
> > > > > supported on dm365.
> > > > > 
> > > > > Signed-off-by: Manjunath Hadli <manjunath.hadli@ti.com>
> > > > > Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> > > > > ---
> > > > > 
> > > > >  include/linux/v4l2-mediabus.h |   10 ++++++++--
> > > > >  1 files changed, 8 insertions(+), 2 deletions(-)
> > > > 
> > > > Please also update the documentation in
> > > > Documentation/DocBook/media/v4l.
> > > > 
> > > > > diff --git a/include/linux/v4l2-mediabus.h
> > > > > b/include/linux/v4l2-mediabus.h index 5ea7f75..d408654 100644
> > > > > --- a/include/linux/v4l2-mediabus.h
> > > > > +++ b/include/linux/v4l2-mediabus.h
> > > > > @@ -47,7 +47,7 @@ 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_UYVY8_1_5X8 = 0x2002,
> > > > >  	V4L2_MBUS_FMT_VYUY8_1_5X8 = 0x2003,
> > > > > 
> > > > > @@ -67,8 +67,10 @@ enum v4l2_mbus_pixelcode {
> > > > > 
> > > > >  	V4L2_MBUS_FMT_YVYU8_1X16 = 0x2012,
> > > > >  	V4L2_MBUS_FMT_YUYV10_1X20 = 0x200d,
> > > > >  	V4L2_MBUS_FMT_YVYU10_1X20 = 0x200e,
> > > > > 
> > > > > +	V4L2_MBUS_FMT_NV12_1X20 = 0x2014,
> > > > > +	V4L2_MBUS_FMT_UV8_1X8 = 0x2015,
> > > > 
> > > > NV12, on the bus ? How does that work ? (The documentation should
> > > > answer my question :-))
> > > 
> > > Well, this is on the internal bus not exposed outside, but
> > > nevertheless bus between two subdevs or two independent hardware
> > > blocks. For example Resizer supports NV12 on its pad. Is there any
> > > other way to treat this?
> > 
> > How is NV12 transferred on the bus in that case ? Are all luma samples
> > transferred first, followed by all chroma samples ?
> 
> It uses parallel bus of 16 bits, where Y and C are transmitted
> simultaneously on 8 bits each. NV12 uses a dummy C byte for every valid
> one.
> So I guess we call it V4L2_MBUS_FMT_YDYC_1X16 or V4L2_MBUS_FMT_YCYD_1X16?
> That way we will be able to document the format in the documentation also.

That sounds good (YDYC8_1X16 to be precise). Hans, Guennadi, Sakari, any 
opinion ?

-- 
Regards,

Laurent Pinchart

[PATCH 2/2] v4l2: add new pixel formats supported on dm365

[Manjunath Hadli]

add new macro V4L2_PIX_FMT_SGRBG10ALAW8 to represent Bayer format
frames compressed by A-LAW alogorithm.
add V4L2_PIX_FMT_UV8 to represent storage of C (UV interleved) only.

Signed-off-by: Manjunath Hadli <manjunath.hadli@ti.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
 include/linux/videodev2.h |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 4b752d5..969112d 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -338,6 +338,9 @@ struct v4l2_pix_format {
 #define V4L2_PIX_FMT_HM12    v4l2_fourcc('H', 'M', '1', '2') /*  8  YUV 4:2:0 16x16 macroblocks */
 #define V4L2_PIX_FMT_M420    v4l2_fourcc('M', '4', '2', '0') /* 12  YUV 4:2:0 2 lines y, 1 line uv interleaved */
 
+/* Chrominance formats */
+#define V4L2_PIX_FMT_UV8      v4l2_fourcc('U', 'V', '8', ' ') /*  8  UV 4:4 */
+
 /* two planes -- one Y, one Cr + Cb interleaved  */
 #define V4L2_PIX_FMT_NV12    v4l2_fourcc('N', 'V', '1', '2') /* 12  Y/CbCr 4:2:0  */
 #define V4L2_PIX_FMT_NV21    v4l2_fourcc('N', 'V', '2', '1') /* 12  Y/CrCb 4:2:0  */
@@ -366,6 +369,9 @@ struct v4l2_pix_format {
 #define V4L2_PIX_FMT_SRGGB12 v4l2_fourcc('R', 'G', '1', '2') /* 12  RGRG.. GBGB.. */
 	/* 10bit raw bayer DPCM compressed to 8 bits */
 #define V4L2_PIX_FMT_SGRBG10DPCM8 v4l2_fourcc('B', 'D', '1', '0')
+	/* 10bit raw bayer a-law compressed to 8 bits */
+#define V4L2_PIX_FMT_SGRBG10ALAW8 v4l2_fourcc('A', 'L', 'W', '8')
+
 	/*
 	 * 10bit raw bayer, expanded to 16 bits
 	 * xxxxrrrrrrrrrrxxxxgggggggggg xxxxggggggggggxxxxbbbbbbbbbb...
-- 
1.6.2.4

Re: [PATCH 2/2] v4l2: add new pixel formats supported on dm365

[Laurent Pinchart]

Hi Manjunath,

Thanks for the patch.

On Thursday 15 December 2011 13:24:58 Manjunath Hadli wrote:
> add new macro V4L2_PIX_FMT_SGRBG10ALAW8 to represent Bayer format
> frames compressed by A-LAW alogorithm.
> add V4L2_PIX_FMT_UV8 to represent storage of C (UV interleved) only.
> 
> Signed-off-by: Manjunath Hadli <manjunath.hadli@ti.com>
> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
>  include/linux/videodev2.h |    6 ++++++
>  1 files changed, 6 insertions(+), 0 deletions(-)

Could you please also document these formats in 
Documentation/DocBook/media/v4l ?

> diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
> index 4b752d5..969112d 100644
> --- a/include/linux/videodev2.h
> +++ b/include/linux/videodev2.h
> @@ -338,6 +338,9 @@ struct v4l2_pix_format {
>  #define V4L2_PIX_FMT_HM12    v4l2_fourcc('H', 'M', '1', '2') /*  8  YUV
> 4:2:0 16x16 macroblocks */ #define V4L2_PIX_FMT_M420    v4l2_fourcc('M',
> '4', '2', '0') /* 12  YUV 4:2:0 2 lines y, 1 line uv interleaved */
> 
> +/* Chrominance formats */
> +#define V4L2_PIX_FMT_UV8      v4l2_fourcc('U', 'V', '8', ' ') /*  8  UV
> 4:4 */ +
>  /* two planes -- one Y, one Cr + Cb interleaved  */
>  #define V4L2_PIX_FMT_NV12    v4l2_fourcc('N', 'V', '1', '2') /* 12  Y/CbCr
> 4:2:0  */ #define V4L2_PIX_FMT_NV21    v4l2_fourcc('N', 'V', '2', '1') /*
> 12  Y/CrCb 4:2:0  */ @@ -366,6 +369,9 @@ struct v4l2_pix_format {
>  #define V4L2_PIX_FMT_SRGGB12 v4l2_fourcc('R', 'G', '1', '2') /* 12  RGRG..
> GBGB.. */ /* 10bit raw bayer DPCM compressed to 8 bits */
>  #define V4L2_PIX_FMT_SGRBG10DPCM8 v4l2_fourcc('B', 'D', '1', '0')
> +	/* 10bit raw bayer a-law compressed to 8 bits */
> +#define V4L2_PIX_FMT_SGRBG10ALAW8 v4l2_fourcc('A', 'L', 'W', '8')
> +

That's not very future-proof, how would you describe SGBRG10ALAW8 for instance 
?

Maybe it's time to standardize FOURCCs for Bayer new formats. We have 4 
characters, we could start with 'B' to denote Bayer, followed by one character 
for the order, one for the compression, and one for the number of bits.

>  	/*
>  	 * 10bit raw bayer, expanded to 16 bits
>  	 * xxxxrrrrrrrrrrxxxxgggggggggg xxxxggggggggggxxxxbbbbbbbbbb...

-- 
Regards,

Laurent Pinchart

RE: [PATCH 2/2] v4l2: add new pixel formats supported on dm365

[Hadli, Manjunath]

Hello Laurent,
Thank you for the comments.

On Thu, Dec 15, 2011 at 18:30:47, Laurent Pinchart wrote:
> Hi Manjunath,
> 
> Thanks for the patch.
> 
> On Thursday 15 December 2011 13:24:58 Manjunath Hadli wrote:
> > add new macro V4L2_PIX_FMT_SGRBG10ALAW8 to represent Bayer format 
> > frames compressed by A-LAW alogorithm.
> > add V4L2_PIX_FMT_UV8 to represent storage of C (UV interleved) only.
> > 
> > Signed-off-by: Manjunath Hadli <manjunath.hadli@ti.com>
> > Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> > ---
> >  include/linux/videodev2.h |    6 ++++++
> >  1 files changed, 6 insertions(+), 0 deletions(-)
> 
> Could you please also document these formats in Documentation/DocBook/media/v4l ?
I will. Sorry to have missed that out.

> 
> > diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h 
> > index 4b752d5..969112d 100644
> > --- a/include/linux/videodev2.h
> > +++ b/include/linux/videodev2.h
> > @@ -338,6 +338,9 @@ struct v4l2_pix_format {
> >  #define V4L2_PIX_FMT_HM12    v4l2_fourcc('H', 'M', '1', '2') /*  8  YUV
> > 4:2:0 16x16 macroblocks */ #define V4L2_PIX_FMT_M420    v4l2_fourcc('M',
> > '4', '2', '0') /* 12  YUV 4:2:0 2 lines y, 1 line uv interleaved */
> > 
> > +/* Chrominance formats */
> > +#define V4L2_PIX_FMT_UV8      v4l2_fourcc('U', 'V', '8', ' ') /*  8  UV
> > 4:4 */ +
> >  /* two planes -- one Y, one Cr + Cb interleaved  */
> >  #define V4L2_PIX_FMT_NV12    v4l2_fourcc('N', 'V', '1', '2') /* 12  Y/CbCr
> > 4:2:0  */ #define V4L2_PIX_FMT_NV21    v4l2_fourcc('N', 'V', '2', '1') /*
> > 12  Y/CrCb 4:2:0  */ @@ -366,6 +369,9 @@ struct v4l2_pix_format {  
> > #define V4L2_PIX_FMT_SRGGB12 v4l2_fourcc('R', 'G', '1', '2') /* 12  RGRG..
> > GBGB.. */ /* 10bit raw bayer DPCM compressed to 8 bits */  #define 
> > V4L2_PIX_FMT_SGRBG10DPCM8 v4l2_fourcc('B', 'D', '1', '0')
> > +	/* 10bit raw bayer a-law compressed to 8 bits */ #define 
> > +V4L2_PIX_FMT_SGRBG10ALAW8 v4l2_fourcc('A', 'L', 'W', '8')
> > +
> 
> That's not very future-proof, how would you describe SGBRG10ALAW8 for instance ?
> 
> Maybe it's time to standardize FOURCCs for Bayer new formats. We have 4 characters, we could start with 'B' to denote Bayer, followed by one character for the order, one for the compression, and one for the number of bits.
I agree.
May be ('B', 'G', 'A', '8') is fine for the above?

Thanks and Regards,
-Manju
> 
> >  	/*
> >  	 * 10bit raw bayer, expanded to 16 bits
> >  	 * xxxxrrrrrrrrrrxxxxgggggggggg xxxxggggggggggxxxxbbbbbbbbbb...
> 
> --
> Regards,
> 
> Laurent Pinchart
> 

Re: [PATCH 2/2] v4l2: add new pixel formats supported on dm365

[Laurent Pinchart]

Hi Manju,

On Friday 16 December 2011 14:42:48 Hadli, Manjunath wrote:
> On Thu, Dec 15, 2011 at 18:30:47, Laurent Pinchart wrote:
> > On Thursday 15 December 2011 13:24:58 Manjunath Hadli wrote:
> > > add new macro V4L2_PIX_FMT_SGRBG10ALAW8 to represent Bayer format
> > > frames compressed by A-LAW alogorithm.
> > > add V4L2_PIX_FMT_UV8 to represent storage of C (UV interleved) only.
> > > 
> > > Signed-off-by: Manjunath Hadli <manjunath.hadli@ti.com>
> > > Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> > > ---
> > > 
> > >  include/linux/videodev2.h |    6 ++++++
> > >  1 files changed, 6 insertions(+), 0 deletions(-)
> > 
> > Could you please also document these formats in
> > Documentation/DocBook/media/v4l ?
> 
> I will. Sorry to have missed that out.
> 
> > > diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
> > > index 4b752d5..969112d 100644
> > > --- a/include/linux/videodev2.h
> > > +++ b/include/linux/videodev2.h
> > > @@ -338,6 +338,9 @@ struct v4l2_pix_format {
> > > 
> > >  #define V4L2_PIX_FMT_HM12    v4l2_fourcc('H', 'M', '1', '2') /*  8 
> > >  YUV
> > > 
> > > 4:2:0 16x16 macroblocks */ #define V4L2_PIX_FMT_M420   
> > > v4l2_fourcc('M', '4', '2', '0') /* 12  YUV 4:2:0 2 lines y, 1 line uv
> > > interleaved */
> > > 
> > > +/* Chrominance formats */
> > > +#define V4L2_PIX_FMT_UV8      v4l2_fourcc('U', 'V', '8', ' ') /*  8 
> > > UV 4:4 */ +
> > > 
> > >  /* two planes -- one Y, one Cr + Cb interleaved  */
> > >  #define V4L2_PIX_FMT_NV12    v4l2_fourcc('N', 'V', '1', '2') /* 12 
> > >  Y/CbCr
> > > 
> > > 4:2:0  */ #define V4L2_PIX_FMT_NV21    v4l2_fourcc('N', 'V', '2', '1')
> > > /* 12  Y/CrCb 4:2:0  */ @@ -366,6 +369,9 @@ struct v4l2_pix_format {
> > > #define V4L2_PIX_FMT_SRGGB12 v4l2_fourcc('R', 'G', '1', '2') /* 12 
> > > RGRG.. GBGB.. */ /* 10bit raw bayer DPCM compressed to 8 bits */ 
> > > #define V4L2_PIX_FMT_SGRBG10DPCM8 v4l2_fourcc('B', 'D', '1', '0')
> > > +	/* 10bit raw bayer a-law compressed to 8 bits */ #define
> > > +V4L2_PIX_FMT_SGRBG10ALAW8 v4l2_fourcc('A', 'L', 'W', '8')
> > > +
> > 
> > That's not very future-proof, how would you describe SGBRG10ALAW8 for
> > instance ?
> > 
> > Maybe it's time to standardize FOURCCs for Bayer new formats. We have 4
> > characters, we could start with 'B' to denote Bayer, followed by one
> > character for the order, one for the compression, and one for the number
> > of bits.
> 
> I agree.
> May be ('B', 'G', 'A', '8') is fine for the above?

We need to describe at last BGGR, GBRG, GRBG and RGGB. We could use 'B', 'g', 
'G' and 'R' respectively for the second character. The third character would 
be 'A' for A-law and 'D' for DPCM, and the fourth character could describe the 
bus width in bits from 0 to 15 with '0' - '9', 'A' - 'F'. However, I suspect 
that we will need 16-bit wide busses for raw Bayer at some point, and a 0 
width is definitely not useful. We could thus offset the width by some value.

This is just a preliminary idea, I'm open to suggestions.

> > >  	/*
> > >  	
> > >  	 * 10bit raw bayer, expanded to 16 bits
> > >  	 * xxxxrrrrrrrrrrxxxxgggggggggg xxxxggggggggggxxxxbbbbbbbbbb...

-- 
Regards,

Laurent Pinchart

RE: [PATCH 2/2] v4l2: add new pixel formats supported on dm365

[Hadli, Manjunath]

Laurent,

On Wed, Dec 21, 2011 at 05:32:08, Laurent Pinchart wrote:
> Hi Manju,
> 
> On Friday 16 December 2011 14:42:48 Hadli, Manjunath wrote:
> > On Thu, Dec 15, 2011 at 18:30:47, Laurent Pinchart wrote:
> > > On Thursday 15 December 2011 13:24:58 Manjunath Hadli wrote:
> > > > add new macro V4L2_PIX_FMT_SGRBG10ALAW8 to represent Bayer format 
> > > > frames compressed by A-LAW alogorithm.
> > > > add V4L2_PIX_FMT_UV8 to represent storage of C (UV interleved) only.
> > > > 
> > > > Signed-off-by: Manjunath Hadli <manjunath.hadli@ti.com>
> > > > Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> > > > ---
> > > > 
> > > >  include/linux/videodev2.h |    6 ++++++
> > > >  1 files changed, 6 insertions(+), 0 deletions(-)
> > > 
> > > Could you please also document these formats in 
> > > Documentation/DocBook/media/v4l ?
> > 
> > I will. Sorry to have missed that out.
> > 
> > > > diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h 
> > > > index 4b752d5..969112d 100644
> > > > --- a/include/linux/videodev2.h
> > > > +++ b/include/linux/videodev2.h
> > > > @@ -338,6 +338,9 @@ struct v4l2_pix_format {
> > > > 
> > > >  #define V4L2_PIX_FMT_HM12    v4l2_fourcc('H', 'M', '1', '2') /*  8 
> > > >  YUV
> > > > 
> > > > 4:2:0 16x16 macroblocks */ #define V4L2_PIX_FMT_M420   
> > > > v4l2_fourcc('M', '4', '2', '0') /* 12  YUV 4:2:0 2 lines y, 1 line 
> > > > uv interleaved */
> > > > 
> > > > +/* Chrominance formats */
> > > > +#define V4L2_PIX_FMT_UV8      v4l2_fourcc('U', 'V', '8', ' ') /*  8 
> > > > UV 4:4 */ +
> > > > 
> > > >  /* two planes -- one Y, one Cr + Cb interleaved  */
> > > >  #define V4L2_PIX_FMT_NV12    v4l2_fourcc('N', 'V', '1', '2') /* 12 
> > > >  Y/CbCr
> > > > 
> > > > 4:2:0  */ #define V4L2_PIX_FMT_NV21    v4l2_fourcc('N', 'V', '2', '1')
> > > > /* 12  Y/CrCb 4:2:0  */ @@ -366,6 +369,9 @@ struct v4l2_pix_format 
> > > > { #define V4L2_PIX_FMT_SRGGB12 v4l2_fourcc('R', 'G', '1', '2') /* 
> > > > 12 RGRG.. GBGB.. */ /* 10bit raw bayer DPCM compressed to 8 bits 
> > > > */ #define V4L2_PIX_FMT_SGRBG10DPCM8 v4l2_fourcc('B', 'D', '1', 
> > > > '0')
> > > > +	/* 10bit raw bayer a-law compressed to 8 bits */ #define
> > > > +V4L2_PIX_FMT_SGRBG10ALAW8 v4l2_fourcc('A', 'L', 'W', '8')
> > > > +
> > > 
> > > That's not very future-proof, how would you describe SGBRG10ALAW8 
> > > for instance ?
> > > 
> > > Maybe it's time to standardize FOURCCs for Bayer new formats. We 
> > > have 4 characters, we could start with 'B' to denote Bayer, followed 
> > > by one character for the order, one for the compression, and one for 
> > > the number of bits.
> > 
> > I agree.
> > May be ('B', 'G', 'A', '8') is fine for the above?
> 
> We need to describe at last BGGR, GBRG, GRBG and RGGB. We could use 'B', 'g', 'G' and 'R' respectively for the second character. The third character would be 'A' for A-law and 'D' for DPCM, and the fourth character could describe the bus width in bits from 0 to 15 with '0' - '9', 'A' - 'F'. However, I suspect that we will need 16-bit wide busses for raw Bayer at some point, and a 0 width is definitely not useful. We could thus offset the width by some value.
> 
> This is just a preliminary idea, I'm open to suggestions.
I think it is a very good suggestion that we can go with.
B : BGGR
g : GBRG
G : GRBG
R : RGGB

and 0-F can signify 1-16.

Thx,
-Manju

> 
> > > >  	/*
> > > >  	
> > > >  	 * 10bit raw bayer, expanded to 16 bits
> > > >  	 * xxxxrrrrrrrrrrxxxxgggggggggg xxxxggggggggggxxxxbbbbbbbbbb...
> 
> --
> Regards,
> 
> Laurent Pinchart
> 

Re: [PATCH 2/2] v4l2: add new pixel formats supported on dm365

[Laurent Pinchart]

Hi Manju,

On Wednesday 21 December 2011 14:56:36 Hadli, Manjunath wrote:
> On Wed, Dec 21, 2011 at 05:32:08, Laurent Pinchart wrote:
> > On Friday 16 December 2011 14:42:48 Hadli, Manjunath wrote:
> > > On Thu, Dec 15, 2011 at 18:30:47, Laurent Pinchart wrote:
> > > > On Thursday 15 December 2011 13:24:58 Manjunath Hadli wrote:
> > > > > add new macro V4L2_PIX_FMT_SGRBG10ALAW8 to represent Bayer format
> > > > > frames compressed by A-LAW alogorithm.
> > > > > add V4L2_PIX_FMT_UV8 to represent storage of C (UV interleved)
> > > > > only.
> > > > > 
> > > > > Signed-off-by: Manjunath Hadli <manjunath.hadli@ti.com>
> > > > > Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> > > > > ---
> > > > > 
> > > > >  include/linux/videodev2.h |    6 ++++++
> > > > >  1 files changed, 6 insertions(+), 0 deletions(-)
> > > > 
> > > > Could you please also document these formats in
> > > > Documentation/DocBook/media/v4l ?
> > > 
> > > I will. Sorry to have missed that out.
> > > 
> > > > > diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
> > > > > index 4b752d5..969112d 100644
> > > > > --- a/include/linux/videodev2.h
> > > > > +++ b/include/linux/videodev2.h
> > > > > @@ -338,6 +338,9 @@ struct v4l2_pix_format {
> > > > > 
> > > > >  #define V4L2_PIX_FMT_HM12    v4l2_fourcc('H', 'M', '1', '2') /*  8
> > > > >  YUV
> > > > > 
> > > > > 4:2:0 16x16 macroblocks */ #define V4L2_PIX_FMT_M420
> > > > > v4l2_fourcc('M', '4', '2', '0') /* 12  YUV 4:2:0 2 lines y, 1 line
> > > > > uv interleaved */
> > > > > 
> > > > > +/* Chrominance formats */
> > > > > +#define V4L2_PIX_FMT_UV8      v4l2_fourcc('U', 'V', '8', ' ') /* 
> > > > > 8 UV 4:4 */ +
> > > > > 
> > > > >  /* two planes -- one Y, one Cr + Cb interleaved  */
> > > > >  #define V4L2_PIX_FMT_NV12    v4l2_fourcc('N', 'V', '1', '2') /* 12
> > > > >  Y/CbCr
> > > > > 
> > > > > 4:2:0  */ #define V4L2_PIX_FMT_NV21    v4l2_fourcc('N', 'V', '2',
> > > > > '1') /* 12  Y/CrCb 4:2:0  */ @@ -366,6 +369,9 @@ struct
> > > > > v4l2_pix_format { #define V4L2_PIX_FMT_SRGGB12 v4l2_fourcc('R',
> > > > > 'G', '1', '2') /* 12 RGRG.. GBGB.. */ /* 10bit raw bayer DPCM
> > > > > compressed to 8 bits */ #define V4L2_PIX_FMT_SGRBG10DPCM8
> > > > > v4l2_fourcc('B', 'D', '1', '0')
> > > > > +	/* 10bit raw bayer a-law compressed to 8 bits */ #define
> > > > > +V4L2_PIX_FMT_SGRBG10ALAW8 v4l2_fourcc('A', 'L', 'W', '8')
> > > > > +
> > > > 
> > > > That's not very future-proof, how would you describe SGBRG10ALAW8
> > > > for instance ?
> > > > 
> > > > Maybe it's time to standardize FOURCCs for Bayer new formats. We
> > > > have 4 characters, we could start with 'B' to denote Bayer, followed
> > > > by one character for the order, one for the compression, and one for
> > > > the number of bits.
> > > 
> > > I agree.
> > > May be ('B', 'G', 'A', '8') is fine for the above?
> > 
> > We need to describe at last BGGR, GBRG, GRBG and RGGB. We could use 'B',
> > 'g', 'G' and 'R' respectively for the second character. The third
> > character would be 'A' for A-law and 'D' for DPCM, and the fourth
> > character could describe the bus width in bits from 0 to 15 with '0' -
> > '9', 'A' - 'F'. However, I suspect that we will need 16-bit wide busses
> > for raw Bayer at some point, and a 0 width is definitely not useful. We
> > could thus offset the width by some value.
> > 
> > This is just a preliminary idea, I'm open to suggestions.
> 
> I think it is a very good suggestion that we can go with.
> B : BGGR
> g : GBRG
> G : GRBG
> R : RGGB
> 
> and 0-F can signify 1-16.

Hans, Guennadi, Sakari, any opinion on that as well ?

-- 
Regards,

Laurent Pinchart

Re: [PATCH 2/2] v4l2: add new pixel formats supported on dm365

[Guennadi Liakhovetski]

On Wed, 21 Dec 2011, Laurent Pinchart wrote:

> Hi Manju,
> 
> On Wednesday 21 December 2011 14:56:36 Hadli, Manjunath wrote:
> > On Wed, Dec 21, 2011 at 05:32:08, Laurent Pinchart wrote:
> > > On Friday 16 December 2011 14:42:48 Hadli, Manjunath wrote:
> > > > On Thu, Dec 15, 2011 at 18:30:47, Laurent Pinchart wrote:
> > > > > On Thursday 15 December 2011 13:24:58 Manjunath Hadli wrote:
> > > > > > add new macro V4L2_PIX_FMT_SGRBG10ALAW8 to represent Bayer format
> > > > > > frames compressed by A-LAW alogorithm.
> > > > > > add V4L2_PIX_FMT_UV8 to represent storage of C (UV interleved)
> > > > > > only.
> > > > > > 
> > > > > > Signed-off-by: Manjunath Hadli <manjunath.hadli@ti.com>
> > > > > > Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> > > > > > ---
> > > > > > 
> > > > > >  include/linux/videodev2.h |    6 ++++++
> > > > > >  1 files changed, 6 insertions(+), 0 deletions(-)
> > > > > 
> > > > > Could you please also document these formats in
> > > > > Documentation/DocBook/media/v4l ?
> > > > 
> > > > I will. Sorry to have missed that out.
> > > > 
> > > > > > diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
> > > > > > index 4b752d5..969112d 100644
> > > > > > --- a/include/linux/videodev2.h
> > > > > > +++ b/include/linux/videodev2.h
> > > > > > @@ -338,6 +338,9 @@ struct v4l2_pix_format {
> > > > > > 
> > > > > >  #define V4L2_PIX_FMT_HM12    v4l2_fourcc('H', 'M', '1', '2') /*  8
> > > > > >  YUV
> > > > > > 
> > > > > > 4:2:0 16x16 macroblocks */ #define V4L2_PIX_FMT_M420
> > > > > > v4l2_fourcc('M', '4', '2', '0') /* 12  YUV 4:2:0 2 lines y, 1 line
> > > > > > uv interleaved */
> > > > > > 
> > > > > > +/* Chrominance formats */
> > > > > > +#define V4L2_PIX_FMT_UV8      v4l2_fourcc('U', 'V', '8', ' ') /* 
> > > > > > 8 UV 4:4 */ +
> > > > > > 
> > > > > >  /* two planes -- one Y, one Cr + Cb interleaved  */
> > > > > >  #define V4L2_PIX_FMT_NV12    v4l2_fourcc('N', 'V', '1', '2') /* 12
> > > > > >  Y/CbCr
> > > > > > 
> > > > > > 4:2:0  */ #define V4L2_PIX_FMT_NV21    v4l2_fourcc('N', 'V', '2',
> > > > > > '1') /* 12  Y/CrCb 4:2:0  */ @@ -366,6 +369,9 @@ struct
> > > > > > v4l2_pix_format { #define V4L2_PIX_FMT_SRGGB12 v4l2_fourcc('R',
> > > > > > 'G', '1', '2') /* 12 RGRG.. GBGB.. */ /* 10bit raw bayer DPCM
> > > > > > compressed to 8 bits */ #define V4L2_PIX_FMT_SGRBG10DPCM8
> > > > > > v4l2_fourcc('B', 'D', '1', '0')
> > > > > > +	/* 10bit raw bayer a-law compressed to 8 bits */ #define
> > > > > > +V4L2_PIX_FMT_SGRBG10ALAW8 v4l2_fourcc('A', 'L', 'W', '8')
> > > > > > +
> > > > > 
> > > > > That's not very future-proof, how would you describe SGBRG10ALAW8
> > > > > for instance ?
> > > > > 
> > > > > Maybe it's time to standardize FOURCCs for Bayer new formats. We
> > > > > have 4 characters, we could start with 'B' to denote Bayer, followed
> > > > > by one character for the order, one for the compression, and one for
> > > > > the number of bits.
> > > > 
> > > > I agree.
> > > > May be ('B', 'G', 'A', '8') is fine for the above?
> > > 
> > > We need to describe at last BGGR, GBRG, GRBG and RGGB. We could use 'B',
> > > 'g', 'G' and 'R' respectively for the second character. The third
> > > character would be 'A' for A-law and 'D' for DPCM, and the fourth
> > > character could describe the bus width in bits from 0 to 15 with '0' -
> > > '9', 'A' - 'F'. However, I suspect that we will need 16-bit wide busses
> > > for raw Bayer at some point, and a 0 width is definitely not useful. We
> > > could thus offset the width by some value.
> > > 
> > > This is just a preliminary idea, I'm open to suggestions.
> > 
> > I think it is a very good suggestion that we can go with.
> > B : BGGR
> > g : GBRG
> > G : GRBG
> > R : RGGB
> > 
> > and 0-F can signify 1-16.
> 
> Hans, Guennadi, Sakari, any opinion on that as well ?

Is there any risk of confusion, if we don't reserve the first character 
for 'B'? I'm just trying to avoid mixed cases, I'm not a great fan of 
those;-) What if we use the first two characters for the order like "GR", 
"GB",... AFAICS, 'G' so far only also occurs in GREY and various RGB* / 
BGR* / ... formats, which we wouldn't be confusing with. We could further 
reduce confusion, if we use some other character for A-law ('L' or 'W'?)

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

Re: [PATCH 2/2] v4l2: add new pixel formats supported on dm365

[Laurent Pinchart]

Hi Guennadi,

On Wednesday 21 December 2011 23:46:24 Guennadi Liakhovetski wrote:
> On Wed, 21 Dec 2011, Laurent Pinchart wrote:
> > On Wednesday 21 December 2011 14:56:36 Hadli, Manjunath wrote:
> > > On Wed, Dec 21, 2011 at 05:32:08, Laurent Pinchart wrote:
> > > > On Friday 16 December 2011 14:42:48 Hadli, Manjunath wrote:
> > > > > On Thu, Dec 15, 2011 at 18:30:47, Laurent Pinchart wrote:
> > > > > > On Thursday 15 December 2011 13:24:58 Manjunath Hadli wrote:
> > > > > > > add new macro V4L2_PIX_FMT_SGRBG10ALAW8 to represent Bayer
> > > > > > > format frames compressed by A-LAW alogorithm.
> > > > > > > add V4L2_PIX_FMT_UV8 to represent storage of C (UV interleved)
> > > > > > > only.
> > > > > > > 
> > > > > > > Signed-off-by: Manjunath Hadli <manjunath.hadli@ti.com>
> > > > > > > Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> > > > > > > ---
> > > > > > > 
> > > > > > >  include/linux/videodev2.h |    6 ++++++
> > > > > > >  1 files changed, 6 insertions(+), 0 deletions(-)
> > > > > > 
> > > > > > Could you please also document these formats in
> > > > > > Documentation/DocBook/media/v4l ?
> > > > > 
> > > > > I will. Sorry to have missed that out.
> > > > > 
> > > > > > > diff --git a/include/linux/videodev2.h
> > > > > > > b/include/linux/videodev2.h index 4b752d5..969112d 100644
> > > > > > > --- a/include/linux/videodev2.h
> > > > > > > +++ b/include/linux/videodev2.h
> > > > > > > @@ -338,6 +338,9 @@ struct v4l2_pix_format {
> > > > > > > 
> > > > > > >  #define V4L2_PIX_FMT_HM12    v4l2_fourcc('H', 'M', '1', '2')
> > > > > > >  /*  8 YUV
> > > > > > > 
> > > > > > > 4:2:0 16x16 macroblocks */ #define V4L2_PIX_FMT_M420
> > > > > > > v4l2_fourcc('M', '4', '2', '0') /* 12  YUV 4:2:0 2 lines y, 1
> > > > > > > line uv interleaved */
> > > > > > > 
> > > > > > > +/* Chrominance formats */
> > > > > > > +#define V4L2_PIX_FMT_UV8      v4l2_fourcc('U', 'V', '8', ' ')
> > > > > > > /* 8 UV 4:4 */ +
> > > > > > > 
> > > > > > >  /* two planes -- one Y, one Cr + Cb interleaved  */
> > > > > > >  #define V4L2_PIX_FMT_NV12    v4l2_fourcc('N', 'V', '1', '2')
> > > > > > >  /* 12 Y/CbCr
> > > > > > > 
> > > > > > > 4:2:0  */ #define V4L2_PIX_FMT_NV21    v4l2_fourcc('N', 'V',
> > > > > > > '2', '1') /* 12  Y/CrCb 4:2:0  */ @@ -366,6 +369,9 @@ struct
> > > > > > > v4l2_pix_format { #define V4L2_PIX_FMT_SRGGB12
> > > > > > > v4l2_fourcc('R', 'G', '1', '2') /* 12 RGRG.. GBGB.. */ /*
> > > > > > > 10bit raw bayer DPCM compressed to 8 bits */ #define
> > > > > > > V4L2_PIX_FMT_SGRBG10DPCM8 v4l2_fourcc('B', 'D', '1', '0')
> > > > > > > +	/* 10bit raw bayer a-law compressed to 8 bits */ #define
> > > > > > > +V4L2_PIX_FMT_SGRBG10ALAW8 v4l2_fourcc('A', 'L', 'W', '8')
> > > > > > > +
> > > > > > 
> > > > > > That's not very future-proof, how would you describe SGBRG10ALAW8
> > > > > > for instance ?
> > > > > > 
> > > > > > Maybe it's time to standardize FOURCCs for Bayer new formats. We
> > > > > > have 4 characters, we could start with 'B' to denote Bayer,
> > > > > > followed by one character for the order, one for the
> > > > > > compression, and one for the number of bits.
> > > > > 
> > > > > I agree.
> > > > > May be ('B', 'G', 'A', '8') is fine for the above?
> > > > 
> > > > We need to describe at last BGGR, GBRG, GRBG and RGGB. We could use
> > > > 'B', 'g', 'G' and 'R' respectively for the second character. The
> > > > third character would be 'A' for A-law and 'D' for DPCM, and the
> > > > fourth character could describe the bus width in bits from 0 to 15
> > > > with '0' - '9', 'A' - 'F'. However, I suspect that we will need
> > > > 16-bit wide busses for raw Bayer at some point, and a 0 width is
> > > > definitely not useful. We could thus offset the width by some value.
> > > > 
> > > > This is just a preliminary idea, I'm open to suggestions.
> > > 
> > > I think it is a very good suggestion that we can go with.
> > > B : BGGR
> > > g : GBRG
> > > G : GRBG
> > > R : RGGB
> > > 
> > > and 0-F can signify 1-16.
> > 
> > Hans, Guennadi, Sakari, any opinion on that as well ?
> 
> Is there any risk of confusion, if we don't reserve the first character
> for 'B'? I'm just trying to avoid mixed cases, I'm not a great fan of
> those;-)

FOURCCs are not really supposed to be displayed anyway :-)

> What if we use the first two characters for the order like "GR", "GB",...
> AFAICS, 'G' so far only also occurs in GREY and various RGB* / BGR* / ...
> formats, which we wouldn't be confusing with.

Or we could use random FOURCC values as well :-)

There could also be other non-Bayer raw formats, such as panchromatic cells or 
Foveon patterns. I don't know if we need to plan for them already.

> We could further reduce confusion, if we use some other character for A-law
> ('L' or 'W'?)

We could also have µ-law compression, L and W would be ambiguous.

-- 
Regards,

Laurent Pinchart

Re: [PATCH 2/2] v4l2: add new pixel formats supported on dm365

[Sakari Ailus]

Hi Laurent,

On Wed, Dec 21, 2011 at 11:23:26PM +0100, Laurent Pinchart wrote:
> Hi Manju,
> 
> On Wednesday 21 December 2011 14:56:36 Hadli, Manjunath wrote:
> > On Wed, Dec 21, 2011 at 05:32:08, Laurent Pinchart wrote:
> > > On Friday 16 December 2011 14:42:48 Hadli, Manjunath wrote:
> > > > On Thu, Dec 15, 2011 at 18:30:47, Laurent Pinchart wrote:
> > > > > On Thursday 15 December 2011 13:24:58 Manjunath Hadli wrote:
> > > > > > add new macro V4L2_PIX_FMT_SGRBG10ALAW8 to represent Bayer format
> > > > > > frames compressed by A-LAW alogorithm.
> > > > > > add V4L2_PIX_FMT_UV8 to represent storage of C (UV interleved)
> > > > > > only.
> > > > > > 
> > > > > > Signed-off-by: Manjunath Hadli <manjunath.hadli@ti.com>
> > > > > > Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> > > > > > ---
> > > > > > 
> > > > > >  include/linux/videodev2.h |    6 ++++++
> > > > > >  1 files changed, 6 insertions(+), 0 deletions(-)
> > > > > 
> > > > > Could you please also document these formats in
> > > > > Documentation/DocBook/media/v4l ?
> > > > 
> > > > I will. Sorry to have missed that out.
> > > > 
> > > > > > diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
> > > > > > index 4b752d5..969112d 100644
> > > > > > --- a/include/linux/videodev2.h
> > > > > > +++ b/include/linux/videodev2.h
> > > > > > @@ -338,6 +338,9 @@ struct v4l2_pix_format {
> > > > > > 
> > > > > >  #define V4L2_PIX_FMT_HM12    v4l2_fourcc('H', 'M', '1', '2') /*  8
> > > > > >  YUV
> > > > > > 
> > > > > > 4:2:0 16x16 macroblocks */ #define V4L2_PIX_FMT_M420
> > > > > > v4l2_fourcc('M', '4', '2', '0') /* 12  YUV 4:2:0 2 lines y, 1 line
> > > > > > uv interleaved */
> > > > > > 
> > > > > > +/* Chrominance formats */
> > > > > > +#define V4L2_PIX_FMT_UV8      v4l2_fourcc('U', 'V', '8', ' ') /* 
> > > > > > 8 UV 4:4 */ +
> > > > > > 
> > > > > >  /* two planes -- one Y, one Cr + Cb interleaved  */
> > > > > >  #define V4L2_PIX_FMT_NV12    v4l2_fourcc('N', 'V', '1', '2') /* 12
> > > > > >  Y/CbCr
> > > > > > 
> > > > > > 4:2:0  */ #define V4L2_PIX_FMT_NV21    v4l2_fourcc('N', 'V', '2',
> > > > > > '1') /* 12  Y/CrCb 4:2:0  */ @@ -366,6 +369,9 @@ struct
> > > > > > v4l2_pix_format { #define V4L2_PIX_FMT_SRGGB12 v4l2_fourcc('R',
> > > > > > 'G', '1', '2') /* 12 RGRG.. GBGB.. */ /* 10bit raw bayer DPCM
> > > > > > compressed to 8 bits */ #define V4L2_PIX_FMT_SGRBG10DPCM8
> > > > > > v4l2_fourcc('B', 'D', '1', '0')
> > > > > > +	/* 10bit raw bayer a-law compressed to 8 bits */ #define
> > > > > > +V4L2_PIX_FMT_SGRBG10ALAW8 v4l2_fourcc('A', 'L', 'W', '8')
> > > > > > +
> > > > > 
> > > > > That's not very future-proof, how would you describe SGBRG10ALAW8
> > > > > for instance ?
> > > > > 
> > > > > Maybe it's time to standardize FOURCCs for Bayer new formats. We
> > > > > have 4 characters, we could start with 'B' to denote Bayer, followed
> > > > > by one character for the order, one for the compression, and one for
> > > > > the number of bits.
> > > > 
> > > > I agree.
> > > > May be ('B', 'G', 'A', '8') is fine for the above?
> > > 
> > > We need to describe at last BGGR, GBRG, GRBG and RGGB. We could use 'B',
> > > 'g', 'G' and 'R' respectively for the second character. The third
> > > character would be 'A' for A-law and 'D' for DPCM, and the fourth
> > > character could describe the bus width in bits from 0 to 15 with '0' -
> > > '9', 'A' - 'F'. However, I suspect that we will need 16-bit wide busses
> > > for raw Bayer at some point, and a 0 width is definitely not useful. We
> > > could thus offset the width by some value.
> > > 
> > > This is just a preliminary idea, I'm open to suggestions.
> > 
> > I think it is a very good suggestion that we can go with.
> > B : BGGR
> > g : GBRG
> > G : GRBG
> > R : RGGB
> > 
> > and 0-F can signify 1-16.
> 
> Hans, Guennadi, Sakari, any opinion on that as well ?

I think four letters simply aren't enough to universally describe a media
bus format in a human-readable way. We can aim to that, but we will have to
make compromises.

For example, DPCM compressed format has two important parameters beyond
pixel order and the colour space, the uncompressed depth and the compressed
depth. Typically one doesn't compress the data too much, but things like
10-to-6 bits are well possible.

Could we use a single letter to tell that a format is both bayer and DPCM
compressed? I'd go for 'b'. Raw bayer alaw could be denoted by 'a'.

Then raw bayer, GBRG pixel order 10-to-7 bits would be called "bgA7". The
same in Alaw would be "agA7".

What do you think?

-- 
Sakari Ailus
e-mail: sakari.ailus@iki.fi	jabber/XMPP/Gmail: sailus@retiisi.org.uk

Re: [PATCH 2/2] v4l2: add new pixel formats supported on dm365

[Laurent Pinchart]

Hi Sakari,

On Wednesday 28 December 2011 12:16:27 Sakari Ailus wrote:
> On Wed, Dec 21, 2011 at 11:23:26PM +0100, Laurent Pinchart wrote:
> > On Wednesday 21 December 2011 14:56:36 Hadli, Manjunath wrote:
> > > On Wed, Dec 21, 2011 at 05:32:08, Laurent Pinchart wrote:
> > > > On Friday 16 December 2011 14:42:48 Hadli, Manjunath wrote:
> > > > > On Thu, Dec 15, 2011 at 18:30:47, Laurent Pinchart wrote:
> > > > > > On Thursday 15 December 2011 13:24:58 Manjunath Hadli wrote:
> > > > > > > add new macro V4L2_PIX_FMT_SGRBG10ALAW8 to represent Bayer
> > > > > > > format frames compressed by A-LAW alogorithm.
> > > > > > > add V4L2_PIX_FMT_UV8 to represent storage of C (UV interleved)
> > > > > > > only.
> > > > > > > 
> > > > > > > Signed-off-by: Manjunath Hadli <manjunath.hadli@ti.com>
> > > > > > > Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> > > > > > > ---
> > > > > > > 
> > > > > > >  include/linux/videodev2.h |    6 ++++++
> > > > > > >  1 files changed, 6 insertions(+), 0 deletions(-)
> > > > > > 
> > > > > > Could you please also document these formats in
> > > > > > Documentation/DocBook/media/v4l ?
> > > > > 
> > > > > I will. Sorry to have missed that out.
> > > > > 
> > > > > > > diff --git a/include/linux/videodev2.h
> > > > > > > b/include/linux/videodev2.h index 4b752d5..969112d 100644
> > > > > > > --- a/include/linux/videodev2.h
> > > > > > > +++ b/include/linux/videodev2.h
> > > > > > > @@ -338,6 +338,9 @@ struct v4l2_pix_format {
> > > > > > > 
> > > > > > >  #define V4L2_PIX_FMT_HM12    v4l2_fourcc('H', 'M', '1', '2')
> > > > > > >  /*  8 YUV
> > > > > > > 
> > > > > > > 4:2:0 16x16 macroblocks */ #define V4L2_PIX_FMT_M420
> > > > > > > v4l2_fourcc('M', '4', '2', '0') /* 12  YUV 4:2:0 2 lines y, 1
> > > > > > > line uv interleaved */
> > > > > > > 
> > > > > > > +/* Chrominance formats */
> > > > > > > +#define V4L2_PIX_FMT_UV8      v4l2_fourcc('U', 'V', '8', ' ')
> > > > > > > /* 8 UV 4:4 */ +
> > > > > > > 
> > > > > > >  /* two planes -- one Y, one Cr + Cb interleaved  */
> > > > > > >  #define V4L2_PIX_FMT_NV12    v4l2_fourcc('N', 'V', '1', '2')
> > > > > > >  /* 12 Y/CbCr
> > > > > > > 
> > > > > > > 4:2:0  */ #define V4L2_PIX_FMT_NV21    v4l2_fourcc('N', 'V',
> > > > > > > '2', '1') /* 12  Y/CrCb 4:2:0  */ @@ -366,6 +369,9 @@ struct
> > > > > > > v4l2_pix_format { #define V4L2_PIX_FMT_SRGGB12
> > > > > > > v4l2_fourcc('R', 'G', '1', '2') /* 12 RGRG.. GBGB.. */ /*
> > > > > > > 10bit raw bayer DPCM compressed to 8 bits */ #define
> > > > > > > V4L2_PIX_FMT_SGRBG10DPCM8 v4l2_fourcc('B', 'D', '1', '0')
> > > > > > > +	/* 10bit raw bayer a-law compressed to 8 bits */ #define
> > > > > > > +V4L2_PIX_FMT_SGRBG10ALAW8 v4l2_fourcc('A', 'L', 'W', '8')
> > > > > > > +
> > > > > > 
> > > > > > That's not very future-proof, how would you describe SGBRG10ALAW8
> > > > > > for instance ?
> > > > > > 
> > > > > > Maybe it's time to standardize FOURCCs for Bayer new formats. We
> > > > > > have 4 characters, we could start with 'B' to denote Bayer,
> > > > > > followed by one character for the order, one for the
> > > > > > compression, and one for the number of bits.
> > > > > 
> > > > > I agree.
> > > > > May be ('B', 'G', 'A', '8') is fine for the above?
> > > > 
> > > > We need to describe at last BGGR, GBRG, GRBG and RGGB. We could use
> > > > 'B', 'g', 'G' and 'R' respectively for the second character. The
> > > > third character would be 'A' for A-law and 'D' for DPCM, and the
> > > > fourth character could describe the bus width in bits from 0 to 15
> > > > with '0' - '9', 'A' - 'F'. However, I suspect that we will need
> > > > 16-bit wide busses for raw Bayer at some point, and a 0 width is
> > > > definitely not useful. We could thus offset the width by some value.
> > > > 
> > > > This is just a preliminary idea, I'm open to suggestions.
> > > 
> > > I think it is a very good suggestion that we can go with.
> > > B : BGGR
> > > g : GBRG
> > > G : GRBG
> > > R : RGGB
> > > 
> > > and 0-F can signify 1-16.
> > 
> > Hans, Guennadi, Sakari, any opinion on that as well ?
> 
> I think four letters simply aren't enough to universally describe a media
> bus format in a human-readable way. We can aim to that, but we will have to
> make compromises.
> 
> For example, DPCM compressed format has two important parameters beyond
> pixel order and the colour space, the uncompressed depth and the compressed
> depth. Typically one doesn't compress the data too much, but things like
> 10-to-6 bits are well possible.
> 
> Could we use a single letter to tell that a format is both bayer and DPCM
> compressed? I'd go for 'b'. Raw bayer alaw could be denoted by 'a'.
> 
> Then raw bayer, GBRG pixel order 10-to-7 bits would be called "bgA7". The
> same in Alaw would be "agA7".
> 
> What do you think?

We can't come up with a naming scheme that will handle all possible 
combinations. I'm fine as long as the names we select have some kind of 
structure and handle the raw patterns currently available. I'd still like to 
hear Hans' opinion on this.

-- 
Regards,

Laurent Pinchart

RE: [PATCH 2/2] v4l2: add new pixel formats supported on dm365

[Hadli, Manjunath]

All,

On Mon, Jan 02, 2012 at 16:51:06, Laurent Pinchart wrote:
> Hi Sakari,
> 
> On Wednesday 28 December 2011 12:16:27 Sakari Ailus wrote:
> > On Wed, Dec 21, 2011 at 11:23:26PM +0100, Laurent Pinchart wrote:
> > > On Wednesday 21 December 2011 14:56:36 Hadli, Manjunath wrote:
> > > > On Wed, Dec 21, 2011 at 05:32:08, Laurent Pinchart wrote:
> > > > > On Friday 16 December 2011 14:42:48 Hadli, Manjunath wrote:
> > > > > > On Thu, Dec 15, 2011 at 18:30:47, Laurent Pinchart wrote:
> > > > > > > On Thursday 15 December 2011 13:24:58 Manjunath Hadli wrote:
> > > > > > > > add new macro V4L2_PIX_FMT_SGRBG10ALAW8 to represent Bayer 
> > > > > > > > format frames compressed by A-LAW alogorithm.
> > > > > > > > add V4L2_PIX_FMT_UV8 to represent storage of C (UV 
> > > > > > > > interleved) only.
> > > > > > > > 
> > > > > > > > Signed-off-by: Manjunath Hadli <manjunath.hadli@ti.com>
> > > > > > > > Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> > > > > > > > ---
> > > > > > > > 
> > > > > > > >  include/linux/videodev2.h |    6 ++++++
> > > > > > > >  1 files changed, 6 insertions(+), 0 deletions(-)
> > > > > > > 
> > > > > > > Could you please also document these formats in 
> > > > > > > Documentation/DocBook/media/v4l ?
> > > > > > 
> > > > > > I will. Sorry to have missed that out.
> > > > > > 
> > > > > > > > diff --git a/include/linux/videodev2.h 
> > > > > > > > b/include/linux/videodev2.h index 4b752d5..969112d 100644
> > > > > > > > --- a/include/linux/videodev2.h
> > > > > > > > +++ b/include/linux/videodev2.h
> > > > > > > > @@ -338,6 +338,9 @@ struct v4l2_pix_format {
> > > > > > > > 
> > > > > > > >  #define V4L2_PIX_FMT_HM12    v4l2_fourcc('H', 'M', '1', '2')
> > > > > > > >  /*  8 YUV
> > > > > > > > 
> > > > > > > > 4:2:0 16x16 macroblocks */ #define V4L2_PIX_FMT_M420 
> > > > > > > > v4l2_fourcc('M', '4', '2', '0') /* 12  YUV 4:2:0 2 lines 
> > > > > > > > y, 1 line uv interleaved */
> > > > > > > > 
> > > > > > > > +/* Chrominance formats */
> > > > > > > > +#define V4L2_PIX_FMT_UV8      v4l2_fourcc('U', 'V', '8', ' ')
> > > > > > > > /* 8 UV 4:4 */ +
> > > > > > > > 
> > > > > > > >  /* two planes -- one Y, one Cr + Cb interleaved  */
> > > > > > > >  #define V4L2_PIX_FMT_NV12    v4l2_fourcc('N', 'V', '1', '2')
> > > > > > > >  /* 12 Y/CbCr
> > > > > > > > 
> > > > > > > > 4:2:0  */ #define V4L2_PIX_FMT_NV21    v4l2_fourcc('N', 'V',
> > > > > > > > '2', '1') /* 12  Y/CrCb 4:2:0  */ @@ -366,6 +369,9 @@ 
> > > > > > > > struct v4l2_pix_format { #define V4L2_PIX_FMT_SRGGB12 
> > > > > > > > v4l2_fourcc('R', 'G', '1', '2') /* 12 RGRG.. GBGB.. */ /* 
> > > > > > > > 10bit raw bayer DPCM compressed to 8 bits */ #define
> > > > > > > > V4L2_PIX_FMT_SGRBG10DPCM8 v4l2_fourcc('B', 'D', '1', '0')
> > > > > > > > +	/* 10bit raw bayer a-law compressed to 8 bits */ #define
> > > > > > > > +V4L2_PIX_FMT_SGRBG10ALAW8 v4l2_fourcc('A', 'L', 'W', '8')
> > > > > > > > +
> > > > > > > 
> > > > > > > That's not very future-proof, how would you describe 
> > > > > > > SGBRG10ALAW8 for instance ?
> > > > > > > 
> > > > > > > Maybe it's time to standardize FOURCCs for Bayer new 
> > > > > > > formats. We have 4 characters, we could start with 'B' to 
> > > > > > > denote Bayer, followed by one character for the order, one 
> > > > > > > for the compression, and one for the number of bits.
> > > > > > 
> > > > > > I agree.
> > > > > > May be ('B', 'G', 'A', '8') is fine for the above?
> > > > > 
> > > > > We need to describe at last BGGR, GBRG, GRBG and RGGB. We could 
> > > > > use 'B', 'g', 'G' and 'R' respectively for the second character. 
> > > > > The third character would be 'A' for A-law and 'D' for DPCM, and 
> > > > > the fourth character could describe the bus width in bits from 0 
> > > > > to 15 with '0' - '9', 'A' - 'F'. However, I suspect that we will 
> > > > > need 16-bit wide busses for raw Bayer at some point, and a 0 
> > > > > width is definitely not useful. We could thus offset the width by some value.
> > > > > 
> > > > > This is just a preliminary idea, I'm open to suggestions.
> > > > 
> > > > I think it is a very good suggestion that we can go with.
> > > > B : BGGR
> > > > g : GBRG
> > > > G : GRBG
> > > > R : RGGB
> > > > 
> > > > and 0-F can signify 1-16.
> > > 
> > > Hans, Guennadi, Sakari, any opinion on that as well ?
> > 
> > I think four letters simply aren't enough to universally describe a 
> > media bus format in a human-readable way. We can aim to that, but we 
> > will have to make compromises.
> > 
> > For example, DPCM compressed format has two important parameters 
> > beyond pixel order and the colour space, the uncompressed depth and 
> > the compressed depth. Typically one doesn't compress the data too 
> > much, but things like
> > 10-to-6 bits are well possible.
> > 
> > Could we use a single letter to tell that a format is both bayer and 
> > DPCM compressed? I'd go for 'b'. Raw bayer alaw could be denoted by 'a'.
> > 
> > Then raw bayer, GBRG pixel order 10-to-7 bits would be called "bgA7". 
> > The same in Alaw would be "agA7".
> > 
> > What do you think?
> 
> We can't come up with a naming scheme that will handle all possible combinations. I'm fine as long as the names we select have some kind of structure and handle the raw patterns currently available. I'd still like to hear Hans' opinion on this.
Since we agree that the scheme will not be able to cover the spectrum 
In the level of detail which we would like to, I think we should go with the 
Above discussed scheme which seems logical. I will send out a detailed patch 
With added documentation.


Thx,
-Manju

> 
> --
> Regards,
> 
> Laurent Pinchart
> 

Re: [PATCH 2/2] v4l2: add new pixel formats supported on dm365

[Laurent Pinchart]

Hi Manjunath,

On Tuesday 17 January 2012 07:59:35 Hadli, Manjunath wrote:
> On Mon, Jan 02, 2012 at 16:51:06, Laurent Pinchart wrote:
> > On Wednesday 28 December 2011 12:16:27 Sakari Ailus wrote:
> > > On Wed, Dec 21, 2011 at 11:23:26PM +0100, Laurent Pinchart wrote:
> > > > On Wednesday 21 December 2011 14:56:36 Hadli, Manjunath wrote:
> > > > > On Wed, Dec 21, 2011 at 05:32:08, Laurent Pinchart wrote:
> > > > > > On Friday 16 December 2011 14:42:48 Hadli, Manjunath wrote:
> > > > > > > On Thu, Dec 15, 2011 at 18:30:47, Laurent Pinchart wrote:
> > > > > > > > On Thursday 15 December 2011 13:24:58 Manjunath Hadli wrote:
> > > > > > > > > add new macro V4L2_PIX_FMT_SGRBG10ALAW8 to represent Bayer
> > > > > > > > > format frames compressed by A-LAW alogorithm.
> > > > > > > > > add V4L2_PIX_FMT_UV8 to represent storage of C (UV
> > > > > > > > > interleved) only.
> > > > > > > > > 
> > > > > > > > > Signed-off-by: Manjunath Hadli <manjunath.hadli@ti.com>
> > > > > > > > > Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> > > > > > > > > ---
> > > > > > > > > 
> > > > > > > > >  include/linux/videodev2.h |    6 ++++++
> > > > > > > > >  1 files changed, 6 insertions(+), 0 deletions(-)
> > > > > > > > 
> > > > > > > > Could you please also document these formats in
> > > > > > > > Documentation/DocBook/media/v4l ?
> > > > > > > 
> > > > > > > I will. Sorry to have missed that out.
> > > > > > > 
> > > > > > > > > diff --git a/include/linux/videodev2.h
> > > > > > > > > b/include/linux/videodev2.h index 4b752d5..969112d 100644
> > > > > > > > > --- a/include/linux/videodev2.h
> > > > > > > > > +++ b/include/linux/videodev2.h
> > > > > > > > > @@ -338,6 +338,9 @@ struct v4l2_pix_format {
> > > > > > > > > 
> > > > > > > > >  #define V4L2_PIX_FMT_HM12    v4l2_fourcc('H', 'M', '1',
> > > > > > > > >  '2') /*  8 YUV
> > > > > > > > > 
> > > > > > > > > 4:2:0 16x16 macroblocks */ #define V4L2_PIX_FMT_M420
> > > > > > > > > v4l2_fourcc('M', '4', '2', '0') /* 12  YUV 4:2:0 2 lines
> > > > > > > > > y, 1 line uv interleaved */
> > > > > > > > > 
> > > > > > > > > +/* Chrominance formats */
> > > > > > > > > +#define V4L2_PIX_FMT_UV8      v4l2_fourcc('U', 'V', '8', '
> > > > > > > > > ') /* 8 UV 4:4 */ +
> > > > > > > > > 
> > > > > > > > >  /* two planes -- one Y, one Cr + Cb interleaved  */
> > > > > > > > >  #define V4L2_PIX_FMT_NV12    v4l2_fourcc('N', 'V', '1',
> > > > > > > > >  '2') /* 12 Y/CbCr
> > > > > > > > > 
> > > > > > > > > 4:2:0  */ #define V4L2_PIX_FMT_NV21    v4l2_fourcc('N',
> > > > > > > > > 'V', '2', '1') /* 12  Y/CrCb 4:2:0  */ @@ -366,6 +369,9 @@
> > > > > > > > > struct v4l2_pix_format { #define V4L2_PIX_FMT_SRGGB12
> > > > > > > > > v4l2_fourcc('R', 'G', '1', '2') /* 12 RGRG.. GBGB.. */ /*
> > > > > > > > > 10bit raw bayer DPCM compressed to 8 bits */ #define
> > > > > > > > > V4L2_PIX_FMT_SGRBG10DPCM8 v4l2_fourcc('B', 'D', '1', '0')
> > > > > > > > > +	/* 10bit raw bayer a-law compressed to 8 bits */ #define
> > > > > > > > > +V4L2_PIX_FMT_SGRBG10ALAW8 v4l2_fourcc('A', 'L', 'W', '8')
> > > > > > > > > +
> > > > > > > > 
> > > > > > > > That's not very future-proof, how would you describe
> > > > > > > > SGBRG10ALAW8 for instance ?
> > > > > > > > 
> > > > > > > > Maybe it's time to standardize FOURCCs for Bayer new
> > > > > > > > formats. We have 4 characters, we could start with 'B' to
> > > > > > > > denote Bayer, followed by one character for the order, one
> > > > > > > > for the compression, and one for the number of bits.
> > > > > > > 
> > > > > > > I agree.
> > > > > > > May be ('B', 'G', 'A', '8') is fine for the above?
> > > > > > 
> > > > > > We need to describe at last BGGR, GBRG, GRBG and RGGB. We could
> > > > > > use 'B', 'g', 'G' and 'R' respectively for the second character.
> > > > > > The third character would be 'A' for A-law and 'D' for DPCM, and
> > > > > > the fourth character could describe the bus width in bits from 0
> > > > > > to 15 with '0' - '9', 'A' - 'F'. However, I suspect that we will
> > > > > > need 16-bit wide busses for raw Bayer at some point, and a 0
> > > > > > width is definitely not useful. We could thus offset the width by
> > > > > > some value.
> > > > > > 
> > > > > > This is just a preliminary idea, I'm open to suggestions.
> > > > > 
> > > > > I think it is a very good suggestion that we can go with.
> > > > > B : BGGR
> > > > > g : GBRG
> > > > > G : GRBG
> > > > > R : RGGB
> > > > > 
> > > > > and 0-F can signify 1-16.
> > > > 
> > > > Hans, Guennadi, Sakari, any opinion on that as well ?
> > > 
> > > I think four letters simply aren't enough to universally describe a
> > > media bus format in a human-readable way. We can aim to that, but we
> > > will have to make compromises.
> > > 
> > > For example, DPCM compressed format has two important parameters
> > > beyond pixel order and the colour space, the uncompressed depth and
> > > the compressed depth. Typically one doesn't compress the data too
> > > much, but things like
> > > 10-to-6 bits are well possible.
> > > 
> > > Could we use a single letter to tell that a format is both bayer and
> > > DPCM compressed? I'd go for 'b'. Raw bayer alaw could be denoted by
> > > 'a'.
> > > 
> > > Then raw bayer, GBRG pixel order 10-to-7 bits would be called "bgA7".
> > > The same in Alaw would be "agA7".
> > > 
> > > What do you think?
> > 
> > We can't come up with a naming scheme that will handle all possible
> > combinations. I'm fine as long as the names we select have some kind of
> > structure and handle the raw patterns currently available. I'd still
> > like to hear Hans' opinion on this.
> 
> Since we agree that the scheme will not be able to cover the spectrum
> In the level of detail which we would like to, I think we should go with
> the Above discussed scheme which seems logical. I will send out a detailed
> patch With added documentation.

Please also see http://www.spinics.net/lists/linux-media/msg43192.html.

-- 
Regards,

Laurent Pinchart