Re: [PATCH v5 3/4] drm/dp_helper: Perform throw-away read before actual read in drm_dp_dpcd_read()

From: Ville Syrjälä
Date: Thu Apr 14 2016 - 13:01:53 EST


On Wed, Apr 13, 2016 at 10:58:32AM -0400, Lyude wrote:
> This is part of a patch series to migrate all of the workarounds for
> commonly seen behavior from bad sinks in intel_dp_dpcd_read_wake() to drm's
> DP helper.
>
> Some sinks will just return garbage for the first aux tranaction they
> receive when coming out of sleep mode, so we need to perform an additional
> read before the actual read to workaround this.
>
> Changes since v5
> - If the throwaway read in drm_dp_dpcd_read() fails, return the error
> from that instead of continuing. This follows the same logic we do in
> drm_dp_dpcd_access() (e.g. the error from the first transaction may
> differ from the errors that proceeding attempts might return).
>
> Signed-off-by: Lyude <cpaul@xxxxxxxxxx>
> ---
> drivers/gpu/drm/drm_dp_helper.c | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index 540c3e4..aa80702 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -248,6 +248,18 @@ unlock:
> ssize_t drm_dp_dpcd_read(struct drm_dp_aux *aux, unsigned int offset,
> void *buffer, size_t size)
> {
> + int ret;
> +
> + /*
> + * Sometimes we just get the same incorrect byte repeated over the
> + * entire buffer. Doing one throw away read initially seems to "solve"
> + * it.
> + */

We might want to improve the comment a bit, now that I analyzed the
problem in more detail. So perhaps something like:

/*
* HP ZR24w corrupts the first DPCD access after entering power save
* mode. Eg. on a read, the entire buffer will be filled with the same
* byte. Do a throw away read to avoid corrupting anything we care
* about. Afterwards things will work correctly until the monitor
* gets woken up and subsequently re-enters power save mode.
*
* The user pressing any button on the monitor is enough to wake it
* up, so there is no particularly good place to do the workaround.
* We just have to do it before any DPCD access and hope that the
* monitor doesn't power down exactly after the throw away read.
*/

I'm thinking we should probably also do it for writes, since those
seem to be affected as well.

> + ret = drm_dp_dpcd_access(aux, DP_AUX_NATIVE_READ, DP_DPCD_REV, buffer,
> + 1);
> + if (ret != 1)
> + return ret;
> +
> return drm_dp_dpcd_access(aux, DP_AUX_NATIVE_READ, offset, buffer,
> size);
> }
> --
> 2.5.5

--
Ville Syrjälä
Intel OTC