<feed xmlns='http://www.w3.org/2005/Atom'>
<title>BMC/Intel-BMC/linux.git/drivers/gpu/drm/etnaviv, branch dev-4.10</title>
<subtitle>Intel OpenBMC Linux kernel source tree (mirror)</subtitle>
<id>https://git.radix-linux.su/BMC/Intel-BMC/linux.git/atom?h=dev-4.10</id>
<link rel='self' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/atom?h=dev-4.10'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/'/>
<updated>2017-04-21T07:32:37+00:00</updated>
<entry>
<title>drm/etnaviv: fix missing unlock on error in etnaviv_gpu_submit()</title>
<updated>2017-04-21T07:32:37+00:00</updated>
<author>
<name>Wei Yongjun</name>
<email>weiyongjun1@huawei.com</email>
</author>
<published>2017-04-12T00:31:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=e97e515b744857377b328d7aaa1a7278343b0bd7'/>
<id>urn:sha1:e97e515b744857377b328d7aaa1a7278343b0bd7</id>
<content type='text'>
commit 45abdf35cf82e4270328c7237e7812de960ac560 upstream.

Add the missing unlock before return from function etnaviv_gpu_submit()
in the error handling case.

lst: fixed label name.

Fixes: f3cd1b064f11 ("drm/etnaviv: (re-)protect fence allocation with GPU mutex")
Signed-off-by: Wei Yongjun &lt;weiyongjun1@huawei.com&gt;
Signed-off-by: Lucas Stach &lt;l.stach@pengutronix.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>drm/etnaviv: (re-)protect fence allocation with GPU mutex</title>
<updated>2017-04-08T07:35:08+00:00</updated>
<author>
<name>Lucas Stach</name>
<email>l.stach@pengutronix.de</email>
</author>
<published>2017-03-22T11:07:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=65e5e864aad944f63161d3bbfc0f5f941a6844cc'/>
<id>urn:sha1:65e5e864aad944f63161d3bbfc0f5f941a6844cc</id>
<content type='text'>
commit f3cd1b064f1179d9e6188c6d67297a2360880e10 upstream.

The fence allocation needs to be protected by the GPU mutex, otherwise
the fence seqnos of concurrent submits might not match the insertion order
of the jobs in the kernel ring. This breaks the assumption that jobs
complete with monotonically increasing fence seqnos.

Fixes: d9853490176c (drm/etnaviv: take GPU lock later in the submit process)
Signed-off-by: Lucas Stach &lt;l.stach@pengutronix.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>drm/etnaviv: trick drm_mm into giving out a low IOVA</title>
<updated>2017-01-11T09:38:45+00:00</updated>
<author>
<name>Lucas Stach</name>
<email>l.stach@pengutronix.de</email>
</author>
<published>2016-12-12T15:15:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=3546fb0cdac25a79c89d87020566fab52b92867d'/>
<id>urn:sha1:3546fb0cdac25a79c89d87020566fab52b92867d</id>
<content type='text'>
After rollover of the IOVA space, we want to get a low IOVA address,
otherwise the the games we play by remembering the last IOVA are
pointless. When we search for a free hole with DRM_MM_SEARCH_DEFAULT,
drm_mm will pop the next entry from the free holes stack, which will
likely be a high IOVA. By using DRM_MM_SEARCH_BELOW we can trick
drm_mm into reversing the search and provide us with a low IOVA.

Signed-off-by: Lucas Stach &lt;l.stach@pengutronix.de&gt;
Reviewed-by: Wladimir van der Laan &lt;laanwj@gmail.com&gt;
</content>
</entry>
<entry>
<title>mm: use vmf-&gt;address instead of of vmf-&gt;virtual_address</title>
<updated>2016-12-15T00:04:09+00:00</updated>
<author>
<name>Jan Kara</name>
<email>jack@suse.cz</email>
</author>
<published>2016-12-14T23:07:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=1a29d85eb0f19b7d8271923d8917d7b4f5540b3e'/>
<id>urn:sha1:1a29d85eb0f19b7d8271923d8917d7b4f5540b3e</id>
<content type='text'>
Every single user of vmf-&gt;virtual_address typed that entry to unsigned
long before doing anything with it so the type of virtual_address does
not really provide us any additional safety.  Just use masked
vmf-&gt;address which already has the appropriate type.

