Displaying 6 results from an estimated 6 matches for "fifo_access".
2010 Feb 02
2
[PATCH 1/6] drm/nv50: align size of buffer object to the right boundaries.
- In the current situation the padding that is added is dangerous to write to,
userspace could potentially overwrite parts of another bo.
- Depth and stencil buffers are supposed to be large enough in general so the
waste of memory should be acceptable.
- Alternatives are hiding the padding from users or splitting vram into 2
zones.
Signed-off-by: Maarten Maathuis <madman2003 at gmail.com>
2009 Dec 11
5
[PATCH 1/3] drm/nouveau: Pre-G80 tiling support.
...;fb.set_region_tiling = nv10_fb_set_region_tiling;
engine->graph.grclass = nv10_graph_grclass;
engine->graph.init = nv10_graph_init;
engine->graph.takedown = nv10_graph_takedown;
@@ -109,6 +110,7 @@ static int nouveau_init_engine_ptrs(struct drm_device *dev)
engine->graph.fifo_access = nv04_graph_fifo_access;
engine->graph.load_context = nv10_graph_load_context;
engine->graph.unload_context = nv10_graph_unload_context;
+ engine->graph.set_region_tiling = nv10_graph_set_region_tiling;
engine->fifo.channels = 32;
engine->fifo.init = nv10_fifo_init;...
2013 Dec 17
0
[Bug 58378] [NV86] Distorted graphics on NVIDIA GeForce 8400M G after upgrade the kernel to 3.7.0 version
...pens... (i.e. the one with
0x74c1)
FWIW I do remember seeing some PCRYPT-related (and PVP/PBSP-related) errors on
start in the form of MMIO write failures in your log and thinking it odd:
nouveau E[ PBUS][0000:01:00.0] MMIO write of 0x00000010 FAULT at 0x10200c
Which of course is an enable of FIFO_ACCESS... probably pretty important. (See
https://github.com/envytools/envytools/blob/master/rnndb/vdec/vp2/pcrypt2.xml)
But why do you get that error... anyone's guess. If you have the blob
installed, would be interested to know if VDPAU hw decode acceleration works
for H.264 (i.e. things are actuall...
2010 Feb 07
3
[PATCH] drm/nouveau: don't hold spin lock while calling kzalloc with GFP_KERNEL
...nce_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->context_switch_lock, flags);
pgraph->fifo_access(dev, false);
if (pgraph->channel(dev) == chan)
@@ -307,7 +302,7 @@ nouveau_channel_free(struct nouveau_channel *chan)
pfifo->reassign(dev, true);
- spin_unlock_irqrestore(&dev_priv->engine.lock, flags);
+ spin_unlock_irqrestore(&dev_priv->context_switch_lock, flags);...
2010 Jan 02
3
[PATCH/TESTING(all hw)/DISCUSSION] FIFO (minor) create and (major) destroy instabilities on nv50+
Many people using nv50+ hardware are aware of gpu lockups when a fifo
closes under certain conditions. Based on a mmio-trace and some trail
and error testing i've come up with a patch that improves the
situation on my NV96.
This patch needs testing on NV50+ hardware and regression testing on
older hardware, since i did change some of the common codepaths. This
is very much a work in progress,
2009 Dec 26
2
[PATCH 1/3] drm/nouveau: Allocate a per-channel instance of NV_SW.
It will be useful for various synchronization purposes, mostly stolen
from "[PATCH] drm/nv50: synchronize user channel after buffer object
move on kernel channel" by Maarten Maathuis.
Signed-off-by: Francisco Jerez <currojerez at riseup.net>
---
drivers/gpu/drm/nouveau/nouveau_channel.c | 4 +++-
drivers/gpu/drm/nouveau/nouveau_dma.c | 17 +++++++++++++++++