summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2012-08-06drm/i915: Workaround hang with BSD and forcewake on SandyBridgeChris Wilson
For reasons that are not apparent to anybody, 990bbdadaba (drm/i915: Group the GT routines together in both code and vtable) breaks the use of the BitStream Decoder ring on SandyBridge. The active ingredient of that patch is the conversion from a udelay(10) to a udelay(1) in the busy-wait loop of waiting for the forcewake acknowledge. If we restore that udelay(10) or insert another udelay(1) afterwards (or any wait longer than 250ns) everything works again. An alternative is also to remove any delay from the busy-wait loop. Given that in the atomic sections we want to complete the wait as quick as possible to avoid blocking the CPU for too long, it makes sense to remove the delay altogether and simply spin on the exit condition until it completes. So we replace the udelay(1) with cpu_relax(). Papers over regression from commit 990bbdadabaa51828e475eda86ee5720a4910cc3 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Mon Jul 2 11:51:02 2012 -0300 drm/i915: Group the GT routines together in both code and vtable Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=51738 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-08-06drm/i915: Make intel_panel_get_backlight static.Stéphane Marchesin
This function isn't used outside of intel_panel.c, so make it static. Signed-off-by: Stéphane Marchesin <marcheu@chromium.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-08-05i915: don't map imported dma-bufs for dmar.Dave Airlie
The exporter should have given us pages in the correct place, avoid the prepare object mapping phase on dmar systems. This fixes an oops on a GM45/R600 machine, when running the intel/radeon tests. Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-08-05drm/i915: remove unused variableDevendra Naga
the following warning was produced, drivers/gpu/drm/i915/i915_gem_context.c: In function ‘i915_switch_context’: drivers/gpu/drm/i915/i915_gem_context.c:454:6: warning: unused variable ‘ret’ [-Wunused-variable] fix up by removing it Signed-off-by: Devendra Naga <devendra.aaru@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-08-05drm/i915: Don't forget to apply SNB PIPE_CONTROL GTT workaround.Eric Anholt
If a buffer that was the target of a PIPE_CONTROL from userland was a reused one that hadn't been evicted which had not previously had this workaround applied, then the early return for a correct presumed_offset in this function meant we would not bind it into the GTT and the write would land somewhere else. Fixes reproducible failures with GL_EXT_timer_query usage in apitrace, and I also expect it to fix the intermittent OQ issues on snb that danvet's been working on. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=48019 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=52932 Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Carl Worth <cworth@cworth.org> Tested-by: Carl Worth <cworth@cworth.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-07-27drm/i915: fix forcewake related hangs on snbDaniel Vetter
... by adding seemingly redudant posting reads. This little dragon lair exploded the first time around when we've refactored the code a bit to use the common wait_for_atomic_us in "drm/i915: Group the GT routines together in both code and vtable", which caused QA to file fdo bug #51738. Chris Wilson entertained a few approaches to fixing #51738: Replacing the udelay(1) with the previously-used udelay(10) (or any other "sufficiently larger" delay), adding a posting read, or ditching the delay completely and using cpu_relax. We went with the cpu_relax and "915: Workaround hang with BSD and forcewake on SandyBridge". Which blew up in fdo bug #52424, but adding the posting read while still using cpu_relax seems to also fix that, it looks like the posting read is the important ingriedient to fix these rc6 related hangs on snb. Popular theories as to why this is like it is include: - A herd of pink elephants got royally angered somehow. - The gpu has internally different functional units and judging by the register offsets, the forcewake request register and the forcewake ack registers are _not_ in the same functional unit (or at least aren't reached through the same routes). Hence the posting read syncs up with the wrong block and gets the entire gpu confused. - ... As a minimal ducttape fix for 3.6, let's just put these posting reads into place again. We can try fancier approaches (like adding back the cpu_relax instead of the udelay) in -next. This (re-)fixes a regression introduced in commit 990bbdadabaa51828e475eda86ee5720a4910cc3 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Mon Jul 2 11:51:02 2012 -0300 drm/i915: Group the GT routines together in both code and vtable Cc: Chris Wilson <chris@chris-wilson.co.uk> Tested-by: Chris Wilson <chris@chris-wilson.co.uk> Tested-by: Du Yan <yanx.du@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=52424 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=51738u Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-07-26i915: Remove silly testAlan Cox
drv_priv->gmbus is an array. Comparing it with NULL is somewhat less useful than a chocolate teapot. Possibly we should be testing bus != NULL each iteration of the loop instead ? gcc could help by warning too! Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-07-26i915: fix error path leak in intel_sdvo_write_cmdAlan Cox
Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-07-26vlv: it might be wise if we initialised the flag value...Alan Cox
Otherwise our initial behaviour is "randomly save a bogus PLL choice" as far as I can see. Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-07-25drm/i915: unbreak lastclose for failed driver initDaniel Vetter
We now refuse to load on gen6+ if kms is not enabled: commit 26394d9251879231b85e6c8cf899fa43e75c68f1 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Mon Mar 26 21:33:18 2012 +0200 drm/i915: refuse to load on gen6+ without kms Which results in the drm core calling our lastclose function to clean up the mess, but that one is neatly broken for such failure cases since kms has been introduced in commit 79e539453b34e35f39299a899d263b0a1f1670bd Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Fri Nov 7 14:24:08 2008 -0800 DRM: i915: add mode setting support Reported-and-tested-by: Paulo Zanoni <przanoni@gmail.com> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-07-25drm/i915: Set the context before setting up regs for the context.Eric Anholt
Fixes failures in transform feedback on gen7 because our SOL_RESET flag was setting the transform feedback offsets in the old context (occasionally happened to be ours) instead of the new context. Signed-off-by: Eric Anholt <eric@anholt.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-07-25drm/i915: constify mode in crtc_mode_fixupDaniel Vetter
Laurent Pinchart missed this when sending in is giant constify patch: commit e811f5ae19043b2ac2c28e147a4274038e655598 Author: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Date: Tue Jul 17 17:56:50 2012 +0200 drm: Make the .mode_fixup() operations mode argument a const pointer Acked-by; Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-07-25drm/i915/lvds: ditch ->prepare special caseDaniel Vetter
LVDS is the first output where dpms on/off and prepare/commit don't perfectly match. Now the idea behind this special case seems to be that for simple resolution changes on the LVDS we don't need to stop the pipe, because (at least on newer chips) we can adjust the panel fitter on the fly. There are a few problems with the current code though: - We still stop and restart the pipe unconditionally, because the crtc helper code isn't flexible enough. - We show some ugly flickering, especially when changing crtcs (this the crtc helper would actually take into account, but we don't implement the encoder->get_crtc callback required to make this work properly). So it doesn't even work as advertised. I agree that it would be nice to do resolution changes on LVDS (and also eDP) whithout blacking the screen where the panel fitter allows to do that. But imo we should implement this as a special case a few layers up in the mode set code, akin to how we already detect simple framebuffer changes (and only update the required registers with ->mode_set_base). Until this is all in place, make our lives easier and just rip it out. Also note that this seems to fix actual bugs with enabling the lvds output, see: http://lists.freedesktop.org/archives/intel-gfx/2012-July/018614.html Cc: Takashi Iwai <tiwai@suse.de> Cc: Giacomo Comes <comes@naic.edu> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Tested-by: Takashi Iwai <tiwai@suse.de> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-07-25drm/i915: dereferencing an error pointerDan Carpenter
We need to check that "ctx" is a valid pointer before dereferencing it. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-07-25drm/i915: fix invalid reference handling of the default ctx objChris Wilson
Otherwise we end up trying to unpin a freed object and BUG. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-07-25drm/i915: Add -EIO to the list of known errors for __wait_seqnoChris Wilson
This prevents a WARN introduced with commit de2b998552c1534e87bfbc51ec5734b02bc89020 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Wed Jul 4 22:52:50 2012 +0200 drm/i915: don't return a spurious -EIO from intel_ring_begin Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-07-25drm/i915: Flush the context object from the CPU caches upon switchingChris Wilson
The issue is that we stale data in the CPU caches, when we come to swap-out the object, the CPU may short-circuit the reads from those cacheline and so corrupt the context object. Secondary, leaving the context object as being marked in the CPU write domain whilst on the GPU active list is a bad idea and will throw warnings later. Note: Thanks to calling set_to_gtt_domain with write = false and not setting any gpu write domain when putting a context object onto the active list (when we switch away from it) the set_to_gtt_domain call won't block. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> [danvet: Added a note to the commit message and a comment in the code to explain the clever non-blocking trick.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-07-20drm/i915: Make the lock for pageflips interruptibleChris Wilson
As we take the struct_mutex lock to access the command-stream, there is a possibility that we may need to wait for a GPU hang and so should make the lock both interruptible and error-checking. References: https://bugs.freedesktop.org/show_bug.cgi?id=50069 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-07-20drm/i915: don't forget the PCH backlight registersPaulo Zanoni
When we enable/disable the CPU backlight registers we can't forget to enable/disable the PCH backlight registers. Since we're using the CPU registers we should also unset the override bit. Fixes a regression on the following commit: drm/i915: properly enable the blc controller on the right pipe The commit just deleted the code that sets the PCH registers, so it was relying on the values set by the BIOS. I told my BIOS to boot on the DVI monitor instead of the LVDS panel, so I noticed the bug. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-07-20drm/i915: Insert a flush between batches if the breadcrumb was droppedChris Wilson
If we drop the breadcrumb request after a batch due to a signal for example we aim to fix it up at the next opportunity. In this case we emit a second batchbuffer with no waits upon the first and so no opportunity to insert the missing request, so we need to emit the missing flush for coherency. (Note that that invalidating the render cache is the same as flushing it, so there should have been no observable corruption.) Note that beside simply adding the missing flush, avoiding potential render corruption, this will also fix at least parts of the problem introduced by some funny interaction of these two commits: commit de2b998552c1534e87bfbc51ec5734b02bc89020 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Wed Jul 4 22:52:50 2012 +0200 drm/i915: don't return a spurious -EIO from intel_ring_begin which allowed intel_ring_begin to return -ERESTARTSYS and commit cc889e0f6ce6a63c62db17d702ecfed86d58083f Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Wed Jun 13 20:45:19 2012 +0200 drm/i915: disable flushing_list/gpu_write_list which essentially disabled the flushing list. The issue happens when we submit a batch & emit it, but get interrupted (thanks to the first patch) while trying to emit the flush. On the next batch we still assume that the full gpu domain handling is in effect and hence compute the invalidate&flushing domains. But thanks to the 2nd patch we totally ignore these and only invalidate all gpu domains, presuming that any required flushes have been issued already. Which is wrong and eventually results in us updating the new write_domain values with the computed pending_write_domain values, which leaves an object with write_domain == 0 on the gpu_write_list. As soon as we try to unbind that object, things blow up. Fix this by emitting the missing flush according to the new ring->gpu_caches_dirty flag. Note that this does _not_ fix all the current cases where we end up with an object on the flushing_list that can't be flushed. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=52040 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> [danvet: Add bug explanation to commit message.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-07-20drm/i915: missing error case in init status pageBen Widawsky
Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-07-20drm/i915: mask tiled bit when updating ILK spritesAnder Conselvan de Oliveira
Or going from tiled to untiled may break. Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-07-20drm/i915: try to train DP even harderPaulo Zanoni
While debugging Haswell link train failures I observed that we never try the maximum voltage configuration more than once consecutively. We start the training, the monitor keeps telling us to increase the voltage, then when we reach the maximum we just go back to the start (because of the "memset" above "voltage_tries = 0"). When we reach this point, we keep alternating between the maximum and the minimum voltages until we give up. The DP spec suggests that we should try the same voltage 5 times before giving up. This patch makes us try the maximum voltage at least 5 times before going back to the minimum voltages. This patch does not fix any particular bug I'm aware of. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-07-20drm/i915: kill intel_ddc_probeDaniel Vetter
We have way too much lying hardware to rely on a simple "does someone answer on the ddc i2c address?" check. And now it's unused, so just kill it. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-07-20drm/i915: check whether we actually received an edid in detect_ddcDaniel Vetter
Somehow detect_ddc manages to fall through all checks when we think that something responds on the ddc i2c address, but the edid read failed. Fix this up by explicitly checking for this case. This fixes a regression on newer chips because since commit aaa377302b2994fcc2c66741b47da33feb489dca Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Sat Jun 16 15:30:32 2012 +0200 drm/i915/crt: Do not rely upon the HPD presence pin we use ddc detection also on hotplug capable platforms. And one of these reads all 0s for any i2c transaction if nothing is connected to the vga port. v2: Implement Chris Wilson's review: - simplify logic, default to "nothing detected" - kill stale comment - BUG_ON(!crt->type != ANALOG) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=51900 Tested-by: Yang Guang <guang.a.yang@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-07-20drm/i915: fix up PCH backlight #define mixupDaniel Vetter
I so totally suck. This can cause a black screen if (for whatever reason) the bios hasn't set this bit itself. This regression has been introduced in commit 7cf4160148136deb31ee5f2802857dd935a38529 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Tue Jun 5 10:07:09 2012 +0200 drm/i915: clear up backlight #define confusion on gen4+ Tested-by: Kenneth Graunke <kenneth@whitecape.org> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-07-20drm/i915: Add comments to explain the BSD tail write workaroundChris Wilson
Having had to dive into the bspec to understand what each stage of the workaround meant, and how that the ring broadcasting IDLE corresponded with the GT powering down the ring (i.e. rc6) add comments to aide the next reader. And since the register "is used to control all aspects of PSMI and power saving functions" that makes it quite interesting to inspect with regards to RC6 hangs, so add it to the error-state. v2: Rediscover the piece of magic, set the RNCID to 0 before waiting for the ring to wake up. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-07-20drm/i915: Disable the BLT on pre-production SNB hardwareChris Wilson
It never quite worked despite the numerous workarounds, yet I still see people trying to use this hardware and filing bug reports. As we no longer even try to implement the workarounds, since 6a233c78878 (drm/i915/ringbuffer: kill snb blt workaround), simply disable the ring. v2: Add a message to inform the user about the limited capabilities of their pre-production hardware. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Eric Anholt <eric@anholt.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-07-20drm/i915: initialize power wells in modeset_init_hwEugeni Dodonov
This initializes power wells within the modeset_init_hw routine. Testing has shown that this works for both driver load time and for suspend-resume code paths. Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-07-20drm/i915: Only request PM interrupts for the events we handledChris Wilson
There is little point waking up every 10ms to service an interrupt which we then promptly ignore. So only program the the PMIER to enable interrupts for those events which we do handle, not all of them! Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: Eugeni Dodonov <eugeni.dodonov@intel.com> Cc: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-07-20drm/i915/context: Add missing IVB context sizesBen Widawsky
There were some fields missed. Daniel pointed this out in review, and I know I fixed it, but something happened somehow and some time. Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-07-20drm/i915/context/: s/CTX/CXTBen Widawsky
*sigh* the docs had it spelled wrong, corrected it, and then proceeded to re-do the original error. The original code preserved this history, and this patch attempts to keep in sync with the current docs. Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-07-19drm/sis: fixup sis_mm ioctl structsDaniel Vetter
Userspace uses long in quite a few places more than the kernel. Which gives me neat proof that I'm the only guy on this side of the galaxy who ever tried to run glxgears on a 64bit machine with sis graphics on linux. Note that the longs in drm_sis_mem_t aren't aligned properly, so this won't even work with 32bit userspace on 64bit kernel as-is. Hence the patch can't break that, either. Nope, I'm not nuts enough to write the 32bit ioctl compat layer for this and test it with some wine app. Even though hunting the ebay dungeons for a sis card actually supported by the mesa drivers casts some doubts on this ... Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-07-19drm: kill i915/i830 ids from drm_pciids.hDaniel Vetter
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-07-19drm: unconditionally clean up dma buffers of closing clientsDaniel Vetter
With the last patch to ditch DMA_QUEUE support, we should be able to call the dma cleanup uncoditionally, even when the master has disappeared. Do so because it just makes more sense. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-07-19drm: kill dma queue supportDaniel Vetter
Absolutely unused. All the values are only ever initialized and then used at most in some debug printout functions. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-07-19drm: ditch strange DRIVER_DMA_QUEUE only error bail-outDaniel Vetter
Only one driver (i810) even sets that flag. Now the actual locking code uncoditionally promotes lock->context to an unsigned int. Closer inspection of the userspace reveals that the drm lock context is defined as an unsigned int (at least on linux). I suspect we just have a strange case of signedness confusion going on. Tested on my i815, doesn't seem to break anything. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-07-19drm: kill reclaim_buffers callbackDaniel Vetter
All leftover users either haven't set DRIVER_HAVE_DMA, in which case this will never be called, or use the drm_core implementation. Call that directly in the only callsite. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-07-19drm/savage: clean up reclaim_buffersDaniel Vetter
The reclaim_buffers function of the savage driver actually wants to run with the hw_lock held - at least there are printks in the call-chain to that effect. But the drm core only calls reclaim_buffers as used by savage _after_ forcefully dropping the hwlock (in case it's still hold by the closing fd). So do the same idlelock dance as for the other dma drivers and hope that papers over any issues. v2: Don't let the idlelock linger around. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Tested-by: Tormod Volden <debian.tormod@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-07-19drm: kill reclaim_buffers_lockedDaniel Vetter
i810 was the last user of this code, with that gone, kill it. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-07-19Revert "Revert "drm/i810: cleanup reclaim_buffers""Daniel Vetter
This reverts commit 6e877b576ddf7cde5db2e9a6dcb56fef0ea77e64, reinstating the original commit: commit 87499ffdcb1c70f66988cd8febc4ead0ba2f9118 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Tue Oct 25 23:51:24 2011 +0200 drm/i810: cleanup reclaim_buffers My dear old i815 always hits the deadlocked on reclaim_buffers warning. Switch over to the idlelock duct-tape on hope that works better. I've fired up my i815 and now closing glxgears doesn't take 5 seconds anymore. \o/ The original problem with that was that I've moved it ahead in the series so that it could be included despite some patches not being ready quite yet. The little problem is that this patch required some of the previous rework to work correctly. Now that everything is in the right order again, this actually works on my i810 and does speed up closing gl apps as the original commit claimed. Without hanging the machine, as the revert says. Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-07-19drm: kill reclaim_buffers_idlelocked functionsDaniel Vetter
The only two users are now folded into the drivers preclose functions, so this is unused. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-07-19drm/sis: clean up reclaim_buffersDaniel Vetter
Like for via. v2: Actually drop the idlelock again if taken. v3: Fixup. v4: Fixup the "has master" vs. "is master" confusion the refactor introduced. v5: Drop the idlelock in the early return path. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-07-19drm/via: clean up reclaim_buffersDaniel Vetter
A few things - kill reclaim_buffers, it's never ever called because via does not set DRIVER_HAVE_DMA - inline the idlelock dance into the buffer reclaim logic and make it a simple preclose cleanup function - directly call the the dma_quiescent function and kill the needless if check. v2: Actually drop the idlelock when we take it. Reported by James Simmons. v3: Rebased onto latest drm-next. v4: Fixup the refactor. v5: More fixup the refactor - I've accidentally changed the check for any master to checking whether the closing fd is the master. v6: Don't forget to drop the idlelock in the early return path, too. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-07-19drm/udl: port over blanking code from udlfb.Dave Airlie
This ports over the dpms code from udlfb, and should mean a better chance of turning on some udl devices. Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-07-19drm/radeon/kms: auto detect pcie link speed from root portDave Airlie
This check the root ports supported link speeds and enables GEN2 mode if the 5.0 GT link speed is available. The first 3.0 cards are SI so they will probably need more investigation. Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-07-19drm/pci: add support for getting the supported link bw.Dave Airlie
This should work for PCIE3.0 as well. Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-07-19pci_regs: define LNKSTA2 pcie cap + bits.Dave Airlie
We need these for detecting the max link speed for drm drivers. Acked-by: Bjorn Helgaas <bhelgass@google.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-07-19drm/radeon: improve GPU lockup debugging info on r6xx/r7xx/r8xx/r9xxJerome Glisse
Print various CP register that have valuable informations regarding GPU lockup. Signed-off-by: Jerome Glisse <jglisse@redhat.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-07-19drm/mgag200: fix null pointer dereferenceDevendra Naga
we are referencing the pointer after doing alloc_apertures, as alloc_apertures kzallocs, the kzalloc may fail and we get a NULL. so we need to check for NULL before we dereference this pointer Signed-off-by: Devendra Naga <devendra.aaru@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
generated by cgit v1.2.3 (git 2.39.1) at 2024-10-24 16:28:28 +0000