diff mbox series

drm: Silence zero EDID carping

Message ID 20201029110030.9959-1-chris@chris-wilson.co.uk
State New, archived
Headers show
Series drm: Silence zero EDID carping | expand

Commit Message

Chris Wilson Oct. 29, 2020, 11 a.m. UTC
We have a few displays in CI that always report their EDID as a bunch of
zeroes. This is consistent behavioud, so one assumes intentional
indication of an "absent" EDID. Let us treat is as such by silently
reporting the zero edid using connector->null_edid_counter, leaving the
loud carp to EDID that violate their checksums or otherwise return
unexpected illegal data upon reading. These are more likely to be
inconsistent bad connections rather than being intended.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
---
 drivers/gpu/drm/drm_edid.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Comments

Ville Syrjala Oct. 29, 2020, 2:07 p.m. UTC | #1
On Thu, Oct 29, 2020 at 11:00:30AM +0000, Chris Wilson wrote:
> We have a few displays in CI that always report their EDID as a bunch of
> zeroes. This is consistent behavioud, so one assumes intentional
> indication of an "absent" EDID. Let us treat is as such by silently
> reporting the zero edid using connector->null_edid_counter, leaving the
> loud carp to EDID that violate their checksums or otherwise return
> unexpected illegal data upon reading. These are more likely to be
> inconsistent bad connections rather than being intended.

I don't think null_edid_counter is actually used by anything.
So apart from wondering why the mode list has turned strange
is there some way I can still see from the logs that the
EDID has become all zeroes?

> 
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> ---
>  drivers/gpu/drm/drm_edid.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 631125b46e04..94549805a204 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -1951,7 +1951,7 @@ struct edid *drm_do_get_edid(struct drm_connector *connector,
>  			break;
>  		if (i == 0 && drm_edid_is_zero(edid, EDID_LENGTH)) {
>  			connector->null_edid_counter++;
> -			goto carp;
> +			goto out;
>  		}
>  	}
>  	if (i == 4)
> -- 
> 2.20.1
> 
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
Chris Wilson Oct. 29, 2020, 4:01 p.m. UTC | #2
Quoting Ville Syrjälä (2020-10-29 14:07:46)
> On Thu, Oct 29, 2020 at 11:00:30AM +0000, Chris Wilson wrote:
> > We have a few displays in CI that always report their EDID as a bunch of
> > zeroes. This is consistent behavioud, so one assumes intentional
> > indication of an "absent" EDID. Let us treat is as such by silently
> > reporting the zero edid using connector->null_edid_counter, leaving the
> > loud carp to EDID that violate their checksums or otherwise return
> > unexpected illegal data upon reading. These are more likely to be
> > inconsistent bad connections rather than being intended.
> 
> I don't think null_edid_counter is actually used by anything.
> So apart from wondering why the mode list has turned strange
> is there some way I can still see from the logs that the
> EDID has become all zeroes?

The ones in question, it's every time we read the EDID it comes back
zero. I am betting that transient everything-is-zero rather than
spurious data is rare enough not to worry about.

An alternative would be to pass the log level to the bad_edid dumper, or
just make it debug for even gibberish edids?
-Chris
Ville Syrjala Oct. 29, 2020, 4:09 p.m. UTC | #3
On Thu, Oct 29, 2020 at 04:01:23PM +0000, Chris Wilson wrote:
> Quoting Ville Syrjälä (2020-10-29 14:07:46)
> > On Thu, Oct 29, 2020 at 11:00:30AM +0000, Chris Wilson wrote:
> > > We have a few displays in CI that always report their EDID as a bunch of
> > > zeroes. This is consistent behavioud, so one assumes intentional
> > > indication of an "absent" EDID. Let us treat is as such by silently
> > > reporting the zero edid using connector->null_edid_counter, leaving the
> > > loud carp to EDID that violate their checksums or otherwise return
> > > unexpected illegal data upon reading. These are more likely to be
> > > inconsistent bad connections rather than being intended.
> > 
> > I don't think null_edid_counter is actually used by anything.
> > So apart from wondering why the mode list has turned strange
> > is there some way I can still see from the logs that the
> > EDID has become all zeroes?
> 
> The ones in question, it's every time we read the EDID it comes back
> zero. I am betting that transient everything-is-zero rather than
> spurious data is rare enough not to worry about.
> 
> An alternative would be to pass the log level to the bad_edid dumper, or
> just make it debug for even gibberish edids?

I suspect debug should be good enough for this. The user is probably
going to notice some problem with their display resolution if the
EDID is bad/zero, so we should still get the bug report.
diff mbox series

Patch

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 631125b46e04..94549805a204 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1951,7 +1951,7 @@  struct edid *drm_do_get_edid(struct drm_connector *connector,
 			break;
 		if (i == 0 && drm_edid_is_zero(edid, EDID_LENGTH)) {
 			connector->null_edid_counter++;
-			goto carp;
+			goto out;
 		}
 	}
 	if (i == 4)