linux-toradex.git/drivers/gpu, branch v3.12.29

drm/radeon/TN: only enable bapm on MSI systems

2014-09-18T14:40:02+00:00

commit 730a336c33a3398d65896e8ee3ef9f5679fe30a9 upstream.

There still seem to be stability problems with other systems.

Bug:
https://bugs.freedesktop.org/show_bug.cgi?id=72921

Signed-off-by: Alex Deucher 
Signed-off-by: Jiri Slaby

drm/radeon: enable bapm by default on desktop TN/RL boards

2014-09-18T14:40:02+00:00

commit 0c78a44964db3d483b0c09a8236e0fe123aa9cfc upstream.

bapm enabled the GPU and CPU to share TDP headroom.  It was
disabled by default since some laptops hung when it was enabled
in conjunction with dpm.  It seems to be stable on desktop
boards and fixes hangs on boot with dpm enabled on certain
boards, so enable it by default on desktop boards.

bug:
https://bugs.freedesktop.org/show_bug.cgi?id=72921

Signed-off-by: Alex Deucher 
Signed-off-by: Jiri Slaby

drm/i915: read HEAD register back in init_ring_common() to enforce ordering

2014-09-18T14:40:01+00:00

commit ece4a17d237a79f63fbfaf3f724a12b6d500555c upstream.

Withtout this, ring initialization fails reliabily during resume with

	[drm:init_ring_common] *ERROR* render ring initialization failed ctl 0001f001 head ffffff8804 tail 00000000 start 000e4000

This is not a complete fix, but it is verified to make the ring
initialization failures during resume much less likely.

We were not able to root-cause this bug (likely HW-specific to Gen4 chips)
yet. This is therefore used as a ducttape before problem is fully
understood and proper fix created, so that people don't suffer from
completely unusable systems in the meantime.

The discussion and debugging is happening at

	https://bugs.freedesktop.org/show_bug.cgi?id=76554

Signed-off-by: Jiri Kosina 
Signed-off-by: Daniel Vetter 
Signed-off-by: Jiri Slaby

drm/radeon: set VM base addr using the PFP v2

2014-09-18T14:40:01+00:00

commit f1d2a26b506e9dc7bbe94fae40da0a0d8dcfacd0 upstream.

Seems to make VM flushes more stable on SI and CIK.

v2: only use the PFP on the GFX ring on CIK

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

drm/radeon: load the lm63 driver for an lm64 thermal chip.

2014-09-18T14:40:01+00:00

commit 5dc355325b648dc9b4cf3bea4d968de46fd59215 upstream.

Looks like the lm63 driver supports the lm64 as well.

Signed-off-by: Alex Deucher 
Signed-off-by: Jiri Slaby

drm/ttm: Pass GFP flags in order to avoid deadlock.

2014-09-18T14:40:00+00:00

commit a91576d7916f6cce76d30303e60e1ac47cf4a76d upstream.

Commit 7dc19d5a "drivers: convert shrinkers to new count/scan API" added
deadlock warnings that ttm_page_pool_free() and ttm_dma_page_pool_free()
are currently doing GFP_KERNEL allocation.

But these functions did not get updated to receive gfp_t argument.
This patch explicitly passes sc->gfp_mask or GFP_KERNEL to these functions,
and removes the deadlock warning.

Signed-off-by: Tetsuo Handa 
Signed-off-by: Dave Airlie 
Signed-off-by: Jiri Slaby

drm/ttm: Fix possible stack overflow by recursive shrinker calls.

2014-09-18T14:40:00+00:00

commit 71336e011d1d2312bcbcaa8fcec7365024f3a95d upstream.

While ttm_dma_pool_shrink_scan() tries to take mutex before doing GFP_KERNEL
allocation, ttm_pool_shrink_scan() does not do it. This can result in stack
overflow if kmalloc() in ttm_page_pool_free() triggered recursion due to
memory pressure.

  shrink_slab()
  => ttm_pool_shrink_scan()
     => ttm_page_pool_free()
        => kmalloc(GFP_KERNEL)
           => shrink_slab()
              => ttm_pool_shrink_scan()
                 => ttm_page_pool_free()
                    => kmalloc(GFP_KERNEL)

Change ttm_pool_shrink_scan() to do like ttm_dma_pool_shrink_scan() does.

Signed-off-by: Tetsuo Handa 
Signed-off-by: Dave Airlie 
Signed-off-by: Jiri Slaby

drm/ttm: Use mutex_trylock() to avoid deadlock inside shrinker functions.

2014-09-18T14:40:00+00:00

commit 22e71691fd54c637800d10816bbeba9cf132d218 upstream.

I can observe that RHEL7 environment stalls with 100% CPU usage when a
certain type of memory pressure is given. While the shrinker functions
are called by shrink_slab() before the OOM killer is triggered, the stall
lasts for many minutes.

One of reasons of this stall is that
ttm_dma_pool_shrink_count()/ttm_dma_pool_shrink_scan() are called and
are blocked at mutex_lock(&_manager->lock). GFP_KERNEL allocation with
_manager->lock held causes someone (including kswapd) to deadlock when
these functions are called due to memory pressure. This patch changes
"mutex_lock();" to "if (!mutex_trylock()) return ...;" in order to
avoid deadlock.

Signed-off-by: Tetsuo Handa 
Signed-off-by: Dave Airlie 
Signed-off-by: Jiri Slaby

drm/ttm: Choose a pool to shrink correctly in ttm_dma_pool_shrink_scan().

2014-09-18T14:39:59+00:00

commit 46c2df68f03a236b30808bba361f10900c88d95e upstream.

We can use "unsigned int" instead of "atomic_t" by updating start_pool
variable under _manager->lock. This patch will make it possible to avoid
skipping when choosing a pool to shrink in round-robin style, after next
patch changes mutex_lock(_manager->lock) to !mutex_trylock(_manager->lork).

Signed-off-by: Tetsuo Handa 
Signed-off-by: Dave Airlie 
Signed-off-by: Jiri Slaby

drm/ttm: Fix possible division by 0 in ttm_dma_pool_shrink_scan().

2014-09-18T14:39:59+00:00

commit 11e504cc705e8ccb06ac93a276e11b5e8fee4d40 upstream.

list_empty(&_manager->pools) being false before taking _manager->lock
does not guarantee that _manager->npools != 0 after taking _manager->lock
because _manager->npools is updated under _manager->lock.

Signed-off-by: Tetsuo Handa 
Signed-off-by: Dave Airlie 
Signed-off-by: Jiri Slaby