All of lore.kernel.org
 help / color / mirror / Atom feed
From: Priit Laes <plaes@plaes.org>
To: Maxime Ripard <maxime.ripard@bootlin.com>
Cc: linux-arm-kernel@lists.infradead.org,
	linux-sunxi@googlegroups.com, Chen-Yu Tsai <wens@csie.org>,
	Jonathan Liu <net147@gmail.com>,
	dri-devel@lists.freedesktop.org
Subject: Re: [linux-sunxi] Re: HDMI/DVI spurious failure
Date: Wed, 16 Jan 2019 20:35:16 +0000	[thread overview]
Message-ID: <20190116203516.s7pisy4miaclo63u@plaes.org> (raw)
In-Reply-To: <20190116192442.qz4xi2ky6axgiyvg@flea>

On Wed, Jan 16, 2019 at 08:24:42PM +0100, Maxime Ripard wrote:
> Hi Priit,
> 
> On Wed, Jan 16, 2019 at 07:58:54AM +0000, Priit Laes wrote:
> > > On Mon, Jan 14, 2019 at 01:29:34PM +0000, Priit Laes wrote:
> > > > I have a somewhat curious case with one HDMI/DVI screen that fails
> > > > to initialize properly every 6-7 boots. The display itself is also
> > > > somewhat flawed (missing HPD pin and the VSYNC/HSYNC pulse width
> > > > is set to 0 in EDID), but I suspect there could be some issues
> > > > regarding timing in A20 HDMI driver in Linux.
> > > > 
> > ...
> > 
> > > 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].

For u-boot I have also some extra patches, to detect HPD-less HDMI
displays [2] + relax some EDID timing checks [3] so u-boot can actually
initialize my screen.

So first configuration with 100% failures:
1) u-boot initializes HDMI ( A20-OLinuXino-Lime2-eMMC_defconfig )
2) Linux switches to simplefb
... somewhere around here blinking cursor is replaced with garbage
on screen 
3) Linux switches to kms
4) Xorg starts

Second scenario with failure every 6-7 boots:
1) Disabled HDMI in u-boot for my board
2) Linux sets up kms (sometimes fails here)
3) Xorg starts
4) ssh to machine and take the clock dump

Third scenario with no failures (but not suitable in long term..)
1) Disabled sun4i HDMI driver (CONFIG_DRM_SUN4I_HDMI=n) in Linux
2) u-boot sets up HDMI
3) Linux continues with simplefb
4) Xorg (with fbdev) starts


[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2018-November/613168.html
[2] https://lists.denx.de/pipermail/u-boot/2018-December/352541.html
[3] https://lists.denx.de/pipermail/u-boot/2018-December/352540.html
> 
> Thanks!
> Maxime
> 
> -- 
> Maxime Ripard, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: Priit Laes <plaes-q/aMd4JkU83YtjvyW6yDsg@public.gmane.org>
To: Maxime Ripard <maxime.ripard-LDxbnhwyfcJBDgjK7y7TUQ@public.gmane.org>
Cc: linux-sunxi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org,
	Jonathan Liu <net147-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
Subject: Re: Re: HDMI/DVI spurious failure
Date: Wed, 16 Jan 2019 20:35:16 +0000	[thread overview]
Message-ID: <20190116203516.s7pisy4miaclo63u@plaes.org> (raw)
In-Reply-To: <20190116192442.qz4xi2ky6axgiyvg@flea>

On Wed, Jan 16, 2019 at 08:24:42PM +0100, Maxime Ripard wrote:
> Hi Priit,
> 
> On Wed, Jan 16, 2019 at 07:58:54AM +0000, Priit Laes wrote:
> > > On Mon, Jan 14, 2019 at 01:29:34PM +0000, Priit Laes wrote:
> > > > I have a somewhat curious case with one HDMI/DVI screen that fails
> > > > to initialize properly every 6-7 boots. The display itself is also
> > > > somewhat flawed (missing HPD pin and the VSYNC/HSYNC pulse width
> > > > is set to 0 in EDID), but I suspect there could be some issues
> > > > regarding timing in A20 HDMI driver in Linux.
> > > > 
> > ...
> > 
> > > 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].

For u-boot I have also some extra patches, to detect HPD-less HDMI
displays [2] + relax some EDID timing checks [3] so u-boot can actually
initialize my screen.

So first configuration with 100% failures:
1) u-boot initializes HDMI ( A20-OLinuXino-Lime2-eMMC_defconfig )
2) Linux switches to simplefb
... somewhere around here blinking cursor is replaced with garbage
on screen 
3) Linux switches to kms
4) Xorg starts

Second scenario with failure every 6-7 boots:
1) Disabled HDMI in u-boot for my board
2) Linux sets up kms (sometimes fails here)
3) Xorg starts
4) ssh to machine and take the clock dump

Third scenario with no failures (but not suitable in long term..)
1) Disabled sun4i HDMI driver (CONFIG_DRM_SUN4I_HDMI=n) in Linux
2) u-boot sets up HDMI
3) Linux continues with simplefb
4) Xorg (with fbdev) starts


[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2018-November/613168.html
[2] https://lists.denx.de/pipermail/u-boot/2018-December/352541.html
[3] https://lists.denx.de/pipermail/u-boot/2018-December/352540.html
> 
> Thanks!
> Maxime
> 
> -- 
> Maxime Ripard, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com

  reply	other threads:[~2019-01-16 20:35 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20190114132934.rywqqtjarbf6fgcr@plaes.org>
2019-01-15  9:49 ` HDMI/DVI spurious failure Maxime Ripard
2019-01-15  9:49   ` Maxime Ripard
2019-01-16  7:58   ` [linux-sunxi] " Priit Laes
2019-01-16  7:58     ` Priit Laes
2019-01-16 19:24     ` [linux-sunxi] " Maxime Ripard
2019-01-16 19:24       ` Maxime Ripard
2019-01-16 20:35       ` Priit Laes [this message]
2019-01-16 20:35         ` Priit Laes
2019-01-17 11:33         ` [linux-sunxi] " Maxime Ripard
2019-01-17 11:33           ` Maxime Ripard
2019-01-18 10:10           ` [linux-sunxi] " Priit Laes
2019-01-18 10:10             ` Priit Laes
2019-01-18 14:04             ` [linux-sunxi] " Maxime Ripard
2019-01-18 14:04               ` Maxime Ripard
2019-01-18 14:51               ` [linux-sunxi] " Priit Laes
2019-01-18 14:51                 ` Priit Laes
2019-01-21 13:25                 ` [linux-sunxi] " Maxime Ripard
2019-01-21 13:25                   ` Maxime Ripard
2019-01-21 15:07                   ` [linux-sunxi] " Priit Laes
2019-01-21 15:07                     ` Priit Laes
2019-01-21 17:18                     ` [linux-sunxi] " Jernej Škrabec
2019-01-21 17:18                       ` Jernej Škrabec
2019-01-21 17:20                       ` [linux-sunxi] " Chen-Yu Tsai
2019-01-21 17:20                         ` Chen-Yu Tsai

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190116203516.s7pisy4miaclo63u@plaes.org \
    --to=plaes@plaes.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-sunxi@googlegroups.com \
    --cc=maxime.ripard@bootlin.com \
    --cc=net147@gmail.com \
    --cc=wens@csie.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.