Re: [PATCH] OMAPDSS: Add timings for ChiMei G121S1-L01/L02 and G121X1-L01 LCD displays

[Tomi Valkeinen <tomi.valkeinen@ti.com>]

[-- Attachment #1: Type: text/plain, Size: 1627 bytes --]

On Tue, 2012-07-17 at 21:57 +0530, Jassi Brar wrote:
> [CC'ing OMAPDSS matinainer]
> 
> On 17 July 2012 19:31, Raphael Assenat <raph@8d.com> wrote:
> > Add timings for ChiMei G121S1-L01/L02 and G121X1-L01 LCD displays.
> >
> Display panels are board specific and there is no limit to the number
> of panels that could be connected to omap dss.
>  Does it make sense to get panel params via DT? Or at least have them
> come from board file? (esp when there is hardly a panel shared by two
> boards, and some panels aren't even used by any board in mainline)

So we have two options, with pros and cons:

1) Have the configuration for countless panels specified in the driver

- Pro: driver for the device is the right place to define hardcoded
device properties
- Pro: panels can be easily used from the board file, just define the
name of the panel
- Pro: the same panel can be easily used from multiple board files,
without duplicating the configs
- Con: Adds lines to the kernel (not really a con, all features add
lines to the kernel. and we can restructure the data to fit fewer
lines.)
- Con: We could have "leftover" panel data, not used by anyone.

2) Have the configuration for countless panels specified in the DT data

- Con: DT data is not the right place to describe device's internal
hardcoded properties. DT data should be about HW connections and
configurable options.
- Con: Adds lines to the DT data

What were the pros for option 2? I didn't really see them in this mail
thread, except moving lines from the kernel to the DT, which I don't
really see as a pro.

 Tomi


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]