sfrench/cifs-2.6.git
2 years agodrm/nouveau: Move irq setup/teardown to pci ctor/dtor
Lyude Paul [Thu, 25 Jan 2018 23:29:53 +0000 (18:29 -0500)]
drm/nouveau: Move irq setup/teardown to pci ctor/dtor

For a while we've been having issues with seemingly random interrupts
coming from nvidia cards when resuming them. Originally the fix for this
was thought to be just re-arming the MSI interrupt registers right after
re-allocating our IRQs, however it seems a lot of what we do is both
wrong and not even nessecary.

This was made apparent by what appeared to be a regression in the
mainline kernel that started introducing suspend/resume issues for
nouveau:

        a0c9259dc4e1 (irq/matrix: Spread interrupts on allocation)

After this commit was introduced, we started getting interrupts from the
GPU before we actually re-allocated our own IRQ (see references below)
and assigned the IRQ handler. Investigating this turned out that the
problem was not with the commit, but the fact that nouveau even
free/allocates it's irqs before and after suspend/resume.

For starters: drivers in the linux kernel haven't had to handle
freeing/re-allocating their IRQs during suspend/resume cycles for quite
a while now. Nouveau seems to be one of the few drivers left that still
does this, despite the fact there's no reason we actually need to since
disabling interrupts from the device side should be enough, as the
kernel is already smart enough to know to disable host-side interrupts
for us before going into suspend. Since we were tearing down our IRQs by
hand however, that means there was a short period during resume where
interrupts could be received before we re-allocated our IRQ which would
lead to us getting an unhandled IRQ. Since we never handle said IRQ and
re-arm the interrupt registers, this would cause us to miss all of the
interrupts from the GPU and cause our init process to start timing out
on anything requiring interrupts.

So, since this whole setup/teardown every suspend/resume cycle is
useless anyway, move irq setup/teardown into the pci subdev's ctor/dtor
functions instead so they're only called at driver load and driver
unload. This should fix most of the issues with pending interrupts on
resume, along with getting suspend/resume for nouveau to work again.

As well, this probably means we can also just remove the msi rearm call
inside nvkm_pci_init(). But since our main focus here is to fix
suspend/resume before 4.15, we'll save that for a later patch.

Signed-off-by: Lyude Paul <lyude@redhat.com>
Cc: Karol Herbst <kherbst@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Mike Galbraith <efault@gmx.de>
Cc: stable@vger.kernel.org
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2 years agodrm/nouveau/mmu/mcp77: fix regressions in stolen memory handling
Ben Skeggs [Fri, 19 Jan 2018 00:34:56 +0000 (10:34 +1000)]
drm/nouveau/mmu/mcp77: fix regressions in stolen memory handling

- Fixes addition of stolen memory base address to PTEs.
- Removes support for compression.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Tested-by: Pierre Moreau <pierre.morrow@free.fr>
2 years agodrm/nouveau/bar/gk20a: Avoid bar teardown during init
Jon Hunter [Thu, 4 Jan 2018 11:29:09 +0000 (11:29 +0000)]
drm/nouveau/bar/gk20a: Avoid bar teardown during init

Commit bbb163e18960 ("drm/nouveau/bar: implement bar1 teardown")
introduced add a teardown helper function for BAR1. During
initialisation of the Nouveau, initially all the teardown helpers are
called once, before calling their init counterparts. For gk20a, after
the BAR1 teardown function is called, the device is hanging during the
initialisation of the FB sub-device. At this point it is unclear why
this is happening and this is still under investigation. However, this
change is preventing Tegra124 devices from booting when Nouveau is
enabled. To allow Tegra124 to boot, remove the teardown helper for
gk20a.

This is based upon a previous patch by Guillaume Tucker but limits
the workaround to only gk20a GPUs.

Fixes: bbb163e18960 ("drm/nouveau/bar: implement bar1 teardown")
Reported-by: Guillaume Tucker <guillaume.tucker@collabora.com>
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2 years agodrm/nouveau/drm/nouveau: Pass the proper arguments to nvif_object_map_handle()
Thierry Reding [Thu, 18 Jan 2018 21:24:12 +0000 (07:24 +1000)]
drm/nouveau/drm/nouveau: Pass the proper arguments to nvif_object_map_handle()

This is obviously wrong in the current code. Make sure to record the
correct size of the arguments and pass the actual arguments to the
nvif_object_map_handle() function.

Suggested-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2 years agodrm/nouveau/disp/gf119: add missing drive vfunc ptr
Rob Clark [Sat, 6 Jan 2018 15:59:41 +0000 (10:59 -0500)]
drm/nouveau/disp/gf119: add missing drive vfunc ptr

Fixes broken dp on GF119:

  Call Trace:
   ? nvkm_dp_train_drive+0x183/0x2c0 [nouveau]
   nvkm_dp_acquire+0x4f3/0xcd0 [nouveau]
   nv50_disp_super_2_2+0x5d/0x470 [nouveau]
   ? nvkm_devinit_pll_set+0xf/0x20 [nouveau]
   gf119_disp_super+0x19c/0x2f0 [nouveau]
   process_one_work+0x193/0x3c0
   worker_thread+0x35/0x3b0
   kthread+0x125/0x140
   ? process_one_work+0x3c0/0x3c0
   ? kthread_park+0x60/0x60
   ret_from_fork+0x25/0x30
  Code:  Bad RIP value.
  RIP:           (null) RSP: ffffb1e243e4bc38
  CR2: 0000000000000000

Fixes: af85389c614a drm/nouveau/disp: shuffle functions around
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103421
Signed-off-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2 years agodrm/nouveau: fix race when adding delayed work items
Ben Skeggs [Fri, 22 Dec 2017 22:54:28 +0000 (08:54 +1000)]
drm/nouveau: fix race when adding delayed work items

kernel.org bz#198221.

Reported-by: Petr Vandrovec <petr@vandrovec.name>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2 years agodrm/nouveau: fix obvious memory leak
Ben Skeggs [Tue, 19 Dec 2017 22:38:46 +0000 (08:38 +1000)]
drm/nouveau: fix obvious memory leak

fdo#104340.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2 years agodrm/nouveau: use alternate memory type for system-memory buffers with kind != 0
Ben Skeggs [Thu, 14 Dec 2017 01:19:27 +0000 (11:19 +1000)]
drm/nouveau: use alternate memory type for system-memory buffers with kind != 0

Fixes bug on Tegra where we'd strip kind information from system memory
(ie. all) buffers, resulting in misrendering.

Behaviour on dGPU should be unchanged.

Reported-by: Thierry Reding <treding@nvidia.com>
Fixes: d7722134b8 ("drm/nouveau: switch over to new memory and vmm interfaces")
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Tested-by: Thierry Reding <treding@nvidia.com>
2 years agodrm/nouveau: avoid GPU page sizes > PAGE_SIZE for buffer objects in host memory
Ben Skeggs [Thu, 7 Dec 2017 05:25:14 +0000 (15:25 +1000)]
drm/nouveau: avoid GPU page sizes > PAGE_SIZE for buffer objects in host memory

While the Tegra (GK20A, GM20B, GP10B) MMUs support large pages in host
memory, we're currently lacking IOMMU support for merging system pages
into large enough chunks to be mapped as such by the GPU.

The core VMM code actually supports automatically determining the best
page size to map with, which is intended for these situations, but for
various complicated reasons the DRM is currently forcing the page size
selection on a per-BO basis.

This should fix breakage reported on Tegra GPUs in the meantime, until
one or both of the above issues are resolved properly.

Reported-by: Mikko Perttunen <cyndis@kapsi.fi>
Fixes: 7dc6a446da7c ("drm/nouveau: improve selection of GPU page size")
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Tested-by: Thierry Reding <treding@nvidia.com>
2 years agodrm/nouveau/mmu/gp10b: use correct implementation
Ben Skeggs [Thu, 7 Dec 2017 05:04:32 +0000 (15:04 +1000)]
drm/nouveau/mmu/gp10b: use correct implementation

Reported-by: Mikko Perttunen <cyndis@kapsi.fi>
Fixes: 6359c98224 ("drm/nouveau/mmu/gp10b: fork from gf100")
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Tested-by: Thierry Reding <treding@nvidia.com>
2 years agodrm/nouveau/pci: do a msi rearm on init
Karol Herbst [Fri, 24 Nov 2017 02:56:26 +0000 (03:56 +0100)]
drm/nouveau/pci: do a msi rearm on init

On my GP107 when I load nouveau after unloading it, for some reason the
GPU stopped sending or the CPU stopped receiving interrupts if MSI was
enabled.

Doing a rearm once before getting any interrupts fixes this.

Signed-off-by: Karol Herbst <kherbst@redhat.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2 years agodrm/nouveau/imem/nv50: fix refcount_t warning
Ben Skeggs [Thu, 7 Dec 2017 01:08:52 +0000 (11:08 +1000)]
drm/nouveau/imem/nv50: fix refcount_t warning

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2 years agodrm/nouveau/bios/dp: support DP Info Table 2.0
Ben Skeggs [Thu, 7 Dec 2017 00:49:35 +0000 (10:49 +1000)]
drm/nouveau/bios/dp: support DP Info Table 2.0

Reported-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2 years agodrm/nouveau/fbcon: fix NULL pointer access in nouveau_fbcon_destroy
Karol Herbst [Mon, 6 Nov 2017 15:20:33 +0000 (16:20 +0100)]
drm/nouveau/fbcon: fix NULL pointer access in nouveau_fbcon_destroy

When the fbcon object is initialized, but nouveau_fbcon_create is not
called, we run into a NULL pointer access within nouveau_fbcon_create when
unloading nouveau.

The call to drm_fb_helper_funcs.fb_probe is deferred until there is a
display for real since 4.14, that's why fbcon->helper.fb is still not set.

