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>
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>
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>
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>
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>
This reverts commit 6e877b576d,
reinstating the original commit:
commit 87499ffdcb
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
It's unused. At it confused me quite a bit until I've discovered that.
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
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>
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>
This contains all the radeon documentation rebased on top of the ib fixes.
* 'next' of git://people.freedesktop.org/~deathsimple/linux:
drm/radeon: fix SS setup for DCPLL
drm/radeon: fix up pll selection on DCE5/6
drm/radeon: start to document evergreen.c
drm/radeon: start to document the functions r100.c
drm/radeon: document VM functions in radeon_gart.c (v3)
drm/radeon: document non-VM functions in radeon_gart.c (v2)
drm/radeon: document radeon_ring.c (v4)
drm/radeon: document radeon_fence.c (v2)
drm/radeon: document radeon_asic.c
drm/radeon: document radeon_irq_kms.c
drm/radeon: document radeon_kms.c
drm/radeon: document radeon_device.c (v2)
drm/radeon: add rptr save support for r1xx-r5xx
drm/radeon: update rptr saving logic for memory buffers
drm/radeon: remove radeon_ring_index()
drm/radeon: update ib_execute for SI (v2)
drm/radeon: fix const IB handling v2
drm/radeon: let sa manager block for fences to wait for v2
drm/radeon: return an error if there is nothing to wait for
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
