[Intel-gfx] [PATCH] drm: Slightly quieten bad EDID messages

[Daniel Vetter]

On Thu, Feb 28, 2019 at 01:42:33PM +0000, Chris Wilson wrote:
> Bad EDID are a fact of life when dealing with random monitors. We only
> spam the logs when debugging is enabled, but we only need to raise
> notice and not set off the warning bells.
> 
> Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> Cc: Maarten Lankhorst <maarten.lankhorst at linux.intel.com>
> ---
>  drivers/gpu/drm/drm_edid.c | 11 +++++------
>  1 file changed, 5 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 990b1909f9d7..98903cb7064d 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -1535,9 +1535,8 @@ static void connector_bad_edid(struct drm_connector *connector,
>  	if (connector->bad_edid_counter++ && !(drm_debug & DRM_UT_KMS))
>  		return;
>  
> -	dev_warn(connector->dev->dev,
> -		 "%s: EDID is invalid:\n",
> -		 connector->name);
> +	dev_notice(connector->dev->dev,
> +		   "%s: EDID is invalid:\n", connector->name);
>  	for (i = 0; i < num_blocks; i++) {
>  		u8 *block = edid + i * EDID_LENGTH;
>  		char prefix[20];
> @@ -1549,7 +1548,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_NOTICE,
>  			       prefix, DUMP_PREFIX_NONE, 16, 1,
>  			       block, EDID_LENGTH, false);
>  	}

These two definitely make sense.

> @@ -4695,8 +4694,8 @@ int drm_add_edid_modes(struct drm_connector *connector, struct edid *edid)
>  	}
>  	if (!drm_edid_is_valid(edid)) {
>  		clear_eld(connector);
> -		dev_warn(connector->dev->dev, "%s: EDID invalid.\n",
> -			 connector->name);
> +		dev_notice(connector->dev->dev,
> +			   "%s: EDID invalid.\n", connector->name);

Not entirely sure about this one, if we totally break the i2c reading, but
load detect still works (likely, since different paths at least for i915),
then we won't catch that. We'll just silently fall back to the default
modes (and maybe some wtf test failures).

I'd keep this one here.
-Daniel

>  		return 0;
>  	}
>  
> -- 
> 2.20.1
> 
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch