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>

Explanation is in the commit.  If anyone has an example of where this is
*not* the case, please report it!
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>

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 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: that open brace { should be on the previous line'
Fix 'ERROR: else should follow close brace }'
Signed-off-by: NEmil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: NFrancisco Jerez <currojerez@riseup.net>

Fix 'ERROR: trailing whitespace',
Fix 'ERROR: do not use C99 // comments'
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>

Signed-off-by: NMartin Peres <martin.peres@ensi-bourges.fr>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NDave Airlie <airlied@redhat.com>

The MXMX method appears to be a mutex of some sort.
Signed-off-by: NDave Airlie <airlied@redhat.com>

optimus has another DSM GUID, so we check for its existance,
also allow the BIOS stuff is we find it.
Signed-off-by: NDave Airlie <airlied@redhat.com>

this hooks up nouveau to the MXM mux switching method.

With this in place I can switch the LVDS MUX on my T410s,
I expect we need a bit more work for other laptops.
Signed-off-by: NDave Airlie <airlied@redhat.com>

Commit 73412c38 ("drm/nouveau: allocate
kernel's notifier object at end of block") intended to align end of
notifier block to page boundary, but start of block was miscalculated
to be off by -16 bytes. Fix it.
Signed-off-by: NMarcin Slusarz <marcin.slusarz@gmail.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

nouveau_bo_wr32 expects offset to be in words, but we pass value in bytes,
so after commit 73412c38 ("drm/nouveau: allocate
kernel's notifier object at end of block") we started to overwrite some memory
after notifier buffer object (previously m2mf_ntfy was always 0, so it didn't
matter it was a value in bytes).
Reported-by: NDominik Brodowski <linux@dominikbrodowski.net>
Reported-by: NNigel Cunningham <lkml@nigelcunningham.com.au>
Signed-off-by: NMarcin Slusarz <marcin.slusarz@gmail.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Pekka Paalanen <pq@iki.fi>
Cc: stable@kernel.org    [2.6.38]
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Problem introduced with commit 6ba9a683Reported-by: NBob Gleitsmann <rjgleits@bellsouth.net>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Caught with kmemcheck on unrelated business.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Wasn't aware they even existed, apparently they do!  They're actually
AGP chips with a bridge as far as I can tell, which puts them in the
same boat as nv40/nv45.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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>

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

Not sure how this snuck in...
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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>

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

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

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

Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=35135
BUG: unable to handle kernel NULL pointer dereference at 000002d8
IP: [<f83694af>] nv04_dfp_restore+0x7f/0xd0 [nouveau]
(...)
Call Trace:
 [<f8372208>] nv04_display_destroy+0xa8/0x140 [nouveau]
 [<f830344a>] nouveau_unload+0x2a/0x160 [nouveau]
 [<f80d98fb>] drm_put_dev+0xbb/0x1b0 [drm]
 [<f8301025>] nouveau_pci_remove+0x15/0x20 [nouveau]
 [<c1292ad4>] pci_device_remove+0x44/0xf0
 [<c13339d1>] __device_release_driver+0x51/0xb0
 [<c133401f>] driver_detach+0x8f/0xa0
 [<c13338a3>] bus_remove_driver+0x63/0xa0
 [<c13340a9>] driver_unregister+0x49/0x80
 [<c1182f84>] ? sysfs_remove_file+0x14/0x20
 [<c1292bb2>] pci_unregister_driver+0x32/0x90
 [<c109b1da>] ? __stop_machine+0x5a/0x70
 [<f80d3f93>] drm_exit+0x83/0x90 [drm]
 [<f837875d>] nouveau_exit+0x1b/0x8be [nouveau]
 [<c1087b5b>] sys_delete_module+0x13b/0x1f0
 [<c1104c3e>] ? do_munmap+0x1fe/0x280
 [<c1104780>] ? arch_unmap_area_topdown+0x0/0x20
 [<c15096f4>] syscall_call+0x7/0xb
Reported-by: NFrancesco Marella <francesco.marella@gmail.com>
Tested-by: NFrancesco Marella <francesco.marella@gmail.com>
Signed-off-by: NMarcin Slusarz <marcin.slusarz@gmail.com>
[ currojerez@riseup.net: No need to spam the logs in that case, an
  unbound LVDS encoder is not an error. ]
Signed-off-by: NFrancisco Jerez <currojerez@riseup.net>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Perf tables v 1.2 and 1.3 (seen on Geforce FX/ 5) are not long enough
to store the voltage label/id

v2 - Remove comment from the code
Signed-off-by: NEmil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

In line with envytools, verified on 4 or 5 BIOS'es.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
Signed-off-by: NRoy Spliet <r.spliet@student.tudelft.nl>

Signed-off-by: NJan Engelhardt <jengelh@medozas.de>
Signed-off-by: NDave Airlie <airlied@redhat.com>