On Tue, 2012-08-21 at 11:13 +0200, Thierry Reding wrote: > On Tue, Aug 21, 2012 at 11:57:45AM +0300, Tomi Valkeinen wrote: > > This doesn't mean that we'd have a separate driver for each device. For > > example, we have a generic panel driver in OMAP, which contains a kind > > of small panel database. The panel database contains the name of the > > panel as a key, and panel specific configuration as a value. This > > configuration could also contain some kind of generic power sequence. > > I see. I do like the idea of it, because it is more straightforward than > representing the whole sequence in DT. Matching could be done using the > standard compatible property. Right. > However this also means we'll essentially just be moving the board code. What do you mean "just"? Wasn't the point of the whole "arm board file mess" to get rid of the code from the board files? If the code in the board file is device specific code, not board specific, then the driver of the device is a logical place to place it. And as I said, I don't have any problems with some kind of generic power sequences. So the code in the board file could be moved and converted to use the power sequences, if that is better than just plain c code. > Being in a central location it would be easier to refactor commonalities > though. > > > I'd like to require the board developer to only fill in to the DT data > > what panel he is using, and how it's connected on his board. Not panel's > > internal functionality. > > The amount of work required by the board developer would largely depend > on whether support for the panel is already present or not. For new > panels this would mean that a new driver needs to be written, while > representing the power sequence in DT might be easier to do, and readily > available from some datasheet. That's true. However, if we already have a generic driver for that type of panel, (which we would need anyway for the DT based approach), the developer only needs to add the name of the panel and the data for the power sequence to the panel driver's database, which is about the same amount of work as with DT. So it's really just a question of where to put the data in question, DT or driver. Both contain the same data, and the data structure may also be the same. In DT's case it just needs to be parsed first, whereas in database case you'll enter the data in structs. Tomi
Attachment:
signature.asc
Description: This is a digitally signed message part