Signed-off-by: Karol Herbst <kherbst@redhat.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2 years agodrm/nouveau/bios/timing: mark expected switch fall-throughs
Gustavo A. R. Silva [Thu, 2 Nov 2017 20:20:33 +0000 (15:20 -0500)]
drm/nouveau/bios/timing: mark expected switch fall-throughs

In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.

Addresses-Coverity-ID: 1260018
Addresses-Coverity-ID: 1260019
Addresses-Coverity-ID: 1260022
Signed-off-by: Gustavo A. R. Silva <garsilva@embeddedor.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2 years agodrm/nouveau/devinit/nv04: mark expected switch fall-throughs
Gustavo A. R. Silva [Thu, 2 Nov 2017 20:06:25 +0000 (15:06 -0500)]
drm/nouveau/devinit/nv04: mark expected switch fall-throughs

In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.

Addresses-Coverity-ID: 143119
Addresses-Coverity-ID: 143120
Addresses-Coverity-ID: 143121
Addresses-Coverity-ID: 143122
Addresses-Coverity-ID: 143123
Addresses-Coverity-ID: 143124
Signed-off-by: Gustavo A. R. Silva <garsilva@embeddedor.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2 years agodrm/nouveau/bios: make const arrays hwsq_signature and edid_sig static
Colin Ian King [Thu, 2 Nov 2017 18:48:12 +0000 (18:48 +0000)]
drm/nouveau/bios: make const arrays hwsq_signature and edid_sig static

Don't populate arrays hwsq_signature and edid_sig on the stack but
instead make them static. Makes the object code smaller by over 190
bytes:

Before:
   text    data     bss     dec     hex filename
  35676    3312      64   39052    988c nouveau_bios.o

After:
   text    data     bss     dec     hex filename
  35319    3472      64   38855    97c7 nouveau_bios.o

(gcc version 7.2.0 x86_64)

Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2 years agodrm/nouveau/core/memory: fix missing mutex unlock
Ben Skeggs [Thu, 2 Nov 2017 22:37:27 +0000 (08:37 +1000)]
drm/nouveau/core/memory: fix missing mutex unlock

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2 years agodrm/nouveau/mmu: swap out round for ALIGN
Ben Skeggs [Thu, 2 Nov 2017 22:36:25 +0000 (08:36 +1000)]
drm/nouveau/mmu: swap out round for ALIGN

Rounding value is guaranteed to be power-of-two, so this is better
anyway.

Fixes build on 32-bit.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2 years agodrm/nouveau/gr/gf100-: don't prevent module load if firmware missing
Ben Skeggs [Tue, 31 Oct 2017 17:56:20 +0000 (03:56 +1000)]
drm/nouveau/gr/gf100-: don't prevent module load if firmware missing

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2 years agodrm/nouveau/mmu: remove old vmm frontend
Ben Skeggs [Tue, 31 Oct 2017 17:56:20 +0000 (03:56 +1000)]
drm/nouveau/mmu: remove old vmm frontend

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2 years agodrm/nouveau: improve selection of GPU page size
Ben Skeggs [Tue, 31 Oct 2017 17:56:20 +0000 (03:56 +1000)]
drm/nouveau: improve selection of GPU page size

Enables the use of Pascal's 2MiB pages for larger buffers.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2 years agodrm/nouveau: switch over to new memory and vmm interfaces
Ben Skeggs [Tue, 31 Oct 2017 17:56:20 +0000 (03:56 +1000)]
drm/nouveau: switch over to new memory and vmm interfaces

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2 years agodrm/nouveau: remove unused nouveau_fence_work()
Ben Skeggs [Tue, 31 Oct 2017 17:56:20 +0000 (03:56 +1000)]
drm/nouveau: remove unused nouveau_fence_work()

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2 years agodrm/nouveau: queue delayed unmapping of VMAs on client workqueue
Ben Skeggs [Tue, 31 Oct 2017 17:56:20 +0000 (03:56 +1000)]
drm/nouveau: queue delayed unmapping of VMAs on client workqueue

VMAs are about to not take references on the VMM they belong to, which
means more care is required when handling delayed unmapping.

