On 2012-12-10 12:53, Archit Taneja wrote:
On Monday 10 December 2012 03:37 PM, Tomi Valkeinen wrote:
quoted
On 2012-12-10 11:54, Archit Taneja wrote:
quoted
On Monday 10 December 2012 01:33 PM, Tomi Valkeinen wrote:
quoted
quoted
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