<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/drivers/gpu/drm/ttm, branch linux-4.1.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.</subtitle>
<id>https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-4.1.y</id>
<link rel='self' href='https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-4.1.y'/>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/'/>
<updated>2018-03-21T03:49:45Z</updated>
<entry>
<title>drm/ttm: check the return value of kzalloc</title>
<updated>2018-03-21T03:49:45Z</updated>
<author>
<name>Xiongwei Song</name>
<email>sxwjean@gmail.com</email>
</author>
<published>2018-01-02T13:24:55Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=3102df24ffc3151330259ce49ae305abb8b7f256'/>
<id>urn:sha1:3102df24ffc3151330259ce49ae305abb8b7f256</id>
<content type='text'>
[ Upstream commit 19d859a7205bc59ffc38303eb25ae394f61d21dc ]

In the function ttm_page_alloc_init, kzalloc call is made for variable
_manager, we need to check its return value, it may return NULL.

Signed-off-by: Xiongwei Song &lt;sxwjean@gmail.com&gt;
Reviewed-by: Christian König &lt;christian.koenig@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
</content>
</entry>
<entry>
<title>drm/ttm: Fix accounting error when fail to get pages for pool</title>
<updated>2017-10-04T01:36:43Z</updated>
<author>
<name>Xiangliang.Yu</name>
<email>Xiangliang.Yu@amd.com</email>
</author>
<published>2017-08-16T06:25:51Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=522d3cb8b7ec67cdf19e1a558344fa91dd24dd99'/>
<id>urn:sha1:522d3cb8b7ec67cdf19e1a558344fa91dd24dd99</id>
<content type='text'>
[ Upstream commit 9afae2719273fa1d406829bf3498f82dbdba71c7 ]

When fail to get needed page for pool, need to put allocated pages
into pool. But current code has a miscalculation of allocated pages,
correct it.

Signed-off-by: Xiangliang.Yu &lt;Xiangliang.Yu@amd.com&gt;
Reviewed-by: Christian König &lt;christian.koenig@amd.com&gt;
Reviewed-by: Monk Liu &lt;monk.liu@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
</content>
</entry>
<entry>
<title>drm/ttm: fix use-after-free races in vm fault handling</title>
<updated>2017-06-13T13:29:21Z</updated>
<author>
<name>Nicolai Hähnle</name>
<email>nicolai.haehnle@amd.com</email>
</author>
<published>2017-02-18T21:59:56Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=47655216cdf4666a274f41ef64adfb2b91a0890e'/>
<id>urn:sha1:47655216cdf4666a274f41ef64adfb2b91a0890e</id>
<content type='text'>
[ Upstream commit 3089c1df10e2931b1d72d2ffa7d86431084c86b3 ]

The vm fault handler relies on the fact that the VMA owns a reference
to the BO. However, once mmap_sem is released, other tasks are free to
destroy the VMA, which can lead to the BO being freed. Fix two code
paths where that can happen, both related to vm fault retries.

Found via a lock debugging warning which flagged &amp;bo-&gt;wu_mutex as
locked while being destroyed.

Fixes: cbe12e74ee4e ("drm/ttm: Allow vm fault retries")
Signed-off-by: Nicolai Hähnle &lt;nicolai.haehnle@amd.com&gt;
Reviewed-by: Christian König &lt;christian.koenig@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
</content>
</entry>
<entry>
<title>drm/ttm: Make sure BOs being swapped out are cacheable</title>
<updated>2017-05-17T19:06:57Z</updated>
<author>
<name>Michel Dänzer</name>
<email>michel.daenzer@amd.com</email>
</author>
<published>2017-01-25T08:21:31Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=1efa8e2ac68bf25c973d874ffb3eab67d05bb1cc'/>
<id>urn:sha1:1efa8e2ac68bf25c973d874ffb3eab67d05bb1cc</id>
<content type='text'>
[ Upstream commit 239ac65fa5ffab71adf66e642750f940e7241d99 ]

The current caching state may not be tt_cached, even though the
placement contains TTM_PL_FLAG_CACHED, because placement can contain
multiple caching flags. Trying to swap out such a BO would trip up the

	BUG_ON(ttm-&gt;caching_state != tt_cached);

