Re: [PATCH 5/5] drm/i915/dp: Move hdcp link check function into short pulse handler

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 2018-09-19 at 21:05 +0300, Ville Syrjälä wrote:
> On Wed, Sep 19, 2018 at 05:49:33PM +0000, Pandiyan, Dhinakaran wrote:
> > On Wed, 2018-09-19 at 20:30 +0300, Ville Syrjälä wrote:
> > > On Tue, Sep 18, 2018 at 12:20:09AM -0700, Dhinakaran Pandiyan
> > > wrote:
> > > > This way all short pulse handlers except MST are in one place.
> > > > 
> > > > Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.c
> > > > om>
> > > > ---
> > > >  drivers/gpu/drm/i915/intel_dp.c | 6 +++---
> > > >  1 file changed, 3 insertions(+), 3 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > > > b/drivers/gpu/drm/i915/intel_dp.c
> > > > index 123c2eafafab..03d2c6426016 100644
> > > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > > @@ -4501,6 +4501,9 @@ intel_dp_short_pulse(struct intel_dp
> > > > *intel_dp)
> > > >  		drm_kms_helper_hotplug_event(&dev_priv->drm);
> > > >  	}
> > > >  
> > > > +	/* Short pulse can signify loss of hdcp authentication
> > > > */
> > > > +	intel_hdcp_check_link(intel_dp->attached_connector);
> > > > +
> > > >  	return true;
> > > >  }
> > > >  
> > > > @@ -5634,9 +5637,6 @@ intel_dp_hpd_pulse(struct
> > > > intel_digital_port
> > > > *intel_dig_port, bool long_hpd)
> > > >  
> > > >  		handled = intel_dp_short_pulse(intel_dp);
> > > >  
> > > > -		/* Short pulse can signify loss of hdcp
> > > > authentication */
> > > > -		intel_hdcp_check_link(intel_dp-
> > > > > attached_connector);
> > > > 
> > > > -
> > > 
> > > This changes the behaviour to skip intel_hdcp_check_link() when
> > > intel_dp_short_pulse() decides to fall back to full detect. Not
> > > sure
> > > if
> > > that's OK or not.
> > 
> > I'm thinking we should move the decision to fallback to the very
> > end of
> > intel_dp_short_pulse(). 
> 
> Perhaps. The entire "how do we process hpd_irqs correctly?" thing
> needs some real thought.

One noteworthy information I remember from my last reading of the spec
is that the sink is required to generate a distinct IRQ_HPD to request
retraining. But then, if we get two interrupts in quick succession, a
queued work item will end up handling both. 

> 
> > 
> > The benefit we get is to disable PSR if the sink complained of PSR
> > errors and then check if the hardware retrained the link correctly
> > after we disabled.
> > 
> > 
> > > 
> > > >  		if (!handled)
> > > >  			goto put_power;
> > > >  	}
> > > > -- 
> > > > 2.14.1
> > > > 
> > > > _______________________________________________
> > > > Intel-gfx mailing list
> > > > Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
> > > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> > > 
> > > 
> 
> 
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux