From: Imre Deak <imre.deak@intel.com>
To: Luca Coelho <luca@coelho.fi>
Cc: <intel-gfx@lists.freedesktop.org>,
<intel-xe@lists.freedesktop.org>,
"Imre Deak" <imre.deak@gmail.com>
Subject: Re: [PATCH 15/20] drm/i915/dp: Read/ack sink count and sink IRQs for SST as it's done for MST
Date: Thu, 3 Jul 2025 16:14:08 +0300 [thread overview]
Message-ID: <aGaCIMPOqLdfGIWZ@ideak-desk> (raw)
In-Reply-To: <b32389ca0460b01d91f5adf42b1a92f81cccd2f4.camel@coelho.fi>
On Thu, Jul 03, 2025 at 04:02:18PM +0300, Luca Coelho wrote:
> On Thu, 2025-06-26 at 11:20 +0300, Imre Deak wrote:
> > From: Imre Deak <imre.deak@gmail.com>
> >
> > Read and ack the sink count, sink device and link service IRQs for SST
> > the same way this is done for MST, the read/ack happening in separate
> > steps via an ESI (Event Status Indicator) vector.
> >
> > The above way is more efficient, since on newer (DPCD_REV >= 1.2) sinks
> > the DP_SINK_COUNT_ESI..DP_LINK_SERVICE_IRQ_VECTOR_ESI0 registers can be
> > read out in one AUX transaction - and the 3 last one written in one
> > transaction. Also this allows sharing more of the SST and MST IRQ
> > handling code (done as a follow-up).
> >
> > For now keep the current behavior of always reading the legacy
> > DP_SINK_COUNT, DP_DEVICE_SERVICE_IRQ_VECTOR registers and not reading
> > the DP_DEVICE_SERVICE_IRQ_VECTOR_ESI1 register.
> >
> > Signed-off-by: Imre Deak <imre.deak@gmail.com>
> > ---
> > drivers/gpu/drm/i915/display/intel_dp.c | 132 +++++++++++++-----------
> > 1 file changed, 73 insertions(+), 59 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c
> > index 2ba4a810f22c2..2e6ed7d2a64a6 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > @@ -4573,6 +4573,70 @@ static bool intel_dp_ack_sink_irq_esi(struct intel_dp *intel_dp, u8 esi[4])
> > return false;
> > }
> >
> > +static bool intel_dp_get_sink_irq_esi_sst(struct intel_dp *intel_dp, u8 esi[4])
> > +{
> > + memset(esi, 0, 4);
> > +
> > + /*
> > + * TODO: For DP_DPCD_REV >= 0x12 read
> > + * DP_SINK_COUNT_ESI and DP_DEVICE_SERVICE_IRQ_VECTOR_ESI0.
> > + */
> > + if (drm_dp_dpcd_read_data(&intel_dp->aux, DP_SINK_COUNT, esi, 2) != 0)
> > + return false;
> > +
> > + if (intel_dp->dpcd[DP_DPCD_REV] < DP_DPCD_REV_12)
> > + return true;
> > +
> > + /* TODO: Read DP_DEVICE_SERVICE_IRQ_VECTOR_ESI1 as well */
> > + if (drm_dp_dpcd_read_byte(&intel_dp->aux, DP_LINK_SERVICE_IRQ_VECTOR_ESI0, &esi[3]) != 0)
> > + return false;
> > +
> > + return true;
> > +}
> > +
> > +static bool intel_dp_ack_sink_irq_esi_sst(struct intel_dp *intel_dp, u8 esi[4])
> > +{
> > + /*
> > + * TODO: For DP_DPCD_REV >= 0x12 write
> > + * DP_DEVICE_SERVICE_IRQ_VECTOR_ESI0
> > + */
> > + if (drm_dp_dpcd_write_byte(&intel_dp->aux, DP_DEVICE_SERVICE_IRQ_VECTOR, esi[1]) != 0)
> > + return false;
> > +
> > + if (intel_dp->dpcd[DP_DPCD_REV] < DP_DPCD_REV_12)
> > + return true;
> > +
> > + /* TODO: Read DP_DEVICE_SERVICE_IRQ_VECTOR_ESI1 as well */
> > + if (drm_dp_dpcd_write_byte(&intel_dp->aux, DP_LINK_SERVICE_IRQ_VECTOR_ESI0, esi[3]) != 0)
> > + return false;
> > +
> > + return true;
> > +}
> > +
> > +static bool intel_dp_get_and_ack_sink_irq_esi_sst(struct intel_dp *intel_dp, u8 esi[4])
> > +{
> > + struct intel_display *display = to_intel_display(intel_dp);
> > + struct intel_connector *connector = intel_dp->attached_connector;
> > + struct intel_encoder *encoder = &dp_to_dig_port(intel_dp)->base;
> > +
> > + if (!intel_dp_get_sink_irq_esi_sst(intel_dp, esi))
> > + return false;
> > +
> > + drm_dbg_kms(display->drm,
> > + "[CONNECTOR:%d:%s][ENCODER:%d:%s] DPRX ESI: %4ph\n",
> > + connector->base.base.id, connector->base.name,
> > + encoder->base.base.id, encoder->base.name,
> > + esi);
> > +
> > + if (mem_is_zero(&esi[1], 3))
> > + return true;
> > +
> > + if (!intel_dp_ack_sink_irq_esi_sst(intel_dp, esi))
> > + return false;
> > +
> > + return true;
> > +}
> > +
>
> Again, I think it's better to propagate the error than to swallow it
> and return a bool.
I agree. But doing that would make these functions return error in
different ways than the MST
intel_dp_get_sink_irq_esi(), intel_dp_ack_sink_irq_esi()
functions, which return a pass/fail bool. Imo the error return should be
the same for both the SST and MST variety of functions and converting
to propagate an error instead of a pass/fail bool should be done for
both (SST and MST), which is best done as a follow-up. Are you ok with
that?
> Other than that, it looks good to me. So if you agree with this
> change:
>
> Reviewed-by: Luca Coelho <luciano.coelho@tintel.com>
>
> --
> Cheers,
> Luca.
>
> > @@ -5393,27 +5457,6 @@ void intel_dp_check_link_state(struct intel_dp *intel_dp)
> > intel_encoder_link_check_queue_work(encoder, 0);
> > }
> >
> > -static bool intel_dp_get_and_ack_device_service_irq(struct intel_dp *intel_dp, u8 *irq_mask)
> > -{
> > - u8 val;
> > -
> > - *irq_mask = 0;
> > -
> > - if (drm_dp_dpcd_readb(&intel_dp->aux,
> > - DP_DEVICE_SERVICE_IRQ_VECTOR, &val) != 1)
> > - return false;
> > -
> > - if (!val)
> > - return true;
> > -
> > - if (drm_dp_dpcd_writeb(&intel_dp->aux, DP_DEVICE_SERVICE_IRQ_VECTOR, val) != 1)
> > - return false;
> > -
> > - *irq_mask = val;
> > -
> > - return true;
> > -}
> > -
> > static void intel_dp_handle_device_service_irq(struct intel_dp *intel_dp, u8 irq_mask)
> > {
> > struct intel_display *display = to_intel_display(intel_dp);
> > @@ -5428,31 +5471,6 @@ static void intel_dp_handle_device_service_irq(struct intel_dp *intel_dp, u8 irq
> > drm_dbg_kms(display->drm, "Sink specific irq unhandled\n");
> > }
> >
> > -static bool intel_dp_get_and_ack_link_service_irq(struct intel_dp *intel_dp, u8 *irq_mask)
> > -{
> > - u8 val;
> > -
> > - *irq_mask = 0;
> > -
> > - if (intel_dp->dpcd[DP_DPCD_REV] < DP_DPCD_REV_12)
> > - return true;
> > -
> > - if (drm_dp_dpcd_readb(&intel_dp->aux,
> > - DP_LINK_SERVICE_IRQ_VECTOR_ESI0, &val) != 1)
> > - return false;
> > -
> > - if (!val)
> > - return true;
> > -
> > - if (drm_dp_dpcd_writeb(&intel_dp->aux,
> > - DP_LINK_SERVICE_IRQ_VECTOR_ESI0, val) != 1)
> > - return false;
> > -
> > - *irq_mask = val;
> > -
> > - return true;
> > -}
> > -
> > static bool intel_dp_handle_link_service_irq(struct intel_dp *intel_dp, u8 irq_mask)
> > {
> > struct intel_display *display = to_intel_display(intel_dp);
> > @@ -5489,30 +5507,26 @@ static bool
> > intel_dp_short_pulse(struct intel_dp *intel_dp)
> > {
> > bool reprobe_needed = false;
> > - u8 irq_mask;
> > + u8 esi[4] = {};
> >
> > intel_dp_test_reset(intel_dp);
> >
> > + if (!intel_dp_get_and_ack_sink_irq_esi_sst(intel_dp, esi))
> > + return false;
> > +
> > /*
> > - * Now read the DPCD to see if it's actually running
> > * If the current value of sink count doesn't match with
> > - * the value that was stored earlier or dpcd read failed
> > - * we need to do full detection
> > + * the value that was stored earlier we need to do full
> > + * detection.
> > */
> > if (intel_dp_has_sink_count(intel_dp) &&
> > - drm_dp_read_sink_count(&intel_dp->aux) != intel_dp->sink_count)
> > + DP_GET_SINK_COUNT(esi[0]) != intel_dp->sink_count)
> > /* No need to proceed if we are going to do full detect */
> > return false;
> >
> > - if (!intel_dp_get_and_ack_device_service_irq(intel_dp, &irq_mask))
> > - return false;
> > + intel_dp_handle_device_service_irq(intel_dp, esi[1]);
> >
> > - intel_dp_handle_device_service_irq(intel_dp, irq_mask);
> > -
> > - if (!intel_dp_get_and_ack_link_service_irq(intel_dp, &irq_mask))
> > - return false;
> > -
> > - if (intel_dp_handle_link_service_irq(intel_dp, irq_mask))
> > + if (intel_dp_handle_link_service_irq(intel_dp, esi[3]))
> > reprobe_needed = true;
> >
> > /* Handle CEC interrupts, if any */
next prev parent reply other threads:[~2025-07-03 13:14 UTC|newest]
Thread overview: 66+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-26 8:20 [PATCH 00/20] drm/i915/dp: Fix few SST HPD IRQ handling issues Imre Deak
2025-06-26 8:20 ` [PATCH 01/20] drm/i915/dp_mst: Reprobe connector if the IRQ ESI read failed Imre Deak
2025-06-27 7:42 ` Luca Coelho
2025-06-26 8:20 ` [PATCH 02/20] drm/i915/dp_mst: Verify the link status always the same way Imre Deak
2025-06-26 8:31 ` Jani Nikula
2025-06-27 15:19 ` Imre Deak
2025-07-03 11:14 ` Luca Coelho
2025-06-26 8:20 ` [PATCH 03/20] drm/i915/dp_mst: Reuse intel_dp_check_link_state() in the HPD IRQ handler Imre Deak
2025-07-01 7:50 ` Luca Coelho
2025-06-26 8:20 ` [PATCH 04/20] drm/i915/dp: Handle a tunneling IRQ after acking it Imre Deak
2025-07-01 8:02 ` Luca Coelho
2025-07-01 8:32 ` Imre Deak
2025-07-01 8:47 ` Luca Coelho
2025-06-26 8:20 ` [PATCH 05/20] drm/i915/dp: Handle the RX_CAP_CHANGED HPD IRQ Imre Deak
2025-07-01 8:03 ` Luca Coelho
2025-07-01 10:30 ` Imre Deak
2025-07-03 11:16 ` Luca Coelho
2025-06-26 8:20 ` [PATCH 06/20] drm/i915/dp: Handle the DOWNSTREAM_PORT_STATUS_CHANGED event Imre Deak
2025-07-01 8:52 ` Luca Coelho
2025-06-26 8:20 ` [PATCH 07/20] drm/i915/dp: Don't clobber the encoder state in the HPD IRQ handler Imre Deak
2025-07-01 8:56 ` Luca Coelho
2025-06-26 8:20 ` [PATCH 08/20] drm/i915/dp: Remove the device service IRQ handling from connector detect Imre Deak
2025-07-01 9:00 ` Luca Coelho
2025-06-26 8:20 ` [PATCH 09/20] drm/i915/dp: Fix the device service IRQ DPCD_REV check Imre Deak
2025-07-01 9:01 ` Luca Coelho
2025-06-26 8:20 ` [PATCH 10/20] drm/i915/dp: Fix the link " Imre Deak
2025-07-01 9:12 ` Luca Coelho
2025-06-26 8:20 ` [PATCH 11/20] drm/i915/dp: Reprobe connector if getting/acking device IRQs fails Imre Deak
2025-06-26 9:12 ` Jani Nikula
2025-06-26 9:35 ` Imre Deak
2025-06-26 10:23 ` Jani Nikula
2025-06-26 10:43 ` Imre Deak
2025-06-26 10:46 ` Jani Nikula
2025-06-26 10:56 ` Imre Deak
2025-07-03 11:28 ` Luca Coelho
2025-07-03 11:43 ` Imre Deak
2025-07-07 10:05 ` Luca Coelho
2025-06-26 8:20 ` [PATCH 12/20] drm/i915/dp: Reprobe connector if getting/acking link service " Imre Deak
2025-07-03 11:37 ` Luca Coelho
2025-06-26 8:20 ` [PATCH 13/20] drm/i915/dp: Return early if getting/acking device " Imre Deak
2025-07-03 11:59 ` Luca Coelho
2025-06-26 8:20 ` [PATCH 14/20] drm/i915/dp: Return early if getting/ackink link " Imre Deak
2025-07-03 12:29 ` Luca Coelho
2025-06-26 8:20 ` [PATCH 15/20] drm/i915/dp: Read/ack sink count and sink IRQs for SST as it's done for MST Imre Deak
2025-07-03 13:02 ` Luca Coelho
2025-07-03 13:14 ` Imre Deak [this message]
2025-07-03 13:24 ` Luca Coelho
2025-06-26 8:20 ` [PATCH 16/20] drm/i915/dp: Print debug message for a sink connected off request Imre Deak
2025-07-03 13:03 ` Luca Coelho
2025-06-26 8:20 ` [PATCH 17/20] drm/i915/dp: Check SST link status while handling link service IRQs Imre Deak
2025-07-03 13:05 ` Luca Coelho
2025-06-26 8:20 ` [PATCH 18/20] drm/i915/dp_mst: Reuse intel_dp_handle_link_service_irq() Imre Deak
2025-07-03 13:07 ` Luca Coelho
2025-06-26 8:20 ` [PATCH 19/20] drm/i915/dp: Ack only the handled device service IRQs Imre Deak
2025-07-03 13:14 ` Luca Coelho
2025-07-03 13:18 ` Imre Deak
2025-07-03 13:27 ` Imre Deak
2025-07-03 13:34 ` Luca Coelho
2025-06-26 8:20 ` [PATCH 20/20] drm/i915/dp: Ack only the handled link " Imre Deak
2025-07-03 13:18 ` Luca Coelho
2025-06-26 8:37 ` ✓ CI.KUnit: success for drm/i915/dp: Fix few SST HPD IRQ handling issues Patchwork
2025-06-26 8:55 ` ✗ CI.checksparse: warning " Patchwork
2025-06-26 9:18 ` ✓ Xe.CI.BAT: success " Patchwork
2025-06-26 13:06 ` ✓ i915.CI.BAT: " Patchwork
2025-06-26 22:48 ` ✗ i915.CI.Full: failure " Patchwork
2025-06-27 8:21 ` ✗ Xe.CI.Full: " 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=aGaCIMPOqLdfGIWZ@ideak-desk \
--to=imre.deak@intel.com \
--cc=imre.deak@gmail.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=luca@coelho.fi \
/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.