<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/gpu/drm/etnaviv, branch v5.4.126</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v5.4.126</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v5.4.126'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2020-09-05T09:22:50+00:00</updated>
<entry>
<title>drm/etnaviv: fix TS cache flushing on GPUs with BLT engine</title>
<updated>2020-09-05T09:22:50+00:00</updated>
<author>
<name>Lucas Stach</name>
<email>l.stach@pengutronix.de</email>
</author>
<published>2020-02-26T15:27:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=538caddbe635d3ca18e0f02276e76c124eb3c604'/>
<id>urn:sha1:538caddbe635d3ca18e0f02276e76c124eb3c604</id>
<content type='text'>
commit f232d9ec029ce3e2543b05213e2979e01e503408 upstream.

As seen in the Vivante kernel driver, most GPUs with the BLT engine have
a broken TS cache flush. The workaround is to temporarily set the BLT
command to CLEAR_IMAGE, without actually executing the clear. Apparently
this state change is enough to trigger the required TS cache flush. As
the BLT engine is completely asychronous, we also need a few more stall
states to synchronize the flush with the frontend.

Root-caused-by: Jonathan Marek &lt;jonathan@marek.ca&gt;
Signed-off-by: Lucas Stach &lt;l.stach@pengutronix.de&gt;
Cc: Walter Lozano &lt;walter.lozano@collabora.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>drm/etnaviv: Fix error path on failure to enable bus clk</title>
<updated>2020-08-19T06:16:07+00:00</updated>
<author>
<name>Lubomir Rintel</name>
<email>lkundrak@v3.sk</email>
</author>
<published>2020-06-16T21:21:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=018192e8586017971021adc95970b3cf2c7379ad'/>
<id>urn:sha1:018192e8586017971021adc95970b3cf2c7379ad</id>
<content type='text'>
[ Upstream commit f8794feaf65cdc97767604cf864775d20b97f397 ]

