- 17 Jul, 2012 9 commits
-
-
Christian König authored
It's not critical, but the current code isn't 100% correct. Signed-off-by:
Christian König <deathsimple@vodafone.de> Reviewed-by:
Jerome Glisse <jglisse@redhat.com> Reviewed-by:
Alex Deucher <alexander.deucher@amd.com>
-
Christian König authored
For a normal suspend/resume we allready wait for the rings to be empty, and for a suspend/reasume in case of a lockup we REALLY don't want to wait for anything. Signed-off-by:
-
Christian König authored
Start with last signaled fence number instead of last emitted one. Signed-off-by:
-
Christian König authored
It is possible that radeon_fence_process is called after writeback is disabled for suspend, leading to an invalid read of register 0x0. This fixes a problem for me where the fence value is temporary incremented by 0x100000000 on suspend/resume. Signed-off-by:
-
Christian König authored
We don't need to pad anything if the number of dwords written to the ring already matches the requirements. Fixes some "writting more dword to ring than expected" warnings. Signed-off-by:
Michel Dänzer <michel.daenzer@amd.com> Reviewed-by:
-
Jerome Glisse authored
GPU reset need to be exclusive, one happening at a time. For this add a rw semaphore so that any path that trigger GPU activities have to take the semaphore as a reader thus allowing concurency. The GPU reset path take the semaphore as a writer ensuring that no concurrent reset take place. v2: init rw semaphore Signed-off-by:
Christian König <christian.koenig@amd.com> Reviewed-by:
-
Christian König authored
Don't return success if scheduling the IB fails, otherwise we end up with an oops in ttm_eu_fence_buffer_objects. Signed-off-by:
-
Christian König authored
Waiting for a fence can fail for different reasons, the most common is a deadlock. Signed-off-by:
-
Christian König authored
Instead of returning the error handle it directly and while at it fix the comments about the ring lock. Signed-off-by:
-
- 15 Jul, 2012 1 commit
-
-
Dave Airlie authored
If drm can't find proc it should fail more gracefully, than just oopsing, this tests drm_class is NULL, and sets it to NULL in the fail paths. Reported-by:
Fengguang Wu <fengguang.wu@intel.com> Signed-off-by:
Dave Airlie <airlied@redhat.com>
-
- 14 Jul, 2012 1 commit
-
-
Dave Airlie authored
Merge tag 'drm-intel-next-2012-07-06' of git://people.freedesktop.org/~danvet/drm-intel into drm-next Daniel writes: New pull for -next. Highlights: - rc6/turbo support for hsw (Eugeni) - improve corner-case of the reset handling code - gpu reset handling should be rock-solid now - support for fb offset > 4096 pixels on gen4+ (yeah, you need some fairly big screens to hit that) - the "Flush Me Harder" patch to fix the gen6+ fallout from disabling the flushing_list - no more /dev/agpgart on gen6+! - HAS_PCH_xxx improvements from Paulo - a few minor bits&pieces all over, most of it in thew hsw code * tag 'drm-intel-next-2012-07-06' of git://people.freedesktop.org/~danvet/drm-intel: (40 commits) drm/i915: program FDI_RX TP and FDI delays drm/i915: introduce for_each_encoder_on_crtc drm/i915: adjust framebuffer base address on gen4+ drm/i915: introduce crtc->dspaddr_offset drm/i915: Reject page flips with changed format/offset/pitch drm/i915: Zero initialize mode_cmd drm/i915: don't return a spurious -EIO from intel_ring_begin drm/i915: properly SIGBUS on I/O errors drm/i915: don't hang userspace when the gpu reset is stuck drm/i915: non-interruptible sleeps can't handle -EAGAIN drm/i915: don't trylock in the gpu reset code drm/i915: fix PIPE_DDI_PORT_MASK drm/i915: prevent bogus intel_update_fbc notifications drm/i915: re-initialize DDI buffer translations after resume drm/i915: don't ironlake_init_pch_refclk() on LPT drm/i915: get rid of dev_priv->info->has_pch_split drm/i915: add PCH_NONE to enum intel_pch drm/i915: prefer wide & slow to fast & narrow in DP configs drm/i915: fix up ilk rc6 disabling confusion drm/i915: move force wake support into intel_pm ...
-
- 05 Jul, 2012 26 commits
-
-
Eugeni Dodonov authored
This is required for a stable FDI connection. v2: fix and simplify the FDI_RX_MISC bits as noticed by Paulo Zanoni. CC: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
Eugeni Dodonov <eugeni.dodonov@intel.com> Reviewed-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Daniel Vetter authored
We already have this pattern at quite a few places, and moving part of the modeset helper stuff into the driver will add more. v2: Don't clobber the crtc struct name with the macro parameter ... v3: Convert two more places noticed by Paulo Zanoni. Reviewed-by:
-
Daniel Vetter authored
The tileoffset register only supports a limited offset in x/y of 4096, so for giant screen configuration with a shared fb we wrap around. Fix this by computing a linear offset in tiles (pages) and only use the tileoffset register to offset within the tile. Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-Off-by:
-
Daniel Vetter authored
To avoid recomputing the display framebuffer offset on gen2/3 pageflips. This is also prep work to do similar trickery on gen4+ Also: - kill "Start", such upper-case remnants from the ddx must surely die. - rename "Offset" to linear_offset, to make it clearer that on gen4+ this is only used by the hw for linear buffers, for tiled buffers it uses the TILEOFF register. - call DSAPADDR DSPLINOFF on gen4+ for the same reason (and because the documentation really renamed the register). Reviewed-by:
-
Ville Syrjälä authored
MI display flips can't handle some changes in the framebuffer format or layout. Return an error in such cases. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Ville Syrjälä authored
Zero initialize the mode_cmd structure when creating the kernel framebuffer. Avoids having uninitialized data in offsets[0] for instance. Signed-off-by:
-
Daniel Vetter authored
The issue with this check is that it results in userspace receiving an -EIO while the gpu reset hasn't completed, resulting in fallback to sw rendering or worse. Now there's also a stern comment in intel_ring_wait_seqno saying that intel_ring_begin should not return -EAGAIN, ever, because some callers can't handle that. But after an audit of the callsites I don't see any issues. I guess the last problematic spot disappeared with the removal of the pipelined fencing code. So do the right thing and call check_wedge, which should properly decide whether an -EAGAIN or -EIO is appropriate if wedged is set. Note that the early check for a wedged gpu before touching the ring is rather important (and it took me quite some time of acting like the densest doofus to figure that out): If we don't do that and the gpu died for good, not having been resurrect by the reset code, userspace can merrily fill up the entire ring until it notices that something is amiss. Allowing userspace to emit more render, despite that we know that it will fail can't lead to anything good (and by experience can lead to all sorts of havoc, including angering the OOM gods and hard-hanging the hw for good). v2: Fix EAGAIN mispell, noticed by Chris Wilson. Reviewed-by:
-
Daniel Vetter authored
... instead of looping endless with no hope of ever serving that page-fault. We only need to break out of this loop when the gpu died, to run the reset work (and hopefully resurrect it). To clarify questions Chris raised on irc: This is about handling I/O errors not from our own code, but e.g. when the disk died when trying to swap in a gem bo. So this patch remidies the issue that the current handling only handles gpu-death-induced cases of -EIO. Admittedly, dying disks are much rarer than hanging gpus ...To clarify questions Chris raised on irc: This is about handling I/O errors not from our own code, but e.g. when the disk died when trying to swap in a gem bo. So this patch remidies the issue that the current handling only handles gpu-death-induced cases of -EIO. Admittedly, dying disks are much rarer than hanging gpus ... This seems to have been lost in: commit d9bc7e9f Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Mon Feb 7 13:09:31 2011 +0000 drm/i915: Fix infinite loop regression from 21dd3734Reviewed-by:
-
Daniel Vetter authored
With the gpu reset no longer using a trylock we've increased the chances of userspace getting stuck quite a bit. To make that (hopefully) rare case more paletable time out when waiting for the gpu reset code to complete and signal this little issue to the caller by returning -EIO. This should help userspace to somewhat gracefully fall back and hopefully allow the user to grab some logs and reboot the machine (instead of staring at a frozen X screen in agony). Suggested by Chris Wilson because I've been stubborn about allowing the gpu reset code no to fail, ever (by removing the trylock). Reviewed-by:
-
Daniel Vetter authored
So don't return -EAGAIN, even in the case of a gpu hang. Remap it to -EIO instead. Note that this isn't really an issue with interruptability, but more that we have quite a few codepaths (mostly around kms stuff) that simply can't handle any errors and hence not even -EAGAIN. Instead of adding proper failure paths so that we could restart these ioctls we've opted for the cheap way out of sleeping non-interruptibly. Which works everywhere but when the gpu dies, which this patch fixes. So essentially interruptible == false means 'wait for the gpu or die trying'.' This patch is a bit ugly because intel_ring_begin is all non-interruptible and hence only returns -EIO. But as the comment in there says, auditing all the callsites would be a pain. To avoid duplicating code, reuse i915_gem_check_wedge in __wait_seqno and intel_wait_ring_buffer. Also use the opportunity to clarify the different cases in i915_gem_check_wedge a bit with comments. v2: Don't access dev_priv->mm.interruptible from check_wedge - we might not hold dev->struct_mutex, making this racy. Instead pass interruptible in as a parameter. I've noticed this because I've hit a BUG_ON(!mutex_is_locked) at the top of check_wedge. This has been added in commit b4aca010 Author: Ben Widawsky <ben@bwidawsk.net> Date: Wed Apr 25 20:50:12 2012 -0700 drm/i915: extract some common olr+wedge code although that commit is missing any justification for this. I guess it's just copy&paste, because the same commit add the same BUG_ON check to check_olr, where it indeed makes sense. But in check_wedge everything we access is protected by other means, so this is superflous. And because it now gets in the way (we add a new caller in __wait_seqno, which can be called without dev->struct_mutext) let's just remove it. v3: Group all the i915_gem_check_wedge refactoring into this patch, so that this patch here is all about not returning -EAGAIN to callsites that can't handle syscall restarting. v4: Add clarification what interuptible == fales means in our code, requested by Ben Widawsky. v5: Fix EAGAIN mispell noticed by Chris Wilson. Reviewed-by:
Ben Widawsky <ben@bwidawsk.net> Reviewed-by:
-
Daniel Vetter authored
Simply failing to reset the gpu because someone else might still hold the mutex isn't a great idea - I see reliable silent reset failures. And gpu reset simply needs to be reliable and Just Work. "But ... the deadlocks!" We already kick all processes waiting for the gpu before launching the reset work item. New waiters need to check the wedging state anyway and then bail out. If we have places that can deadlock, we simply need to fix them. "But ... testing!" We have the gpu hangman, and if the current gpu load gem_exec_nop isn't good enough to hit a specific case, we can add a new one. "But ... don't we return -EAGAIN for non-interruptible calls to wait_seqno now?" Yep, but this problem already exists in the current code. A follow up patch will remedy this by returning -EIO for non-interruptible sleeps if the gpu died and the low-level wait bails out with -EAGAIN. Reviewed-by:
-
Paulo Zanoni authored
Only bits 30:28, bit 31 is PIPE_DDI_FUNC_ENABLE. Signed-off-by:
-
Eugeni Dodonov authored
This pollutes dmesg output even if we do not have FBC for the device, so move the DRM_DEBUG_KMS statement lower. v2: just kill the message as suggested by Daniel. Signed-off-by:
-
Eugeni Dodonov authored
This is necessary for the modesetting to work correctly after a suspend-resume cycle. Without this, the pipes and clocks got the correct configuration, but the underlying DDI buffers configuration was lost. Signed-off-by:
-
Paulo Zanoni authored
This function is used to set the PCH_DREF_CONTROL register, which does not exist on LPT anymore. Signed-off-by:
-
Paulo Zanoni authored
Previously we had has_pch_split to tell us whether we had a PCH or not and we also had dev_priv->pch_type to tell us which kind of PCH it was, but it could only be used if we were 100% sure we did have a PCH. Now that PCH_NONE was added to dev_priv->pch_type we don't need has_pch_split anymore: we can just check for pch_type != PCH_NONE. The HAS_PCH_{IBX,CPT,LPT} macros use dev_priv->pch_type, so they can only be called after intel_detect_pch. The HAS_PCH_SPLIT macro looks at dev_priv->info->has_pch_split, which is available earlier. Since the goal is to implement HAS_PCH_SPLIT using dev_priv->pch_type instead of dev_priv->info->has_pch_split, we need to make sure that intel_detect_pch is called before any calls to HAS_PCH_SPLIT are made. So we moved the intel_detect_pch call to an earlier stage. Signed-off-by: -
Paulo Zanoni authored
And rely on the fact that it's 0 to assume that machines without a PCH will have PCH_NONE as dev_priv->pch_type. Just today I finally realized that HAS_PCH_IBX is true for machines without a PCH. IMHO this is totally counter-intuitive and I don't think it's a good idea to assume that we're going to check for HAS_PCH_IBX only after we check for HAS_PCH_SPLIT. I believe that in the future we'll have more PCH types and checks like: if (HAS_PCH_IBX(dev) || HAS_PCH_CPT(dev)) will become more and more common. There's a good chance that we may break non-PCH machines by adding these checks in code that runs on all machines. I also believe that the HAS_PCH_SPLIT check will become less common as we add more and more different PCH types. We'll probably start replacing checks like: if (HAS_PCH_SPLIT(dev)) foo(); else bar(); with: if (HAS_PCH_NEW(dev)) baz(); else if (HAS_PCH_OLD(dev) || HAS_PCH_IBX(dev)) foo(); else bar(); and this may break gen 2/3/4. As far as we have investigated, this patch will affect the behavior of intel_hdmi_dpms and intel_dp_link_down on gen 4. In both functions the code inside the HAS_PCH_IBX check is for IBX-specific workarounds, so we should be safe. If we start bisecting gen 2/3/4 bugs to this commit we should consider replacing the HAS_PCH_IBX checks with something else. V2: Improve commit message, list possible side effects and solution. Signed-off-by: -
Jesse Barnes authored
High frequency link configurations have the potential to cause trouble with long and/or cheap cables, so prefer slow and wide configurations instead. This patch has the potential to cause trouble for eDP configurations that lie about available lanes, so if we run into that we can make it conditional on eDP. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45801 Tested-by: peter@colberg.org Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
-
Daniel Vetter authored
While creating the new enable/disable_gt_powersave functions in commit 8090c6b9 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Sun Jun 24 16:42:32 2012 +0200 drm/i915: wrap up gt powersave enabling functions I've botched up the handling of ironlake_disable_rc6. Fix this up by calling it at the right place. Note though that ironlake_disable_rc6 does a bit more than just disabling rc6 - it also tears down all the allocated context objects. Hence we need to move intel_teardown_rc6 out and directly call it from intel_modeset_cleanup. Also properly mark ironlake_enable_rc6 as static and kill the un-used declaration in i915_drv.h. Note: In review a question popped out why disable_rc6 also tears down the backing object and why we should move that out - it's simply for consistency with gen6+ rps code, which does it that way. Cc: Ben Widawsky <ben@bwidawsk.net> Reviewed-by:
-
Eugeni Dodonov authored
This commit moves force wake support routines into intel_pm modules, and exports the gen6_gt_check_fifodbg routine (used in I915_READ). Signed-off-by:
-
Eugeni Dodonov authored
For Haswell, on some of the early hardware revisions, it is possible to run into issues when RC6 state is enabled and when pipes change state. v2: add comment saying that this is for early revisions only. v3: beautify as suggested by Daniel Vetter. Signed-off-by:
-
Eugeni Dodonov authored
This is based on Ivy Bridge clock gating for now, but is subject to changes in the future. Note: Compared to the ivb clock gating this drops the the IDICOS medium uncore sharing tuned in commit 20848223 Author: Ben Widawsky <ben@bwidawsk.net> Date: Fri May 4 18:58:59 2012 -0700 drm/i915: set IDICOS to medium uncore resources Eugeni wants to benchmark the effect of this first. Signed-off-by:
-
Eugeni Dodonov authored
We weren't disabling RC6 bits when bringing down RPS. Signed-off-by:
-
Eugeni Dodonov authored
It should be working so let's turn it on by default and catch any possible issues faster. Signed-off-by:
-
Eugeni Dodonov authored
Just a cosmetic change to simplify the if statement. Signed-off-by:
-
Eugeni Dodonov authored
Most of the RPS and RC6 enabling functionality is similar to what we had on Gen6/Gen7, so we preserve most of the registers. Note that Haswell only has RC6, so account for that as well. As suggested by Daniel Vetter, to reduce the amount of changes in the patch, we still write the RC6p/RC6pp thresholds, but those are ignored on Haswell. Note: Some discussion about the nature of the new tuning constants popped up in review - the answer is that we don't know why they've changed, but the guide from VPG with the magic numbers simply has different values now. v2: Squash fix for ?: vs | operation precende bug into this patch. Signed-off-by:
-
- 03 Jul, 2012 3 commits
-
-
Eugeni Dodonov authored
There is a different ACK register for force wake on Haswell, so account for that. Signed-off-by:
-
Chris Wilson authored
As a w/a to prevent reads sporadically returning 0, we need to wait for the GT thread to return to TC0 before proceeding to read the registers. v2: adapt for Haswell changes (Eugeni). v3: use wait_for_atomic_us for thread status polling. v3: *really* use wait_for_atomic for polling. References: https://bugs.freedesktop.org/show_bug.cgi?id=50243Signed-off-by:
-
Chris Wilson authored
Tidy up the routines for interacting with the GT (in particular the forcewake dance) which are scattered throughout the code in a single structure. v2: use wait_for_atomic for polling. v3: *really* use wait_for_atomic for polling. Signed-off-by:
-
