linux-media.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sascha Hauer <s.hauer@pengutronix.de>
To: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Cc: Robert Jarzmik <robert.jarzmik@free.fr>,
	Linux Media Mailing List <linux-media@vger.kernel.org>
Subject: Re: mt9m111 swap_rgb_red_blue
Date: Mon, 31 May 2010 09:54:25 +0200	[thread overview]
Message-ID: <20100531075424.GD26820@pengutronix.de> (raw)
In-Reply-To: <Pine.LNX.4.64.1005310842160.16053@axis700.grange>

On Mon, May 31, 2010 at 08:46:00AM +0200, Guennadi Liakhovetski wrote:
> On Mon, 31 May 2010, Robert Jarzmik wrote:
> 
> > Sascha Hauer <s.hauer@pengutronix.de> writes:
> > 
> > > Hi Robert,
> > >
> > > I have digged around in the Datasheet and if I understand it correctly
> > > the PXA swaps red/blue in RGB mode. So if we do not use rgb mode but yuv
> > > (which should be a pass through) we should be able to support rgb on PXA
> > > aswell. Robert, can you confirm that with the following patch applied
> > > you still get an image but with red/blue swapped?
> > I can confirm the color swap.
> > If you want to follow that path, I would suggest instead :
> >    cicr1 |= CICR1_COLOR_SP_VAL(0);
> > 
> > There is no difference from a processing point of view, it's just that
> > CICR1_COLOR_SP_VAL(0) is "raw colorspace", with means "pass through", and that
> > seems to be your goal here.
> 
> That would be the default case in that switch, but raw only supports 8, 9, 
> or 10 bpp, so, you'd have to use 8bpp but then fake the pixels-per-line 
> field.

That's why I suggested yuv. I could leave a big comment why this is
done, but I would implement it using raw mode aswell if that's prefered.

> But that would be the cleanest way, yes. Would that work like that?
> 
> > Note that the patch would have to be completed with the BGR565 into RGB565
> > conversion, if the sensor was to provide only BGR565. But that could very well
> > be for another patch.

Will do, I just wanted to see if this works at all.

Sascha


-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

      reply	other threads:[~2010-05-31  7:54 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-26 14:18 mt9m111 swap_rgb_red_blue Sascha Hauer
     [not found] ` <87bpc2za9i.fsf@free.fr>
2010-05-27  8:04   ` Sascha Hauer
2010-05-27  9:45   ` Guennadi Liakhovetski
2010-05-27 11:18     ` Sascha Hauer
2010-05-28  6:27   ` Sascha Hauer
2010-05-30 22:52     ` Robert Jarzmik
2010-05-31  6:46       ` Guennadi Liakhovetski
2010-05-31  7:54         ` Sascha Hauer [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=20100531075424.GD26820@pengutronix.de \
    --to=s.hauer@pengutronix.de \
    --cc=g.liakhovetski@gmx.de \
    --cc=linux-media@vger.kernel.org \
    --cc=robert.jarzmik@free.fr \
    /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).