On 2012-12-10 12:53, Archit Taneja wrote: > On Monday 10 December 2012 03:37 PM, Tomi Valkeinen wrote: >> On 2012-12-10 11:54, Archit Taneja wrote: >>> On Monday 10 December 2012 01:33 PM, Tomi Valkeinen wrote: >> >>>> Another option would be to pass information about mgr-output links from >>>> the board files (or DT data) to the omapdss driver, so that omapdss >>>> could setup them at probe time. With this option omapfb/omapdrm doesn't >>>> need to care about this, and it doesn't create load order restriction. >>>> But mgr-output links are something that I'd really like to handle >>>> inside >>>> the drivers, not something that needs to be passed via platform data. >>> >>> This would definitely make things simpler, but if this parameter is put >>> in a panel's DT, it would become omap specific. We could add this info >>> to the DT corresponding to omapdss. >> >> Yes, I meant it should be omapdss platform data. Nothing related to >> panels. > > I think this is the easiest way out. We can have one parameter per > output in DT. If we do come up with a way to implement the 3rd option > below, we can always ignore those DT fields(assuming our implementation > to give the same result). So in this way, we would just be deprecating a > DT field in the future, and calculating it ourselves. I would rather go the other way around: calculate it ourselves (presuming it can be done for the current boards), and add the DT field later if we come up with boards that won't work with the dynamic approach. The reasons I'm not too happy with having the parameter in the DT data is that: - DT should be about describing the hardware connections between components, but in this case it's dynamically configurable connection. - We need to have the DT parameter for all cases, even if in 95% of cases it's not really needed. - We may never need the parameter, if we never get boards that require funny setup. > If we do use DT/platform data, would we need to parse it in omapdrm to > establish drm entities? Or do we rely on omapdss to parse the DT data > and give the links to omapdrm? I think we should parse it in omapdss and setup the connections at omapdss's probe. Then when omapfb/omapdrm starts, they can get information about the connections from omapdss, and setup their entities as they want. So omapdss would setup the mgr->output->panel links, and they would be ready for omapfb/omapdrm to use. Tomi
Attachment:
signature.asc
Description: OpenPGP digital signature
