* [PATCH] drm: Silence zero EDID carping @ 2020-10-29 11:00 Chris Wilson 2020-10-29 14:07 ` Ville Syrjälä 2020-10-29 16:44 ` [PATCH v2] drm: Quieten [zero] " Chris Wilson 0 siblings, 2 replies; 6+ messages in thread From: Chris Wilson @ 2020-10-29 11:00 UTC (permalink / raw) To: dri-devel; +Cc: intel-gfx, Chris Wilson 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(-) 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 ^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH] drm: Silence zero EDID carping 2020-10-29 11:00 [PATCH] drm: Silence zero EDID carping Chris Wilson @ 2020-10-29 14:07 ` Ville Syrjälä 2020-10-29 16:01 ` [Intel-gfx] " Chris Wilson 2020-10-29 16:44 ` [PATCH v2] drm: Quieten [zero] " Chris Wilson 1 sibling, 1 reply; 6+ messages in thread From: Ville Syrjälä @ 2020-10-29 14:07 UTC (permalink / raw) To: Chris Wilson; +Cc: intel-gfx, dri-devel 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 -- Ville Syrjälä Intel _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Intel-gfx] [PATCH] drm: Silence zero EDID carping 2020-10-29 14:07 ` Ville Syrjälä @ 2020-10-29 16:01 ` Chris Wilson 2020-10-29 16:09 ` Ville Syrjälä 0 siblings, 1 reply; 6+ messages in thread From: Chris Wilson @ 2020-10-29 16:01 UTC (permalink / raw) To: Ville Syrjälä; +Cc: intel-gfx, dri-devel 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 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Intel-gfx] [PATCH] drm: Silence zero EDID carping 2020-10-29 16:01 ` [Intel-gfx] " Chris Wilson @ 2020-10-29 16:09 ` Ville Syrjälä 0 siblings, 0 replies; 6+ messages in thread From: Ville Syrjälä @ 2020-10-29 16:09 UTC (permalink / raw) To: Chris Wilson; +Cc: intel-gfx, dri-devel 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. -- Ville Syrjälä Intel _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 6+ messages in thread
* [PATCH v2] drm: Quieten [zero] EDID carping 2020-10-29 11:00 [PATCH] drm: Silence zero EDID carping Chris Wilson 2020-10-29 14:07 ` Ville Syrjälä @ 2020-10-29 16:44 ` Chris Wilson 2020-10-29 16:59 ` Ville Syrjälä 1 sibling, 1 reply; 6+ messages in thread From: Chris Wilson @ 2020-10-29 16:44 UTC (permalink / raw) To: dri-devel; +Cc: igt-dev, Chris Wilson We have a few displays in CI that always report their EDID as a bunch of zeroes. This is consistent behaviour, so one assumes intentional indication of an "absent" EDID. Flagging these consistent warnings detracts from CI. One option would be to ignore the zero EDIDs as intentional behaviour, but Ville would like to keep the information available for debugging. The simple alternative then is to reduce the loglevel for all the EDID dumping from WARN to DEBUG so the information is present but not annoy CI. Note that the bad EDID dumping is already only shown if drm.debug=KMS, it's just the loglevel chosen was set to be caught by CI if it ever occurred as it was expected to be an internal error not external. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2203 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> --- drivers/gpu/drm/drm_edid.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index 631125b46e04..c7363af731b4 100644 --- a/drivers/gpu/drm/drm_edid.c +++ b/drivers/gpu/drm/drm_edid.c @@ -1844,7 +1844,7 @@ static void connector_bad_edid(struct drm_connector *connector, if (connector->bad_edid_counter++ && !drm_debug_enabled(DRM_UT_KMS)) return; - drm_warn(connector->dev, "%s: EDID is invalid:\n", connector->name); + drm_dbg_kms(connector->dev, "%s: EDID is invalid:\n", connector->name); for (i = 0; i < num_blocks; i++) { u8 *block = edid + i * EDID_LENGTH; char prefix[20]; @@ -1856,7 +1856,7 @@ static void connector_bad_edid(struct drm_connector *connector, else sprintf(prefix, "\t[%02x] GOOD ", i); - print_hex_dump(KERN_WARNING, + print_hex_dump(KERN_DEBUG, prefix, DUMP_PREFIX_NONE, 16, 1, block, EDID_LENGTH, false); } -- 2.20.1 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH v2] drm: Quieten [zero] EDID carping 2020-10-29 16:44 ` [PATCH v2] drm: Quieten [zero] " Chris Wilson @ 2020-10-29 16:59 ` Ville Syrjälä 0 siblings, 0 replies; 6+ messages in thread From: Ville Syrjälä @ 2020-10-29 16:59 UTC (permalink / raw) To: Chris Wilson; +Cc: igt-dev, dri-devel On Thu, Oct 29, 2020 at 04:44:17PM +0000, Chris Wilson wrote: > We have a few displays in CI that always report their EDID as a bunch of > zeroes. This is consistent behaviour, so one assumes intentional > indication of an "absent" EDID. Flagging these consistent warnings > detracts from CI. > > One option would be to ignore the zero EDIDs as intentional behaviour, > but Ville would like to keep the information available for debugging. > The simple alternative then is to reduce the loglevel for all the EDID > dumping from WARN to DEBUG so the information is present but not annoy > CI. Note that the bad EDID dumping is already only shown if > drm.debug=KMS, it's just the loglevel chosen was set to be caught by CI > if it ever occurred as it was expected to be an internal error not > external. Indeed. That makes this even less controversial. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> > > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2203 > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> > Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> > --- > drivers/gpu/drm/drm_edid.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c > index 631125b46e04..c7363af731b4 100644 > --- a/drivers/gpu/drm/drm_edid.c > +++ b/drivers/gpu/drm/drm_edid.c > @@ -1844,7 +1844,7 @@ static void connector_bad_edid(struct drm_connector *connector, > if (connector->bad_edid_counter++ && !drm_debug_enabled(DRM_UT_KMS)) > return; > > - drm_warn(connector->dev, "%s: EDID is invalid:\n", connector->name); > + drm_dbg_kms(connector->dev, "%s: EDID is invalid:\n", connector->name); > for (i = 0; i < num_blocks; i++) { > u8 *block = edid + i * EDID_LENGTH; > char prefix[20]; > @@ -1856,7 +1856,7 @@ static void connector_bad_edid(struct drm_connector *connector, > else > sprintf(prefix, "\t[%02x] GOOD ", i); > > - print_hex_dump(KERN_WARNING, > + print_hex_dump(KERN_DEBUG, > prefix, DUMP_PREFIX_NONE, 16, 1, > block, EDID_LENGTH, false); > } > -- > 2.20.1 -- Ville Syrjälä Intel _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2020-10-29 16:59 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2020-10-29 11:00 [PATCH] drm: Silence zero EDID carping Chris Wilson 2020-10-29 14:07 ` Ville Syrjälä 2020-10-29 16:01 ` [Intel-gfx] " Chris Wilson 2020-10-29 16:09 ` Ville Syrjälä 2020-10-29 16:44 ` [PATCH v2] drm: Quieten [zero] " Chris Wilson 2020-10-29 16:59 ` Ville Syrjälä
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox