1. 06 9月, 2013 3 次提交
  2. 05 9月, 2013 1 次提交
  3. 04 9月, 2013 2 次提交
  4. 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
  5. 22 8月, 2013 1 次提交
  6. 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
  7. 05 8月, 2013 2 次提交
  8. 27 7月, 2013 1 次提交
  9. 24 7月, 2013 1 次提交
  10. 18 7月, 2013 7 次提交
  11. 09 7月, 2013 1 次提交
  12. 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
  13. 01 7月, 2013 2 次提交
  14. 28 6月, 2013 6 次提交
  15. 07 6月, 2013 1 次提交
  16. 04 6月, 2013 2 次提交
    • D
      drm/i915: store adjusted dotclock in adjusted_mode->clock · ff9a6750
      Daniel Vetter 提交于
      ... not the port clock. This allows us to kill the funny semantics
      around pixel_target_clock.
      
      Since the dpll code still needs the real port clock, add a new
      port_clock field to the pipe configuration. Handling the default case
      for that one is a bit tricky, since encoders might not consistently
      overwrite it when retrying the crtc/encoder bw arbitrage step in the
      compute config stage. Hence we need to always clear port_clock and
      update it again if the encoder hasn't put in something more specific.
      This can't be done in one step since the encoder might want to adjust
      the mode first.
      
      I was a bit on the fence whether I should subsume the pixel multiplier
      handling into the port_clock, too. But then I decided against this
      since it's on an abstract level still the dotclock of the adjusted
      mode, and only our hw makes it a bit special due to the separate pixel
      mulitplier setting (which requires that the dpll runs at the
      non-multiplied dotclock).
      
      So after this patch the adjusted_mode accurately describes the mode we
      feed into the port, after the panel fitter and pixel multiplier (or
      line doubling, if we ever bother with that) have done their job.
      Since the fdi link is between the pfit and the pixel multiplier steps
      we need to be careful with calculating the fdi link config.
      
      v2: Fix up ilk cpu pll handling.
      
      v3: Introduce an fdi_dotclock variable in ironlake_fdi_compute_config
      to make it clearer that we transmit the adjusted_mode without the
      pixel multiplier taken into account. The old code multiplied the the
      available link bw with the pixel multiplier, which results in the same
      fdi configuration, but is much more confusing.
      
      v4: Rebase on top of Imre's is_cpu_edp removal.
      
      v5: Rebase on top of Paulo's haswell watermark fixes, which introduce
      a new place which looked at the pixel_clock and so needed conversion.
      
      v6: Split out prep patches as requested by Paulo Zanoni. Also rebase
      on top of the fdi dotclock handling fix in the fdi lanes/bw
      computation code.
      
      Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> (v3)
      Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> (v6)
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      ff9a6750
    • D
      drm/i915: refactor cpu eDP PLL handling a bit · 7c62a164
      Daniel Vetter 提交于
      This prepares a bit for the next big patch, where we switch the
      semantics of the different clocks in the pipe config around.
      
      Since I've broken cpu eDP PLL handling in the first version I've
      figured some refactoring is in order.
      
      Split out on request from Paulo Zanoni.
      Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      7c62a164
  17. 01 6月, 2013 4 次提交
  18. 24 5月, 2013 2 次提交