On 2012-11-02 13:56, Archit Taneja wrote: > 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.
Ah. Yes, that's true. >>> 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
signature.asc
Description: OpenPGP digital signature
