1. 10 10月, 2013 1 次提交
  2. 09 10月, 2013 2 次提交
  3. 04 10月, 2013 1 次提交
  4. 01 10月, 2013 10 次提交
  5. 25 9月, 2013 1 次提交
  6. 17 9月, 2013 4 次提交
  7. 13 9月, 2013 1 次提交
  8. 06 9月, 2013 4 次提交
  9. 05 9月, 2013 1 次提交
  10. 04 9月, 2013 2 次提交
  11. 23 8月, 2013 1 次提交
    • 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
  12. 22 8月, 2013 1 次提交
  13. 06 8月, 2013 2 次提交
    • J
      drm/i915: rearrange vlv dp enable and pre_enable callbacks · ab1f90f9
      Jani Nikula 提交于
      VLV wants encoder enabling before the pipe is up. This is currently
      achieved through calling the ->enable callback early, right after the
      ->pre_enable callback, in valleyview_crtc_enable(). This loses both the
      distinction between ->pre_enable and ->enable on VLV and the possibility
      to use a hook at the end of the modeset sequence.
      
      Rearrange the DP callbacks to make it possible to move ->enable call
      later. Basically do everything in ->pre_enable on VLV, and make ->enable
      a NOP.
      
      There should be no functional changes.
      
      v2: Rebase.
      
      v3: Explain why this is needed in the commit message (Chris).
      Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      ab1f90f9
    • C
      drm/i915: Acquire dpio_lock for VLV sideband programming in DP/HDMI · 0980a60f
      Chris Wilson 提交于
      Otherwise we get flooded by the kernel warning us that we are doing
      long sequences of IO without serialisation. For example,
      
       WARNING: CPU: 0 PID: 11136 at drivers/gpu/drm/i915/intel_sideband.c:40 vlv_sideband_rw+0x48/0x1ef()
       Modules linked in:
       CPU: 0 PID: 11136 Comm: kworker/u2:0 Tainted: G        W    3.11.0-rc2+ #4
       Call Trace:
        [<c2028564>] ?  warn_slowpath_common+0x63/0x78
        [<c227ad43>] ?  vlv_sideband_rw+0x48/0x1ef
        [<c20285dd>] ?  warn_slowpath_null+0xf/0x13
        [<c227ad43>] ?  vlv_sideband_rw+0x48/0x1ef
        [<c227b060>] ?  vlv_dpio_write+0x1c/0x21
        [<c2262b3b>] ?  intel_dp_set_signal_levels+0x24a/0x385
        [<c2264909>] ?  intel_dp_complete_link_train+0x25/0x1d1
        [<c2264c55>] ?  intel_dp_check_link_status+0xf7/0x106
        [<c2238ced>] ?  i915_hotplug_work_func+0x17b/0x221
        [<c203a204>] ?  process_one_work+0x12e/0x210
        [<c203a5e4>] ?  worker_thread+0x116/0x1ad
        [<c203a4ce>] ?  rescuer_thread+0x1cb/0x1cb
        [<c203d8f5>] ?  kthread+0x67/0x6c
        [<c2457ebb>] ?  ret_from_kernel_thread+0x1b/0x30
        [<c203d88e>] ?  init_completion+0x18/0x18
      
      v2: Retire the locking in vlv_crtc_enable() and do it close to the meat.
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: NJani Nikula <jani.nikula@intel.com>
      [danvet: Squash in a s/mutex_lock/mutex_unlock/ fixup spotted by the 0
      day kernel build/coccinelle and reported by Dan Carpenter.]
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      0980a60f
  14. 05 8月, 2013 2 次提交
  15. 27 7月, 2013 1 次提交
  16. 24 7月, 2013 1 次提交
  17. 18 7月, 2013 5 次提交