From patchwork Wed Jul 18 11:05:18 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Laurent Pinchart X-Patchwork-Id: 1210421 Return-Path: X-Original-To: patchwork-linux-media@patchwork.kernel.org Delivered-To: patchwork-process-083081@patchwork2.kernel.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by patchwork2.kernel.org (Postfix) with ESMTP id 30C5FDFFFD for ; Wed, 18 Jul 2012 11:05:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752367Ab2GRLFP (ORCPT ); Wed, 18 Jul 2012 07:05:15 -0400 Received: from perceval.ideasonboard.com ([95.142.166.194]:46608 "EHLO perceval.ideasonboard.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752009Ab2GRLFO (ORCPT ); Wed, 18 Jul 2012 07:05:14 -0400 Received: from avalon.localnet (unknown [91.178.171.146]) by perceval.ideasonboard.com (Postfix) with ESMTPSA id 77EE7359D1; Wed, 18 Jul 2012 13:05:12 +0200 (CEST) From: Laurent Pinchart To: "Hadli, Manjunath" Cc: dlos , LMML , Sakari Ailus , Hans Verkuil Subject: Re: [PATCH v4 1/2] media: add new mediabus format enums for dm365 Date: Wed, 18 Jul 2012 13:05:18 +0200 Message-ID: <41958950.qGmmsSpAPM@avalon> User-Agent: KMail/4.8.3 (Linux/3.3.8-gentoo; KDE/4.8.3; x86_64; ; ) In-Reply-To: References: <1333102154-24657-1-git-send-email-manjunath.hadli@ti.com> <1521995.bdrhyBupKO@avalon> MIME-Version: 1.0 Sender: linux-media-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-media@vger.kernel.org Hi Manjunath, On Tuesday 17 July 2012 12:22:42 Hadli, Manjunath wrote: > On Tue, Jul 17, 2012 at 17:25:42, Laurent Pinchart wrote: > > On Tuesday 17 July 2012 11:41:11 Hadli, Manjunath wrote: > > > On Tue, Jul 17, 2012 at 16:26:24, Laurent Pinchart wrote: > > > > On Friday 30 March 2012 10:09:13 Hadli, Manjunath wrote: > > > > > add new enum entries for supporting the media-bus formats on dm365. > > > > > These include some bayer and some non-bayer formats. > > > > > V4L2_MBUS_FMT_YDYC8_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. > > > > > > > > > > Signed-off-by: Manjunath Hadli > > > > > Cc: Laurent Pinchart > > > > > Cc: Sakari Ailus > > > > > Cc: Hans Verkuil > > > > > --- > > > > > > > > > > Documentation/DocBook/media/v4l/subdev-formats.xml | 171 > > > > > ++++++++++++ > > > > > include/linux/v4l2-mediabus.h | 10 +- > > > > > 2 files changed, 179 insertions(+), 2 deletions(-) > > > > > > > > > > diff --git a/Documentation/DocBook/media/v4l/subdev-formats.xml > > > > > b/Documentation/DocBook/media/v4l/subdev-formats.xml index > > > > > 49c532e..48d92bb > > > > > 100644 > > > > > --- a/Documentation/DocBook/media/v4l/subdev-formats.xml > > > > > +++ b/Documentation/DocBook/media/v4l/subdev-formats.xml > > > > [snip] > > > > > > > @@ -965,6 +1036,56 @@ > > > > > > > > > > y1 > > > > > y0 > > > > > > > > > > > > > > > > > > > > + > > > > > > > > That's a weird one. Just out of curiosity, what's the point of > > > > transferring chroma information without luma ? > > > > > > DM365 supports this format. > > > > Right, but what is it used for ? > > Sorry about that. The Resizer in Dm365 can take only chroma and resize the > buffer. It can also take luma of course. In general it can take UV8, Y8 and > also UYVY. So UV8 is used to resize an NV buffer in two passes (first Y8 then UV8) ? > > [snip] > > > > > > > @@ -2415,6 +2536,56 @@ > > > > > > > > > > u1 > > > > > u0 > > > > > > > > > > > > > > > > > > > > + > > > > > > > > What is this beast ? We at least need a textual description, as I have > > > > no > > > > idea what the format corresponds to. > > > > > > This was discussed earlier over here > > > http://patchwork.linuxtv.org/patch/8843/ > > > > My bad, I should have remembered that. Please add a textual description of > > the format, it's not clear from the name what D and C are. > > I see no description for individual MBUS formats but a collective para on > everything together. Would you like me to add in the same or otherwise can > you point to me where I can add this description? What about the following patch ? Note that I've renamed YDYC to YDYU, as we might later need a YDYV format. (Hans, Sakari, any opinion ?) diff --git a/Documentation/DocBook/media/v4l/subdev-formats.xml b/Documentation/DocBook/media/v4l/subdev-formats.xml index 49c532e..47a485e 100644 --- a/Documentation/DocBook/media/v4l/subdev-formats.xml +++ b/Documentation/DocBook/media/v4l/subdev-formats.xml @@ -853,10 +853,15 @@ 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. + + + 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 YDYU, YDYV, YUYD and YVYD 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. @@ -877,7 +882,21 @@ U, Y, V, Y order will be named V4L2_MBUS_FMT_UYVY8_2X8. - The following table lisst existing packet YUV formats. + 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. + + The role of each bit transferred over the bus is identified by one + of the following codes. + + + yx for luma component bit number x + ux for blue chroma component bit number x + vx for red chroma component bit number x + - for non-available bits (for positions higher than the bus width) + / for dummy bits + YUV Formats @@ -2415,6 +2434,106 @@ u1u0 + + V4L2_MBUS_FMT_YDYU8_1X16 + 0x2014 + + - + - + - + - + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + / + / + / + / + / + / + / + / + + + + + + - + - + - + - + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + u7 + u6 + u5 + u4 + u3 + u2 + u1 + u0 + + + + + + - + - + - + - + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + / + / + / + / + / + / + / + / + + + + + + - + - + - + - + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + v7 + v6 + v5 + v4 + v3 + v2 + v1 + v0 + V4L2_MBUS_FMT_YUYV10_1X20 0x200d