Queuing it on the client workqueue ensures all pending VMA unmaps will
have completed before the VMM is destroyed.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2 years agodrm/nouveau: implement per-client delayed workqueue with fence support
Ben Skeggs [Tue, 31 Oct 2017 17:56:20 +0000 (03:56 +1000)]
drm/nouveau: implement per-client delayed workqueue with fence support

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2 years agodrm/nouveau: determine memory class for each client
Ben Skeggs [Tue, 31 Oct 2017 17:56:20 +0000 (03:56 +1000)]
drm/nouveau: determine memory class for each client

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2 years agodrm/nouveau: pass handle of vmm object to channel allocation ioctls
Ben Skeggs [Tue, 31 Oct 2017 17:56:20 +0000 (03:56 +1000)]
drm/nouveau: pass handle of vmm object to channel allocation ioctls

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2 years agodrm/nouveau: switch to vmm limit
Ben Skeggs [Tue, 31 Oct 2017 17:56:20 +0000 (03:56 +1000)]
drm/nouveau: switch to vmm limit

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2 years agodrm/nouveau: allocate vmm object for every client
Ben Skeggs [Tue, 31 Oct 2017 17:56:20 +0000 (03:56 +1000)]
drm/nouveau: allocate vmm object for every client

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2 years agodrm/nouveau: replace use of cpu_coherent with memory types
Ben Skeggs [Tue, 31 Oct 2017 17:56:20 +0000 (03:56 +1000)]
drm/nouveau: replace use of cpu_coherent with memory types

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2 years agodrm/nouveau: use nvif_mmu_type to determine BAR1 caching
Ben Skeggs [Tue, 31 Oct 2017 17:56:20 +0000 (03:56 +1000)]
drm/nouveau: use nvif_mmu_type to determine BAR1 caching

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2 years agodrm/nouveau: fetch memory type indices that we care about for ttm
Ben Skeggs [Tue, 31 Oct 2017 17:56:20 +0000 (03:56 +1000)]
drm/nouveau: fetch memory type indices that we care about for ttm

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2 years agodrm/nouveau: consolidate handling of dma mask
Ben Skeggs [Tue, 31 Oct 2017 17:56:19 +0000 (03:56 +1000)]
drm/nouveau: consolidate handling of dma mask

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2 years agodrm/nouveau: check kind validity against mmu object
Ben Skeggs [Tue, 31 Oct 2017 17:56:19 +0000 (03:56 +1000)]
drm/nouveau: check kind validity against mmu object

This is already handled in the top-level gem_new() ioctl in another manner,
but this will be removed in a future commit.

Ideally we'd not need to check up-front at all, and let the VMM code handle
error checking, but there are paths in the current BO management code where
this isn't possible due to map() not always being called during BO creation,
and map() calls not being allowed to fail during buffer migration.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2 years agodrm/nouveau: allocate mmu object for every client
Ben Skeggs [Tue, 31 Oct 2017 17:56:19 +0000 (03:56 +1000)]
drm/nouveau: allocate mmu object for every client

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2 years agodrm/nouveau: remove trivial cases of nvxx_device() usage
Ben Skeggs [Tue, 31 Oct 2017 17:56:19 +0000 (03:56 +1000)]
drm/nouveau: remove trivial cases of nvxx_device() usage

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2 years agodrm/nouveau/mmu: define user interfaces to mmu vmm opertaions
Ben Skeggs [Tue, 31 Oct 2017 17:56:19 +0000 (03:56 +1000)]
drm/nouveau/mmu: define user interfaces to mmu vmm opertaions

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2 years agodrm/nouveau/mmu: define user interfaces to mmu memory allocation
Ben Skeggs [Tue, 31 Oct 2017 17:56:19 +0000 (03:56 +1000)]
drm/nouveau/mmu: define user interfaces to mmu memory allocation

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2 years agodrm/nouveau/mmu: define user interfaces to mmu
Ben Skeggs [Tue, 31 Oct 2017 17:56:19 +0000 (03:56 +1000)]
drm/nouveau/mmu: define user interfaces to mmu

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2 years agodrm/nouveau/mmu/gf100-: type-based vram allocation and bar mapping
Ben Skeggs [Tue, 31 Oct 2017 17:56:19 +0000 (03:56 +1000)]
drm/nouveau/mmu/gf100-: type-based vram allocation and bar mapping

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2 years agodrm/nouveau/mmu/nv50,g84: type-based vram allocation and bar mapping
Ben Skeggs [Tue, 31 Oct 2017 17:56:19 +0000 (03:56 +1000)]
drm/nouveau/mmu/nv50,g84: type-based vram allocation and bar mapping

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2 years agodrm/nouveau/mmu/nv04-nv4x: type-based vram allocation and bar mapping
Ben Skeggs [Tue, 31 Oct 2017 17:56:19 +0000 (03:56 +1000)]
drm/nouveau/mmu/nv04-nv4x: type-based vram allocation and bar mapping

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2 years agodrm/nouveau/mmu: add base for type-based memory allocation
Ben Skeggs [Tue, 31 Oct 2017 17:56:19 +0000 (03:56 +1000)]
drm/nouveau/mmu: add base for type-based memory allocation

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2 years agodrm/nouveau/mmu: build up information on available memory types
Ben Skeggs [Tue, 31 Oct 2017 17:56:19 +0000 (03:56 +1000)]
drm/nouveau/mmu: build up information on available memory types

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2 years agodrm/nouveau: remove explicit unmaps
Ben Skeggs [Tue, 31 Oct 2017 17:56:19 +0000 (03:56 +1000)]
drm/nouveau: remove explicit unmaps

If the VMA is being deleted, we don't need to explicity unmap first
anymore.  The MMU code will automatically merge the operations into
a single page tree walk.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2 years agodrm/nouveau/gr/gf100-: replace hardcoded instance/vmm setup in grctx generation
Ben Skeggs [Tue, 31 Oct 2017 17:56:19 +0000 (03:56 +1000)]
drm/nouveau/gr/gf100-: replace hardcoded instance/vmm setup in grctx generation

