Loading nouveau.ko would fail with unknown symbols, if the backlight
class device support is not provided in the kernel. Let's make the
backlight support dependant on the kernel configuration.
This is a bit ugly, the proper way would be to check for the config in
Makefile.kernel whether to build nouveau_backlight.o at all, and if not,
nouveau_drv.h should provide the stubs.
Signed-off-by: Pekka Paalanen <pq@iki.fi>
Several nvidia-based systems don't support backlight control via the
standard ACPI control mechanisms. Instead, it's necessary for the driver
to modify the backlight control registers directly. This patch adds
support for determining whether the registers appear to be in use, and
if so registers a kernel backlight device to control them. The backlight
can then be controlled via existing userspace tools.
Signed-off-by: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
This patch tries to use the available fence count to figure out whether a
given batch can succeed or not (just like the aperture check).
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
(cherry picked from commit 2fa5f28eee)
It is impossible to replace the original semantics of this call purely
in userland, since the fb_id would change.
after discussion with Dr_Jakob
Signed-Off-By: Owain Ainsworth <oga@openbsd.org>
Acked-By: Jakob Bornecrantz <jakob@vmware.com>
Michel caught a case where we might overwrite a success or other return
value with EBUSY, so check the return value before checking for the
timeout condition.
(cherry picked from commit ca37077fb7)
In some cases, vblank interrupts may be disabled or otherwise broken.
The kernel has a 3s timeout builtin to handle these cases, but the X
server's SIGALM for cursor handling may interrupt vblank wait ioctls,
causing libdrm to restart the ioctl, making the kernel's timeout
useless.
This change tracks time across ioctl restarts and returns EBUSY to the
caller if the expected vblank sequence doesn't occur within 1s of the
first call.
Fixes fdo bz #18041, which is caused by a drmWaitVBlank hanging due to
the corresponding pipe getting disabled (thus preventing further events
from coming in).
Remember tiling mode values provided by appplications, and
record tiling mode when creating a buffer from another application. This
eliminates any need to ask the kernel for tiling values and also makes
reused buffers get the right tiling.
Signed-off-by: Keith Packard <keithp@keithp.com>
(cherry picked from commit 18f091d136)
Applications may actually care if the mapping operation failed, so when
it happens, return an error indication. errno is probably trashed by
fprintf though.
Signed-off-by: Keith Packard <keithp@keithp.com>
(cherry picked from commit bd14b2cf75)
The execbuffer ioctl returns ENOMEM when it fails to pin all of the buffers
in the GTT. This is usually caused by the DRM client attempting to use too
much memory in a single request. Dumping out the requested and available
memory values should help point out failures in the DRM code to catch over
commitments of this form.
Signed-off-by: Keith Packard <keithp@keithp.com>
(cherry picked from commit b13f4e1a32)
NVIDIA do this fun little sequence after updating the PRAMIN page tables.
On 9xxx chips, none of the PRAMIN BAR bindings (except the initial one)
worked, hence the majority of the setup needed to create a channel
ended up in the wrong place, causing all sorts of fun.
This is done by NVIDIA on nv8x chips also, so we'll do it for them too,
even though they appear to work without it.
I'm not 100% sure that the nv94 one we were using won't work. The context
layouts are identical (well.. same ctxprog, so of course!), only a couple
of registers differ. But, be safe until we actually get some 9xxx chips
working.
Our PFIFO/PGRAPH context save/load functions don't really work well
(at all?) on nv5x yet. Depending on what random state the card is
in before the drm loads, fbcon probably won't work correctly.
Luckily we've setup the GPU in such a way that it'll actually do a
hw context switch for the first context. Not sure of how successful
this'd be currently on the older chips (actually, pretty sure it won't
work), so NV50 only for now.
