Op 20-11-17 om 15:01 schreef Ville Syrjälä:
> On Mon, Nov 20, 2017 at 01:23:35PM +0100, Maarten Lankhorst wrote:
>> ips_enabled was used as a variable of whether IPS can be enabled or not,
>> but should be used to test whether IPS is actually enabled.
>>
>> Changes since v1:
>> - Call needs_modeset on new crtc state. (Ville)
>> - IPS can be enabled with sprite plane enabled too. (Ville)
>> - Fix CDCLK vs IPS workaround. (Ville)
>>
>> Signed-off-by: Maarten Lankhorst <maarten.lankho...@linux.intel.com>
>> ---
>>  drivers/gpu/drm/i915/intel_cdclk.c    |   2 +-
>>  drivers/gpu/drm/i915/intel_display.c  | 119 
>> +++++++++++++++++++---------------
>>  drivers/gpu/drm/i915/intel_drv.h      |   1 +
>>  drivers/gpu/drm/i915/intel_pipe_crc.c |   2 -
>>  4 files changed, 67 insertions(+), 57 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_cdclk.c 
>> b/drivers/gpu/drm/i915/intel_cdclk.c
>> index e8884c2ade98..30affa7903d7 100644
>> --- a/drivers/gpu/drm/i915/intel_cdclk.c
>> +++ b/drivers/gpu/drm/i915/intel_cdclk.c
>> @@ -1896,7 +1896,7 @@ int intel_crtc_compute_min_cdclk(const struct 
>> intel_crtc_state *crtc_state)
>>      min_cdclk = intel_pixel_rate_to_cdclk(dev_priv, crtc_state->pixel_rate);
>>  
>>      /* pixel rate mustn't exceed 95% of cdclk with IPS on BDW */
>> -    if (IS_BROADWELL(dev_priv) && crtc_state->ips_enabled)
>> +    if (IS_BROADWELL(dev_priv) && hsw_pipe_config_ips_capable(crtc_state))
>>              min_cdclk = DIV_ROUND_UP(min_cdclk * 100, 95);
> I think either we should drop this entirely and make the
> ips_compute_config() check logical.cdclk instead of max_cdclk,
> or we stick to the max_cdclk based check but move it into 
> hsw_pipe_config_ips_capable(). Otherwise we would end up
> rejecting any mode whose pixel rate exceed the 95% cdclk
> limit.
>
>>  
>>      /* BSpec says "Do not use DisplayPort with CDCLK less than 432 MHz,
>> diff --git a/drivers/gpu/drm/i915/intel_display.c 
>> b/drivers/gpu/drm/i915/intel_display.c
>> index 3b3dec1e6640..0b9ba415839a 100644
>> --- a/drivers/gpu/drm/i915/intel_display.c
>> +++ b/drivers/gpu/drm/i915/intel_display.c
>> @@ -4870,7 +4870,7 @@ void hsw_enable_ips(const struct intel_crtc_state 
>> *crtc_state)
>>      struct drm_device *dev = crtc->base.dev;
>>      struct drm_i915_private *dev_priv = to_i915(dev);
>>  
>> -    if (!crtc->config->ips_enabled)
>> +    if (!crtc_state->ips_enabled)
>>              return;
>>  
>>      /*
>> @@ -4966,14 +4966,6 @@ intel_post_enable_primary(struct drm_crtc *crtc,
>>      struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
>>      int pipe = intel_crtc->pipe;
>>  
>> -    /*
>> -     * FIXME IPS should be fine as long as one plane is
>> -     * enabled, but in practice it seems to have problems
>> -     * when going from primary only to sprite only and vice
>> -     * versa.
>> -     */
>> -    hsw_enable_ips(new_crtc_state);
>> -
>>      /*
>>       * Gen2 reports pipe underruns whenever all planes are disabled.
>>       * So don't enable underrun reporting before at least some planes
>> @@ -4989,10 +4981,9 @@ intel_post_enable_primary(struct drm_crtc *crtc,
>>      intel_check_pch_fifo_underruns(dev_priv);
>>  }
>>  
>> -/* FIXME move all this to pre_plane_update() with proper state tracking */
>> +/* FIXME get rid of this and use pre_plane_update */
>>  static void
>> -intel_pre_disable_primary(struct drm_crtc *crtc,
>> -                      const struct intel_crtc_state *old_crtc_state)
>> +intel_pre_disable_primary_noatomic(struct drm_crtc *crtc)
>>  {
>>      struct drm_device *dev = crtc->dev;
>>      struct drm_i915_private *dev_priv = to_i915(dev);
>> @@ -5001,32 +4992,12 @@ intel_pre_disable_primary(struct drm_crtc *crtc,
>>  
>>      /*
>>       * Gen2 reports pipe underruns whenever all planes are disabled.
>> -     * So diasble underrun reporting before all the planes get disabled.
>> -     * FIXME: Need to fix the logic to work when we turn off all planes
>> -     * but leave the pipe running.
>> +     * So disable underrun reporting before all the planes get disabled.
>>       */
>>      if (IS_GEN2(dev_priv))
>>              intel_set_cpu_fifo_underrun_reporting(dev_priv, pipe, false);
>>  
>> -    /*
>> -     * FIXME IPS should be fine as long as one plane is
>> -     * enabled, but in practice it seems to have problems
>> -     * when going from primary only to sprite only and vice
>> -     * versa.
>> -     */
>> -    hsw_disable_ips(old_crtc_state);
>> -}
>> -
>> -/* FIXME get rid of this and use pre_plane_update */
>> -static void
>> -intel_pre_disable_primary_noatomic(struct drm_crtc *crtc)
>> -{
>> -    struct drm_device *dev = crtc->dev;
>> -    struct drm_i915_private *dev_priv = to_i915(dev);
>> -    struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
>> -    int pipe = intel_crtc->pipe;
>> -
>> -    intel_pre_disable_primary(crtc, to_intel_crtc_state(crtc->state));
>> +    hsw_disable_ips(to_intel_crtc_state(crtc->state));
>>  
>>      /*
>>       * Vblank time updates from the shadow to live plane control register
>> @@ -5058,6 +5029,11 @@ static void intel_post_plane_update(struct 
>> intel_crtc_state *old_crtc_state)
>>      if (pipe_config->update_wm_post && pipe_config->base.active)
>>              intel_update_watermarks(crtc);
>>  
>> +    if (!old_crtc_state->ips_enabled ||
>> +        needs_modeset(&pipe_config->base) ||
>> +        pipe_config->update_pipe)
> Hmm. So thinking more about this I guess I figured out why you put the
> update_pipe check here. On BDW the initial old_crtc_state will have
> ips_enabled=true since the readout now always makes it so. Thus if we
> skip the initial modeset we would not turn on IPS even if a suitable
> set of planes is enabled.
>
> I think it would be more clear to check for the INHERITED thing
> specifically. Also that would avoid paying the cost of the pcode
> access every time we have update_pipe==true and ips_enabled==true.
In case of update_pipe = true we already avoided a modeset, which is an order 
more expensive. I'm not too worried about it. :p
Maybe hsw_ips_pre/post_update with the relevant checks?
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Reply via email to