[PATCH 05/20] drm/i915/dp: Handle the RX_CAP_CHANGED HPD IRQ

[Imre Deak]

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.deak at 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.deak at 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.