1. 13 Jul, 2013 1 commit
  2. 12 Jul, 2013 1 commit
    • Daniel Vetter's avatar
      drm/i915: fix pfit regression for non-autoscaled resolutions · 21d8a475
      Daniel Vetter authored
      I.e. for letter/pillarboxing. For those cases we need to adjust the
      mode a bit, but Jesse gmch pfit refactoring in
      
      commit 2dd24552
      Author: Jesse Barnes <jbarnes@virtuousgeek.org>
      Date:   Thu Apr 25 12:55:01 2013 -0700
      
          drm/i915: factor out GMCH panel fitting code and use for eDP v3
      
      broke that by reordering the computation of the gmch pfit state with
      the block of code that prepared the adjusted mode for it and told the
      modeset core not to overwrite the adjusted mode with default settings.
      
      We might want to switch around the core code to just fill in defaults,
      but this code predates the pipe_config modeset rework. And in the old
      crtc helpers we did not have a suitable spot to do this.
      
      Cc: Mika Kuoppala <mika.kuoppala@intel.com>
      Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
      Cc: Hans de Bruin <jmdebruin@xmsnet.nl>
      Reported-and-tested-by: default avatarHans de Bruin <jmdebruin@xmsnet.nl>
      Reviewed-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      21d8a475
  3. 11 Jul, 2013 1 commit
    • Daniel Vetter's avatar
      drm/i915: fix up readout of the lvds dither bit on gen2/3 · 06922821
      Daniel Vetter authored
      It's in the PFIT_CONTROL register, but very much associated with the
      lvds encoder. So move the readout for it (in the case of an otherwise
      disabled pfit) from the pipe to the lvds encoder's get_config
      function.
      
      Otherwise we get a pipe state mismatch if we use pipe B for a non-lvds
      output and we've left the dither bit enabled behind us. This can
      happen if the BIOS has set the bit (some seem to unconditionally do
      that, even in the complete absence of an lvds port), but not enabled
      pipe B at boot-up. Then we won't clear the pfit control register since
      we can only touch that if the pfit is associated with our pipe in the
      crtc configuration - we could trample over the pfit state of the other
      pipe otherwise since it's shared. Once pipe B is enabled we notice
      that the 6to8 dither bit is set and complain about the mismatch.
      
      Note that testing indicates that we don't actually need to set this
      bit when the pfit is disabled, dithering on 18bpp panels seems to work
      regardless. But ripping that code out is not something for a bugfix
      meant for -rc kernels.
      
      v2: While at it clarify the logic in i9xx_get_pfit_config, spurred by
      comments from Chris on irc.
      
      v3: Use Chris suggestion to make the control flow in
      i9xx_get_pfit_config easier to understand.
      
      v4: Kill the extra line, spotted by Chris.
      Reported-by: default avatarKnut Petersen <Knut_Petersen@t-online.de>
      Cc: Knut Petersen <Knut_Petersen@t-online.de>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      References: http://lists.freedesktop.org/archives/intel-gfx/2013-July/030092.htmlTested-by: default avatarKnut Petersen <Knut_Petersen@t-online.de>
      Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      06922821
  4. 10 Jul, 2013 4 commits
    • Chris Wilson's avatar
      Revert "drm/i915: Workaround incoherence between fences and LLC across multiple CPUs" · 46a0b638
      Chris Wilson authored
      This reverts commit 25ff1195 and the follow on for Valleyview commit 2dc8aae0.
      
      commit 25ff1195
      Author: Chris Wilson <chris@chris-wilson.co.uk>
      Date:   Thu Apr 4 21:31:03 2013 +0100
      
          drm/i915: Workaround incoherence between fences and LLC across multiple CPUs
      
      commit 2dc8aae0
      Author: Chris Wilson <chris@chris-wilson.co.uk>
      Date:   Wed May 22 17:08:06 2013 +0100
      
          drm/i915: Workaround incoherence with fence updates on Valleyview
      
      Jon Bloomfield came up with a plausible explanation and cheap fix
      (drm/i915: Fix incoherence with fence updates on Sandybridge+) for the
      race condition, so lets run with it.
      
      This is a candidate for stable as the old workaround incurs a
      significant cost (calling wbinvd on all CPUs before performing the
      register write) for some workloads as noted by Carsten Emde.
      
      Link: http://lists.freedesktop.org/archives/intel-gfx/2013-June/028819.html
      References: https://www.osadl.org/?id=1543#c7602
      References: https://bugs.freedesktop.org/show_bug.cgi?id=63825Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: Jon Bloomfield <jon.bloomfield@intel.com>
      Cc: Carsten Emde <C.Emde@osadl.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      46a0b638
    • Chris Wilson's avatar
      drm/i915: Fix incoherence with fence updates on Sandybridge+ · d18b9619
      Chris Wilson authored
      This hopefully fixes the root cause behind the workaround added in
      
      commit 25ff1195
      Author: Chris Wilson <chris@chris-wilson.co.uk>
      Date:   Thu Apr 4 21:31:03 2013 +0100
      
          drm/i915: Workaround incoherence between fences and LLC across multiple CPUs
      
      Thanks to further investigation by Jon Bloomfield, he realised that
      the 64-bit register might be broken up by the hardware into two 32-bit
      writes (a problem we have encountered elsewhere). This non-atomicity
      would then cause an issue where a second thread would see an
      intermediate register state (new high dword, old low dword), and this
      register would randomly be used in preference to its own thread register.
      This would cause the second thread to read from and write into a fairly
      random tiled location.  Breaking the operation into 3 explicit 32-bit
      updates (first disable the fence, poke the upper bits, then poke the lower
      bits and enable) ensures that, given proper serialisation between the
      32-bit register write and the memory transfer, that the fence value is
      always consistent.
      
      Armed with this knowledge, we can explain how the previous workaround
      work. The key to the corruption is that a second thread sees an
      erroneous fence register that conflicts and overrides its own. By
      serialising the fence update across all CPUs, we have a small window
      where no GTT access is occurring and so hide the potential corruption.
      This also leads to the conclusion that the earlier workaround was
      incomplete.
      
      v2: Be overly paranoid about the order in which fence updates become
      visible to the GPU to make really sure that we turn the fence off before
      doing the update, and then only switch the fence on afterwards.
      Signed-off-by: default avatarJon Bloomfield <jon.bloomfield@intel.com>
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: Carsten Emde <C.Emde@osadl.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      d18b9619
    • Chris Wilson's avatar
      drm/i915: Fix write-read race with multiple rings · 02978ff5
      Chris Wilson authored
      Daniel noticed a problem where is we wrote to an object with ring A in
      the middle of a very long running batch, then executed a quick batch on
      ring B before a batch that reads from the same object, its obj->ring would
      now point to ring B, but its last_write_seqno would be still relative to
      ring A. This would allow for the user to read from the object before the
      GPU had completed the write, as set_domain would only check that ring B
      had passed the last_write_seqno.
      
      To fix this simply (and inelegantly), we bump the last_write_seqno when
      switching rings so that the last_write_seqno is always relative to the
      current obj->ring.
      
      This fixes igt/tests/gem_write_read_ring_switch.
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: stable@vger.kernel.org
      [danvet: Add note about the newly created igt which exercises this
      bug.]
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      02978ff5
    • Guenter Roeck's avatar
      Partially revert "drm/i915: unconditionally use mt forcewake on hsw/ivb" · c11e5f35
      Guenter Roeck authored
      This patch partially reverts commit 36ec8f87 for
      IvyBridge CPUs.
      
      The original commit results in repeated 'Timed out waiting for forcewake old
      ack to clear' messages on a Supermicro C7H61 board (BIOS version 2.00 and 2.00b)
      with i7-3770K CPU. It ultimately results in a hangup if the system is highly
      loaded. Reverting the commit for IvyBridge CPUs fixes the issue.
      
      Issue a warning if the CPU is IvyBridge and mt forcewake is disabled, since
      this condition can result in secondary issues.
      
      v2: Only revert patch for Ivybridge CPUs
          Issue info message if mt forcewake is disabled on Ivybridge
      
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=60541
      Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: Mika Kuoppala <mika.kuoppala@intel.com>
      Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Cc: stable@vger.kernel.org
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66139Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      c11e5f35
  5. 09 Jul, 2013 4 commits
  6. 04 Jul, 2013 1 commit
    • Daniel Vetter's avatar
      drm/i915: reinit status page registers after gpu reset · 035dc1e0
      Daniel Vetter authored
      This fixes gpu reset on my gm45 - without this patch the bsd thing is
      forever stuck since the seqno updates never reach the status page.
      
      Tbh I have no idea how this ever worked without rewriting the hws
      registers after a gpu reset.
      
      To satisfy my OCD also give the functions a bit more consistent names:
      - Use status_page everywhere, also for the physical addressed one.
      - Use init for the allocation part and setup for the register setup
        part consistently.
      
      Long term I'd really like to share the hw init parts completely
      between gpu reset, resume and driver load, i.e. to call
      i915_gem_init_hw instead of the individual pieces we might need.
      
      v2: Add the missing paragraph to the commit message about what bug
      exactly this patch here fixes.
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65495
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Tested-by: default avatarlu hua <huax.lu@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      035dc1e0
  7. 02 Jul, 2013 1 commit
    • Daniel Vetter's avatar
      drm/i915: Don't try to tear down the stolen drm_mm if it's not there · 446f8d81
      Daniel Vetter authored
      Every other place properly checks whether we've managed to set
      up the stolen allocator at boot-up properly, with the exception
      of the cleanup code. Which results in an ugly
      
      *ERROR* Memory manager not clean. Delaying takedown
      
      at module unload time since the drm_mm isn't initialized at all.
      
      v2: While at it check whether the stolen drm_mm is initialized instead
      of the more obscure stolen_base == 0 check.
      
      v3: Fix up the logic. Also we need to keep the stolen_base check in
      i915_gem_object_create_stolen_for_preallocated since that can be
      called before stolen memory is fully set up. Spotted by Chris Wilson.
      
      v4: Readd the conversion in i915_gem_object_create_stolen_for_preallocated,
      the check is for the dev_priv->mm.gtt_space drm_mm, the stolen
      allocatot must already be initialized when calling that function (if
      we indeed have stolen memory).
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65953
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Tested-by: lu hua <huax.lu@intel.com> (v3)
      Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      446f8d81
  8. 01 Jul, 2013 27 commits