Displaying 20 results from an estimated 1000 matches similar to: "[PATCH] drm/nouveau: do not map evicted bo's in nouveau_bo_vma_add"
2013 Nov 12
0
[PATCH 5/7] drm/nouveau: do not map evicted vram buffers in nouveau_bo_vma_add
From: Maarten Lankhorst <maarten.lankhorst at canonical.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com>
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 9ecb874..bb3734d 100644
---
2013 Sep 25
1
[PATCH] drm/nouveau: avoid null deref on bad arguments to nouveau_vma_getmap
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
2013 Sep 04
0
[PATCH] drm/nouveau: avoid null deref on bad arguments to nouveau_vma_getmap
Op 04-09-13 05:41, Ben Skeggs schreef:
> 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
2012 Nov 21
2
[PATCH] drm/nouveau: fix takedown in move_notify
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
2013 Aug 28
0
[PATCH 4/6] drm/nouveau: introduce NOUVEAU_GEM_TILE_WCUS
This flag allows userspace to give the kernel a hint that it should use
a non-snooped resource. To guarantee coherency at all times mappings
into userspace are done write combined, so userspace should avoid
reading back from those resources.
Signed-off-by: Lucas Stach <dev at lynxeye.de>
---
On x86 an optimized userspace can save up on snoop traffic in the
system, on ARM the benefits are
2013 Aug 28
1
[PATCH 4/6] drm/nouveau: introduce NOUVEAU_GEM_TILE_WCUS
On Wed, Aug 28, 2013 at 10:00 AM, Lucas Stach <dev at lynxeye.de> wrote:
> This flag allows userspace to give the kernel a hint that it should use
> a non-snooped resource. To guarantee coherency at all times mappings
> into userspace are done write combined, so userspace should avoid
> reading back from those resources.
Do any other combinations of cached/uncached and
2013 Sep 04
4
[PATCH] drm/nouveau: avoid null deref on bad arguments to nouveau_vma_getmap
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
2013 Aug 11
0
Fixing nouveau for >4k PAGE_SIZE
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
2013 Nov 12
0
[PATCH 2/7] drm/nv50-: untile mmap'd bo's
From: Maarten Lankhorst <maarten.lankhorst at canonical.com>
Map the GART to the bar and use that mapping, to hide all the tiling details from users.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com>
---
drivers/gpu/drm/nouveau/core/subdev/bar/nv50.c | 5 ++++-
drivers/gpu/drm/nouveau/core/subdev/bar/nvc0.c | 5 ++++-
drivers/gpu/drm/nouveau/nouveau_bo.c
2013 Aug 29
0
Fixing nouveau for >4k PAGE_SIZE
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
>> > ---
2013 Sep 02
0
[PATCH] drm/nv50-: fix tiled memory layout checks
nv50_bo_move_m2mf might copy to tiled gart, in which case linear copy is not appropriate.
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 42 ++++++++++++++++++++----------------
1 file changed, 24 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 88f0c45..0daf3f0 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++
2013 Aug 11
2
Fixing nouveau for >4k PAGE_SIZE
Hi folks !
So I've been trying to figure out what it would take to make
nouveau work properly on architectures where PAGE_SIZE isn't
4k such as most ppc64's. An initial patch from Dave fixed a
bogon in nv41.c nv41_vm_map_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:
2013 Aug 11
2
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
2013 Aug 11
2
Fixing nouveau for >4k PAGE_SIZE
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
2013 Aug 11
2
Fixing nouveau for >4k PAGE_SIZE
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 @@
2013 Dec 11
0
Fixing nouveau for >4k PAGE_SIZE
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
2013 Nov 29
2
Fixing nouveau for >4k PAGE_SIZE
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"
2013 Aug 11
0
Fixing nouveau for >4k PAGE_SIZE
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
2013 Nov 12
6
[PATCH 1/7] drm/nouveau: fix m2mf copy to tiled gart
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
2014 Jul 16
1
Questions about the Nouveau VM subsystem
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