similar to: [PATCH] nouveau: add coherent BO attribute

Add a flag allowing Nouveau to specify that an object should be coherent at allocation time. This is required for some class of objects like fences which are randomly-accessed by both the CPU and GPU. This flag instructs the kernel driver to make sure the object remains coherent even on architectures for which coherency is not guaranteed by the bus. Signed-off-by: Alexandre Courbot <acourbot

Doesn't this require a kernel version that has your other patch? What happens when this runs on an older kernel? Does it get silently ignored, or does it end up erroring out? If it errors out, that's fine. Otherwise some sort of version check should be put in, no? On Fri, Mar 13, 2015 at 2:27 AM, Alexandre Courbot <acourbot at nvidia.com> wrote: > Add a flag allowing Nouveau to

User-space use mappable BOs notably for fences, and expects that a value update by the GPU will be immediatly visible through the user-space mapping. ARM has a property that may prevent this from happening though: memory can be mapped multiple times only if the different mappings share the same caching properties. However all the lowmem memory is already identity-mapped into the kernel with cache

The ffsll function is a lot slower than the __ffs64 built-in which compiles to a single instruction on 64-bit. It's also nice to avoid custom versions of standard functions. Note that __ffs == ffs - 1. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- I wrote a user-space program to test these out and make sure that the functions behaved as expected. The logic in abi16 had to be

Seems to make suspend slightly more reliable on my system. Cc: stable at vger.kernel.org [3.7+] Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c b/drivers/gpu/drm/nouveau/nouveau_drm.c index b6bdc9f..5032c31 100644 --- a/drivers/gpu/drm/nouveau/nouveau_drm.c +++ b/drivers/gpu/drm/nouveau/nouveau_drm.c @@ -464,6

From: Ben Skeggs <bskeggs at redhat.com> Signed-off-by: Ben Skeggs <bskeggs at redhat.com> --- nouveau/abi16.c | 62 ++++++++++++++++++++++++++++++++++++++++++++++++++----- nouveau/nouveau.c | 56 +++++++------------------------------------------ nouveau/private.h | 7 ++----- 3 files changed, 67 insertions(+), 58 deletions(-) diff --git a/nouveau/abi16.c b/nouveau/abi16.c index

This adds some basic debug information about the internal nouveau state. making it slightly easier to determine which bo belongs to which vm address, as long as that program is still running. Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- diff --git a/drivers/gpu/drm/nouveau/core/include/subdev/vm.h b/drivers/gpu/drm/nouveau/core/include/subdev/vm.h index

If there are no channels, chan would never end up being NULL, and so the null pointer check would fail. Solve this by initializing chan to NULL, and iterating over temp instead. Fixes oops when running intel-gpu-tools/tests/kms_flip, which attempts to do some intel ioctl's on a nouveau device. Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> Cc: stable at

abi16->handles is a u64, so make sure to use 1ULL << val when modifying. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- Noticed this when doing the previous patch. I'm not sure whether this affects 64-bit builds or not, didn't care to look at the assembly or check the standard. drivers/gpu/drm/nouveau/nouveau_abi16.c | 4 ++-- 1 file changed, 2 insertions(+), 2

From: Ben Skeggs <bskeggs at redhat.com> This will expose functionality supported by newer kernel interfaces. Current userspace uses the chipset to determine which classes are likely exposed, which generally works pretty well, but isn't as flexible as it could be. Unfortunately, the G98:GF100 video code in Mesa is still relying on the kernel exposing incorrect vdec classes on some

On 23 January 2015 at 08:53, Alexandre Courbot <acourbot at nvidia.com> wrote: > Having a RAM device does not make sense for chips like GK20A which have > no dedicated video memory. The dummy RAM device that we used so far > works as a temporary band-aid, but in the long-term it is desirable for > the driver to be able to work without any kind of VRAM. > > This patch adds a

Commit "drm/nouveau: port all engines to new engine module format" changed IB size calculation to be less wasteful, but didn't take into account already existing off-by-one bugs :). So: - ib_max is the last entry, so we need to +1 when calculating number of free entries - nv50_dma_wait already does +1 (for FIRE_RING), so we don't need another +1 on nouveau_gem_ioctl_pushbuf

Not holding the mutex potentially causes corruption of the kernel channel when page flipping. Cc: stable at vger.kernel.org #3.13 Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c b/drivers/gpu/drm/nouveau/nouveau_display.c index 29c3efdfc7dd..76e3cf025c10 100644 --- a/drivers/gpu/drm/nouveau/nouveau_display.c

I was getting a order 4 allocation failure from kmalloc when testing some game after a few days uptime with some suspend/resumes. For big allocations vmalloc should be used instead. Also limit size more aggressively to 256 KiB. Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- drivers/gpu/drm/nouveau/nouveau_gem.c | 30 +++++++++++++++++++++++------- 1 file

Hey all, I've just pushed a major rework/rewrite of the Nouveau kernel module to git[1]. Details of the whys and what-nots of the rework are in the various commit messages. At this point don't expect any exciting cool functionality, the work so far is merely a restructure to allow moving forward on a number of fronts in the future. I expect that for a while there will be a *lot* of

From: Ben Skeggs <bskeggs at redhat.com> This commit also modifies the install path of the main libdrm_nouveau header to be under a nouveau/ subdirectory. Signed-off-by: Ben Skeggs <bskeggs at redhat.com> --- include/drm/nouveau_drm.h | 1 + nouveau/Makefile.am | 11 +++- nouveau/libdrm_nouveau.pc.in | 2 +- nouveau/nvif/cl0080.h | 45 ++++++++++++++

We can't copy_*_user while holding reservations, that will (soon even for nouveau) lead to deadlocks. And it breaks the cross-driver contract around dma_resv. Fix this by adding a slowpath for when we need relocations, and by pushing the writeback of the new presumed offsets to the very end. Aside from "it compiles" entirely untested unfortunately. Signed-off-by: Daniel Vetter

Hello, I'm facing issues with a Point of View GT210/218 and nouveau drivers. I'm using ubuntu server with LXDE on top of it... *lshw -c video* output: *-display description: VGA compatible controller product: GT218 [GeForce 210] vendor: NVIDIA Corporation physical id: 0 bus info: pci at 0000:01:00.0 version: a2 width: 64 bits clock:

From: Ben Skeggs <bskeggs at redhat.com> This commit also modifies the install path of the main libdrm_nouveau header to be under a nouveau/ subdirectory. Signed-off-by: Ben Skeggs <bskeggs at redhat.com> --- include/drm/nouveau_drm.h | 1 + nouveau/Makefile.am | 11 +++- nouveau/libdrm_nouveau.pc.in | 2 +- nouveau/nvif/cl0080.h | 45 ++++++++++++++

From: Ben Skeggs <bskeggs at redhat.com> The latter is deprecated, and will not be valid for newer clients. Signed-off-by: Ben Skeggs <bskeggs at redhat.com> --- nouveau/abi16.c | 32 +++++++++++++++----------------- nouveau/nouveau-symbol-check | 1 - nouveau/nouveau.c | 43 +++++++++++++++++++++---------------------- nouveau/nouveau.h | 1 -