| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
When I was lock profiling, this was high up on the list and I
see no reason to do it.
|
|
|
|
There is no reason to gratuitously sync these maps to swap.
|
|
|
|
|
|
|
|
Tylo.
Signed-off-by: Pekka Paalanen <pq@iki.fi>
|
|
|
|
|
|
This avoids using the oldest BO in the BO cache and waiting for it to be
idle before we turn around and render to it with the GPU. Thanks to
Chris Wilson for pointing out how silly we were being.
|
|
|
|
|
|
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>
|
|
Signed-off-by: Matthew Garrett <mjg59@srcf.ucam.org>
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 function is unused, and yet creates build problems: the symbol
init_mm is not exported by the latest -rc kernels and I don't believe it
ever will be. Even CONFIG_UNUSED_SYMBOLS does not provide it anymore.
If this function is needed in the future, it needs to be reinvented in
any case. So remove it.
Signed-off-by: Pekka Paalanen <pq@iki.fi>
|
|
Intel developers have stated, that their DRM development continues
elsewhere in some Linux kernel trees. This makes the code in drm.git
just dead weight. This removal allows further cleanup of compatibility
code.
shared-core and bsd-core are left untouched this time.
Signed-off-by: Pekka Paalanen <pq@iki.fi>
Acked-by: Eric Anholt <eric@anholt.net>
|
|
The minor CPU cost here is probably outweighed by bothering us with noise in
the tool.
|
|
|
|
|
|
libdrm isn't supposed to ship APIs not present in a released kernel.
|
|
|
|
nouveau_notifier.c had two places where void* was used in arithmetic,
fixed by using char*.
nouveau_dma_wait(), nouveau_notifier_wait_status() and
nouveau_resource_alloc() had signed/unsigned comparison warnings, fixed
by changing the function parameter into an unsigned type.
Signed-off-by: Pekka Paalanen <pq@iki.fi>
|
|
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.
|
|
It won't work yet, just like the other 9xxx chips. Real soon now :)
|
|
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.
|
|
Suprisingly the card still worked without this...
|
|
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.
|
|
Fixes nouveau_ioctl_mem_free Oops
|
|
|
|
|
|
|
|
Use of the new bits is guarded with a mm_enabled=0 hardcode.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Bug exposed by DDX change d9da090c
|
|
|
|
Bug #19608.
|
|
|
|
|
|
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>
|
|
drm_fops.c reads the current process' EUID directly from task_struct.
Apparently starting in 2.6.28-rc4 this fails to build.
In Linus' tree, commit b6dff3ec5e116e3af6f537d4caedcad6b9e5082a
"CRED: Separate task security context from task_struct"
moves the euid field from task_struct to another struct.
Earlier commit 9e2b2dc4133f65272a6d3c5dcb2ce63f8a87cae9
"CRED: Introduce credential access wrappers" implements the wrapper
macros to access e.g. euid. This is in 2.6.27-rc4, and this contains the
definition of current_euid() that will be used in the DRM compatibility header
for kernels before 2.6.27. That commit also creates <linux/cred.h>, which
contains the upstream definition of current_euid().
drm_fops.c is fixed to use current_euid(), and drm_compat.h will offer
the compatibility definition for kernels <2.6.27.
Signed-off-by: Pekka Paalanen <pq@iki.fi>
|
|
ctxprog seen in okias' trace identical to one we use on NV94, assuming
the initial context values for NV94 will work here too.
|
|
|