Could be useful for if/when a future GPU removes support for the GF100
PT layout.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2 years agodrm/nouveau/gr/gf100-: use new interfaces for vmm operations
Ben Skeggs [Tue, 31 Oct 2017 17:56:19 +0000 (03:56 +1000)]
drm/nouveau/gr/gf100-: use new interfaces for vmm operations

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2 years agodrm/nouveau/fifo/gf100-: use new interfaces for vmm operations
Ben Skeggs [Tue, 31 Oct 2017 17:56:19 +0000 (03:56 +1000)]
drm/nouveau/fifo/gf100-: use new interfaces for vmm operations

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2 years agodrm/nouveau/secboot/gm200: use new interfaces for vmm operations
Ben Skeggs [Tue, 31 Oct 2017 17:56:19 +0000 (03:56 +1000)]
drm/nouveau/secboot/gm200: use new interfaces for vmm operations

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2 years agodrm/nouveau/imem/nv50-: use new interfaces for vmm operations
Ben Skeggs [Tue, 31 Oct 2017 17:56:19 +0000 (03:56 +1000)]
drm/nouveau/imem/nv50-: use new interfaces for vmm operations

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2 years agodrm/nouveau/fb/ram: use new interfaces for vmm operations
Ben Skeggs [Tue, 31 Oct 2017 17:56:19 +0000 (03:56 +1000)]
drm/nouveau/fb/ram: use new interfaces for vmm operations

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2 years agodrm/nouveau/fifo: initialise vmm with new interfaces
Ben Skeggs [Tue, 31 Oct 2017 17:56:19 +0000 (03:56 +1000)]
drm/nouveau/fifo: initialise vmm with new interfaces

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2 years agodrm/nouveau/secboot/gm200: initialise vmm with new interfaces
Ben Skeggs [Tue, 31 Oct 2017 17:56:19 +0000 (03:56 +1000)]
drm/nouveau/secboot/gm200: initialise vmm with new interfaces

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2 years agodrm/nouveau/bar/gf100: initialise vmm with new interfaces
Ben Skeggs [Tue, 31 Oct 2017 17:56:19 +0000 (03:56 +1000)]
drm/nouveau/bar/gf100: initialise vmm with new interfaces

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2 years agodrm/nouveau/bar/nv50: initialise vmm with new interfaces
Ben Skeggs [Tue, 31 Oct 2017 17:56:19 +0000 (03:56 +1000)]
drm/nouveau/bar/nv50: initialise vmm with new interfaces

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2 years agodrm/nouveau/mmu: implement new vmm frontend
Ben Skeggs [Tue, 31 Oct 2017 17:56:19 +0000 (03:56 +1000)]
drm/nouveau/mmu: implement new vmm frontend

These are the new priviledged interfaces to the VMM backends, and expose
some functionality that wasn't previously available.

It's now possible to allocate a chunk of address-space (even all of it),
without causing page tables to be allocated up-front, and then map into
it at arbitrary locations.  This is the basic primitive used to support
features such as sparse mapping, or to allow userspace control over its
own address-space, or HMM (where the GPU driver isn't in control of the
address-space layout).

Rather than being tied to a subtle combination of memory object and VMA
properties, arguments that control map flags (ro, kind, etc) are passed
explicitly at map time.

The compatibility hacks to implement the old frontend on top of the new
driver backends have been replaced with something similar to implement
the old frontend's interfaces on top of the new frontend.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2 years agodrm/nouveau/mmu: remove support for old backends
Ben Skeggs [Tue, 31 Oct 2017 17:56:19 +0000 (03:56 +1000)]
drm/nouveau/mmu: remove support for old backends

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2 years agodrm/nouveau/mmu/gp100,gp10b: implement new vmm backend
Ben Skeggs [Tue, 31 Oct 2017 17:56:19 +0000 (03:56 +1000)]
drm/nouveau/mmu/gp100,gp10b: implement new vmm backend

Adds support for:
- 64KiB/2MiB big page sizes (128KiB not supported by HW with new PT layout).
- System-memory PTs.
- LPTE "invalid" state.
- (Tegra) Use of video memory aperture.
- Sparse PDEs/PTEs.
- Additional blocklinear kinds.
- 49-bit address-space.

GP100 supports an entirely new 5-level page table layout that provides
an expanded 49-bit address-space.  It also supports the layout present
on previous generations, which we've been making do with until now.

This commit implements support for the new layout, and enables it by
default.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2 years agodrm/nouveau/mmu/gm200,gm20b: implement new vmm backend
Ben Skeggs [Tue, 31 Oct 2017 17:56:19 +0000 (03:56 +1000)]
drm/nouveau/mmu/gm200,gm20b: implement new vmm backend

