search for: nouveau_vm_map

...c b/drivers/gpu/drm/nouveau/core/subdev/bar/nv50.c index 160d27f..9907a25 100644 --- a/drivers/gpu/drm/nouveau/core/subdev/bar/nv50.c +++ b/drivers/gpu/drm/nouveau/core/subdev/bar/nv50.c @@ -67,7 +67,10 @@ nv50_bar_umap(struct nouveau_bar *bar, struct nouveau_mem *mem, if (ret) return ret; - nouveau_vm_map(vma, mem); + if (mem->pages) + nouveau_vm_map_sg(vma, 0, mem->size << 12, mem); + else + nouveau_vm_map(vma, mem); return 0; } diff --git a/drivers/gpu/drm/nouveau/core/subdev/bar/nvc0.c b/drivers/gpu/drm/nouveau/core/subdev/bar/nvc0.c index b2ec741..badd835 100644 --- a/drivers/...

...au_bo.c > index 89b992e..355a1b7 100644 > --- a/drivers/gpu/drm/nouveau/nouveau_bo.c > +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c > @@ -1560,7 +1560,8 @@ nouveau_bo_vma_add(struct nouveau_bo *nvbo, struct nouveau_vm *vm, > > if (nvbo->bo.mem.mem_type == TTM_PL_VRAM) > nouveau_vm_map(vma, nvbo->bo.mem.mm_node); > - else if (nvbo->bo.mem.mem_type == TTM_PL_TT) { > + else if (nvbo->bo.mem.mem_type == TTM_PL_TT && > + nvbo->page_shift == vma->vm->vmm->spg_shift) { > if (node->sg) > nouveau_vm_map_sg_table(vma, 0, size, node);...

From: Maarten Lankhorst <maarten.lankhorst at canonical.com> Commit de7b7d59d54852c introduced tiled GART, but a linear copy is still performed. This may result in errors on eviction, fix it by checking tiling from memtype. Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> Cc: stable at vger.kernel.org #3.10+ --- drivers/gpu/drm/nouveau/nouveau_bo.c | 33

...veau_vma, head); + + nouveau_vm_unmap(vma); + nouveau_vm_put(vma); + list_del(&vma->head); + } + return; + } + list_for_each_entry(vma, &nvbo->vma_list, head) { - if (new_mem && new_mem->mem_type == TTM_PL_VRAM) { + if (new_mem->mem_type == TTM_PL_VRAM) { nouveau_vm_map(vma, new_mem->mm_node); - } else - if (new_mem && new_mem->mem_type == TTM_PL_TT && - nvbo->page_shift == vma->vm->vmm->spg_shift) { + } else if (new_mem->mem_type == TTM_PL_TT && + nvbo->page_shift == vma->vm->vmm->spg_sh...

...t; (nvbo->pin_refcnt ? TTM_PL_FLAG_NO_EVICT : 0); > > pl->placement = nvbo->placements; > @@ -1554,6 +1560,9 @@ nouveau_bo_vma_add(struct nouveau_bo *nvbo, struct nouveau_vm *vm, > if (nvbo->bo.mem.mem_type == TTM_PL_VRAM) > nouveau_vm_map(vma, nvbo->bo.mem.mm_node); > else if (nvbo->bo.mem.mem_type == TTM_PL_TT) { > + if (!(nvbo->valid_caching & TTM_PL_FLAG_CACHED)) > + vma->access |= NV_MEM_ACCESS_NOSNOOP; > + > if (node->sg) >...

...ap_sg() which was trying to handle the case at that low level, but this isn't enough, and after a bit of digging, I also think that's not the right approach: So, from what I can tell, subdev/vm/base.c is not clean vs. PAGE_SIZE in a number of places unless I'm mistaken. For example, in nouveau_vm_map_sg_table(), something like that: sglen = sg_dma_len(sg) >> PAGE_SHIFT; end = pte + sglen; Seems to imply an assumption here that the "pte" is in multiple of PAGE_SHIFT, but afaik, it's not. So further down, we do: for (m = 0; m < len; m++) { dma_addr_t addr = sg_...

...ew() will set it to whatever page_shift the BO has. I *thought* it should indicate the size and alignment of the pages described in the nouveau_mem object. Is this definition correct? In that case, shouldn't the memory allocator be the one that sets that field, instead of the callers? - In nouveau_vm_map*(), why are we using vma->node->type to decide whether to use the small or big pages table? It seems like this should rather be decided by mem->page_shift, and more generally by how contiguous the physical memory is, in order to maximize large pages use whenever possible. Right now the...

...t;> straightforward way to avoid a null deref that you see happens in the >> bug. I haven't figured out the root cause of this, but it's getting >> well into the "I have no idea how TTM works" space. However this seems >> like a bit of defensive programming -- nouveau_vm_map_sg will pass >> node->pages as a list down, which will be dereferenced by >> nvc0_vm_map_sg. Perhaps the other arguments should make that >> dereferencing not happen, but it definitely was happening here, as you >> can see in the bug. >> >> Ben/Maarten, I'...

...M_PL_MASK_CACHING | + uint32_t flags = nvbo->valid_caching | (nvbo->pin_refcnt ? TTM_PL_FLAG_NO_EVICT : 0); pl->placement = nvbo->placements; @@ -1554,6 +1560,9 @@ nouveau_bo_vma_add(struct nouveau_bo *nvbo, struct nouveau_vm *vm, if (nvbo->bo.mem.mem_type == TTM_PL_VRAM) nouveau_vm_map(vma, nvbo->bo.mem.mm_node); else if (nvbo->bo.mem.mem_type == TTM_PL_TT) { + if (!(nvbo->valid_caching & TTM_PL_FLAG_CACHED)) + vma->access |= NV_MEM_ACCESS_NOSNOOP; + if (node->sg) nouveau_vm_map_sg_table(vma, 0, size, node); else diff --git a/drivers/gpu/drm/nouv...

...vers/gpu/drm/nouveau/nouveau_bo.c b/drivers/gpu/drm/nouveau/nouveau_bo.c --- a/drivers/gpu/drm/nouveau/nouveau_bo.c +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c @@ -1551,7 +1579,8 @@ nouveau_bo_vma_add(struct nouveau_bo *nvbo, struct nouveau_vm *vm, if (nvbo->bo.mem.mem_type == TTM_PL_VRAM) nouveau_vm_map(vma, nvbo->bo.mem.mm_node); - else if (nvbo->bo.mem.mem_type == TTM_PL_TT) { + else if (nvbo->bo.mem.mem_type == TTM_PL_TT && + nvbo->page_shift == vma->vm->vmm->spg_shift) { if (node->sg) nouveau_vm_map_sg_table(vma, 0, size, node); else

...o.c b/drivers/gpu/drm/nouveau/nouveau_bo.c index 9ecb874..bb3734d 100644 --- a/drivers/gpu/drm/nouveau/nouveau_bo.c +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c @@ -1549,7 +1549,8 @@ nouveau_bo_vma_add(struct nouveau_bo *nvbo, struct nouveau_vm *vm, if (nvbo->bo.mem.mem_type == TTM_PL_VRAM) nouveau_vm_map(vma, nvbo->bo.mem.mm_node); - else if (nvbo->bo.mem.mem_type == TTM_PL_TT) { + else if (nvbo->bo.mem.mem_type == TTM_PL_TT && + nvbo->page_shift == vma->vm->vmm->spg_shift) { if (node->sg) nouveau_vm_map_sg_table(vma, 0, size, node); else -- 1.8.4

...+ if (!new_mem || + old_mem->mem_type == TTM_PL_VRAM || + (old_mem->mem_type == TTM_PL_TT && + nvbo->page_shift == vma->vm->vmm->spg_shift)) + nouveau_vm_unmap(vma); + + if (!new_mem) + continue; + + if (new_mem->mem_type == TTM_PL_VRAM) { nouveau_vm_map(vma, new_mem->mm_node); } else if (new_mem && new_mem->mem_type == TTM_PL_TT && @@ -1185,8 +1193,6 @@ nouveau_bo_move_ntfy(struct ttm_buffer_object *bo, struct ttm_mem_reg *new_mem) nouveau_vm_map_sg(vma, 0, new_mem-> num_pages << PAGE_SHIFT,...

...ghtforward way to avoid a null deref that you see happens in the >>> bug. I haven't figured out the root cause of this, but it's getting >>> well into the "I have no idea how TTM works" space. However this seems >>> like a bit of defensive programming -- nouveau_vm_map_sg will pass >>> node->pages as a list down, which will be dereferenced by >>> nvc0_vm_map_sg. Perhaps the other arguments should make that >>> dereferencing not happen, but it definitely was happening here, as you >>> can see in the bug. >>> >>...

...ct nouveau_mm_node, what unit are "offset" and "length" ? They *seem* to be hard wired to be in units of 4k (regardless of either of system page size) which I assume means card small page size, but "offset" is in bytes ? At least according to my parsing of the code in nouveau_vm_map_at(). The big question then is whether that represents card address space or system address space... I assume the former right ? So a function like nouveau_vm_map_at() is solely concerned with mapping a piece of card address space in the card VM and thus shouldn't be concerned by the system PA...

...<<12, which is the smallest unit a card can address. > They *seem* to be hard wired to be in units of 4k (regardless of either > of system page size) which I assume means card small page size, but > "offset" is in bytes ? At least according to my parsing of the code in > nouveau_vm_map_at(). Correct. > The big question then is whether that represents card address space or > system address space... I assume the former right ? So a function like > nouveau_vm_map_at() is solely concerned with mapping a piece of card > address space in the card VM and thus shouldn't b...

This is the first set of patches to make Nouveau work on Tegra. Those are only the obvious correctness fixes, a lot of optimization work remains to be done, but at least it's enough to get accel working and let the machine survive a piglit run. A new BO flag is introduced to allow userspace to hint the kernel about possible optimizations. Lucas Stach (6): drm/ttm: recognize ARM arch in

https://bugs.freedesktop.org/show_bug.cgi?id=70927 Priority: medium Bug ID: 70927 Assignee: nouveau at lists.freedesktop.org Summary: nv50_instobj_wr32 kernel panic Severity: normal Classification: Unclassified OS: Linux (All) Reporter: antoniovazquezblanco at gmail.com Hardware: x86-64 (AMD64)

.../0x30 [nouveau] [ 402.177930] [<ffffffffa00ebf89>] _nouveau_gpuobj_rd32+0x29/0x30 [nouveau] [ 402.177960] [<ffffffffa0130551>] nv44_vm_fill+0x91/0x230 [nouveau] [ 402.177990] [<ffffffffa013089e>] nv44_vm_map_sg+0x1ae/0x1d0 [nouveau] [ 402.178020] [<ffffffffa012f507>] nouveau_vm_map+0x287/0x3d0 [nouveau] [ 402.178026] [<ffffffff811ca7f7>] ? __kmalloc+0x1f7/0x240 [ 402.178039] [<ffffffffa005f3a2>] ? ttm_dma_tt_init+0xe2/0x110 [ttm] [ 402.178077] [<ffffffffa0173c0e>] nv04_sgdma_bind+0x4e/0x80 [nouveau] [ 402.178087] [<ffffffffa005ecaf>] ttm_tt_bin...