aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/nouveau
Commit message (Collapse)AuthorAge
* drm/nouveau: Force TV encoder DPMS reinit after resume.Francisco Jerez2010-02-15
| | | | | Signed-off-by: Francisco Jerez <currojerez@riseup.net> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau: use mutex for vbios lockBen Skeggs2010-02-15
| | | | Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* nouveau: fix state detection with switchable graphicsMatthew Garrett2010-02-10
| | | | | Signed-off-by: Matthew Garrett <mjg@redhat.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau: move dereferences after null checksMarcin Slusarz2010-02-10
| | | | | | | Reported-by: Dan Carpenter <error27@gmail.com> Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com> Signed-off-by: Maarten Maathuis <madman2003@gmail.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nv50: make the pgraph irq handler loop like the pre-nv50 versionMaarten Maathuis2010-02-09
| | | | | | | Unset the bit that indicates that a ctxprog can continue at the end. Signed-off-by: Maarten Maathuis <madman2003@gmail.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nv50: delete ramfc object after disabling fifo, not beforeMaarten Maathuis2010-02-09
| | | | | | | | ramfc is zero'ed upon destruction, so it's safer to do things in the right order. Signed-off-by: Maarten Maathuis <madman2003@gmail.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nv50: avoid unloading pgraph context when ctxprog is runningMaarten Maathuis2010-02-09
| | | | | | | | | | | - 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: Maarten Maathuis <madman2003@gmail.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nv50: align size of buffer object to the right boundaries.Maarten Maathuis2010-02-09
| | | | | | | | | | | | - 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: Maarten Maathuis <madman2003@gmail.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nv50: disregard dac outputs in nv50_sor_dpms()Ben Skeggs2010-02-09
| | | | | | | 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: Ben Skeggs <bskeggs@redhat.com>
* drm/nv50: prevent multiple init tables being parsed at the same timeBen Skeggs2010-02-09
| | | | | | | | 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: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau: make dp auxch xfer len check for reads onlyBen Skeggs2010-02-08
| | | | | | Writes don't return a count, and adding the check broke native DP. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nv40: make INIT_COMPUTE_MEM a NOP, just like nv50Ben Skeggs2010-02-08
| | | | | | | | | | 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: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau: Add proper vgaarb support.Marcin Kościelnicki2010-02-08
| | | | | Signed-off-by: Marcin Kościelnicki <koriakin@0x04.net> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau: Fix fbcon on mixed pre-NV50 + NV50 multicard.Marcin Kościelnicki2010-02-08
| | | | | | | | | | 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: Marcin Kościelnicki <koriakin@0x04.net> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drivers/gpu/drm/nouveau/nouveau_grctx.c: correct NULL testJulia Lawall2010-02-08
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Julia Lawall <julia@diku.dk> Cc: David Airlie <airlied@linux.ie> Cc: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau: call ttm_bo_wait with the bo lock held to prevent hangLuca Barbieri2010-02-08
| | | | | | | | | | | | 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: Maarten Maathuis <madman2003@gmail.com> Signed-off-by: Francisco Jerez <currojerez@riseup.net> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau: Fixup semaphores on pre-nv50 cards.Francisco Jerez2010-02-08
| | | | | | | | | | 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: Francisco Jerez <currojerez@riseup.net> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau: Add getparam to get available PGRAPH units.Marcin Kościelnicki2010-02-08
| | | | | | | | On nv50, this will be needed by applications using CUDA to know how much stack/local memory to allocate. Signed-off-by: Marcin Kościelnicki <koriakin@0x04.net> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau: Add module options to disable acceleration.Marcin Kościelnicki2010-02-08
| | | | | | | | noaccel=1 disables all acceleration and doesn't even attempt initialising PGRAPH+PFIFO, nofbaccel=1 only makes fbcon unaccelerated. Signed-off-by: Marcin Kościelnicki <koriakin@0x04.net> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau: fix non-vram notifier blocksBen Skeggs2010-02-08
| | | | | | | | | | 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: Ben Skeggs <bskeggs@redhat.com>
* drm/nv50: prevent switching off SOR when in use for DVI-over-DPBen Skeggs2010-01-24
| | | | | | | | | | | 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: Ben Skeggs <bskeggs@redhat.com>
* drm/nv50: fail auxch transaction if reply count not what we expectBen Skeggs2010-01-24
| | | | Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau: fix failure path if userspace specifies no valid memtypesBen Skeggs2010-01-24
| | | | | | | | 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: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau: report LVDS as disconnected if lid closedBen Skeggs2010-01-24
| | | | | | | Also adds a module option to ignore the status reported via ACPI, in case we hit systems with broken ACPI. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nv50: prevent accidently turning off encoders we're actually usingBen Skeggs2010-01-17
| | | | | | | | | | | | | 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: Ben Skeggs <bskeggs@redhat.com>
* drm/nv50: fix alignment of per-channel fifo cacheBen Skeggs2010-01-17
| | | | | | | | GPU pointer to the structure is shifted right by 10 bits, so we need to align to 1024 bytes, not 256. Reported-by: Maarten Maathuis <madman2003@gmail.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau: Evict buffers in VRAM before freeing sgdmaLuca Barbieri2010-01-17
| | | | | | | | | | | | | | | | | | | 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: Luca Barbieri <luca@luca-barbieri.com> Signed-off-by: Francisco Jerez <currojerez@riseup.net> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau: Acknowledge DMA_VTX_PROTECTION PGRAPH interruptsLuca Barbieri2010-01-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Luca Barbieri <luca@luca-barbieri.com> Signed-off-by: Francisco Jerez <currojerez@riseup.net> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau: fix thinko in nv04_instmem.cBen Skeggs2010-01-17
| | | | Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau: fix a race condition in nouveau_dma_wait()Ben Skeggs2010-01-17
| | | | | | | Can be triggered easily on certain cards (NV46 and NV50 of mine) by running "dmesg", the DRM's channel will lockup. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau: check pushbuffer bounds in ioctlLuca Barbieri2010-01-14
| | | | | | | | | | | | | | | | | | | | 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: Luca Barbieri <luca@luca-barbieri.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau: reserve VGA area for the momentBen Skeggs2010-01-14
| | | | | | | | | | 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: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau: Unset the EDID connector property when the EDID block goes away.Francisco Jerez2010-01-14
| | | | | Signed-off-by: Francisco Jerez <currojerez@riseup.net> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau: Fallback to analog load detection when the EDID block is invalid.Francisco Jerez2010-01-14
| | | | | Signed-off-by: Francisco Jerez <currojerez@riseup.net> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau: fix edid memleak in nouveau_connectorXavier Chantry2010-01-14
| | | | | | | | This was spotted by kmemleak. Signed-off-by: Xavier Chantry <shiningxc@gmail.com> Signed-off-by: Francisco Jerez <currojerez@riseup.net> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau: Break some long lines.Francisco Jerez2010-01-14
| | | | | Signed-off-by: Francisco Jerez <currojerez@riseup.net> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau: add NV18 device id to call_lvds_manufacturer_scriptAndrea Tacconi2010-01-14
| | | | | | | | This fixes imac black screen (NV18 card) Signed-off-by: Andrea Tacconi <tacconet@libero.it> Signed-off-by: Francisco Jerez <currojerez@riseup.net> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nv50: Fix typo in PGRAPH initialisation.Marcin Kościelnicki2010-01-14
| | | | | | | This enables streamout functionality. Signed-off-by: Marcin Kościelnicki <koriakin@0x04.net> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau: less magic DCB 1.5 parsingBen Skeggs2010-01-14
| | | | | | | | 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: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau: assume no nv04 board has a DCB tableBen Skeggs2010-01-14
| | | | | | | | 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: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau: remove PRIV0 check in nouveau_mem_close()Ben Skeggs2010-01-14
| | | | | | We don't setup PRIV0 anymore, so this is unnecessary. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau: wait on fence after bo move if validating for another channelBen Skeggs2010-01-14
| | | | | | | | | | | 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: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau: trust init table registers are safeBen Skeggs2010-01-14
| | | | | | | | | | | | | | | 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: Ben Skeggs <bskeggs@redhat.com>
* drm/nv50: wait for pgraph to idle before unloading the contextMaarten Maathuis2010-01-14
| | | | | | | | This should fix the problem with gpu hangs people have had when closing channels. Signed-off-by: Maarten Maathuis <madman2003@gmail.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nv04: Fix set_operation software method.Marcin Kościelnicki2010-01-10
| | | | Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau: initialise DMA tracking parameters earlierBen Skeggs2010-01-10
| | | | Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau: use dma.max rather than pushbuf size for checking GET validityBen Skeggs2010-01-10
| | | | | | | 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: Ben Skeggs <bskeggs@redhat.com>
* drm/nv04: differentiate between nv04/nv05Ben Skeggs2010-01-10
| | | | Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau: Fix null deref in nouveau_fence_emit due to deleted fenceLuca Barbieri2010-01-10
| | | | | | | | | | | | | | | | 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: Luca Barbieri <luca@luca-barbieri.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nv50: prevent a possible ctxprog hangBen Skeggs2010-01-10
| | | | | | | | | | | | | | | | | | | | | | 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>
generated by cgit v1.2.2 (git 2.25.0) at 2025-02-11 13:08:40 -0500