linux-toradex.git/drivers/gpu, branch v3.4.30 Linux kernel for Apalis and Colibri modules drm/radeon: Calling object_unrefer() when creating fb failure 2013-02-11T16:47:18+00:00 liu chuansheng chuansheng.liu@intel.com 2013-01-31T14:13:00+00:00 8f69eeaecbb7d741e943f7972627bbd1ca294ab6 commit f2d68cf4daa4de97d400d94836b907e35228e54f upstream. When kzalloc() failed in radeon_user_framebuffer_create(), need to call object_unreference() to match the object_reference(). Signed-off-by: liu chuansheng <chuansheng.liu@intel.com> Signed-off-by: xueminsu <xuemin.su@intel.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit f2d68cf4daa4de97d400d94836b907e35228e54f upstream.

When kzalloc() failed in radeon_user_framebuffer_create(), need to
call object_unreference() to match the object_reference().

Signed-off-by: liu chuansheng <chuansheng.liu@intel.com>
Signed-off-by: xueminsu <xuemin.su@intel.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
drm/radeon: prevent crash in the ring space allocation 2013-02-11T16:47:18+00:00 Alex Deucher alexander.deucher@amd.com 2013-01-30T19:24:09+00:00 dcf73edd833be6d4999a7d8f6cc6941c9e475ce4 commit fd5d93a0015ce1a7db881382022b2fcdfdc61760 upstream. If the requested number of DWs on the ring is larger than the size of the ring itself, return an error. In testing with large VM updates, we've seen crashes when we try and allocate more space on the ring than the total size of the ring without checking. This prevents the crash but for large VM updates or bo moves of very large buffers, we will need to break the transaction down into multiple batches. I have patches to use IBs for the next kernel. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit fd5d93a0015ce1a7db881382022b2fcdfdc61760 upstream.

If the requested number of DWs on the ring is larger than
the size of the ring itself, return an error.

In testing with large VM updates, we've seen crashes when we
try and allocate more space on the ring than the total size
of the ring without checking.

This prevents the crash but for large VM updates or bo moves
of very large buffers, we will need to break the transaction
down into multiple batches.  I have patches to use IBs for
the next kernel.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
drm/radeon: fix MC blackout on evergreen+ 2013-02-11T16:47:17+00:00 Christopher Staite chris@yourdreamnet.co.uk 2013-01-26T16:10:58+00:00 c7d3c1787d491f55849d587e519a0bfe14d5f716 commit bb588820ef421c6098dca1fec29c3b347f1c8c19 upstream. Force the crtc mem requests on/off immediately rather than waiting for the double buffered updates to kick in. Seems we miss the update in certain conditions. Also handle the DCE6 case. Signed-off-by: Christopher Staite <chris@yourdreamnet.co.uk> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit bb588820ef421c6098dca1fec29c3b347f1c8c19 upstream.

Force the crtc mem requests on/off immediately rather
than waiting for the double buffered updates to kick in.
Seems we miss the update in certain conditions.  Also
handle the DCE6 case.

Signed-off-by: Christopher Staite <chris@yourdreamnet.co.uk>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
drm/radeon: add quirk for RV100 board 2013-02-11T16:47:17+00:00 Alex Deucher alexander.deucher@amd.com 2013-01-29T21:36:47+00:00 b5dc90fe1300df803e7c5b1922c759e135116251 commit 9200ee4941a6e5d1ec5df88982243686882dff3f upstream. vbios says external TMDS while the board is actually internal TMDS. fixes: https://bugs.freedesktop.org/show_bug.cgi?id=60037 Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 9200ee4941a6e5d1ec5df88982243686882dff3f upstream.

vbios says external TMDS while the board is actually
internal TMDS.

fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=60037

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
drm/radeon: add WAIT_UNTIL to the non-VM safe regs list for cayman/TN 2013-02-11T16:47:17+00:00 Alex Deucher alexander.deucher@amd.com 2013-01-28T02:57:51+00:00 b5d3ef25ca19150e30b0d3c0969349951134684b commit 674a16f2b4724880d07389abbb95abf320b924aa upstream. Newer versions of mesa emit this. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 674a16f2b4724880d07389abbb95abf320b924aa upstream.

Newer versions of mesa emit this.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
drm/radeon/evergreen+: wait for the MC to settle after MC blackout 2013-02-11T16:47:17+00:00 Alex Deucher alexander.deucher@amd.com 2013-01-31T14:00:52+00:00 36509fceeabafd1a6e95e48ae75efe020fa59937 commit ed39fadd6df01095378e499fac3674883f16b853 upstream. Some chips seem to need a little delay after blacking out the MC before the requests actually stop. May fix: https://bugs.freedesktop.org/show_bug.cgi?id=56139 https://bugs.freedesktop.org/show_bug.cgi?id=57567 Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit ed39fadd6df01095378e499fac3674883f16b853 upstream.

