From: Todd Previte <tprevite@gmail.com>
To: Jani Nikula <jani.nikula@linux.intel.com>,
ville.syrjala@linux.intel.com, intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 1/2] drm/i915: Do a dummy DPCD read before the actual read
Date: Fri, 17 Oct 2014 09:10:50 -0700 [thread overview]
Message-ID: <54413F8A.5080309@gmail.com> (raw)
In-Reply-To: <87fvenm6hi.fsf@intel.com>
On 10/17/2014 1:43 AM, Jani Nikula wrote:
> On Thu, 16 Oct 2014, ville.syrjala@linux.intel.com wrote:
>> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>>
>> Sometimes we seem to get utter garbage from DPCD reads. The resulting
>> buffer is filled with the same byte, and the operation completed without
>> errors. My HP ZR24w monitor seems particularly susceptible to this
>> problem once it's gone into a sleep mode.
>>
>> The issue seems to happen only for the first AUX message that wakes the
>> sink up. But as the first AUX read we often do is the DPCD receiver
>> cap it does wreak a bit of havoc with subsequent link training etc. when
>> the receiver cap bw/lane/etc. information is garbage.
> This makes me suspect our sink dpms and wake handling even more than I
> already did. Someone(tm) should dig into the DP and hw specs again with
> fresh eyes...
I can go look into this today/next week. This problem sounds vaguely
similar to one I've run across before.
-T
>> A sufficient workaround seems to be to perform a single byte dummy read
>> before reading the actual data. I suppose that just wakes up the sink
>> sufficiently and we can just throw away the returned data in case it's
>> crap. DP_DPCD_REV seems like a sufficiently safe location to read here.
> Seems like a pretty harmless thing to do, and we already do loads of
> dpcd reads anyway. We should throw this at some related bugs.
>
> So ack.
>
> BR,
> Jani.
>
>
>> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
>> ---
>> drivers/gpu/drm/i915/intel_dp.c | 7 +++++++
>> 1 file changed, 7 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
>> index 64c8e04..f07f02c 100644
>> --- a/drivers/gpu/drm/i915/intel_dp.c
>> +++ b/drivers/gpu/drm/i915/intel_dp.c
>> @@ -2870,6 +2870,13 @@ intel_dp_dpcd_read_wake(struct drm_dp_aux *aux, unsigned int offset,
>> ssize_t ret;
>> int i;
>>
>> + /*
>> + * Sometime we just get the same incorrect byte repeated
>> + * over the entire buffer. Doing just one throw away read
>> + * initially seems to "solve" it.
>> + */
>> + drm_dp_dpcd_read(aux, DP_DPCD_REV, buffer, 1);
>> +
>> for (i = 0; i < 3; i++) {
>> ret = drm_dp_dpcd_read(aux, offset, buffer, size);
>> if (ret == size)
>> --
>> 2.0.4
>>
>> _______________________________________________
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
prev parent reply other threads:[~2014-10-17 16:10 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-16 17:46 [PATCH 1/2] drm/i915: Do a dummy DPCD read before the actual read ville.syrjala
2014-10-16 17:46 ` [PATCH 2/2] drm/i915: Ignore long hpds on eDP ports ville.syrjala
2014-10-16 19:38 ` Todd Previte
2014-10-17 8:43 ` Ville Syrjälä
2014-10-17 16:08 ` Todd Previte
2014-10-21 16:00 ` Daniel Vetter
2014-10-22 1:22 ` Dave Airlie
2014-10-22 7:39 ` Ville Syrjälä
2014-10-22 13:42 ` Jani Nikula
2014-10-17 3:37 ` Dave Airlie
2014-10-17 8:49 ` Jani Nikula
2014-10-17 9:00 ` Ville Syrjälä
2014-10-16 19:39 ` [PATCH 1/2] drm/i915: Do a dummy DPCD read before the actual read Todd Previte
2014-10-17 9:06 ` Ville Syrjälä
2014-10-17 16:13 ` Todd Previte
2014-10-21 15:57 ` Daniel Vetter
2014-10-17 8:43 ` Jani Nikula
2014-10-17 8:59 ` Ville Syrjälä
2014-10-17 16:38 ` Todd Previte
2014-10-17 16:10 ` Todd Previte [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54413F8A.5080309@gmail.com \
--to=tprevite@gmail.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jani.nikula@linux.intel.com \
--cc=ville.syrjala@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.