- 26 Jul, 2012 10 commits
-
-
Dave Airlie authored
Merge branch 'drm-nouveau-fixes' of 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
-
Marcin Slusarz authored
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>
-
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
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 authored
I want this file for the new interfaces... Signed-off-by: -
Ben Skeggs authored
Reported-by:
Maarten Lankhorst <maarten.lankhorst@canonical.com> Signed-off-by:
-
Marcin Slusarz authored
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 authored
Signed-off-by:
-
Ben Skeggs authored
Signed-off-by: -
Maarten Lankhorst authored
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:
-
- 25 Jul, 2012 7 commits
-
-
Jerome Glisse authored
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>
-
Jerome Glisse authored
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 authored
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 authored
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:
-
Dan Carpenter authored
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:
-
Jerome Glisse authored
Retry label was at wrong place in function leading to memory leak. Cc: <stable@vger.kernel.org> Signed-off-by:
Michel Dänzer <michel.daenzer@amd.com> Reviewed-by:
-
Ilija Hadzic authored
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.htmlSigned-off-by:
Ilija Hadzic <ihadzic@research.bell-labs.com> Signed-off-by:
-
- 24 Jul, 2012 1 commit
-
-
Ilija Hadzic authored
Patch 649bf3ca has completely removed ttm_backend structure. Remove lingering declaration and related (now stale) field in ttm_tt structure, CC: Jerome Glisse <jglisse at redhat.com> Signed-off-by: Ilija Hadzic <ihadzic at research.bell-labs.com> Signed-off-by:
-
- 20 Jul, 2012 22 commits
-
-
Dave Airlie authored
Merge Linus tree into drm to fixup conflicts in radeon code for further testing before upstream merge. Signed-off-by: -
Daniel Vetter authored
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:
-
Daniel Vetter authored
Signed-off-by:
-
Daniel Vetter authored
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 authored
Absolutely unused. All the values are only ever initialized and then used at most in some debug printout functions. Signed-off-by:
-
Daniel Vetter authored
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 authored
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 authored
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:
Tormod Volden <debian.tormod@gmail.com> Signed-off-by:
-
Daniel Vetter authored
i810 was the last user of this code, with that gone, kill it. Signed-off-by:
-
Daniel Vetter authored
This reverts commit 6e877b57, reinstating the original commit: commit 87499ffd 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 authored
The only two users are now folded into the drivers preclose functions, so this is unused. Signed-off-by:
-
Daniel Vetter authored
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 authored
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:
-
Dave Airlie authored
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 authored
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 authored
This should work for PCIE3.0 as well. Signed-off-by: -
Dave Airlie authored
We need these for detecting the max link speed for drm drivers. Acked-by:
Bjorn Helgaas <bhelgass@google.com> Signed-off-by:
-
Jerome Glisse authored
Print various CP register that have valuable informations regarding GPU lockup. Signed-off-by:
-
Devendra Naga authored
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:
-
Michel Dänzer authored
This could previously fail if either of the enabled displays was using a horizontal resolution that is a multiple of 128, and only the leftmost column of the cursor was (supposed to be) visible at the right edge of that display. The solution is to move the cursor one pixel to the left in that case. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=33183 Cc: stable@vger.kernel.org Signed-off-by:
-
Laurent Pinchart authored
The passed mode must not be modified by the operation, make it const. Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by:
-
Daniel Vetter authored
It's unused. At it confused me quite a bit until I've discovered that. Cc: dri-devel@lists.freedesktop.org Signed-off-by:
-
