similar to: [PATCH 3/3] nouveau: add vblank methods on newer cards

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

--- drivers/gpu/drm/nouveau/nvd0_display.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nvd0_display.c b/drivers/gpu/drm/nouveau/nvd0_display.c index c486d3c..c50b075 100644 --- a/drivers/gpu/drm/nouveau/nvd0_display.c +++ b/drivers/gpu/drm/nouveau/nvd0_display.c @@ -790,7 +790,7 @@ nvd0_crtc_cursor_move(struct drm_crtc *crtc, int x, int y)

After switcherooing to integrated and starting X, when X fails to start and causes a console switch, we get hit with a hanger (below). Fix by checking if we're already in D3. BUG: soft lockup - CPU#0 stuck for 22s! [Xorg:1703] [<ffffffffa037c538>] nv04_timer_read+0x28/0x70 [nouveau] [<ffffffffa037bfec>] nouveau_timer_wait_eq+0x7c/0xe0 [nouveau] [<ffffffffa03f4f4e>]

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 ) ---

From: Lauri Peltonen <lpeltonen at nvidia.com> Notify interrupt is only used for cyclestats. We can just clear it and avoid an "unknown stat" error that gets printed to dmesg otherwise. 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 | 9 +++++++++ 1 file changed,

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 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

We want to be able to guarantee the location of the allocated buffer object if we're going to be able to reliably allocate the existing framebuffer at startup. Add an argument to do so and pass that through to the ttm core. Signed-off-by: Matthew Garrett <mjg at redhat.com> --- drivers/bcma/main.c | 1 - drivers/gpu/drm/nouveau/nouveau_bo.c | 8 +++++++-

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

Complete migration of nouveau_event_get/_put from add/remove semantics to enable/disable semantics. Introduce nouveau_event_handler_install/_remove interface to add/remove non-local-scope event handlers (ie., those stored in parent containers). This change in semantics makes explicit the handler lifetime, and distinguishes "one-of" event handlers (such as gpio) from "many

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

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,

Revised patch set v2. [PATCH 1/8] drm/nouveau: bo read/write wrappers for nv04_crtc.c [PATCH 2/8] drm/nouveau: use bo accessors for push buffers [PATCH 3/8] drm/nouveau: OUT_RINGp - optimize OUT_RING loops [PATCH 4/8] drm/nv50: proper notifier_bo access in nv50_display_vblank_crtc_handler() [PATCH 5/8] drm/nouveau: access fbcon notifier via bo accessors [PATCH 6/8] drm/nouveau: screen_base and

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 +++

From: Ben Skeggs <bskeggs at redhat.com> Also emits a method to properly bind the class to a subchannel, which was missing previously. The kernel currently doesn't care, but this will break if it ever decides to (ie. to support multiple sw classes). Signed-off-by: Ben Skeggs <bskeggs at redhat.com> --- src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 8 +++++--- 1 file changed,

--- drivers/gpu/drm/nouveau/core/include/subdev/ltcg.h | 7 + drivers/gpu/drm/nouveau/core/subdev/fb/nvc0.c | 55 +++++---- drivers/gpu/drm/nouveau/core/subdev/ltcg/nvc0.c | 129 +++++++++++++++++++- drivers/gpu/drm/nouveau/core/subdev/vm/nvc0.c | 58 +++++++++- 4 files changed, 220 insertions(+), 29 deletions(-) diff --git

Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- drivers/gpu/drm/nouveau/nouveau_connector.h | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.h b/drivers/gpu/drm/nouveau/nouveau_connector.h index 6e399aa..4cefce3 100644 --- a/drivers/gpu/drm/nouveau/nouveau_connector.h +++ b/drivers/gpu/drm/nouveau/nouveau_connector.h @@ -107,7 +107,4

From: Ben Skeggs <bskeggs at redhat.com> This would need to be fixed before NVIF can be switched on, but since we don't use it anyway, just remove it. Signed-off-by: Ben Skeggs <bskeggs at redhat.com> --- src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 8 -------- src/gallium/drivers/nouveau/nvc0/nvc0_screen.h | 1 - 2 files changed, 9 deletions(-) diff --git