#
01175474 |
|
08-Aug-2023 |
Srinivasan Shanmugam <srinivasan.shanmugam@amd.com> |
drm/radeon: Cleanup radeon/radeon_fence.c Fixes the following: WARNING: Possible repeated word: 'Fences' WARNING: Missing a blank line after declarations WARNING: braces {} are not necessary for single statement blocks WARNING: braces {} are not necessary for any arm of this statement WARNING: Prefer 'unsigned int' to bare use of 'unsigned' WARNING: quoted string split across lines WARNING: Block comments use * on subsequent lines WARNING: Block comments use a trailing */ on a separate line Cc: Guchun Chen <guchun.chen@amd.com> Cc: Christian König <christian.koenig@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: "Pan, Xinhui" <Xinhui.Pan@amd.com> Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com> Reviewed-by: Guchun Chen <guchun.chen@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
#
6091ede9 |
|
16-May-2023 |
Su Hui <suhui@nfschina.com> |
drm/radeon: Remove unnecessary (void*) conversions No need cast (void*) to (struct radeon_device *) or (struct radeon_ring *). Signed-off-by: Su Hui <suhui@nfschina.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
#
d72277b6 |
|
29-Jul-2021 |
Christian König <christian.koenig@amd.com> |
dma-buf: nuke DMA_FENCE_TRACE macros v2 Only the DRM GPU scheduler, radeon and amdgpu where using them and they depend on a non existing config option to actually emit some code. v2: keep the signal path as is for now Signed-off-by: Christian König <christian.koenig@amd.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210818105443.1578-1-christian.koenig@amd.com
|
#
04f61f6c |
|
29-Jul-2021 |
Cai Huoqing <caihuoqing@baidu.com> |
gpu/drm/radeon: Fix typo in comments Remove the repeated word 'the' from comments Signed-off-by: Cai Huoqing <caihuoqing@baidu.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
#
b2ffa2c2 |
|
25-Jun-2021 |
Thomas Zimmermann <tzimmermann@suse.de> |
drm/radeon: Track IRQ state in local device state Replace usage of struct drm_device.irq_enabled with the driver's own state field struct radeon_device.irq.installed. The field in the DRM device structure is considered legacy and should not be used by KMS drivers. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210625082222.3845-4-tzimmermann@suse.de
|
#
519424d7 |
|
21-Jun-2021 |
Bernard Zhao <bernard@vivo.com> |
drm/radeon: delete useless function return values & remove meaningless if(r) check code Function radeon_fence_driver_init always returns success, the function type maybe coule be changed to void. This patch first delete the check of the return value of the function call radeon_fence_driver_init, then, optimise the function declaration and function to void type. Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Bernard Zhao <bernard@vivo.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
#
5b54d679 |
|
17-Feb-2021 |
Nirmoy Das <nirmoy.das@amd.com> |
drm/radeon: do not use drm middle layer for debugfs (v2) Use debugfs API directly instead of drm middle layer. v2: squash in build fix (Alex) Signed-off-by: Nirmoy Das <nirmoy.das@amd.com> Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
#
de1d598b |
|
09-Nov-2020 |
Lee Jones <lee.jones@linaro.org> |
drm/radeon/radeon_fence: Demote some non-conformant kernel-doc headers and fix another Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/radeon/radeon_fence.c:168: warning: Function parameter or member 'wait' not described in 'radeon_fence_check_signaled' drivers/gpu/drm/radeon/radeon_fence.c:168: warning: Function parameter or member 'mode' not described in 'radeon_fence_check_signaled' drivers/gpu/drm/radeon/radeon_fence.c:168: warning: Function parameter or member 'flags' not described in 'radeon_fence_check_signaled' drivers/gpu/drm/radeon/radeon_fence.c:168: warning: Function parameter or member 'key' not described in 'radeon_fence_check_signaled' drivers/gpu/drm/radeon/radeon_fence.c:393: warning: Function parameter or member 'f' not described in 'radeon_fence_enable_signaling' drivers/gpu/drm/radeon/radeon_fence.c:393: warning: Excess function parameter 'fence' description in 'radeon_fence_enable_signaling' drivers/gpu/drm/radeon/radeon_fence.c:1010: warning: Function parameter or member 'm' not described in 'radeon_debugfs_gpu_reset' drivers/gpu/drm/radeon/radeon_fence.c:1010: warning: Function parameter or member 'data' not described in 'radeon_debugfs_gpu_reset' Cc: Alex Deucher <alexander.deucher@amd.com> Cc: "Christian König" <christian.koenig@amd.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Sumit Semwal <sumit.semwal@linaro.org> Cc: Jerome Glisse <glisse@freedesktop.org> Cc: amd-gfx@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org Cc: linux-media@vger.kernel.org Cc: linaro-mm-sig@lists.linaro.org Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
#
e241df69 |
|
01-Jul-2020 |
Tiezhu Yang <yangtiezhu@loongson.cn> |
gpu/drm: Remove debug info about CPU address When I update the latest kernel, I see the following "____ptrval____" boot messages. [ 1.872600] radeon 0000:01:05.0: fence driver on ring 0 use gpu addr 0x0000000048000c00 and cpu addr 0x(____ptrval____) [ 1.879095] radeon 0000:01:05.0: fence driver on ring 5 use gpu addr 0x0000000040056038 and cpu addr 0x(____ptrval____) Both radeon_fence_driver_start_ring() and amdgpu_fence_driver_start_ring() have the similar issue, there exists the following two methods to solve it: (1) Use "%pK" instead of "%p" so that the CPU address can be printed when the kptr_restrict sysctl is set to 1. (2) Just completely drop the CPU address suggested by Christian, because the CPU address was useful in the past, but isn't any more. We now have a debugfs file to read the current fence values. Since the CPU address is not much useful, just remove the debug info about CPU address. Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
#
f9183127 |
|
08-Jun-2019 |
Sam Ravnborg <sam@ravnborg.org> |
drm/radeon: drop use of drmP.h (1/2) Drop use of drmP.h in all .c files named radeon*c. To ease review a little drmP.h removal was divided in two commits. Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Cc: "Christian König" <christian.koenig@amd.com> Cc: "David (ChunMing) Zhou" <David1.Zhou@amd.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20190608080241.4958-7-sam@ravnborg.org
|
#
0e1a351d |
|
08-Jun-2019 |
Sam Ravnborg <sam@ravnborg.org> |
drm/radeon: drop dependency on drm_os_linux.h The drm_os_linux.h header file is deprecated. Drop all uses of symbols from this file. All macros are just opencoded. A few adjustments to include files was required as the obsolete drm_os_linux.h included these headers. Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Cc: "Christian König" <christian.koenig@amd.com> Cc: "David (ChunMing) Zhou" <David1.Zhou@amd.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20190608080241.4958-4-sam@ravnborg.org
|
#
ac6424b9 |
|
19-Jun-2017 |
Ingo Molnar <mingo@kernel.org> |
sched/wait: Rename wait_queue_t => wait_queue_entry_t Rename: wait_queue_t => wait_queue_entry_t 'wait_queue_t' was always a slight misnomer: its name implies that it's a "queue", but in reality it's a queue *entry*. The 'real' queue is the wait queue head, which had to carry the name. Start sorting this out by renaming it to 'wait_queue_entry_t'. This also allows the real structure name 'struct __wait_queue' to lose its double underscore and become 'struct wait_queue_entry', which is the more canonical nomenclature for such data types. Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-kernel@vger.kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
|
#
f54d1867 |
|
25-Oct-2016 |
Chris Wilson <chris@chris-wilson.co.uk> |
dma-buf: Rename struct fence to dma_fence I plan to usurp the short name of struct fence for a core kernel struct, and so I need to rename the specialised fence/timeline for DMA operations to make room. A consensus was reached in https://lists.freedesktop.org/archives/dri-devel/2016-July/113083.html that making clear this fence applies to DMA operations was a good thing. Since then the patch has grown a bit as usage increases, so hopefully it remains a good thing! (v2...: rebase, rerun spatch) v3: Compile on msm, spotted a manual fixup that I broke. v4: Try again for msm, sorry Daniel coccinelle script: @@ @@ - struct fence + struct dma_fence @@ @@ - struct fence_ops + struct dma_fence_ops @@ @@ - struct fence_cb + struct dma_fence_cb @@ @@ - struct fence_array + struct dma_fence_array @@ @@ - enum fence_flag_bits + enum dma_fence_flag_bits @@ @@ ( - fence_init + dma_fence_init | - fence_release + dma_fence_release | - fence_free + dma_fence_free | - fence_get + dma_fence_get | - fence_get_rcu + dma_fence_get_rcu | - fence_put + dma_fence_put | - fence_signal + dma_fence_signal | - fence_signal_locked + dma_fence_signal_locked | - fence_default_wait + dma_fence_default_wait | - fence_add_callback + dma_fence_add_callback | - fence_remove_callback + dma_fence_remove_callback | - fence_enable_sw_signaling + dma_fence_enable_sw_signaling | - fence_is_signaled_locked + dma_fence_is_signaled_locked | - fence_is_signaled + dma_fence_is_signaled | - fence_is_later + dma_fence_is_later | - fence_later + dma_fence_later | - fence_wait_timeout + dma_fence_wait_timeout | - fence_wait_any_timeout + dma_fence_wait_any_timeout | - fence_wait + dma_fence_wait | - fence_context_alloc + dma_fence_context_alloc | - fence_array_create + dma_fence_array_create | - to_fence_array + to_dma_fence_array | - fence_is_array + dma_fence_is_array | - trace_fence_emit + trace_dma_fence_emit | - FENCE_TRACE + DMA_FENCE_TRACE | - FENCE_WARN + DMA_FENCE_WARN | - FENCE_ERR + DMA_FENCE_ERR ) ( ... ) Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Acked-by: Sumit Semwal <sumit.semwal@linaro.org> Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20161025120045.28839-1-chris@chris-wilson.co.uk
|
#
04db4caf |
|
07-Feb-2016 |
Matthew Dawson <matthew@mjdsystems.ca> |
drm/radeon: Avoid double gpu reset by adding a timeout on IB ring tests. When the radeon driver resets a gpu, it attempts to test whether all the rings can successfully handle an IB. If these rings fail to respond, the process will wait forever. Another gpu reset can't happen at this point, as the current reset holds a lock required to do so. Instead, make all the IB tests run with a timeout, so the system can attempt to recover in this case. While this doesn't fix the underlying issue with card resets failing, it gives the system a higher chance of recovering. These timeouts have been confirmed to help both a Tathi and Hawaii card recover after a gpu reset. This also adds a new function, radeon_fence_wait_timeout, that behaves like fence_wait_timeout. It is used instead of fence_wait_timeout as it continues to work during a reset. radeon_fence_wait is changed to be implemented using this function. V2: - Changed the timeout to 1s, as the default 10s from radeon_wait_timeout was too long. A timeout of 100ms was tested and found to be too short. - Changed radeon_fence_wait_timeout to behave more like fence_wait_timeout. Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Matthew Dawson <matthew@mjdsystems.ca> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
#
b24c683a |
|
12-Dec-2015 |
Nicolai Hähnle <nicolai.haehnle@amd.com> |
drm/radeon: only increment sync_seq when a fence is really emitted In the rare situation where the kmalloc fails we're probably screwed anyway, but let's try to be more robust about it. Reviewed-by: Michel Dänzer <michel.daenzer@amd.com> Signed-off-by: Nicolai Hähnle <Nicolai.Haehnle@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
#
b6610101 |
|
03-Mar-2015 |
Maarten Lankhorst <maarten.lankhorst@ubuntu.com> |
drm/radeon: fix wait to actually occur after the signaling callback A normal wait adds to the front of the tail. By doing something similar to fence_default_wait the fence code can run without racing. This is a complete fix for "panic on suspend from KDE with radeon", and a partial fix for "Radeon: System pauses on TAHITI". On tahiti si_irq_set needs to be fixed too, to completely flush the writes before radeon_fence_activity is called in radeon_fence_enable_signaling. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=90741 Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=90861 Signed-off-by: Maarten Lankhorst <maarten.lankhorst@ubuntu.com> Reported-by: Jon Arne Jørgensen <jonjon.arnearne@gmail.com> Reported-and-tested-by: Gustaw Smolarczyk <wielkiegie@gmail.com> Cc: stable@vger.kernel.org (v3.18+) Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
#
ad1a58a4 |
|
19-Nov-2014 |
Christian König <christian.koenig@amd.com> |
drm/radeon: track VM update fences separately Note for each fence if it's a VM page table update or not. This allows us to determine the last VM update in a sync object and so to figure out if we need to flush the TLB or not. Signed-off-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
#
392a250b |
|
24-Sep-2014 |
Maarten Lankhorst <maarten.lankhorst@canonical.com> |
drm/radeon: cope with foreign fences inside the reservation object Not the whole world is a radeon! :-) Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
#
954605ca |
|
09-Jan-2014 |
Maarten Lankhorst <maarten.lankhorst@canonical.com> |
drm/radeon: use common fence implementation for fences, v4 Changes since v1: - Kill the sw interrupt dance, add and use radeon_irq_kms_sw_irq_get_delayed instead. - Change custom wait function, lockdep complained about it. Holding exclusive_lock in the wait function might cause deadlocks. Instead do all the processing in .enable_signaling, and wait on the global fence_queue to pick up gpu resets. - Process all fences in radeon_gpu_reset after reset to close a race with the trylock in enable_signaling. Changes since v2: - Small changes to work with the rewritten lockup recovery patches. Changes since v3: - Call radeon_fence_schedule_check when exclusive_lock cannot be acquired to always cause a wake up. - Reset irqs from hangup check. - Drop reading seqno in the callback, use cached value. - Fix indentation in radeon_fence_default_wait - Add a radeon_test_signaled function, drop a few test_bit calls. - Make to_radeon_fence global. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com> Reviewed-by: Christian König <christian.koenig@amd.com>
|
#
d6d5c5b8 |
|
27-Aug-2014 |
Christian König <christian.koenig@amd.com> |
drm/radeon: drop RADEON_FENCE_SIGNALED_SEQ v2 It's causing issues with VMID handling and comparing the fence value two times actually doesn't make handling faster. v2: rebased on reset changes Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@canonical.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
#
9867d00d |
|
27-Aug-2014 |
Maarten Lankhorst <maarten.lankhorst@canonical.com> |
drm/radeon: add timeout argument to radeon_fence_wait_seq v2 This makes it possible to wait for a specific amount of time, rather than wait until infinity. v2 (chk): rebased on other changes Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com> Signed-off-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
#
0bfa4b41 |
|
27-Aug-2014 |
Christian König <christian.koenig@amd.com> |
drm/radeon: handle lockup in delayed work, v5 v5 (chk): complete rework, start when the first fence is emitted, stop when the last fence is signalled, make it work correctly with GPU resets, cleanup radeon_fence_wait_seq Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com> Signed-off-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
#
eb98c709 |
|
27-Aug-2014 |
Christian König <christian.koenig@amd.com> |
drm/radeon: force fence completion only on problematic rings (v2) Instead of resetting all fence numbers, only reset the number of the problematic ring. Split out from a patch from Maarten Lankhorst <maarten.lankhorst@canonical.com> v2 (agd5f): rebase build fix Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@canonical.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
#
f0d970b4 |
|
27-Aug-2014 |
Christian König <christian.koenig@amd.com> |
drm/radeon: wake up all fences on manual reset Wake up all fences when we manually trigger a reset. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@canonical.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
#
478b6e72 |
|
02-Jun-2014 |
Christian König <christian.koenig@amd.com> |
drm/radeon: add debugfs file to trigger GPU reset Signed-off-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
#
37615527 |
|
18-Feb-2014 |
Christian König <christian.koenig@amd.com> |
drm/radeon: cleanup the fence ring locking code We no longer need to take the ring lock while checking for a gpu lockup, so just cleanup the code. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
|
#
1d784167 |
|
23-Jan-2014 |
Christian König <christian.koenig@amd.com> |
drm/radeon: add ring to fence trace functions Signed-off-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
#
e290b634 |
|
12-Dec-2013 |
Christian König <christian.koenig@amd.com> |
drm/radeon: update fence values in before reporting them Signed-off-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
#
1654b817 |
|
11-Nov-2013 |
Christian König <christian.koenig@amd.com> |
drm/radeon: allow semaphore emission to fail To workaround bugs and/or certain limits it's sometimes useful to fall back to waiting on fences. Signed-off-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
|
#
721529b5 |
|
05-Nov-2013 |
Christian König <christian.koenig@amd.com> |
drm/radeon: fix radeon_fence_wait_empty_locked Don't block forever if there is nothing to wait for. Signed-off-by: Christian König <christian.koenig@amd.com> Tested-by: Rafa? Mi?ecki <zajec5@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
f9eaf9ae |
|
29-Oct-2013 |
Christian König <christian.koenig@amd.com> |
drm/radeon: rework and fix reset detection v2 Stop fiddling with jiffies, always wait for RADEON_FENCE_JIFFIES_TIMEOUT. Consolidate the two wait sequence implementations into just one function. Activate all waiters and remember if the reset was already done instead of trying to reset from only one thread. v2: clear reset flag earlier to avoid timeout in IB test Signed-off-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
#
4ad9c1c7 |
|
05-Aug-2013 |
Christian König <christian.koenig@amd.com> |
drm/radeon: only save UVD bo when we have open handles Otherwise just reinitialize from scratch on resume, and so make it more likely to succeed. Signed-off-by: Christian König <christian.koenig@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
#
9cc2e0e9 |
|
12-Jul-2013 |
Christian König <christian.koenig@amd.com> |
drm/radeon: never unpin UVD bo v3 Changing the UVD BOs offset on suspend/resume doesn't work because the VCPU internally keeps pointers to it. Just keep it always pinned and save the content manually. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=66425 v2: fix compiler warning v3: fix CIK support Note: a version of this patch needs to go to stable. Signed-off-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
#
089920f2 |
|
06-Jun-2013 |
Jerome Glisse <jglisse@redhat.com> |
drm/radeon: fix write back suspend regression with uvd v2 UVD ring can't use scratch thus it does need writeback buffer to keep a valid address or radeon_ring_backup will trigger a kernel fault. It's ok to not unpin the write back buffer on suspend as it leave in gtt and thus does not need eviction. v2: Fix the uvd case. Reported and tracked by Wojtek <wojtask9@wp.pl> Signed-off-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
#
581bc3a9 |
|
24-Apr-2013 |
Christian König <christian.koenig@amd.com> |
drm/radeon: fix scratch reg handling for UVD fence Also init the scratch reg to zero on the UVD ring. This fixes UVD on AGP based cards. Signed-off-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
#
d7c605a2 |
|
13-Apr-2013 |
Christian König <christian.koenig@amd.com> |
drm/radeon: fix alignment of UVD fence Signed-off-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
#
f2ba57b5 |
|
07-Apr-2013 |
Christian König <deathsimple@vodafone.de> |
drm/radeon: UVD bringup v8 Just everything needed to decode videos using UVD. v6: just all the bugfixes and support for R7xx-SI merged in one patch v7: UVD_CGC_GATE is a write only register, lockup detection fix v8: split out VRAM fallback changes, remove support for RV770, add support for HEMLOCK, add buffer sizes checks Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
#
5f8f635e |
|
17-Dec-2012 |
Jerome Glisse <jglisse@redhat.com> |
drm/radeon: avoid deadlock in pm path when waiting for fence radeon_fence_wait_empty_locked should not trigger GPU reset as no place where it's call from would benefit from such thing and it actually lead to a kernel deadlock in case the reset is triggered from pm codepath. Instead force ring completion in place where it makes sense or return early in others. Signed-off-by: Jerome Glisse <jglisse@redhat.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
|
#
76903b96 |
|
17-Dec-2012 |
Jerome Glisse <jglisse@redhat.com> |
drm/radeon: don't leave fence blocked process on failed GPU reset Force all fence to signal if GPU reset failed so no process get stuck on waiting fence. Signed-off-by: Jerome Glisse <jglisse@redhat.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
|
#
86a1881d |
|
12-Dec-2012 |
Jerome Glisse <jglisse@redhat.com> |
drm/radeon: fix fence driver for dma ring when wb is disabled The dma ring can't write to register thus have to write to memory its fence value. This ensure that it doesn't try to use scratch register for dma ring fence driver. Should fix: https://bugs.freedesktop.org/show_bug.cgi?id=58166 Signed-off-by: Jerome Glisse <jglisse@redhat.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
|
#
760285e7 |
|
02-Oct-2012 |
David Howells <dhowells@redhat.com> |
UAPI: (Scripted) Convert #include "..." to #include <path/...> in drivers/gpu/ Convert #include "..." to #include <path/...> in drivers/gpu/. Signed-off-by: David Howells <dhowells@redhat.com> Acked-by: Dave Airlie <airlied@redhat.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Acked-by: Dave Jones <davej@redhat.com>
|
#
4126d5d6 |
|
02-Oct-2012 |
David Howells <dhowells@redhat.com> |
UAPI: (Scripted) Remove redundant DRM UAPI header #inclusions from drivers/gpu/. Remove redundant DRM UAPI header #inclusions from drivers/gpu/. Remove redundant #inclusions of core DRM UAPI headers (drm.h, drm_mode.h and drm_sarea.h). They are now #included via drmP.h and drm_crtc.h via a preceding patch. Without this patch and the patch to make include the UAPI headers from the core headers, after the UAPI split, the DRM C sources cannot find these UAPI headers because the DRM code relies on specific -I flags to make #include "..." work on headers in include/drm/ - but that does not work after the UAPI split without adding more -I flags. Signed-off-by: David Howells <dhowells@redhat.com> Acked-by: Dave Airlie <airlied@redhat.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Acked-by: Dave Jones <davej@redhat.com>
|
#
1109ca09 |
|
31-Aug-2012 |
Lauri Kasanen <cand@gmx.com> |
drm/radeon: Mark all possible functions / structs as static Let's allow GCC to optimize better. This exposed some five unused functions, but this patch doesn't remove them. Signed-off-by: Lauri Kasanen <cand@gmx.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
#
f492c171 |
|
13-Sep-2012 |
Christian König <deathsimple@vodafone.de> |
drm/radeon: make 64bit fences more robust v3 Only increase the higher 32bits if we really detect a wrap around. v2: instead of increasing the higher 32bits just use the higher 32bits from the last emitted fence. v3: also use last emitted fence value as upper limit. The intention of this patch is to make fences as robust as they where before introducing 64bit fences. This is necessary because on older systems it looks like the fence value gets corrupted on initialization. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=51344 Should also fix: https://bugs.freedesktop.org/show_bug.cgi?id=54129 https://bugs.freedesktop.org/show_bug.cgi?id=54662 https://bugzilla.redhat.com/show_bug.cgi?id=846505 https://bugzilla.redhat.com/show_bug.cgi?id=845639 3.5 needs a separate patch due to changes in the fence code. Will send that out separately. Signed-off-by: Christian König <deathsimple@vodafone.de> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
#
d66b7ec2 |
|
17-Jul-2012 |
Alex Deucher <alexander.deucher@amd.com> |
drm/radeon: document radeon_fence.c (v2) Adds documentation to most of the functions in radeon_fence.c v2: address Christian's comments: - split common concept description into it's own comment - fix description of intr parameter - Improve description of -EDEADLK error Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com>
|
#
246fa345 |
|
11-Jul-2012 |
Christian König <deathsimple@vodafone.de> |
drm/radeon: return an error if there is nothing to wait for Otherwise the sa managers out of memory handling doesn't work. Signed-off-by: Christian König <deathsimple@vodafone.de> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
|
#
31be6183 |
|
07-Jul-2012 |
Christian König <deathsimple@vodafone.de> |
drm/radeon: fix fence init after resume Start with last signaled fence number instead of last emitted one. Signed-off-by: Christian König <deathsimple@vodafone.de> Reviewed-by: Jerome Glisse <jglisse@redhat.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
|
#
bf66625e |
|
09-Jul-2012 |
Christian König <deathsimple@vodafone.de> |
drm/radeon: fix fence value access It is possible that radeon_fence_process is called after writeback is disabled for suspend, leading to an invalid read of register 0x0. This fixes a problem for me where the fence value is temporary incremented by 0x100000000 on suspend/resume. Signed-off-by: Christian König <deathsimple@vodafone.de> Reviewed-by: Jerome Glisse <jglisse@redhat.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
|
#
7ecc45e3 |
|
29-Jun-2012 |
Christian König <deathsimple@vodafone.de> |
drm/radeon: add error handling to fence_wait_empty_locked Instead of returning the error handle it directly and while at it fix the comments about the ring lock. Signed-off-by: Christian König <deathsimple@vodafone.de> Reviewed-by: Michel Dänzer <michel.daenzer@amd.com> Reviewed-by: Jerome Glisse <jglisse@redhat.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
|
#
68e250b7 |
|
10-May-2012 |
Christian König <deathsimple@vodafone.de> |
drm/radeon: add infrastructure for advanced ring synchronization v2 v2: BUG_ON not matching rings. Signed-off-by: Christian König <deathsimple@vodafone.de> Reviewed-by: Jerome Glisse <jglisse@redhat.com>
|
#
876dc9f3 |
|
08-May-2012 |
Christian König <deathsimple@vodafone.de> |
drm/radeon: remove radeon_fence_create It is completely unnecessary to create fences before they are emitted, so remove it and a bunch of checks if fences are emitted or not. Signed-off-by: Christian König <deathsimple@vodafone.de> Reviewed-by: Jerome Glisse <jglisse@redhat.com>
|
#
d3029b4e |
|
09-May-2012 |
Dave Airlie <airlied@redhat.com> |
drm/radeon/kms: fix warning on 32-bit in atomic fence printing /ssd/git/drm-core-next/drivers/gpu/drm/radeon/radeon_fence.c: In function ‘radeon_debugfs_fence_info’: /ssd/git/drm-core-next/drivers/gpu/drm/radeon/radeon_fence.c:606:7: warning: format ‘%lx’ expects argument of type ‘long unsigned int’, but argument 3 has type ‘long long int’ [-Wformat] Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
68470ae7 |
|
09-May-2012 |
Jerome Glisse <jglisse@redhat.com> |
drm/radeon: move the semaphore from the fence into the ib It never really belonged there in the first place. Signed-off-by: Christian König <deathsimple@vodafone.de> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
a8c05940 |
|
09-May-2012 |
Jerome Glisse <jglisse@redhat.com> |
drm/radeon: simplify semaphore handling v2 Directly use the suballocator to get small chunks of memory. It's equally fast and doesn't crash when we encounter a GPU reset. v2: rebased on new SA interface. Signed-off-by: Christian König <deathsimple@vodafone.de> Signed-off-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
0085c950 |
|
09-May-2012 |
Jerome Glisse <jglisse@redhat.com> |
drm/radeon: use one wait queue for all rings add fence_wait_any v2 Use one wait queue for all rings. When one ring progress, other likely does to and we are not expecting to have a lot of waiter anyway. Also add a fence_wait_any that will wait until the first fence in the fence array (one fence per ring) is signaled. This allow to wait on all rings. v2: some minor cleanups and improvements. Signed-off-by: Christian König <deathsimple@vodafone.de> Signed-off-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
8a47cc9e |
|
09-May-2012 |
Christian König <deathsimple@vodafone.de> |
drm/radeon: rework locking ring emission mutex in fence deadlock detection v2 Some callers illegal called fence_wait_next/empty while holding the ring emission mutex. So don't relock the mutex in that cases, and move the actual locking into the fence code. v2: Don't try to unlock the mutex if it isn't locked. Signed-off-by: Christian König <deathsimple@vodafone.de> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
3b7a2b24 |
|
09-May-2012 |
Jerome Glisse <jglisse@redhat.com> |
drm/radeon: rework fence handling, drop fence list v7 Using 64bits fence sequence we can directly compare sequence number to know if a fence is signaled or not. Thus the fence list became useless, so does the fence lock that mainly protected the fence list. Things like ring.ready are no longer behind a lock, this should be ok as ring.ready is initialized once and will only change when facing lockup. Worst case is that we return an -EBUSY just after a successfull GPU reset, or we go into wait state instead of returning -EBUSY (thus delaying reporting -EBUSY to fence wait caller). v2: Remove left over comment, force using writeback on cayman and newer, thus not having to suffer from possibly scratch reg exhaustion v3: Rebase on top of change to uint64 fence patch v4: Change DCE5 test to force write back on cayman and newer but also any APU such as PALM or SUMO family v5: Rebase on top of new uint64 fence patch v6: Just break if seq doesn't change any more. Use radeon_fence prefix for all function names. Even if it's now highly optimized, try avoiding polling to often. v7: We should never poll the last_seq from the hardware without waking the sleeping threads, otherwise we might lose events. Signed-off-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Christian König <deathsimple@vodafone.de> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
bb635567 |
|
09-May-2012 |
Jerome Glisse <jglisse@redhat.com> |
drm/radeon: convert fence to uint64_t v4 This convert fence to use uint64_t sequence number intention is to use the fact that uin64_t is big enough that we don't need to care about wrap around. Tested with and without writeback using 0xFFFFF000 as initial fence sequence and thus allowing to test the wrap around from 32bits to 64bits. v2: Add comment about possible race btw CPU & GPU, add comment stressing that we need 2 dword aligned for R600_WB_EVENT_OFFSET Read fence sequenc in reverse order of GPU write them so we mitigate the race btw CPU and GPU. v3: Drop the need for ring to emit the 64bits fence, and just have each ring emit the lower 32bits of the fence sequence. We handle the wrap over 32bits in fence_process. v4: Just a small optimization: Don't reread the last_seq value if loop restarts, since we already know its value anyway. Also start at zero not one for seq value and use pre instead of post increment in emmit, otherwise wait_empty will deadlock. Signed-off-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Christian König <deathsimple@vodafone.de> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
6c6f4783 |
|
02-May-2012 |
Christian König <deathsimple@vodafone.de> |
drm/radeon: rework recursive gpu reset handling Instead of all this humpy pumpy with recursive mutex (which also fixes only halve of the problem) move the actual gpu reset out of the fence code, return -EDEADLK and then reset the gpu in the calling ioctl function. v2: Split removal of radeon_mutex into separate patch. Return -EAGAIN if reset is successful. Signed-off-by: Christian König <deathsimple@vodafone.de> Reviewed-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
bfb9a077 |
|
02-May-2012 |
Christian König <deathsimple@vodafone.de> |
drm/radeon: don't keep list of created fences. It's never used and so practically superfluous. Signed-off-by: Christian König <deathsimple@vodafone.de> Reviewed-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
adea5c27 |
|
02-May-2012 |
Christian König <deathsimple@vodafone.de> |
drm/radeon: rename fence_wait_last to fence_wait_empty As discussed with Michel that name better describes the behavior of this function. Signed-off-by: Christian König <deathsimple@vodafone.de> Reviewed-by: Michel Dänzer <michel.daenzer@amd.com> Reviewed-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
2f6bfe11 |
|
02-May-2012 |
Christian König <deathsimple@vodafone.de> |
drm/radeon: return -ENOENT in fence_wait_next v2 We should signal the caller that we haven't waited at all. v2: only change fence_wait_next not fence_wait_last. Signed-off-by: Christian König <deathsimple@vodafone.de> Reviewed-by: Michel Dänzer <michel.daenzer@amd.com> Reviewed-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
36abacae |
|
02-May-2012 |
Christian König <deathsimple@vodafone.de> |
drm/radeon: rework gpu lockup detection and processing Previusly multiple rings could trigger multiple GPU resets at the same time. Signed-off-by: Christian König <deathsimple@vodafone.de> Reviewed-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
25a9e352 |
|
02-May-2012 |
Christian König <deathsimple@vodafone.de> |
drm/radeon: replace gpu_lockup with ring->ready flag It makes no sense at all to have more than one flag. Signed-off-by: Christian König <deathsimple@vodafone.de> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
312c4a8c |
|
02-May-2012 |
Christian König <deathsimple@vodafone.de> |
drm/radeon: make radeon_gpu_is_lockup a per ring function Different rings have different criteria to test if they are stuck. v2: rebased on current drm-next Signed-off-by: Christian König <deathsimple@vodafone.de> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
40e8c738 |
|
12-Feb-2012 |
Dave Airlie <airlied@redhat.com> |
drm/radeon/kms: drop lock in return path of radeon_fence_count_emitted. Silly bad return path. Reported-and-Tested-by: Mikko Vinni Reviewed-by: Alex Deucher <alexander.deucher@amd.com> CC: stable@vger.kernel.org Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
93504fce |
|
05-Jan-2012 |
Christian König <deathsimple@vodafone.de> |
drm/radeon/kms: Add support for multi-ring sync in CS ioctl (v2) Use semaphores to sync buffers across rings in the CS ioctl. Add a reloc flag to allow userspace to skip sync for buffers. agd5f: port to latest CS ioctl changes. v2: add ring lock/unlock to make sure changes hit the ring. Signed-off-by: Christian König <deathsimple@vodafone.de> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
1b37078b |
|
17-Nov-2011 |
Alex Deucher <alexander.deucher@amd.com> |
drm/radeon/kms: add support for per-ring fence interrupts Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Christian König <deathsimple@vodafone.de> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
30eb77f4 |
|
20-Nov-2011 |
Jerome Glisse <jglisse@redhat.com> |
drm/radeon: precompute fence cpu/gpu addr once v3 Add a start fence driver helper function which will be call once for each ring and will compute cpu/gpu addr for fence depending on wether to use wb buffer or scratch reg. This patch replace initialize fence driver separately which was broken in regard of GPU lockup. The fence list for created, emited, signaled must be initialize once and only from the asic init callback not from the startup call back which is call from the gpu reset. v2: With this in place we no longer need to know the number of rings in fence_driver_init, also writing to the scratch reg before knowing its offset is a bad idea. v3: rebase on top of change to previous patch in the serie Signed-off-by: Christian König <deathsimple@vodafone.de> Signed-off-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
e32eb50d |
|
22-Oct-2011 |
Christian König <deathsimple@vodafone.de> |
drm/radeon: rename struct radeon_cp to radeon_ring That naming seems to make more sense, since we not only want to run PM4 rings with it. Signed-off-by: Christian König <deathsimple@vodafone.de> Reviewed-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
47492a23 |
|
19-Oct-2011 |
Christian König <deathsimple@vodafone.de> |
drm/radeon: add radeon_fence_count_emited function Split counting of emited fences out of power management into a seperate function. Signed-off-by: Christian König <deathsimple@vodafone.de> Reviewed-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
4c87bc26 |
|
19-Oct-2011 |
Christian König <deathsimple@vodafone.de> |
drm/radeon: make some asic pointers per ring Emitting fences, semaphores and ib works differently on different ring, so its is easier to maintain separate functions for each ring. Signed-off-by: Christian König <deathsimple@vodafone.de> Reviewed-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
bf852799 |
|
13-Oct-2011 |
Christian König <deathsimple@vodafone.de> |
drm/radeon: make cp variable an array Replace cp, cp1 and cp2 members with just an array of radeon_cp structs. Signed-off-by: Christian König <deathsimple@vodafone.de> Reviewed-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
7b1f2485 |
|
23-Sep-2011 |
Christian König <deathsimple@vodafone.de> |
drm/radeon: make all functions work with multiple rings. Give all asic and radeon_ring_* functions a radeon_cp parameter, so they know the ring to work with. Signed-off-by: Christian König <deathsimple@vodafone.de> Reviewed-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
7465280c |
|
25-Aug-2011 |
Alex Deucher <alexander.deucher@amd.com> |
drm/radeon/kms: add support for multiple fence queues v2 For supporting multiple CP ring buffers, async DMA engines and UVD. We still need a way to synchronize between engines. v2 initialize unused fence driver ring to avoid issue in suspend/unload Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Christian König <deathsimple@vodafone.de> Reviewed-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
851a6bd9 |
|
24-Oct-2011 |
Christian König <deathsimple@vodafone.de> |
drm/radeon: fix a spelling mistake Better fix it before this obvious typo spreads even more. Signed-off-by: Christian König <deathsimple@vodafone.de> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
19703058 |
|
20-Oct-2011 |
Dave Jones <davej@redhat.com> |
drm/radeon: Lower the severity of the radeon lockup messages. abrt files a lot of bug reports when users get GPU lockups, but there's not really enough context to do anything useful with them. Given the lack of GPU context being dumped, this patch removes the stack trace, so that abrt ignores the messages. Signed-off-by: Dave Jones <davej@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
69932487 |
|
27-Jul-2011 |
Justin P. Mattock <justinmattock@gmail.com> |
treewide: remove extra semicolons from various parts of the kernel This is a resend from the original, changing the title from PATCH to RFC(since this is a review for commit, and I should have put that the first go around). and also removing some of the commit's with ia64 and bash since it is significant. let me know if I might have missed anything etc.. Signed-off-by: Justin P. Mattock <justinmattock@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
60063497 |
|
26-Jul-2011 |
Arun Sharma <asharma@fb.com> |
atomic: use <linux/atomic.h> This allows us to move duplicated code in <asm/atomic.h> (atomic_inc_not_zero() for now) to <linux/atomic.h> Signed-off-by: Arun Sharma <asharma@fb.com> Reviewed-by: Eric Dumazet <eric.dumazet@gmail.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: David Miller <davem@davemloft.net> Cc: Eric Dumazet <eric.dumazet@gmail.com> Acked-by: Mike Frysinger <vapier@gentoo.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
b81157d0 |
|
13-Jun-2011 |
Alex Deucher <alexdeucher@gmail.com> |
drm/radeon/kms: use helper functions for fence read/write The existing code assumed scratch registers in a number of places while in most cases we are be using writeback and events rather than scratch registers. Signed-off-by: Alex Deucher <alexdeucher@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
cdb650a4 |
|
26-Feb-2011 |
Paul Bolle <pebolle@tiscali.nl> |
drm: minor kref_put() nits There's no need to pass kref_put() the address of a function (just the function will do just fine) nor to cast its unused return to void. Signed-off-by: Paul Bolle <pebolle@tiscali.nl> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
dc66b325 |
|
07-Apr-2011 |
Michel Dänzer <daenzer@vmware.com> |
radeon: Fix KMS CP writeback on big endian machines. This is necessary even with PCI(e) GART, and it makes writeback work even with AGP on my PowerBook. Might still be unreliable with older revisions of UniNorth and other AGP bridges though. Signed-off-by: Michel Dänzer <daenzer@vmware.com> Reviewed-by: Alex Deucher <alex.deucher@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
3409fc1b |
|
16-Mar-2011 |
Nicolas Kaiser <nikai@nikai.net> |
radeon: merge list_del()/list_add_tail() to list_move_tail() Merge list_del() + list_add_tail() to list_move_tail(). Signed-off-by: Nicolas Kaiser <nikai@nikai.net> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
99ee7fac |
|
22-Nov-2010 |
Dave Airlie <airlied@redhat.com> |
drm/radeon: add initial tracepoint support. this adds a bo create, and fence seq tracking tracepoints. This is just an initial set to play around with, we should investigate what others we need would be useful. Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
fce7d61b |
|
30-Oct-2010 |
Joe Perches <joe@perches.com> |
drivers/gpu/drm: Update WARN uses Coalesce long formats. Align arguments. Add missing newlines. Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
d0f8a854 |
|
04-Sep-2010 |
Alex Deucher <alexdeucher@gmail.com> |
drm/radeon/kms/r6xx+: use new style fencing (v3) On r6xx+ a newer fence mechanism was implemented to replace the old wait_until plus scratch regs setup. A single EOP event will flush the destination caches, write a fence value, and generate an interrupt. This is the recommended fence mechanism on r6xx+ asics. This requires my previous writeback patch. v2: fix typo that enabled event fence checking on all asics rather than just r6xx+. v3: properly enable EOP interrupts Should fix: https://bugs.freedesktop.org/show_bug.cgi?id=29972 Signed-off-by: Alex Deucher <alexdeucher@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
724c80e1 |
|
27-Aug-2010 |
Alex Deucher <alexdeucher@gmail.com> |
drm/radeon/kms: enable writeback (v2) When writeback is enabled, the GPU shadows writes to certain registers into a buffer in memory. The driver can then read the values from the shadow rather than reading back from the register across the bus. Writeback can be disabled by setting the no_wb module param to 1. On r6xx/r7xx/evergreen, the following registers are shadowed: - CP scratch registers - CP read pointer - IH write pointer On r1xx-rr5xx, the following registers are shadowed: - CP scratch registers - CP read pointer v2: - Combine wb patches for r6xx-evergreen and r1xx-r5xx - Writeback is disabled on AGP boards since it tends to be unreliable on AGP using the gart. - Check radeon_wb_init return values properly. Signed-off-by: Alex Deucher <alexdeucher@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
a1e9ada3 |
|
26-Apr-2010 |
Jerome Glisse <jglisse@redhat.com> |
drm/radeon/kms: R3XX-R4XX fix GPU reset code Previous reset code leaded to computer hard lockup (need to unplug the power too reboot the computer) on various configuration. This patch change the reset code to avoid hard lockup. The GPU reset is failing most of the time but at least user can log in remotely or properly shutdown the computer. Two issues were leading to hard lockup : - Writting to the scratch register lead to hard lockup most likely because the write back mecanism is in fuzy state after GPU lockup. - Resetting the GPU memory controller and not reinitializing it after leaded to hard lockup. We did only reinitialize in case of successfull reset thus unsuccessfull reset quickly leaded to hard lockup. Signed-off-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
90aca4d2 |
|
09-Mar-2010 |
Jerome Glisse <jglisse@redhat.com> |
drm/radeon/kms: simplify & improve GPU reset V2 This simplify and improve GPU reset for R1XX-R6XX hw, it's not 100% reliable here are result: - R1XX/R2XX works bunch of time in a row, sometimes it seems it can work indifinitly - R3XX/R3XX the most unreliable one, sometimes you will be able to reset few times, sometimes not even once - R5XX more reliable than previous hw, seems to work most of the times but once in a while it fails for no obvious reasons (same status than previous reset just no same happy ending) - R6XX/R7XX are lot more reliable with this patch, still it seems that it can fail after a bunch (reset every 2sec for 3hour bring down the GPU & computer) This have been tested on various hw, for some odd reasons i wasn't able to lockup RS480/RS690 (while they use to love locking up). Note that on R1XX-R5XX the cursor will disapear after lockup haven't checked why, switch to console and back to X will restore cursor. Next step is to record the bogus command that leaded to the lockup. V2 Fix r6xx resume path to avoid reinitializing blit module, use the gpu_lockup boolean to avoid entering inifinite waiting loop on fence while reiniting the GPU Signed-off-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
a2d07b74 |
|
09-Mar-2010 |
Jerome Glisse <jglisse@redhat.com> |
drm/radeon/kms: rename gpu_reset to asic_reset Patch rename gpu_reset to asic_reset in prevision of having gpu_reset doing more stuff than just basic asic reset. Signed-off-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
225758d8 |
|
09-Mar-2010 |
Jerome Glisse <jglisse@redhat.com> |
drm/radeon/kms: fence cleanup + more reliable GPU lockup detection V4 This patch cleanup the fence code, it drops the timeout field of fence as the time to complete each IB is unpredictable and shouldn't be bound. The fence cleanup lead to GPU lockup detection improvement, this patch introduce a callback, allowing to do asic specific test for lockup detection. In this patch the CP is use as a first indicator of GPU lockup. If CP doesn't make progress during 1second we assume we are facing a GPU lockup. To avoid overhead of testing GPU lockup frequently due to fence taking time to be signaled we query the lockup callback every 500msec. There is plenty code comment explaining the design & choise inside the code. This have been tested mostly on R3XX/R5XX hw, in normal running destkop (compiz firefox, quake3 running) the lockup callback wasn't call once (1 hour session). Also tested with forcing GPU lockup and lockup was reported after the 1s CP activity timeout. V2 switch to 500ms timeout so GPU lockup get call at least 2 times in less than 2sec. V3 store last jiffies in fence struct so on ERESTART, EBUSY we keep track of how long we already wait for a given fence V4 make sure we got up to date cp read pointer so we don't have false positive Signed-off-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
5a0e3ad6 |
|
24-Mar-2010 |
Tejun Heo <tj@kernel.org> |
include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h percpu.h is included by sched.h and module.h and thus ends up being included when building most .c files. percpu.h includes slab.h which in turn includes gfp.h making everything defined by the two files universally available and complicating inclusion dependencies. percpu.h -> slab.h dependency is about to be removed. Prepare for this change by updating users of gfp and slab facilities include those headers directly instead of assuming availability. As this conversion needs to touch large number of source files, the following script is used as the basis of conversion. http://userweb.kernel.org/~tj/misc/slabh-sweep.py The script does the followings. * Scan files for gfp and slab usages and update includes such that only the necessary includes are there. ie. if only gfp is used, gfp.h, if slab is used, slab.h. * When the script inserts a new include, it looks at the include blocks and try to put the new include such that its order conforms to its surrounding. It's put in the include block which contains core kernel includes, in the same order that the rest are ordered - alphabetical, Christmas tree, rev-Xmas-tree or at the end if there doesn't seem to be any matching order. * If the script can't find a place to put a new include (mostly because the file doesn't have fitting include block), it prints out an error message indicating which .h file needs to be added to the file. The conversion was done in the following steps. 1. The initial automatic conversion of all .c files updated slightly over 4000 files, deleting around 700 includes and adding ~480 gfp.h and ~3000 slab.h inclusions. The script emitted errors for ~400 files. 2. Each error was manually checked. Some didn't need the inclusion, some needed manual addition while adding it to implementation .h or embedding .c file was more appropriate for others. This step added inclusions to around 150 files. 3. The script was run again and the output was compared to the edits from #2 to make sure no file was left behind. 4. Several build tests were done and a couple of problems were fixed. e.g. lib/decompress_*.c used malloc/free() wrappers around slab APIs requiring slab.h to be added manually. 5. The script was run on all .h files but without automatically editing them as sprinkling gfp.h and slab.h inclusions around .h files could easily lead to inclusion dependency hell. Most gfp.h inclusion directives were ignored as stuff from gfp.h was usually wildly available and often used in preprocessor macros. Each slab.h inclusion directive was examined and added manually as necessary. 6. percpu.h was updated not to include slab.h. 7. Build test were done on the following configurations and failures were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my distributed build env didn't work with gcov compiles) and a few more options had to be turned off depending on archs to make things build (like ipr on powerpc/64 which failed due to missing writeq). * x86 and x86_64 UP and SMP allmodconfig and a custom test config. * powerpc and powerpc64 SMP allmodconfig * sparc and sparc64 SMP allmodconfig * ia64 SMP allmodconfig * s390 SMP allmodconfig * alpha SMP allmodconfig * um on x86_64 SMP allmodconfig 8. percpu.h modifications were reverted so that it could be applied as a separate patch and serve as bisection point. Given the fact that I had only a couple of failures from tests on step 6, I'm fairly confident about the coverage of this conversion patch. If there is a breakage, it's likely to be something in one of the arch headers which should be easily discoverable easily on most builds of the specific arch. Signed-off-by: Tejun Heo <tj@kernel.org> Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org> Cc: Ingo Molnar <mingo@redhat.com> Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
|
#
3655d54a |
|
29-Dec-2009 |
Darren Jenkins <darrenrjenkins@gmail.com> |
drm/radeon/radeon_fence.c: move a dereference below the NULL test If a NULL value is possible, the dereference should only occur after the NULL test. Coverity CID: 13334 Signed-off-by: Darren Jenkins <darrenrjenkins@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
0a0c7596 |
|
11-Dec-2009 |
Jerome Glisse <jglisse@redhat.com> |
drm/radeon/kms: Avoid crash when trying to cleanup uninitialized structure Add boolean to record if some part of the driver are initialized or not this allow to avoid a crash when trying to cleanup uninitialized structure members. Signed-off-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
2e7b6f7f |
|
08-Dec-2009 |
Dave Airlie <airlied@redhat.com> |
drm/radeon/kms: fix return value from fence function. We only want to return here for errors, the wait functions return a positive timeout otherwise, which gets back to userspace and causes X to crash here. Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
5cc6fbab |
|
07-Dec-2009 |
Thomas Hellstrom <thellstrom@vmware.com> |
drm/radeon: Remove tests for -ERESTART from the TTM code. Also sets affected TTM calls up to not wait interruptible, since that would cause an in-kernel spin until the TTM call succeeds, since the Radeon code does not return to user-space when a signal is received. Modifies interruptible fence waits to return -ERESTARTSYS rather than -EBUSY when interrupted by a signal, since that's the (yet undocumented) semantics required by the TTM sync object hooks. Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Signed-off-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
1614f8b1 |
|
30-Nov-2009 |
Dave Airlie <airlied@redhat.com> |
drm/radeon/kms: add irq mitigation code for sw interrupt. We really don't need to process every irq that comes in, we only really want to do SW irq processing when we are actually waiting for a fence to pass. I'm not 100% sure this is race free esp on non-MSI systems so it needs some testing. Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
d8f60cfc |
|
01-Dec-2009 |
Alex Deucher <alexdeucher@gmail.com> |
drm/radeon/kms: Add support for interrupts on r6xx/r7xx chips (v3) This enables the use of interrupts on r6xx/r7xx hardware. Interrupts are implemented via a ring buffer. The GPU adds interrupts vectors to the ring and the host reads them off in the interrupt handler. The interrupt controller requires firmware like the CP. This firmware must be installed and accessble to the firmware loader for interrupts to function. MSIs don't seem to work on my RS780. They work fine on all my discrete cards. I'm not sure about other RS780s or RS880s. I've disabled MSIs on RS780 and RS880, but it would probably be worth checking on some other systems. v2 - fix some checkpatch.pl problems; re-read the disp int status reg if we restart the ih; v3 - remove the irq handler if r600_irq_init() fails; remove spinlock in r600_ih_ring_fini(); move ih rb overflow check to r600_get_ih_wptr(); move irq ack to separate function; Signed-off-by: Alex Deucher <alexdeucher@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
cecc6b63 |
|
08-Sep-2009 |
Alex Deucher <alexdeucher@gmail.com> |
drm/radeon/r600: use fence->timeout directly Fixes fence timeouts on r6xx/r7xx. Noticed by taiu on IRC. Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
|
#
c746e205 |
|
07-Sep-2009 |
Dave Airlie <airlied@linux.ie> |
drm/radeon/kms: don't allow ERESTART to hit userspace. the pre-r600 fence code returns ebusy if we get hit by a signal so we should continue to do that. Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
3ce0a23d |
|
07-Sep-2009 |
Jerome Glisse <jglisse@redhat.com> |
drm/radeon/kms: add r600 KMS support This adds the r600 KMS + CS support to the Linux kernel. The r600 TTM support is quite basic and still needs more work esp around using interrupts, but the polled fencing should work okay for now. Also currently TTM is using memcpy to do VRAM moves, the code is here to use a 3D blit to do this, but isn't fully debugged yet. Authors: Alex Deucher <alexdeucher@gmail.com> Dave Airlie <airlied@redhat.com> Jerome Glisse <jglisse@redhat.com> Signed-off-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
3b170c3b |
|
23-Jul-2009 |
Dave Airlie <airlied@redhat.com> |
drm/radeon/kms: allow interruptible waits for objects. Blocking here isn't something the X server mouse appreciates, avoid the block and let userspace retry the waits. libdrm_radeon userspace library is also expecting EBUSY not ERESTART Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
771fe6b9 |
|
05-Jun-2009 |
Jerome Glisse <jglisse@redhat.com> |
drm/radeon: introduce kernel modesetting for radeon hardware Add kernel modesetting support to radeon driver, use the ttm memory manager to manage memory and DRM/GEM to provide userspace API. In order to avoid backward compatibility issue and to allow clean design and code the radeon kernel modesetting use different code path than old radeon/drm driver. When kernel modesetting is enabled the IOCTL of radeon/drm driver are considered as invalid and an error message is printed in the log and they return failure. KMS enabled userspace will use new API to talk with the radeon/drm driver. The new API provide functions to create/destroy/share/mmap buffer object which are then managed by the kernel memory manager (here TTM). In order to submit command to the GPU the userspace provide a buffer holding the command stream, along this buffer userspace have to provide a list of buffer object used by the command stream. The kernel radeon driver will then place buffer in GPU accessible memory and will update command stream to reflect the position of the different buffers. The kernel will also perform security check on command stream provided by the user, we want to catch and forbid any illegal use of the GPU such as DMA into random system memory or into memory not owned by the process supplying the command stream. This part of the code is still incomplete and this why we propose that patch as a staging driver addition, future security might forbid current experimental userspace to run. This code support the following hardware : R1XX,R2XX,R3XX,R4XX,R5XX (radeon up to X1950). Works is underway to provide support for R6XX, R7XX and newer hardware (radeon from HD2XXX to HD4XXX). Authors: Jerome Glisse <jglisse@redhat.com> Dave Airlie <airlied@redhat.com> Alex Deucher <alexdeucher@gmail.com> Signed-off-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Alex Deucher <alexdeucher@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
|