Adds support for:
- 64KiB big page size.
- System-memory PTs.
- LPTE "invalid" state.
- (Tegra) Use of video memory aperture.
- Sparse PDEs/PTEs.
- Additional blocklinear kinds.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2 years agodrm/nouveau/mmu/gk104,gk20a: implement new vmm backend
Ben Skeggs [Tue, 31 Oct 2017 17:56:19 +0000 (03:56 +1000)]
drm/nouveau/mmu/gk104,gk20a: implement new vmm backend

Adds support for:
- 64KiB big page size.
- System-memory PTs.
- LPTE "invalid" state.
- (Tegra) Use of video memory aperture.

Adds support for marking LPTEs invalid, resulting in the corresponding
SPTEs being ignored, which is supposed to speed up TLB invalidates.

On The Tegra side, this will switch to using the video memory aperture
for all mappings.  The HW will still target non-coherent system memory,
but this aperture needs to be selected in order to support compression.

Tegra's instmem backend somewhat cheated to get this effect previously.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2 years agodrm/nouveau/mmu/gf100: implement new vmm backend
Ben Skeggs [Tue, 31 Oct 2017 17:56:19 +0000 (03:56 +1000)]
drm/nouveau/mmu/gf100: implement new vmm backend

Adds support for:
- 64KiB big page size.
- System-memory PTs.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2 years agodrm/nouveau/mmu/nv50,g84: implement new vmm backend
Ben Skeggs [Tue, 31 Oct 2017 17:56:19 +0000 (03:56 +1000)]
drm/nouveau/mmu/nv50,g84: implement new vmm backend

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2 years agodrm/nouveau/mmu/nv44: implement new vmm backend
Ben Skeggs [Tue, 31 Oct 2017 17:56:19 +0000 (03:56 +1000)]
drm/nouveau/mmu/nv44: implement new vmm backend

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2 years agodrm/nouveau/mmu/nv41: implement new vmm backend
Ben Skeggs [Tue, 31 Oct 2017 17:56:19 +0000 (03:56 +1000)]
drm/nouveau/mmu/nv41: implement new vmm backend

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2 years agodrm/nouveau/mmu/nv04: implement new vmm backend
Ben Skeggs [Tue, 31 Oct 2017 17:56:19 +0000 (03:56 +1000)]
drm/nouveau/mmu/nv04: implement new vmm backend

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2 years agodrm/nouveau/mmu: implement new vmm backend
Ben Skeggs [Tue, 31 Oct 2017 17:56:19 +0000 (03:56 +1000)]
drm/nouveau/mmu: implement new vmm backend

This is the common code to support a rework of the VMM backends.

It adds support for more than 2 levels of page table nesting, which
is required to be able to support GP100's MMU layout.

