similar to: [PATCH] gr/gf100: Clear notify interrupt

From: Lauri Peltonen <lpeltonen at nvidia.com> Other methods in this file suggest this is the correct way to retrieve the engine pointer. Signed-off-by: Lauri Peltonen <lpeltonen at nvidia.com> Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> --- drm/nouveau/nvkm/engine/gr/gf100.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

The inst variable (and thus engctx) will not be properly populated for pre-NV44 cards. The dma setter method didn't need it anyways, so call it directly instead of the nv_call indirection. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- Tested on NV42. Ben, I'm going to guess that you hate this patch, since it gets rid of the beautiful nv_call stuff. However I wasn't

On Fri, Sep 26, 2014 at 01:00:12PM +0300, Lauri Peltonen wrote: > Allow user space to provide an explicit sync fence fd when exporting > a dma-buf from gem handle. The fence will be stored as the explicit > fence to the reservation object. > > Signed-off-by: Lauri Peltonen <lpeltonen at nvidia.com> All existing userspace treats dma_bufs as long-lived objects. Well, all the

Add a flag NVOBJ_FLAG_CREAT_EXCL, which will make sure that only 1 engctx will be created. This removes the need of having multiple Fixes the following lockdep splat: ============================================= [ INFO: possible recursive locking detected ] 3.8.0-rc6-ninja+ #1 Not tainted --------------------------------------------- modprobe/585 is trying to acquire lock:

Full piglit run with this patch: http://people.freedesktop.org/~mslusarz/chan_owners.txt This patch covers only a small subset of all error messages, so: Not-yet-signed-off-by: Marcin Slusarz <marcin.slusarz at gmail.com> Comments? Ideas? (This commit depends on this one: http://people.freedesktop.org/~mslusarz/0001-drm-nouveau-split-fifo-interrupt-handler.patch ) ---

Allow the software channel to be created now, since methods for vblanking have been implemented. The instmem flush seems to be needed on fermi to prevent a race, but I enabled it on earlier cards too since they seem to be susceptible to the same race. Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- drivers/gpu/drm/nouveau/nouveau_abi16.c | 9 ----

Allow user space to provide an explicit sync fence fd when exporting a dma-buf from gem handle. The fence will be stored as the explicit fence to the reservation object. Signed-off-by: Lauri Peltonen <lpeltonen at nvidia.com> --- drivers/gpu/drm/drm_prime.c | 41 +++++++++++++++++++++++++++++++++-------- include/uapi/drm/drm.h | 9 ++++++++- 2 files changed, 41 insertions(+), 9

On Mon, Jun 3, 2013 at 5:02 AM, Ilia Mirkin <imirkin at alum.mit.edu> wrote: > These chipsets include the VP2 engine which is composed of a bitstream > processor (BSP) that decodes H.264 and a video processor (VP) which can > do iDCT/mo-comp/etc for MPEG1/2, H.264, and VC-1. Both of these are > driven by separate xtensa chips embedded in the hardware. This patch > provides the

Modify sync_fence_create to accept an array of 'struct fence' objects. This will allow drm drivers to create sync_fence objects and pass sync fd's between user space with minimal modifications, without ever creating sync_timeline or sync_pt objects, and without implementing the sync_timeline_ops interface. Modify the sync driver debug code to not assume that every 'struct

These chipsets include the VP2 engine which is composed of a bitstream processor (BSP) that decodes H.264 and a video processor (VP) which can do iDCT/mo-comp/etc for MPEG1/2, H.264, and VC-1. Both of these are driven by separate xtensa chips embedded in the hardware. This patch provides the mechanism to load the kernel for the xtensa chips and provide the necessary interactions to do the rest of

For NV98+, BSP/VP/PPP are all FUC-based engines. Hook them all up in the same way as NVC0, but with a couple of different values. Also make sure that the PPP engine is handled in the fifo/mc/vm. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- It seems like VP4.0 is basically working here... only mpeg2/vc1 work, but I'm pretty sure that's just a user-side issue. My guess is

From: Thierry Reding <treding at nvidia.com> Add a new nouveau_pushbuf_kick_fence() function that takes and emits a sync fence FD. The fence FD can be waited on, or merged with other fence FDs, or passed back to the kernel as a prerequisite for a subsequent HW operation. Based heavily on work by Lauri Peltonen <lpeltonen at nvidia.com> Signed-off-by: Thierry Reding <treding at

Do not attach fences automatically to buffers that are marked for explicit synchronization. Signed-off-by: Lauri Peltonen <lpeltonen at nvidia.com> --- drm/nouveau_bo.c | 8 ++++---- drm/nouveau_bo.h | 4 ++-- drm/nouveau_drm.c | 1 + drm/nouveau_gem.c | 47 +++++++++++++++++++++++++++++++++++++++------- drm/nouveau_gem.h | 6 ++++--

These chipsets include the VP2 engine which is composed of a bitstream processor (BSP) that decodes H.264 and a video processor (VP) which can do iDCT/mo-comp/etc for MPEG1/2, H.264, and VC-1. Both of these are driven by separate xtensa chips embedded in the hardware. This patch provides the mechanism to load the kernel for the xtensa chips and provide the necessary interactions to do the rest of

On Mon, May 5, 2014 at 4:48 AM, Sergei Antonov <saproj at gmail.com> wrote: > The following commit from about a year ago removed nouveau_dp_dpms() which > did steps required to suspend and resume a monitor connected via DisplayPort. > > commit 0a0afd282fd715dd63d64b243299a64da14f8e8d > Author: Ben Skeggs <bskeggs at redhat.com> > Date: Mon Feb 18

Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- drivers/gpu/drm/nouveau/core/engine/mpeg/nv31.c | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/drivers/gpu/drm/nouveau/core/engine/mpeg/nv31.c b/drivers/gpu/drm/nouveau/core/engine/mpeg/nv31.c index c190043..5c54aa1 100644 --- a/drivers/gpu/drm/nouveau/core/engine/mpeg/nv31.c +++

Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> Fixes: 590801c1a3 ("drm/nouveau/mpeg: remove dependence on namedb/engctx lookup") Cc: stable at vger.kernel.org # v4.3+ --- This is just a nice-to-have, as it only affects an error print afterwards. drivers/gpu/drm/nouveau/nvkm/engine/mpeg/nv31.c | 2 +- drivers/gpu/drm/nouveau/nvkm/engine/mpeg/nv44.c | 2 +- 2 files changed,

In this case, no class is available but the bind methods is sent too, so use it to keep track of what channel is 'bound' and find the software class id from it. Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- calim can I get a tested-by? drivers/gpu/drm/nouveau/nouveau_software.h | 1 + drivers/gpu/drm/nouveau/nvc0_software.c | 35

On 5 May 2014 01:43, Ben Skeggs <skeggsb at gmail.com> wrote: > On Mon, May 5, 2014 at 4:48 AM, Sergei Antonov <saproj at gmail.com> wrote: >> The following commit from about a year ago removed nouveau_dp_dpms() which >> did steps required to suspend and resume a monitor connected via DisplayPort. >> >> commit 0a0afd282fd715dd63d64b243299a64da14f8e8d

The following commit from about a year ago removed nouveau_dp_dpms() which did steps required to suspend and resume a monitor connected via DisplayPort. commit 0a0afd282fd715dd63d64b243299a64da14f8e8d Author: Ben Skeggs <bskeggs at redhat.com> Date: Mon Feb 18 23:17:53 2013 -0500 drm/nv50-/disp: move DP link training to core and train from supervisor My computer with