Environment ---------------- platform: gm45 Kernel: (drm-intel-next)9ca1d10d748e56964de95e3ed80211b192f56cf4 Libdrm: (master)2.4.29-2-g0ab2251b70d49a294d24f3ef54982e95226c104a Bug detailed description: ----------------- Gm45 lost HDMI info frame until re-plug HDMI connector. When this issue occurs, the register video_dip_control(0x61170) value is 0xA1390000. I got the video_dip_control address from kernel source drivers/gpu/drm/i915/i915_reg.h If I revert the patch "drm/i915: fix ILK+ infoframe support", the info frame would be got as soon as system boot up. In that case, the value of video_dip_control is 0xA13B0006.
Hm so the working register value is using reserved bits (both bits 16 and 17 are set, which isn't supposed to be legal). Also, the RAM access address is nonzero. Can you verify that i9xx_write_infoframe is writing more than one value to VIDEO_DIP_DATA (just add a DRM_ERROR in the loop or something). You could also try making intel_infoframe_flags set bit 17...
(In reply to comment #1) > Hm so the working register value is using reserved bits (both bits 16 and 17 > are set, which isn't supposed to be legal). Also, the RAM access address is > nonzero. > > Can you verify that i9xx_write_infoframe is writing more than one value to > VIDEO_DIP_DATA (just add a DRM_ERROR in the loop or something). > > You could also try making intel_infoframe_flags set bit 17... I add a DRM_ERROR in the loop as following to dump the some verifies' value: for (i = 0; i < len; i += 4) { DRM_ERROR("len:%d, i:%d, data:%d(0x%x)\n",len,i,*data,*data); I915_WRITE(VIDEO_DIP_DATA, *data); data++; } Then when I boot machine with a HDMI monitor or hot plug-in a HDMI, I get the following information: [drm:i9xx_write_infoframe] *ERROR* len:18, i:0, data:852610(0xd0282) [drm:i9xx_write_infoframe] *ERROR* len:18, i:4, data:111(0x6f) [drm:i9xx_write_infoframe] *ERROR* len:18, i:8, data:0(0x0) [drm:i9xx_write_infoframe] *ERROR* len:18, i:12, data:0(0x0) [drm:i9xx_write_infoframe] *ERROR* len:18, i:16, data:0(0x0) [drm:i9xx_write_infoframe] *ERROR* len:30, i:0, data:1638787(0x190183) [drm:i9xx_write_infoframe] *ERROR* len:30, i:4, data:1953384946(0x746e49f2) [drm:i9xx_write_infoframe] *ERROR* len:30, i:8, data:27749(0x6c65) [drm:i9xx_write_infoframe] *ERROR* len:30, i:12, data:1953384704(0x746e4900) [drm:i9xx_write_infoframe] *ERROR* len:30, i:16, data:1634887525(0x61726765) [drm:i9xx_write_infoframe] *ERROR* len:30, i:20, data:543450484(0x20646574) [drm:i9xx_write_infoframe] *ERROR* len:30, i:24, data:7890535(0x786667) [drm:i9xx_write_infoframe] *ERROR* len:30, i:28, data:2304(0x900)
Can you check what gets written when the patch is reverted too? And also test the bit 17 set?
(In reply to comment #3) > Can you check what gets written when the patch is reverted too? And also test > the bit 17 set? Hi Jesse, I re-test this issue with three different kernel: 1)revert the patch, 2)with the patch and setting the 17th bit of intel_infoframe_flags, 3)kernel-3.2 without any modification. The detailed output are as following. I found the same output and the same issue between case 2) and 3). The issue didn't happen in case 1), and the output in case 1) is different from what in the two ones'. The difference of register VIDEO_DIP_DATA is the data value when variety 'i' is 4 and the 'len' is 30. case 1: revert patch: [drm:i9xx_write_infoframe] *ERROR* len:18, i:0, data:852610(0xd0282) [drm:i9xx_write_infoframe] *ERROR* len:18, i:4, data:0(0x0) [drm:i9xx_write_infoframe] *ERROR* len:18, i:8, data:0(0x0) [drm:i9xx_write_infoframe] *ERROR* len:18, i:12, data:0(0x0) [drm:i9xx_write_infoframe] *ERROR* len:18, i:16, data:0(0x0) [drm:i9xx_write_infoframe] *ERROR* len:30, i:0, data:1638787(0x190183) [drm:i9xx_write_infoframe] *ERROR* len:30, i:4, data:1953384822(0x746e4976) [drm:i9xx_write_infoframe] *ERROR* len:30, i:8, data:27749(0x6c65) [drm:i9xx_write_infoframe] *ERROR* len:30, i:12, data:1953384704(0x746e4900) [drm:i9xx_write_infoframe] *ERROR* len:30, i:16, data:1634887525(0x61726765) [drm:i9xx_write_infoframe] *ERROR* len:30, i:20, data:543450484(0x20646574) [drm:i9xx_write_infoframe] *ERROR* len:30, i:24, data:7890535(0x786667) [drm:i9xx_write_infoframe] *ERROR* len:30, i:28, data:2304(0x900) case 2: with patch and setting 17th bit of video_dip_control: [drm:i9xx_write_infoframe] *ERROR* len:18, i:0, data:852610(0xd0282) [drm:i9xx_write_infoframe] *ERROR* len:18, i:4, data:111(0x6f) [drm:i9xx_write_infoframe] *ERROR* len:18, i:8, data:0(0x0) [drm:i9xx_write_infoframe] *ERROR* len:18, i:12, data:0(0x0) [drm:i9xx_write_infoframe] *ERROR* len:18, i:16, data:0(0x0) [drm:i9xx_write_infoframe] *ERROR* len:30, i:0, data:1638787(0x190183) [drm:i9xx_write_infoframe] *ERROR* len:30, i:4, data:1953384946(0x746e49f2) [drm:i9xx_write_infoframe] *ERROR* len:30, i:8, data:27749(0x6c65) [drm:i9xx_write_infoframe] *ERROR* len:30, i:12, data:1953384704(0x746e4900) [drm:i9xx_write_infoframe] *ERROR* len:30, i:16, data:1634887525(0x61726765) [drm:i9xx_write_infoframe] *ERROR* len:30, i:20, data:543450484(0x20646574) [drm:i9xx_write_infoframe] *ERROR* len:30, i:24, data:7890535(0x786667) [drm:i9xx_write_infoframe] *ERROR* len:30, i:28, data:2304(0x900) case 3: Kernel-3.2(with patch): [drm:i9xx_write_infoframe] *ERROR* len:18, i:0, data:852610(0xd0282) [drm:i9xx_write_infoframe] *ERROR* len:18, i:4, data:111(0x6f) [drm:i9xx_write_infoframe] *ERROR* len:18, i:8, data:0(0x0) [drm:i9xx_write_infoframe] *ERROR* len:18, i:12, data:0(0x0) [drm:i9xx_write_infoframe] *ERROR* len:18, i:16, data:0(0x0) [drm:i9xx_write_infoframe] *ERROR* len:30, i:0, data:1638787(0x190183) [drm:i9xx_write_infoframe] *ERROR* len:30, i:4, data:1953384946(0x746e49f2) [drm:i9xx_write_infoframe] *ERROR* len:30, i:8, data:27749(0x6c65) [drm:i9xx_write_infoframe] *ERROR* len:30, i:12, data:1953384704(0x746e4900) [drm:i9xx_write_infoframe] *ERROR* len:30, i:16, data:1634887525(0x61726765) [drm:i9xx_write_infoframe] *ERROR* len:30, i:20, data:543450484(0x20646574) [drm:i9xx_write_infoframe] *ERROR* len:30, i:24, data:7890535(0x786667) [drm:i9xx_write_infoframe] *ERROR* len:30, i:28, data:2304(0x900)
That helps a lot. So the second write is different between the broken and working cases. I believe that's the checksum value. What happens if you apply something like this? diff --git a/drivers/gpu/drm/i915/intel_hdmi.c b/drivers/gpu/drm/i915/intel_hdmi index 64541f7..2c832c9 100644 --- a/drivers/gpu/drm/i915/intel_hdmi.c +++ b/drivers/gpu/drm/i915/intel_hdmi.c @@ -185,7 +185,7 @@ static void intel_set_infoframe(struct drm_encoder *encoder, if (!intel_hdmi->has_hdmi_sink) return; - intel_dip_infoframe_csum(frame); +// intel_dip_infoframe_csum(frame); intel_hdmi->write_infoframe(encoder, frame); }
(In reply to comment #5) > That helps a lot. So the second write is different between the broken and > working cases. I believe that's the checksum value. What happens if you apply > something like this? > > diff --git a/drivers/gpu/drm/i915/intel_hdmi.c > b/drivers/gpu/drm/i915/intel_hdmi > index 64541f7..2c832c9 100644 > --- a/drivers/gpu/drm/i915/intel_hdmi.c > +++ b/drivers/gpu/drm/i915/intel_hdmi.c > @@ -185,7 +185,7 @@ static void intel_set_infoframe(struct drm_encoder > *encoder, > if (!intel_hdmi->has_hdmi_sink) > return; > > - intel_dip_infoframe_csum(frame); > +// intel_dip_infoframe_csum(frame); > intel_hdmi->write_infoframe(encoder, frame); > } Hi Jesse, I tried it, and the issue still exists. As before, I dumped the value of VIDEO_DIP_DATA: [drm:i9xx_write_infoframe] *ERROR* len:18, i:0, data:852610(0xd0282) [drm:i9xx_write_infoframe] *ERROR* len:18, i:4, data:0(0x0) [drm:i9xx_write_infoframe] *ERROR* len:18, i:8, data:0(0x0) [drm:i9xx_write_infoframe] *ERROR* len:18, i:12, data:0(0x0) [drm:i9xx_write_infoframe] *ERROR* len:18, i:16, data:0(0x0) [drm:i9xx_write_infoframe] *ERROR* len:30, i:0, data:1638787(0x190183) [drm:i9xx_write_infoframe] *ERROR* len:30, i:4, data:1953384704(0x746e4900) [drm:i9xx_write_infoframe] *ERROR* len:30, i:8, data:27749(0x6c65) [drm:i9xx_write_infoframe] *ERROR* len:30, i:12, data:1953384704(0x746e4900) [drm:i9xx_write_infoframe] *ERROR* len:30, i:16, data:1634887525(0x61726765) [drm:i9xx_write_infoframe] *ERROR* len:30, i:20, data:543450484(0x20646574) [drm:i9xx_write_infoframe] *ERROR* len:30, i:24, data:7890535(0x786667) [drm:i9xx_write_infoframe] *ERROR* len:30, i:28, data:2304(0x900)
After upgrading Debian Squeeze backports kernel image (2.6.39-bpo.2-amd64) to a custom build of vanilla 3.2.1, HDMI audio stopped to work. danvet on IRC advised me to revert commit 64a8fc0145a1d0fdc25fc9367c2e6c621955fb3b, and that fixed the issue. Board: ASRock H61M/U3S3 CPU: Intel(R) Core(TM) i3-2100T lspci details which were requested: 00:02.0 VGA compatible controller [0300]: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller [8086:0102] (rev 09) (prog-if 00 [VGA controller]) Subsystem: ASRock Incorporation Device [1849:0102] Flags: bus master, fast devsel, latency 0, IRQ 49 Memory at fe000000 (64-bit, non-prefetchable) [size=4M] Memory at d0000000 (64-bit, prefetchable) [size=256M] I/O ports at f000 [size=64] Expansion ROM at <unassigned> [disabled] Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit- Capabilities: [d0] Power Management version 2 Capabilities: [a4] PCI Advanced Features Kernel driver in use: i915 00:1b.0 Audio device [0403]: Intel Corporation 6 Series/C200 Series Chipset Family High Definition Audio Controller [8086:1c20] (rev 05) Subsystem: ASRock Incorporation Device [1849:3662] Flags: bus master, fast devsel, latency 0, IRQ 50 Memory at fe700000 (64-bit, non-prefetchable) [size=16K] Capabilities: [50] Power Management version 2 Capabilities: [60] MSI: Enable+ Count=1/1 Maskable- 64bit+ Capabilities: [70] Express Root Complex Integrated Endpoint, MSI 00 Capabilities: [100] Virtual Channel Capabilities: [130] Root Complex Link Kernel driver in use: snd_hda_intel Thanks for all your great work! :)
danvet pointed out that I probably should add a note that I cannot test patches on that box easily sine it's located at my parents' and I don't come up here that often. I'll try to reproduce the problem (and any proposed fixes, if it rears its head) on my machine at home though, which is a very similar setup.
Ok the only diff between those cases is this: -[drm:i9xx_write_infoframe] *ERROR* len:30, i:4, data:1953384822(0x746e4976) +[drm:i9xx_write_infoframe] *ERROR* len:30, i:4, data:1953384704(0x746e4900) so we're writing a different value for the SPD infoframe... does the patch below fix all known issues? diff --git a/drivers/gpu/drm/i915/intel_hdmi.c b/drivers/gpu/drm/i915/intel_hdmi index 64541f7..dc689d2 100644 --- a/drivers/gpu/drm/i915/intel_hdmi.c +++ b/drivers/gpu/drm/i915/intel_hdmi.c @@ -185,7 +185,7 @@ static void intel_set_infoframe(struct drm_encoder *encoder, if (!intel_hdmi->has_hdmi_sink) return; - intel_dip_infoframe_csum(frame); +// intel_dip_infoframe_csum(frame); intel_hdmi->write_infoframe(encoder, frame); } @@ -260,7 +260,7 @@ static void intel_hdmi_mode_set(struct drm_encoder *encoder, POSTING_READ(intel_hdmi->sdvox_reg); intel_hdmi_set_avi_infoframe(encoder); - intel_hdmi_set_spd_infoframe(encoder); +// intel_hdmi_set_spd_infoframe(encoder); } static void intel_hdmi_dpms(struct drm_encoder *encoder, int mode)
We still need a re-plug to get the info frame with the patch. The difference is that the data written to the register VIDEO_DIP_DATA become less: [drm:i9xx_write_infoframe] *ERROR* len:18, i:0, data:852610(0xd0282) [drm:i9xx_write_infoframe] *ERROR* len:18, i:4, data:0(0x0) [drm:i9xx_write_infoframe] *ERROR* len:18, i:8, data:0(0x0) [drm:i9xx_write_infoframe] *ERROR* len:18, i:12, data:0(0x0) [drm:i9xx_write_infoframe] *ERROR* len:18, i:16, data:0(0x0)
Does the following patch make any difference? https://bugzilla.kernel.org/attachment.cgi?id=72694
(In reply to comment #11) > Does the following patch make any difference? > > https://bugzilla.kernel.org/attachment.cgi?id=72694 Hi Paulo, I tried the patch, but no difference. I have to re-connect the HDMI cable to get the AVI info frame.
Created attachment 60529 [details] proposed patches Hi Could please try the 9 patches attached? I believe patch 1 should fix the problem. If you have some time, you could do two tests: - one test containing only patch 1 applied - another test containing all the patches applied If patch 1 fixes the bug by itself, the plan is to submit only patch 1 to stable, but submit all the 9 patches to the development branch. Thank you, Paulo
(In reply to comment #13) > Created attachment 60529 [details] > proposed patches > Hi > Could please try the 9 patches attached? > I believe patch 1 should fix the problem. If you have some time, you could do > two tests: > - one test containing only patch 1 applied > - another test containing all the patches applied > If patch 1 fixes the bug by itself, the plan is to submit only patch 1 to > stable, but submit all the 9 patches to the development branch. > Thank you, > Paulo I have do two tests: one test containing only patch 1 applied,the bug is gone. another test containing all the patches applied,the bug still occurs.
(In reply to comment #14) > (In reply to comment #13) > > Created attachment 60529 [details] > > proposed patches > > Hi > > Could please try the 9 patches attached? > > I believe patch 1 should fix the problem. If you have some time, you could do > > two tests: > > - one test containing only patch 1 applied > > - another test containing all the patches applied > > If patch 1 fixes the bug by itself, the plan is to submit only patch 1 to > > stable, but submit all the 9 patches to the development branch. > > Thank you, > > Paulo > > I have do two tests: > one test containing only patch 1 applied,the bug is gone. > another test containing all the patches applied,the bug still occurs. This is weird. Everything works perfectly now on the gen4 machine I have here. Could you please describe how you boot and how you plug/unplug the monitor, so I can try to reproduce the problem here? How do you check the presence of the InfoFrame? Could you please try to bisect and see which of the patches re-introduces the problem? Thank you, Paulo
> This is weird. Everything works perfectly now on the gen4 machine I have here. > Could you please describe how you boot and how you plug/unplug the monitor, so > I can try to reproduce the problem here? > How do you check the presence of the InfoFrame? > Could you please try to bisect and see which of the patches re-introduces the > problem? > Thank you, > Paulo Hi,Paulo,I try the kernel with all patches again,it can work well.we can get the Info Fram after booting,the bug is gone.It's the same testing with kernel only having patch 1. I use a capture card with a tool:UFG CONSOLE on win7 system to get the HDMI Info Fram.
Fix merged to drm-intel-fixes as commit c3e897d603e9b0c19c2c65a3ab1cf07fe87da583 Author: Paulo Zanoni <paulo.r.zanoni@intel.com> Date: Wed May 2 22:55:43 2012 -0300 drm/i915: enable dip before writing data on gen4 While testing with the intel_infoframes tool on gen4, I see that when video DIP is disabled, what we write to the DATA memory is not exactly what we read back later. This regression has been introduce in commit 64a8fc0145a1d0fdc25fc9367c2e6c621955fb3b Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Thu Sep 22 11:16:00 2011 +0530 drm/i915: fix ILK+ infoframe support That commit was setting VIDEO_DIP_CTL to 0 when initializing, which caused the problem. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=43947 Cc: stable@kernel.org Tested-by: Yang Guang <guang.a.yang@intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> [danvet: Pimped commit message by using the usual commit citation layout.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
*** Bug 48266 has been marked as a duplicate of this bug. ***
A patch referencing this bug report has been merged in Linux v3.4-rc6: commit c1230df7e19e0f27655c0eb9d966c7e03be7cc50 Author: Paulo Zanoni <paulo.r.zanoni@intel.com> Date: Wed May 2 22:55:43 2012 -0300 drm/i915: enable dip before writing data on gen4
This patch creates a regression on my system. See bug 52350 for the details. Not sure if this should be tracked separately, as bug 52350 is related to display issues, whereas this patch causes audio to break when my receiver or TV is power-cycled. Please advise.
Matt's machine is pch-split (according to the dmesg on bug #52350), this bug is gm45 specific. Also, the original bug reporter confirmed the fix, so if this issue still exists it's likely a slightly different bug (yeah, that patch from Jesse broke tons of machines for tons of different reasons).
Closing old verified+fixed.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.