linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Maxime Ripard <maxime.ripard@bootlin.com>
To: Priit Laes <plaes@plaes.org>
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: HDMI/DVI spurious failure
Date: Tue, 15 Jan 2019 10:49:51 +0100	[thread overview]
Message-ID: <20190115094951.e7jnjpibj5tcp5pz@flea> (raw)
In-Reply-To: <20190114132934.rywqqtjarbf6fgcr@plaes.org>

Hi,

(Sending those kind of bug reports to linux-sunxi doesn't really work,
you should Cc at least the ML involved in the development of the
driver at fault).

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.
> 
> HW: Olinuxino Lime2 eMMC
> 
> The same display works out of the box on Raspberry Pi. And I
> haven't seen it failing in u-boot on A20 Lime2 hw.
> 
> I have disabled HDMI support in U-boot (there's another issue
> with simplefb handover to modesetting, but I currently try to
> leave u-boot out of the equation), so kernel itselfs sets up
> the display.
> Basically the only differences I have found are some timing
> differences in DRM logs and following discrepancey in clock
> tree when comparing failing and working boots:
> 
> --- clks-failing.dump	2019-01-14 14:45:24.026279493 +0200
> +++ clks-ok.dump	2019-01-14 14:29:59.799715126 +0200
> @@ -6,7 +6,7 @@
>   mii_phy_tx               0        0        0    25000000          0     0  50000
>   osc32k                   0        0        0       32768          0     0  50000
>   osc24M                   2        2        1    24000000          0     0  50000
> -    hosc                  5        5        1    24000000          0     0  50000
> +    hosc                  6        6        1    24000000          0     0  50000
>         out-b              0        0        0       32000          0     0  50000
>         out-a              0        0        0       32000          0     0  50000
>         hdmi1-slow         0        0        0    24000000          0     0  50000
> @@ -52,10 +52,10 @@
>            apb1-i2c1       1        1        0    24000000          0     0  50000
>            apb1-i2c0       1        1        0    24000000          0     0  50000
>         pll-gpu            0        0        0  1200000000          0     0  50000
> -       pll-video1         0        0        0   327000000          0     0  50000
> -          pll-video1-2x   0        0        0   654000000          0     0  50000
> -             hdmi-tmds    0        0        0    25153846          0     0  50000
> -                hdmi-ddc  0        0        0       89835          0     0  50000
> +       pll-video1         1        1        0   327000000          0     0  50000
> +          pll-video1-2x   1        1        0   654000000          0     0  50000
> +             hdmi-tmds    1        1        0    25153846          0     0  50000
> +                hdmi-ddc  1        1        0       89835          0     0  50000
>         pll-periph-base    3        3        0  1200000000          0     0  50000
>            mbus            1        1        0   300000000          0     0  50000
>            pll-periph-sata 1        1        0   100000000          0     0  50000
> 
> 
> Any hints what else to debug?

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

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

       reply	other threads:[~2019-01-15 15:57 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20190114132934.rywqqtjarbf6fgcr@plaes.org>
2019-01-15  9:49 ` Maxime Ripard [this message]
2019-01-16  7:58   ` [linux-sunxi] Re: HDMI/DVI spurious failure Priit Laes
2019-01-16 19:24     ` Maxime Ripard
2019-01-16 20:35       ` Priit Laes
2019-01-17 11:33         ` Maxime Ripard
2019-01-18 10:10           ` Priit Laes
2019-01-18 14:04             ` Maxime Ripard
2019-01-18 14:51               ` Priit Laes
2019-01-21 13:25                 ` Maxime Ripard
2019-01-21 15:07                   ` Priit Laes
2019-01-21 17:18                     ` Jernej Škrabec
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=20190115094951.e7jnjpibj5tcp5pz@flea \
    --to=maxime.ripard@bootlin.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-sunxi@googlegroups.com \
    --cc=net147@gmail.com \
    --cc=plaes@plaes.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).