On Tue, 2012-07-31 at 13:57 +0530, Jassi Brar wrote: > On 31 July 2012 13:44, Tomi Valkeinen <tomi.valkeinen@xxxxxx> wrote: > > On Tue, 2012-07-31 at 13:33 +0530, Jassi Brar wrote: > >> On 31 July 2012 13:21, Tomi Valkeinen <tomi.valkeinen@xxxxxx> 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:
signature.asc
Description: This is a digitally signed message part
