Re: [v2 5/6] i915/dp/fec: Configure the Forward Error Correction bits.

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

 




>-----Original Message-----
>From: Ville Syrjälä [mailto:ville.syrjala@xxxxxxxxxxxxxxx]
>Sent: Friday, October 19, 2018 4:12 PM
>To: Navare, Manasi D <manasi.d.navare@xxxxxxxxx>
>Cc: Srivatsa, Anusha <anusha.srivatsa@xxxxxxxxx>; intel-
>gfx@xxxxxxxxxxxxxxxxxxxxx; Singh, Gaurav K <gaurav.k.singh@xxxxxxxxx>; Jani
>Nikula <jani.nikula@xxxxxxxxxxxxxxx>
>Subject: Re: [v2 5/6] i915/dp/fec: Configure the Forward Error Correction bits.
>
>On Fri, Oct 19, 2018 at 01:29:05PM -0700, Manasi Navare wrote:
>> On Fri, Oct 19, 2018 at 10:58:29PM +0300, Ville Syrjälä wrote:
>> > On Fri, Oct 19, 2018 at 12:24:43PM -0700, Manasi Navare wrote:
>> > > On Fri, Oct 19, 2018 at 09:39:11PM +0300, Ville Syrjälä wrote:
>> > > > On Mon, Oct 15, 2018 at 02:50:36PM -0700, Anusha Srivatsa wrote:
>> > > > > If FEC is supported, the corresponding DP_TP_CTL register bits
>> > > > > have to be configured.
>> > > > >
>> > > > > The driver has to program the FEC_ENABLE in DP_TP_CTL[30]
>> > > > > register and wait till FEC_STATUS in DP_TP_CTL[28] is 1.
>> > > > > Also add the warn message to make sure that the control
>> > > > > register is already active while enabling FEC.
>> > > > >
>> > > > > v2:
>> > > > > - Change commit message. Configure fec state after
>> > > > >   link training (Manasi, Gaurav)
>> > > > > - Remove redundent checks (Manasi)
>> > > > > - Remove the registers that get added automagically (Anusha)
>> > > > >
>> > > > > v3: s/intel_dp_set_fec_state()/intel_dp_enable_fec_state()
>> > > > > (Gaurav)
>> > > > >
>> > > > > v4: rebased.
>> > > > >
>> > > > > Cc: Gaurav K Singh <gaurav.k.singh@xxxxxxxxx>
>> > > > > Cc: Jani Nikula <jani.nikula@xxxxxxxxxxxxxxx>
>> > > > > Cc: Ville Syrjala <ville.syrjala@xxxxxxxxxxxxxxx>
>> > > > > Cc: Manasi Navare <manasi.d.navare@xxxxxxxxx>
>> > > > > Signed-off-by: Anusha Srivatsa <anusha.srivatsa@xxxxxxxxx>
>> > > > > ---
>> > > > >  drivers/gpu/drm/i915/i915_reg.h  |  2 ++
>> > > > > drivers/gpu/drm/i915/intel_ddi.c |  2 ++
>> > > > > drivers/gpu/drm/i915/intel_dp.c  | 27
>> > > > > +++++++++++++++++++++++++++  drivers/gpu/drm/i915/intel_drv.h
>> > > > > |  3 ++-
>> > > > >  4 files changed, 33 insertions(+), 1 deletion(-)
>> > > > >
>> > > > > diff --git a/drivers/gpu/drm/i915/i915_reg.h
>> > > > > b/drivers/gpu/drm/i915/i915_reg.h index
>> > > > > bcde78bc0027..c8d7fdcd7823 100644
>> > > > > --- a/drivers/gpu/drm/i915/i915_reg.h
>> > > > > +++ b/drivers/gpu/drm/i915/i915_reg.h
>> > > > > @@ -9093,6 +9093,7 @@ enum skl_power_gate {
>> > > > >  #define _DP_TP_CTL_B			0x64140
>> > > > >  #define DP_TP_CTL(port) _MMIO_PORT(port, _DP_TP_CTL_A,
>_DP_TP_CTL_B)
>> > > > >  #define  DP_TP_CTL_ENABLE			(1 << 31)
>> > > > > +#define  DP_TP_CTL_FEC_ENABLE			(1 << 30)
>> > > > >  #define  DP_TP_CTL_MODE_SST			(0 << 27)
>> > > > >  #define  DP_TP_CTL_MODE_MST			(1 << 27)
>> > > > >  #define  DP_TP_CTL_FORCE_ACT			(1 << 25)
>> > > > > @@ -9111,6 +9112,7 @@ enum skl_power_gate {
>> > > > >  #define _DP_TP_STATUS_A			0x64044
>> > > > >  #define _DP_TP_STATUS_B			0x64144
>> > > > >  #define DP_TP_STATUS(port) _MMIO_PORT(port, _DP_TP_STATUS_A,
>> > > > > _DP_TP_STATUS_B)
>> > > > > +#define  DP_TP_STATUS_FEC_ENABLE_LIVE		(1 << 28)
>> > > > >  #define  DP_TP_STATUS_IDLE_DONE			(1 << 25)
>> > > > >  #define  DP_TP_STATUS_ACT_SENT			(1 << 24)
>> > > > >  #define  DP_TP_STATUS_MODE_STATUS_MST		(1 << 23)
>> > > > > diff --git a/drivers/gpu/drm/i915/intel_ddi.c
>> > > > > b/drivers/gpu/drm/i915/intel_ddi.c
>> > > > > index f531900165bf..67c013ea4d39 100644
>> > > > > --- a/drivers/gpu/drm/i915/intel_ddi.c
>> > > > > +++ b/drivers/gpu/drm/i915/intel_ddi.c
>> > > > > @@ -2911,6 +2911,8 @@ static void intel_ddi_pre_enable_dp(struct
>intel_encoder *encoder,
>> > > > >  					      DP_DECOMPRESSION_EN);
>> > > > >  	intel_dp_sink_set_fec_ready(intel_dp, crtc_state,
>DP_FEC_READY);
>> > > > >  	intel_dp_start_link_train(intel_dp);
>> > > > > +	intel_dp_enable_fec_state(intel_dp, crtc_state);
>> > > >
>> > > > This doesn't look like the correct spot. According to the spec
>> > > > it should be after stop_link_train() (where we set DP_TP_CTL to
>> > > > to normal).
>> > > >
>> > >
>> > > Yes I see in the display port enabling sequence page of the spec,
>> > > that it says enable FEC after DP_TP_CTL is set to Normal. Also the
>> > > FEC page says that this should be enabled only after ensuring that
>> > > link training completed. So according to that this call should happen after
>intel_dp_stop_link_train().
>> > > So yes move this to after intel_dp_stop_link_training().
>> > >
>> > > > > +
>> > > > >  	if (port != PORT_A || INTEL_GEN(dev_priv) >= 9)
>> > > > >  		intel_dp_stop_link_train(intel_dp);
>> > > > >
>> > > > > diff --git a/drivers/gpu/drm/i915/intel_dp.c
>> > > > > b/drivers/gpu/drm/i915/intel_dp.c index
>> > > > > b4e8af3142a2..b9f85502d9ff 100644
>> > > > > --- a/drivers/gpu/drm/i915/intel_dp.c
>> > > > > +++ b/drivers/gpu/drm/i915/intel_dp.c
>> > > > > @@ -3017,6 +3017,33 @@ void intel_dp_sink_set_fec_ready(struct
>intel_dp *intel_dp,
>> > > > >  		DRM_DEBUG_KMS("Failed to get FEC enabled in
>sink\n");  }
>> > > > >
>> > > > > +void intel_dp_enable_fec_state(struct intel_dp *intel_dp,
>> > > > > +			       const struct intel_crtc_state *crtc_state) {
>> > > > > +	struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
>> > > > > +	struct intel_digital_port *intel_dig_port =
>dp_to_dig_port(intel_dp);
>> > > > > +	enum port port = intel_dig_port->base.port;
>> > > > > +	u32 val;
>> > > > > +
>> > > > > +	/* FEC support exists for DP 1.4 only */
>> > > > > +	if (intel_dp_is_edp(intel_dp))
>> > > > > +		return;
>> > > > > +
>> > > > > +	/* If Display Compression is not enabled, FEC need not be
>configured */
>> > > > > +	if (!crtc_state->dsc_params.compression_enable)
>> > > > > +		return;
>> > > > > +
>> > > > > +	val = I915_READ(DP_TP_CTL(port));
>> > > > > +	val |= DP_TP_CTL_FEC_ENABLE;
>> > > > > +	I915_WRITE(DP_TP_CTL(port), val);
>> > > > > +
>> > > > > +	if (intel_wait_for_register(dev_priv, DP_TP_STATUS(port),
>> > > > > +				    DP_TP_STATUS_FEC_ENABLE_LIVE,
>> > > > > +				    DP_TP_STATUS_FEC_ENABLE_LIVE,
>> > > > > +				    1))
>> > > > > +		DRM_ERROR("Timed out waiting for FEC Enable
>Status\n"); }
>> > > >
>> > > > There is no reason to stick these into intel_dp.c when the only
>> > > > caller is in intel_ddi.c.
>> > > >
>> > >
>> > > So may be move the set_dsc_state function also from intel_dp.c to
>> > > intel_ddi.c Or does it make sense to move all these DSC related functions
>including fec to intel_dsc.c?
>> > >
>> > > > We also seem to be missing platform checks. FEC doesn't appear
>> > > > to be a thing prior to ICL. I guess the edp+compression_enable
>> > > > takes care of this, but I think I'd rather stick a new
>> > > > fec_enable bool into the crtc state. That way we get can add it to the
>state checker as well.
>> > > >
>> > >
>> > > fec_enable can be added to crtc_state->dsc_params may be?
>> >
>> > Isn't FEC something that can be used w/o DSC too?
>> >
>>
>> Nope, FEC always goes hand in hand with DSC on external DP and that
>> DSC on external DP cannot be enabled without FEC.
>
>Sure, DSC needs FEC. But FEC doesn't need DSC. At least if I'm reading the spec
>correctly.
>
>FEC is enabled for the entire main link, so everything getting transported over it
>get FECced. DSC on the other hand operates on on a stream level. So assuming a
>MST branch device that can do FEC but can't do DSC you should be able transport
>both compressed and uncompressed streams through it simultaneously. Kinda
>makes me think that we want to enable FEC for MST whenever the downstream
>device supports it.

FEC for MST modes is not supported for ICL platform. We could extend this for future platforms  for branch devices that support FEC.

>And I suppose we could also consider using FEC opportunistically for
>uncompressed SST when we have the extra link bandwidth to handle the extra
>overhead.

Yes. The requirement though is for compressed streams. I am not sure if we will have to pay any power penalty for SST. Also my understanding is that if a few symbols in a non-compressed stream are in error, then only those symbols will be in error. These errors do not cause other pixels to get corrupted. In compressed streams, if a few symbols are in error, it can cause the entire slice to get corrupted. Will we be getting any much return on non-compressed streams?

Anusha 
>>
>> Manasi
>>
>> > >
>> > > Manasi
>> > >
>> > > > > +
>> > > > >  /* If the sink supports it, try to set the power state
>> > > > > appropriately */  void intel_dp_sink_dpms(struct intel_dp
>> > > > > *intel_dp, int mode)  { diff --git
>> > > > > a/drivers/gpu/drm/i915/intel_drv.h
>> > > > > b/drivers/gpu/drm/i915/intel_drv.h
>> > > > > index fbc9fa06e8be..e51d612a9f42 100644
>> > > > > --- a/drivers/gpu/drm/i915/intel_drv.h
>> > > > > +++ b/drivers/gpu/drm/i915/intel_drv.h
>> > > > > @@ -1532,7 +1532,6 @@ intel_encoder_current_mode(struct
>> > > > > intel_encoder *encoder);  bool intel_port_is_tc(struct
>> > > > > drm_i915_private *dev_priv, enum port port);  enum tc_port
>intel_port_to_tc(struct drm_i915_private *dev_priv,
>> > > > >  			      enum port port);
>> > > > > -
>> > > > >  enum pipe intel_get_pipe_from_connector(struct
>> > > > > intel_connector *connector);  int
>intel_get_pipe_from_crtc_id_ioctl(struct drm_device *dev, void *data,
>> > > > >  				      struct drm_file *file_priv); @@ -
>1712,6 +1711,8 @@
>> > > > > void intel_dp_sink_set_decompression_state(struct intel_dp
>> > > > > *intel_dp,  void intel_dp_sink_set_fec_ready(struct intel_dp *intel_dp,
>> > > > >  				 const struct intel_crtc_state
>*crtc_state,
>> > > > >  				 int state);
>> > > > > +void intel_dp_enable_fec_state(struct intel_dp *intel_dp,
>> > > > > +			       const struct intel_crtc_state *crtc_state);
>> > > > >  void intel_dp_encoder_reset(struct drm_encoder *encoder);
>> > > > > void intel_dp_encoder_suspend(struct intel_encoder
>> > > > > *intel_encoder);  void intel_dp_encoder_destroy(struct
>> > > > > drm_encoder *encoder);
>> > > > > --
>> > > > > 2.17.1
>> > > >
>> > > > --
>> > > > Ville Syrjälä
>> > > > Intel
>> >
>> > --
>> > Ville Syrjälä
>> > Intel
>
>--
>Ville Syrjälä
>Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx




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

  Powered by Linux