There's a bug [1] where the faster GMBUS transmissions fail with some CRTs, and the fix [2] is to fallback to GPIO bit-banging upon errors. As noted in the bug, the fix still leaves plenty of EDID dumps in dmesg, so some measures to reduce the EDID error messages would be most welcome. [1] https://bugzilla.kernel.org/show_bug.cgi?id=45881 [2] http://thread.gmane.org/gmane.linux.kernel/1332810/focus=1341912 On Tue, 14 Aug 2012, Jerome Glisse <j.glisse@xxxxxxxxx> wrote: > On Tue, Aug 14, 2012 at 10:54 AM, Adam Jackson <ajax@xxxxxxxxxx> wrote: >> On 8/9/12 11:25 AM, j.glisse@xxxxxxxxx wrote: >>> >>> From: Jerome Glisse <jglisse@xxxxxxxxxx> >>> >>> Limit printing bad edid information at one time per connector. >>> Connector that are connected to a bad monitor/kvm will likely >>> stay connected to the same bad monitor/kvm and it makes no >>> sense to keep printing the bad edid message. Do I understand correctly that bad_edid_counter is only reset when you reboot or reload the module? So if you have a laptop that you connect to the monitor at home, the monitor at the office, the projector in the meeting room, and to a TV somewhere else, etc, the message about bad EDID will only printed once? I don't think that's good. But please do correct me if I'm wrong. >>> >>> Signed-off-by: Jerome Glisse <jglisse@xxxxxxxxxx> >> >> >> I guess. I don't see why we don't just move it into DRM_DEBUG_KMS if we're >> going to suppress it, but this does what it says on the box. >> >> Reviewed-by: Adam Jackson <ajax@xxxxxxxxxx> >> >> - ajax >> > > I think there is still value in getting at least once the bad edid. I think the raw edid dumps should be DEBUG level no matter what. Perhaps some of the other messages could use WARNING/DEBUG too. And with that, and my comment above, I not sure there really needs to be all that logic to count errors and act differently further on. BR, Jani. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel