linux-stable.git/drivers/gpu/drm/ttm, branch linux-3.19.y

drm/ttm: optionally move duplicates to a separate list

2014-12-03T23:26:52+00:00

This patch adds an optional list_head parameter to ttm_eu_reserve_buffers.
If specified duplicates in the execbuf list are no longer reported as errors,
but moved to this list instead.

Reviewed-by: Thomas Hellstrom 
Signed-off-by: Christian König 
Signed-off-by: Alex Deucher

drm/ttm: Avoid memory allocation from shrinker functions.

2014-11-20T01:31:56+00:00

Andrew Morton wrote:
> On Wed, 12 Nov 2014 13:08:55 +0900 Tetsuo Handa  wrote:
>
> > Andrew Morton wrote:
> > > Poor ttm guys - this is a bit of a trap we set for them.
> >
> > Commit a91576d7916f6cce ("drm/ttm: Pass GFP flags in order to avoid deadlock.")
> > changed to use sc->gfp_mask rather than GFP_KERNEL.
> >
> > -       pages_to_free = kmalloc(npages_to_free * sizeof(struct page *),
> > -                       GFP_KERNEL);
> > +       pages_to_free = kmalloc(npages_to_free * sizeof(struct page *), gfp);
> >
> > But this bug is caused by sc->gfp_mask containing some flags which are not
> > in GFP_KERNEL, right? Then, I think
> >
> > -       pages_to_free = kmalloc(npages_to_free * sizeof(struct page *), gfp);
> > +       pages_to_free = kmalloc(npages_to_free * sizeof(struct page *), gfp & GFP_KERNEL);
> >
> > would hide this bug.
> >
> > But I think we should use GFP_ATOMIC (or drop __GFP_WAIT flag)
>
> Well no - ttm_page_pool_free() should stop calling kmalloc altogether.
> Just do
>
> 	struct page *pages_to_free[16];
>
> and rework the code to free 16 pages at a time.  Easy.

Well, ttm code wants to process 512 pages at a time for performance.
Memory footprint increased by 512 * sizeof(struct page *) buffer is
only 4096 bytes. What about using static buffer like below?
----------
>From d3cb5393c9c8099d6b37e769f78c31af1541fe8c Mon Sep 17 00:00:00 2001
From: Tetsuo Handa 
Date: Thu, 13 Nov 2014 22:21:54 +0900
Subject: [PATCH] drm/ttm: Avoid memory allocation from shrinker functions.

Commit a91576d7916f6cce ("drm/ttm: Pass GFP flags in order to avoid
deadlock.") caused BUG_ON() due to sc->gfp_mask containing flags
which are not in GFP_KERNEL.

  https://bugzilla.kernel.org/show_bug.cgi?id=87891

Changing from sc->gfp_mask to (sc->gfp_mask & GFP_KERNEL) would
avoid the BUG_ON(), but avoiding memory allocation from shrinker
function is better and reliable fix.

Shrinker function is already serialized by global lock, and
clean up function is called after shrinker function is unregistered.
Thus, we can use static buffer when called from shrinker function
and clean up function.

Signed-off-by: Tetsuo Handa 
Cc: stable  [2.6.35+]
Signed-off-by: Dave Airlie

drm/ttm: Use only DRM_MM_SEARCH_BELOW for TTM_PL_FLAG_TOPDOWN

2014-11-12T16:56:33+00:00

DRM_MM_SEARCH_BEST gets the smallest hole which can fit the BO. That seems
against the idea of TTM_PL_FLAG_TOPDOWN:

* The smallest hole may be in the overall bottom of the area
* If the hole isn't much larger than the BO, it doesn't make much
  difference whether the BO is placed at the bottom or at the top of the
  hole

Reviewed-by: Lauri Kasanen 
Signed-off-by: Michel Dänzer 
Signed-off-by: Alex Deucher

drm/ttm: Add DRM_MM_SEARCH_BELOW for TTM_PL_FLAG_TOPDOWN

2014-11-12T16:56:32+00:00

If the BO should be placed at the top of the area, we should start looking
for holes from the top.

Reviewed-by: Lauri Kasanen 
Signed-off-by: Michel Dänzer 
Signed-off-by: Alex Deucher

drm/ttm: Don't evict BOs outside of the requested placement range

2014-10-16T22:34:08+00:00

The radeon driver uses placement range restrictions for several reasons,
in particular to make sure BOs in VRAM can be accessed by the CPU, e.g.
during a page fault.

Without this change, TTM could evict other BOs while trying to satisfy
the requested placement, even if the evicted BOs were outside of the
requested placement range. Doing so didn't free up any space in the
requested placement range, so the (potentially high) eviction cost was
incurred for no benefit.

Nominating for stable because radeon driver changes in 3.17 made this
much more noticeable than before.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=84662
Cc: stable@vger.kernel.org
Signed-off-by: Michel Dänzer 
Signed-off-by: Alex Deucher

drm/ttm: Don't skip fpfn check if lpfn is 0 in ttm_bo_mem_compat

2014-10-16T22:34:08+00:00

Reviewed-by: Christian König 
Signed-off-by: Michel Dänzer 
Signed-off-by: Alex Deucher

drm/ttm: add reservation_object as argument to ttm_bo_init

2014-09-30T12:04:00+00:00

This allows importing reservation objects from dma-bufs.

Signed-off-by: Maarten Lankhorst

drm/ttm: Clean usage of ttm_io_prot() with TTM_PL_FLAG_CACHED

2014-09-23T05:00:26+00:00

Today, most callers of ttm_io_prot() check TTM_PL_FLAG_CACHED before
calling it since on some archs it will unconditionally create non-cached
mappings.

But not all callers do which is incorrect as far as I can tell.

Instead, move that check inside ttm_io_port() itself for all archs
and make powerpc use the same implementation as ia64 and arm

Signed-off-by: Benjamin Herrenschmidt 
Signed-off-by: Dave Airlie

drm/ttm: make sure format string cannot leak in

2014-09-17T01:15:01+00:00

While zone->name is currently hard coded, the call to kobject_init_and_add()
should follow the more defensive argument list usage (as already done in
other places in ttm_memory.c) where "%s" is used instead of directly passing
in a variable as a format string.

Signed-off-by: Kees Cook 
Signed-off-by: Dave Airlie

drm/ttm: allow fence to be added as shared

2014-09-11T14:46:00+00:00

This patch adds a new flag to the ttm_validate_buffer list to
add the fence as shared to the reservation object.

Signed-off-by: Christian König 
Signed-off-by: Alex Deucher