- 30 Jul, 2013 3 commits
-
-
Emil Velikov authored
Since the original merge of nouveau to upstream kernel, we were assuming that nv90 (and later) cards have 32 lines. Based on mmio traces of the binary driver, as well as PBUS error messages during read/write of the e070/e074 registers, we can conclude that nv92 has only 16 lines whereas nv94 (and later) cards have 32. Reported-and-tested-by: David M. Lloyd <david.lloyd@redhat.com> Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com> Cc: dri-devel@lists.freedesktop.org Cc: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Roy Spliet authored
Kernel panic caused by list corruption in ltcg seems to indicate a concurrency issue. Take mutex of pfb like nv50_ram_put() to eliminate concurrency. V2: Separate critical section into separate function, avoid taking the lock twice on NVC0 Signed-off-by: Roy Spliet <r.spliet@student.tudelft.nl> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ilia Mirkin authored
The current logic is wrong since we send fw->size >> 8 to the card. Rounding the size up by 0x100 and 0x1000 didn't seem to help, the card still hung, so go back to what the blob does -- 0x40000. Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
- 10 Jul, 2013 8 commits
-
-
Maarten Lankhorst authored
The API allows up to 64-bits allocations, but size is handled as int inside nouveau almost everywhere. Until this is fixed it's better to prevent negative sizes. The 256 kB before INT_MAX is paranoia, because of the large page aligning below that could flip it above INT_MAX. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Maarten Lankhorst authored
This prevents 100% cpu usage on fermi cards when the exit interrupt from the secret scrubber is not acked. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
The moves themselves were generally async to graphics previously, with the exception that if the "main" channel is used to synchronise a page flip at the same time, it can end up blocked for a noticable amount of time for large buffer moves. Not really critical, and there's better ways of handling this, but they are all rather invasive, so this is fine for now. Based on a patch by Maarten Lankhorst addressing the same issue. Reported-by: Maarten Lankhorst <maarten.lankhorst@canonical.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Acked-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
-
Maarten Lankhorst authored
calim didn't like 150 seconds timeout, so lower the timeout for him. 15 seconds should still be plenty. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Maarten Lankhorst authored
This should no longer be required, and is harmful for framebuffer pinning. Also add a warning if unpin causes the pin count to drop below 0. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Weren't critical previously, the buffers would go away anyway. But with recent changes to core drm/ttm lockdep will get pissed off now, so let's fix it. Reported-by: Maarten Lankhorst <maarten.lankhorst@canonical.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Acked-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
-
Maarten Lankhorst authored
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
b580c9e2 introduced additional problems while trying to solve issues that became apparent while porting to the new reservation stuff. The major problem was that the the previously mentioned patch took the client mutex earlier than previously, but the pinning of new_bo can can potentially cause a buffer move, which would result in attempting to acquire the same mutex again. This commit attempts to fix that "fix". Thanks to Maarten for the tips on keeping lockdep happy and cooking :) Reported-by: Maarten Lankhorst <maarten.lankhorst@canonical.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Acked-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
-
- 08 Jul, 2013 3 commits
-
-
Ben Skeggs authored
-
Maarten Lankhorst authored
"drm/nve0-/gr: some new gpc registers can have multiple copies" 5ee86c41 caused a regression for nvc0, because the bit indicating last transfer has occured was no longer set, resulting in random system lockups. Reported-by: Ronald Uitermark <ronald645@gmail.com> Tested-by: Ronald Uitermark <ronald645@gmail.com> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Reported-by: Maarten Lankhorst <maarten.lankhorst@canonical.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
- 05 Jul, 2013 26 commits
-
-
Ilia Mirkin authored
This is the nva3 counterpart to commit beba44b1 (drm/nv84/disp: Fix HDMI audio regression). The regression happened as a result of refactoring in commit 8e9e3d2d (drm/nv84/disp: move hdmi control into core). Reported-and-tested-by: Max Baldwin <archerseven@gmail.com> Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Cc: stable@vger.kernel.org
-
Emil Velikov authored
The commit commit 476e84e1 Author: Ben Skeggs <bskeggs@redhat.com> Date: Mon Feb 11 09:24:23 2013 +1000 drm/nv50-/disp: initial supervisor support for off-chip encoders changed the write mask in one of the interrupt functions for on-chip encoders, causing a regression in certain VGA dual-head setups. This commit reintroduces the mask thus resolving the regression Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66129Reported-and-Tested-by: Yves-Alexis <corsac@debian.org> Cc: stable@vger.kernel.org [3.9+] CC: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Marcin Slusarz authored
Page tables on nv50 take 48kB, which can be hard to allocate in one piece. Let's use vmalloc. Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com> Cc: stable@vger.kernel.org [3.7+] Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
NVC1/NVD9 are the only chipsets that should have anything different happen on them after this. We previously weren't doing these register modifications, and NVIDIA do. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
This can be generalised and used on GK104 (probably even GF117), but lets just make it work for now. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Maarten Lankhorst authored
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
GK110 exposes more than one, and needs to be dealt with in the ctxsw ucode just like the TPC sets are. Broadcast is at +0xe00. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Generated context verified to be the same for all supported chipsets. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
git://people.freedesktop.org/~airlied/linuxDave Airlie authored
Adds 3 features that UMS had to the KMS driver. dynamic resizing - resizing remote-viewer makes guest resize multiple crtcs - remote-viewer can access > 1 crtc. suspend/resume/hibernate: guests can do suspend/resume/hibernate now. * 'qxl-next' of git://people.freedesktop.org/~airlied/linux: qxl: use drm helper hotplug support qxl: add suspend/resume/hibernate support. qxl: add fb and ttm entry points for use by suspend/resume. qxl: add ring prep code for s/r qxl: prepare memslot code for suspend/resume qxl: split monitors_config object creation out. drm/qxl: set time on drawables from userspace drm/qxl: add support for > 1 output drm/qxl: make dynamic resizing work properly.
-
Dave Airlie authored
This uses the helper to deal with hotplug so fbdev gets included. Signed-off-by: Dave Airlie <airlied@redhat.com>
-
Dave Airlie authored
This adds suspend/resume and hibernate support for the KMS driver. it evicts all the objects, turns off the outputs, and waits for the hw to go idle, On resume, it resets the memslots, rings, monitors object and forces modeset. Signed-off-by: Dave Airlie <airlied@redhat.com>
-
Dave Airlie authored
This just ports some APIs like radeon uses to provide hooks for s/r to call. Signed-off-by: Dave Airlie <airlied@redhat.com>
-