On 20/09/13 13:18, Archit Taneja wrote: > On Friday 20 September 2013 02:25 PM, Tomi Valkeinen wrote: >> On 20/09/13 11:49, Archit Taneja wrote: >> >>> I suppose we would hit this case if all of the displays are deferred >>> because of some dependency and are probed after omapdrm probes. >>> >>> Is that the case with beagle-xm? >> >> Yes, DVI is probed after omapdrm. There's also analog TV out on beagle. >> I'm not sure why that wasn't ready earlier, or was it available at all. >> I didn't study it further. >> >> If the analog tv would've been available, omapdrm would have started >> with only tv out, and DVI would have been left out. So it's still not >> perfect. > > Right, I suppose omapdrm should be probed only after all the dssdevs are > probed. That's a bit tough to do. Yes. Omapfb has the same issue. >>> I think we need to move this from pdev_probe() anyway. I don't see other >>> drivers doing much in pdev_probe(), they do most of their stuff in >>> dev_load() itself. I'll try with that along with disabling of the >>> dssdevs in encoder's destroy. >> >> Ok. The dssdevs are disabled in omap_connector already, though. > > I couldn't find where it is disabled in omap_connector. The only > function which calls dssdrv->disable is omap_connector_set_enabled(). > That doesn't seem to be called in omap_connector. Ah, right. Sorry, it seems I remembered totally wrong. I guess I was thinking about omap_dss_put_device instead. Tomi
Attachment:
signature.asc
Description: OpenPGP digital signature