Link: http://lkml.kernel.org/r/1479460644-25076-3-git-send-email-jack@suse.cz
Signed-off-by: Jan Kara &lt;jack@suse.cz&gt;
Acked-by: Kirill A. Shutemov &lt;kirill.shutemov@linux.intel.com&gt;
Cc: Dan Williams &lt;dan.j.williams@intel.com&gt;
Cc: Ross Zwisler &lt;ross.zwisler@linux.intel.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>mm: add locked parameter to get_user_pages_remote()</title>
<updated>2016-12-15T00:04:08+00:00</updated>
<author>
<name>Lorenzo Stoakes</name>
<email>lstoakes@gmail.com</email>
</author>
<published>2016-12-14T23:06:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=5b56d49fc31dbb0487e14ead790fc81ca9fb2c99'/>
<id>urn:sha1:5b56d49fc31dbb0487e14ead790fc81ca9fb2c99</id>
<content type='text'>
Patch series "mm: unexport __get_user_pages_unlocked()".

This patch series continues the cleanup of get_user_pages*() functions
taking advantage of the fact we can now pass gup_flags as we please.

It firstly adds an additional 'locked' parameter to
get_user_pages_remote() to allow for its callers to utilise
VM_FAULT_RETRY functionality.  This is necessary as the invocation of
__get_user_pages_unlocked() in process_vm_rw_single_vec() makes use of
this and no other existing higher level function would allow it to do
so.

Secondly existing callers of __get_user_pages_unlocked() are replaced
with the appropriate higher-level replacement -
get_user_pages_unlocked() if the current task and memory descriptor are
referenced, or get_user_pages_remote() if other task/memory descriptors
are referenced (having acquiring mmap_sem.)

This patch (of 2):

Add a int *locked parameter to get_user_pages_remote() to allow
VM_FAULT_RETRY faulting behaviour similar to get_user_pages_[un]locked().

Taking into account the previous adjustments to get_user_pages*()
functions allowing for the passing of gup_flags, we are now in a
position where __get_user_pages_unlocked() need only be exported for his
ability to allow VM_FAULT_RETRY behaviour, this adjustment allows us to
subsequently unexport __get_user_pages_unlocked() as well as allowing
for future flexibility in the use of get_user_pages_remote().

[sfr@canb.auug.org.au: merge fix for get_user_pages_remote API change]
  Link: http://lkml.kernel.org/r/20161122210511.024ec341@canb.auug.org.au
Link: http://lkml.kernel.org/r/20161027095141.2569-2-lstoakes@gmail.com
Signed-off-by: Lorenzo Stoakes &lt;lstoakes@gmail.com&gt;
Acked-by: Michal Hocko &lt;mhocko@suse.com&gt;
Cc: Jan Kara &lt;jack@suse.cz&gt;
Cc: Hugh Dickins &lt;hughd@google.com&gt;
Cc: Dave Hansen &lt;dave.hansen@linux.intel.com&gt;
Cc: Rik van Riel &lt;riel@redhat.com&gt;
Cc: Mel Gorman &lt;mgorman@techsingularity.net&gt;
Cc: Paolo Bonzini &lt;pbonzini@redhat.com&gt;
Cc: Radim Krcmar &lt;rkrcmar@redhat.com&gt;
Signed-off-by: Stephen Rothwell &lt;sfr@canb.auug.org.au&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>Merge branch 'drm-etnaviv-next' of git://git.pengutronix.de/lst/linux into drm-next</title>
<updated>2016-12-06T01:00:16+00:00</updated>
<author>
<name>Dave Airlie</name>
<email>airlied@redhat.com</email>
</author>
<published>2016-12-06T01:00:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=770ac20413ce654f6e4efaaf24e954ebb907fc3b'/>
<id>urn:sha1:770ac20413ce654f6e4efaaf24e954ebb907fc3b</id>
<content type='text'>
- fix dma-buf export path to return correct SG table
- trivially implement direct dma-buf mapping
- allow DRAW_INSTANCED commands in validator
- make the driver work on i.MX6SX, yielding a working 2D/3D stack
together with Mareks MXS DRM driver