in ttm_tt_swapout.

Cc: stable@vger.kernel.org
Signed-off-by: Michel Dänzer &lt;michel.daenzer@amd.com&gt;
Reviewed-by: Thomas Hellstrom &lt;thellstrom@vmware.com&gt;
Reviewed-by: Christian König &lt;christian.koenig@amd.com&gt;.
Reviewed-by: Sinclair Yeh &lt;syeh@vmware.com&gt;
Signed-off-by: Christian König &lt;christian.koenig@amd.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
</content>
</entry>
<entry>
<title>drm/ttm: Make ttm_bo_mem_compat available</title>
<updated>2016-08-03T15:46:07Z</updated>
<author>
<name>Sinclair Yeh</name>
<email>syeh@vmware.com</email>
</author>
<published>2016-06-29T19:58:49Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=97f28872a3148fb589125507e757163fef6a0b9b'/>
<id>urn:sha1:97f28872a3148fb589125507e757163fef6a0b9b</id>
<content type='text'>
[ Upstream commit 94477bff390aa4612d2332c8abafaae0a13d6923 ]

There are cases where it is desired to see if a proposed placement
is compatible with a buffer object before calling ttm_bo_validate().

Signed-off-by: Sinclair Yeh &lt;syeh@vmware.com&gt;
Reviewed-by: Thomas Hellstrom &lt;thellstrom@vmware.com&gt;
Cc: &lt;stable@vger.kernel.org&gt;
---
This is the first of a 3-patch series to fix a black screen
issue observed on Ubuntu 16.04 server.

Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
</content>
</entry>
<entry>
<title>dma-buf: cleanup dma_buf_export() to make it easily extensible</title>
<updated>2015-04-21T09:17:16Z</updated>
<author>
<name>Sumit Semwal</name>
<email>sumit.semwal@linaro.org</email>
</author>
<published>2015-01-23T07:23:43Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=d8fbe341beb617ebb22b98fb893e4aa32ae2d864'/>
<id>urn:sha1:d8fbe341beb617ebb22b98fb893e4aa32ae2d864</id>
<content type='text'>
At present, dma_buf_export() takes a series of parameters, which
makes it difficult to add any new parameters for exporters, if required.

Make it simpler by moving all these parameters into a struct, and pass
the struct * as parameter to dma_buf_export().

While at it, unite dma_buf_export_named() with dma_buf_export(), and
change all callers accordingly.

Reviewed-by: Maarten Lankhorst &lt;maarten.lankhorst@canonical.com&gt;
Reviewed-by: Daniel Thompson &lt;daniel.thompson@linaro.org&gt;
Acked-by: Mauro Carvalho Chehab &lt;mchehab@osg.samsung.com&gt;
Acked-by: Dave Airlie &lt;airlied@redhat.com&gt;
Signed-off-by: Sumit Semwal &lt;sumit.semwal@linaro.org&gt;
</content>
</entry>
<entry>
<title>drm/ttm: device address space != CPU address space</title>
<updated>2015-03-04T23:04:39Z</updated>
<author>
<name>Alex Deucher</name>
<email>alexdeucher@gmail.com</email>
</author>
<published>2015-03-04T05:18:38Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=54c4cd68ed7abd9f245722bee39464d04ddb4cfd'/>
<id>urn:sha1:54c4cd68ed7abd9f245722bee39464d04ddb4cfd</id>
<content type='text'>
We need to store device offsets in 64 bit as the device
address space may be larger than the CPU's.

Fixes GPU init failures on radeons with 4GB or more of
vram on 32 bit kernels.  We put vram at the start of the
GPU's address space so the gart aperture starts at 4 GB
causing all GPU addresses in the gart aperture to get
truncated.

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

