1. 01 10月, 2013 2 次提交
  2. 20 9月, 2013 1 次提交
    • B
      drm/i915: Add second slice l3 remapping · 35a85ac6
      Ben Widawsky 提交于
      Certain HSW SKUs have a second bank of L3. This L3 remapping has a
      separate register set, and interrupt from the first "slice". A slice is
      simply a term to define some subset of the GPU's l3 cache. This patch
      implements both the interrupt handler, and ability to communicate with
      userspace about this second slice.
      
      v2:  Remove redundant check about non-existent slice.
      Change warning about interrupts of unknown slices to WARN_ON_ONCE
      Handle the case where we get 2 slice interrupts concurrently, and switch
      the tracking of interrupts to be non-destructive (all Ville)
      Don't enable/mask the second slice parity interrupt for ivb/vlv (even
      though all docs I can find claim it's rsvd) (Ville + Bryan)
      Keep BYT excluded from L3 parity
      
      v3: Fix the slice = ffs to be decremented by one (found by Ville). When
      I initially did my testing on the series, I was using 1-based slice
      counting, so this code was correct. Not sure why my simpler tests that
      I've been running since then didn't pick it up sooner.
      Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      35a85ac6
  3. 19 9月, 2013 1 次提交
  4. 17 9月, 2013 1 次提交
    • V
      drm/i915: Fix port_clock and adjusted_mode.clock readout all over · 18442d08
      Ville Syrjälä 提交于
      Now that adjusted_mode.clock no longer contains the pixel_multiplier, we
      can kill the get_clock() callback and instead do the clock readout
      in get_pipe_config().
      
      Also i9xx_crtc_clock_get() can now extract the frequency of the PCH
      DPLL, so use it to populate port_clock accurately for PCH encoders.
      For DP in port A the encoder is still responsible for filling in
      port_clock. The FDI adjusted_mode.clock extraction is kept in place
      for some extra sanity checking, but we no longer need to pretend it's
      also the port_clock.
      
      In the encoder get_config() functions fill out adjusted_mode.clock
      based on port_clock and other details such as the DP M/N values,
      HDMI 12bpc and SDVO pixel_multiplier. For PCH encoders we will then
      do an extra sanity check to make sure the dotclock we derived from
      the FDI configuratiuon matches the one we derive from port_clock.
      
      DVO doesn't exist on PCH platforms, so it doesn't need to anything
      but assign adjusted_mode.clock=port_clock. And DDI is HSW only, so
      none of the changes apply there.
      
      v2: Use hdmi_reg color format to detect 12bpc HDMI case
      v3: Set adjusted_mode.clock for LVDS too
      v4: Rename ironlake_crtc_clock_get to ironlake_pch_clock_get,
          eliminate the useless link_freq variable.
      Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: NJani Nikula <jani.nikula@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      18442d08
  5. 06 9月, 2013 1 次提交
  6. 04 9月, 2013 8 次提交
  7. 30 8月, 2013 2 次提交
  8. 23 8月, 2013 2 次提交
  9. 22 8月, 2013 1 次提交
  10. 19 8月, 2013 1 次提交
  11. 07 8月, 2013 1 次提交
  12. 06 8月, 2013 1 次提交
  13. 27 7月, 2013 1 次提交
  14. 24 7月, 2013 2 次提交
    • P
      drm/i915: add functions to disable and restore LCPLL · be256dc7
      Paulo Zanoni 提交于
      For now there are no callers, but these functions are going to be
      needed for the code that allows Package C8+. Other future features may
      also require this code.
      
      Also merge the commit which introduced assert_can_disable_lcpll and
      had the following commit message:
      
      Most of the hardware needs to be disabled before LCPLL is disabled, so
      let's add a function to assert some of items listed in the "Display
      Sequences for LCPLL disabling" documentation.
      
      The idea is that hsw_disable_lcpll should not disable the hardware,
      the callers need to take care of calling hsw_disable_lcpll only once
      everything is already disabled.
      
      v2: - Rebase.
          - Fix D_COMP wait timeout.
      v3: - Use wait_for_atomic_use (Ben)
          - Remove/add a useless/needed POSTING_READ (Ben)
          - Early return in case LCPLL is already restored (Ben)
          - Add ndelay(100) (Ben)
      v4: - Merge the commit that added assert_can_disable_lcpll (Ben)
          - Add interrupt assertions (Ben)
      Reviewed-by: NBen Widawsky <ben@bwidawsk.net>
      Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      [danvet: Fix compile fail since there's no HAS_LP_PCH yet.]
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      be256dc7
    • P
      drm/i915: extend lpt_enable_clkout_dp · 2fa86a1f
      Paulo Zanoni 提交于
      Now it implements 3 different sequences from BSpec and also has
      support for ULT.
      
      v2: - Change IS_ULT checks for LPT-LP checks
          - Add check for LPT-LP + with_fdi (Ben)
          - Merge DBUFF0/GEN0 bit definitions since they're the same
            register (Ben)
          - DBUFF0 (1<<0) is Disable, not Enable
      Reviewed-by: NBen Widawsky <ben@bwidawsk.net>
      Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      2fa86a1f
  15. 20 7月, 2013 1 次提交
  16. 18 7月, 2013 3 次提交
  17. 16 7月, 2013 1 次提交
  18. 11 7月, 2013 2 次提交
    • D
      drm/i915: improve GEN7_ERR_INT clearing for fifo underrun reporting · 7336df65
      Daniel Vetter 提交于
      Same treatment as for SERR_INT: If we clear only the bit for the pipe
      we're enabling (but unconditionally) then we can always check for
      possible underruns after having disabled the interrupt. That way pipe
      underruns won't be lost, but at worst only get reported in a delayed
      fashion.
      
      v2: The same logic bug as in the SERR handling change also existed
      here. The same bugfix of only reporting missed underruns when the
      error interrupt was masked applies, too.
      
      v3: Do the same fixes as for the SERR handling that Paulo suggested in
      his review:
      - s/%i/%c/ fix in the debug output
      - move the DE_ERR_INT_IVB read into the respective if block
      
      Cc: Paulo Zanoni <przanoni@gmail.com>
      Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      [danvet: Fix up the checkpatch bikeshed Paulo noticed.]
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      7336df65
    • D
      drm/i915: improve SERR_INT clearing for fifo underrun reporting · 1dd246fb
      Daniel Vetter 提交于
      The current code won't report any fifo underruns on cpt if just one
      pipe has fifo underrun reporting disabled. We can't enable the
      interrupts, but we can still check the per-transcoder bits and so
      report the underrun delayed if:
      - We always clear the transcoder's bit (and none of the other bits)
        when enabling.
      - We check the transcoder's bit after disabling (to avoid racing with
        the interrupt handler).
      
      v2: I've forgotten to actually remove the old SERR_INT clearing.
      
      v3: Use transcoder_name as suggested by Paulo Zanoni. Paulo also
      noticed a logic bug: When an underrun interrupt fires we report it
      both in the interrupt handler and when checking for underruns when
      disabling it in cpt_set_fifo_underrun_reporting. But that second check
      is only required if the interrupt is disabled and we're switching of
      underrun reporting (e.g. because we're disabling the crtc). Hence
      check for that condition.
      
      At first I wanted to rework the code to pass that bit of information
      from the uppper functions down to cpt_set_fifo_underrun_reporting. But
      that turned out too messy. Hence the quick&dirty check whether the
      south error interrupt source is masked off or not.
      
      v4: Streamline the control flow a bit.
      
      v5: s/pipe/pch transcoder/ in the dmesg output, suggested by Paulo.
      
      v6: Review from Paulo:
      - Reorder the was_enabled assignment to only read the register when we
        need it. Also add a comment that we need to do that before updating
        the register.
      - s/%i/%c/ fix for the debug output.
      - Fix the checkpath complaint in the SERR_INT_TRANS_FIFO_UNDERRUN
        #define.
      
      v7: Hopefully put that elusive SERR hunk back into this patch, spotted
      by Paulo.
      
      Cc: Paulo Zanoni <przanoni@gmail.com>
      Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      1dd246fb
  19. 09 7月, 2013 1 次提交
  20. 02 7月, 2013 1 次提交
  21. 01 7月, 2013 4 次提交
  22. 18 6月, 2013 1 次提交
  23. 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