Re: [PATCH 02/23] OMAPDSS: outputs: Create and initialize output instances

On Mon, 2012-08-27 at 11:49 +0530, Archit Taneja wrote:

On Friday 24 August 2012 06:44 PM, Tomi Valkeinen wrote:

quoted

On Tue, 2012-08-21 at 11:28 +0530, Archit Taneja wrote:

quoted

Create output instances by having an init function in the probes of the platform
device drivers for different interfaces. Create a small function for each
interface to initialize the output entity's fields type and id.

In the probe of each interface driver, the output entities are created before
the *_probe_pdata() functions intentionally. This is done to ensure that the
output entity is prepared before the panels connected to the output are
registered. We need the output entities to be ready because OMAPDSS will try
to make connections between overlays, managers, outputs and devices during the
panel's probe.

You're referring to the recheck_connections stuff? I have a patch that
moves that to omapfb side. But of course it doesn't hurt to initialize
the output early.

I've seen that patch. omapfb would need to take care of connecting 
outputs to displays, and managers to outputs. This is added in 
recheck_connections done in a patch #9 of the series.

The question is whether we want some initial connections made between 
outputs and displays by DSS, or should that be left completely to 
omapfb/omapdrm?

Good question. I don't know. Perhaps we should set initial connections
there, as the cases where we have multiple displays per output are quite
rare.

quoted

We should generally do the initialization in output driver's probe more
or less so that we first setup everything related to the output driver,
and after that we register the dssdevs. But I think that's what is
already done.

So, no complaints =).

Another thing that comes up with delaying the recheck_connections stuff 
is that we can't assume that at the point of panel driver's probe, there 
is an output connected to the display. That makes it a bit tricky to 
call an output function in the panel's probe, since it isn't connected 
to any output at all. An example is when we request for a VC in 
taal_probe. Since the panel isn't connected to any output yet, we can't 
really call a dsi function to request for the VC. This particular case 
can be solved by requesting VCs only when we enable the panel(probably 
makes more sense this way), but there might be other situations which 
could get tricky to tackle.

Right. Well, as you said, we can easily move the stuff from taal's probe
to enable. There shouldn't be any problems to that.

However, this problem is part of the bigger problem that I haven't been
able to solve properly: how to manage the probe/enable stuff for panels.
Everything would be simple and easy if we had just one panel per output,
and we could just get and configure everything at probe. But we can have
multiple panels per output, of which only one can be used at a time...

That's why we currently acquire most of the display resources at enable,
instead of probe.

 Tomi