1. 03 12月, 2014 4 次提交
    • V
      drm/i915: Reject modeset when the same digital port is used more than once · 00f0b378
      Ville Syrjälä 提交于
      On pre-HSW we have two encoders per digital port: one HDMI, one DP.
      However they are the same physical port in hardware and we can't enable
      both at the same time. Reject the modeset if the user attempts this.
      
      So far we've been saved by the fact that we never see both HDMI and DP
      connectors as connected. But if the user decides to force a mode anyway,
      all kinds of funny stuff might happen.
      
      Unfortunately we don't seem to have any way to inform userspace that
      such configurations are invalid except by returning an error from
      setcrtc. possible_clones only covers real cloning situations, and
      looking at the connector names doesn't work either since we don't
      always register both connectors for the same port. I suppose the
      only way to fix that would be to expose only a single encoder per
      digital port like we do on HSW+ but that would be a fairly large
      undertaking for little gain.
      
      kms_setmode hits this since it forces modes on non-connected VGA and
      HDMI connectors. Previosuly it just resulted in weirdness such as
      failed link training. With this patch it will now get an error back
      from the kernel and will die with an assert since it thinks that the
      configuration should be fine.
      
      v2: Deal with INTEL_OUTPUT_UNKNOWN (Paulo)
      
      Cc: Paulo Zanoni <przanoni@gmail.com>
      Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      00f0b378
    • V
      drm/i915: Disable crtcs gracefully before GPU reset on gen3/4 · f98ce92f
      Ville Syrjälä 提交于
      The GPU reset also resets the display on gen3/4. The g33 docs say we
      should disable all planes before flipping the reset switch. Just
      disable all the crtcs instead. That seems a nicer thing to do anyway.
      Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      f98ce92f
    • V
      drm/i915: Grab modeset locks for GPU rest on pre-ctg · 7514747d
      Ville Syrjälä 提交于
      On gen4 and earlier the GPU reset also resets the display, so we should
      protect against concurrent modeset operations. Grab all the modeset locks
      around the entire GPU reset dance, remebering first ti dislogde any
      pending page flip to make sure we don't deadlock. Any pageflip coming
      in between these two steps should fail anyway due to reset_in_progress,
      so this should be safe.
      
      This fixes a lot of failed asserts in the modeset code when there's a
      modeset racing with the reset. Naturally the asserts aren't happy when
      the expected state has disappeared.
      
      v2: Drop UMS checks, complete pending flips after the reset (Daniel)
      
      Cc: Daniel Vetter <daniel@ffwll.ch>
      Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      7514747d
    • V
      drm/i915: Don't clobber crtc->new_config when nothing changes · b9950a13
      Ville Syrjälä 提交于
      When doing a nop modeset we currently leave crtc->new_config point at
      the already freed temporary pipe_config. That will anger the sanity
      checks in intel_modeset_update_state() when the nop modeset gets
      followed by a GPU reset on gen3/4 where the display block gets fully
      reinitialized during the reset.
      
      So leave crtc->new_config alone until we know a modeset is actually
      required.
      
      Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      b9950a13
  2. 24 11月, 2014 1 次提交
    • V
      drm/i915: Ignore SURFLIVE and flip counter when the GPU gets reset · bdfa7542
      Ville Syrjälä 提交于
      During a GPU reset we need to get pending page flip cleared out
      since the ring contents are gone and flip will never complete
      on its own. This used to work until the mmio vs. CS flip race
      detection came about. That piece of code is looking for a
      specific surface address in the SURFLIVE register, but as
      a flip to that address may never happen the check may never
      pass. So we should just skip the SURFLIVE and flip counter
      checks when the GPU gets reset.
      
      intel_display_handle_reset() tries to effectively complete
      the flip anyway by calling .update_primary_plane(). But that
      may not satisfy the conditions of the mmio vs. CS race
      detection since there's no guarantee that a modeset didn't
      sneak in between the GPU reset and intel_display_handle_reset().
      Such a modeset will not wait for pending flips due to the ongoing GPU
      reset, and then the primary plane updates performed by
      intel_display_handle_reset() will already use the new surface
      address, and thus the surface address the flip is waiting for
      might never appear in SURFLIVE. The result is that the flip
      will never complete and attempts to perform further page flips
      will fail with -EBUSY.
      
      During the GPU reset intel_crtc_has_pending_flip() will return
      false regardless, so the deadlock with a modeset vs. the error
      work acquiring crtc->mutex was avoided. And the reset_counter
      check in intel_crtc_has_pending_flip() actually made this bug
      even less severe since it allowed normal modesets to go through
      even though there's a pending flip.
      
      This is a regression introduced by me here:
       commit 75f7f3ec
       Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
       Date:   Tue Apr 15 21:41:34 2014 +0300
      
          drm/i915: Fix mmio vs. CS flip race on ILK+
      
      Testcase: igt/kms_flip/flip-vs-panning-vs-hang
      Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Cc: stable@vger.kernel.org
      Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      bdfa7542
  3. 20 11月, 2014 3 次提交
  4. 19 11月, 2014 2 次提交
  5. 18 11月, 2014 2 次提交
  6. 17 11月, 2014 1 次提交
  7. 14 11月, 2014 14 次提交
  8. 12 11月, 2014 2 次提交
    • A
      drm/i915: Plug memory leak in intel_shared_dpll_start_config() · f354d733
      Ander Conselvan de Oliveira 提交于
      The cleanup path would reset pll->new_config to NULL but wouldn't free
      the allocated memory.
      Signed-off-by: NAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
      Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      f354d733
    • D
      drm: Per-plane locking · 4d02e2de
      Daniel Vetter 提交于
      Turned out to be much simpler on top of my latest atomic stuff than
      what I've feared. Some details:
      
      - Drop the modeset_lock_all snakeoil in drm_plane_init. Same
        justification as for the equivalent change in drm_crtc_init done in
      
      	commit d0fa1af4
      	Author: Daniel Vetter <daniel.vetter@ffwll.ch>
      	Date:   Mon Sep 8 09:02:49 2014 +0200
      
      	    drm: Drop modeset locking from crtc init function
      
        Without these the drm_modeset_lock_init would fall over the exact
        same way.
      
      - Since the atomic core code wraps the locking switching it to
        per-plane locks was a one-line change.
      
      - For the legacy ioctls add a plane argument to the locking helper so
        that we can grab the right plane lock (cursor or primary). Since the
        universal cursor plane might not be there, or someone really crazy
        might forgoe the primary plane even accept NULL.
      
      - Add some locking WARN_ON to the atomic helpers for good paranoid
        measure and to check that it all works out.
      
      Tested on my exynos atomic hackfest with full lockdep checks and ww
      backoff injection.
      
      v2: I've forgotten about the load-detect code in i915.
      
      v3: Thierry reported that in latest 3.18-rc vmwgfx doesn't compile any
      more due to
      
      commit 21e88620
      Author: Rob Clark <robdclark@gmail.com>
      Date:   Thu Oct 30 13:39:04 2014 -0400
      
          drm/vmwgfx: fix lock breakage
      
      Rebased and fix this up.
      
      Cc: Thierry Reding <thierry.reding@gmail.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
      Reviewed-by: NSean Paul <seanpaul@chromium.org>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      4d02e2de
  9. 08 11月, 2014 11 次提交