#
39126abc |
|
28-Jan-2024 |
Dave Airlie <airlied@redhat.com> |
nouveau: offload fence uevents work to workqueue This should break the deadlock between the fctx lock and the irq lock. This offloads the processing off the work from the irq into a workqueue. Cc: linux-stable@vger.kernel.org Signed-off-by: Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/576237/
|
#
4d7acc8f |
|
26-Jan-2024 |
Dave Airlie <airlied@redhat.com> |
Revert "nouveau: push event block/allowing out of the fence context" This reverts commit eacabb5462717a52fccbbbba458365a4f5e61f35. This commit causes some regressions in desktop usage, this will reintroduce the original deadlock in DRI_PRIME situations, I've got an idea to fix it by offloading to a workqueue in a different spot, however this code has a race condition where we sometimes miss interrupts so I'd like to fix that as well. Cc: stable@vger.kernel.org Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
eacabb54 |
|
21-Dec-2023 |
Dave Airlie <airlied@gmail.com> |
nouveau: push event block/allowing out of the fence context There is a deadlock between the irq and fctx locks, the irq handling takes irq then fctx lock the fence signalling takes fctx then irq lock This splits the fence signalling path so the code that hits the irq lock is done in a separate work queue. This seems to fix crashes/hangs when using nouveau gsp with i915 primary GPU. Signed-off-by: Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231222043308.3090089-11-airlied@gmail.com
|
#
978474dc |
|
29-Aug-2023 |
Danilo Krummrich <dakr@redhat.com> |
drm/nouveau: fence: fix undefined fence state after emit nouveau_fence_emit() can fail before and after initializing the dma-fence and hence before and after initializing the dma-fence' kref. In order to avoid nouveau_fence_emit() potentially failing before dma-fence initialization pass the channel to nouveau_fence_new() already and perform the required check before even allocating the fence. While at it, restore the original behavior of nouveau_fence_new() and add nouveau_fence_create() for separate (pre-)allocation instead. Always splitting up allocation end emit wasn't a good idea in the first place. Hence, limit it to the places where we actually need to pre-allocate. Fixes: 7f2a0b50b2b2 ("drm/nouveau: fence: separate fence alloc and emit") Signed-off-by: Danilo Krummrich <dakr@redhat.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230829223847.4406-1-dakr@redhat.com
|
#
f124eef7 |
|
04-Aug-2023 |
Danilo Krummrich <dakr@redhat.com> |
drm/nouveau: fence: fail to emit when fence context is killed The new VM_BIND UAPI implementation introduced in subsequent commits will allow asynchronous jobs processing push buffers and emitting fences. If a fence context is killed, e.g. due to a channel fault, jobs which are already queued for execution might still emit new fences. In such a case a job would hang forever. To fix that, fail to emit a new fence on a killed fence context with -ENODEV to unblock the job. Reviewed-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Danilo Krummrich <dakr@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230804182406.5222-9-dakr@redhat.com
|
#
7f2a0b50 |
|
04-Aug-2023 |
Danilo Krummrich <dakr@redhat.com> |
drm/nouveau: fence: separate fence alloc and emit The new (VM_BIND) UAPI exports DMA fences through DRM syncobjs. Hence, in order to emit fences within DMA fence signalling critical sections (e.g. as typically done in the DRM GPU schedulers run_job() callback) we need to separate fence allocation and fence emitting. Reviewed-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Danilo Krummrich <dakr@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230804182406.5222-8-dakr@redhat.com
|
#
8c880fd4 |
|
01-Jun-2022 |
Ben Skeggs <bskeggs@redhat.com> |
drm/nouveau/fifo: expose non-stall intr in host channel event class Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
|
#
ea13e5ab |
|
22-Jan-2020 |
Ben Skeggs <bskeggs@redhat.com> |
drm/nouveau: signal pending fences when channel has been killed Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
#
b7019ac5 |
|
19-Jun-2019 |
Ilia Mirkin <imirkin@alum.mit.edu> |
drm/nouveau: fix bogus GPL-2 license header The bulk SPDX addition made all these files into GPL-2.0 licensed files. However the remainder of the project is MIT-licensed, these files (primarily header files) were simply missing the boiler plate and got caught up in the global update. Fixes: b24413180f5 (License cleanup: add SPDX GPL-2.0 license identifier to files with no license) Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Acked-by: Emil Velikov <emil.l.velikov@gmail.com> Acked-by: Karol Herbst <kherbst@redhat.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
#
fcd6f048 |
|
12-Feb-2019 |
Ben Skeggs <bskeggs@redhat.com> |
drm/nouveau/kms/nv04-nv4x: move a bunch of pre-nv50 page flip code to dispnv04 Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
#
eb47db4f |
|
08-May-2018 |
Ben Skeggs <bskeggs@redhat.com> |
drm/nouveau/fifo: support channel count query Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
#
b2441318 |
|
01-Nov-2017 |
Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
License cleanup: add SPDX GPL-2.0 license identifier to files with no license Many source files in the tree are missing licensing information, which makes it harder for compliance tools to determine the correct license. By default all files without license information are under the default license of the kernel, which is GPL version 2. Update the files which contain no license information with the 'GPL-2.0' SPDX license identifier. The SPDX identifier is a legally binding shorthand, which can be used instead of the full boiler plate text. This patch is based on work done by Thomas Gleixner and Kate Stewart and Philippe Ombredanne. How this work was done: Patches were generated and checked against linux-4.14-rc6 for a subset of the use cases: - file had no licensing information it it. - file was a */uapi/* one with no licensing information in it, - file was a */uapi/* one with existing licensing information, Further patches will be generated in subsequent months to fix up cases where non-standard license headers were used, and references to license had to be inferred by heuristics based on keywords. The analysis to determine which SPDX License Identifier to be applied to a file was done in a spreadsheet of side by side results from of the output of two independent scanners (ScanCode & Windriver) producing SPDX tag:value files created by Philippe Ombredanne. Philippe prepared the base worksheet, and did an initial spot review of a few 1000 files. The 4.13 kernel was the starting point of the analysis with 60,537 files assessed. Kate Stewart did a file by file comparison of the scanner results in the spreadsheet to determine which SPDX license identifier(s) to be applied to the file. She confirmed any determination that was not immediately clear with lawyers working with the Linux Foundation. Criteria used to select files for SPDX license identifier tagging was: - Files considered eligible had to be source code files. - Make and config files were included as candidates if they contained >5 lines of source - File already had some variant of a license header in it (even if <5 lines). All documentation files were explicitly excluded. The following heuristics were used to determine which SPDX license identifiers to apply. - when both scanners couldn't find any license traces, file was considered to have no license information in it, and the top level COPYING file license applied. For non */uapi/* files that summary was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 11139 and resulted in the first patch in this series. If that file was a */uapi/* path one, it was "GPL-2.0 WITH Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 WITH Linux-syscall-note 930 and resulted in the second patch in this series. - if a file had some form of licensing information in it, and was one of the */uapi/* ones, it was denoted with the Linux-syscall-note if any GPL family license was found in the file or had no licensing in it (per prior point). Results summary: SPDX license identifier # files ---------------------------------------------------|------ GPL-2.0 WITH Linux-syscall-note 270 GPL-2.0+ WITH Linux-syscall-note 169 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17 LGPL-2.1+ WITH Linux-syscall-note 15 GPL-1.0+ WITH Linux-syscall-note 14 ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5 LGPL-2.0+ WITH Linux-syscall-note 4 LGPL-2.1 WITH Linux-syscall-note 3 ((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3 ((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1 and that resulted in the third patch in this series. - when the two scanners agreed on the detected license(s), that became the concluded license(s). - when there was disagreement between the two scanners (one detected a license but the other didn't, or they both detected different licenses) a manual inspection of the file occurred. - In most cases a manual inspection of the information in the file resulted in a clear resolution of the license that should apply (and which scanner probably needed to revisit its heuristics). - When it was not immediately clear, the license identifier was confirmed with lawyers working with the Linux Foundation. - If there was any question as to the appropriate license identifier, the file was flagged for further research and to be revisited later in time. In total, over 70 hours of logged manual review was done on the spreadsheet to determine the SPDX license identifiers to apply to the source files by Kate, Philippe, Thomas and, in some cases, confirmation by lawyers working with the Linux Foundation. Kate also obtained a third independent scan of the 4.13 code base from FOSSology, and compared selected files where the other two scanners disagreed against that SPDX file, to see if there was new insights. The Windriver scanner is based on an older version of FOSSology in part, so they are related. Thomas did random spot checks in about 500 files from the spreadsheets for the uapi headers and agreed with SPDX license identifier in the files he inspected. For the non-uapi files Thomas did random spot checks in about 15000 files. In initial set of patches against 4.14-rc6, 3 files were found to have copy/paste license identifier errors, and have been fixed to reflect the correct identifier. Additionally Philippe spent 10 hours this week doing a detailed manual inspection and review of the 12,461 patched files from the initial patch version early this week with: - a full scancode scan run, collecting the matched texts, detected license ids and scores - reviewing anything where there was a license detected (about 500+ files) to ensure that the applied SPDX license was correct - reviewing anything where there was no detection but the patch license was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied SPDX license was correct This produced a worksheet with 20 files needing minor correction. This worksheet was then exported into 3 different .csv files for the different types of files to be modified. These .csv files were then reviewed by Greg. Thomas wrote a script to parse the csv files and add the proper SPDX tag to the file, in the format that the file expected. This script was further refined by Greg based on the output to detect more types of files automatically and to distinguish between header and source .c files (which need different comment types.) Finally Greg ran the script using the .csv files to generate the patches. Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org> Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
10842ba0 |
|
31-Oct-2017 |
Ben Skeggs <bskeggs@redhat.com> |
drm/nouveau: remove unused nouveau_fence_work() Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
#
24e8375b |
|
31-Oct-2017 |
Ben Skeggs <bskeggs@redhat.com> |
drm/nouveau: separate constant-va tracking from nvkm vma structure Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
#
bc3b0c7a |
|
31-Oct-2017 |
Ben Skeggs <bskeggs@redhat.com> |
drm/nouveau: remove unused sysmem fence code Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
#
96692b09 |
|
13-Dec-2016 |
Ben Skeggs <bskeggs@redhat.com> |
drm/nouveau/fence/g84-: protect against concurrent access to semaphore buffers Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
#
e1ef6b42 |
|
04-Nov-2016 |
Ben Skeggs <bskeggs@redhat.com> |
drm/nouveau/kms/nv50: remove code to support non-atomic page flips Made completely unreachable (and broken) by atomic commits. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
#
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
|
#
76bf0db5 |
|
01-Jun-2016 |
Christian König <christian.koenig@amd.com> |
dma-buf/fence: make fence context 64 bit v2 Fence contexts are created on the fly (for example) by the GPU scheduler used in the amdgpu driver as a result of an userspace request. Because of this userspace could in theory force a wrap around of the 32bit context number if it doesn't behave well. Avoid this by increasing the context number to 64bits. This way even when userspace manages to allocate a billion contexts per second it takes more than 500 years for the context number to wrap around. v2: fix printf formats as well. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Acked-by: Sumit Semwal <sumit.semwal@linaro.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1464786612-5010-2-git-send-email-deathsimple@vodafone.de
|
#
898a2b32 |
|
19-Aug-2015 |
Ben Skeggs <bskeggs@redhat.com> |
drm/nouveau/sw: turn flip completion into an event Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
#
be83cd4e |
|
13-Jan-2015 |
Ben Skeggs <bskeggs@redhat.com> |
drm/nouveau: finalise nvkm namespace switch (no binary change) The namespace of NVKM is being changed to nvkm_ instead of nouveau_, which will be used for the DRM part of the driver. This is being done in order to make it very clear as to what part of the driver a given symbol belongs to, and as a minor step towards splitting the DRM driver out to be able to stand on its own (for virt). Because there's already a large amount of churn here anyway, this is as good a time as any to also switch to NVIDIA's device and chipset naming to ease collaboration with them. A comparison of objdump disassemblies proves no code changes. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
#
0ec5f02f |
|
01-Dec-2014 |
Maarten Lankhorst <maarten.lankhorst@canonical.com> |
drm/nouveau: prevent stale fence->channel pointers, and protect with rcu Tested-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
#
15a996bb |
|
29-Sep-2014 |
Maarten Lankhorst <maarten.lankhorst@canonical.com> |
drm/nouveau: assign fence_chan->name correctly Make nouveau_fence_chan refcounted, to make trace_fence_destroy always return the correct name without a race condition. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
|
#
e3be4c23 |
|
16-Sep-2014 |
Maarten Lankhorst <maarten.lankhorst@canonical.com> |
drm/nouveau: specify if interruptible wait is desired in nouveau_fence_sync Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
|
#
809e9447 |
|
09-Apr-2014 |
Maarten Lankhorst <maarten.lankhorst@canonical.com> |
drm/nouveau: use shared fences for readable objects nouveau keeps track in userspace whether a buffer is being written to or being read, but it doesn't use that information. Change this to allow multiple readers on the same bo. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com> Acked-by: Ben Skeggs <bskeggs@redhat.com>
|
#
f2c24b83 |
|
02-Apr-2014 |
Maarten Lankhorst <maarten.lankhorst@canonical.com> |
drm/ttm: flip the switch, and convert to dma_fence Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
|
#
29ba89b2 |
|
09-Jan-2014 |
Maarten Lankhorst <maarten.lankhorst@ubuntu.com> |
drm/nouveau: rework to new fence interface Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com> Acked-by: Ben Skeggs <bskeggs@redhat.com>
|
#
c4c7044f |
|
06-May-2013 |
Ben Skeggs <bskeggs@redhat.com> |
drm/nouveau: delay busy bo vma removal until fence signals As opposed to an explicit wait. Allows userspace to not stall waiting on buffer deletion. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
#
264ce192 |
|
13-Feb-2013 |
Ben Skeggs <bskeggs@redhat.com> |
drm/nv84-/fence: prepare for emit/sync support of sysram sequences Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
#
827520ce |
|
13-Feb-2013 |
Ben Skeggs <bskeggs@redhat.com> |
drm/nouveau/fence: make internal hooks part of the context A step towards being able to provide fences from other engines not connected to PFIFO. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
#
60e5cb79 |
|
13-Feb-2013 |
Ben Skeggs <bskeggs@redhat.com> |
drm/nv17/fence: split from nv10 code Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
#
bba9852f |
|
13-Feb-2013 |
Ben Skeggs <bskeggs@redhat.com> |
drm/nv84-/fence: abstract class emit/sync functions to virt+sequence Now can be used to operate on any buffer mapped into the GPU virtual address and not just the main inter-channel sync buffer. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
#
a34caf78 |
|
13-Feb-2013 |
Ben Skeggs <bskeggs@redhat.com> |
drm/nv84/fence: access fences with full virtual address, not offset Allows most of the code to be shared between nv84/nvc0 implementations, and paves the way for doing emit/sync on non-VRAM buffers (multi-gpu, dma-buf). Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
#
e18c080f |
|
30-Jan-2013 |
Ben Skeggs <bskeggs@redhat.com> |
drm/nouveau/fence/nv84-: put processes to sleep while waiting on fences Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
#
f20ebd03 |
|
25-Dec-2012 |
Marcin Slusarz <marcin.slusarz@gmail.com> |
drm/nv17-50: restore fence buffer on resume Since commit 5e120f6e4b3f35b741c5445dfc755f50128c3c44 "drm/nouveau/fence: convert to exec engine, and improve channel sync" nouveau fence sync implementation for nv17-50 and nvc0+ started to rely on state of fence buffer left by previous sync operation. But as pinned bo's (where fence state is stored) are not saved+restored across suspend/resume, we need to do it manually. nvc0+ was fixed by commit d6ba6d215a538a58f0f0026f0961b0b9125e8042 "drm/nvc0/fence: restore pre-suspend fence buffer context on resume". Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=50121 Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Cc: stable@vger.kernel.org
|
#
ebb945a9 |
|
19-Jul-2012 |
Ben Skeggs <bskeggs@redhat.com> |
drm/nouveau: port all engines to new engine module format This is a HUGE commit, but it's not nearly as bad as it looks - any problems can be isolated to a particular chipset and engine combination. It was simply too difficult to port each one at a time, the compat layers are *already* ridiculous. Most of the changes here are simply to the glue, the process for each of the engine modules was to start with a standard skeleton and copy+paste the old code into the appropriate places, fixing up variable names etc as needed. v2: Marcin Slusarz <marcin.slusarz@gmail.com> - fix find/replace bug in license header v3: Ben Skeggs <bskeggs@redhat.com> - bump indirect pushbuf size to 8KiB, 4KiB barely enough for userspace and left no space for kernel's requirements during GEM pushbuf submission. - fix duplicate assignments noticed by clang v4: Marcin Slusarz <marcin.slusarz@gmail.com> - add sparse annotations to nv04_fifo_pause/nv04_fifo_start - use ioread32_native/iowrite32_native for fifo control registers v5: Ben Skeggs <bskeggs@redhat.com> - rebase on v3.6-rc4, modified to keep copy engine fix intact - nv10/fence: unmap fence bo before destroying - fixed fermi regression when using nvidia gr fuc - fixed typo in supported dma_mask checking Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
#
f589be88 |
|
21-Jul-2012 |
Ben Skeggs <bskeggs@redhat.com> |
drm/nouveau/pageflip: kick flip handling out of engsw and into fence This is all very much a policy thing, and hence will not belong in SW after the rework. engsw now only handles receiving the event to say "can flip now" and makes a callback to perform the actual work. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
#
e193b1d4 |
|
18-Jul-2012 |
Ben Skeggs <bskeggs@redhat.com> |
drm/nouveau/fence: un-port from nouveau_exec_engine interfaces Still the same code, but not an "engine" anymore. The fence code is more of a policy decision rather than exposing mechanisms, so it's not appropriate to port it to the new engine subsystem. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
#
906c033e |
|
04-May-2012 |
Ben Skeggs <bskeggs@redhat.com> |
drm/nouveau/fence: fix a race where fence->channel can disappear Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
#
5e120f6e |
|
29-Apr-2012 |
Ben Skeggs <bskeggs@redhat.com> |
drm/nouveau/fence: convert to exec engine, and improve channel sync Now have a somewhat simpler semaphore sync implementation for nv17:nv84, and a switched to using semaphores as fences on nv84+ and making use of the hardware's >= acquire operation. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
#
d375e7d5 |
|
29-Apr-2012 |
Ben Skeggs <bskeggs@redhat.com> |
drm/nouveau/fence: minor api changes for an upcoming rework Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|