Created attachment 70400 [details] dmesg info with testdisplay System Environment: -------------------------- Platform: Ivybridge Kernel: (drm-intel-next-queued)2d60696d645809c6a1a737c31898b3e630d7d495 Bug detailed description: ------------------------- On Ivybridge platform, after running testdisplay dmesg -r shows: <4>[ 1331.226181] HDMI: DVI dual 0, max TMDS clock 0, latency present 0 0, video latency 0 0, audio latency 0 0 I attach the dmesg.
(In reply to comment #0) > Created attachment 70400 [details] > dmesg info with testdisplay > > System Environment: > -------------------------- > Platform: Ivybridge > Kernel: (drm-intel-next-queued)2d60696d645809c6a1a737c31898b3e630d7d495 > Bug detailed description: > ------------------------- > On Ivybridge platform, after running testdisplay dmesg -r shows: > <4>[ 1331.226181] HDMI: DVI dual 0, max TMDS clock 0, latency present 0 0, > video latency 0 0, audio latency 0 0 > I attach the dmesg. BTW, we connected 3 display (VGA+2 HDMI) with the machine.
The message is harmless, this patch should tune it down to debug levels: https://patchwork.kernel.org/patch/1783171/ Please test.
(In reply to comment #2) > The message is harmless, this patch should tune it down to debug levels: > > https://patchwork.kernel.org/patch/1783171/ > > Please test. Yeah, the debug levels have changed to 7, the patch can work well.
Fyi the patch hasn't been merged yet, so I think we shouldn't close this just yet. Unfortunately we don't have a "patch works but not yet merged" state on fdo bugzilla, so I'll just reopen it.
Fix merged into drm-next as commit 670c1ef6508c8fdd83dc55968fc1ce7284d849a7 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Thu Nov 22 09:53:55 2012 +0100 drm/edid: tune down debug message in parse_hdmi_vsdb Should be included in -nightly.
I change the status to resolved, because only find the patch in -nightly but not in - dinq or -fixed, it seems the drm-next branch your said is in your another tree: drm-upstream. Daniel, should we verified the bug if we only find the patch in -nightly.
(In reply to comment #6) Daniel, should we verified the bug if we only > find the patch in -nightly. I think so. This is the purpose of -nightly.
Yeah, the idea behind -nightly is that it contains other trees and so allows us to verify/test them before they're merged into one of the tree's I maintain. This is because I do backmerges and rebases to never upstream only when required for merging patches (upstream policy), hence we would otherwise have a few weeks (sometimes months) of delays until a fix in a different tree can be verified.
Closing old verified.
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.