Some chips seem to need a little delay after blacking out
the MC before the requests actually stop.

May fix:
https://bugs.freedesktop.org/show_bug.cgi?id=56139
https://bugs.freedesktop.org/show_bug.cgi?id=57567

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
radeon_display: Use pointer return error codes 2013-02-04T00:24:40+00:00 xueminsu xuemin.su@intel.com 2013-01-22T14:16:53+00:00 592306fd6bde5d73b2586ab163b4c78953d182ac commit b2f4b03f8a378cd626d2ea67d19e7470c050a098 upstream. drm_mode_addfb() expects fb_create return error code instead of NULL. Signed-off-by: xueminsu <xuemin.su@intel.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit b2f4b03f8a378cd626d2ea67d19e7470c050a098 upstream.

drm_mode_addfb() expects fb_create return error code
instead of NULL.

Signed-off-by: xueminsu <xuemin.su@intel.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
drm/radeon: fix cursor corruption on DCE6 and newer 2013-02-04T00:24:40+00:00 Jerome Glisse jglisse@redhat.com 2013-01-21T20:50:03+00:00 d4ffc500fcf28db4bc6e358e318b37bb884e421b commit e521a29014794d139cca46396d1af8faf1295a26 upstream. Aruba and newer gpu does not need the avivo cursor work around, quite the opposite this work around lead to corruption. agd5f: check DCE6 rather than ARUBA since the issue is DCE version specific rather than family specific. Signed-off-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit e521a29014794d139cca46396d1af8faf1295a26 upstream.

Aruba and newer gpu does not need the avivo cursor work around,
quite the opposite this work around lead to corruption.

agd5f: check DCE6 rather than ARUBA since the issue is DCE
version specific rather than family specific.

Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
drm/i915: Implement WaDisableHiZPlanesWhenMSAAEnabled 2013-01-28T04:47:44+00:00 Daniel Vetter daniel.vetter@ffwll.ch 2012-12-14T22:38:28+00:00 35d620d4a06a739c97f9e4ea53374df8c2c95281 commit 4283908ef7f11a72c3b80dd4cf026f1a86429f82 upstream. Quoting from Bspec, 3D_CHICKEN1, bit 10 This bit needs to be set always to "1", Project: DevSNB " Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Abdallah Chatila <abdallah.chatila@ericsson.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 4283908ef7f11a72c3b80dd4cf026f1a86429f82 upstream.

Quoting from Bspec, 3D_CHICKEN1, bit 10

This bit needs to be set always to "1", Project: DevSNB "

Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Abdallah Chatila <abdallah.chatila@ericsson.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
drm/i915: Invalidate the relocation presumed_offsets along the slow path 2013-01-28T04:47:42+00:00 Chris Wilson chris@chris-wilson.co.uk 2013-01-15T16:17:54+00:00 aa824d5b726d7d7d90331bcacc7807b83f02fa54 commit 262b6d363fcff16359c93bd58c297f961f6e6273 upstream. In the slow path, we are forced to copy the relocations prior to acquiring the struct mutex in order to handle pagefaults. We forgo copying the new offsets back into the relocation entries in order to prevent a recursive locking bug should we trigger a pagefault whilst holding the mutex for the reservations of the execbuffer. Therefore, we need to reset the presumed_offsets just in case the objects are rebound back into their old locations after relocating for this exexbuffer - if that were to happen we would assume the relocations were valid and leave the actual pointers to the kernels dangling, instant hang. Fixes regression from commit bcf50e2775bbc3101932d8e4ab8c7902aa4163b4 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Sun Nov 21 22:07:12 2010 +0000 drm/i915: Handle pagefaults in execbuffer user relocations Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=55984 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@fwll.ch> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> 
commit 262b6d363fcff16359c93bd58c297f961f6e6273 upstream.

In the slow path, we are forced to copy the relocations prior to
acquiring the struct mutex in order to handle pagefaults. We forgo
copying the new offsets back into the relocation entries in order to
prevent a recursive locking bug should we trigger a pagefault whilst
holding the mutex for the reservations of the execbuffer. Therefore, we
need to reset the presumed_offsets just in case the objects are rebound
back into their old locations after relocating for this exexbuffer - if
that were to happen we would assume the relocations were valid and leave
the actual pointers to the kernels dangling, instant hang.

Fixes regression from commit bcf50e2775bbc3101932d8e4ab8c7902aa4163b4
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Sun Nov 21 22:07:12 2010 +0000

    drm/i915: Handle pagefaults in execbuffer user relocations

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=55984
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@fwll.ch>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>