Since commit 65f037e8e908 ("drm/etnaviv: add support for slave interface
clock") the reg clock is enabled before the bus clock and we need to undo
its enablement on error.

Fixes: 65f037e8e908 ("drm/etnaviv: add support for slave interface clock")
Signed-off-by: Lubomir Rintel &lt;lkundrak@v3.sk&gt;
Signed-off-by: Lucas Stach &lt;l.stach@pengutronix.de&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drm/etnaviv: fix ref count leak via pm_runtime_get_sync</title>
<updated>2020-08-19T06:16:01+00:00</updated>
<author>
<name>Navid Emamdoost</name>
<email>navid.emamdoost@gmail.com</email>
</author>
<published>2020-06-15T06:12:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=20e7c445606967ed9c45f68c16da0adc8359f362'/>
<id>urn:sha1:20e7c445606967ed9c45f68c16da0adc8359f362</id>
<content type='text'>
[ Upstream commit c5d5a32ead1e3a61a07a1e59eb52a53e4a6b2a7f ]

in etnaviv_gpu_submit, etnaviv_gpu_recover_hang, etnaviv_gpu_debugfs,
and etnaviv_gpu_init the call to pm_runtime_get_sync increments the
counter even in case of failure, leading to incorrect ref count.
In case of failure, decrement the ref count before returning.

Signed-off-by: Navid Emamdoost &lt;navid.emamdoost@gmail.com&gt;
Signed-off-by: Lucas Stach &lt;l.stach@pengutronix.de&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drm/etnaviv: Fix a leak in submit_pin_objects()</title>
<updated>2020-05-27T15:46:42+00:00</updated>
<author>
<name>Dan Carpenter</name>
<email>dan.carpenter@oracle.com</email>
</author>
<published>2020-05-18T11:29:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=57c32a52c3fecb17689e268dd9af201920872600'/>
<id>urn:sha1:57c32a52c3fecb17689e268dd9af201920872600</id>
<content type='text'>
commit ad99cb5e783bb03d512092db3387ead9504aad3d upstream.

If the mapping address is wrong then we have to release the reference to
it before returning -EINVAL.

Fixes: 088880ddc0b2 ("drm/etnaviv: implement softpin")
Signed-off-by: Dan Carpenter &lt;dan.carpenter@oracle.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: fix perfmon domain interation</title>
<updated>2020-05-27T15:46:41+00:00</updated>
<author>
<name>Christian Gmeiner</name>
<email>christian.gmeiner@gmail.com</email>
</author>
<published>2020-05-19T05:30:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=3b1e38dfbc9f1bcec35cae89b2d9b498e542f7c8'/>
<id>urn:sha1:3b1e38dfbc9f1bcec35cae89b2d9b498e542f7c8</id>
<content type='text'>
commit 40b697e256ccdb88aaff424b44b4d300eb8460e8 upstream.

The GC860 has one GPU device which has a 2d and 3d core. In this case
we want to expose perfmon information for both cores.

The driver has one array which contains all possible perfmon domains
with some meta data - doms_meta. Here we can see that for the GC860
two elements of that array are relevant:

  doms_3d: is at index 0 in the doms_meta array with 8 perfmon domains
  doms_2d: is at index 1 in the doms_meta array with 1 perfmon domain

The userspace driver wants to get a list of all perfmon domains and
their perfmon signals. This is done by iterating over all domains and
their signals. If the userspace driver wants to access the domain with
id 8 the kernel driver fails and returns invalid data from doms_3d with
and invalid offset.

This results in:
  Unable to handle kernel paging request at virtual address 00000000

On such a device it is not possible to use the userspace driver at all.

The fix for this off-by-one error is quite simple.

Reported-by: Paul Cercueil &lt;paul@crapouillou.net&gt;
Tested-by: Paul Cercueil &lt;paul@crapouillou.net&gt;
Fixes: ed1dd899baa3 ("drm/etnaviv: rework perfmon query infrastructure")
Cc: stable@vger.kernel.org
Signed-off-by: Christian Gmeiner &lt;christian.gmeiner@gmail.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: rework perfmon query infrastructure</title>
<updated>2020-04-17T08:50:20+00:00</updated>
<author>
<name>Christian Gmeiner</name>
<email>christian.gmeiner@gmail.com</email>
</author>
<published>2020-02-28T10:37:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=b716a5f5ec65474365965e4db3d3c77c625d53d2'/>
<id>urn:sha1:b716a5f5ec65474365965e4db3d3c77c625d53d2</id>
<content type='text'>
commit ed1dd899baa32d47d9a93d98336472da50564346 upstream.

Report the correct perfmon domains and signals depending
on the supported feature flags.

Reported-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Fixes: 9e2c2e273012 ("drm/etnaviv: add infrastructure to query perf counter")
Cc: stable@vger.kernel.org
Signed-off-by: Christian Gmeiner &lt;christian.gmeiner@gmail.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: fix dumping of iommuv2</title>
<updated>2019-10-29T17:12:24+00:00</updated>
<author>
<name>Christian Gmeiner</name>
<email>christian.gmeiner@gmail.com</email>
</author>
<published>2019-10-25T10:39:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=a2f10d4a3069fee666dab20fab5458757ba1f22d'/>
<id>urn:sha1:a2f10d4a3069fee666dab20fab5458757ba1f22d</id>
<content type='text'>
etnaviv_iommuv2_dump_size(..) returns the number of PTE * SZ_4K but
etnaviv_iommuv2_dump(..) increments buf pointer even if there is no PTE.
This results in a bad buf pointer which gets used for memcpy(..), when
copying the MMU state in the coredump buffer.

Fixes: afb7b3b1deb4 ("drm/etnaviv: implement IOMMUv2 translation")
Cc: stable@vger.kernel.org
Signed-off-by: Christian Gmeiner &lt;christian.gmeiner@gmail.com&gt;
Signed-off-by: Lucas Stach &lt;l.stach@pengutronix.de&gt;
</content>
</entry>
<entry>
<title>drm/etnaviv: reinstate MMUv1 command buffer window check</title>
<updated>2019-10-29T17:11:50+00:00</updated>
<author>
<name>Lucas Stach</name>
<email>l.stach@pengutronix.de</email>
</author>
<published>2019-10-16T14:10:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=18fa692d8020083cd57ce031a4b5a7a4ec8bc50a'/>
<id>urn:sha1:18fa692d8020083cd57ce031a4b5a7a4ec8bc50a</id>
<content type='text'>
The switch to per-process address spaces erroneously dropped the check
which validated that the command buffer is mapped through the linear
apperture as required by the hardware. This turned a system
misconfiguration with a helpful error message into a very hard to
debug issue. Reinstate the check at the appropriate location.

Fixes: 17e4660ae3d7 (drm/etnaviv: implement per-process address spaces on MMUv2)
Signed-off-by: Lucas Stach &lt;l.stach@pengutronix.de&gt;
Reviewed-by: Guido Günther &lt;agx@sigxcpu.org&gt;
</content>
</entry>
<entry>
<title>drm/etnaviv: fix deadlock in GPU coredump</title>
<updated>2019-10-29T17:11:06+00:00</updated>
<author>
<name>Lucas Stach</name>
<email>l.stach@pengutronix.de</email>
</author>
<published>2019-10-16T13:37:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=ca8cb69580236f47041dd045c08f82cb7bb50d7c'/>
<id>urn:sha1:ca8cb69580236f47041dd045c08f82cb7bb50d7c</id>
<content type='text'>
The GPU coredump function violates the locking order by holding the MMU
context lock while trying to acquire the etnaviv_gem_object lock. This
results in a possible ABBA deadlock with other codepaths which follow
the established locking order.
Fortunately this is easy to fix by dropping the MMU context lock
earlier, as the BO dumping doesn't need the MMU context to be stable.
The only thing the BO dumping cares about are the BO mappings, which
are stable across the lifetime of the job.

Fixes: 27b67278e007 (drm/etnaviv: rework MMU handling)
[ Not really the first bad commit, but the one where this fix applies
  cleanly. Stable kernels need a manual backport. ]
Reported-by: Christian Gmeiner &lt;christian.gmeiner@gmail.com&gt;
Signed-off-by: Lucas Stach &lt;l.stach@pengutronix.de&gt;
Tested-by: Christian Gmeiner &lt;christian.gmeiner@gmail.com&gt;
</content>
</entry>
<entry>
<title>drm/etnaviv: fix missing unlock on error in etnaviv_iommuv1_context_alloc()</title>
<updated>2019-09-02T10:48:55+00:00</updated>
<author>
<name>Wei Yongjun</name>
<email>weiyongjun1@huawei.com</email>
</author>
<published>2019-08-19T06:17:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=dbcc574a4bfad810ce6e118f3cf327c7b6e7c897'/>
<id>urn:sha1:dbcc574a4bfad810ce6e118f3cf327c7b6e7c897</id>
<content type='text'>
Add the missing unlock before return from function etnaviv_iommuv1_context_alloc()
in the error handling case.

Fixes: 27b67278e007 ("drm/etnaviv: rework MMU handling")
Signed-off-by: Wei Yongjun &lt;weiyongjun1@huawei.com&gt;
Signed-off-by: Lucas Stach &lt;l.stach@pengutronix.de&gt;
</content>
</entry>
</feed>
