1. 01 7月, 2013 1 次提交
  2. 13 6月, 2013 1 次提交
    • V
      drm/i915: Try harder to disable trickle feed on VLV · e0d8d59b
      Ville Syrjälä 提交于
      The specs are a bit unclear whether the per-plane trickle feed disable
      control exists on VLV. There is another trickle feed disable control
      in the MI_ARB register.
      
      After some experimentation it turns out both the DSPCNTR trickle feed
      bits and the MI_ARB bit can be toggled. However the DSPCNTR bits don't
      seem to have any effect.
      
      The MI_ARB bit, on the other hand, has a noticable effect. I performed
      an experiment where I reduced the FIFO size via DSPARB and observed the
      effect of the MI_ARB trickle feed bit on the display.
      
      Using a 1920x1080-60 mode, with MI_ARB=0x4 the display started to have
      problems with DSPARB=0x42424242, whereas with MI_ARB=0x0 the problems
      didn't start until DSPARB=0x09090909. This seems to confirm that the
      MI_ARB trickle feed bit actually does work.
      
      So replace the use of the DSPCNTR trickle feed bits with MI_ARB
      on VLV.
      
      v2: Amend commit message with results from experimentation
      Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      e0d8d59b
  3. 07 6月, 2013 5 次提交
  4. 06 6月, 2013 2 次提交
  5. 05 6月, 2013 2 次提交
  6. 04 6月, 2013 1 次提交
    • D
      drm/i915: store adjusted dotclock in adjusted_mode->clock · ff9a6750
      Daniel Vetter 提交于
      ... not the port clock. This allows us to kill the funny semantics
      around pixel_target_clock.
      
      Since the dpll code still needs the real port clock, add a new
      port_clock field to the pipe configuration. Handling the default case
      for that one is a bit tricky, since encoders might not consistently
      overwrite it when retrying the crtc/encoder bw arbitrage step in the
      compute config stage. Hence we need to always clear port_clock and
      update it again if the encoder hasn't put in something more specific.
      This can't be done in one step since the encoder might want to adjust
      the mode first.
      
      I was a bit on the fence whether I should subsume the pixel multiplier
      handling into the port_clock, too. But then I decided against this
      since it's on an abstract level still the dotclock of the adjusted
      mode, and only our hw makes it a bit special due to the separate pixel
      mulitplier setting (which requires that the dpll runs at the
      non-multiplied dotclock).
      
      So after this patch the adjusted_mode accurately describes the mode we
      feed into the port, after the panel fitter and pixel multiplier (or
      line doubling, if we ever bother with that) have done their job.
      Since the fdi link is between the pfit and the pixel multiplier steps
      we need to be careful with calculating the fdi link config.
      
      v2: Fix up ilk cpu pll handling.
      
      v3: Introduce an fdi_dotclock variable in ironlake_fdi_compute_config
      to make it clearer that we transmit the adjusted_mode without the
      pixel multiplier taken into account. The old code multiplied the the
      available link bw with the pixel multiplier, which results in the same
      fdi configuration, but is much more confusing.
      
      v4: Rebase on top of Imre's is_cpu_edp removal.
      
      v5: Rebase on top of Paulo's haswell watermark fixes, which introduce
      a new place which looked at the pixel_clock and so needed conversion.
      
      v6: Split out prep patches as requested by Paulo Zanoni. Also rebase
      on top of the fdi dotclock handling fix in the fdi lanes/bw
      computation code.
      
      Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> (v3)
      Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> (v6)
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      ff9a6750
  7. 01 6月, 2013 7 次提交
    • B
      drm/i915: make PM interrupt writes non-destructive · 4848405c
      Ben Widawsky 提交于
      PM interrupts have an expanded role on HSW. It helps route the EBOX
      interrupts. This patch is necessary to make the existing code which
      touches the mask, and enable registers more friendly to other code paths
      that also will need these registers.
      
      To be more explicit:
      At preinstall all interrupts are masked and disabled. This implies that
      preinstall should always happen before any enabling/disabling of RPS or
      other interrupts.
      
      The PMIMR is touched by the workqueue, so enable/disable touch IER and
      IIR. Similarly, the code currently expects IMR has no use outside of the
      RPS related interrupts so they unconditionally set 0, or ~0. We could
      use IER in the workqueue, and IMR elsewhere, but since the workqueue
      use-case is more transient the existing usage makes sense.
      
      Disable RPS events:
      IER := IER & ~GEN6_PM_RPS_EVENTS // Disable RPS related interrupts
      IIR := GEN6_PM_RPS_EVENTS // Disable any outstanding interrupts
      
      Enable RPS events:
      IER := IER | GEN6_PM_RPS_EVENTS // Enable the RPS related interrupts
      IIR := GEN6_PM_RPS_EVENTS // Make sure there were no leftover events
      (really shouldn't happen)
      
      v2: Shouldn't destroy PMIIR or PMIMR VEBOX interrupt state in
      enable/disable rps functions (Haihao)
      
      v3: Bug found by Chris where we were clearing the wrong bits at rps
      disable.
          expanded commit message
      
      v4: v3 was based off the wrong branch
      
      v5: Added the setting of PMIMR because of previous patch update
      
      CC: Chris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
      Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      4848405c
    • B
      drm/i915: Add PM regs to pre/post install · eda63ffb
      Ben Widawsky 提交于
      At the moment, these values are wiped out anyway by the rps
      enable/disable. That will be changed in the next patch though.
      
      v2: Add post install setup to address issue found by Damien in the next
      patch.
      replaced
      WARN_ON(dev_priv->rps.pm_iir != 0);
      with rps.pm_iir = 0;
      
      With the v2 of this patch and the deferred pm enabling (which changed
      since the original patches) we're now able to get PM interrupts before
      we've brought up enabled rps. At this point in boot, we don't want to do
      anything about it, so we simply ignore it. Since writing the original
      assertion, the code has changed quite a bit, and I believe removing this
      assertion is perfectly safe.
      Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
      Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com>
      [danvet: I don't agree with the justification to drop the WARN and
      added a FIXME to that effect.]
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      eda63ffb
    • P
      drm/i915: add support for 5/6 data buffer partitioning on Haswell · 861f3389
      Paulo Zanoni 提交于
      Now we compute the results for both 1/2 and 5/6 partitioning and then
      use hsw_find_best_result to choose which one to use.
      
      With this patch, Haswell watermarks support should be in good shape.
      The only improvement we're missing is the case where the primary plane
      is disabled: we always assume it's enabled, so we take it into
      consideration when calculating the watermarks.
      
      v2: - Check the latency when finding the best result
      Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      861f3389
    • P
      drm/i915: properly set HSW WM_LP watermarks · cca32e9a
      Paulo Zanoni 提交于
      We were previously only setting the WM_PIPE registers, now we are
      setting the LP watermark registers. This should allow deeper PC
      states, resulting in power savings.
      
      We're only using 1/2 data buffer partitioning for now.
      
      v2: Merge both hsw_compute_pri_wm_* functions (Ville)
      v3: - Simplify hsw_compute_wm_results (Ville)
          - Rebase due to changes on the previous patch
      v4: Unconfuse wm_lp/level (Ville)
      Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      cca32e9a
    • P
      drm/i915: properly set HSW WM_PIPE registers · 801bcfff
      Paulo Zanoni 提交于
      We were previously calling sandybridge_update_wm on HSW, but the SNB
      function didn't really match the HSW specification, so we were just
      writing the wrong values.
      
      With this patch, the haswell_update_wm function will set the correct
      values for the WM_PIPE registers, but it will still keep all the LP
      watermarks disabled.
      
      The patch may look a little bit over-complicated for now, but it's
      because much of the infrastructure for setting the LP watermarks is
      already in place, so we won't have too much code churn on the patch
      that sets the LP watermarks.
      
      v2: - Fix pixel_rate on panel fitter case (Ville)
          - Try to not overflow (Ville)
          - Remove useless variable (Ville)
          - Fix p->pri_horiz_pixels (Paulo)
      v3: - Fix rounding errors on hsw_wm_method2 (Ville)
      v4: - Fix memcmp bug (Paulo)
      Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      801bcfff
    • P
      drm/i915: add haswell_update_sprite_wm · 526682e9
      Paulo Zanoni 提交于
      On Haswell, whenever we change the sprites we need to completely
      recalculate all the watermarks, because the sprites are one of the
      parameters to the LP watermarks, so a change on the sprites may
      trigger a change on which LP levels are enabled.
      
      So on this commit we store all the parameters we need to store for
      proper recalculation of the Haswell WMs and then call
      haswell_update_wm.
      
      Notice that for now our haswell_update_wm function is not really using
      these parameters we're storing, but on the next commits we'll use
      these parameters.
      Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      526682e9
    • P
      drm/i915: add "enable" argument to intel_update_sprite_watermarks · 4c4ff43a
      Paulo Zanoni 提交于
      Because we want to call it from the "sprite disable" paths, since on
      Haswell we need to update the sprite watermarks when we disable
      sprites.
      
      For now, all this patch does is to add the "enable" argument and call
      intel_update_sprite_watermarks from inside ivb_disable_plane. This
      shouldn't change how the code behaves because on
      sandybridge_update_sprite_wm we just ignore the "!enable" case. The
      patches that implement Haswell watermarks will make use of the changes
      introduced by this patch.
      Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      4c4ff43a
  8. 24 5月, 2013 3 次提交
  9. 23 5月, 2013 1 次提交
    • P
      drm/i915: set FORCE_ARB_IDLE_PLANES workaround · 90a88643
      Paulo Zanoni 提交于
      Commit 1544d9d5 added a workaround
      inside haswell_init_clock_gating and mentioned it is "a workaround for
      early silicon revisions and should be removed later". This workaround
      is documented in bit 31 of PRI_CTL. I asked Arthur and he mentioned
      that setting FORCE_ARB_IDLE_PLANES replaces that workaround for the
      newer machines. So use the new one.
      
      Also notice that there's still another workaround for PRI_CTL that
      involves WM_DBG, but it's not the one we're reverting. And notice that
      we were previously setting WM_DBG_DISALLOW_MULTIPIPE_LP which disables
      the LP watermarks when more than one pipe is used, and we really don't
      want this because we need the LP watermarks if we want to reach deeper
      PC states.
      Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      [danvet: Add a comment for the w/a name Ville dug out of Bspec.]
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      90a88643
  10. 21 5月, 2013 5 次提交
  11. 11 5月, 2013 12 次提交