- 15 Feb, 2012 1 commit
-
-
Chris Wilson authored
By recording the location of every request in the ringbuffer, we know that in order to retire the request the GPU must have finished reading it and so the GPU head is now beyond the tail of the request. We can therefore provide a conservative estimate of where the GPU is reading from in order to avoid having to read back the ring buffer registers when polling for space upon starting a new write into the ringbuffer. A secondary effect is that this allows us to convert intel_ring_buffer_wait() to use i915_wait_request() and so consolidate upon the single function to handle the complicated task of waiting upon the GPU. A necessary precaution is that we need to make that wait uninterruptible to match the existing conditions as all the callers of intel_ring_begin() have not been audited to handle ERESTARTSYS correctly. By using a conservative estimate for the head, and always processing all outstanding requests first, we prevent a race condition between using the estimate and direct reads of I915_RING_HEAD which could result in the value of the head going backwards, and the tail overflowing once again. We are also careful to mark any request that we skip over in order to free space in ring as consumed which provides a self-consistency check. Given sufficient abuse, such as a set of unthrottled GPU bound cairo-traces, avoiding the use of I915_RING_HEAD gives a 10-20% boost on Sandy Bridge (i5-2520m): firefox-paintball 18927ms -> 15646ms: 1.21x speedup firefox-fishtank 12563ms -> 11278ms: 1.11x speedup which is a mild consolation for the performance those traces achieved from exploiting the buggy autoreported head. v2: Add a few more comments and make request->tail a conservative estimate as suggested by Daniel Vetter. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> [danvet: resolve conflicts with retirement defering and the lack of the autoreport head removal (that will go in through -fixes).] Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
- 14 Feb, 2012 3 commits
-
-
Paulo Zanoni authored
This was pointed by Jesse Barnes. The code now seems to follow the specification but I don't have an SDVO device to really test this. Signed-off-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
-
Yufeng Shen authored
GMBUS has several ports and each has it's own corresponding I2C adpater. When multiple I2C adapters call gmbus_xfer() at the same time there is a race condition in using the underlying GMBUS controller. Fixing this by adding a mutex lock when calling gmbus_xfer(). v2: Moved gmbus_mutex below intel_gmbus and added comments. Rebased to drm-intel-next-queued. Signed-off-by:
Yufeng Shen <miletus@chromium.org> [danvet: Shortened the gmbus_mutex comment a bit and add the patch revision comment to the commit message.] Signed-off-by:
-
Wu Fengguang authored
When HDMI-DVI converter is used, it's not only necessary to turn off audio, but also to disable HDMI_MODE_SELECT and video infoframe. Since the DVI mode is mainly tied to audio functionality from end user POV, add a new "force-dvi" audio mode: xrandr --output HDMI1 --set audio force-dvi Note that most users won't need to set this and happily rely on the EDID based DVI auto detection. Reported-by:
Andrea Arcangeli <aarcange@redhat.com> Signed-off-by:
Wu Fengguang <fengguang.wu@intel.com> Signed-off-by:
-
- 13 Feb, 2012 5 commits
-
-
Sean Paul authored
This patch replaces the locking from the downclock routines with an assert to ensure the registers are indeed unlocked. Without this patch, pre-SNB devices would lock the registers when downclocking which would cause a WARNING on suspend/resume with downclocking enabled. Note: To hit this bug, you need to have lvds downclocking enabled. Signed-off-by:
Sean Paul <seanpaul@chromium.org> Acked-by:
-
Daniel Vetter authored
The locking in our setup and teardown paths is rather arbitrary, but generally we try to protect gem stuff with dev->struct_mutex. Further, the ums/gem ioctl to setup gem _does_ take the look. So fix up this benign inconsistency. Notice while reading through code. v2: Rebased on top of the ppgtt code. Reviewed-by:
-
Daniel Vetter authored
We still have reports of missed irqs even on Sandybridge with the HWSTAM workaround in place. Testing by the bug reporter gets rid of them with the forcewake voodoo and no HWSTAM writes. Because I've slightly botched the rebasing I've left out the ACTHD readback which is also required to get IVB working. Seems to still work on the tester's machine, so I think we should go with the more minmal approach on SNB. Especially since I've only found weak evidence for holding forcewake while waiting for an interrupt to arrive, but none for the ACTHD readback. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45181 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45332 Tested-by: Nicolas Kalkhof nkalkhof()at()web.de Acked-by:
-
Daniel Vetter authored
Currently we reserve seqnos only when we emit the request to the ring (by bumping dev_priv->next_seqno), but start using it much earlier for ring->oustanding_lazy_request. When 2 threads compete for the gpu and run on two different rings (e.g. ddx on blitter vs. compositor) hilarity ensued, especially when we get constantly interrupted while reserving buffers. Breakage seems to have been introduced in commit 6f392d54 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Sat Aug 7 11:01:22 2010 +0100 drm/i915: Use a common seqno for all rings. This patch fixes up the seqno reservation logic by moving it into i915_gem_next_request_seqno. The ring->add_request functions now superflously still return the new seqno through a pointer, that will be refactored in the next patch. Note that with this change we now unconditionally allocate a seqno, even when ->add_request might fail because the rings are full and the gpu died. But this does not open up a new can of worms because we can already leave behind an outstanding_request_seqno if e.g. the caller gets interrupted with a signal while stalling for the gpu in the eviciton paths. And with the bugfix we only ever have one seqno allocated per ring (and only that ring), so there are no ordering issues with multiple outstanding seqnos on the same ring. v2: Keep i915_gem_get_seqno (but move it to i915_gem.c) to make it clear that we only have one seqno counter for all rings. Suggested by Chris Wilson. v3: As suggested by Chris Wilson use i915_gem_next_request_seqno instead of ring->oustanding_lazy_request to make the follow-up refactoring more clearly correct. Also improve the commit message with issues discussed on irc. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45181 Tested-by: Nicolas Kalkhof nkalkhof()at()web.de Reviewed-by:
-
Daniel Vetter authored
So don't assign it false, that's just confusing ... No functional change here. Signed-Off-by:
-
- 11 Feb, 2012 3 commits
-
-
Ben Widawsky authored
If we don't have a sufficient number of free entries in the FIFO, we proceed to do a write anyway. With this check we should have a clue if that write actually failed or not. After some discussion with Daniel Vetter regarding his original complaint, we agreed upon this. Reviewed-by:
Ben Widawsky <ben@bwidawsk.net> Signed-off-by:
-
Ben Widawsky authored
This is similar to a patch I wrote several months ago. It's been updated for the new FORCEWAKE_MT. As recommended by Chris Wilson, use WARN() instead of DRM_ERROR, so we can get a backtrace. This shouldn't impact performance too much as the extra register read can replace the POSTING_READ we had previously. Reviewed-by:
-
Ben Widawsky authored
Add register definitions for GTFIFODBG, and clear it during init time to make sure state is correct. This register tells us if either a read, or a write occurred while the fifo was full. It seems like bit 2 is an OR of bit 0 and bit 1, so we check that as well, but the documents are not quite clear. Reviewed-by:
-
- 10 Feb, 2012 12 commits
-
-
Paulo Zanoni authored
I'm not sure why they are needed (I didn't notice any difference in my tests), but these bits are in our documentation and they are also set by the Windows driver. Signed-off-by:
-
Daniel Vetter authored
The drm core _really_ likes to frob around with the crtc timings and put halfed vertical timings (in fields) in there. Which confuses the overlay code, resulting in it's refusal to display anything at the lower half of an interlaced pipe. Tested-by:
Christopher Egert <cme3000@gmail.com> Reviewed-by:
Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-Off-by:
-
Peter Ross authored
Signed-off-by:
Peter Ross <pross@xvid.org> Reviewed-by:
Alfonso Fiore <alfonso.fiore@gmail.com> Signed-off-by:
-
Peter Ross authored
Signed-off-by:
-
Daniel Vetter authored
The hw seems to use this to correctly insert the required delay before/after an even/odd interlaced field. This might also explain why we need to substract 1 half-line from vtotal - if the hw just adds the delay programmend in VSYNCSHIFT the total frame time would be about that too long. These registers seems to only exist on gen4 and later. For paranoia also program it to 0 for progressive modes, but according to documentation the hw should just ignore it in this case. Reviewed-by:
-
Daniel Vetter authored
gen2 doesn't support it, so be a bit more paranoid and add a check to ensure that we never ever set an unsupported interlaced bit. Ensure that userspace can't set an interlaced mode by resetting interlace_allowed for the crt on gen2. dvo and lvds are the only other encoders that gen2 supports and these already disallow interlaced modes. Reviewed-by:
-
Daniel Vetter authored
According to Paulo Zanoni, this is what windows does. Reviewed-by:
-
Daniel Vetter authored
According to bspec, we need to subtract an additional line from vtotal for interlaced modes and vblank_end needs to equal vtotal. All other timing fields do not need this special treatment, so kill it. Bspec says that this is irrespective of whether the interlaced mode has an odd or even vtotal, both modes are supported. Reviewed-by:
-
Daniel Vetter authored
We have a pretty decent confusion about vertical timings of interlaced modes. Peter Ross has written a patch that makes interlace modes work on a lot more platforms/output combinations by doubling the vertical timings. The issue with that patch is that core drm _does_ support specifying whether we want these vertical timings in fields or frames, we just haven't managed to consistently use this facility. The relavant function is drm_mode_set_crtcinfo, which fills in the crtc timing information. The first thing to note is that the drm core keeps interlaced modes in frames, but displays modelines in fields. So when the crtc modeset helper copies over the mode into adjusted_mode it will already contain vertical timings in half-frames. The result is that the fixup code in intel_crtc_mode_fixup doesn't actually do anything (in most cases at least). Now gen3+ natively supports interlaced modes and wants the vertical timings in frames. Which is what sdvo already fixes up, at least under some conditions. There are a few other place that demand vertical timings in fields but never actually deal with interlaced modes, so use frame timings for consistency, too. These are: - lvds panel, - dvo encoders - dvo is the only way gen2 could support interlaced mode, but currently we don't support any encoders that do. - tv out - despite that the tv dac sends out an interlaced signal it expects a progressive mode pipe configuration. All these encoders enforce progressive modes by resetting interlace_allowed. Hence we always want crtc vertical timings in frames. Enforce this in our crtc mode_fixup function and rip out any redudant timing computations from the encoders' mode_fixup function. v2-4: Adjust the vertical timings a bit. v5: Split out the 'subtract-one for interlaced' fixes. v6: Clarify issues around tv-out and gen2. Reviewed-by:
-
Daniel Vetter authored
- Clarify which bits are for which chips. - Note that gen2 can't do interlaced directly (only via dvo tv chips). - Move the mask to the top to make it clearer how wide this field is. - Add defintions for all possible values. This patch doesn't change any code. v2: Paulo Zanoni pointed out that the pixel doubling modes do no longer exist on ivb. Cc: Peter Ross <pross@xvid.org> Reviewed-by:
-
Daniel Vetter authored
Back-merge from drm-fixes into drm-intel-next to sort out two things: - interlaced support: -fixes contains a bugfix to correctly clear interlaced configuration bits in case the bios sets up an interlaced mode and we want to set up the progressive mode (current kernels don't support interlaced). The actual feature work to support interlaced depends upon (and conflicts with) this bugfix. - forcewake voodoo to workaround missed IRQ issues: -fixes only enabled this for ivybridge, but some recent bug reports indicate that we need this on Sandybridge, too. But in a slightly different flavour and with other fixes and reworks on top. Additionally there are some forcewake cleanup patches heading to -next that would conflict with currrent -fixes. Signed-Off-by: -
Dave Airlie authored
Merge branch 'drm-intel-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/keithp/linux into drm-fixes * 'drm-intel-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/keithp/linux: drm/i915: fixup interlaced bits clearing in PIPECONF on PCH_SPLIT (v2) drm/i915: no lvds quirk for AOpen MP45 drm/i915: Force explicit bpp selection for intel_dp_link_required drm/i915: fixup interlaced bits clearing in PIPECONF on PCH_SPLIT drm/i915:: Disable FBC on SandyBridge
-
- 09 Feb, 2012 9 commits
-
-
Daniel Vetter authored
We want to unconditionally enable ppgtt for two reasons: - Windows uses this on snb and later. - We need the basic hw support to work before we can think about real per-process address spaces and other cool features we want. But Chris Wilson was complaining all over irc and intel-gfx that this will blow up if we don't have a module option to disable it. Hence add one, to prevent this. ppgtt support seems to slightly change the timings and make crashy things slightly more or less crashy. Now in my testing and the testing this got on troublesome snb machines, it seems to have improved things only. But on ivb it makes quite a few crashes happen much more often, see https://bugs.freedesktop.org/show_bug.cgi?id=41353 Luckily Eugeni Dodonov seems to have a set of workarounds that fix this issue. v2: Don't try to enable ppgtt on pre-snb. v3: Pimp commit message and make Chris Wilson less grumpy by adding a module option. v4: New try at making Chris Wilson happy. Reviewed-by:
-
Daniel Vetter authored
This was pretty usefull for debugging, might be useful for diagnosing issues. Reviewed-by:
-
Daniel Vetter authored
Split out for easier cross-checking of the boring pieces with bspec. Reviewed-by:
-
Daniel Vetter authored
This adds support to bind/unbind objects and wires it up. Objects are only put into the ppgtt when necessary, i.e. at execbuf time. Objects are still unconditionally put into the global gtt. v2: Kill the quick hack and explicitly pass cache_level to ppgtt_bind like for the global gtt function. Noticed by Chris Wilson. Reviewed-by:
-
Daniel Vetter authored
This just adds the setup and teardown code for the ppgtt PDE and the last-level pagetables, which are fixed for the entire lifetime, at least for the moment. v2: Kill the stray debug printk noted by and improve the pte definitions as suggested by Chris Wilson. v3: Clean up the aperture stealing code as noted by Ben Widawsky. v4: Paint the init code in a more pleasing colour as suggest by Chris Wilson. v5: Explain the magic numbers noticed by Ben Widawsky. Reviewed-by:
-
Daniel Vetter authored
We need this because ppgtt page directory entries need to be in the global gtt pagetable. Reviewed-by:
-
Daniel Vetter authored
To implement a PPGTT for drm/i915 that fully aliases the GTT, we also need to properly alias the scratch page. Reviewed-by:
-
Daniel Vetter authored
Chris Wilson and me have again stared at funny error states and it's been pretty clear from the start that something was seriously amiss. The seqnos last seen by the cpu were a few hundred behind those that the gpu could have possibly emitted last before it died ... Chris now tracked it down (hopefully, definit verdict's still out), but in hindsight we'd have found the bug by simply dumping the cpu side tracking of the ring head and tail registers. Fix this and prevent an identical time-waster in the future. Because the hangs always involved semaphores in one way or another, we've tried to dump the mbox registers, but couldn't find any inconsistencies. Still, dump them too. Reviewed-and-wanted-by:
-
Daniel Vetter authored
These are all user-trigerable, so tune down their loudness a notch. For some of these we have i-g-t tests (because they prevent newly-discovered bugs), without this patches running the test suite leaves behind a dirty dmesg. Reviewed-by:
-
- 08 Feb, 2012 5 commits
-
-
Daniel Vetter authored
Reviewed-by:
-
Daniel Vetter authored
On gen5 we also need to correctly set up swizzling in the display scanout engine, but only there. Consolidate this into the same function. This has a small effect on ums setups - the kernel now also sets this bit in addition to userspace setting it. Given that this code only runs when userspace either can't (resume, gpu reset) or explicitly won't(gem_init) touch the hw this shouldn't have an adverse effect. Reviewed-by:
-
Daniel Vetter authored
We have to do this manually. Somebody had a Great Idea. I've measured speed-ups just a few percent above the noise level (below 5% for the best case), but no slowdows. Chris Wilson measured quite a bit more (10-20% above the usual snb variance) on a more recent and better tuned version of sna, but also recorded a few slow-downs on benchmarks know for uglier amounts of snb-induced variance. v2: Incorporate Ben Widawsky's preliminary review comments and elaborate a bit about the performance impact in the changelog. v3: Add a comment as to why we don't need to check the 3rd memory channel. v4: Fixup whitespace. Acked-by:
Eric Anholt <eric@anholt.net> Signed-Off-by:
-
Keith Packard authored
An identical patch has been merged for i9xx_crtc_mode_set: Commit 59df7b17 Author: Christian Schmidt <schmidt@digadd.de> Date: Mon Dec 19 20:03:33 2011 +0100 drm/intel: Fix initialization if startup happens in interlaced mode [v2] But that one neglected to fix up the ironlake+ path. This should fix the issue reported by Alfonso Fiore where booting with only a HDMI cable connected to his TV failed to display anything. The issue is that the bios set up things for 1080i and used the pannel fitter to scale up the lower progressive resolutions. We failed to clear the interlace bit in the PIPEACONF register, resulting in havoc. v2: Be more paranoid and just unconditionally clear the field before setting new values. Cc: Peter Ross <pross@xvid.org> Cc: Alfonso Fiore <alfonso.fiore@gmail.com> Signed-Off-by:
Keith Packard <keithp@keithp.com>
-
Daniel Vetter authored
According to a bug report, it doesn't have one. Cc: stable@kernel.org Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44263Acked-by:
-
- 06 Feb, 2012 1 commit
-
-
Keith Packard authored
It is never correct to use intel_crtc->bpp in intel_dp_link_required, so instead pass an explicit bpp in to this function. This patch only supports 18bpp and 24bpp modes, which means that 10bpc modes will be computed incorrectly. Fixing that will require more extensive changes, and so must be addressed separately from this bugfix. intel_dp_link_required is called from intel_dp_mode_valid and intel_dp_mode_fixup. * intel_dp_mode_valid is called to list supported modes; in this case, the current crtc values cannot be relevant as the modes in question may never be selected. Thus, using intel_crtc->bpp is never right. * intel_dp_mode_fixup is called during mode setting, but it is run well before ironlake_crtc_mode_set is called to set intel_crtc->bpp, so using intel_crtc-bpp in this path can only ever get a stale value. Cc: Lubos Kolouch <lubos.kolouch@gmail.com> Cc: Adam Jackson <ajax@redhat.com> Cc: stable@vger.kernel.org Reviewed-by:
Dave Airlie <airlied@redhat.com> Tested-by: camalot@picnicpark.org (Dell Latitude 6510) Tested-by:
Roland Dreier <roland@digitalvampire.org> Signed-off-by:
-
- 03 Feb, 2012 1 commit
-
-
Matthijs Kooijman authored
This return statement got dropped while fixing the conflicts introduced in 7a7e8734. Reviewed-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
