From: Manasi Navare <manasi.d.navare@intel.com>
To: Jani Nikula <jani.nikula@intel.com>
Cc: intel-gfx@lists.freedesktop.org, stable@vger.kernel.org
Subject: Re: [Intel-gfx] [PATCH 1/2] drm/i915/edp: read edp display control registers unconditionally
Date: Thu, 26 Oct 2017 12:40:59 -0700 [thread overview]
Message-ID: <20171026194058.GD19276@intel.com> (raw)
In-Reply-To: <20171026142932.17737-1-jani.nikula@intel.com>
On Thu, Oct 26, 2017 at 05:29:31PM +0300, Jani Nikula wrote:
> Per my reading of the eDP spec, DP_DPCD_DISPLAY_CONTROL_CAPABLE bit in
> DP_EDP_CONFIGURATION_CAP should be set if the eDP display control
> registers starting at offset DP_EDP_DPCD_REV are "enabled". Currently we
> check the bit before reading the registers, and DP_EDP_DPCD_REV is the
> only way to detect eDP revision.
>
> Turns out there are (likely buggy) displays that require eDP 1.4+
> features, such as supported link rates and link rate select, but do not
> have the bit set. Read the display control registers
> unconditionally. They are supposed to read zero anyway if they are not
> supported, so there should be no harm in this.
>
> This fixes the referenced bug by enabling the eDP version check, and
> thus reading of the supported link rates. The panel in question has 0 in
> DP_MAX_LINK_RATE which is only supported in eDP 1.4+. Without the
> supported link rates method we default to RBR which is insufficient for
> the panel native mode. As a curiosity, the panel also has a bogus value
> of 0x12 in DP_EDP_DPCD_REV, but that passes our check for >= DP_EDP_14
> (which is 0x03).
>
This is the second wierd eDP panel case/bug that I have seen recently
where it doesnt not behave as per the spec.
Good catch, the fix looks good to me.
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103400
> Reported-and-tested-by: Nicolas P. <issun.artiste@gmail.com>
> Cc: Ville Syrj�l� <ville.syrjala@linux.intel.com>
> Cc: stable@vger.kernel.org
> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
> ---
> drivers/gpu/drm/i915/intel_dp.c | 13 ++++++++++---
> 1 file changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index aa75f55eeb61..158438bb0389 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -3735,9 +3735,16 @@ intel_edp_init_dpcd(struct intel_dp *intel_dp)
>
> }
>
> - /* Read the eDP Display control capabilities registers */
> - if ((intel_dp->dpcd[DP_EDP_CONFIGURATION_CAP] & DP_DPCD_DISPLAY_CONTROL_CAPABLE) &&
> - drm_dp_dpcd_read(&intel_dp->aux, DP_EDP_DPCD_REV,
> + /*
> + * Read the eDP display control registers.
> + *
> + * Do this independent of DP_DPCD_DISPLAY_CONTROL_CAPABLE bit in
> + * DP_EDP_CONFIGURATION_CAP, because some buggy displays do not have it
> + * set, but require eDP 1.4+ detection (e.g. for supported link rates
> + * method). The display control registers should read zero if they're
> + * not supported anyway.
> + */
> + if (drm_dp_dpcd_read(&intel_dp->aux, DP_EDP_DPCD_REV,
> intel_dp->edp_dpcd, sizeof(intel_dp->edp_dpcd)) ==
> sizeof(intel_dp->edp_dpcd))
> DRM_DEBUG_KMS("EDP DPCD : %*ph\n", (int) sizeof(intel_dp->edp_dpcd),
> --
> 2.11.0
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2017-10-26 19:36 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-26 14:29 [PATCH 1/2] drm/i915/edp: read edp display control registers unconditionally Jani Nikula
2017-10-26 14:55 ` Ville Syrjälä
2017-10-26 19:40 ` Manasi Navare [this message]
2017-10-30 9:55 ` [Intel-gfx] " Jani Nikula
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=20171026194058.GD19276@intel.com \
--to=manasi.d.navare@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jani.nikula@intel.com \
--cc=stable@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).