The "return" command is buggy on the original nv20, it jumps back to
the caller address as expected, but it doesn't clear the subroutine
active bit making the subsequent pushbuf calls fail with a "stack"
overflow.
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The TMDS output of an nv11 was being detected as LVDS, because it uses
DCB type 2 for TMDS instead of type 4.
Reported-by: Bertrand VIEILLE <Vieille.Bertrand@free.fr>
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
This should fix the reported TV-out load detection false positives
(fdo bug 29455).
Reported-by: Vlado Plaga <rechner@vlado-do.de>
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The blob also thinks there's a TV connected, so hardware bug...
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
This message is apparently confusing people, and is being blamed for some
modesetting issues. Lets remove the message, and instead replace it
with an unconditional printout of the table revision.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
When VRAM is running out it's possible that the client's push buffers get
evicted to main memory. When they're validated back in, the GPU may
be used for the copy back to VRAM, but the existing synchronisation code
only deals with inter-channel sync, not sync between PFIFO and PGRAPH on
the same channel. This leads to PFIFO fetching from command buffers that
haven't quite been copied by PGRAPH yet.
This patch marks push buffers as so, and forces any GPU-assisted buffer
moves to be done on a different channel, which triggers the correct
synchronisation to happen before we submit them.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Fixes a regression introduced by 58bbb63720c8997e0136fe1884101e7ca40d68fd
(fdo bug 29324).
Reported-by: Johannes Obermayr <johannesobermayr@gmx.de>
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
We need a valid OR value because there're a few nv17 cards with DCB v1.4.
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
There's some known configurations where the lack of these tables/scripts
is perfectly normal, reduce visibilty of complaint messages to debug.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
sil164 and friends are the most common, usually they just need to be
poked once because a fixed configuration is enough for any modes and
clocks, so they worked without this patch if the BIOS had done a good
job on POST. Display couldn't survive a suspend/resume cycle though.
Unfortunately, BIOS scripts are useless here.
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Not very nice, but I don't think there's a simpler workaround.
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Leaving the IRQ unack'ed while switching contexts makes the switch
fail randomly on some nv1x.
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
nouveau_load() just returned directly if there was an error instead of
releasing resources.
Signed-off-by: Dan Carpenter <error27@gmail.com>
Reviewed-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Previously nouveau_mem_reset_agp() was only disabling AGP fast writes
when coming back from suspend. However, the "locked out of the card
because of FW" problem can also be reproduced on init if you
unload/reload nouveau.ko several times. This patch makes the AGP code
reset FW on init.
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
This makes it easier to see how this is working, and lets us transfer the
EDID in blocks of 16 bytes.
The primary reason for this change is because debug logs are rather hard
to read with the hundreds of single-byte auxch transactions that occur.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
IRQ and resource[] may not have correct values until
after PCI hotplug setup occurs at pci_enable_device() time.
The semantic match that finds this problem is as follows:
// <smpl>
@@
identifier x;
identifier request ~= "pci_request.*|pci_resource.*";
@@
(
* x->irq
|
* x->resource
|
* request(x, ...)
)
...
*pci_enable_device(x)
// </smpl>
Signed-off-by: Kulikov Vasiliy <segooon@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
IRQ and resource[] may not have correct values until
after PCI hotplug setup occurs at pci_enable_device() time.
The semantic match that finds this problem is as follows:
// <smpl>
@@
identifier x;
identifier request ~= "pci_request.*|pci_resource.*";
@@
(
* x->irq
|
* x->resource
|
* request(x, ...)
)
...
*pci_enable_device(x)
// </smpl>
Signed-off-by: Kulikov Vasiliy <segooon@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This restricts the use of the big kernel lock to the i830 and i810
device drivers. The three remaining users in common code (open, ioctl
and release) get converted to a new mutex, the drm_global_mutex,
making the locking stricter than the big kernel lock.
This may have a performance impact, but only in those cases that
currently don't use DRM_UNLOCKED flag in the ioctl list and would
benefit from that anyway.
The reason why i810 and i830 cannot use drm_global_mutex in their
mmap functions is a lock-order inversion problem between the current
use of the BKL and mmap_sem in these drivers. Since the BKL has
release-on-sleep semantics, it's harmless but it would cause trouble
if we replace the BKL with a mutex.
Instead, these drivers get their own ioctl wrappers that take the
BKL around every ioctl call and then set their own handlers as
DRM_UNLOCKED.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: David Airlie <airlied@linux.ie>
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
In most use cases the driver will be using the same static config all
the time: interpreting i2c_board_info::platform_data as the default
config we can can save the GPU driver a redundant set_config() call.
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This is required should we ever attempt to use an io-mapping where
KM_USER0 is verboten, such as inside an IRQ context.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
