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
next prev parent 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: linkBe 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.