linux/drivers/gpu/drm, branch v2.6.38

drm/radeon: fix problem with changing active VRAM size. (v2)

2011-03-14T02:51:04Z

So we used to use lpfn directly to restrict VRAM when we couldn't access the unmappable area, however this was removed in 93225b0d7bc030f4a93165347a65893685822d70 as it also restricted the gtt placements. However it was only later noticed that this broke on some hw. This removes the active_vram_size, and just explicitly sets it when it changes, TTM/drm_mm will always use the real_vram_size, and the active vram size will change the TTM size used for lpfn setting. We should re-work the fpfn/lpfn to per-placement at some point I suspect, but that is too late for this kernel. Hopefully this addresses: https://bugs.freedesktop.org/show_bug.cgi?id=35254 v2: fix reported useful VRAM size to userspace to be correct. Signed-off-by: Dave Airlie

drm/radeon: fix page flipping hangs on r300/r400

2011-03-13T00:03:34Z

We've been getting reports of complete system lockups with rv3xx hw on AGP and PCIE when running gnome-shell or kwin with compositing. It appears the hw really doesn't like setting these registers while stuff is running, this moves the setting of the registers into the modeset since they aren't required to be changed anywhere else. fixes: https://bugs.freedesktop.org/show_bug.cgi?id=35183 Reported-and-tested-by: Álmos

drm/radeon: add pageflip hooks for fusion

2011-03-11T05:01:15Z

Looks like these got passed over with both being merged at the same time but not quite meeting in the middle. should fix: https://bugs.freedesktop.org/show_bug.cgi?id=34137 along with Michael's phoronix article. Reported-by: Chi-Thanh Christopher Nguyen Article-written-by: Michael Larabel @ phoronix Signed-off-by: Dave Airlie

drm/i915: Revive combination mode for backlight control

2011-03-10T21:06:57Z

This reverts commit 951f3512dba5bd44cda3e5ee22b4b522e4bb09fb drm/i915: Do not handle backlight combination mode specially since this commit introduced other regressions due to untouched LBPC register, e.g. the backlight dimmed after resume. In addition to the revert, this patch includes a fix for the original issue (weird backlight levels) by removing the wrong bit shift for computing the current backlight level. Also, including typo fixes (lpbc -> lbpc). Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=34524 Acked-by: Indan Zupancic Reviewed-by: Keith Packard Reviewed-by: Jesse Barnes Cc: Signed-off-by: Takashi Iwai Signed-off-by: Linus Torvalds

drm: index i shadowed in 2nd loop

2011-03-07T22:28:33Z

Index i was already used in thhe first loop Signed-off-by: Roel Kluin Signed-off-by: Dave Airlie

Merge remote branch 'ickle/drm-intel-fixes' into drm-fixes

2011-03-07T21:18:35Z

* ickle/drm-intel-fixes: drm/i915: Rebind the buffer if its alignment constraints changes with tiling drm/i915: Disable GPU semaphores by default drm/i915: Do not overflow the MMADDR write FIFO Revert "drm/i915: fix corruptions on i8xx due to relaxed fencing"

drm/nv50-nvc0: prevent multiple vm/bar flushes occuring simultanenously

2011-03-07T21:03:08Z

The per-vm mutex doesn't prevent this completely, a flush coming from the BAR VM could potentially happen at the same time as one for the channel VM. Not to mention that if/when we get per-client/channel VM, this will happen far more frequently. Signed-off-by: Ben Skeggs Signed-off-by: Dave Airlie

drm/nouveau: fix regression causing ttm to not be able to evict vram

2011-03-07T21:03:01Z

TTM assumes an error condition from man->func->get_node() means that something went horribly wrong, and causes it to bail. The driver is supposed to return 0, and leave mm_node == NULL to signal that it couldn't allocate any memory. Signed-off-by: Ben Skeggs Signed-off-by: Dave Airlie

drm/i915: Rebind the buffer if its alignment constraints changes with tiling

2011-03-07T11:02:16Z

Early gen3 and gen2 chipset do not have the relaxed per-surface tiling constraints of the later chipsets, so we need to check that the GTT alignment is correct for the new tiling. If it is not, we need to rebind. Reported-by: Daniel Vetter Reviewed-by: Daniel Vetter Signed-off-by: Chris Wilson

drm/i915: Disable GPU semaphores by default

2011-03-07T11:00:59Z

Andi Kleen narrowed his GPU hangs on his Sugar Bay (SNB desktop) rev 09 down to the use of GPU semaphores, and we already know that they appear broken up to Huron River (mobile) rev 08. (I'm optimistic that disabling GPU semaphores is simply hiding another bug by the latency and side-effects of the additional device interaction it introduces...) However, use of semaphores is a massive performance improvement... Only as long as the system remains stable. Enable at your peril. Reported-by: Andi Kleen Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=33921 Signed-off-by: Chris Wilson