Re: [linux-sunxi] Re: HDMI/DVI spurious failure
On Mon, Jan 21, 2019 at 02:25:17PM +0100, Maxime Ripard wrote: > On Fri, Jan 18, 2019 at 02:51:26PM +, Priit Laes wrote: > > On Fri, Jan 18, 2019 at 03:04:18PM +0100, Maxime Ripard wrote: > > > On Fri, Jan 18, 2019 at 10:10:53AM +, 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. > > > > Baseline is clean u-boot / linux. U-boot does not detect/enable display. > > > > 1) Booting Linux with drm.debug=0xe > > > > * Linux does not detect/enable display > > > > 2) Booting with drm.debug=0xe video=HDMI-A-1:640x480@60e > > > > * Linux detects display, but display is garbled, and proper edid data is > > detected: > > > > [snip] > > pll-video1 000 32700 0 > > 0 5 > >pll-video1-2x 000 65400 0 > > 0 5 > > hdmi-tmds00025153846 0 > > 0 5 > > hdmi-ddc 000 89835 0 > > 0 5 > > [/snip] > > > > 3) Booting with drm.debug=0xe video=HDMI-A-1:640x480@60e > > And also one extra patch for Linux where HDMI DDC clock marked as critical > > > > Linux detects and initializes display properly: > > [snip] > > pll-video1 110 32700 0 > > 0 5 > >pll-video1-2x 110 65400 0 > > 0 5 > > hdmi-tmds11025153846 0 > > 0 5 > > hdmi-ddc 110 89835 0 > > 0 5 > > [/snip] > > I guess you'll need to track down when the hdmi-tmds and hdmi-ddc are > enabled and disabled, and if it makes sense :/ OK, figured out the cause. Apparently, for each ddc poll we enable ddc clock which is a child of TMDS clock. After transfer is done, we disable the clock and this also tears down the parent because its only user has gone missing.. :( So basically, patch below also works, but I guess we should override the sun4i_tmds_ops.disable to properly account for tmds clock use. --- @@ -225,7 +235,7 @@ int sun4i_tmds_create(struct sun4i_hdmi *hdmi) init.ops = _tmds_ops; init.parent_names = parents; init.num_parents = 2; - init.flags = CLK_SET_RATE_PARENT; + init.flags = CLK_SET_RATE_PARENT | CLK_IS_CRITICAL; tmds->hdmi = hdmi; tmds->hw.init = > Maxime > > -- > Maxime Ripard, Bootlin > Embedded Linux and Kernel engineering > https://bootlin.com ___ dri-devel mailing list dri-devel@lists.freedesktop.org
Re: [linux-sunxi] Re: HDMI/DVI spurious failure
Dne ponedeljek, 21. januar 2019 ob 16:07:28 CET je Priit Laes napisal(a): > On Mon, Jan 21, 2019 at 02:25:17PM +0100, Maxime Ripard wrote: > > On Fri, Jan 18, 2019 at 02:51:26PM +, Priit Laes wrote: > > > On Fri, Jan 18, 2019 at 03:04:18PM +0100, Maxime Ripard wrote: > > > > On Fri, Jan 18, 2019 at 10:10:53AM +, 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. > > > > > > Baseline is clean u-boot / linux. U-boot does not detect/enable display. > > > > > > 1) Booting Linux with drm.debug=0xe > > > > > > * Linux does not detect/enable display > > > > > > 2) Booting with drm.debug=0xe video=HDMI-A-1:640x480@60e > > > > > > * Linux detects display, but display is garbled, and proper edid data is > > > detected: > > > > > > [snip] > > > pll-video1 000 32700 > > > 0 0 5> > > > >pll-video1-2x 000 65400 > > >0 0 5> > > > > hdmi-tmds00025153846 > > > 0 0 5> > > > > hdmi-ddc 000 89835 > > > 0 0 5> > > > > [/snip] > > > > > > 3) Booting with drm.debug=0xe video=HDMI-A-1:640x480@60e > > > And also one extra patch for Linux where HDMI DDC clock marked as > > > critical > > > > > > Linux detects and initializes display properly: > > > [snip] > > > pll-video1 110 32700 > > > 0 0 5> > > > >pll-video1-2x 110 65400 > > >0 0 5> > > > > hdmi-tmds11025153846 > > > 0 0 5> > > > > hdmi-ddc 110 89835 > > > 0 0 5> > > > > [/snip] > > > > I guess you'll need to track down when the hdmi-tmds and hdmi-ddc are > > enabled and disabled, and if it makes sense :/ > > OK, figured out the cause. > > Apparently, for each ddc poll we enable ddc clock which is a child of TMDS > clock. After transfer is done, we disable the clock and this also tears down > the parent because its only user has gone missing.. :( > > > So basically, patch below also works, but I guess we should override > the sun4i_tmds_ops.disable to properly account for tmds clock use. > As far as I can see, nobody called clk_prepare_enable() on tmds clock. I had similar issue with TMDS clock for H3, since I based
Re: [linux-sunxi] Re: HDMI/DVI spurious failure
On Tue, Jan 22, 2019 at 1:18 AM Jernej Škrabec wrote: > > Dne ponedeljek, 21. januar 2019 ob 16:07:28 CET je Priit Laes napisal(a): > > On Mon, Jan 21, 2019 at 02:25:17PM +0100, Maxime Ripard wrote: > > > On Fri, Jan 18, 2019 at 02:51:26PM +, Priit Laes wrote: > > > > On Fri, Jan 18, 2019 at 03:04:18PM +0100, Maxime Ripard wrote: > > > > > On Fri, Jan 18, 2019 at 10:10:53AM +, 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. > > > > > > > > Baseline is clean u-boot / linux. U-boot does not detect/enable display. > > > > > > > > 1) Booting Linux with drm.debug=0xe > > > > > > > > * Linux does not detect/enable display > > > > > > > > 2) Booting with drm.debug=0xe video=HDMI-A-1:640x480@60e > > > > > > > > * Linux detects display, but display is garbled, and proper edid data is > > > > detected: > > > > > > > > [snip] > > > > pll-video1 000 32700 > > > > 0 0 5> > > > > >pll-video1-2x 000 65400 > > > >0 0 5> > > > > > hdmi-tmds00025153846 > > > > 0 0 5> > > > > > hdmi-ddc 000 89835 > > > > 0 0 5> > > > > > [/snip] > > > > > > > > 3) Booting with drm.debug=0xe video=HDMI-A-1:640x480@60e > > > > And also one extra patch for Linux where HDMI DDC clock marked as > > > > critical > > > > > > > > Linux detects and initializes display properly: > > > > [snip] > > > > pll-video1 110 32700 > > > > 0 0 5> > > > > >pll-video1-2x 110 65400 > > > >0 0 5> > > > > > hdmi-tmds11025153846 > > > > 0 0 5> > > > > > hdmi-ddc 110 89835 > > > > 0 0 5> > > > > > [/snip] > > > > > > I guess you'll need to track down when the hdmi-tmds and hdmi-ddc are > > > enabled and disabled, and if it makes sense :/ > > > > OK, figured out the cause. > > > > Apparently, for each ddc poll we enable ddc clock which is a child of TMDS > > clock. After transfer is done, we disable the clock and this also tears down > > the parent because its only user has gone missing.. :( > > > > > > So basically, patch below also works, but I guess we should override > > the sun4i_tmds_ops.disable to properly account
Re: [linux-sunxi] Re: HDMI/DVI spurious failure
On Fri, Jan 18, 2019 at 02:51:26PM +, Priit Laes wrote: > On Fri, Jan 18, 2019 at 03:04:18PM +0100, Maxime Ripard wrote: > > On Fri, Jan 18, 2019 at 10:10:53AM +, 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. > > Baseline is clean u-boot / linux. U-boot does not detect/enable display. > > 1) Booting Linux with drm.debug=0xe > > * Linux does not detect/enable display > > 2) Booting with drm.debug=0xe video=HDMI-A-1:640x480@60e > > * Linux detects display, but display is garbled, and proper edid data is > detected: > > [snip] > pll-video1 000 32700 0 > 0 5 >pll-video1-2x 000 65400 0 > 0 5 > hdmi-tmds00025153846 0 > 0 5 > hdmi-ddc 000 89835 0 > 0 5 > [/snip] > > 3) Booting with drm.debug=0xe video=HDMI-A-1:640x480@60e > And also one extra patch for Linux where HDMI DDC clock marked as critical > > Linux detects and initializes display properly: > [snip] > pll-video1 110 32700 0 > 0 5 >pll-video1-2x 110 65400 0 > 0 5 > hdmi-tmds11025153846 0 > 0 5 > hdmi-ddc 110 89835 0 > 0 5 > [/snip] I guess you'll need to track down when the hdmi-tmds and hdmi-ddc are enabled and disabled, and if it makes sense :/ Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [linux-sunxi] Re: HDMI/DVI spurious failure
On Thu, Jan 17, 2019 at 12:33:40PM +0100, Maxime Ripard wrote: > On Wed, Jan 16, 2019 at 08:35:16PM +, Priit Laes wrote: > > On Wed, Jan 16, 2019 at 08:24:42PM +0100, Maxime Ripard wrote: > > > Hi Priit, > > > > > > On Wed, Jan 16, 2019 at 07:58:54AM +, Priit Laes wrote: > > > > > On Mon, Jan 14, 2019 at 01:29:34PM +, 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]. > > 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. > > 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. > > Do you have the same issues without those patches? Yes. Without those patches display is not detected by u-boot (issues with missing hpd pin and stricter edid checks), so kernel initializes display. Disabling those patches is mostly the same as disabling the HDMI support in u-boot the kernel side. > > 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 > > Do you have the DRM fbdev emulation enabled in that case or is Xorg > the first to setup the kms driver? Do you have some logs and a > configuration? Xorg logs for scenario 1 and 2 are basically the same whether or not HDMI is enabled in u-boot. Now, differences arise when DDC clock is marked as critical. Attached files: * Xorg.0.ddc-critical.log * Xorg.0.ddc-default.log Also attached drm.debug outputs. > Maxime > > -- > Maxime Ripard, Bootlin > Embedded Linux and Kernel engineering > https://bootlin.com Linux with (edid fallback + clk_critical patch) [12.552] X.Org X Server 1.19.2 Release Date: 2017-03-02 [12.553] X Protocol Version 11, Revision 0 [12.553] Build Operating System: Linux 4.9.0-8-armmp-lpae armv7l Debian [12.553] Current Operating System: Linux xxx-screen 5.0.0-rc1-00021-g9b31f15d4c57 #76 SMP Fri Jan 18 11:12:40 EET 2019 armv7l [12.553] Kernel command line: console=ttyS0,115200n8 root=/dev/mmcblk0p1 rootwait debug [12.553] Build Date: 03 November 2018 05:53:43AM [12.553] xorg-server 2:1.19.2-1+deb9u5 (https://www.debian.org/support) [12.554] Current version of pixman: 0.34.0 [12.554]Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [12.554] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [12.554] (==) Log file: "/var/log/Xorg.0.log", Time: Fri Jan 18 09:13:19 2019 [12.573]
Re: [linux-sunxi] Re: HDMI/DVI spurious failure
On Fri, Jan 18, 2019 at 03:04:18PM +0100, Maxime Ripard wrote: > On Fri, Jan 18, 2019 at 10:10:53AM +, 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. Baseline is clean u-boot / linux. U-boot does not detect/enable display. 1) Booting Linux with drm.debug=0xe * Linux does not detect/enable display 2) Booting with drm.debug=0xe video=HDMI-A-1:640x480@60e * Linux detects display, but display is garbled, and proper edid data is detected: [snip] pll-video1 000 32700 0 0 5 pll-video1-2x 000 65400 0 0 5 hdmi-tmds00025153846 0 0 5 hdmi-ddc 000 89835 0 0 5 [/snip] 3) Booting with drm.debug=0xe video=HDMI-A-1:640x480@60e And also one extra patch for Linux where HDMI DDC clock marked as critical Linux detects and initializes display properly: [snip] pll-video1 110 32700 0 0 5 pll-video1-2x 110 65400 0 0 5 hdmi-tmds11025153846 0 0 5 hdmi-ddc 110 89835 0 0 5 [/snip] > Maxime > > -- > Maxime Ripard, Bootlin > Embedded Linux and Kernel engineering > https://bootlin.com > > -- > You received this message because you are subscribed to the Google Groups > "linux-sunxi" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to linux-sunxi+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [linux-sunxi] Re: HDMI/DVI spurious failure
On Fri, Jan 18, 2019 at 10:10:53AM +, 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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [linux-sunxi] Re: HDMI/DVI spurious failure
On Wed, Jan 16, 2019 at 08:35:16PM +, Priit Laes wrote: > On Wed, Jan 16, 2019 at 08:24:42PM +0100, Maxime Ripard wrote: > > Hi Priit, > > > > On Wed, Jan 16, 2019 at 07:58:54AM +, Priit Laes wrote: > > > > On Mon, Jan 14, 2019 at 01:29:34PM +, 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]. Do you have the same issue without that patch? > 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. Do you have the same issues without those patches? > 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 Do you have the DRM fbdev emulation enabled in that case or is Xorg the first to setup the kms driver? Do you have some logs and a configuration? Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [linux-sunxi] Re: HDMI/DVI spurious failure
On Wed, Jan 16, 2019 at 08:24:42PM +0100, Maxime Ripard wrote: > Hi Priit, > > On Wed, Jan 16, 2019 at 07:58:54AM +, Priit Laes wrote: > > > On Mon, Jan 14, 2019 at 01:29:34PM +, 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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [linux-sunxi] Re: HDMI/DVI spurious failure
Hi Priit, On Wed, Jan 16, 2019 at 07:58:54AM +, Priit Laes wrote: > > On Mon, Jan 14, 2019 at 01:29:34PM +, 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? Thanks! Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [linux-sunxi] Re: HDMI/DVI spurious failure
On Tue, Jan 15, 2019 at 10:49:51AM +0100, Maxime Ripard wrote: > 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). OK, sorry for that. > > On Mon, Jan 14, 2019 at 01:29:34PM +, 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. Priit :) > > Maxime > > -- > Maxime Ripard, Bootlin > Embedded Linux and Kernel engineering > https://bootlin.com > > -- > You received this message because you are subscribed to the Google Groups > "linux-sunxi" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to linux-sunxi+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
