VRAM->system is a synchronous operation: it involves scheduling a
VRAM->TT DMA transfer and stalling the CPU until it's finished so that
we can unbind the new memory from the translation tables. VRAM->TT can
always be performed asynchronously, even if TT is already full and we
have to move something out of it.

Additionally, allowing VRAM->system behaves badly under heavy memory
pressure because once we run out of TT, stuff starts to be moved back
and forth between VRAM and system, and the TT contents are hardly
renewed.
Signed-off-by: NFrancisco Jerez <currojerez@riseup.net>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

- In the current situation the padding that is added is dangerous to write
  to, userspace could potentially overwrite parts of another bo.
- Depth and stencil buffers are supposed to be large enough in general so
  the waste of memory should be acceptable.
- Alternatives are hiding the padding from users or splitting vram into 2
  zones.
Signed-off-by: NMaarten Maathuis <madman2003@gmail.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Not an ideal solution, but it'll do for the moment for correctness.  We
need to come up with a nicer way to manage inter-channel sync, the hw
is unfortunately a little lacking in this area.

Should fix some resume corruption, as well as corruption that may be seen
while under memory pressure.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

- This should be better than what we have now.
- I'm less sure about the non power of two path.
Signed-off-by: NMaarten Maathuis <madman2003@gmail.com>

- Aligning to block size should ensure that the extra size is enough.
- Using roundup, because not all sizes are powers of two.
Signed-off-by: NMaarten Maathuis <madman2003@gmail.com>

Signed-off-by: NFrancisco Jerez <currojerez@riseup.net>

Signed-off-by: NFrancisco Jerez <currojerez@riseup.net>

Signed-off-by: NFrancisco Jerez <currojerez@riseup.net>

This commit has also the following 3 bugfix commits squashed into it from
the nouveau git tree:

drm/nouveau: Fix up the tiling alignment restrictions for nv1x.
drm/nouveau: Fix up the nv2x tiling alignment restrictions.
drm/nv50: fix align typo for g9x
Signed-off-by: NFrancisco Jerez <currojerez@riseup.net>

- This should be better than what we have now.
- I'm less sure about the non power of two path.
Signed-off-by: NMaarten Maathuis <madman2003@gmail.com>

- Aligning to block size should ensure that the extra size is enough.
- Using roundup, because not all sizes are powers of two.
Signed-off-by: NMaarten Maathuis <madman2003@gmail.com>

Signed-off-by: NFrancisco Jerez <currojerez@riseup.net>

Signed-off-by: NFrancisco Jerez <currojerez@riseup.net>

Signed-off-by: NFrancisco Jerez <currojerez@riseup.net>

This commit has also the following 3 bugfix commits squashed into it from
the nouveau git tree:

drm/nouveau: Fix up the tiling alignment restrictions for nv1x.
drm/nouveau: Fix up the nv2x tiling alignment restrictions.
drm/nv50: fix align typo for g9x
Signed-off-by: NFrancisco Jerez <currojerez@riseup.net>

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

Previously, if there was no firmware available, the DRM would just
disable channel creation from userspace, but still use a single
channel for its own purposes.

With a bit of care it should actually be possible to do this, due
to the DRM's very limited use of the engine.  It currently doesn't
work correctly however, resulting in corrupted fbcon and hangs on
a number of cards.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NFrancisco Jerez <currojerez@riseup.net>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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

This adds a drm/kms staging non-API stable driver for GPUs from NVIDIA.

This driver is a KMS-based driver and requires a compatible nouveau
userspace libdrm and nouveau X.org driver.

This driver requires firmware files not available in this kernel tree,
interested parties can find them via the nouveau project git archive.

This driver is reverse engineered, and is in no way supported by nVidia.

Support for nearly the complete range of nvidia hw from nv04->g80 (nv50)
is available, and the kms driver should support driving nearly all
output types (displayport is under development still) along with supporting
suspend/resume.

This work is all from the upstream nouveau project found at
nouveau.freedesktop.org.

The original authors list from nouveau git tree is:
Anssi Hannula <anssi.hannula@iki.fi>
Ben Skeggs <bskeggs@redhat.com>
Francisco Jerez <currojerez@riseup.net>
Maarten Maathuis <madman2003@gmail.com>
Marcin Kościelnicki <koriakin@0x04.net>
Matthew Garrett <mjg@redhat.com>
Matt Parnell <mparnell@gmail.com>
Patrice Mandin <patmandin@gmail.com>
Pekka Paalanen <pq@iki.fi>
Xavier Chantry <shiningxc@gmail.com>
along with project founder Stephane Marchesin <marchesin@icps.u-strasbg.fr>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>