On Friday 02 November 2012 04:58 PM, Tomi Valkeinen wrote:
On 2012-11-02 13:09, Archit Taneja wrote:
On Friday 02 November 2012 04:19 PM, Tomi Valkeinen wrote:
On 2012-11-02 12:44, Archit Taneja wrote:
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.
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.
Archit
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
