1. 02 12月, 2016 1 次提交
  2. 01 12月, 2016 2 次提交
  3. 26 11月, 2016 1 次提交
  4. 25 11月, 2016 2 次提交
  5. 24 11月, 2016 5 次提交
  6. 23 11月, 2016 1 次提交
  7. 22 11月, 2016 5 次提交
  8. 21 11月, 2016 6 次提交
  9. 17 11月, 2016 8 次提交
  10. 16 11月, 2016 1 次提交
    • P
      drm/i915/bxt: Broxton decoupled MMIO · 85ee17eb
      Praveen Paneri 提交于
      Decoupled MMIO is an alternative way to access forcewake domain
      registers, which requires less cycles for a single read/write and
      avoids frequent software forcewake.
      This certainly gives advantage over the forcewake as this new
      mechanism “decouples” CPU cycles and allow them to complete even
      when GT is in a CPD (frequency change) or C6 state.
      
      This can co-exist with forcewake and we will continue to use forcewake
      as appropriate. E.g. 64-bit register writes to avoid writing 2 dwords
      separately and land into funny situations.
      
      v2:
      - Moved platform check out of the function and got rid of duplicate
       functions to find out decoupled power domain (Chris)
      - Added a check for forcewake already held and skipped decoupled
       access (Chris)
      - Skipped writing 64 bit registers through decoupled MMIO (Chris)
      
      v3:
      - Improved commit message with more info on decoupled mmio (Tvrtko)
      - Changed decoupled operation to enum and used u32 instead of
       uint_32 data type for register offset (Tvrtko)
      - Moved HAS_DECOUPLED_MMIO to device info (Tvrtko)
      - Added lookup table for converting fw_engine to pd_engine (Tvrtko)
      - Improved __gen9_decoupled_read and __gen9_decoupled_write
       routines (Tvrtko)
      
      v4:
      - Fixed alignment and variable names (Chris)
      - Write GEN9_DECOUPLED_REG0_DW1 register in just one go (Zhe Wang)
      
      v5:
      - Changed HAS_DECOUPLED_MMIO() argument name to dev_priv (Tvrtko)
      - Sanitize info->had_decoupled_mmio at init (Chris)
      Signed-off-by: NZhe Wang <zhe1.wang@intel.com>
      Signed-off-by: NPraveen Paneri <praveen.paneri@intel.com>
      Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/1479230360-22395-1-git-send-email-praveen.paneri@intel.com
      85ee17eb
  11. 15 11月, 2016 5 次提交
  12. 14 11月, 2016 1 次提交
    • J
      drm/i915: rename preliminary_hw_support to alpha_support · c007fb4a
      Jani Nikula 提交于
      The term "preliminary hardware support" has always caused confusion both
      among users and developers. It has always been about preliminary driver
      support for new hardware, and not so much about preliminary hardware. Of
      course, initially both the software and hardware are in early stages,
      but the distinction becomes more clear when the user picks up production
      hardware and an older kernel to go with it, with just the early support
      we had for the hardware at the time the kernel was released. The user
      has to specifically enable the alpha quality *driver* support for the
      hardware in that specific kernel version.
      
      Rename preliminary_hw_support to alpha_support to emphasize that the
      module parameter, config option, and flag are about software, not about
      hardware. Improve the language in help texts and debug logging as well.
      
      This appears to be a good time to do the change, as there are currently
      no platforms with preliminary^W alpha support.
      
      Cc: Rob Clark <robdclark@gmail.com>
      Cc: Dave Airlie <airlied@gmail.com>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
      Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/1477909108-18696-1-git-send-email-jani.nikula@intel.com
      c007fb4a
  13. 11 11月, 2016 2 次提交