Test the just-allocated value for NULL rather than some other value.

The semantic patch that makes this change is as follows:
(http://coccinelle.lip6.fr/)

// <smpl>
@@
expression x,y;
statement S;
@@

x = \(kmalloc\|kcalloc\|kzalloc\)(...);
(
if ((x) == NULL) S
|
if (
-   y
+   x
       == NULL)
 S
)
// </smpl>
Signed-off-by: NJulia Lawall <julia@diku.dk>
Cc: David Airlie <airlied@linux.ie>
Cc: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

nouveau_gem_ioctl_cpu_prep calls ttm_bo_wait without the bo lock held.
ttm_bo_wait unlocks that lock, and so must be called with it held.

Currently this bug causes libdrm nouveau_bo_busy() to hang the machine.

Signed-off-by: Luca Barbieri <luca at luca-barbieri.com>
Acked-by: NMaarten Maathuis <madman2003@gmail.com>
Signed-off-by: NFrancisco Jerez <currojerez@riseup.net>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Apparently, they generate a PFIFO interrupt each time one of the
semaphore methods is executed if its ctxdma wasn't manually marked as
valid. This patch makes it flip the valid bit in response to the
DMA_SEMAPHORE method (which triggers the IRQ even for a valid ctxdma).
Signed-off-by: NFrancisco Jerez <currojerez@riseup.net>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

On nv50, this will be needed by applications using CUDA to know
how much stack/local memory to allocate.
Signed-off-by: NMarcin Kościelnicki <koriakin@0x04.net>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

noaccel=1 disables all acceleration and doesn't even attempt
initialising PGRAPH+PFIFO, nofbaccel=1 only makes fbcon unaccelerated.
Signed-off-by: NMarcin Kościelnicki <koriakin@0x04.net>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Due to a thinko, these were previously forced to VRAM even if we allocated
them in GART.

This commit fixes that bug, but keeps the previous behaviour of using VRAM
by default until it's been tested properly across more chipsets.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Another hack because of us exposing each encoder block's function as
an encoder rather than exposing a single encoder that deals with them
all.

A proper fix will come, it's just rather invasive so this hack will
do until then.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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

We need to add the buffer to the list even if we fail, otherwise the
validate_fini() call won't unreserve + unreference the GEM object,
making TTM very unhappy.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Also adds a module option to ignore the status reported via ACPI, in case
we hit systems with broken ACPI.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

On most cards the DisplayPort connector is created with 2 encoders sharing
a single SOR (for native DP, and for DVI-over-DP).  The previous logic
for turning off unused encoders didn't take into account that we could
have multiple drm_encoders on a single hw encoder and ended up turning off
encoders that were actually being used still.

This patch fixes that issue.  We probably want to look at something a bit
better later on, and only expose one drm_encoder per hw encoder block.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

GPU pointer to the structure is shifted right by 10 bits, so we need to
align to 1024 bytes, not 256.
Reported-by: NMaarten Maathuis <madman2003@gmail.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Currently, we take down the sgdma engine without evicting all buffers
from VRAM.

The TTM device release will try to evict anything in VRAM to GART
memory, but this will fail since sgdma has already been taken down.

This causes an infinite loop in kernel mode on module unload.
It usually doesn't happen because there aren't any buffer on close.
However, if the GPU is locked up, this condition is easily triggered.

This patch fixes it in the simplest way possible by cleaning VRAM
right before cleaning SGDMA memory.
Signed-off-by: NLuca Barbieri <luca@luca-barbieri.com>
Signed-off-by: NFrancisco Jerez <currojerez@riseup.net>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Currently Nouveau is unable to dismiss DMA_VTX_PROTECTION errors,
which results in an infinite loop in the interrupt handler.

These errors are caused both by bugs in the Gallium driver and by
user-specified index buffers with out of bounds indices.

By mmio-tracing the nVidia drivers, I found out how this is done.
On DMA_VTX_PROTECTION, The nVidia driver reads the register 0x402000,
always getting the value 4, and then writes 4 back to 0x402000.

This patch adds that logic by reading 0x402000 and writing the same
value back.
It's unclear what should happen if the value read is not 4, and
the current approach might not be the correct one.

To test this, modify mesa/progs/trivial/vbo-drawrange.c, defining
ELTOBJ to 1 and replacing indices with huge out of bounds integers.

Without this patch, the GPU and/or kernel should lock up.
With this patch, it should misrender as expected but not lock up.

The errors are still logged since they are useful for development.

This has been tested on NV49 and may not work on other cards.

To find out how things work on other cards, run the aforementioned
test using the blob with mmiotrace and grep for a read of the PGRAPH
source register.
Signed-off-by: NLuca Barbieri <luca@luca-barbieri.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>

Can be triggered easily on certain cards (NV46 and NV50 of mine) by
running "dmesg", the DRM's channel will lockup.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Currently there is no check that the pushbuffer request bounds are inside
the TTM BO.

This allows to instruct the kernel to do relocations on user-selected
addresses, since the relocation bounds checking relies on the request
bounds.

This can oops the kernel accidentally and is easily exploitable.

This patch adds bound checking and alignment checking for ->offset and
->nr_dwords.

It also makes some variables unsigned, which should have no effect,
but prevents possible bounds checking problems.
Signed-off-by: NLuca Barbieri <luca@luca-barbieri.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

This is to prevent things such as GART tables and other important GPU
structures being allocated there before we take over fbcon ourselves.

This is more of a workaround for the moment, a better solution will
require some more invasive changes, but it'll be done at some point.
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>

This was spotted by kmemleak.
Signed-off-by: NXavier Chantry <shiningxc@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>

This fixes imac black screen (NV18 card)
Signed-off-by: NAndrea Tacconi <tacconet@libero.it>
Signed-off-by: NFrancisco Jerez <currojerez@riseup.net>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

This enables streamout functionality.
Signed-off-by: NMarcin Kościelnicki <koriakin@0x04.net>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

This in the very least matches the parsing of all the previously known
entries, and hopefully (at least closer to) correct for any we haven't
seen yet.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

There's a report of a TNT2 where the DCB table pointer is *not* NULL
(it contains a part of a VBIOS data string), and we assume this means
a DCB table is present, causing all kinds of hilarity.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

We don't setup PRIV0 anymore, so this is unnecessary.
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>

Apparently the original reason for checking this was there were known
register accesses that caused hangs on some chipsets.  This was more
than likely because of incorrect parsing of previous opcodes, and I
hardly think aborting a script half way through is going to be any
better (in fact, we have had bug reports where this has been the cause
of s/r failures among other things).

This patch (which has been in Fedora 12 for a long time now) removes
all checking for known register ranges, and just leaves the check to
ensure the access is within the mapped aperture to avoid an oops.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

This should fix the problem with gpu hangs people have had when closing
channels.
Signed-off-by: NMaarten Maathuis <madman2003@gmail.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>

Some upcoming G80 DMA changes will depend on this, but it's split out for
bisectibility just in case it causes some unexpected issues.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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

Currently Nouveau will unvalidate all buffers if it is forced to wait on
one, and then start revalidating from the beginning.  While doing so, it
destroys the operation fence, causing nouveau_fence_emit to crash.

This patch fixes this bug by taking the fence object out of validate_op
and creating it just before emit.  The fence pointer is initialized to 0
and unref'ed unconditionally.

In addition to fixing the bug, this prevents its reintroduction and
simplifies the code.
Signed-off-by: NLuca Barbieri <luca@luca-barbieri.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

The below is mainly an educated guess at what's going on, docs would
sure be handy...  NVIDIA? :P

It appears it's possible for a ctxprog to run even while a GPU exception
is pending.  The GF8 and up ctxprogs appear to have a small snippet of
code which detects this, and stalls the ctxprog until it's been handled,
which essentially looks like:

	if (r2 & 0x00008000) {
		r0 |= 0x80000000;
		while (r0 & 0x80000000) {}
	}

I don't know of any way that flag would get cleared unless the driver
intervenes (and indeed, in the cases I've seen the hang, nothing steps
in to automagically clear it for us).  This patch causes the driver to
clear the flag during the PGRAPH IRQ handler.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

There's no good reason for us to have our own anymore, this is left over
from an early port to these TTM interfaces.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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

It's mostly a cleanup, but in nv50_fbcon_accel_init gpu lockup
message was printed, but HWACCEL_DISBALED flag was not set.
Signed-off-by: NMarcin Slusarz <marcin.slusarz@gmail.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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