On Fri, Jun 30, 2017 at 09:41:35AM +0300, Tomi Valkeinen wrote: > On 29/06/17 21:50, Aaro Koskinen wrote: > > Hi, > > > > On Thu, Jun 15, 2017 at 09:51:06AM +0300, Tomi Valkeinen wrote: > >> On 15/06/17 01:11, Aaro Koskinen wrote: > >>> When booting v4.12-rc5 on Nokia N900, omapdrm fails to probe and there > >>> is no display. > >> > >> Are you sure it doesn't probe? It fails the omapdss_stack_is_ready() > >> check? > > > > It appears the reason was that I didn't have > > CONFIG_DRM_OMAP_CONNECTOR_ANALOG_TV enabled. > > > > I think that's wrong. I don't own an analog TV, so why should I enable > > such option to get device's built-in display working? > > Indeed. Unfortunately I don't have a solution for that. > > DRM doesn't support adding devices after probe. So at omapdrm probe time > we have to decide which displays to use. In the dts file, n900 defines > the lcd and analog tv. omapdrm sees those, and, of course, must wait > until their respective drivers have probed. If you don't have the > display driver enabled, it's never loaded and omapdrm never probes as it > keeps waiting for those. > > omapdrm could start when some of the drivers are missing, but then the > question comes: when? omapdrm doesn't know if the driver will be probed > at some later time, or maybe it is a module, loaded later by the userspace. > > So, unless the DRM framework is modified to support adding displays > after probe, I don't see a solution for this. > > >> If that's the case then this is easier to debug. > > > > Sure it's always easy... when users do all the testing and debugging. > > > > Is it just me or do other OMAP users fail to see omapdrm changes being > > posted to linux-omap for testing or review purposes? > > I thought linux-omap was more for omap platform thingies. But sure, I > can start cc'ing linux-omap for all omapdrm patches. > > > And now I face another issue. When I boot v4.12-rc7 with > > CONFIG_DRM_OMAP_CONNECTOR_ANALOG_TV enabled and your "misc fixes" > > patches on N900, I get the error flood again, and the device is unusable: > > Yes, I think there's still something wrong. I haven't been able to find > out what. > > Somehow delays seem to help (like enabling debug prints), but I haven't > been able to find out where exactly the delay is needed. > > And I'd rather not revert the patch, because there's nothing wrong with > that patch as such, and it fixes issues on all platforms. > > So, I don't know... I guess I need to try to invent some horrible hacks > around the driver to somehow manage the omap3 problems. Perhaps > disabling/enabling the outputs when sync lost happens... I don't think registering before everything is loaded make sense. On the big desktop driver chips we have all the bridge/encoder/panel drivers built into the driver. arm-soc loves to make everything a separate module, but in the end if you decided to not compile half of the driver you need, then it's not going to work. Imo the only thing we should support to be hotplugged in drm is stuff you can physically hotplug (like atm connectors). Everything else just complicates the code for no good reason at all. tldr; Wrong .config gives you a non-working driver, no surprises. And due to the "default n" rule this can even look like a regression. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch -- 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
