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: 1721 bytes --]

On Tue, 2012-07-31 at 13:57 +0530, Jassi Brar wrote:
> On 31 July 2012 13:44, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> > On Tue, 2012-07-31 at 13:33 +0530, Jassi Brar wrote:
> >> On 31 July 2012 13:21, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> >>
> >> > 2) Have the configuration for countless panels specified in the DT data
> >> >
> >> Why should a DT blob for a board contain more than 1 panel configuration?
> >
> > I meant the DT data generally, for all boards.
> >
> If you mean : Why have the configuration (those 15 integers) of the
> panel on a board specified in board.dtb?
> Well, that is an important purpose of DT - moving board specific
> parameters, on which a generic code works, out of kernel (I am
> refraining from preaching the goodness of that).

Sure. But panel's unconfigurable properties are not board specific
parameters, they are panel's internal stuff. It doesn't matter to which
board I attach Acme Foo-123 panel, the panel timings are still the same.

Okay, agreed, the timing properties are not unconfigurable. But I'd
expect that normally the timings used are the normal timings specified
in the panel's datasheet.

For the cases where the board manufacturer wants to use non-standard
timings, perhaps we could allow overriding with DT data the ones
specified in the kernel. Or have a panel driver that expects to get all
the data from DT.

But I don't see why a panel database in the kernel driver is a bad thing
(presuming it can be used in most cases). The driver should allow using
the panel device without requiring the user to give extra information.
(extra in the sense that the driver should already know about that
info).

 Tomi


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