search for: nouveau_dma_init

.../ ret = drm_gem_handle_create(file_priv, chan->notifier_bo->gem, diff --git a/drivers/gpu/drm/nouveau/nouveau_dma.c b/drivers/gpu/drm/nouveau/nouveau_dma.c index 7035536..f1fd3f2 100644 --- a/drivers/gpu/drm/nouveau/nouveau_dma.c +++ b/drivers/gpu/drm/nouveau/nouveau_dma.c @@ -35,6 +35,7 @@ nouveau_dma_init(struct nouveau_channel *chan) struct drm_device *dev = chan->dev; struct drm_nouveau_private *dev_priv = dev->dev_private; struct nouveau_gpuobj *m2mf = NULL; + struct nouveau_gpuobj *nvsw = NULL; int ret, i; /* Create NV_MEMORY_TO_MEMORY_FORMAT for buffer moves */ @@ -47,6 +48,15...

...cept that it gets one NV_PFIFO_INTR_CACHE_ERROR interrupt right after the FIFO is allocated. According to the wiki docs, I need to set NV_MEMORY_TO_MEMORY_FORMAT_NOTIFY_STYLE_WRITE_LE_AWAKEN into the 'notify' field of an object in a channel. Hence, I tried seting a flag to a DMA notifier in nouveau_dma_init(): // seems entry[1] is related to a DMA notifier? nv_wo32(dev, m2mf, 1, NV_MEMORY_TO_MEMORY_FORMAT_NOTIFY_STYLE_WRITE_LE_AWAKEN); I also tried sending some command: // guess this is a very wrong way ;-) BEGIN_RING(chan, NV_MEMORY_TO_MEMORY_FORMAT_NOTIFY, 1); OUT_RING(chan, NV_MEMORY_TO_MEMORY_F...

...ret = drm_gem_handle_create(file_priv, chan->notifier_bo->gem, diff --git a/drivers/gpu/drm/nouveau/nouveau_dma.c b/drivers/gpu/drm/nouveau/nouveau_dma.c index 7035536..7e66cc8 100644 --- a/drivers/gpu/drm/nouveau/nouveau_dma.c +++ b/drivers/gpu/drm/nouveau/nouveau_dma.c @@ -52,6 +52,23 @@ nouveau_dma_init(struct nouveau_channel *chan) if (ret) return ret; + /* Allocate what we need for (simple) cross channel synchronisation. */ + if (dev_priv->card_type >= NV_50) { + struct nouveau_gpuobj *nvsw = NULL; + + ret = nouveau_gpuobj_sw_new(chan, NV50_NVSW, &nvsw); + if (ret) + return...

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

Introduce accessors for TTM buffer object memory that has been mapped into the kernel virtual address space or as IO memory. IO memory needs to be accessed via special accessor functions, not by dereferencing the iomem cookie. The wrappers hide the details of 32-bit access and honour the TTM map type. nv04_crtc_cursor_set() is changed to use the new wrappers. 'cursor' is received from

- Depth and stencil buffers are supposed to be large enough in general. Signed-off-by: Maarten Maathuis <madman2003 at gmail.com> --- drivers/gpu/drm/nouveau/nouveau_bo.c | 9 ++++----- 1 files changed, 4 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c b/drivers/gpu/drm/nouveau/nouveau_bo.c index e342a41..9fc4bd6 100644 ---

...ine.lock, flags); - /* disable the fifo caches */ pfifo->reassign(dev, false); @@ -225,8 +222,6 @@ nouveau_channel_alloc(struct drm_device *dev, struct nouveau_channel **chan_ret, pfifo->reassign(dev, true); - spin_unlock_irqrestore(&dev_priv->engine.lock, flags); - ret = nouveau_dma_init(chan); if (!ret) ret = nouveau_fence_init(chan); @@ -290,7 +285,7 @@ nouveau_channel_free(struct nouveau_channel *chan) if (pgraph->channel(dev) == chan) nouveau_wait_for_idle(dev); - spin_lock_irqsave(&dev_priv->engine.lock, flags); + spin_lock_irqsave(&dev_priv->conte...

Hello, I am kernel engineer working on PV-OPS kernel trying to get it work in Dom0 with an NVidia (NV30 right now) card. But there are issues, such as that the pv-ops kernel has a different understanding of memory (for details check out: http://wiki.xensource.com/xenwiki/XenPVOPSDRM). I've fleshed out most of them (like GART had the wrong phys addresses, ouch!), but the one that I am