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: Ben 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: Ben 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: Marcin Slusarz <marcin.slusarz@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Depending on the visual, the colours handed to us in fillrect() can either be
an actual colour, or an index into the pseudo-palette.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
This should avoid a race condition on nv0x, if we're doing it with
actual PGRAPH objects and a there's a fence within the FIFO DMA fetch
area when a context switch kicks in.
In that case we get an ILLEGAL_MTHD interrupt as expected, but the
values in PGRAPH_TRAPPED_ADDR aren't calculated correctly and they're
almost useless (e.g. you can see ILLEGAL_MTHDs for the now inactive
channel, with a wrong offset/data pair).
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
It will be useful for various synchronization purposes, mostly stolen
from "[PATCH] drm/nv50: synchronize user channel after buffer object
move on kernel channel" by Maarten Maathuis.
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
- Aligning to block size should ensure that the extra size is enough.
- Using roundup, because not all sizes are powers of two.
Signed-off-by: Maarten Maathuis <madman2003@gmail.com>
struct fb_fillrect->color is not a color, but index into pseudo_palette
array
Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
This partially reverts e4b41066, as this driver is intended to be
useful with any KMS driver for suitable hardware. The missing build
dependency that commit workarounded was DRM_KMS_HELPER.
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
This commit has also the following 3 bugfix commits squashed into it from
the nouveau git tree:
drm/nouveau: Fix up the tiling alignment restrictions for nv1x.
drm/nouveau: Fix up the nv2x tiling alignment restrictions.
drm/nv50: fix align typo for g9x
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Lots of ppl keep thinking this is an oops, it was just a warning for
me to see, just make it a printk now.
Signed-off-by: Dave Airlie <airlied@redhat.com>
If userspace (plymouth in this case) asks for a deeper depth,
refuse it as well due to lack of resizing.
This fixes an issue since < 32MB cards went to 8bpp and plymouth
crashes on startup.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Ben Skeggs
Marcin Slusarz
Francisco Jerez
Maarten Maathuis
Dave Airlie