1. 01 10月, 2013 4 次提交
  2. 25 9月, 2013 1 次提交
  3. 17 9月, 2013 4 次提交
  4. 13 9月, 2013 1 次提交
  5. 06 9月, 2013 4 次提交
  6. 05 9月, 2013 1 次提交
  7. 04 9月, 2013 2 次提交
  8. 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
  9. 22 8月, 2013 1 次提交
  10. 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
  11. 05 8月, 2013 2 次提交
  12. 27 7月, 2013 1 次提交
  13. 24 7月, 2013 1 次提交
  14. 18 7月, 2013 7 次提交
  15. 09 7月, 2013 1 次提交
  16. 02 7月, 2013 1 次提交
    • J
      drm/i915: get mode clock when reading the pipe config v9 · f1f644dc
      Jesse Barnes 提交于
      We need this for comparing modes between configuration changes.
      
      The tricky part is to allow us to reuse the new get_clock stuff to
      recover the lvds clock on gen2/3 when neither the vbt has an lvds mode
      nor the panel a (useful) EDID.
      
      v2: try harder to calulate non-simple pixel clocks (Daniel)
          call get_clock after getting the encoder config, needed for pixel multiply
          (Jesse)
      v3: drop get_clock now that the pixel_multiply has been moved into
          get_pipe_config
      v4: re-add get_clock; we need to get the pixel multiplier in the
          encoder, so need to calculate the clock value after the encoder's
          get_config is called
      v5: drop hsw clock_get, still needs to be written
      v6: add fuzzy clock check (Daniel)
      v7: wrap fuzzy clock check under !IS_HASWELL
          use port_clock field rather than a new CPU eDP clock field in crtc_config
      v8: remove stale pixel_multiplier sets (Daniel)
          multiply by pixel_multiplier in 9xx clock get too (Daniel)
      v9: make sure we set pixel_multiplier before calling clock_get from mode_get
          for LVDS (Daniel)
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      [danvet: Add some explanation to the commit message about why we have
      to jump through a few hoops. Also remove the rebase-fail hunk from
      intel_sdvo.c]
      [danvet: Squash in the fixup from Jesse to also call ->get_clock in
      the modeset state checker.]
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      f1f644dc
  17. 01 7月, 2013 2 次提交
  18. 28 6月, 2013 4 次提交