All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jerome Glisse <j.glisse@gmail.com>
To: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Jerome Glisse <jglisse@redhat.com>, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH] drm/edid: limit printk when facing bad edid
Date: Thu, 16 Aug 2012 12:07:09 -0400	[thread overview]
Message-ID: <CAH3drwb4C9G-LNLt+rFNvoR_23rLOw9+M_3RoqdTY8194r4wGQ@mail.gmail.com> (raw)
In-Reply-To: <87mx1udg4l.fsf@intel.com>

On Thu, Aug 16, 2012 at 11:13 AM, Jani Nikula
<jani.nikula@linux.intel.com> wrote:
>
> 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@gmail.com> wrote:
>> On Tue, Aug 14, 2012 at 10:54 AM, Adam Jackson <ajax@redhat.com> wrote:
>>> On 8/9/12 11:25 AM, j.glisse@gmail.com wrote:
>>>>
>>>> From: Jerome Glisse <jglisse@redhat.com>
>>>>
>>>> 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.

I wanted to reset the counter any time the connector is connected to
something with good edid but i did not do that in the end. I can do a
patch on top if you think it would be nicer. That way only thing with
bad edid will be printed once and assuming you don't repeatly
alternate btw good and bad edid device you would not get spam.

>>>>
>>>> Signed-off-by: Jerome Glisse <jglisse@redhat.com>
>>>
>>>
>>> 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@redhat.com>
>>>
>>> - 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.
>

No, i do think we want bad edid as normal log at least once per
connector and we definitely don't want to spam bomb the log messages.

Cheers,
Jerome

  reply	other threads:[~2012-08-16 16:07 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-09 15:25 [PATCH] drm/edid: limit printk when facing bad edid j.glisse
2012-08-14 14:54 ` Adam Jackson
2012-08-14 15:01   ` Jerome Glisse
2012-08-16 15:13     ` Jani Nikula
2012-08-16 16:07       ` Jerome Glisse [this message]
2012-08-17  7:01         ` Jani Nikula
2012-08-17 14:50           ` Jerome Glisse

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAH3drwb4C9G-LNLt+rFNvoR_23rLOw9+M_3RoqdTY8194r4wGQ@mail.gmail.com \
    --to=j.glisse@gmail.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jani.nikula@linux.intel.com \
    --cc=jglisse@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.