drm: warn when moving a pinned object

Pinned BOs are supposed to remain in their current location until
unpinned. Display a warning for the supposedly-erroneous case where we
are trying to move such objects.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
drm: introduce nv_device_is_cpu_coherent()

Add a function allowing us to know whether a device is CPU-coherent,
i.e. accesses performed by the CPU on GPU-mapped buffers will
be immediately visible on the GPU side and vice-versa.

For now, a device is considered to be coherent if it uses the PCI bus on
a non-ARM architecture.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
drm: implement explicitly coherent BOs

Allow nouveau_bo_new() to recognize the TTM_PL_FLAG_UNCACHED flag, which
means that we want the allocated BO to be perfectly coherent between the
CPU and GPU. This is useful on non-coherent architectures for which we
do not want to manually sync some rarely-accessed buffers: typically,
fences and pushbuffers.

A TTM BO allocated with the TTM_PL_FLAG_UNCACHED on a non-coherent
architecture will be populated using the DMA API, and accesses to it
performed using the coherent mapping performed by dma_alloc_coherent().

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
drm: allocate GPFIFOs and fences coherently

Specify TTM_PL_FLAG_UNCACHED when allocating GPFIFOs and fences to
allow them to be safely accessed by the kernel without being synced
on non-coherent architectures.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
drm: synchronize BOs when required

On architectures for which access to GPU memory is non-coherent,
caches need to be flushed and invalidated explicitly when BO control
changes between CPU and GPU.

This patch adds buffer synchronization functions which invokes the
correct API (PCI or DMA) to ensure synchronization is effective.

Based on the TTM DMA cache helper patches by Lucas Stach.

Signed-off-by: Lucas Stach <dev@lynxeye.de>
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
drm: fix pin refcnt leak in failure path

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
kms/nv50: remove a couple of cursor-related stub functions

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
kms/nv50: use sclass() instead of trial-and-error

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
kms/nv50-: add some evo tracing ability for debugging

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
drm: we need pin_refcnt for nouveau_bo_placement_set()

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
graph/nvc0: add support for netlist firmwares

NVIDIA is releasing some GPU firmwares for the Tegra SoCs under
linux-firmware. The release format is a single file (called a netlist)
containing all the firmwares relevant to a GPU, which must thus be
extracted. This patch adds support for parsing the netlist and loading
the firmwares for the NVC0 family of GPUs, falling back to the previous
firmware lookup method is no netlist was already loaded.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
platform: support for netlist firmwares

Netlists released by NVIDIA are made of a single file containing
firmwares that can potentially be used across different engines. It
therefore makes most sense to load a netlist once before engines are
probed and have them duplicate their firmwares so the netlist can
be freed at the end of probe.

This patch implements this mechanism and adds the lookup data for GK20A.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
[HACK] create dumb objects in GART
[HACK] warn when allocating VRAM object

We should never allocate VRAM objects from user-space on GK20A.
Warn when such an attempt happens.
[HACK] add gk20a instmem

This is a gazillion times faster, but requires to invalidate the
GPU L2 (probably at a better place than this!)
doc
Use mm_nodes
gk20a: use IOMMU and 1:1 mapping for instmem

Create a 1:1 mapping for each memory block allocated by the gk20a VRAM
allocator, and create mappings in the GPU VA space that use the SMMU.

We are unfortunately forced to use 1:1 mappings here, because some of
these addresses are directly written to registers (i.e. addresses
without going through the GPU VA space) and it seems that such accesses
also bypass the SMMU. So we cannot use SMMU for e.g. PDEs (PTEs look
fine though) and runlists.
[HACK] always use IOMMU for VRAM allocations
[DEBUG] Add channel dumping functions for NVEA