summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/nouveau/nouveau_mm.h
AgeCommit message (Collapse)AuthorFilesLines
2012-10-03drm/nouveau: restructure source tree, split core from drm implementationBen Skeggs1-67/+0
Future work will be headed in the way of separating the policy supplied by the nouveau drm module from the mechanisms provided by the driver core. There will be a couple of major classes (subdev, engine) of driver modules that have clearly defined tasks, and the further directory structure change is to reflect this. No code changes here whatsoever, aside from fixing up a couple of include file pathnames. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2011-09-20drm/nouveau: allow a nouveau_mm to be created with holesBen Skeggs1-0/+1
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2011-09-20drm/nouveau: embed nouveau_mmBen Skeggs1-2/+2
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2011-06-23drm/nouveau: rework vram init/fini ordering a littleBen Skeggs1-0/+1
Commit "drm/nouveau: add some debug output if nouveau_mm busy at destroy time" revealed an issue where vram mm takedown would actually fail due to there still being nodes present, causing nouveau to leak a small amount of memory on module unload. This splits TTM/nouveau_mm a bit more cleanly and ensures nouveau_mm fini isn't done until all gpuobjs are also destroyed. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2011-02-24drm/nouveau: rename nouveau_vram to nouveau_memBen Skeggs1-3/+3
This structure will also be used for GART in the near future. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2011-01-17drm/nouveau: greatly simplify mm, killing some bugs in the processBen Skeggs1-3/+1
Reviewed-by: Francisco Jerez <currojerez@riseup.net> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2010-12-21drm/nvc0: initial vm implementation, use for bar1/bar3 managementBen Skeggs1-0/+5
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2010-12-08drm/nouveau: kick vram functions out into an "engine"Ben Skeggs1-0/+1
NVC0 will be able to share some of nv50's paths this way. This also makes it the card-specific vram code responsible for deciding if a given set of tile_flags is valid, rather than duplicating the allowed types in nv50_vram.c and nouveau_gem.c Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2010-12-08drm/nv50: implement custom vram mmBen Skeggs1-0/+61
This is required on nv50 as we need to be able to have more precise control over physical VRAM allocations to avoid buffer corruption when using buffers of mixed memory types. This removes some nasty overallocation/alignment that we were previously using to "control" this problem. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>