[airlied: fix warning on nouveau build]

Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Cc: thellstrom@vmware.com
Acked-by: Thomas Hellstrom &lt;thellstrom@vmware.com&gt;
Signed-off-by: Dave Airlie &lt;airlied@redhat.com&gt;
</content>
</entry>
<entry>
<title>drm/ttm: optionally move duplicates to a separate list</title>
<updated>2014-12-03T23:26:52Z</updated>
<author>
<name>Christian König</name>
<email>christian.koenig@amd.com</email>
</author>
<published>2014-12-03T14:46:48Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=aa35071c590461f95d0179cc8e730d49d610f773'/>
<id>urn:sha1:aa35071c590461f95d0179cc8e730d49d610f773</id>
<content type='text'>
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 &lt;thellstrom@vmware.com&gt;
Signed-off-by: Christian König &lt;christian.koenig@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
</content>
</entry>
<entry>
<title>drm/ttm: Avoid memory allocation from shrinker functions.</title>
<updated>2014-11-20T01:31:56Z</updated>
<author>
<name>Tetsuo Handa</name>
<email>penguin-kernel@I-love.SAKURA.ne.jp</email>
</author>
<published>2014-11-13T13:43:23Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=881fdaa5e4cb0d68e52acab0ad4e1820e2bfffa4'/>
<id>urn:sha1:881fdaa5e4cb0d68e52acab0ad4e1820e2bfffa4</id>
<content type='text'>
Andrew Morton wrote:
&gt; On Wed, 12 Nov 2014 13:08:55 +0900 Tetsuo Handa &lt;penguin-kernel@i-love.sakura.ne.jp&gt; wrote:
&gt;
&gt; &gt; Andrew Morton wrote:
&gt; &gt; &gt; Poor ttm guys - this is a bit of a trap we set for them.
&gt; &gt;
&gt; &gt; Commit a91576d7916f6cce ("drm/ttm: Pass GFP flags in order to avoid deadlock.")
&gt; &gt; changed to use sc-&gt;gfp_mask rather than GFP_KERNEL.
&gt; &gt;
&gt; &gt; -       pages_to_free = kmalloc(npages_to_free * sizeof(struct page *),
&gt; &gt; -                       GFP_KERNEL);
&gt; &gt; +       pages_to_free = kmalloc(npages_to_free * sizeof(struct page *), gfp);
&gt; &gt;
&gt; &gt; But this bug is caused by sc-&gt;gfp_mask containing some flags which are not
&gt; &gt; in GFP_KERNEL, right? Then, I think
&gt; &gt;
&gt; &gt; -       pages_to_free = kmalloc(npages_to_free * sizeof(struct page *), gfp);
&gt; &gt; +       pages_to_free = kmalloc(npages_to_free * sizeof(struct page *), gfp &amp; GFP_KERNEL);
&gt; &gt;
&gt; &gt; would hide this bug.
&gt; &gt;
&gt; &gt; But I think we should use GFP_ATOMIC (or drop __GFP_WAIT flag)
&gt;
&gt; Well no - ttm_page_pool_free() should stop calling kmalloc altogether.
&gt; Just do
&gt;
&gt; 	struct page *pages_to_free[16];
&gt;
&gt; 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?
----------
&gt;From d3cb5393c9c8099d6b37e769f78c31af1541fe8c Mon Sep 17 00:00:00 2001
From: Tetsuo Handa &lt;penguin-kernel@I-love.SAKURA.ne.jp&gt;
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-&gt;gfp_mask containing flags
which are not in GFP_KERNEL.

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

Changing from sc-&gt;gfp_mask to (sc-&gt;gfp_mask &amp; 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 &lt;penguin-kernel@I-love.SAKURA.ne.jp&gt;
Cc: stable &lt;stable@kernel.org&gt; [2.6.35+]
Signed-off-by: Dave Airlie &lt;airlied@redhat.com&gt;
</content>
</entry>
<entry>
<title>drm/ttm: Use only DRM_MM_SEARCH_BELOW for TTM_PL_FLAG_TOPDOWN</title>
<updated>2014-11-12T16:56:33Z</updated>
<author>
<name>Michel Dänzer</name>
<email>michel.daenzer@amd.com</email>
</author>
<published>2014-10-28T09:35:04Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=507d0ca71bcbefd8623eb20f4de1b5f4e103a48b'/>
<id>urn:sha1:507d0ca71bcbefd8623eb20f4de1b5f4e103a48b</id>
<content type='text'>
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 &lt;cand@gmx.com&gt;
Signed-off-by: Michel Dänzer &lt;michel.daenzer@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
</content>
</entry>
</feed>
