- 24 Sep, 2010 35 commits
-
-
Francisco Jerez authored
More Apple brain damage, it fixes the modesetting failure on an eMac G4 (fdo bug 29810). Reported-by:
Zoltan Varnagy <doi@freemail.hu> Signed-off-by:
Francisco Jerez <currojerez@riseup.net> Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Francisco Jerez authored
Instead of emptying the caches to avoid a race with the PFIFO puller, go straight ahead and try to recover from it when it happens. Also, kill pfifo->cache_flush and tile->lock, we don't need them anymore. Signed-off-by:
-
Francisco Jerez authored
Signed-off-by:
-
Francisco Jerez authored
This makes sure that RAMHT is cleared correctly on start up. Signed-off-by:
-
Francisco Jerez authored
Signed-off-by:
-
Francisco Jerez authored
FW seems to be broken on nv18, it causes random lockups and breaks suspend/resume even with the blob. Signed-off-by:
-
Francisco Jerez authored
Signed-off-by:
-
Francisco Jerez authored
Signed-off-by:
-
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Marcin Kościelnicki authored
Signed-off-by:
Marcin Kościelnicki <koriakin@0x04.net> Signed-off-by:
-
Ben Skeggs authored
This doesn't actually happen now, but there's a test case for an earlier kernel where a GPU error is signalled on one of nv50's fake channels, and the ramht lookup by the IRQ handler triggered an oops. This adds a check for RAMHT's existance on a channel before looking up an object handle. Signed-off-by: -
Ben Skeggs authored
Reviewed-by:
-
Ben Skeggs authored
Reviewed-by:
-
Ben Skeggs authored
Reviewed-by:
-
Ben Skeggs authored
Reviewed-by:
-
Ben Skeggs authored
Reviewed-by:
-
Ben Skeggs authored
Reviewed-by:
-
Ben Skeggs authored
Will be used at a later point when we plug in an alternative VRAM memory manager for GeForce 8+ boards. Based on pscnv code to do the same. Signed-off-by:
-
Ben Skeggs authored
Reviewed-by:
-
Ben Skeggs authored
Reviewed-by:
-
Ben Skeggs authored
Reviewed-by:
-
Ben Skeggs authored
Reviewed-by:
-
Ben Skeggs authored
Reviewed-by:
-
Ben Skeggs authored
Reviewed-by:
-
Ben Skeggs authored
Signed-off-by: -
Francisco Jerez authored
They don't seem to do anything useful, and we really want to program CRE_LCD if we aren't lucky enough to find the right CRTC binding already set. Signed-off-by:
-
Francisco Jerez authored
On some boards the residual current DAC outputs can draw when they're disconnected can be high enough to give a false load detection positive (I've only seen it in the S-video luma output of some cards, but just to be sure). The output line capacitance is limited and sampling twice should fix it reliably. Signed-off-by:
-
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Hopefully this one will be better able to cope with moving tiled buffers around without getting them all scrambled as a result. Signed-off-by: -
Francisco Jerez authored
nv2x CRTC FIFOs are as large as in nv3x (4kB it seems), and the FIFO control registers have the same layout: we can make them share the same implementation. Previously we were using the nv1x code, but the calculated FIFO watermarks are usually too low for nv2x and they cause horrible scanout artifacts. They've gone unnoticed until now because we've been leaving one of the bandwidth regs uninitialized (CRE 47, which contains the most significant bits of FFLWM), so everything seemed to work fine except in some cases after a cold boot, depending on the memory bandwidth and pixel clocks used. Signed-off-by:
-
Francisco Jerez authored
On some nv4x cards (specifically, the ones that use an internal PCIE->AGP bridge) the AGP controller state isn't preserved after a suspend/resume cycle, and the AGP control registers have moved from 0x18xx to 0x100xx, so the FW check in nouveau_mem_reset_agp() doesn't quite work. Check "dev->agp->mode" instead. Signed-off-by:
-
- 20 Sep, 2010 1 commit
-
-
Chris Wilson authored
During heavy aperture thrashing we may be forced to wait upon several active objects during eviction. The active list may be the last reference to these objects and so the action of waiting upon one of them may cause another to be freed (and itself unbound). To prevent the object disappearing underneath us, we need to acquire and hold a reference whilst unbinding. This should fix the reported page refcount OOPS: kernel BUG at drivers/gpu/drm/i915/i915_gem.c:1444! ... RIP: 0010:[<ffffffffa0093026>] [<ffffffffa0093026>] i915_gem_object_put_pages+0x25/0xf5 [i915] Call Trace: [<ffffffffa009481d>] i915_gem_object_unbind+0xc5/0x1a7 [i915] [<ffffffffa0098ab2>] i915_gem_evict_something+0x3bd/0x409 [i915] [<ffffffffa0027923>] ? drm_gem_object_lookup+0x27/0x57 [drm] [<ffffffffa0093bc3>] i915_gem_object_bind_to_gtt+0x1d3/0x279 [i915] [<ffffffffa0095b30>] i915_gem_object_pin+0xa3/0x146 [i915] [<ffffffffa0027948>] ? drm_gem_object_lookup+0x4c/0x57 [drm] [<ffffffffa00961bc>] i915_gem_do_execbuffer+0x50d/0xe32 [i915] Reported-by:
Shawn Starr <shawn.starr@rogers.com> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=18902 Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk>
-
- 17 Sep, 2010 3 commits
-
-
Chris Wilson authored
There is a second revision of B43 (a desktop gen4 part) floating around, functionally equivalent to the original B43, so simply add the new PCI-IDs. Bugzilla: https://bugs.freedesktop.org/show_bugs.cgi?id=30221 Signed-off-by:
-
Chris Wilson authored
With 5 places to update when adding handling for fence registers, it is easy to overlook one or two. Correct that oversight, but fence management should be improved before a new set of registers is added. Bugzilla: https://bugs.freedesktop.org/show_bug?id=30199 Original patch by: Yuanhan Liu <yuanhan.liu@intel.com> Signed-off-by:
-
Chris Wilson authored
These are not fatal errors, so do not alarm the user by filling the logs with *** ERROR ***. Especially as we know that g4x CRT detection is a little sticky. On the one hand the errors are valid since they are warning us of a stall -- we poll the register whilst holding the mode lock so not even the mouse will update. On the other hand, those stalls were already present yet nobody complained. Reported-by:
Andi Kleen <andi@firstfloor.org> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=18332 Signed-off-by:
-
- 15 Sep, 2010 1 commit
-
-
Alex Deucher authored
The texture base address registers are in units of 256 bytes. The original CS checker treated these offsets as bytes, so the original check was wrong. I fixed the units in a patch during the 2.6.36 cycle, but this ended up breaking some existing userspace (probably due to a bug in either userspace texture allocation or the drm texture mipmap checker). So for now, until we come up with a better fix, just warn if the mipmap size it too large. This will keep existing userspace working and it should be just as safe as before when we were checking the wrong units. These are GPU MC addresses, so if they fall outside of the VRAM or GART apertures, they end up at the GPU default page, so this should be safe from a security perspective. v2: Just disable the warning. It just spams the log and there's nothing the user can do about it. Signed-off-by:
Alex Deucher <alexdeucher@gmail.com> Cc: Jerome Glisse <glisse@freedesktop.org> Signed-off-by:
Dave Airlie <airlied@redhat.com>
-
