summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)AuthorFilesLines
2012-07-20Revert "Revert "drm/i810: cleanup reclaim_buffers""Daniel Vetter3-11/+13
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-20drm: kill reclaim_buffers_idlelocked functionsDaniel Vetter1-8/+0
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-20drm/sis: clean up reclaim_buffersDaniel Vetter2-4/+12
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-20drm/via: clean up reclaim_buffersDaniel Vetter2-5/+12
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-20drm/udl: port over blanking code from udlfb.Dave Airlie1-7/+37
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-20drm/radeon/kms: auto detect pcie link speed from root portDave Airlie4-3/+35
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-20drm/pci: add support for getting the supported link bw.Dave Airlie1-0/+49
This should work for PCIE3.0 as well. Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-07-20drm/radeon: improve GPU lockup debugging info on r6xx/r7xx/r8xx/r9xxJerome Glisse6-0/+59
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-20drm/mgag200: fix null pointer dereferenceDevendra Naga1-0/+3
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>
2012-07-20drm/radeon: Try harder to avoid HW cursor ending on a multiple of 128 columns.Michel Dänzer1-1/+7
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: Michel Dänzer <michel.daenzer@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-07-20drm: Make the .mode_fixup() operations mode argument a const pointerLaurent Pinchart51-67/+73
The passed mode must not be modified by the operation, make it const. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-07-20drm/fb helper: don't call drm_crtc_helper_set_configDaniel Vetter1-1/+1
Go through the interface vtable instead, because not everyone might be using the crtc helper code. Cc: dri-devel@lists.freedesktop.org Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-07-20drm/fb-helper: delay hotplug handling when partially boundDaniel Vetter1-4/+4
Ok, this requires quite a dance to actually hit: 1) We plug in a 2nd screen, enable it in both X and (by vt-switching) in the fbcon. 2) We disable that screen again in with xrandr. 3) We vt-switch again, so that fbcon displays on the 2nd screen, but X on the first screen. This obviously needs a driver that doesn't switch off unused functions when regaining the VT. 3) When X controls the vt, we unplug that screen. Now drm_fb_helper_hotplug_event we noticed that that some crtcs are bound, but because we still have the fbcon on the 2nd screeen we also have bound set. Which means the fbcon wrongly assumes it's in control of everything an happily disables the output on the 2nd screen, but enables its fb on the first screen. Work around this issue by counting how many crtcs are bound and how many are bound to fbcon and assuming that when fbcon isn't bound to all of them, it better not touch the output configuration. Conceptually this is the same as only restoring the fbcon output configuration on the driver's ->lastclose, when we're sure that no one else is using kms. So this should be consistent with existing kms drivers. Chris has created a separate patch for the intel ddx, but I think we should fix this issue here regardless - the fbcon messing with the output config while it's not fully in control simply isn't a too polite behaviour. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50772 Tested-by: Maxim A. Nikulin <M.A.Nikulin@gmail.com> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-07-18drm/radeon: fix SS setup for DCPLLAlex Deucher1-12/+4
Need to actually set the SS parameters rather than just 0. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com>
2012-07-18drm/radeon: fix up pll selection on DCE5/6Alex Deucher1-1/+5
Selecting ATOM_PPLL_INVALID should be equivalent as the DCPLL or PPLL0 are already programmed for the DISPCLK, but the preferred method is to always specify the PLL selected. SetPixelClock will check the parameters and skip the programming if the PLL is already set up. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com>
2012-07-18drm/radeon: start to document evergreen.cAlex Deucher1-0/+120
Still a lot to do. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com>
2012-07-18drm/radeon: start to document the functions r100.cAlex Deucher1-3/+124
Still a lot more to do. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com>
2012-07-18drm/radeon: document VM functions in radeon_gart.c (v3)Alex Deucher1-0/+142
Document the VM functions in radeon_gart.c v2: adjust per Christian's suggestions v3: adjust to Christians's latest changes Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com>
2012-07-18drm/radeon: document non-VM functions in radeon_gart.c (v2)Alex Deucher1-3/+122
Document the non-VM functions in radeon_gart.c v2: adjust per Christian's suggestions Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com>
2012-07-18drm/radeon: document radeon_ring.c (v4)Alex Deucher1-3/+205
Adds documentation to most of the functions in radeon_ring.c v2: adjust per Christian's suggestions v3: adjust per Christian's latest patches v4: adjust per my latest changes Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com>
2012-07-18drm/radeon: document radeon_fence.c (v2)Alex Deucher1-2/+240
Adds documentation to most of the functions in radeon_fence.c v2: address Christian's comments: - split common concept description into it's own comment - fix description of intr parameter - Improve description of -EDEADLK error Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com>
2012-07-18drm/radeon: document radeon_asic.cAlex Deucher1-0/+46
Adds documentation to most of the functions in radeon_asic.c Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com>
2012-07-18drm/radeon: document radeon_irq_kms.cAlex Deucher1-0/+150
Adds documentation to most of the functions in radeon_irq_kms.c Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com>
2012-07-18drm/radeon: document radeon_kms.cAlex Deucher1-0/+126
Adds documentation to most of the functions in radeon_kms.c Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com>
2012-07-18drm/radeon: document radeon_device.c (v2)Alex Deucher1-3/+310
Adds documentation to most of the functions in radeon_device.c v2: split out general descriptions as per Christian's comments. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com>
2012-07-18drm/radeon: add rptr save support for r1xx-r5xxAlex Deucher1-0/+15
Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com>
2012-07-18drm/radeon: update rptr saving logic for memory buffersAlex Deucher5-9/+67
Add support for using memory buffers rather than scratch registers. Some rings may not be able to write to scratch registers. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com>
2012-07-18drm/radeon: remove radeon_ring_index()Alex Deucher5-45/+27
Just store the index in the ring structure. Idea taken from one of Jerome's wip rptr patches. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com>
2012-07-18drm/radeon: update ib_execute for SI (v2)Alex Deucher2-21/+29
When submitting a CONST_IB, emit a SWITCH_BUFFER packet before the CONST_IB. This isn't strictly necessary (the driver will work fine without it), but is good practice and allows for more flexible DE/CE sychronization options in the future. Current userspace drivers do not take advantage of the CE yet. v2: - clean up code flow a bit - no need to flush caches for CONST IB Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com>
2012-07-18drm/radeon: fix const IB handling v2Christian König5-17/+25
Const IBs are executed on the CE not the CP, so we can't fence them in the normal way. So submit them directly before the IB instead, just as the documentation says. v2: keep the extra documentation Signed-off-by: Christian König <deathsimple@vodafone.de> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
2012-07-18drm/radeon: let sa manager block for fences to wait for v2Christian König2-23/+61
Otherwise we can encounter out of memory situations under extreme load. v2: add documentation for the new function Signed-off-by: Christian König <deathsimple@vodafone.de> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
2012-07-18drm/radeon: return an error if there is nothing to wait forChristian König1-1/+1
Otherwise the sa managers out of memory handling doesn't work. Signed-off-by: Christian König <deathsimple@vodafone.de> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
2012-07-18drm: Disallow DRM_IOCTL_MODESET_CTL for KMS driversLaurent Pinchart1-1/+4
DRM_IOCTL_MODESET_CTL must only be used for UMS drivers. Make it a no-op for KMS drivers. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Michel Dänzer <michel@daenzer.net> Signed-off-by: Dave Airlie <airlied@gmail.com>
2012-07-17Merge branch 'next' of git://people.freedesktop.org/~deathsimple/linux into ↵Dave Airlie23-460/+505
drm-next This merges Christian work that has been hanging around on the list.
2012-07-17drm/radeon: implement ring saving on reset v4Christian König3-8/+126
Try to save whatever is on the rings when we encounter an lockup. v2: Fix spelling error. Free saved ring data if reset fails. Add documentation for the new functions. v3: Some more spelling fixes v4: It doesn't make sense to save anything if all fences are signaled Signed-off-by: Christian König <deathsimple@vodafone.de> Reviewed-by: Michel Dänzer <michel.daenzer@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
2012-07-17drm/radeon: record what is next valid wptr for each ring v4Christian König7-8/+68
Before emitting any indirect buffer, emit the offset of the next valid ring content if any. This allow code that want to resume ring to resume ring right after ib that caused GPU lockup. v2: use scratch registers instead of storing it into memory v3: skip over the surface sync for ni and si as well v4: use SET_CONFIG_REG instead of PACKET0 Signed-off-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Christian König <deathsimple@vodafone.de> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
2012-07-17drm/radeon: move radeon_ib_ring_tests out of chipset codeChristian König14-69/+15
Making it easier to control when it is executed. Signed-off-by: Christian König <deathsimple@vodafone.de> Reviewed-by: Michel Dänzer <michel.daenzer@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
2012-07-17drm/radeon: remove vm_manager start/suspendChristian König4-50/+59
Just restore the page table instead. Addressing three problem with this change: 1. Calling vm_manager_suspend in the suspend path is problematic cause it wants to wait for the VM use to end, which in case of a lockup never happens. 2. In case of a locked up memory controller unbinding the VM seems to make it even more unstable, creating an unrecoverable lockup in the end. 3. If we want to backup/restore the leftover ring content we must not unbind VMs in between. Signed-off-by: Christian König <deathsimple@vodafone.de> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
2012-07-17drm/radeon: remove r600_blit_suspendChristian König8-63/+40
Just reinitialize the shader content on resume instead. Signed-off-by: Christian König <deathsimple@vodafone.de> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
2012-07-17drm/radeon: remove ip_pool start/suspendChristian König16-157/+84
The IB pool is in gart memory, so it is completely superfluous to unpin / repin it on suspend / resume. Signed-off-by: Christian König <deathsimple@vodafone.de> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
2012-07-17drm/radeon: make cp init on cayman more robustChristian König1-77/+56
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>
2012-07-17drm/radeon: remove FIXME comment from chipset suspendChristian König5-5/+0
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 <deathsimple@vodafone.de> Reviewed-by: Jerome Glisse <jglisse@redhat.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
2012-07-17drm/radeon: fix fence init after resumeChristian König1-1/+1
Start with last signaled fence number instead of last emitted one. Signed-off-by: Christian König <deathsimple@vodafone.de> Reviewed-by: Jerome Glisse <jglisse@redhat.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
2012-07-17drm/radeon: fix fence value accessChristian König1-6/+8
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 <deathsimple@vodafone.de> Reviewed-by: Jerome Glisse <jglisse@redhat.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
2012-07-17drm/radeon: fix ring commit paddingChristian König1-6/+1
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: Christian König <deathsimple@vodafone.de> Reviewed-by: Jerome Glisse <jglisse@redhat.com> Reviewed-by: Michel Dänzer <michel.daenzer@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
2012-07-17drm/radeon: add an exclusive lock for GPU reset v2Jerome Glisse4-0/+17
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: Jerome Glisse <jglisse@redhat.com> Reviewed-by: Christian König <christian.koenig@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
2012-07-17drm/radeon: fix fence related segfault in CSChristian König1-1/+1
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 <deathsimple@vodafone.de> Reviewed-by: Jerome Glisse <jglisse@redhat.com> Reviewed-by: Michel Dänzer <michel.daenzer@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2012-07-17drm/radeon: add error handling to radeon_vm_unbind_lockedChristian König1-3/+14
Waiting for a fence can fail for different reasons, the most common is a deadlock. Signed-off-by: Christian König <deathsimple@vodafone.de> Reviewed-by: Michel Dänzer <michel.daenzer@amd.com> Reviewed-by: Jerome Glisse <jglisse@redhat.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
2012-07-17drm/radeon: add error handling to fence_wait_empty_lockedChristian König2-13/+22
Instead of returning the error handle it directly and while at it fix the comments about the ring lock. Signed-off-by: Christian König <deathsimple@vodafone.de> Reviewed-by: Michel Dänzer <michel.daenzer@amd.com> Reviewed-by: Jerome Glisse <jglisse@redhat.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
2012-07-16gma500,cdv: Fix the brightness baseAlan Cox1-16/+19
Some desktop environments carefully save and restore the brightness settings from the previous boot. Unfortunately they don't all check to see if the range has changed. The end result is that they restore a brightness of 100/lots not 100/100. As the old driver and the non-free GMA36xx driver both use 0-100 we thus need to go back doing the same thing to avoid users getting a mysterious black screen after boot. Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
generated by cgit v1.2.3 (git 2.39.0) at 2024-10-17 00:35:52 +0300