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

[Jean-Christophe PLAGNIOL-VILLARD]

On 10:17 Thu 06 Jun     , Stephen Warren wrote:
> On 06/06/2013 08:50 AM, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > On 17:27 Thu 06 Jun     , Alex Courbot wrote:
> >> On 06/06/2013 05:24 PM, Jean-Christophe PLAGNIOL-VILLARD wrote:
> >>>
> >>> On Jun 6, 2013, at 10:12 AM, Alex Courbot <acourbot@xxxxxxxxxx> wrote:
> >>>
> >>>> On 06/06/2013 04:59 PM, Jean-Christophe PLAGNIOL-VILLARD wrote:
> >>>>>
> >>>>> On Jun 6, 2013, at 9:20 AM, Alexandre Courbot <acourbot@xxxxxxxxxx> wrote:
> ...
> >>>>>> 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?
> 
> Jean-Christophe, I'm afraid I can't tell exactly what you're arguing for.
> 
> Here, you want code added to parse the string ...
> 
> This has already been rejected as being over-engineered, and more than
> this simple driver needs. Even if it were shared code, the only
> practical use of such a parsing function would be to support this
> driver, since presumably any other HW-specific driver already knows
> exactly which format the FB is in, and hence wouldn't need to share this
> code.
> 
> >>>>> 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'm going to be very honest I do not like the simplefb driver from the beginning
> >>> but I do found it useful. And as said in it's name it need to be *SIMPLE*
> >>>
> >>> Then a huge list of compatible no way
> >>> otherwise we drop this from the simplefb and make it a generic helper
> >>>
> >>> I do not want to see format parser in every drivers this need to handle at video framework level
> 
> ... yet here you appear to be arguing against using a format parser, or
> including a format parser ...
> 
> Note that a lookup table isn't any kind of shared parser; it's just a
> very tiny and simple table of static data. It seems quite unlikely that
> this could be a maintenance issue, even if over time a few more entries
> get added to the table.
> 
> >>> If I see that we start to increase again and again the simplefb I will not accept
> >>> to merge the code as we must keep it simple
> >>
> >> In that case it's probably better to maintain a "simple" list of
> >> supported modes, which is what this patch does.
> > 
> > so get out it of the simplefb other drivers can use it
> 
> ... yet here you appear to want to move the list of modes into some
> central location ...
> 
> I don't think that's useful for the reason I mentioned above: presumably
> any other HW-specific driver already knows exactly which format the FB
> is in, and hence wouldn't need to share this code/table.
> 
> Why don't we simply take this patch to extend this table, and then *if*
> any other FB driver needs to parse a format from DT, we can move the
> code(table) to a common location at that time. That will be a trivial
> change, and one this patch does nothing to make any harder. Making the
> code/table common before then seems like over-engineering.

that why I said *if I see that we start ....*

I did reject this patch but put a warning I do not want to see a huge table
if so => factorisation or parser

Best Regards,
J.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/