similar to: [PATCH]

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

Op 04-09-13 03:24, Ben Skeggs schreef: > On Mon, Jul 15, 2013 at 6:39 PM, Maarten Lankhorst > <maarten.lankhorst at canonical.com> wrote: >> Op 15-07-13 08:05, Ben Skeggs schreef: >>> On Fri, Jul 12, 2013 at 10:45 PM, Maarten Lankhorst >>> <maarten.lankhorst at canonical.com> wrote: >>>> I have no idea what this bogus restriction on placement

Op 04-09-13 05:34, Ben Skeggs schreef: > On Tue, Sep 3, 2013 at 12:31 AM, Maarten Lankhorst > <maarten.lankhorst at canonical.com> wrote: >> There are a lot of places that allocate multiples of 1000, >> but do not set alignment correctly and still require this >> alignment implicitly or explicitly. > This is wrong. Where are the places you think you need this?

Sort of fixes mmiotrace for me again, I could sear I sent a similar patch before the rework to event interface, so I guess it got reintroduced. Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- diff --git a/drivers/gpu/drm/nouveau/core/engine/disp/nv50.c b/drivers/gpu/drm/nouveau/core/engine/disp/nv50.c index 7e3875d..35e526b 100644 ---

I don't see why the display engine would need write access to the entirety of vram, when read-only access is enough. Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- drivers/gpu/drm/nouveau/nv50_display.c | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nv50_display.c

On Mon, Jul 15, 2013 at 6:39 PM, Maarten Lankhorst <maarten.lankhorst at canonical.com> wrote: > Op 15-07-13 08:05, Ben Skeggs schreef: >> On Fri, Jul 12, 2013 at 10:45 PM, Maarten Lankhorst >> <maarten.lankhorst at canonical.com> wrote: >>> I have no idea what this bogus restriction on placement is, but it breaks decoding 1080p >>> VDPAU at boot speed.

Op 15-07-13 08:05, Ben Skeggs schreef: > On Fri, Jul 12, 2013 at 10:45 PM, Maarten Lankhorst > <maarten.lankhorst at canonical.com> wrote: >> I have no idea what this bogus restriction on placement is, but it breaks decoding 1080p >> VDPAU at boot speed. With this patch applied I only need to bump the vdec clock to >> get real-time 1080p decoding. It prevents a lot of

If init doesn't run then disp->outp might not be initialized, resulting in an oops. Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- diff --git a/drivers/gpu/drm/nouveau/core/engine/disp/base.c b/drivers/gpu/drm/nouveau/core/engine/disp/base.c index c41f656abe64..9c38c5e40500 100644 --- a/drivers/gpu/drm/nouveau/core/engine/disp/base.c +++

This increases the chance slightly that recovery from lockup can happen succesfully. Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- drivers/gpu/drm/nouveau/nv84_fence.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/nv84_fence.c b/drivers/gpu/drm/nouveau/nv84_fence.c index 2cf0ade..daf4b18 100644 ---

Op 30-07-13 04:42, Ben Skeggs schreef: > On Tue, Jul 23, 2013 at 11:43 PM, Maarten Lankhorst > <maarten.lankhorst at canonical.com> wrote: >> Sort of fixes mmiotrace for me again, I could sear I sent a similar patch before >> the rework to event interface, so I guess it got reintroduced. > I don't know how/why you think this fixes anything. The interrupt >

I have no idea what this bogus restriction on placement is, but it breaks decoding 1080p VDPAU at boot speed. With this patch applied I only need to bump the vdec clock to get real-time 1080p decoding. It prevents a lot of VRAM <-> VRAM buffer moves. Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c

I was getting a order 4 allocation failure from kmalloc when testing some game after a few days uptime with some suspend/resumes. For big allocations vmalloc should be used instead. Also limit size more aggressively to 256 KiB. Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- drivers/gpu/drm/nouveau/nouveau_gem.c | 30 +++++++++++++++++++++++------- 1 file

Seems to make suspend slightly more reliable on my system. Cc: stable at vger.kernel.org [3.7+] Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c b/drivers/gpu/drm/nouveau/nouveau_drm.c index b6bdc9f..5032c31 100644 --- a/drivers/gpu/drm/nouveau/nouveau_drm.c +++ b/drivers/gpu/drm/nouveau/nouveau_drm.c @@ -464,6

Most graphics cards nowadays have a multiple of this limit as their vram, so limiting GART doesn't seem to make much sense. Signed-off-by: Maarten >Lnkhorst <maarten.lankhorst at canonical.com> --- diff --git a/drivers/gpu/drm/nouveau/nouveau_ttm.c b/drivers/gpu/drm/nouveau/nouveau_ttm.c index 3a5e19a..41ddecd 100644 --- a/drivers/gpu/drm/nouveau/nouveau_ttm.c +++

In the autumn and winter it's considered bad form to set power state to D3cold, it might cause the device to freeze to death. This is also the case in the other seasons, so any device in the southern hemisphere is affected too. D3cold is not a valid state in a call to pci_set_power_state, only up to D3hot is allowed. Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com>

Some registers were not initialized in init, this causes them to be uninitialized after suspend. Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- diff --git a/drivers/gpu/drm/nouveau/core/subdev/ltcg/nvc0.c b/drivers/gpu/drm/nouveau/core/subdev/ltcg/nvc0.c index bcca883..7288940 100644 --- a/drivers/gpu/drm/nouveau/core/subdev/ltcg/nvc0.c +++

It's my megabyte, I want to use it! At this point in init vbios is copied over already, so there's no reason it cannot used to hold other data now. Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- diff --git a/drivers/gpu/drm/nouveau/core/subdev/fb/ramnvc0.c b/drivers/gpu/drm/nouveau/core/subdev/fb/ramnvc0.c index cf97c4d..507d35d 100644 ---

Commit c0077061e7ea accidentally inverted the logic for nouveau_acpi_edid, causing it to only show a connector as connected when the edid could not be retrieved with acpi. Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c b/drivers/gpu/drm/nouveau/nouveau_connector.c index 9a6e2cb..d3595b2 100644 ---

There are a lot of places that allocate multiples of 1000, but do not set alignment correctly and still require this alignment implicitly or explicitly. --- drivers/gpu/drm/nouveau/core/core/gpuobj.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/drivers/gpu/drm/nouveau/core/core/gpuobj.c b/drivers/gpu/drm/nouveau/core/core/gpuobj.c index 7595506..7bcae1d 100644 ---

Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- Oops, fixed to apply this time.. diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c b/drivers/gpu/drm/nouveau/nouveau_display.c index 4610c3a..020542e 100644 --- a/drivers/gpu/drm/nouveau/nouveau_display.c +++ b/drivers/gpu/drm/nouveau/nouveau_display.c @@ -593,7 +597,7 @@ nouveau_crtc_page_flip(struct drm_crtc