On 31 July 2012 14:12, Tomi Valkeinen <tomi.valkeinen@xxxxxx> wrote: > 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. > It's not about the panel, it's about the board. For the generic driver in the kernel , the 'panel' is just a set of 15 integer values. There's no "Acme Foo-123" or "Acme Bar-123". In fact, the _only_ purpose of the panel's name string in the driver is to pick the correct set of "15 integers". With DT, the name string would be unnecessary. Consider two panels "ABC_123" and "XYZ_321" having identical parameters but different internals. Would you have duplicate elements in the generic_dpi_panels[] array ? Because the 'panels' are different. Or would you simply assume the XYZ_Board has the panel 'ABC_123'? Because after all it's the parameters that matter. In short, we should see a 'panel' simply as a set of 15 integers. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
