v3.18-rc2
drm: fix regression on agp boards

Extends the fix in f2f9a2cbaf019481feefe231f996d3602612fa99 to also
workaround permission issues noticed by people using AGP systems.

Cc: stable@vger.kernel.org # 3.16: f2f9a2c: drm/nouveau: fix regression
Cc: stable@vger.kernel.org # 3.16+
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
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>
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>
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>
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>
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>
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] add gk20a instmem

This is a gazillion times faster, but requires to invalidate the
GPU L2 (probably at a better place than this!)
[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.
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

Problem with this: rungbm.sh will block when trying to save the
resulting image. Other stuff (kmscube, weston, glmark2) works as
expected.