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

The ability to use NVIDIA's fuc has been retained *temporarily* in order
to better debug any issues that may be lingering in our initial attempt
at writing this ucode.  Once I'm fairly confident we're okay, it'll be
removed.

There's a number of things not implemented by this fuc currently, but
most of it is sets of state that our context setup would not have used
anyway.  No doubt we'll find out what they're for at some point, and
implement it if required.

This has been tested on 0xc0/0xc4 thus far, and from what I could tell
it worked as well as NVIDIA's.  It's also been tested on 0xc1, but even
with NVIDIA's fuc that chipset doesn't work correctly with nouveau yet.

0xc3/0xc8/0xce should in theory be supported too, but I don't have the
hardware to check that.

There's no doubt numerous bugs to squash yet, please report any!
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

We need the physical VRAM address in vinst, even for objects mapped into
a vm, as the gpuobj suspend/resume code uses PMEM to access the object.

Previously, vinst was overloaded to mean "VRAM address" for !VM objects,
and "VM address" for VM objects, causing the wrong data to be accessed
during suspend/resume.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Until we know these should work properly, would much rather default to
noaccel than risk giving people corruption/hangs out of the box..
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

The core/mem/shader clocks don't support the fractional feedback divider,
causing our calculated clocks to be off by quite a lot in some cases.  To
solve this we will switch to a search-based algorithm when fN is NULL.

For my NVA8 at PL3, this actually generates identical cooefficients to
the binary driver.  Hopefully that's a good sign, and that does not
break VPLL calculation for someone..
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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

v2 (Ben Skeggs): fix ramcfg strap, and remove bogus handling of perf 0x40
Signed-off-by: NMartin Peres <martin.peres@ensi-bourges.fr>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

In preparation for adding 0x50 support.
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>

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

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

In the very least VPE (PMPEG and friends) also has this style of tile
region regs, lets make them just work if/when they get added.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Like nv10-nv50, needs cleanup.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Like nv20-nv50, needs cleanup.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

A bit of cleanup done along the way, but, like nv40/nv50, needs more.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Like nv50, this needs a good cleanup.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Much nicer to do that nv50, the code was pretty much written to expect
such a change in the future.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

This needs a massive cleanup, but to catch bugs from the interface changes
vs the engine code cleanup, this will be done later.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

There's lots of more-or-less independant engines present on NVIDIA GPUs
these days, and we generally want to perform the same operations on them.
Implementing new ones requires hooking into lots of different places,
the aim of this work is to make this simpler and cleaner.

NV84:NV98 PCRYPT moved over as a test.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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

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

Improves the parsing of the memory timing table on NV50-NV98revA1 chipsets.

Added stepping to drm_nouveau_private to make sure newer NV98 (105M) is
zero rather than incorrect.
Signed-off-by: NRoy Spliet <r.spliet@student.tudelft.nl>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

This patch fixes messages such as
ERROR: space required after that ','
ERROR: spaces required around that '='
Signed-off-by: NEmil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: NFrancisco Jerez <currojerez@riseup.net>

Fix 'ERROR: code indent should use tabs where possible'
Fix 'ERROR: space required before the open parenthesis ('
Signed-off-by: NEmil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: NFrancisco Jerez <currojerez@riseup.net>

Fixes a possible lock ordering reversal between context_switch_lock
and ramin_lock.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
Reviewed-by: NFrancisco Jerez <currojerez@riseup.net>

It has been reported that this greatly improves (and possibly fixes
completely) the stability of NVA3+ chipsets.  In traces of my NVA8,
NVIDIA now appear to be doing this too.

The most recent traces of 0x50 and 0xac I could find don't show NVIDIA
checking PGRAPH status on these flushes, so for now, we won't either.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Fixes generated by 'codespell' and manually reviewed.
Signed-off-by: NLucas De Marchi <lucas.demarchi@profusion.mobi>

We may eventually end up with per-connector backlights, especially with
ddcci devices.  Make sure that the parent node for the backlight device is
the connector rather than the PCI device.
Signed-off-by: NMatthew Garrett <mjg@redhat.com>
Cc: Richard Purdie <rpurdie@rpsys.net>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: David Airlie <airlied@linux.ie>
Cc: Alex Deucher <alexdeucher@gmail.com>
Acked-by: NBen Skeggs <bskeggs@redhat.com>
Cc: Zhang Rui <rui.zhang@intel.com>
Cc: Len Brown <lenb@kernel.org>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Tested-by: NSedat Dilek <sedat.dilek@googlemail.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

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

The nv30/nv40 3d driver is about to start using DMA_FENCE from the 3D
object which, it turns out, doesn't like its DMA object to not be
aligned to a 4KiB boundary.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

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

The immediate benefit of doing this is that on NV50 and up, the GPU
virtual address of any buffer is now constant, regardless of what
memtype they're placed in.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

This structure will also be used for GART in the near future.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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

Upcoming patches are going to enable full support for buffers that keep
a constant GPU virtual address whenever they're validated for use by
the GPU.

In order for this to work properly while keeping support for large pages,
we need to know if it's ever going to be possible for a buffer to end
up in GART, and if so, disable large pages for the buffer's VMA.

This is a new restriction that's not present in earlier kernel's, but
should not break userspace as the current code never attempts to validate
buffers into a memtype other than it was created with.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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

'mappable' isn't really used at all, nor is it necessary anymore as the
bo code is capable of moving buffers to mappable vram as required.

'no_vm' isn't necessary anymore either, any places that don't want to be
mapped into a GPU address space should allocate the VRAM directly instead.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

We need to be able to have the bh run while possibly spinning waiting for
the EVO notifier to signal.  This apparently happens in some circumstances
with preempt disabled, so our workqueue was never being run.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>