summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
2012-07-26Merge branch 'drm-next' of git://people.freedesktop.org/~airlied/linuxLinus Torvalds
Pull drm updates from Dave Airlie: "One of the smaller drm -next pulls in ages! Ben (nouveau) has a rewrite in progress but we decided to leave it stew for another cycle, so just some fixes from him. - radeon: lots of documentation work, fixes, more ring and locking changes, pcie gen2, more dp fixes. - i915: haswell features, gpu reset fixes, /dev/agpgart removal on machines that we never used it on, more VGA/HDP fix., more DP fixes - drm core: cleanups from Daniel, sis 64-bit fixes, range allocator colouring. but yeah fairly quiet merge this time, probably because I missed half of it!" Trivial add-add conflict in include/linux/pci_regs.h * 'drm-next' of git://people.freedesktop.org/~airlied/linux: (255 commits) drm/nouveau: init vblank requests list drm/nv50: extend vblank semaphore to generic dmaobj + offset pair drm/nouveau: mark most of our ioctls as deprecated, move to compat layer drm/nouveau: move current gpuobj code out of nouveau_object.c drm/nouveau/gem: fix object reference leak in a failure path drm/nv50: rename INVALID_QUERY_OR_TEXTURE error to INVALID_OPERATION drm/nv84: decode PCRYPT errors drm/nouveau: dcb table quirk for fdo#50830 nouveau: Fix alignment requirements on src and dst addresses drm/i915: unbreak lastclose for failed driver init drm/i915: Set the context before setting up regs for the context. drm/i915: constify mode in crtc_mode_fixup drm/i915/lvds: ditch ->prepare special case drm/i915: dereferencing an error pointer drm/i915: fix invalid reference handling of the default ctx obj drm/i915: Add -EIO to the list of known errors for __wait_seqno drm/i915: Flush the context object from the CPU caches upon switching drm/radeon: fix dpms on/off on trinity/aruba v2 drm/radeon: on hotplug force link training to happen (v2) drm/radeon: fix hotplug of DP to DVI|HDMI passive adapters (v2) ...
2012-07-26Merge branch 'drm-intel-fixes' of ↵Dave Airlie
git://people.freedesktop.org/~danvet/drm-intel into drm-next Daniel writes: (this pull is the one with the bad patch dropped) First pile of fixes for 3.6 already, and I'm afraid it's a bit larger than what I'd wish for. But I've moved all the feature-y stuff to -next, so this really is all -fixes. Most of it is handling fallout from the hw context stuff, discovered now that mesa git has started using them for real. Otherwise all just small fixes: - unbreak modeset=0 on gen6+ (regressed in next) - const mismatch fix for ->mode_fixup - simplify overly clever lvds modeset code (current code can totally confuse backlights, resulting in broken panels until a full power draw restores them). - fix some fallout from the flushing_list disabling (regression only introduced in -next) - DP link train improvements (this also kills the last 3.2 dp regression afaik) - bugfix for the new ddc VGA detection on newer platforms - minor backlight fixes (one of them a -next regression) - only enable the required PM interrupts (to avoid waking up the cpu unnecessarily) - some really minor bits (workaround clarification, make coverty happy, hsw init fix) * 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel: (23 commits) drm/i915: unbreak lastclose for failed driver init drm/i915: Set the context before setting up regs for the context. drm/i915: constify mode in crtc_mode_fixup drm/i915/lvds: ditch ->prepare special case drm/i915: dereferencing an error pointer drm/i915: fix invalid reference handling of the default ctx obj drm/i915: Add -EIO to the list of known errors for __wait_seqno drm/i915: Flush the context object from the CPU caches upon switching drm/i915: Make the lock for pageflips interruptible drm/i915: don't forget the PCH backlight registers drm/i915: Insert a flush between batches if the breadcrumb was dropped drm/i915: missing error case in init status page drm/i915: mask tiled bit when updating ILK sprites drm/i915: try to train DP even harder drm/i915: kill intel_ddc_probe drm/i915: check whether we actually received an edid in detect_ddc drm/i915: fix up PCH backlight #define mixup drm/i915: Add comments to explain the BSD tail write workaround drm/i915: Disable the BLT on pre-production SNB hardware drm/i915: initialize power wells in modeset_init_hw ...
2012-07-26Merge branch 'drm-nouveau-fixes' of ↵Dave Airlie
git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-next * 'drm-nouveau-fixes' of git://anongit.freedesktop.org/git/nouveau/linux-2.6: drm/nouveau: init vblank requests list drm/nv50: extend vblank semaphore to generic dmaobj + offset pair drm/nouveau: mark most of our ioctls as deprecated, move to compat layer drm/nouveau: move current gpuobj code out of nouveau_object.c drm/nouveau/gem: fix object reference leak in a failure path drm/nv50: rename INVALID_QUERY_OR_TEXTURE error to INVALID_OPERATION drm/nv84: decode PCRYPT errors drm/nouveau: dcb table quirk for fdo#50830 nouveau: Fix alignment requirements on src and dst addresses
2012-07-26drm/nouveau: init vblank requests listMarcin Slusarz
Fixes kernel panic when vblank interrupt triggers before first sync to vblank request. (Besides init, remove some relevant leftovers from vblank rework) Reported-by: Ortwin Glück <odi@odi.ch> Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com> Cc: stable@vger.kernel.org [3.5] Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2012-07-26drm/nv50: extend vblank semaphore to generic dmaobj + offset pairBen Skeggs
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2012-07-26drm/nouveau: mark most of our ioctls as deprecated, move to compat layerBen Skeggs
These will be replaced in the near future, the code isn't yet stable enough for this merge window however. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2012-07-26drm/nouveau: move current gpuobj code out of nouveau_object.cBen Skeggs
I want this file for the new interfaces... Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2012-07-26drm/nouveau/gem: fix object reference leak in a failure pathBen Skeggs
Reported-by: Maarten Lankhorst <maarten.lankhorst@canonical.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
2012-07-26drm/nv50: rename INVALID_QUERY_OR_TEXTURE error to INVALID_OPERATIONMarcin Slusarz
Current name is misleading, because this error can be triggered by other conditions, like changing STRMOUT parameter without disabling STRMOUT first. Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2012-07-26drm/nv84: decode PCRYPT errorsMarcin Slusarz
Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2012-07-26drm/nouveau: dcb table quirk for fdo#50830Ben Skeggs
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2012-07-26nouveau: Fix alignment requirements on src and dst addressesMaarten Lankhorst
Linear copy works by adding the offset to the buffer address, which may end up not being 16-byte aligned. Some tests I've written for prime_pcopy show that the engine allows this correctly, so the restriction on lowest 4 bits of address can be lifted safely. The comments added were by envyas, I think because I used a newer version. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com> Cc: stable@vger.kernel.org
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-25drm/radeon: fix dpms on/off on trinity/aruba v2Jerome Glisse
The external encoder need to be setup again before enabling the transmiter. This seems to be only needed on some trinity/aruba to fix dpms on. v2: Add comment, only setup again on dce6 ie aruba or newer. Cc: <stable@kernel.org> 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-25drm/radeon: on hotplug force link training to happen (v2)Jerome Glisse
To have DP behave like VGA/DVI we need to retrain the link on hotplug. For this to happen we need to force link training to happen by setting connector dpms to off before asking it turning it on again. v2: agd5f - drop the dp_get_link_status() change in atombios_dp.c for now. We still need the dpms OFF change. Signed-off-by: Jerome Glisse <jglisse@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-07-25drm/radeon: fix hotplug of DP to DVI|HDMI passive adapters (v2)Jerome Glisse
No need to retrain the link for passive adapters. v2: agd5f - no passive DP to VGA adapters, update comments - assign radeon_connector_atom_dig after we are sure we have a digital connector as analog connectors have different private data. - get new sink type before checking for retrain. No need to check if it's no longer a DP connection. Cc: <stable@vger.kernel.org> Signed-off-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-07-25drm/radeon: fix non revealent error messageJerome Glisse
We want to print link status query failed only if it's an unexepected fail. If we query to see if we need link training it might be because there is nothing connected and thus link status query have the right to fail in that case. To avoid printing failure when it's expected, move the failure message to proper place. Cc: stable@vger.kernel.org Signed-off-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-07-25drm/radeon: check for allocation failure in radeon_ring_backup()Dan Carpenter
Static checkers complain if this we don't check for allocation failure. Also we can use the new kmalloc_array() function here as a cleanup. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-07-25drm/radeon: fix bo creation retry pathJerome Glisse
Retry label was at wrong place in function leading to memory leak. Cc: <stable@vger.kernel.org> Signed-off-by: Jerome Glisse <jglisse@redhat.com> Reviewed-by: Michel Dänzer <michel.daenzer@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-07-25drm: track dev_mapping in more robust and flexible wayIlija Hadzic
Setting dev_mapping (pointer to the address_space structure used for memory mappings) to the address_space of the first opener's inode and then failing if other openers come in through a different inode has a few restrictions that are eliminated by this patch. If we already have valid dev_mapping and we spot an opener with different i_node, we force its i_mapping pointer to the already established address_space structure (first opener's inode). This will make all mappings from drm device hang off the same address_space object. Some benefits (things that now work and didn't work before) of this patch are: * user space can mknod and use any number of device nodes and they will all work fine as long as the major device number is that of the drm module. * user space can even remove the first opener's device nodes and mknod the new one and the applications and windowing system will still work. * GPU drivers can safely assume that dev->dev_mapping is correct address_space and just blindly copy it into their (private) bdev.dev_mapping For reference, some discussion that lead to this patch can be found here: http://lists.freedesktop.org/archives/dri-devel/2012-April/022283.html Signed-off-by: Ilija Hadzic <ihadzic@research.bell-labs.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
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-20Merge tag 'v3.5-rc7' into drm-nextDave Airlie
Merge Linus tree into drm to fixup conflicts in radeon code for further testing before upstream merge. Signed-off-by: Dave Airlie <airlied@redhat.com> Conflicts: drivers/gpu/drm/i915/i915_dma.c drivers/gpu/drm/i915/intel_display.c drivers/gpu/drm/radeon/radeon_gart.c
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: 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>
generated by cgit v1.2.3 (git 2.25.1) at 2024-12-13 03:01:28 +0000