Re: [BISECTED, REGRESSION] v4.12-rc: omapdrm fails to probe on Nokia N900

[Tomi Valkeinen]

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