1. 11 5月, 2013 17 次提交
  2. 27 4月, 2013 1 次提交
  3. 24 4月, 2013 4 次提交
  4. 18 4月, 2013 10 次提交
  5. 09 4月, 2013 1 次提交
    • B
      drm/i915: Don't touch South Display when PCH_NOP · ab5c608b
      Ben Widawsky 提交于
      Interrupts, clock gating, LVDS, and GMBUS are all within the, "this will
      be bad for CPU" range when we have PCH_NOP.
      
      There is a bit of a hack in init clock gating. We want to do most of the
      clock gating, but the part we skip will hang the system. It could
      probably be abstracted a bit better, but I don't feel it's too
      unsightly.
      
      v2: Use inverse HAS_PCH_NOP check (Jani)
      
      v3: Actually do what I claimed in v2 (spotted by Daniel)
      Merge Ivybridge IRQ handler PCH check to decrease whitespace (Daniel)
      Move LVDS bail into this patch (Ben)
      
      v4: logical rebase conflict resolution with SDEIIR (Ben)
      Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
      
      Brush up patch a bit and resolve conflicts:
      - Adjust PCH_NOP checks due to Egbert's hpd handling rework.
      - Addd a PCH_NOP check in the irq uninstall code.
      - Resolve conflicts with Paulo's SDE irq handling race fix.
      
      v5: Drop the added hunks in the ilk irq handler again, they're bogus.
      OOps.
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      ab5c608b
  6. 03 4月, 2013 2 次提交
  7. 26 3月, 2013 2 次提交
  8. 24 3月, 2013 1 次提交
  9. 23 3月, 2013 2 次提交
    • B
      drm/i915: Implement WaSwitchSolVfFArbitrationPriority · e3dff585
      Ben Widawsky 提交于
      Bspec mentions this for HSW+. I can't quite tell what the effects are,
      and I don't easily have a way to test this.
      Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      e3dff585
    • B
      drm/i915: Correct sandybrige overclocking · a2b3fc01
      Ben Widawsky 提交于
      Change the gen6+ max delay if the pcode read was successful (not the
      inverse).
      
      The previous code was all sorts of wrong and has existed since I broke
      it:
      commit 42c0526c
      Author: Ben Widawsky <ben@bwidawsk.net>
      Date:   Wed Sep 26 10:34:00 2012 -0700
      
          drm/i915: Extract PCU communication
      
      I added some parentheses for clarity, and I also corrected the debug
      message message to use the mask (wrong before I came along) and added a
      print to show the value we're changing from.
      
      Looking over the code, I'm not actually sure what we're trying to do. I
      introduced the bug simply by extracting the function not implementing
      anything new. We already set max_delay based on the capabilities
      register (which is what we use elsewhere to determine min and max).
      This would potentially increase it, I suppose? Jesse, I can't find the
      document which explains the definitions of the pcode commands, maybe you
      have it around.
      
      Based on Jesse's response, this could potentially be for -fixes, or
      stable, or maybe lead to us dropping it entirely. As the current code is
      is, things won't completely break because of the aforementioned
      capabilities register, and in my experimentation, enabling this has no
      effect, it goes from 1100->1100.
      
      I found this while reviewing Jesse's VLV patches.
      
      Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
      Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      [danvet: Bikeshed-away the redudant parens spotted by Chris Wilson.]
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      a2b3fc01