On Tue, Jul 01, 2025 at 11:03:56AM +0300, Luca Coelho wrote: > On Thu, 2025-06-26 at 11:20 +0300, Imre Deak wrote: > > From: Imre Deak <imre.d...@gmail.com> > > > > Handle the RX_CAP_CHANGED IRQ, which a sink can use to indicate a DPRX > > capability change without disconnecting and reconnecting itself (i.e. > > through a short vs. long HPD pulse). Handle the IRQ by doing a full > > connector detection. > > > > Signed-off-by: Imre Deak <imre.d...@gmail.com> > > --- > > drivers/gpu/drm/i915/display/intel_dp.c | 8 +++++++- > > 1 file changed, 7 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c > > b/drivers/gpu/drm/i915/display/intel_dp.c > > index 453416b9e9bec..c2eadfa060c2d 100644 > > --- a/drivers/gpu/drm/i915/display/intel_dp.c > > +++ b/drivers/gpu/drm/i915/display/intel_dp.c > > @@ -5099,7 +5099,7 @@ intel_dp_check_mst_status(struct intel_dp *intel_dp) > > > > drm_dbg_kms(display->drm, "DPRX ESI: %4ph\n", esi); > > > > - ack[3] |= esi[3] & (LINK_STATUS_CHANGED | DP_TUNNELING_IRQ); > > + ack[3] |= esi[3] & (RX_CAP_CHANGED | LINK_STATUS_CHANGED | > > DP_TUNNELING_IRQ); > > > > intel_dp_mst_hpd_irq(intel_dp, esi, ack); > > > > @@ -5112,6 +5112,9 @@ intel_dp_check_mst_status(struct intel_dp *intel_dp) > > if (ack[1] & (DP_DOWN_REP_MSG_RDY | DP_UP_REQ_MSG_RDY)) > > drm_dp_mst_hpd_irq_send_new_request(&intel_dp->mst.mgr); > > > > + if (ack[3] & RX_CAP_CHANGED) > > + reprobe_needed = true; > > + > > if ((ack[3] & LINK_STATUS_CHANGED) || > > intel_dp->link.force_retrain) > > intel_dp_check_link_state(intel_dp); > > > > @@ -5424,6 +5427,9 @@ static bool intel_dp_check_link_service_irq(struct > > intel_dp *intel_dp) > > DP_LINK_SERVICE_IRQ_VECTOR_ESI0, val) != 1) > > return false; > > > > + if (val & RX_CAP_CHANGED) > > + reprobe_needed = true; > > + > > if (val & HDMI_LINK_STATUS_CHANGED) > > intel_dp_handle_hdmi_link_status_change(intel_dp); > > > > Same question as to the previous patch. What happens if the interrupt > is not actually handled?
For the MST case the same thing applies as discussed in the previous patch, the acked interrupts will be handled and only those interrupts will be acked that are also handled. In the SST case here all the interrupts handled were acked above. It's possible that an interrupt is acked and then not handled or at least indicated that it's handled on purpose (atm the only such case is CONNECTED_OFF_ENTRY_REQUESTED), but this will be addressed later in the patchset. > -- > Cheers, > Luca.
