1. 28 Mar, 2014 4 commits
    • Deepak S's avatar
      drm/i915: Track the enabled PM interrupts in dev_priv. · a6706b45
      Deepak S authored
      When we use different rps events for different platforms or due to wa,
      we might end up needing this logic in a lot of places. Instead of
      this let's use a variable in dev_priv to track the enabled PM
      interrupts.
      
      v2: Initialize pm_rps_events in intel_irq_init() (Ville).
      Signed-off-by: default avatarDeepak S <deepak.s@linux.intel.com>
      Reviewed-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      [danvet: Frob the commit message a bit since the English was a bit too
      garbled ;-) ]
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      a6706b45
    • Daniel Vetter's avatar
      drm/i915: Fix initial pipe underrun state tracking · 4cc31489
      Daniel Vetter authored
      Since
      
      commit 5c673b60
      Author: Daniel Vetter <daniel.vetter@ffwll.ch>
      Date:   Fri Mar 7 20:34:46 2014 +0100
      
          drm/i915: Don't enable display error interrupts from the start
      
      we don't enable underrun interrupts any more at takeover time.
      Unfortunately I've forgotten to also adjust the sw-side tracking.
      
      Since the code assumes that disabled pipes have underrun reporting
      enabled set the disable flag only on all pipes which are active at
      takeover time. Without this underrun reporting wasn't enabled
      correctly on the first modeset. Note that for fastboot this is another
      piece of state that needs to be fixed up by enabling the underrung
      reporting after watermarks have beend fixed up.
      
      On ivb/hsw an additional effect of this regression was that also all
      cpu crc reporting stopped working since the master error interrupt it
      shared across all pipes and sources.
      
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Cc: Jani Nikula <jani.nikula@intel.com>
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76150
      [danvet: Augment the code comment and polish the commit message a bit,
      as discussed with Jani.]
      Reviewed-by: default avatarJani Nikula <jani.nikula@intel.com>
      Tested-by: default avatarlu hua <huax.lu@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      4cc31489
    • Daniel Vetter's avatar
      drm/i915: fix up semaphore_waits_for · 88fe429d
      Daniel Vetter authored
      There's an entire pile of issues in here:
      
      - Use the main RING_HEAD register, not ACTHD. ACTHD points at the gtt
        offset of the batch buffer when a batch is executed. Semaphores are
        always emitted to the main ring, so we always want to look at that.
      
      - Mask the obtained HEAD pointer with the actual ring size, which is
        much smaller. Together with the above issue this resulted us in
        trying to dereference a pointer way outside of the ring mmio
        mapping. The resulting invalid access in interrupt context
        (hangcheck is executed from timers) lead to a full blown kernel
        panic. The fbcon panic handler then tried to frob our driver harder,
        resulting in a full machine hang at least on my snb here where I've
        stumbled over this.
      
      - Handle ring wrapping correctly and be a bit more explicit about how
        many dwords we're scanning. We probably should also scan more than
        just 4 ...
      
      - Space out some of teh computations for readability.
      
      This reduces hard-hangs on my snb here. Mika and QA both say that it
      doesn't completel remove them, but at least for me it's a clear
      improvement in stability.
      
      Cc: Mika Kuoppala <mika.kuoppala@intel.com>
      Cc: Ben Widawsky <ben@bwidawsk.net>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      References: https://bugs.freedesktop.org/show_bug.cgi?id=74100Reviewed-by: default avatarMika Kuoppala <mika.kuoppala@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      88fe429d
    • Daniel Vetter's avatar
      drm/i915: add locking to fixed panel edid probing · 4da98541
      Daniel Vetter authored
      With the recent addition of locking checks in
      
      commit 62ff94a5
      Author:     Daniel Vetter <daniel.vetter@ffwll.ch>
      AuthorDate: Thu Jan 23 22:18:47 2014 +0100
      
          drm/crtc-helper: remove LOCKING from kerneldoc
      
      drm_add_edid_modes started to WARN about the mode_config.mutex not
      being held in the lvds and dp initialization code.
      
      Now since this is init code locking is fairly redudant if it wouldn't
      be for the drm core registering sysfs files a bit early. And the
      locking WARNINGs nicely enforce that indeed all access to the mode
      lists are properly protected. And a full audit shows that only i915
      and gma500 touch the modes lists at init time.
      
      Hence I've opted to wrap up this entire mode detection sequence for
      fixed panels with the mode_config mutex for both lvds and edp outputs.
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      4da98541
  2. 21 Mar, 2014 3 commits
  3. 20 Mar, 2014 9 commits
  4. 19 Mar, 2014 21 commits
  5. 18 Mar, 2014 3 commits