Sparse mappings (that don't cause MMU faults when accessed) are now
supported, where the backend provides it.

Dual-PT handling had to become more sophisticated to support sparse,
but this also allows us to support an optimisation the MMU provides
on GK104 and newer.

Certain operations can now be combined into a single page tree walk
to avoid some overhead, but also enables optimsations like skipping
PTE unmap writes when the PT will be destroyed anyway.

The old backend has been hacked up to forward requests onto the new
backend, if present, so that it's possible to bisect between issues
in the backend changes vs the upcoming frontend changes.

Until the new frontend has been merged, new backends will leak BAR2
page tables on module unload.  This is expected, and it's not worth
the effort of hacking around this as it doesn't effect runtime.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2 years agodrm/nouveau/fb/gm200: enable NV_PFB_MMU_CTRL_USE_FULL_COMP_TAG_LINE where appropriate
Ben Skeggs [Tue, 31 Oct 2017 17:56:19 +0000 (03:56 +1000)]
drm/nouveau/fb/gm200: enable NV_PFB_MMU_CTRL_USE_FULL_COMP_TAG_LINE where appropriate

To avoid wasting compression tags when using 64KiB pages, we need to
enable this so we can select between upper/lower comptagline in PTEs.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2 years agodrm/nouveau/ltc/gm200: limit NV_MMU_PTE_COMPTAGLINE bits to 16 where required
Ben Skeggs [Tue, 31 Oct 2017 17:56:19 +0000 (03:56 +1000)]
drm/nouveau/ltc/gm200: limit NV_MMU_PTE_COMPTAGLINE bits to 16 where required

If NV_PFB_MMU_CTRL_USE_FULL_COMP_TAG_LINE is TRUE, then the last bit of
NV_MMU_PTE_COMPTAGLINE is re-purposed to select the upper/lower half of
a compression tag when using 64KiB big pages.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2 years agodrm/nouveau/fifo/nv04-nv40: fix missing nvkm_kmap() calls around ramfc access
Ben Skeggs [Tue, 31 Oct 2017 17:56:19 +0000 (03:56 +1000)]
drm/nouveau/fifo/nv04-nv40: fix missing nvkm_kmap() calls around ramfc access

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2 years agodrm/nouveau/mmu: handle instance block setup
Ben Skeggs [Tue, 31 Oct 2017 17:56:19 +0000 (03:56 +1000)]
drm/nouveau/mmu: handle instance block setup

We previously required each VMM user to allocate their own page directory
and fill in the instance block themselves.

It makes more sense to handle this in a common location.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2 years agodrm/nouveau/mmu: remove old vm creation hooks
Ben Skeggs [Tue, 31 Oct 2017 17:56:19 +0000 (03:56 +1000)]
drm/nouveau/mmu: remove old vm creation hooks

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2 years agodrm/nouveau/mmu/gp100,gp10b: implement vmm on top of new base
Ben Skeggs [Tue, 31 Oct 2017 17:56:19 +0000 (03:56 +1000)]
drm/nouveau/mmu/gp100,gp10b: implement vmm on top of new base

Adds support for:
- Selection of old/new-style page table layout (GP100MmuLayout=0/1).
- System-memory PDs.

New layout disabled by default for the moment, as we don't have a
backend that can handle it yet.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2 years agodrm/nouveau/mmu/gm200,gm20b: implement vmm on top of new base
Ben Skeggs [Tue, 31 Oct 2017 17:56:19 +0000 (03:56 +1000)]
drm/nouveau/mmu/gm200,gm20b: implement vmm on top of new base

Adds support for:
- Per-VMM selection of big page size.
- System-memory PDs.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2 years agodrm/nouveau/mmu/gk104,gk20a: implement vmm on top of new base
Ben Skeggs [Tue, 31 Oct 2017 17:56:19 +0000 (03:56 +1000)]
drm/nouveau/mmu/gk104,gk20a: implement vmm on top of new base

Adds support for:
- Selection of a 64KiB big page size (NvFbBigPage=16).
- System-memory PDs.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2 years agodrm/nouveau/mmu/gf100: implement vmm on top of new base
Ben Skeggs [Tue, 31 Oct 2017 17:56:19 +0000 (03:56 +1000)]
drm/nouveau/mmu/gf100: implement vmm on top of new base

Adds support for:
- Selection of a 64KiB big page size (NvFbBigPage=16).
- System-memory PDs.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2 years agodrm/nouveau/mmu/nv50,g84: implement vmm on top of new base
Ben Skeggs [Tue, 31 Oct 2017 17:56:19 +0000 (03:56 +1000)]
drm/nouveau/mmu/nv50,g84: implement vmm on top of new base

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2 years agodrm/nouveau/mmu/nv44: implement vmm on top of new base
Ben Skeggs [Tue, 31 Oct 2017 17:56:19 +0000 (03:56 +1000)]
drm/nouveau/mmu/nv44: implement vmm on top of new base

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2 years agodrm/nouveau/mmu/nv41: implement vmm on top of new base
Ben Skeggs [Tue, 31 Oct 2017 17:56:19 +0000 (03:56 +1000)]
drm/nouveau/mmu/nv41: implement vmm on top of new base

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2 years agodrm/nouveau/mmu/nv04: implement vmm on top of new base
Ben Skeggs [Tue, 31 Oct 2017 17:56:19 +0000 (03:56 +1000)]
drm/nouveau/mmu/nv04: implement vmm on top of new base

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2 years agodrm/nouveau/mmu: implement base for new vm management
Ben Skeggs [Tue, 31 Oct 2017 17:56:19 +0000 (03:56 +1000)]
drm/nouveau/mmu: implement base for new vm management

This is the first chunk of the new VMM code that provides the structures
needed to describe a GPU virtual address-space layout, as well as common
interfaces to handle VMM creation, and connecting instances to a VMM.

The constructor now allocates the PD itself, rather than having the user
handle that manually.  This won't/can't be used until after all backends
have been ported to these interfaces, so a little bit of memory will be
wasted on Fermi and newer for a couple of commits in the series.

Compatibility has been hacked into the old code to allow each GPU backend
to be ported individually.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2 years agodrm/nouveau/mmu: implement page table sub-allocation
Ben Skeggs [Tue, 31 Oct 2017 17:56:19 +0000 (03:56 +1000)]
drm/nouveau/mmu: implement page table sub-allocation

GP100 "big" (which is a funny name, when it supports "even bigger") page
tables are small enough that we want to be able to suballocate them from
a larger block of memory.

This builds on the previous page table cache interfaces so that the VMM
code doesn't need to know the difference.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2 years agodrm/nouveau/mmu: implement page table cache
Ben Skeggs [Tue, 31 Oct 2017 17:56:19 +0000 (03:56 +1000)]
drm/nouveau/mmu: implement page table cache

Builds up and maintains a small cache of each page table size in order
to reduce the frequency of expensive allocations, particularly in the
pathological case where an address range ping-pongs between allocated
and free.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2 years agodrm/nouveau/mmu: automatically handle "un-bootstrapping" of vmm
Ben Skeggs [Tue, 31 Oct 2017 17:56:19 +0000 (03:56 +1000)]
drm/nouveau/mmu: automatically handle "un-bootstrapping" of vmm

Removes the need to expose internals outside of MMU, and GP100 is both
different, and a lot harder to deal with.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2 years agodrm/nouveau/mmu/gp10b: fork from gf100
Ben Skeggs [Tue, 31 Oct 2017 17:56:19 +0000 (03:56 +1000)]
drm/nouveau/mmu/gp10b: fork from gf100

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2 years agodrm/nouveau/mmu/gp100: fork from gf100
Ben Skeggs [Tue, 31 Oct 2017 17:56:19 +0000 (03:56 +1000)]
drm/nouveau/mmu/gp100: fork from gf100

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2 years agodrm/nouveau/mmu/gm20b: fork from gf100
Ben Skeggs [Tue, 31 Oct 2017 17:56:19 +0000 (03:56 +1000)]
drm/nouveau/mmu/gm20b: fork from gf100

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2 years agodrm/nouveau/mmu/gm200: fork from gf100
Ben Skeggs [Tue, 31 Oct 2017 17:56:19 +0000 (03:56 +1000)]
drm/nouveau/mmu/gm200: fork from gf100

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2 years agodrm/nouveau/mmu/gk20a: fork from gf100
Ben Skeggs [Tue, 31 Oct 2017 17:56:19 +0000 (03:56 +1000)]
drm/nouveau/mmu/gk20a: fork from gf100

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2 years agodrm/nouveau/mmu/gk104: fork from gf100
Ben Skeggs [Tue, 31 Oct 2017 17:56:19 +0000 (03:56 +1000)]
drm/nouveau/mmu/gk104: fork from gf100

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2 years agodrm/nouveau/mmu/g84: fork from nv50
Ben Skeggs [Tue, 31 Oct 2017 17:56:19 +0000 (03:56 +1000)]
drm/nouveau/mmu/g84: fork from nv50

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2 years agodrm/nouveau/fb/ram: remove old allocators
Ben Skeggs [Tue, 31 Oct 2017 17:56:19 +0000 (03:56 +1000)]
drm/nouveau/fb/ram: remove old allocators

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2 years agodrm/nouveau: allocate vram with nvkm_ram_get()
Ben Skeggs [Tue, 31 Oct 2017 17:56:19 +0000 (03:56 +1000)]
drm/nouveau: allocate vram with nvkm_ram_get()

This will cause a subtle behaviour change on GPUs that are in mixed-memory
configurations in that VRAM in the degraded section of VRAM will no longer
be used for TTM buffer objects.

That section of VRAM is not meant to be used for displayable/compressed
surfaces, and we have no reliable way with the current interfaces to be
able to make that decision properly.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2 years agodrm/nouveau: directly handle comptag allocation
Ben Skeggs [Tue, 31 Oct 2017 17:56:19 +0000 (03:56 +1000)]
drm/nouveau: directly handle comptag allocation

Another transition step to allow finer-grained patches transitioning to
new MMU backends.

Old backends will continue operate as before (accessing nvkm_mem::tag),
and new backends will get a reference to the tags allocated here.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2 years agodrm/nouveau: wrap nvkm_mem objects in nvkm_memory interfaces
Ben Skeggs [Tue, 31 Oct 2017 17:56:19 +0000 (03:56 +1000)]
drm/nouveau: wrap nvkm_mem objects in nvkm_memory interfaces

This is a transition step, to enable finer-grained commits while
transitioning to new MMU interfaces.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2 years agodrm/nouveau/ltc/gf100-: allocate tagram with nvkm_ram_get()
Ben Skeggs [Tue, 31 Oct 2017 17:56:19 +0000 (03:56 +1000)]
drm/nouveau/ltc/gf100-: allocate tagram with nvkm_ram_get()

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2 years agodrm/nouveau/imem/nv50: allocate memory with nvkm_ram_get()
Ben Skeggs [Tue, 31 Oct 2017 17:56:19 +0000 (03:56 +1000)]
drm/nouveau/imem/nv50: allocate memory with nvkm_ram_get()

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2 years agodrm/nouveau/fb/ram/gt215: allocate training buffer with nvkm_ram_get()
Ben Skeggs [Tue, 31 Oct 2017 17:56:19 +0000 (03:56 +1000)]
drm/nouveau/fb/ram/gt215: allocate training buffer with nvkm_ram_get()

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2 years agodrm/nouveau/fb/ram: add interface to allocate vram as an nvkm_memory object
Ben Skeggs [Tue, 31 Oct 2017 17:56:19 +0000 (03:56 +1000)]
drm/nouveau/fb/ram: add interface to allocate vram as an nvkm_memory object

Upcoming MMU changes use nvkm_memory as its basic representation of memory,
so we need to be able to allocate VRAM like this.

The code is basically identical to the current chipset-specific allocators,
minus support for compression tags (which will be handled elsewhere anyway).

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2 years agodrm/nouveau/core/memory: add some useful accessor macros
Ben Skeggs [Tue, 31 Oct 2017 17:56:19 +0000 (03:56 +1000)]
drm/nouveau/core/memory: add some useful accessor macros

Adds support for 64-bit writes, and optimised filling of buffers with
fixed 32/64-bit values.

These will all be used by the upcoming MMU changes.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>