linux-fbdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Christian Glindkamp <christian.glindkamp@taskit.de>
To: linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] atmel_lcdfb: support 16bit BGR:565 mode, remove
Date: Tue, 10 Jan 2012 13:01:46 +0000	[thread overview]
Message-ID: <20120110130146.GC2057@taskit.de> (raw)
In-Reply-To: <87ty45dt89.fsf@macbook.be.48ers.dk>

On 2012-01-09 12:13, Peter Korsgaard wrote:
> >>>>> "Nicolas" = Nicolas Ferre <nicolas.ferre@atmel.com> writes:
> 
>  Nicolas> On 10/13/2011 04:52 PM, Peter Korsgaard :
>  >> Allow framebuffer to be configured in 16bit mode when panel is wired in
>  >> (the default) BGR configuration, and don't claim to support 15bit input
>  >> modes, which the LCD controller cannot handle.
>  >> 
>  >> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
> 
>  Nicolas> Hi Peter,
> 
>  Nicolas> Sorry for not having more responsive concerning the two
>  Nicolas> patches that you posted about atmel_lcdfb driver.
> 
> No problem.
> 
>  Nicolas> I have a question though about this one...
> 
>  >> -		} else if (sinfo->lcd_wiring_mode = ATMEL_LCDC_WIRING_RGB555) {
>  >> -			var->red.offset = 10;
>  >> -			var->blue.offset = 0;
>  >> -			var->green.length = 5;
> 
>  Nicolas> Maybe I have missed something but I do not know why you are removing
>  Nicolas> this part of the configuration? A board at least is using this wiring
>  Nicolas> mode...
> 
> Because it is arguable wrong as far as I understand the HW.
> There's two parts here:
> 
> - 1: Format of framebuffer memory
> - 2: Wiring of LCD (RGB/BGR order and number of bits)
> 
> From the datasheet, the following framebuffer formats are supported:
> 
> 1, 2, 4, 8 bits per pixel (palletized), 16, 24 bits per pixel
> (non-palletized) for TFT.
> 
> So it doesn't really support RGB555 mode. The controller reads up to
> 32bit of framebuffer data and outputs 24bit on the LCD pins. You CAN
> wire up a RGB555 panel by just skipping the LSB green of a RGB565
> wiring, but that is independent of the framebufffer format.

But the AT91SAM9261/AT91SAM9263 do not have a native RGB565 format if it
is configured for 16bit (so it does not read 32bit and output 24bit but
just 16bit) but uses BGR555 with an additional intensity bit in the MSB
like the palette where you also kept the BGR555 format. How can you get
correct colors on these processors if this code above is removed?


  parent reply	other threads:[~2012-01-10 13:01 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-13 14:52 [PATCH] atmel_lcdfb: support 16bit BGR:565 mode, remove unsupported 15bit modes Peter Korsgaard
2012-01-05 11:26 ` Peter Korsgaard
2012-01-09  2:49   ` [PATCH] atmel_lcdfb: support 16bit BGR:565 mode, remove unsupported Florian Tobias Schandinat
2012-01-09  6:15     ` [PATCH] atmel_lcdfb: support 16bit BGR:565 mode, remove unsupported 15bit modes Peter Korsgaard
2012-01-09 13:36     ` [PATCH] atmel_lcdfb: support 16bit BGR:565 mode, remove unsupported Nicolas Ferre
2012-01-09 10:34 ` Nicolas Ferre
2012-01-09 11:13   ` [PATCH] atmel_lcdfb: support 16bit BGR:565 mode, remove unsupported 15bit modes Peter Korsgaard
2012-01-09 13:32     ` [PATCH] atmel_lcdfb: support 16bit BGR:565 mode, remove unsupported Nicolas Ferre
2012-01-10 13:01     ` Christian Glindkamp [this message]
2012-01-10 13:17       ` [PATCH] atmel_lcdfb: support 16bit BGR:565 mode, remove unsupported 15bit modes Peter Korsgaard
2012-01-10 16:42       ` Peter Korsgaard
2012-01-10 14:02     ` [PATCH] atmel_lcdfb: support 16bit BGR:565 mode, remove Jamie Lokier
2012-01-10 14:19       ` [PATCH] atmel_lcdfb: support 16bit BGR:565 mode, remove unsupported 15bit modes Peter Korsgaard
2012-01-10 21:06       ` [PATCH] atmel_lcdfb: support 16bit BGR:565 mode, remove Russell King - ARM Linux
2012-01-09 12:13   ` Russell King - ARM Linux
2012-01-09 12:20     ` [PATCH] atmel_lcdfb: support 16bit BGR:565 mode, remove unsupported 15bit modes Peter Korsgaard
2012-01-30  5:12 ` Florian Tobias Schandinat

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=20120110130146.GC2057@taskit.de \
    --to=christian.glindkamp@taskit.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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).