1. 23 8月, 2013 2 次提交
    • P
      drm/i915: add i915.pc8_timeout function · 90058745
      Paulo Zanoni 提交于
      We currently only enter PC8+ after all its required conditions are
      met, there's no rendering, and we stay like that for at least 5
      seconds.
      
      I chose "5 seconds" because this value is conservative and won't make
      us enter/leave PC8+ thousands of times after the screen is off: some
      desktop environments have applications that wake up and do rendering
      every 1-3 seconds, even when the screen is off and the machine is
      completely idle.
      
      But when I was testing my PC8+ patches I set the default value to
      100ms so I could use the bad-behaving desktop environments to
      stress-test my patches. I also thought it would be a good idea to ask
      our power management team to test different values, but I'm pretty
      sure they would ask me for an easy way to change the timeout. So to
      help these 2 cases I decided to create an option that would make it
      easier to change the default value. I also expect people making
      specific products that use our driver could try to find the perfect
      timeout for them.
      
      Anyway, fixing the bad-behaving applications will always lead to
      better power savings than just changing the timeout value: you need to
      stop waking the Kernel, not quickly put it back to sleep again after
      you wake it for nothing. Bad sleep leads to bad mood!
      Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Reviewed-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      90058745
    • P
      drm/i915: allow package C8+ states on Haswell (disabled) · c67a470b
      Paulo Zanoni 提交于
      This patch allows PC8+ states on Haswell. These states can only be
      reached when all the display outputs are disabled, and they allow some
      more power savings.
      
      The fact that the graphics device is allowing PC8+ doesn't mean that
      the machine will actually enter PC8+: all the other devices also need
      to allow PC8+.
      
      For now this option is disabled by default. You need i915.allow_pc8=1
      if you want it.
      
      This patch adds a big comment inside i915_drv.h explaining how it
      works and how it tracks things. Read it.
      
      v2: (this is not really v2, many previous versions were already sent,
           but they had different names)
          - Use the new functions to enable/disable GTIMR and GEN6_PMIMR
          - Rename almost all variables and functions to names suggested by
            Chris
          - More WARNs on the IRQ handling code
          - Also disable PC8 when there's GPU work to do (thanks to Ben for
            the help on this), so apps can run caster
          - Enable PC8 on a delayed work function that is delayed for 5
            seconds. This makes sure we only enable PC8+ if we're really
            idle
          - Make sure we're not in PC8+ when suspending
      v3: - WARN if IRQs are disabled on __wait_seqno
          - Replace some DRM_ERRORs with WARNs
          - Fix calls to restore GT and PM interrupts
          - Use intel_mark_busy instead of intel_ring_advance to disable PC8
      v4: - Use the force_wake, Luke!
      v5: - Remove the "IIR is not zero" WARNs
          - Move the force_wake chunk to its own patch
          - Only restore what's missing from RC6, not everything
      Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      c67a470b
  2. 22 8月, 2013 1 次提交
  3. 25 7月, 2013 1 次提交
    • 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
  4. 21 7月, 2013 1 次提交
    • D
      drm/i915: fix up gt init sequence fallout · 181d1b9e
      Daniel Vetter 提交于
      The regression fix for gen6+ rps fallout
      
      commit 7dcd2677
      Author: Konstantin Khlebnikov <khlebnikov@openvz.org>
      Date:   Wed Jul 17 10:22:58 2013 +0400
      
          drm/i915: fix long-standing SNB regression in power consumption after resume
      
      unintentionally also changed the init sequence ordering between
      gt_init and gt_reset - we need to reset BIOS damage like leftover
      forcewake references before we run our own code. Otherwise we can get
      nasty dmesg noise like
      
      [drm:__gen6_gt_force_wake_mt_get] *ERROR* Timed out waiting for forcewake old ack to clear.
      
      again. Since _reset suggests that we first need to have stuff
      initialized (which isn't the case here) call it sanitze instead.
      
      While at it also block out the rps disable introduced by the above
      commit on ilk: We don't have any knowledge of ilk rps being broken in
      similar ways. And the disable functions uses the default hw state
      which is only read out when we're enabling rps. So essentially we've
      been writing random grabage into that register.
      Reported-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Konstantin Khlebnikov <khlebnikov@openvz.org>
      Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
      Cc: stable@vger.kernel.org
      Tested-by: NChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      181d1b9e
  5. 20 7月, 2013 1 次提交
    • C
      drm/i915: Serialize almost all register access · a7cd1b8f
      Chris Wilson 提交于
      In theory, the different register blocks were meant to be only ever
      touched when holding either the struct_mutex, mode_config.lock or even a
      specific localised lock. This does not seem to be the case, and the
      hardware reacts extremely badly if we attempt to concurrently access two
      registers within the same cacheline.
      
      The HSD suggests that we only need to do this workaround for display
      range registers. However, upon review we need to serialize the multiple
      stages in our register write functions - if only for preemption
      protection.
      
      Irrespective of the hardware requirements, the current io functions are
      a little too loose with respect to the combination of pre- and
      post-condition testing that we do in conjunction with the actual io. As
      a result, we may be pre-empted and generate both false-postive and
      false-negative errors.
      
      Note well that this is a "90%" solution, there remains a few direct
      users of ioread/iowrite which will be fixed up in the next few patches.
      Since they are more invasive and that this simple change will prevent
      almost all lockups on Haswell, we kept this patch simple to facilitate
      backporting to stable.
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=63914Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: stable@vger.kernel.org
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      a7cd1b8f
  6. 19 7月, 2013 1 次提交
  7. 18 7月, 2013 1 次提交
  8. 10 7月, 2013 1 次提交
    • D
      drm/i915: don't frob mm.suspended when not using ums · db1b76ca
      Daniel Vetter 提交于
      In kernel modeset driver mode we're in full control of the chip,
      always. So there's no need at all to set mm.suspended in
      i915_gem_idle. Hence move that out into the leavevt ioctl. Since
      i915_gem_idle doesn't suspend gem any more we can also drop the
      re-enabling for KMS in the thaw function.
      
      Also clean up the handling of mm.suspend at driver load by coalescing
      all the assignments.
      
      Stumbled over while reading through our resume code for unrelated
      reasons.
      
      v2: Shovel mm.suspended into the (newly created) ums dungeon as
      suggested by Chris Wilson. The plan is that once we've completely
      stopped relying on the register save/restore code we could shovel even
      that in there.
      
      v3: Improve the locking for the entervt/leavevt ioctls a bit by moving
      the dev->struct_mutex locking outside of i915_gem_idle. Also don't
      clear dev_priv->ums.mm_suspended for the kms case, we allocate it with
      kzalloc. Both suggested by Chris Wilson.
      
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (v2)
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      db1b76ca
  9. 09 7月, 2013 2 次提交
    • D
      drm/i915: clean up media reset on gm45 · 36c0cc61
      Daniel Vetter 提交于
      Originally I've thought that this fixes up the reset issues on my
      gm45, but that was just a red herring due to b0rked testing.
      
      Still I much prefer writing the right values (all other fields are
      reserved) instead of potentially dragging gunk around. Hence also
      clear the register to 0 after a reset.
      
      Note that Cspec is a bit confused and doesn't explicitly say that all
      the other bits in this register are "reserved, mbz" like usually.
      Instead they're marked as "r/o, default value = 0" which semantically
      amounts to the same thing.
      
      v2: Stop claiming this fixes anything and return 0 if successful
      instead of stack garbage.
      
      v3: Pimp the commit message to explain exactly why I think the docs
      allow us to ditch the rmw cycle, spurred by a discussion with Chris.
      
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      36c0cc61
    • P
      drm/i915: switch disable_power_well default value to 1 · bf51d5e2
      Paulo Zanoni 提交于
      Now that the audio driver is using our power well API, everything
      should be working correctly, so let's give it a try.
      Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      bf51d5e2
  10. 01 7月, 2013 2 次提交
  11. 11 6月, 2013 2 次提交
    • D
      drm/i915: consolidate ->num_shared_dplls assignement · 7c74ade1
      Daniel Vetter 提交于
      In the future this won't be just for pch plls, so move it into the
      shared dpll init code.
      
      v2: Bikeshed the uncessary {} away while applying to appease
      checkpatch.
      
      Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (v1)
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      7c74ade1
    • D
      drm/i915: s/pch_pll/shared_dpll/ · e72f9fbf
      Daniel Vetter 提交于
      For fastboot we need some support to read out the sharing state of
      plls, at least for platforms where they can be shared (or freely
      assigned at least). Now for ivb we already have pretty extensive
      infrastructure for tracking pch plls, and it took us an aweful lot of
      tries to get that remotely right. Note that hsw could also share plls,
      but even now they're already freely assignable. So we need this on
      more than just ivb.
      
      So on top of the usual fastboot fun pll sharing seems to be an
      additional step up in fragility. Hence a common infrastructure for all
      shared/freely assignable display plls seems to be in order.
      
      The plan is to have a bit of dpll hw state readout code, which can be
      used individually, but also to fill in the pipe config. The hw state
      cross check code will then use that information to make sure that
      after every modeset every pipe still is connected to a pll which still
      has the correct configuration - a lot of the pch pll sharing bugs
      where due to incorrect sharing.
      
      We start this endeavour with a simple s/pch_pll/shared_dpll/ rename
      job.
      Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      e72f9fbf
  12. 10 6月, 2013 1 次提交
  13. 01 6月, 2013 3 次提交
  14. 21 5月, 2013 1 次提交
  15. 11 5月, 2013 5 次提交
  16. 23 4月, 2013 3 次提交
  17. 18 4月, 2013 4 次提交
  18. 09 4月, 2013 2 次提交
  19. 06 4月, 2013 1 次提交
  20. 02 4月, 2013 1 次提交
  21. 27 3月, 2013 2 次提交
  22. 24 3月, 2013 1 次提交
  23. 23 3月, 2013 1 次提交
新手
引导
客服 返回
顶部