1. 25 7月, 2013 2 次提交
    • C
      drm/i915: Use a private interface for register access within GT · 6af5d92f
      Chris Wilson 提交于
      The GT functions for enabling register access also need to occasionally
      write to and read from registers. To avoid the potential recursion as we
      modify the public interface to be stricter, introduce a private register
      access API for the GT functions.
      
      v2: Rebase
      v3: Rebase onto uncore
      v4: Use raw interfaces consistently so that we only use the low-level
          readN functions from a single location.
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: NBen Widawsky <ben@bwidawsk.net>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      6af5d92f
    • C
      drm/i915: Colocate all GT access routines in the same file · 907b28c5
      Chris Wilson 提交于
      Currently, the register access code is split between i915_drv.c and
      intel_pm.c. It only bares a superficial resemblance to the reset of the
      powermanagement code, so move it all into its own file. This is to ease
      further patches to enforce serialised register access.
      
      v2: Scan for random abuse of I915_WRITE_NOTRACE
      v3: Take the opportunity to rename the GT functions as uncore. Uncore is
      the term used by the hardware design (and bspec) for all functions
      outside of the GPU (and CPU) cores in what is also known as the System
      Agent.
      v4: Rebase onto SNB rc6 fixes
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: NBen Widawsky <ben@bwidawsk.net>
      [danvet: Wrestle patch into applying and inline
      intel_uncore_early_sanitize (plus move the old comment to the new
      function). Also keep the _santize postfix for intel_uncore_sanitize.]
      [danvet: Squash in fixup spotted by Chris on irc: We need to call
      intel_pm_init before intel_uncore_sanitize since the later will call
      cancel_work on the delayed rps setup work the former initializes.]
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      907b28c5