drm_wait_vblank must be DRM_UNLOCKED because otherwise it
will grab the drm_global_mutex and then go to sleep until the vblank
event it is waiting for. That can wreck havoc in the windowing system
because if one process issues this ioctl, it will block all other
processes for the duration of all vblanks between the current and the
one it is waiting for. In some cases it can block the entire windowing
system.
v2: incorporate comments received from Daniel Vetter and
Michel Daenzer.
v3/v4: after a lengty discussion with Daniel Vetter, it was concluded
that the only thing not yet protected with locks and atomic
ops is the write to dev->last_vblank_wait. It's only used in a
debug file in proc, and the current code already employs no
correct locking: the proc file only takes dev->struct_mutex,
whereas drm_wait_vblank implicitly took the drm_global_mutex.
Given all this, it's not worth bothering to try to fix
the locks at this time.
Signed-off-by: Ilija Hadzic <ihadzic@research.bell-labs.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
We restore the CRTC, encoder, and connector configurations, but if the
mode set failed, the attached display may have been turned off, so we
need to try set_config again to restore things to the way they were.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Can happen when there is no DP panel attached, confusing
users. Make it debug only.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
slow-work got killed in commit 181a51f6e0. This means that since v2.6.36
there is no Kconfig symbol SLOW_WORK. Apparently selecting that symbol
is a nop. Drop that select.
Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Nouveau, when configured with debugfs, creates debugfs files for every
channel, so structure holding list of files needs to be protected from
simultaneous changes by multiple threads.
Without this patch it's possible to hit kernel oops in
drm_debugfs_remove_files just by running a couple of xterms with
looped glxinfo.
Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This hunk seems to have gotten lost when I rebased the patch.
Reported-by: Sylvain Bertrand <sylvain.bertrand@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This was only the case if the GPU reset was triggered from the CS ioctl,
otherwise other processes could happily enter the CS ioctl and wreak havoc
during the GPU reset.
This is a little complicated because the GPU reset can be triggered from the
CS ioctl, in which case we're already holding the mutex, or from other call
paths, in which case we need to lock the mutex. AFAICT the mutex API doesn't
allow recursive locking or finding out the mutex owner, so we need to handle
this with helper functions which allow recursive locking from the same
process.
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Snooping code expects this to be the case.
Signed-off-by: Jakob Bornecrantz <jakob@vmware.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Jakob Bornecrantz <jakob@vmware.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Jakob Bornecrantz <jakob@vmware.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
I've been seeing memory leaks on my system in the form of large
(300-400MB) GEM objects created by now-dead processes laying around
clogging up memory. I usually notice when it gets to about 1.2GB of
them. Hopefully this clears up the issue, but I just found this bug
by inspection.
Signed-off-by: Eric Anholt <eric@anholt.net>
Cc: stable@kernel.org
Signed-off-by: Keith Packard <keithp@keithp.com>
* 'drm-fixes' of git://people.freedesktop.org/~airlied/linux: (40 commits)
vmwgfx: Snoop DMA transfers with non-covering sizes
vmwgfx: Move the prefered mode first in the list
vmwgfx: Unreference surface on cursor error path
vmwgfx: Free prefered mode on error path
vmwgfx: Use pointer return error codes
vmwgfx: Fix hw cursor position
vmwgfx: Infrastructure for explicit placement
vmwgfx: Make the preferred autofit mode have a 60Hz vrefresh
vmwgfx: Remove screen object active list
vmwgfx: Screen object cleanups
drm/radeon/kms: consolidate GART code, fix segfault after GPU lockup V2
drm/radeon/kms: don't poll forever if MC GDDR link training fails
drm/radeon/kms: fix DP setup on TRAVIS bridges
drm/radeon/kms: set HPD polarity in hpd_init()
drm/radeon/kms: add MSI module parameter
drm/radeon/kms: Add MSI quirk for Dell RS690
drm/radeon/kms: Add MSI quirk for HP RS690
drm/radeon/kms: split MSI check into a separate function
vmwgfx: Reinstate the update_layout ioctl
drm/radeon/kms: always do extended edid probe
...
Enough to get cursors working under Wayland.
Signed-off-by: Jakob Bornecrantz <jakob@vmware.com>
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Jakob Bornecrantz <jakob@vmware.com>
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Jakob Bornecrantz <jakob@vmware.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Jakob Bornecrantz <jakob@vmware.com>
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Jakob Bornecrantz <jakob@vmware.com>
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Make it possible to use explicit placement
(although not hooked up with a user-space interface yet)
and relax the single framebuffer limit to only apply to implicit placement.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
It isn't used for anything. Replace with an active bool.
Also make a couple of functions return void instead of int
since their return value wasn't checked anyway.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Jakbo Bornecrantz <jakob@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Remove unused member.
No need to pin / unpin fb.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
After GPU lockup VRAM gart table is unpinned and thus its pointer
becomes unvalid. This patch move the unpin code to a common helper
function and set pointer to NULL so that page update code can check
if it should update GPU page table or not. That way bo still bound
to GART can be unbound (pci_unmap_page for all there page) properly
while there is no need to update the GPU page table.
V2 move the test for null gart out of the loop, small optimization
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Supposedly both NUTMEG and TRAVIS should use the same
panel mode, but switching the panel mode for TRAVIS
gets things working.
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=41569
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Polarity needs to be set accordingly to connector status (connected
or disconnected). Set it up in hpd_init() so first hotplug works
reliably no matter what is the initial set of connector. hpd_init()
also covers resume so HPD will work correctly after resume as well.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: Jerome Glisse <j.glisse@gmail.com>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
Allow the user to override whether MSIs are enabled
or not on supported ASICs. MSIs are disabled by default
on IGP chips as they tend not to work. However certain
IGP chips only seem to work with MSIs enabled.
I suspect this is a chipset or bios issue, but I'm not sure
what the proper fix is. This will at least make diagnosing
and working around the problem much easier.
See:
https://bugs.freedesktop.org/show_bug.cgi?id=37679
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
This makes it easier to add quirks for certain systems.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
We need to redefine a connector as "connected" if it matches a window
in the host preferred GUI layout.
Otherwise "smart" window managers would turn on Xorg outputs that we don't
want to be on.
This reinstates the update_layout and adds the following information to
the modesetting system.
a) Connection status <-> Equivalent to real hardware connection status
b) Preferred mode <-> Equivalent to real hardware reading EDID
c) Host window position <-> Equivalent to a real hardware scanout address
dynamic register.
It should be noted that there is no assumption here about what should be
displayed and where. Only how to access the host windows.
This also bumps minor to signal availability of the new IOCTL.
Based on code originally written by Jakob Bornecrantz
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Rather than having a quirk list just always check the EDID header
when probing. This is the recommended behavior according to the
display team. This avoids problems with improperly terminated
i2c lines on some boards. This is also what the proprietary
driver does.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The function didn't work with DP, eDP, or DP bridge
connectors and thus confused users as it lead them to
believe nothing was connected or the EDID was invalid
when in fact is was, just on the aux bus rather an i2c.
It should also speed up module loading as it avoids a
bunch of extra DDC probing.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Use the table version to determine which params to use.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
set up the params based on the table version number.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Leave the common code in radeon_encoders.c and move the atom
specific code to atombios_encoders.c. This matches legacy
encoder setup and crtc setup.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The vram scratch was originally only used on some 7xx asics
to work around a hw bug. Allocate the scratch page on all 6xx+
radeons and set the MC_VM_SYSTEM_APERTURE_DEFAULT_ADDR to point
to it. We shouldn't ever hit it since we limit the system
aperture to vram or vram and AGP, but better safe than sorry.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
DP MST is DP multi-stream support, part of DP 1.2.
v2: switch to a helper macro as suggested by Michel.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The existing function was getting too big and complex.
Break it down into a more manageable set of functions.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Return the encoder id rather than a boolean. This is needed
for differentiate between multiple DP bridge chips.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
radeon_driver_irq_preinstall_kms and radeon_driver_irq_uninstall_kms
hard code the loop to 6 which happens to be the current maximum
number of crtcs and hpd pins; if one day an ASIC with more crtcs
(or hpd pins) comes out, this is a trouble waiting to happen.
introduce constants for maximum CRTC count, maximum HPD pins count
and maximum HDMI blocks count (per FIXME in radeon_irq structure)
and correct the loops in radeon_driver_irq_preinstall_kms and
radeon_driver_irq_uninstall_kms
v2: take care of goofs pointed out by Alex Deucher
Signed-off-by: Ilija Hadzic <ihadzic@research.bell-labs.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Polarity needs to be set accordingly to connector status (connected
or disconnected). Set it up at module init so first hotplug works
reliably no matter what is the initial set of connector.
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
This should make eDP more reliable.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
CP_COHER_CNTL2 has to be programmed manually when submitting packets
to the ring directly rather than programmed via an IB.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Move the TC flush before the texture setup to match mesa and
the ddx. Also, move the TC flush into the texture setup
function.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