* 'drm-etnaviv-next' of git://git.pengutronix.de/lst/linux:
  MAINTAINERS: add etnaviv mailinglist
  drm/etnaviv: move linear window on MC1.0 parts if necessary
  drm/etnaviv: don't invoke OOM killer from dump code
  drm/etnaviv: fix gem_prime_get_sg_table to return new SG table
  drm/etnaviv: Allow DRAW_INSTANCED commands
  drm/etnaviv: implement dma-buf mmap
</content>
</entry>
<entry>
<title>drm/etnaviv: move linear window on MC1.0 parts if necessary</title>
<updated>2016-12-02T18:30:24+00:00</updated>
<author>
<name>Lucas Stach</name>
<email>l.stach@pengutronix.de</email>
</author>
<published>2016-12-02T11:19:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=1db0127904469b7288ecd6b26e86898037aaf060'/>
<id>urn:sha1:1db0127904469b7288ecd6b26e86898037aaf060</id>
<content type='text'>
On i.MX6SX the physical memory is placed above the 2GB mark, so the GPU
linear window has to be moved for the GPU to work at all. This doesn't
mix with the FAST_CLEAR feature, as the TS unit doesn't take the linear
window offset into account and will corrupt memory when used with a
non-zero offset.

Move the linear window if it's necessary for the GPU to work, but avoid
announcing FAST_CLEAR support to userspace in this case.

Signed-off-by: Lucas Stach &lt;l.stach@pengutronix.de&gt;
Tested-by: Marek Vasut &lt;marex@denx.de&gt;
</content>
</entry>
<entry>
<title>drm/etnaviv: don't invoke OOM killer from dump code</title>
<updated>2016-12-02T18:30:23+00:00</updated>
<author>
<name>Lucas Stach</name>
<email>l.stach@pengutronix.de</email>
</author>
<published>2016-12-02T10:14:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=172dbac35efdba3b1251c547a16697e6f3648ebb'/>
<id>urn:sha1:172dbac35efdba3b1251c547a16697e6f3648ebb</id>
<content type='text'>
The dumper is only a debugging aid so we don't want to invoke the OOM
killer if buffer for the potentially large GPU state can't be vmalloced.

Signed-off-by: Lucas Stach &lt;l.stach@pengutronix.de&gt;
</content>
</entry>
<entry>
<title>drm/etnaviv: fix gem_prime_get_sg_table to return new SG table</title>
<updated>2016-12-02T18:30:23+00:00</updated>
<author>
<name>Lucas Stach</name>
<email>l.stach@pengutronix.de</email>
</author>
<published>2016-11-30T14:26:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=5f4a4a73f437b007019495c3c789599d71b9c59e'/>
<id>urn:sha1:5f4a4a73f437b007019495c3c789599d71b9c59e</id>
<content type='text'>
The object internal SG table must not be returned, as the caller
will take ownership of the returned table.

Construct a new table from the object pages and return this one
instead.

Signed-off-by: Lucas Stach &lt;l.stach@pengutronix.de&gt;
</content>
</entry>
<entry>
<title>drm/etnaviv: Allow DRAW_INSTANCED commands</title>
<updated>2016-12-02T18:30:22+00:00</updated>
<author>
<name>Wladimir J. van der Laan</name>
<email>laanwj@gmail.com</email>
</author>
<published>2016-11-11T16:57:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=557800532ebdec4fc460876af4e3c216d23a184d'/>
<id>urn:sha1:557800532ebdec4fc460876af4e3c216d23a184d</id>
<content type='text'>
Vivante GPUs with HALTI0 feature support a DRAW_INSTANCED command in the
command stream to draw a number of instances of the same geometry.

The information that has been figured out about the command can be found
here: https://github.com/etnaviv/etna_viv/blob/master/rnndb/cmdstream.xml#L270

This command is not allowed currently by the DRM driver because it
was not known before. This patch enables parsing it in command
streams and allows using it by userspace drivers.

Signed-off-by: Wladimir J. van der Laan &lt;laanwj@gmail.com&gt;
Signed-off-by: Lucas Stach &lt;l.stach@pengutronix.de&gt;
</content>
</entry>
</feed>
