From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from perceval.ideasonboard.com ([95.142.166.194]:57504 "EHLO perceval.ideasonboard.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751041Ab2G3TG2 (ORCPT ); Mon, 30 Jul 2012 15:06:28 -0400 From: Laurent Pinchart To: davinci-linux-open-source@linux.davincidsp.com Cc: Hans Verkuil , Sakari Ailus , LMML , Guennadi Liakhovetski Subject: Re: [PATCH v7 1/2] media: add new mediabus format enums for dm365 Date: Mon, 30 Jul 2012 21:06:33 +0200 Message-ID: <1527741.DUREJZiXMg@avalon> In-Reply-To: <201207302036.36180.hverkuil@xs4all.nl> References: <1343386505-8695-1-git-send-email-prabhakar.lad@ti.com> <20120727220124.GC26642@valkosipuli.retiisi.org.uk> <201207302036.36180.hverkuil@xs4all.nl> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Sender: linux-media-owner@vger.kernel.org List-ID: 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 > > > > > > 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 > > > Acked-by: Hans Verkuil > > > Signed-off-by: Manjunath Hadli > > > Signed-off-by: Lad, Prabhakar > > > Cc: Sakari Ailus > > > Cc: Guennadi Liakhovetski > > > --- > > > > > > 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 @@ > > > > > > The number of bits per pixel component. All components > > > are > > > transferred on the same number of bits. Common values are 8, 10 and > > > 12. > > > > > > - If the pixel components are DPCM-compressed, a mention > > > of the - DPCM compression and the number of bits per compressed pixel > > > component. - > > > + The 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. > > > > > > 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. > > > > > > @@ -504,6 +504,74 @@ > > > > > > r1 > > > r0 > > > > > > > > > > > > + > > > + V4L2_MBUS_FMT_SBGGR10_ALAW8_1X8 > > > + 0x3015 > > > + > > > + - > > > + - > > > + - > > > + - > > > + b7 > > > + b6 > > > + b5 > > > + b4 > > > + b3 > > > + b2 > > > + b1 > > > + b0 > > > + > > > + > > > + V4L2_MBUS_FMT_SGBRG10_ALAW8_1X8 > > > + 0x3016 > > > + > > > + - > > > + - > > > + - > > > + - > > > + g7 > > > + g6 > > > + g5 > > > + g4 > > > + g3 > > > + g2 > > > + g1 > > > + g0 > > > + > > > + > > > + V4L2_MBUS_FMT_SGRBG10_ALAW8_1X8 > > > + 0x3017 > > > + > > > + - > > > + - > > > + - > > > + - > > > + g7 > > > + g6 > > > + g5 > > > + g4 > > > + g3 > > > + g2 > > > + g1 > > > + g0 > > > + > > > + > > > + V4L2_MBUS_FMT_SRGGB10_ALAW8_1X8 > > > + 0x3018 > > > + > > > + - > > > + - > > > + - > > > + - > > > + r7 > > > + r6 > > > + r5 > > > + r4 > > > + r3 > > > + r2 > > > + r1 > > > + r0 > > > + > > > > > > > > > > > > V4L2_MBUS_FMT_SBGGR10_DPCM8_1X8 > > > 0x300b > > > > > > @@ -853,10 +921,16 @@ > > > > > > Packed YUV Formats > > > > > > Those data formats transfer pixel data as (possibly > > > downsampled) Y, U > > > > > > - and V components. The format code is made of the following > > > information. + 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. + > > > + The format code is made of the following information. > > > > > > > > > > > > The Y, U and V components order code, as transferred > > > on the > > > > > > - bus. Possible values are YUYV, UYVY, YVYU and VYUY. > > > + bus. Possible values are YUYV, UYVY, YVYU and VYUY for formats with no > > > + dummy bit, and YDYUYDYV, YDYVYDYU, YUYDYVYD and YVYDYUYD for YDYC > > > formats. + > > > > > > The number of bits per pixel component. All components > > > are > > > transferred on the same number of bits. Common values are 8, 10 and > > > 12. > > > > 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