Only supported on NV50+ so far, and disabled by default currently.  The
module parameter "msi=1" will enable it.

There's a kernel bug which will cause this to fail if the module (or the
NVIDIA binary driver) has ever been loaded before loading nouveau with
MSI enabled.  As such, this is only safe to enable if you have nouveau
load on boot, and don't wish to ever reload it.

The workaround is to "echo 0 > /sys/bus/pci/devices/<device>/enable"
until the enable count reads 0.  Then you should be able to load nouveau
with MSI enabled.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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

Not an issue right now, we're forced to 64k size/alignment by the BO
allocator anyway.  This won't be the case soon.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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

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

This doesn't work yet for unknown reasons.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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

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

This really needs cleaning up somehow, and probably investigate what's
needed to do this on earlier generations.  NVIDIA do something similar
there too.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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

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

We previously added all the available classes for the entire generation,
even though the objects wouldn't work on the hardware.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

The structs themselves, as well as the non-sw object creation function are
probably very misnamed now.  That's a problem for later :)
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

We will eventually want to address hw engines other than PGRAPH.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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

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

Without it there's a potential race with nouveau_fence_update().
Signed-off-by: NFrancisco Jerez <currojerez@riseup.net>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

It needs a "strong" channel reference because it actually writes to
the channel pushbuf, otherwise the corresponding FIFO context could
get kicked off in the middle of nouveau_fence_sync().
Signed-off-by: NFrancisco Jerez <currojerez@riseup.net>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Fences didn't increment the channel reference count, and the fenced
channel could go away at any time. Fixes a potential race in
nouveau_fence_update().
Signed-off-by: NFrancisco Jerez <currojerez@riseup.net>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

nouveau_channel_ref() takes a "weak" channel reference that doesn't
prevent the hardware channel resources from being released, it just
keeps the channel data structure alive.
Signed-off-by: NFrancisco Jerez <currojerez@riseup.net>
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: NFrancisco Jerez <currojerez@riseup.net>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

nouveau_channel_put() can be executed after the 'refcount == 0' check
in nouveau_channel_get() and before the channel reference count is
incremented. In that case CPU0 will take the context down while CPU1
thinks it owns the channel and 'refcount == 1'.
Signed-off-by: NFrancisco Jerez <currojerez@riseup.net>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

The destroy_context() engine hooks call gpuobj management functions to
release the channel resources, these functions use HARDIRQ-unsafe locks
whereas destroy_context() is called with the HARDIRQ-safe
context_switch_lock held, that's a lock ordering violation.

Push the engine-specific channel destruction logic into destroy_context()
and let the hardware-specific code lock and unlock when it's actually
needed. Change the engine destruction order to avoid a race in the small
gap between pgraph and pfifo context uninitialization.
Reported-by: NMarcin Slusarz <marcin.slusarz@gmail.com>
Signed-off-by: NFrancisco Jerez <currojerez@riseup.net>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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

The pushbuf ioctl syncs after validation, no need for this anymore.
Signed-off-by: NFrancisco Jerez <currojerez@riseup.net>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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

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

Not used at all yet, but lets hook it up now anyway.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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

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

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

No other driver uses this, and userspace should be responsible for handling
locking between them if they share BOs.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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

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

This fixes a race condition between fbcon acceleration and TTM buffer
moves.  To reproduce:

- start X
- switch to vt and "while (true); do dmesg; done"
- switch to another vt and "sleep 2 && cat /path/to/debugfs/dri/0/evict_vram"
- switch back to vt running dmesg

We don't make use of this on any other channel yet, they're currently
protected by drm_global_mutex.  This will change in the near future.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

A future commit will add locking to the DRM's channel, and there's numerous
problems that come up if we allow printk from an interrupt context to be
accelerated.  It seems saner to just disallow it completely.

As a nice side-effect, all the "to accel or not to accel" logic gets moved
out of the chipset-specific code.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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

* 'drm-radeon-fusion' of ../drm-radeon-next:
  drm/radeon/kms: add Ontario APU ucode loading support
  drm/radeon/kms: add Ontario Fusion APU pci ids
  drm/radeon/kms: enable MSIs on fusion APUs
  drm/radeon/kms: add power table parsing support for Ontario fusion APUs
  drm/radeon/kms: refactor atombios power state fetching
  drm/radeon/kms: add bo blit support for Ontario fusion APUs
  drm/radeon/kms: add thermal sensor support for fusion APUs
  drm/radeon/kms: fill in GPU init for AMD Ontario Fusion APUs
  drm/radeon/kms: add radeon_asic struct for AMD Ontario fusion APUs
  drm/radeon/kms: evergreen.c updates for fusion
  drm/radeon/kms: MC setup changes for fusion APUs
  drm/radeon/kms: move r7xx/evergreen to its own vram_gtt setup function
  drm/radeon/kms: add support for ss overrides on Fusion APUs
  drm/radeon/kms: Add support for external encoders on fusion APUs
  drm/radeon/kms: atom changes for DCE4.1 devices
  drm/radeon/kms: add new family id for AMD Ontario APUs
  drm/radeon/kms: upstream power table updates
  drm/radeon/kms: upstream atombios.h updates
  drm/radeon/kms: upstream ObjectID.h updates
  drm/radeon/kms: setup mc chremap properly on r7xx/evergreen

* 'drm-radeon-next' of ../drm-radeon-next:
  drm/radeon/kms: improve pflip precision on r1xx-r4xx
  drm/kms/radeon: Use high precision timestamps for pageflip completion events.
  drm/kms/radeon: Reorder vblank and pageflip interrupt handling.
  drm/radeon/kms: add pageflip ioctl support (v3)
  drm/kms/radeon: Add support for precise vblank timestamping.