This patch introduces the drm_gem_object_unreference_unlocked
and drm_gem_object_handle_unreference_unlocked functions that
do not require holding struct_mutex.

drm_gem_object_unreference_unlocked calls the new
->gem_free_object_unlocked entry point if available, and
otherwise just takes struct_mutex and just calls ->gem_free_object
Signed-off-by: NLuca Barbieri <luca@luca-barbieri.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

ATOM appears to return 0x20 which seems to mean some sort of timeout.

retry the transaction up to 10 times before failing, this
makes DP->VGA convertor we bought work at least a bit more predictably.
Signed-off-by: NDave Airlie <airlied@redhat.com>

radeon_copy_dma is only available for r200 or newer cards.
Call to radeon_copy_dma would result to NULL pointer
dereference if benchmarking asic without dma engine.
Signed-off-by: NPauli Nieminen <suokkos@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Even if this bumps the version to 1 it does not mean the driver is
out of staging. From what we know this is the last backwards
incompatible change to the driver.
Signed-off-by: NJakob Bornecrantz <jakob@vmware.com>
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NJakob Bornecrantz <jakob@vmware.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

When time-based throttling is implemented, we need to bump minor.
When the old way of detecting scanout is removed, we need to bump major.
In the meantime, this change should not break existing user-space.
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: NJakob Bornecrantz <jakob@vmware.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This memset_io was added to debug something way back and got
left behind, memset the fb to black so the borders don't be all white.
Signed-off-by: NDave Airlie <airlied@redhat.com>

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

Reported-by: NDan Carpenter <error27@gmail.com>
Signed-off-by: NMarcin Slusarz <marcin.slusarz@gmail.com>
Signed-off-by: NMaarten Maathuis <madman2003@gmail.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Unset the bit that indicates that a ctxprog can continue at the end.
Signed-off-by: NMaarten Maathuis <madman2003@gmail.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

ramfc is zero'ed upon destruction, so it's safer to do things in the right
order.
Signed-off-by: NMaarten Maathuis <madman2003@gmail.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

- We need to disable pgraph fifo access before checking the current channel,
  otherwise we could still hit a running ctxprog.
- The writes to 0x400500 are already handled by pgraph->fifo_access and are
  therefore redundant, moreover pgraph fifo access should not be reenabled
  before current context is set as invalid. So remove them altogether.
Signed-off-by: NMaarten Maathuis <madman2003@gmail.com>
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>

Fixes DVI+VGA on my 9400, and likely a lot of other configurations that
got broken by the previos DVI-over-DP fix.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

With DVI and DP plugged, the DVI clock change interrupts being run can
cause DP link training to fail.  This adds a spinlock around init table
parsing to prevent this.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Writes don't return a count, and adding the check broke native DP.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

It appears we aren't required to do memory sizing ourselves on nv40
either.  NV40 init tables read a strap from PEXTDEV_BOOT_0 into a
CRTC register, and then later use that value to select a memory
configuration (written to PFB_CFG0, just like INIT_COMPUTE_MEM on
earlier cards) with INIT_IO_RESTRICT_PROG.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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

We used single shared fbops struct and patched it at fb init time with
pointers to the right variant. On mixed multicard, this meant that
it was either sending NV50-style commands to all cards, or NV04-style
commands to all cards.
Signed-off-by: NMarcin Kościelnicki <koriakin@0x04.net>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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>

Reported on irc by nirbheek.
Signed-off-by: NDave Airlie <airlied@redhat.com>

This is strange - like really really strange, twilight zone of strange.
VGA ports have DDC buses, but sometimes for some reasons the BIOS
says we don't and we oops - AMD mentioned bios bugs so we'll have
to add quirks.

reported on irc by nirbheek and
https://bugzilla.redhat.com/show_bug.cgi?id=554323Signed-off-by: NDave Airlie <airlied@redhat.com>

Ingo pointed out that we really don't give the user enough warning to make
a decision here. So revise the Kconfig text with a better warning.
Acked-by: NIngo Molnar <mingo@elte.hu>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Fixes FDO bug #26214
Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This was incorrect according to the docs and the UMS driver does
it like this.
Signed-off-by: NDave Airlie <airlied@redhat.com>

Boot testing on my rs480 laptop found the MC idle never happened
on startup, a quick check with AMD found the idle bit is in a different
place on the rs4xx than r300.

Implement a new rs400 mc idle function to fix this.
Signed-off-by: NDave Airlie <airlied@redhat.com>

this was incorrect on my rs480.
Signed-off-by: NDave Airlie <airlied@redhat.com>

Support isn't correct yet and we are getting green tinges on the
displays.
Signed-off-by: NDave Airlie <airlied@redhat.com>

In suspend path we unmap the GART table while in cleaning up
path we will unbind buffer and thus try to write to unmapped
GART leading to oops. In order to avoid this we don't call the
suspend path in cleanup path. Cleanup path is clever enough
to desactive GPU like the suspend path is doing, thus this was
redondant.

Tested on: RV370, R420, RV515, RV570, RV610, RV770 (all PCIE)
Signed-off-by: NJerome Glisse <jglisse@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

drivers/gpu/drm/radeon/radeon_combios.c: In function 'radeon_combios_get_lvds_info':
drivers/gpu/drm/radeon/radeon_combios.c:893: warning: comparison is always false due to limited range of data type

Cc: Dave Airlie <airlied@linux.ie>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Fix ati_pcigart printk format warning:

drivers/gpu/drm/ati_pcigart.c:115: warning: format '%Lx' expects type 'long long unsigned int', but argument 3 has type 'dma_addr_t'
Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
Cc: Zhenyu Wang <zhenyuw@linux.intel.com>
Cc: Dave Airlie <airlied@linux.ie>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Cache flush is required in case CPU is accessing rendered data.

This fixes glean/readPixSanity test case and random rendering
errors in sauerbraten and warzone2100.

v2 Fix comment ordering in r100_fence_ring_emit and remove extra
   defines added in first version.
Signed-off-by: NPauli Nieminen <suokkos@gmail.com>
Reviewed-by: NJerome Glisse <jglisse@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

It seems that some R6XX/R7XX silently ignore HDP flush when
programmed through ring, this patch addback an ioctl callback
to allow R6XX/R7XX hw to perform such flush through MMIO in
order to fix a regression. For more details see:

http://bugzilla.kernel.org/show_bug.cgi?id=15186Signed-off-by: NJerome Glisse <jglisse@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

VGA might be overwritting VRAM and corrupt our blit shader leading
to corruption, it likely won't happen if you load fbcon right after
radeon. Thanks to Shawn Starr and Andre Maasikas for tracking down
this issue.
Signed-off-by: NJerome Glisse <jglisse@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>