Re: [PATCH] simplefb: add support for a8b8g8r8 pixel format

On 09:33 Thu 06 Jun     , Olof Johansson wrote:

On Thu, Jun 6, 2013 at 9:20 AM, Jean-Christophe PLAGNIOL-VILLARD
[off-list ref] wrote:

quoted

On 10:11 Thu 06 Jun     , Stephen Warren wrote:

quoted

On 06/06/2013 02:12 AM, Alex Courbot wrote:

quoted

On 06/06/2013 04:59 PM, Jean-Christophe PLAGNIOL-VILLARD wrote:

quoted

On Jun 6, 2013, at 9:20 AM, Alexandre Courbot [off-list ref]
wrote:

quoted

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>

No commit description? It'd be useful to at least justify this by
mentioning that some platform will actually use this...

...

quoted

quoted

quoted

static struct simplefb_format simplefb_formats[] = {
    { "r5g6b5", 16, {11, 5}, {5, 6}, {0, 5}, {0, 0} },
+    { "a8b8g8r8", 32, {0, 8}, {8, 8}, {16, 8}, {31, 8} },

why don't you parse the string?

so you will a real generic bindings

Tried that already, got NACKed: https://lkml.org/lkml/2013/5/27/330

The list of modes of this driver should not grow too big. Even in terms
of footprint I'd say the list should remain smaller than the parsing code.

What we can discuss though is whether we want to keep this a8b8g8r8
syntax or switch to something more standard, say "rgba8888".

I would prefer to keep the syntax of the new formats consistent, so that
if we ever do add format-parsing code rather than table-based lookup,
all the existing formats will continue to work unchanged, without any
kind of fallback lookup table.

I do prefer a format-parsing than any long lookup table that take time at boot
time

We're talking about adding a bunch of code instead of one line in a
table. Sorry, I NACK your NACK. If we get more entries we'll add the
parser, but not just for this.

as there is no NACK so far I do take as a NACK

Best Regards,
J.

If you want to make a framebuffer-subsystem generic and shared helper,
go ahead. I'm sure simplefb will move over to it when it's available.

Until then:

Acked-by: Olof Johansson <redacted>



-Olof