similar to: Fixing nouveau for >4k PAGE_SIZE

Op 11-08-13 07:36, Benjamin Herrenschmidt schreef: > On Sun, 2013-08-11 at 10:41 +1000, Benjamin Herrenschmidt wrote: >> Now, to do that, I need a better understanding of the various things >> in there since I'm not familiar with nouveau at all. What I think I've >> figured out is with a few questions, it would be awesome if you could >> answer them so I can have

On Sun, 2013-08-11 at 17:06 +1000, Benjamin Herrenschmidt wrote: > I think I found at least two cases where "12" was used where it should > have been PAGE_SHIFT (basically ttm_mem_reg->num_pages). This > is only the tip of the iceberg, so this isn't a formal patch submission, > but I would appreciate your thought as to whether the below is correct > (and thus

On Sun, 2013-08-11 at 11:02 +0200, Maarten Lankhorst wrote: > > diff --git a/drivers/gpu/drm/nouveau/core/engine/fifo/nv40.c b/drivers/gpu/drm/nouveau/core/engine/fifo/nv40.c > > index 5c7433d..c314a5f 100644 > > --- a/drivers/gpu/drm/nouveau/core/engine/fifo/nv40.c > > +++ b/drivers/gpu/drm/nouveau/core/engine/fifo/nv40.c > > @@ -190,8 +190,8 @@

On Thu, 2013-08-29 at 16:49 +1000, Ben Skeggs wrote: > > Additionally the current code is broken in that the upper layer in > > vm/base.c doesn't increment "pte" by the right amount. > > > > Now, if those two assertions can be made always true: > > > > - Those two functions (map_sg and map_sg_table) never deal with the > > "big"

On Sun, 2013-08-11 at 10:41 +1000, Benjamin Herrenschmidt wrote: > Now, to do that, I need a better understanding of the various things > in there since I'm not familiar with nouveau at all. What I think I've > figured out is with a few questions, it would be awesome if you could > answer them so I can have a shot at fixing it all :-) Ok, a few more questions :-) - in struct

Op 11-08-13 10:04, Benjamin Herrenschmidt schreef: > On Sun, 2013-08-11 at 17:06 +1000, Benjamin Herrenschmidt wrote: > >> I think I found at least two cases where "12" was used where it should >> have been PAGE_SHIFT (basically ttm_mem_reg->num_pages). This >> is only the tip of the iceberg, so this isn't a formal patch submission, >> but I would

On Sun, Aug 11, 2013 at 7:35 PM, Benjamin Herrenschmidt <benh at kernel.crashing.org> wrote: > On Sun, 2013-08-11 at 11:02 +0200, Maarten Lankhorst wrote: > >> > diff --git a/drivers/gpu/drm/nouveau/core/engine/fifo/nv40.c b/drivers/gpu/drm/nouveau/core/engine/fifo/nv40.c >> > index 5c7433d..c314a5f 100644 >> > ---

On Fri, Nov 29, 2013 at 4:01 PM, Benjamin Herrenschmidt <benh at kernel.crashing.org> wrote: > On Thu, 2013-08-29 at 16:49 +1000, Ben Skeggs wrote: > >> > Additionally the current code is broken in that the upper layer in >> > vm/base.c doesn't increment "pte" by the right amount. >> > >> > Now, if those two assertions can be made

Hi, Generally the the imported buffers which has memory type TTM_PL_TT are mapped as small pages probably due to lack of big page allocation. But the platform device which also use memory type TTM_PL_TT, like GK20A, can *allocate* big page though the IOMMU hardware inside the SoC. This is a try to map the imported buffers as big pages in GMMU by the platform IOMMU. With some preparation work to

Page tables on nv50 take 48kB, which can be hard to allocate in one piece. Let's use vmalloc. Signed-off-by: Marcin Slusarz <marcin.slusarz at gmail.com> Cc: stable at vger.kernel.org [3.7+] --- drivers/gpu/drm/nouveau/core/subdev/vm/base.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/nouveau/core/subdev/vm/base.c

move_notify is called by ttm after the the object is idle and about to be destroyed. Clean up the vm list properly in that case. This is not a problem right now, since the list should already be empty, but if it wasn't empty, vm_put was not called which leads to random corruption later. With this fix, nouveau_gem_object_close can be safely changed to a noop, forcing the vm bindings to be

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

On Thu, Aug 22, 2013 at 5:12 PM, Maarten Lankhorst <maarten.lankhorst at canonical.com> wrote: > Op 22-08-13 02:10, Ilia Mirkin schreef: >> The code expects non-VRAM mem nodes to have a pages list. If that's not >> set, it will do a null deref down the line. Warn on that condition and >> return an error. >> >> See

Two questions -- (a) What's the perf impact of doing this? Less work for the GPU MMU but more work for the IOMMU... (b) Would it be a good idea to do this for desktop GPUs that are on CPUs with IOMMUs in them (VT-d and whatever the AMD one is)? Is there some sort of shared API for this stuff that you should be (or are?) using? -ilia On Thu, Apr 16, 2015 at 7:06 AM, Vince Hsu <vinceh

It's a miracle it compiles at all - nv04_vm_priv does not exist anywhere in the tree. Signed-off-by: Marcin Slusarz <marcin.slusarz at gmail.com> --- Noticed when adding types to Nouveau APIs. --- drivers/gpu/drm/nouveau/core/subdev/vm/nv41.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/core/subdev/vm/nv41.c

It's a miracle it compiles at all - nv04_vm_priv does not exist anywhere in the tree. Signed-off-by: Marcin Slusarz <marcin.slusarz at gmail.com> --- v2: rebased on top of nouveau/master --- drivers/gpu/drm/nouveau/core/subdev/vm/nv41.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/core/subdev/vm/nv41.c

The code expects non-VRAM mem nodes to have a pages list. If that's not set, it will do a null deref down the line. Warn on that condition and return an error. See https://bugs.freedesktop.org/show_bug.cgi?id=64774 Reported-by: Pasi K?rkk?inen <pasik at iki.fi> Tested-by: Pasi K?rkk?inen <pasik at iki.fi> Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> Cc: <stable

On Wed, Sep 04, 2013 at 08:59:13AM +0200, Maarten Lankhorst wrote: > > When looking into this bug I noticed that nouveau_bo_vma_add needs to have a check for nvbo->page_shift == vma->vm->vmm->spg_shift, > and only if the check is true it should map the page in TTM_PL_TT. Patch below. > Should probably also be cc'd to stable. > How about this patch? Is it ready to

Hi everyone, I have been studing the VM code in order to come with a better implementation of my fix for large pages usage on GK20A (https://lkml.org/lkml/2014/6/3/375 ). Following some older threads about this code (http://marc.info/?l=dri-devel&m=137618326022935 ) also left me kind of puzzled, and I wonder if we could not simplify and improve things there. It seems like arbitrary

This adds some basic debug information about the internal nouveau state. making it slightly easier to determine which bo belongs to which vm address, as long as that program is still running. Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- diff --git a/drivers/gpu/drm/nouveau/core/include/subdev/vm.h b/drivers/gpu/drm/nouveau/core/include/subdev/vm.h index