Current 3D driver expects this behaviour. While this could be changed,
there's no compelling reason to reserve more than one subchannel for the
DRM. If we ever need to use an object other then M2MF, we can just
re-bind subchannel 0 as required.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
When hacking the libdrm for improvements, I triggered a kernel crash
related to the fact that the NOUVEAU_NOTIFIEROBJ_ALLOC ioctl calls
nouveau_channel_get with an unchecked channel index.
The patch ensures that the channel index is an unsigned and validates
its value in nouveau_channel_get.
Signed-off-by: Michel Hermier <hermier@frugalware.org>
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
CONFIG_ACPI_VIDEO depends on more than just CONFIG_ACPI, so add those
dependencies to the Kconfig select condition. The case where some
dependencies fail to be satisfied should be handled correctly, because
in that case the ACPI_VIDEO symbols we use are converted into
static-inline stubs.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* 'nouveau/drm-nouveau-next' of ../drm-nouveau-next: (93 commits)
drm/nv50: fix a couple of vm init issues
drm/nv04-nv40: Fix up PCI(E) GART DMA object bus address calculation.
drm/nouveau: kick vram functions out into an "engine"
drm/nouveau: allow gpuobj vinst to be a virtual address when necessary
drm/nv50: tidy up PCIEGART implementation
drm/nv50: enable non-contig vram allocations where requested
drm/nv50: enable 4KiB pages for small vram allocations
drm/nv50: implement global channel address space on new VM code
drm/nv50: implement BAR1/BAR3 management on top of new VM code
drm/nv50: import new vm code
drm/nv50: implement custom vram mm
drm/nouveau: Avoid potential race between nouveau_fence_update() and context takedown.
drm/nouveau: fix use of drm_mm_node in semaphore object
drm/nouveau: wrap calls to ttm_bo_validate()
drm/nouveau: no need to zero dma objects, we fill them completely anyway
drm/nouveau: introduce a util function to wait on reg != val
drm/nouveau: implicitly insert non-DMA objects into RAMHT
drm/nouveau: make fifo.create_context() responsible for mapping control regs
drm/nouveau: Spin for a bit in nouveau_fence_wait() before yielding the CPU.
drm/nouveau: Use WC memory on the AGP GART.
...
Drivers using their own implementation of io_mem_reserve/io_mem_free are
likely to store the tracking information for the map in mem.mm_node, so
it can't be freed while still mapped.
Signed-off-by: Ben Skeggs<bskeggs@redhat.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
this adds a bo create, and fence seq tracking tracepoints.
This is just an initial set to play around with, we should investigate
what others we need would be useful.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Fixes overwriting the first page table entry when testing that the PRAMIN
BAR can be correctly read/written, and adds an additional bar flush after
poking the BAR3 control regs.
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
NVC0 will be able to share some of nv50's paths this way. This also makes
it the card-specific vram code responsible for deciding if a given set
of tile_flags is valid, rather than duplicating the allowed types in
nv50_vram.c and nouveau_gem.c
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
As of this commit, it's guaranteed that if an object is in VRAM that its
GPU virtual address will be constant.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
This is required on nv50 as we need to be able to have more precise control
over physical VRAM allocations to avoid buffer corruption when using
buffers of mixed memory types.
This removes some nasty overallocation/alignment that we were previously
using to "control" this problem.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
At some point in the future, this bo won't necessarily be backed by
a drm_mm_node, so use the start/size fields of the ttm_mem_reg instead.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The regs belong to PFIFO, they're different for pretty much the same
generations we need different PFIFO control for, and NVC0 is going
to be even more different than the rest.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
