commit 6441ab5f8ffdf7e99eefe0fb747858e0c12b567e
Author: Paulo Zanoni <paulo.r.zanoni@intel.com>
Date:   Fri Oct 5 12:05:58 2012 -0300

    drm/i915: completely rewrite the Haswell PLL handling code

Paulo, this is your debug spam...

Yeah, we need to get rid of that "wrpll_tmds_clock_table" from intel_ddi.c and add code that generates the table for any possible input... I hope to be able to send a patch that implements this soon.

By the way, these are DRM_INFO, not DRM_ERROR.

This should be fixed in the drm-intel-next-queued branch by:

From: Damien Lespiau <damien.lespiau@intel.com>
Date: Fri, 10 May 2013 13:01:51 +0000
Subject: drm/i915: Compute WR PLL dividers dynamically

Up to now, we were using a static table to match the clock frequency
with a (r2,n2,p) triplet. Despite this table being big, it's by no mean
comprehensive and we had to fall back to the closest frequency when the
requested TMDS clock wasn't in the table.

This patch computes (r2,n2,p) dynamically and get rid of The Big Table.

v2: Replace the floating point constant 1e6 by 1000000

Bugzilla: http://bugs.freedesktop.org/show_bug.cgi?id=58497
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> (v1)
Tested-by: Paulo Zanoni <paulo.r.zanoni@intel.com> (v1)
[danvet: s/        /^T/]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Created attachment 79219 [details]
dmesg: DRM_INFO during booting up

Environment:
--------------------------
Kernel: (drm-intel-next-queued)e2e3de90ee465ae8fffb8095b85c2bdd322c74f7
Some additional commit info:
Author: Paulo Zanoni <paulo.r.zanoni@intel.com>
Date:   Wed Apr 17 18:15:49 2013 -0300

    drm/i915: implement WADPOClockGatingDisable for LPT

Description:
--------------------------
I have tried latest -next-queued kernel, but there's also some DRM_INFO in dmesg. I attached the dmesg here.

(In reply to comment #5)
> Created attachment 79219 [details]
> dmesg: DRM_INFO during booting up
> 
> Environment:
> --------------------------
> Kernel: (drm-intel-next-queued)e2e3de90ee465ae8fffb8095b85c2bdd322c74f7
> Some additional commit info:
> Author: Paulo Zanoni <paulo.r.zanoni@intel.com>
> Date:   Wed Apr 17 18:15:49 2013 -0300
> 
>     drm/i915: implement WADPOClockGatingDisable for LPT
> 
> Description:
> --------------------------
> I have tried latest -next-queued kernel, but there's also some DRM_INFO in
> dmesg. I attached the dmesg here.

This attachment is the dmesg of HSW machine booting up, I append testdisplay dmesg in next comment.

Created attachment 79221 [details]
dmesg: DRM_INFO after running testdisplay

Environment:
--------------------------------
Kernel: (drm-intel-next-queued)e2e3de90ee465ae8fffb8095b85c2bdd322c74f7
Some additional commit info:
Author: Paulo Zanoni <paulo.r.zanoni@intel.com>
Date:   Wed Apr 17 18:15:49 2013 -0300

    drm/i915: implement WADPOClockGatingDisable for LPT

Description:
---------------------------------
After running testdisplay, there's also some information not clean.

(In reply to comment #7)
> Created attachment 79221 [details]
> dmesg: DRM_INFO after running testdisplay
> 
> Environment:
> --------------------------------
> Kernel: (drm-intel-next-queued)e2e3de90ee465ae8fffb8095b85c2bdd322c74f7
> Some additional commit info:
> Author: Paulo Zanoni <paulo.r.zanoni@intel.com>
> Date:   Wed Apr 17 18:15:49 2013 -0300
> 
>     drm/i915: implement WADPOClockGatingDisable for LPT
> 
> Description:
> ---------------------------------
> After running testdisplay, there's also some information not clean.

The commit causing these error messages was reverted on Friday.

Environment:
------------------------------
Kernel: (drm-intel-next-queued)f2799ab0a317ecde76161df5d3102aa6e0e2c9e4
Some additional commit info:
Author: Jani Nikula <jani.nikula@intel.com>
Date:   Tue May 7 15:10:29 2013 +0300

    drm/i915: fix hotplug event bit tracking

Description:
------------------------------
I retest with the latest -next-queued kernel, it's much more better, there's only a little DRM_INFO messages after running testdisplay like below:

<6>[  182.607082] ALSA sound/pci/hda/hda_eld.c:334 HDMI: ELD buf size is 0, force 128
<6>[  182.607127] ALSA sound/pci/hda/hda_eld.c:351 HDMI: invalid ELD data byte 0
<6>[  182.607188] ALSA sound/pci/hda/hda_eld.c:334 HDMI: ELD buf size is 0, force 128
<6>[  182.607228] ALSA sound/pci/hda/hda_eld.c:351 HDMI: invalid ELD data byte 0

Reproduce step:
------------------------------
1. booting up machine
2. dmesg -c
3. ./testdisplay -a
4. dmesg -r | less

Hi,

This last error is a different bug than the original one. Could you please file a separate bug for this?

We cannot track all "there's something wrong in the log messages" errors in the same bug, bugs have to be more specific than that, and this one was about the WR PLL message.

Thanks!

-- 
Damien

OK, I verified here, and the new bug ID of tracking the new issue is: Bug #64657

Closing old verified+fixed.