[PATCH] drm: Silence zero EDID carping

[PATCH] drm: Silence zero EDID carping

[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

[Intel-gfx] [PATCH] drm: Silence zero EDID carping

[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

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for drm: Silence zero EDID carping

[Patchwork]

[-- Attachment #1.1: Type: text/plain, Size: 8165 bytes --]

== Series Details ==

Series: drm: Silence zero EDID carping
URL   : https://patchwork.freedesktop.org/series/83199/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_9216 -> Patchwork_18804
====================================================

Summary
-------

  **SUCCESS**

  No regressions found.

  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18804/index.html

New tests
---------

  New tests have been introduced between CI_DRM_9216 and Patchwork_18804:

### New CI tests (1) ###

  * boot:
    - Statuses : 40 pass(s)
    - Exec time: [0.0] s

  

Known issues
------------

  Here are the changes found in Patchwork_18804 that come from known issues:

### IGT changes ###

#### Issues hit ####

  * igt@core_hotunplug@unbind-rebind:
    - fi-tgl-u2:          [PASS][1] -> [DMESG-WARN][2] ([i915#1982])
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9216/fi-tgl-u2/igt@core_hotunplug@unbind-rebind.html
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18804/fi-tgl-u2/igt@core_hotunplug@unbind-rebind.html

  * igt@debugfs_test@read_all_entries:
    - fi-bsw-nick:        [PASS][3] -> [INCOMPLETE][4] ([i915#1250] / [i915#1436])
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9216/fi-bsw-nick/igt@debugfs_test@read_all_entries.html
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18804/fi-bsw-nick/igt@debugfs_test@read_all_entries.html

  * igt@i915_pm_rpm@basic-pci-d3-state:
    - fi-bsw-kefka:       [PASS][5] -> [DMESG-WARN][6] ([i915#1982])
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9216/fi-bsw-kefka/igt@i915_pm_rpm@basic-pci-d3-state.html
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18804/fi-bsw-kefka/igt@i915_pm_rpm@basic-pci-d3-state.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
    - fi-byt-j1900:       [PASS][7] -> [DMESG-WARN][8] ([i915#1982])
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9216/fi-byt-j1900/igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic.html
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18804/fi-byt-j1900/igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic.html

  * igt@kms_cursor_legacy@basic-flip-before-cursor-atomic:
    - fi-icl-u2:          [PASS][9] -> [DMESG-WARN][10] ([i915#1982]) +1 similar issue
   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9216/fi-icl-u2/igt@kms_cursor_legacy@basic-flip-before-cursor-atomic.html
   [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18804/fi-icl-u2/igt@kms_cursor_legacy@basic-flip-before-cursor-atomic.html

  * igt@prime_self_import@basic-with_one_bo_two_files:
    - fi-tgl-y:           [PASS][11] -> [DMESG-WARN][12] ([i915#402]) +1 similar issue
   [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9216/fi-tgl-y/igt@prime_self_import@basic-with_one_bo_two_files.html
   [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18804/fi-tgl-y/igt@prime_self_import@basic-with_one_bo_two_files.html

  
#### Possible fixes ####

  * igt@core_hotunplug@unbind-rebind:
    - fi-kbl-7500u:       [DMESG-WARN][13] -> [PASS][14]
   [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9216/fi-kbl-7500u/igt@core_hotunplug@unbind-rebind.html
   [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18804/fi-kbl-7500u/igt@core_hotunplug@unbind-rebind.html

  * igt@debugfs_test@read_all_entries:
    - fi-tgl-y:           [DMESG-WARN][15] ([i915#402]) -> [PASS][16] +2 similar issues
   [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9216/fi-tgl-y/igt@debugfs_test@read_all_entries.html
   [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18804/fi-tgl-y/igt@debugfs_test@read_all_entries.html

  * igt@gem_busy@busy@all:
    - fi-tgl-y:           [DMESG-WARN][17] ([i915#1982]) -> [PASS][18] +1 similar issue
   [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9216/fi-tgl-y/igt@gem_busy@busy@all.html
   [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18804/fi-tgl-y/igt@gem_busy@busy@all.html

  * igt@i915_module_load@reload:
    - {fi-ehl-1}:         [DMESG-WARN][19] ([i915#1982]) -> [PASS][20]
   [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9216/fi-ehl-1/igt@i915_module_load@reload.html
   [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18804/fi-ehl-1/igt@i915_module_load@reload.html
    - fi-icl-y:           [DMESG-WARN][21] ([i915#1982]) -> [PASS][22]
   [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9216/fi-icl-y/igt@i915_module_load@reload.html
   [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18804/fi-icl-y/igt@i915_module_load@reload.html

  * igt@i915_selftest@live@gt_lrc:
    - fi-bsw-n3050:       [DMESG-FAIL][23] -> [PASS][24]
   [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9216/fi-bsw-n3050/igt@i915_selftest@live@gt_lrc.html
   [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18804/fi-bsw-n3050/igt@i915_selftest@live@gt_lrc.html

  * igt@i915_selftest@live@gt_timelines:
    - fi-apl-guc:         [INCOMPLETE][25] ([i915#1635]) -> [PASS][26]
   [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9216/fi-apl-guc/igt@i915_selftest@live@gt_timelines.html
   [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18804/fi-apl-guc/igt@i915_selftest@live@gt_timelines.html

  * igt@kms_chamelium@hdmi-crc-fast:
    - fi-skl-6700k2:      [DMESG-WARN][27] ([i915#2203]) -> [PASS][28] +35 similar issues
   [27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9216/fi-skl-6700k2/igt@kms_chamelium@hdmi-crc-fast.html
   [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18804/fi-skl-6700k2/igt@kms_chamelium@hdmi-crc-fast.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
    - fi-skl-guc:         [DMESG-WARN][29] ([i915#2203]) -> [PASS][30] +31 similar issues
   [29]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9216/fi-skl-guc/igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic.html
   [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18804/fi-skl-guc/igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic.html

  * igt@kms_cursor_legacy@basic-flip-after-cursor-legacy:
    - fi-icl-u2:          [DMESG-WARN][31] ([i915#1982]) -> [PASS][32]
   [31]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9216/fi-icl-u2/igt@kms_cursor_legacy@basic-flip-after-cursor-legacy.html
   [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18804/fi-icl-u2/igt@kms_cursor_legacy@basic-flip-after-cursor-legacy.html

  
#### Warnings ####

  * igt@core_hotunplug@unbind-rebind:
    - fi-icl-u2:          [DMESG-WARN][33] ([i915#289]) -> [DMESG-WARN][34] ([i915#1982] / [i915#289])
   [33]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9216/fi-icl-u2/igt@core_hotunplug@unbind-rebind.html
   [34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18804/fi-icl-u2/igt@core_hotunplug@unbind-rebind.html

  
  {name}: This element is suppressed. This means it is ignored when computing
          the status of the difference (SUCCESS, WARNING, or FAILURE).

  [i915#1250]: https://gitlab.freedesktop.org/drm/intel/issues/1250
  [i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436
  [i915#1635]: https://gitlab.freedesktop.org/drm/intel/issues/1635
  [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
  [i915#2203]: https://gitlab.freedesktop.org/drm/intel/issues/2203
  [i915#289]: https://gitlab.freedesktop.org/drm/intel/issues/289
  [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402


Participating hosts (42 -> 40)
------------------------------

  Missing    (2): fi-bsw-cyan fi-bdw-samus 


Build changes
-------------

  * Linux: CI_DRM_9216 -> Patchwork_18804

  CI-20190529: 20190529
  CI_DRM_9216: b50212d10fa0b1ef83ad62d4b445b361f282ed36 @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5828: db972bdaab8ada43b742bc9621bb0fc9d56a6fc6 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_18804: 47c03ad26318c0600ac4fdcde08234e8cf93076b @ git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

47c03ad26318 drm: Silence zero EDID carping

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18804/index.html

[-- Attachment #1.2: Type: text/html, Size: 9962 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH] drm: Silence zero EDID carping

[Ville Syrjälä]

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

Re: [Intel-gfx] [PATCH] drm: Silence zero EDID carping

[Ville Syrjälä]

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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm: Silence zero EDID carping

[Chris Wilson]

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

Re: [Intel-gfx] [PATCH] drm: Silence zero EDID carping

[Chris Wilson]

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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm: Silence zero EDID carping

[Ville Syrjälä]

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

Re: [Intel-gfx] [PATCH] drm: Silence zero EDID carping

[Ville Syrjälä]

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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[PATCH v2] drm: Quieten [zero] EDID carping

[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

[igt-dev] [PATCH v2] drm: Quieten [zero] EDID carping

[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

_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

[igt-dev] ✗ Fi.CI.BUILD: failure for drm: Quieten [zero] EDID carping

[Patchwork]

== Series Details ==

Series: drm: Quieten [zero] EDID carping
URL   : https://patchwork.freedesktop.org/series/83208/
State : failure

== Summary ==

Applying: drm: Quieten [zero] EDID carping
Patch failed at 0001 drm: Quieten [zero] EDID carping
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".


_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

Re: [PATCH v2] drm: Quieten [zero] EDID carping

[Ville Syrjälä]

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

Re: [igt-dev] [PATCH v2] drm: Quieten [zero] EDID carping

[Ville Syrjälä]

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
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev