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... Tomi
Attachment:
signature.asc
Description: OpenPGP digital signature
