[linux-sunxi] Re: HDMI/DVI spurious failure

Maxime Ripard maxime.ripard at bootlin.com
Fri Jan 18 14:04:18 UTC 2019


On Fri, Jan 18, 2019 at 10:10:53AM +0000, Priit Laes wrote:
> > > > > > It doesn't look related to the clock rate itself, since it doesn't
> > > > > > change between the two cases. However, in one case the DDC clock is
> > > > > > enabled and in the other it's disabled.
> > > > > > 
> > > > > > Was it taken at the same time? Maybe you can try with that patch?
> > > > > > http://code.bulix.org/z7jmkm-555344?raw
> > > > > 
> > > > > Thanks, after doing ~50+ boots I haven't seen a single failure.
> > > > > 
> > > > > Previously I had following failure cases which are now both fixed:
> > > > > 
> > > > > a) Linux without u-boot HDMI, where one in every 6-7 boots failed.
> > > > > b) u--boot with hdmi enabled switching to simplefb and then switching
> > > > > to kms, where previously all boots ended up with garbled screen.
> > > > 
> > > > So it's not really a fix, but it really looks like the clock is not
> > > > enabled when it should.
> > > > 
> > > > Can you describe your test scenario a bit more? What are you doing
> > > > exactly, just booting? When do you start using the display? When did
> > > > you capture the debugfs output that you pasted?
> > > 
> > > Display is already connected via HDMI to the board. I don't really
> > > remove it, I just boot the device and let it start Xorg.
> > > Meanwhile I just ssh into the device and capture debugfs output.
> > > See my 3 testing scenarios below.
> > > 
> > > Kernel also includes one extra patch to fall back to DDC, in case HPD
> > > fails. Mostly the same I already submitted last November [1].
> > 
> > Do you have the same issue without that patch?
> 
> Can't really test this display without this patch and I do not have other
> HDMI/DVI screens. And this issue does not happen with other HDMI displays
> that I have here.

Can't you just force the monitor to be reported as present? It's not
great and we don't want to merge it, but that would allow you to test
that setup without too many interferences.

Maxime

-- 
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


More information about the dri-devel mailing list