On 2012-11-02 13:56, Archit Taneja wrote:

On Friday 02 November 2012 04:58 PM, Tomi Valkeinen wrote:

quoted

On 2012-11-02 13:09, Archit Taneja wrote:

quoted

On Friday 02 November 2012 04:19 PM, Tomi Valkeinen wrote:

quoted

On 2012-11-02 12:44, Archit Taneja wrote:

quoted

Hmm, that makes sense. Anyway, I don't think it's really bad if we
refer
to dssdev->channel for now.

It is, because dssdev->channel doesn't exist with DT.

With DT we either need to figure out the channel in omapdss at runtime,
or add a property to the DT data telling the channel. And adding such a
property is not correct, as DT should be about describing the HW.

Ok.

I don't totally agree with your idea of figuring out the manager in
panel the panel's probe. If it's done in the panel driver's probe
itself, then by this point of time we have already set
mgr->output->device links. If omapdss only does this stuff, then

Hmm, I'm not sure I understand what's your point above? If figuring out
the mgr is done in panel's probe, the mgr->output link is not yet made
before that time.

My point is that we are trying to find a manager at panel's probe
itself. It think that's what we do now. But one of your recent patch
moves that to omapfb.

Ah. Yes, that's true.

quoted

quoted

omapfb/omapdrm have just the job of connecting the overlays to the
manager. Do you think that's okay?

Yes, that's how I think it should be. I don't see why omapfb/omapdrm
should care about which manager is being used for the output, it doesn't
really matter as long there is one and it works.

Then again, I don't have anything against omapfb/omapdrm choosing the
manager, but I don't see how they would have any better idea of which
manager to use than omapdss.

But as doing the connections at probe time is a bit problematic, perhaps
we should have a new step in this whole sequence. Something like
"connect" or whatever, which would lock the required blocks in the whole
pipeline, and acquire the required resources that couldn't be gotten at
probe time.

But even then, choosing the manager is not easy, as whoever chooses the
manager needs to observe all the possible displays used at the same
time...

Right. I was wondering if omapfb/omapdrm could understand the 'all
possible displays information' better compared to a panel's probe.

Even omapdrm/omafb can't be perfect because we could insert a panel
driver module at any time, and omapfb/omapdrm may miss that out.

True, omapdrm/fb may have a better idea. It's still unclear though.
Currently we have quite strict order in the sequence the modules need to
be loaded, which is quite bad and causes issues. We should make things
more dynamic, so that the initialization of the drivers could happen
more freely.

But that creates more problems: when booting up, omapfb starts. But
omapfb can't know if all the panel drivers have already been loaded.
omapfb may see that DVI is the default display, but what should it do if
DVI doesn't have a driver yet? It could wait, but perhaps the driver for
DVI will never even be loaded.

 Tomi