drm/nouveau/bar: switch to instanced constructor

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>

drm/nouveau/bar/gf100: ensure BAR is mapped

If the BAR is zero size, it indicates it was never successfully mapped.
Ensure that the BAR is valid during initialization before attempting to
use it.

Signed-off-by: Jon Derrick <jonathan.derrick@intel.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/bar/gf100: initialise vmm with new interfaces

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

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>

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>

drm/nouveau/core/memory: add reference counting

We need to be able to prevent memory from being freed while it's still
mapped in a GPU's address-space.

Will be used by upcoming MMU changes.

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

drm/nouveau/bar: initialise bar2 during oneinit

If we initialise BAR2 earlier, we're able to complete BAR1 setup using
the instmem fast-path.

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

drm/nouveau/bar: modify interface to bar2 vmm mapping

Match API with the BAR1 version.

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

drm/nouveau/bar: modify interface to bar1 vmm mapping

Upcoming changes will remove the nvkm_vmm pointer from nvkm_vma, instead
requiring it to be explicitly specified on each operation.

It's not currently possible to get this information for BAR1 mappings,
so let's fix that ahead of time.

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

drm/nouveau/bar: expose interface to bar2 teardown

Will prevent spurious MMU fault interrupts if something decides to touch
BAR1 after we've unloaded the driver.

Exposed external to BAR so that INSTMEM can use it to better control the
suspend/resume fast-path access.

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

drm/nouveau/bar: expose interface to bar2 initialisation

If we want to be able to hit the instmem fast-path in a few trickier cases,
we need to be more flexible with when we can initialise BAR2 access.

There's probably a decent case to be made for merging BAR/INSTMEM into BUS,
but that's something to ponder another day.

Flushes have been added after the write to bind the instance block,
as later commits will reveal the need for them.

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

drm/nouveau/bar: implement bar1 teardown

Will prevent spurious MMU fault interrupts if something decides to touch
BAR1 after we've unloaded the driver.

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

drm/nouveau/bar: move bar1 initialisation into its own function

BAR2 being done for practical reasons, this is just for consistency.

Flushes have been added after the write to bind the instance block,
as later commits will reveal the need for them.

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

drm/nouveau/bar: swap oneinit/init ordering, and rename bar3 to bar2

NVIDIA call it BAR2, Linux APIs treat it as BAR3 due to BAR1 being a
64-bit BAR, which I presume take two slots or something.

No actual code changes here, just to make future commits less messy.

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

drm/nouveau/bar: remove NV_PMC_ENABLE_PFIFO twiddling

It's handled by FIFO preinit() now.

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

drm/nouveau/bar/nv50,g84: drop mmu invalidate

Will already be done by MMU as a result of the PT writes that occur
during BAR2 bootstrapping.

This is likely just a left-over from the days when it was hardcoded.

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

drm/nouveau/bar/gf100: add config option to limit BAR2 to 16MiB

Useful for testing, and for the userspace build where we can't kick
a framebuffer driver off the device.

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

drm/nouveau/bar/gf100: fix access to upper half of BAR2

Bit 30 being set causes the upper half of BAR2 to stay in physical mode,
mapped over the end of VRAM, even when the rest of the BAR has been set
to virtual mode.

We inherited our initial value from RM, but I'm not aware of any reason
we need to keep it that way.

This fixes severe GPU hang/lockup issues revealed by Wayland on F26.

Shout-out to NVIDIA for the quick response with the potential cause!

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Cc: stable@vger.kernel.org # 4.3+

drm/nouveau/device: cleaner abstraction for device resource functions

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

drm/nouveau/core: remove the remainder of the previous style

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

drm/nouveau/bar: convert to new-style nvkm_subdev

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

drm/nouveau/gpuobj: separate allocation from nvkm_object

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

drm/nouveau/bar/gf100: directly use instmem for channel descriptors

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

drm/nouveau/mmu: directly use instmem for page tables

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

drm/nouveau/imem: improve management of instance memory

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

drm/nouveau/mmu: protect each vm with its own mutex

An upcoming commit requires being able to modify the PRAMIN BAR page
tables while already holding the MMU subdev mutex.

To solve this issue, each VM has been given its own mutex. As a nice
side-effect, this also allows separate VMs to be updated concurrently.

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

drm/nouveau/bar: switch to gpuobj accessor macros

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

drm/nouveau/bar: switch to device pri macros

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

drm/nouveau/bar: cosmetic changes

This is purely preparation for upcoming commits, there should be no
code changes here.

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

drm/nouveau/device: include core/device.h automatically for subdevs/engines

Pretty much every subdev/engine is going to need access to nvkm_device
shortly to touch registers and/or output messages.

The odd placement of the includes is necessary to work around some
inter-dependencies that currently exist. This will be fixed later.

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

drm/nouveau/mmu: namespace + nvidia gpu names (no binary change)

The namespace of NVKM is being changed to nvkm_ instead of nouveau_,
which will be used for the DRM part of the driver. This is being
done in order to make it very clear as to what part of the driver a
given symbol belongs to, and as a minor step towards splitting the
DRM driver out to be able to stand on its own (for virt).

Because there's already a large amount of churn here anyway, this is
as good a time as any to also switch to NVIDIA's device and chipset
naming to ease collaboration with them.

A comparison of objdump disassemblies proves no code changes.

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

drm/nouveau/bar: namespace + nvidia gpu names (no binary change)

The namespace of NVKM is being changed to nvkm_ instead of nouveau_,
which will be used for the DRM part of the driver. This is being
done in order to make it very clear as to what part of the driver a
given symbol belongs to, and as a minor step towards splitting the
DRM driver out to be able to stand on its own (for virt).

Because there's already a large amount of churn here anyway, this is
as good a time as any to also switch to NVIDIA's device and chipset
naming to ease collaboration with them.

A comparison of objdump disassemblies proves no code changes.

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