From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>,
dri-devel@lists.freedesktop.org, intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm: Only warn about an invalid EDID block prior to rejection
Date: Mon, 9 Mar 2015 18:04:46 +0200 [thread overview]
Message-ID: <20150309160446.GZ11371@intel.com> (raw)
In-Reply-To: <20150309153901.GA31461@nuc-i3427.alporthouse.com>
On Mon, Mar 09, 2015 at 03:39:01PM +0000, Chris Wilson wrote:
> On Mon, Mar 09, 2015 at 05:29:44PM +0200, Ville Syrjälä wrote:
> > On Mon, Mar 09, 2015 at 11:44:05AM +0000, Chris Wilson wrote:
> > > On a noisy link, we may retry the EDID reads multiple times per block
> > > and still succeed. In such cases, we don't want to flood the kernel logs
> > > with *ERROR* messages as we then succeed. Refactor the EDID dumping and
> > > push it into the caller rather than the validator so we can suppress the
> > > warnings from transient failures. In the process, we want to refactor
> > > drm_load_edid_firmware() to use the common drm_do_get_edid() to share
> > > the same logic (since it already duplicates it).
> > >
> > > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > > References: https://bugs.freedesktop.org/show_bug.cgi?id=89454
> >
> > Could we get it to dump the number of retries it had to make to get a
> > valid EDID? The retries could be due to driver bugs so we may want to
> > know that they in fact occured. Otherwise we might end up with eg.
> > large delays during resume without any indication what caused them.
>
> We also log the number of times the edid was bad and the edid was zero.
I don't see where we log those. We do count them though.
> Knowing how many times we retried would be nice as well. Seems like it
> should be possible to output that to debugfs/.../connector/edid_info ?
>
> What interface do you envisage being useful? I'm not convinced adding it
> to the user dmesg would be useful, but can a debugfs be integrated into
> whatever test you have in mind?
Well I just figure having it in the dmesg would be OK. That way when we
get a bug titled 'Resume takes forever' we can just ask for the dmesg as
usual, and we'd be able to see that something fishy was going on with
the EDID reads.
--
Ville Syrjälä
Intel OTC
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2015-03-09 16:04 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-09 11:44 [PATCH] drm: Only warn about an invalid EDID block prior to rejection Chris Wilson
2015-03-09 15:29 ` Ville Syrjälä
2015-03-09 15:39 ` Chris Wilson
2015-03-09 16:04 ` Ville Syrjälä [this message]
2015-03-09 16:22 ` Chris Wilson
2015-03-09 17:08 ` [Intel-gfx] " Daniel Vetter
2015-03-09 17:25 ` shuang.he
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=20150309160446.GZ11371@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=chris@chris-wilson.co.uk \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
/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.