1. 19 11月, 2014 3 次提交
    • I
      drm/i915: sanitize rps irq enabling · 3cc134e3
      Imre Deak 提交于
      Atm we first enable the RPS interrupts then we clear any pending ones.
      By this we could lose an interrupt arriving after we unmasked it. This
      may not be a problem as the caller should handle such a race, but logic
      still calls for the opposite order. Also we can delay enabling the
      interrupts until after all the RPS initialization is ready with the
      following order:
      
      1. disable left-over RPS (earlier via intel_uncore_sanitize)
      2. clear any pending RPS interrupts
      3. initialize RPS
      4. enable RPS interrupts
      
      This also allows us to do the 2. and 4. step the same way for all
      platforms, so let's follow this order to simplifying things.
      
      Also make sure any queued interrupts are also cleared.
      
      v2:
      - rebase on the GEN9 patches where we don't support RPS yet, so we
        musn't enable RPS interrupts on it (Paulo)
      v3:
      - avoid enabling RPS interrupts on GEN>9 too (Paulo)
      - clarify the RPS init sequence in the log message (Chris)
      - add POSTING_READ to gen6_reset_rps_interrupts() (Paulo)
      - WARN if any PM_IIR bits are set in gen6_enable_rps_interrupts()
        (Paulo)
      Signed-off-by: NImre Deak <imre.deak@intel.com>
      Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      3cc134e3
    • I
      drm/i915: move rps irq disable one level up · e534770a
      Imre Deak 提交于
      We disable the RPS interrupts for all platforms at the same spot, so
      move it one level up in the callstack to simplify things.
      
      No functional change.
      
      v2:
      - rebase on the GEN9 patches where RPS isn't supported yet, so we don't
        need to disable RPS interrupts on it (Paulo)
      v3:
      - avoid disabling the interrupts on GEN>9 too (Paulo)
      Signed-off-by: NImre Deak <imre.deak@intel.com>
      Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      e534770a
    • T
      drm/i915: Extend pcode mailbox interface · 151a49d0
      Tom O'Rourke 提交于
      In sandybridge_pcode_read and sandybridge_pcode_write,
      extend the mbox parameter from u8 to u32.
      
      On Haswell and Sandybridge, bits 7:0 encode the mailbox
      command and bits 28:8 are used for address control for
      specific commands.
      
      Based on suggestion from Ville Syrjälä.
      Signed-off-by: NTom O'Rourke <Tom.O'Rourke@intel.com>
      Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      151a49d0
  2. 17 11月, 2014 7 次提交
  3. 14 11月, 2014 7 次提交
  4. 08 11月, 2014 22 次提交
  5. 24 10月, 2014 1 次提交