linux-media.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Sylwester Nawrocki <s.nawrocki@samsung.com>
Cc: Hans Verkuil <hverkuil@xs4all.nl>, linux-media@vger.kernel.org
Subject: Re: [PATCH] v4l: Clarify RGB666 pixel format definition
Date: Tue, 10 Nov 2015 00:21:13 +0200	[thread overview]
Message-ID: <1467109.0hyysKvb3u@avalon> (raw)
In-Reply-To: <4301993.tc7nBMPXQH@avalon>

Hi Sylwester,

Reviving a "slightly" old discussion.

On Wednesday 29 October 2014 13:45:46 Laurent Pinchart wrote:
> On Tuesday 09 September 2014 16:45:17 Sylwester Nawrocki wrote:
> > On 09/09/14 15:18, Laurent Pinchart wrote:
> >> On Tuesday 22 July 2014 00:44:34 Hans Verkuil wrote:
> >>> On 07/22/2014 12:30 AM, Laurent Pinchart wrote:
> >>>> On Monday 21 July 2014 23:43:16 Hans Verkuil wrote:
> >>>>> On 07/21/2014 10:39 PM, Laurent Pinchart wrote:
> >>>>>> The RGB666 pixel format doesn't include an alpha channel. Document
> >>>>>> it as such.
> >>>>>> 
> >>>>>> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> >>>>>> ---
> >>>>>> 
> >>>>>>  .../DocBook/media/v4l/pixfmt-packed-rgb.xml          | 20
> >>>>>>  ++++-------
> >>>>>> 
> >>>>>> 1 file changed, 6 insertions(+), 14 deletions(-)
> >>>>>> 
> >>>>>> diff --git a/Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml
> >>>>>> b/Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml index
> >>>>>> 32feac9..c47692a 100644
> >>>>>> --- a/Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml
> >>>>>> +++ b/Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml
> >>>>>> @@ -330,20 +330,12 @@ colorspace
> >>>>>> <constant>V4L2_COLORSPACE_SRGB</constant>.</para>
> >>>>>> 
> >>>>>>  	    <entry></entry>
> >>>>>>  	    <entry>r<subscript>1</subscript></entry>
> >>>>>>  	    <entry>r<subscript>0</subscript></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>
> >>>>>> +	    <entry>-</entry>
> >>>>>> +	    <entry>-</entry>
> >>>>>> +	    <entry>-</entry>
> >>>>>> +	    <entry>-</entry>
> >>>>>> +	    <entry>-</entry>
> >>>>> 
> >>>>> Just to clarify: BGR666 is a three byte format, not a four byte
> >>>>> format?

[snip]

> > My apologies, I didn't notice this earlier.
> > 
> > In case of S5P/Exynos FIMC the format is:
> > 
> > Byte 0   Byte 1   Byte 2   Byte 3
> > 
> > BBBBBBGG GGGGRRRR RR------ --------
> > 
> > i.e. 4 byte per pixel, with 14-bit padding (don't care bits).
> > 
> > As far as S3C6410 CAMIF is concerned it's hard to say. I primarily
> > developed the s3c-camif driver for S3C2440 SoC, which doesn't support
> > BGR666 format. I merged some patches from others adding s3c6410 support,
> > before sending upstream.
> > 
> > Nevertheless, looking at the S3C CAMIF datasheet the RGB666 format seems
> > identical with the FIMC one. See [1], chapter "20.7.4 MEMORY STORING
> > METHOD". This would make sense, since the S5P/Exynos FIMC is basically
> > a significantly evolved S3C CAMIF AFAICT.
> 
> Looking at the figure, I would understand RGB666 as follows
> 
> Bits 31     24|23         16|15                    8|7                     0
> ---- ----|---- -- R5 R4|R3 R2 R1 R0 G5 G4 G3 G2|G1 G0 B5 B4 B3 B2 B1 B0
> 
> Assuming little endian memory format, that would thus be
> 
> Byte 0   Byte 1   Byte 2   Byte 3
> 
> GGBBBBBB RRRRGGGG ------RR --------
> 
> If the memory format was big endian it would instead be
> 
> -------- ------RR RRRRGGGG GGBBBBBB
> 
> > [1] http://www.arm9board.net/download/OK6410/docs/S3C6410X.pdf

Did I understand something incorrectly ?

-- 
Regards,

Laurent Pinchart


      reply	other threads:[~2015-11-09 22:21 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-21 20:39 [PATCH] v4l: Clarify RGB666 pixel format definition Laurent Pinchart
2014-07-21 21:43 ` Hans Verkuil
2014-07-21 22:30   ` Laurent Pinchart
2014-07-21 22:44     ` Hans Verkuil
2014-09-09 13:18       ` Laurent Pinchart
2014-09-09 14:45         ` Sylwester Nawrocki
2014-10-29 11:45           ` Laurent Pinchart
2015-11-09 22:21             ` Laurent Pinchart [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1467109.0hyysKvb3u@avalon \
    --to=laurent.pinchart@ideasonboard.com \
    --cc=hverkuil@xs4all.nl \
    --cc=linux-media@vger.kernel.org \
    --cc=s.nawrocki@samsung.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).