From: "Shankar, Uma" <uma.shankar@intel.com>
To: "Nikula, Jani" <jani.nikula@intel.com>,
"intel-gfx@lists.freedesktop.org"
<intel-gfx@lists.freedesktop.org>
Cc: "Nikula, Jani" <jani.nikula@intel.com>
Subject: Re: [Intel-gfx] [PATCH RESEND 5/7] drm/i915/mst: read link status only when requested by sink in ESI
Date: Thu, 20 Jan 2022 10:41:07 +0000 [thread overview]
Message-ID: <2a4d6d7cf26c418b94cd51a7982bee1d@intel.com> (raw)
In-Reply-To: <20220112110319.1172110-5-jani.nikula@intel.com>
> -----Original Message-----
> From: Intel-gfx <intel-gfx-bounces@lists.freedesktop.org> On Behalf Of Jani Nikula
> Sent: Wednesday, January 12, 2022 4:33 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Nikula, Jani <jani.nikula@intel.com>
> Subject: [Intel-gfx] [PATCH RESEND 5/7] drm/i915/mst: read link status only when
> requested by sink in ESI
>
> The link service irq vector in DPCD 0x2005 contains the link status changed bit to
> indicate the status should be checked. Only read and check the link status when
> requested by the sink.
>
> This also reduces the confusion around the buffer size for the combined ESI and link
> status. Alas, we still need to take into account that all link status helpers expect a
> buffer of DP_LINK_STATUS_SIZE (6) while the link status in ESI only has 4 bytes.
Looks Good to me.
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 41 +++++++++++--------------
> 1 file changed, 18 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 5a7976768b06..d8a0ba3a14b7 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -73,8 +73,6 @@
> #include "intel_vdsc.h"
> #include "intel_vrr.h"
>
> -#define DP_DPRX_ESI_LEN 14
> -
> /* DP DSC throughput values used for slice count calculations KPixels/s */
> #define DP_DSC_PEAK_PIXEL_RATE 2720000
> #define DP_DSC_MAX_ENC_THROUGHPUT_0 340000
> @@ -2814,11 +2812,9 @@ intel_dp_configure_mst(struct intel_dp *intel_dp) }
>
> static bool
> -intel_dp_get_sink_irq_esi(struct intel_dp *intel_dp, u8 *sink_irq_vector)
> +intel_dp_get_sink_irq_esi(struct intel_dp *intel_dp, u8 *esi)
> {
> - return drm_dp_dpcd_read(&intel_dp->aux, DP_SINK_COUNT_ESI,
> - sink_irq_vector, DP_DPRX_ESI_LEN) ==
> - DP_DPRX_ESI_LEN;
> + return drm_dp_dpcd_read(&intel_dp->aux, DP_SINK_COUNT_ESI, esi, 4) ==
> +4;
> }
>
> static bool intel_dp_ack_sink_irq_esi(struct intel_dp *intel_dp, u8 esi[4]) @@ -
> 3639,12 +3635,22 @@ intel_dp_mst_hpd_irq(struct intel_dp *intel_dp, u8 *esi, bool
> *handled)
> }
> }
>
> -static bool intel_dp_mst_link_status(struct intel_dp *intel_dp, u8 *esi)
> +static bool intel_dp_mst_link_status(struct intel_dp *intel_dp)
> {
> struct intel_encoder *encoder = &dp_to_dig_port(intel_dp)->base;
> struct drm_i915_private *i915 = to_i915(encoder->base.dev);
> + u8 link_status[DP_LINK_STATUS_SIZE] = {};
> + const size_t esi_link_status_size = DP_LINK_STATUS_SIZE - 2;
> +
> + if (drm_dp_dpcd_read(&intel_dp->aux, DP_LANE0_1_STATUS_ESI,
> link_status,
> + esi_link_status_size) != esi_link_status_size) {
> + drm_err(&i915->drm,
> + "[ENCODER:%d:%s] Failed to read link status\n",
> + encoder->base.base.id, encoder->base.name);
> + return false;
> + }
>
> - if (!drm_dp_channel_eq_ok(&esi[10], intel_dp->lane_count)) {
> + if (!drm_dp_channel_eq_ok(link_status, intel_dp->lane_count)) {
> drm_dbg_kms(&i915->drm,
> "[ENCODER:%d:%s] channel EQ not ok, retraining\n",
> encoder->base.base.id, encoder->base.name); @@ -
> 3676,18 +3682,7 @@ intel_dp_check_mst_status(struct intel_dp *intel_dp)
> drm_WARN_ON_ONCE(&i915->drm, intel_dp->active_mst_links < 0);
>
> for (;;) {
> - /*
> - * The +2 is because DP_DPRX_ESI_LEN is 14, but we then
> - * pass in "esi+10" to drm_dp_channel_eq_ok(), which
> - * takes a 6-byte array. So we actually need 16 bytes
> - * here.
> - *
> - * Somebody who knows what the limits actually are
> - * should check this, but for now this is at least
> - * harmless and avoids a valid compiler warning about
> - * using more of the array than we have allocated.
> - */
> - u8 esi[DP_DPRX_ESI_LEN+2] = {};
> + u8 esi[4] = {};
> bool handled;
>
> if (!intel_dp_get_sink_irq_esi(intel_dp, esi)) { @@ -3700,9 +3695,9
> @@ intel_dp_check_mst_status(struct intel_dp *intel_dp)
>
> drm_dbg_kms(&i915->drm, "DPRX ESI: %4ph\n", esi);
>
> - /* check link status - esi[10] = 0x200c */
> - if (intel_dp->active_mst_links > 0 && link_ok) {
> - if (!intel_dp_mst_link_status(intel_dp, esi))
> + if (intel_dp->active_mst_links > 0 && link_ok &&
> + esi[3] & LINK_STATUS_CHANGED) {
> + if (!intel_dp_mst_link_status(intel_dp))
> link_ok = false;
> }
>
> --
> 2.30.2
next prev parent reply other threads:[~2022-01-20 10:41 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-12 11:03 [Intel-gfx] [PATCH RESEND 1/7] drm/i915/mst: fix intel_dp_mst_hpd_irq() indentation Jani Nikula
2022-01-12 11:03 ` [Intel-gfx] [PATCH RESEND 2/7] drm/i915/mst: abstract intel_dp_ack_sink_irq_esi() Jani Nikula
2022-01-20 11:29 ` Shankar, Uma
2022-01-12 11:03 ` [Intel-gfx] [PATCH RESEND 3/7] drm/i915/mst: debug log 4 bytes of ESI right after reading Jani Nikula
2022-01-20 10:37 ` Shankar, Uma
2022-01-12 11:03 ` [Intel-gfx] [PATCH RESEND 4/7] drm/i915/mst: abstract handling of link status in DP MST Jani Nikula
2022-01-20 10:39 ` Shankar, Uma
2022-01-12 11:03 ` [Intel-gfx] [PATCH RESEND 5/7] drm/i915/mst: read link status only when requested by sink in ESI Jani Nikula
2022-01-20 10:41 ` Shankar, Uma [this message]
2022-01-12 11:03 ` [Intel-gfx] [PATCH RESEND 6/7] drm/i915/mst: ack sink irq ESI for link status changes Jani Nikula
2022-01-20 10:42 ` Shankar, Uma
2022-01-12 11:03 ` [Intel-gfx] [PATCH RESEND 7/7] drm/i915/mst: only ack the ESI we actually handled Jani Nikula
2022-01-20 10:43 ` Shankar, Uma
2022-01-20 11:01 ` Jani Nikula
2022-01-20 11:33 ` Shankar, Uma
2022-01-21 11:27 ` Jani Nikula
2022-01-20 11:01 ` [Intel-gfx] [PATCH v2] " Jani Nikula
2022-01-20 11:31 ` Shankar, Uma
2022-01-12 13:30 ` [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [RESEND,1/7] drm/i915/mst: fix intel_dp_mst_hpd_irq() indentation Patchwork
2022-01-12 17:27 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
2022-01-20 11:28 ` [Intel-gfx] [PATCH RESEND 1/7] " Shankar, Uma
2022-01-20 11:56 ` [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [RESEND,1/7] drm/i915/mst: fix intel_dp_mst_hpd_irq() indentation (rev2) Patchwork
2022-01-20 13:57 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
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=2a4d6d7cf26c418b94cd51a7982bee1d@intel.com \
--to=uma.shankar@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jani.nikula@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.