<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/drivers/gpu, branch v5.4.32</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>drm/i915: Fix ref-&gt;mutex deadlock in i915_active_wait()</title>
<updated>2020-04-13T08:48:15+00:00</updated>
<author>
<name>Sultan Alsawaf</name>
<email>sultan@kerneltoast.com</email>
</author>
<published>2020-04-07T20:32:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=04ad505eed58f442b8d55004df10456ab2f0ec08'/>
<id>04ad505eed58f442b8d55004df10456ab2f0ec08</id>
<content type='text'>
The following deadlock exists in i915_active_wait() due to a double lock
on ref-&gt;mutex (call chain listed in order from top to bottom):
 i915_active_wait();
 mutex_lock_interruptible(&amp;ref-&gt;mutex); &lt;-- ref-&gt;mutex first acquired
 i915_active_request_retire();
 node_retire();
 active_retire();
 mutex_lock_nested(&amp;ref-&gt;mutex, SINGLE_DEPTH_NESTING); &lt;-- DEADLOCK

Fix the deadlock by skipping the second ref-&gt;mutex lock when
active_retire() is called through i915_active_request_retire().

Note that this bug only affects 5.4 and has since been fixed in 5.5.
Normally, a backport of the fix from 5.5 would be in order, but the
patch set that fixes this deadlock involves massive changes that are
neither feasible nor desirable for backporting [1][2][3]. Therefore,
this small patch was made to address the deadlock specifically for 5.4.

[1] 274cbf20fd10 ("drm/i915: Push the i915_active.retire into a worker")
[2] 093b92287363 ("drm/i915: Split i915_active.mutex into an irq-safe spinlock for the rbtree")
[3] 750bde2fd4ff ("drm/i915: Serialise with remote retirement")

Fixes: 12c255b5dad1 ("drm/i915: Provide an i915_active.acquire callback")
Cc: &lt;stable@vger.kernel.org&gt; # 5.4.x
Signed-off-by: Sultan Alsawaf &lt;sultan@kerneltoast.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The following deadlock exists in i915_active_wait() due to a double lock
on ref-&gt;mutex (call chain listed in order from top to bottom):
 i915_active_wait();
 mutex_lock_interruptible(&amp;ref-&gt;mutex); &lt;-- ref-&gt;mutex first acquired
 i915_active_request_retire();
 node_retire();
 active_retire();
 mutex_lock_nested(&amp;ref-&gt;mutex, SINGLE_DEPTH_NESTING); &lt;-- DEADLOCK

Fix the deadlock by skipping the second ref-&gt;mutex lock when
active_retire() is called through i915_active_request_retire().

Note that this bug only affects 5.4 and has since been fixed in 5.5.
Normally, a backport of the fix from 5.5 would be in order, but the
patch set that fixes this deadlock involves massive changes that are
neither feasible nor desirable for backporting [1][2][3]. Therefore,
this small patch was made to address the deadlock specifically for 5.4.

[1] 274cbf20fd10 ("drm/i915: Push the i915_active.retire into a worker")
[2] 093b92287363 ("drm/i915: Split i915_active.mutex into an irq-safe spinlock for the rbtree")
[3] 750bde2fd4ff ("drm/i915: Serialise with remote retirement")

Fixes: 12c255b5dad1 ("drm/i915: Provide an i915_active.acquire callback")
Cc: &lt;stable@vger.kernel.org&gt; # 5.4.x
Signed-off-by: Sultan Alsawaf &lt;sultan@kerneltoast.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>drm/amdgpu: fix typo for vcn1 idle check</title>
<updated>2020-04-08T07:08:39+00:00</updated>
<author>
<name>James Zhu</name>
<email>James.Zhu@amd.com</email>
</author>
<published>2020-03-18T21:09:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=7ebc1e53a46b5256438988bfec15a50b941b04f1'/>
<id>7ebc1e53a46b5256438988bfec15a50b941b04f1</id>
<content type='text'>
[ Upstream commit acfc62dc68770aa665cc606891f6df7d6d1e52c0 ]

fix typo for vcn1 idle check

Signed-off-by: James Zhu &lt;James.Zhu@amd.com&gt;
Reviewed-by: Leo Liu &lt;leo.liu@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit acfc62dc68770aa665cc606891f6df7d6d1e52c0 ]

fix typo for vcn1 idle check

Signed-off-by: James Zhu &lt;James.Zhu@amd.com&gt;
Reviewed-by: Leo Liu &lt;leo.liu@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/bochs: downgrade pci_request_region failure from error to warning</title>
<updated>2020-04-08T07:08:38+00:00</updated>
<author>
<name>Gerd Hoffmann</name>
<email>kraxel@redhat.com</email>
</author>
<published>2020-03-13T08:41:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=4a8ba74c1c64842b27e9ad42e238a994ae0dd3e5'/>
<id>4a8ba74c1c64842b27e9ad42e238a994ae0dd3e5</id>
<content type='text'>
[ Upstream commit 8c34cd1a7f089dc03933289c5d4a4d1489549828 ]

Shutdown of firmware framebuffer has a bunch of problems.  Because
of this the framebuffer region might still be reserved even after
drm_fb_helper_remove_conflicting_pci_framebuffers() returned.

Don't consider pci_request_region() failure for the framebuffer
region as fatal error to workaround this issue.

Reported-by: Marek Marczykowski-Górecki &lt;marmarek@invisiblethingslab.com&gt;
Signed-off-by: Gerd Hoffmann &lt;kraxel@redhat.com&gt;
Acked-by: Sam Ravnborg &lt;sam@ravnborg.org&gt;
Link: http://patchwork.freedesktop.org/patch/msgid/20200313084152.2734-1-kraxel@redhat.com
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 8c34cd1a7f089dc03933289c5d4a4d1489549828 ]

Shutdown of firmware framebuffer has a bunch of problems.  Because
of this the framebuffer region might still be reserved even after
drm_fb_helper_remove_conflicting_pci_framebuffers() returned.

Don't consider pci_request_region() failure for the framebuffer
region as fatal error to workaround this issue.

Reported-by: Marek Marczykowski-Górecki &lt;marmarek@invisiblethingslab.com&gt;
Signed-off-by: Gerd Hoffmann &lt;kraxel@redhat.com&gt;
Acked-by: Sam Ravnborg &lt;sam@ravnborg.org&gt;
Link: http://patchwork.freedesktop.org/patch/msgid/20200313084152.2734-1-kraxel@redhat.com
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/amd/display: Add link_rate quirk for Apple 15" MBP 2017</title>
<updated>2020-04-08T07:08:38+00:00</updated>
<author>
<name>Mario Kleiner</name>
<email>mario.kleiner.de@gmail.com</email>
</author>
<published>2020-02-28T21:36:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=f8abcff4fd0db7c54b9c48e1202e9f7660098573'/>
<id>f8abcff4fd0db7c54b9c48e1202e9f7660098573</id>
<content type='text'>
[ Upstream commit dec9de2ada523b344eb2428abfedf9d6cd0a0029 ]

This fixes a problem found on the MacBookPro 2017 Retina panel:

The panel reports 10 bpc color depth in its EDID, and the
firmware chooses link settings at boot which support enough
bandwidth for 10 bpc (324000 kbit/sec aka LINK_RATE_RBR2
aka 0xc), but the DP_MAX_LINK_RATE dpcd register only reports
2.7 Gbps (multiplier value 0xa) as possible, in direct
contradiction of what the firmware successfully set up.

This restricts the panel to 8 bpc, not providing the full
color depth of the panel on Linux &lt;= 5.5. Additionally, commit
'4a8ca46bae8a ("drm/amd/display: Default max bpc to 16 for eDP")'
introduced into Linux 5.6-rc1 will unclamp panel depth to
its full 10 bpc, thereby requiring a eDP bandwidth for all
modes that exceeds the bandwidth available and causes all modes
to fail validation -&gt; No modes for the laptop panel -&gt; failure
to set any mode -&gt; Panel goes dark.

This patch adds a quirk specific to the MBP 2017 15" Retina
panel to override reported max link rate to the correct maximum
of 0xc = LINK_RATE_RBR2 to fix the darkness and reduced display
precision.

Please apply for Linux 5.6+ to avoid regressing Apple MBP panel
support.

Signed-off-by: Mario Kleiner &lt;mario.kleiner.de@gmail.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit dec9de2ada523b344eb2428abfedf9d6cd0a0029 ]

This fixes a problem found on the MacBookPro 2017 Retina panel:

The panel reports 10 bpc color depth in its EDID, and the
firmware chooses link settings at boot which support enough
bandwidth for 10 bpc (324000 kbit/sec aka LINK_RATE_RBR2
aka 0xc), but the DP_MAX_LINK_RATE dpcd register only reports
2.7 Gbps (multiplier value 0xa) as possible, in direct
contradiction of what the firmware successfully set up.

This restricts the panel to 8 bpc, not providing the full
color depth of the panel on Linux &lt;= 5.5. Additionally, commit
'4a8ca46bae8a ("drm/amd/display: Default max bpc to 16 for eDP")'
introduced into Linux 5.6-rc1 will unclamp panel depth to
its full 10 bpc, thereby requiring a eDP bandwidth for all
modes that exceeds the bandwidth available and causes all modes
to fail validation -&gt; No modes for the laptop panel -&gt; failure
to set any mode -&gt; Panel goes dark.

This patch adds a quirk specific to the MBP 2017 15" Retina
panel to override reported max link rate to the correct maximum
of 0xc = LINK_RATE_RBR2 to fix the darkness and reduced display
precision.

Please apply for Linux 5.6+ to avoid regressing Apple MBP panel
support.

Signed-off-by: Mario Kleiner &lt;mario.kleiner.de@gmail.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/exynos: Fix cleanup of IOMMU related objects</title>
<updated>2020-04-01T09:01:53+00:00</updated>
<author>
<name>Marek Szyprowski</name>
<email>m.szyprowski@samsung.com</email>
</author>
<published>2020-03-09T11:02:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=957e6f437d022ce780ae9aef3a76038c4603123b'/>
<id>957e6f437d022ce780ae9aef3a76038c4603123b</id>
<content type='text'>
[ Upstream commit 07dc3678bacc2a75b1900febea7d996a31f178a2 ]

Store the IOMMU mapping created by the device core of each Exynos DRM
sub-device and restore it when the Exynos DRM driver is unbound. This
fixes IOMMU initialization failure for the second time when a deferred
probe is triggered from the bind() callback of master's compound DRM
driver. This also fixes the following issue found using kmemleak
detector:

unreferenced object 0xc2137640 (size 64):
  comm "swapper/0", pid 1, jiffies 4294937900 (age 3127.400s)
  hex dump (first 32 bytes):
    50 a3 14 c2 80 a2 14 c2 01 00 00 00 20 00 00 00  P........... ...
    00 10 00 00 00 80 00 00 00 00 00 00 00 00 00 00  ................
  backtrace:
    [&lt;3acd268d&gt;] arch_setup_dma_ops+0x4c/0x104
    [&lt;9f7d2cce&gt;] of_dma_configure+0x19c/0x3a4
    [&lt;ba07704b&gt;] really_probe+0xb0/0x47c
    [&lt;4f510e4f&gt;] driver_probe_device+0x78/0x1c4
    [&lt;7481a0cf&gt;] device_driver_attach+0x58/0x60
    [&lt;0ff8f5c1&gt;] __driver_attach+0xb8/0x158
    [&lt;86006144&gt;] bus_for_each_dev+0x74/0xb4
    [&lt;10159dca&gt;] bus_add_driver+0x1c0/0x200
    [&lt;8a265265&gt;] driver_register+0x74/0x108
    [&lt;e0f3451a&gt;] exynos_drm_init+0xb0/0x134
    [&lt;db3fc7ba&gt;] do_one_initcall+0x90/0x458
    [&lt;6da35917&gt;] kernel_init_freeable+0x188/0x200
    [&lt;db3f74d4&gt;] kernel_init+0x8/0x110
    [&lt;1f3cddf9&gt;] ret_from_fork+0x14/0x20
    [&lt;8cd12507&gt;] 0x0
unreferenced object 0xc214a280 (size 128):
  comm "swapper/0", pid 1, jiffies 4294937900 (age 3127.400s)
  hex dump (first 32 bytes):
    00 a0 ec ed 00 00 00 00 00 00 00 00 00 00 00 00  ................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace:
    [&lt;3acd268d&gt;] arch_setup_dma_ops+0x4c/0x104
    [&lt;9f7d2cce&gt;] of_dma_configure+0x19c/0x3a4
    [&lt;ba07704b&gt;] really_probe+0xb0/0x47c
    [&lt;4f510e4f&gt;] driver_probe_device+0x78/0x1c4
    [&lt;7481a0cf&gt;] device_driver_attach+0x58/0x60
    [&lt;0ff8f5c1&gt;] __driver_attach+0xb8/0x158
    [&lt;86006144&gt;] bus_for_each_dev+0x74/0xb4
    [&lt;10159dca&gt;] bus_add_driver+0x1c0/0x200
    [&lt;8a265265&gt;] driver_register+0x74/0x108
    [&lt;e0f3451a&gt;] exynos_drm_init+0xb0/0x134
    [&lt;db3fc7ba&gt;] do_one_initcall+0x90/0x458
    [&lt;6da35917&gt;] kernel_init_freeable+0x188/0x200
    [&lt;db3f74d4&gt;] kernel_init+0x8/0x110
    [&lt;1f3cddf9&gt;] ret_from_fork+0x14/0x20
    [&lt;8cd12507&gt;] 0x0
unreferenced object 0xedeca000 (size 4096):
  comm "swapper/0", pid 1, jiffies 4294937900 (age 3127.400s)
  hex dump (first 32 bytes):
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace:
    [&lt;3acd268d&gt;] arch_setup_dma_ops+0x4c/0x104
    [&lt;9f7d2cce&gt;] of_dma_configure+0x19c/0x3a4
    [&lt;ba07704b&gt;] really_probe+0xb0/0x47c
    [&lt;4f510e4f&gt;] driver_probe_device+0x78/0x1c4
    [&lt;7481a0cf&gt;] device_driver_attach+0x58/0x60
    [&lt;0ff8f5c1&gt;] __driver_attach+0xb8/0x158
    [&lt;86006144&gt;] bus_for_each_dev+0x74/0xb4
    [&lt;10159dca&gt;] bus_add_driver+0x1c0/0x200
    [&lt;8a265265&gt;] driver_register+0x74/0x108
    [&lt;e0f3451a&gt;] exynos_drm_init+0xb0/0x134
    [&lt;db3fc7ba&gt;] do_one_initcall+0x90/0x458
    [&lt;6da35917&gt;] kernel_init_freeable+0x188/0x200
    [&lt;db3f74d4&gt;] kernel_init+0x8/0x110
    [&lt;1f3cddf9&gt;] ret_from_fork+0x14/0x20
    [&lt;8cd12507&gt;] 0x0
unreferenced object 0xc214a300 (size 128):
  comm "swapper/0", pid 1, jiffies 4294937900 (age 3127.400s)
  hex dump (first 32 bytes):
    00 a3 14 c2 00 a3 14 c2 00 40 18 c2 00 80 18 c2  .........@......
    02 00 02 00 ad 4e ad de ff ff ff ff ff ff ff ff  .....N..........
  backtrace:
    [&lt;08cbd8bc&gt;] iommu_domain_alloc+0x24/0x50
    [&lt;b835abee&gt;] arm_iommu_create_mapping+0xe4/0x134
    [&lt;3acd268d&gt;] arch_setup_dma_ops+0x4c/0x104
    [&lt;9f7d2cce&gt;] of_dma_configure+0x19c/0x3a4
    [&lt;ba07704b&gt;] really_probe+0xb0/0x47c
    [&lt;4f510e4f&gt;] driver_probe_device+0x78/0x1c4
    [&lt;7481a0cf&gt;] device_driver_attach+0x58/0x60
    [&lt;0ff8f5c1&gt;] __driver_attach+0xb8/0x158
    [&lt;86006144&gt;] bus_for_each_dev+0x74/0xb4
    [&lt;10159dca&gt;] bus_add_driver+0x1c0/0x200
    [&lt;8a265265&gt;] driver_register+0x74/0x108
    [&lt;e0f3451a&gt;] exynos_drm_init+0xb0/0x134
    [&lt;db3fc7ba&gt;] do_one_initcall+0x90/0x458
    [&lt;6da35917&gt;] kernel_init_freeable+0x188/0x200
    [&lt;db3f74d4&gt;] kernel_init+0x8/0x110
    [&lt;1f3cddf9&gt;] ret_from_fork+0x14/0x20

Signed-off-by: Marek Szyprowski &lt;m.szyprowski@samsung.com&gt;
Reviewed-by: Lukasz Luba &lt;lukasz.luba@arm.com&gt;
Signed-off-by: Inki Dae &lt;inki.dae@samsung.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 07dc3678bacc2a75b1900febea7d996a31f178a2 ]

Store the IOMMU mapping created by the device core of each Exynos DRM
sub-device and restore it when the Exynos DRM driver is unbound. This
fixes IOMMU initialization failure for the second time when a deferred
probe is triggered from the bind() callback of master's compound DRM
driver. This also fixes the following issue found using kmemleak
detector:

unreferenced object 0xc2137640 (size 64):
  comm "swapper/0", pid 1, jiffies 4294937900 (age 3127.400s)
  hex dump (first 32 bytes):
    50 a3 14 c2 80 a2 14 c2 01 00 00 00 20 00 00 00  P........... ...
    00 10 00 00 00 80 00 00 00 00 00 00 00 00 00 00  ................
  backtrace:
    [&lt;3acd268d&gt;] arch_setup_dma_ops+0x4c/0x104
    [&lt;9f7d2cce&gt;] of_dma_configure+0x19c/0x3a4
    [&lt;ba07704b&gt;] really_probe+0xb0/0x47c
    [&lt;4f510e4f&gt;] driver_probe_device+0x78/0x1c4
    [&lt;7481a0cf&gt;] device_driver_attach+0x58/0x60
    [&lt;0ff8f5c1&gt;] __driver_attach+0xb8/0x158
    [&lt;86006144&gt;] bus_for_each_dev+0x74/0xb4
    [&lt;10159dca&gt;] bus_add_driver+0x1c0/0x200
    [&lt;8a265265&gt;] driver_register+0x74/0x108
    [&lt;e0f3451a&gt;] exynos_drm_init+0xb0/0x134
    [&lt;db3fc7ba&gt;] do_one_initcall+0x90/0x458
    [&lt;6da35917&gt;] kernel_init_freeable+0x188/0x200
    [&lt;db3f74d4&gt;] kernel_init+0x8/0x110
    [&lt;1f3cddf9&gt;] ret_from_fork+0x14/0x20
    [&lt;8cd12507&gt;] 0x0
unreferenced object 0xc214a280 (size 128):
  comm "swapper/0", pid 1, jiffies 4294937900 (age 3127.400s)
  hex dump (first 32 bytes):
    00 a0 ec ed 00 00 00 00 00 00 00 00 00 00 00 00  ................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace:
    [&lt;3acd268d&gt;] arch_setup_dma_ops+0x4c/0x104
    [&lt;9f7d2cce&gt;] of_dma_configure+0x19c/0x3a4
    [&lt;ba07704b&gt;] really_probe+0xb0/0x47c
    [&lt;4f510e4f&gt;] driver_probe_device+0x78/0x1c4
    [&lt;7481a0cf&gt;] device_driver_attach+0x58/0x60
    [&lt;0ff8f5c1&gt;] __driver_attach+0xb8/0x158
    [&lt;86006144&gt;] bus_for_each_dev+0x74/0xb4
    [&lt;10159dca&gt;] bus_add_driver+0x1c0/0x200
    [&lt;8a265265&gt;] driver_register+0x74/0x108
    [&lt;e0f3451a&gt;] exynos_drm_init+0xb0/0x134
    [&lt;db3fc7ba&gt;] do_one_initcall+0x90/0x458
    [&lt;6da35917&gt;] kernel_init_freeable+0x188/0x200
    [&lt;db3f74d4&gt;] kernel_init+0x8/0x110
    [&lt;1f3cddf9&gt;] ret_from_fork+0x14/0x20
    [&lt;8cd12507&gt;] 0x0
unreferenced object 0xedeca000 (size 4096):
  comm "swapper/0", pid 1, jiffies 4294937900 (age 3127.400s)
  hex dump (first 32 bytes):
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace:
    [&lt;3acd268d&gt;] arch_setup_dma_ops+0x4c/0x104
    [&lt;9f7d2cce&gt;] of_dma_configure+0x19c/0x3a4
    [&lt;ba07704b&gt;] really_probe+0xb0/0x47c
    [&lt;4f510e4f&gt;] driver_probe_device+0x78/0x1c4
    [&lt;7481a0cf&gt;] device_driver_attach+0x58/0x60
    [&lt;0ff8f5c1&gt;] __driver_attach+0xb8/0x158
    [&lt;86006144&gt;] bus_for_each_dev+0x74/0xb4
    [&lt;10159dca&gt;] bus_add_driver+0x1c0/0x200
    [&lt;8a265265&gt;] driver_register+0x74/0x108
    [&lt;e0f3451a&gt;] exynos_drm_init+0xb0/0x134
    [&lt;db3fc7ba&gt;] do_one_initcall+0x90/0x458
    [&lt;6da35917&gt;] kernel_init_freeable+0x188/0x200
    [&lt;db3f74d4&gt;] kernel_init+0x8/0x110
    [&lt;1f3cddf9&gt;] ret_from_fork+0x14/0x20
    [&lt;8cd12507&gt;] 0x0
unreferenced object 0xc214a300 (size 128):
  comm "swapper/0", pid 1, jiffies 4294937900 (age 3127.400s)
  hex dump (first 32 bytes):
    00 a3 14 c2 00 a3 14 c2 00 40 18 c2 00 80 18 c2  .........@......
    02 00 02 00 ad 4e ad de ff ff ff ff ff ff ff ff  .....N..........
  backtrace:
    [&lt;08cbd8bc&gt;] iommu_domain_alloc+0x24/0x50
    [&lt;b835abee&gt;] arm_iommu_create_mapping+0xe4/0x134
    [&lt;3acd268d&gt;] arch_setup_dma_ops+0x4c/0x104
    [&lt;9f7d2cce&gt;] of_dma_configure+0x19c/0x3a4
    [&lt;ba07704b&gt;] really_probe+0xb0/0x47c
    [&lt;4f510e4f&gt;] driver_probe_device+0x78/0x1c4
    [&lt;7481a0cf&gt;] device_driver_attach+0x58/0x60
    [&lt;0ff8f5c1&gt;] __driver_attach+0xb8/0x158
    [&lt;86006144&gt;] bus_for_each_dev+0x74/0xb4
    [&lt;10159dca&gt;] bus_add_driver+0x1c0/0x200
    [&lt;8a265265&gt;] driver_register+0x74/0x108
    [&lt;e0f3451a&gt;] exynos_drm_init+0xb0/0x134
    [&lt;db3fc7ba&gt;] do_one_initcall+0x90/0x458
    [&lt;6da35917&gt;] kernel_init_freeable+0x188/0x200
    [&lt;db3f74d4&gt;] kernel_init+0x8/0x110
    [&lt;1f3cddf9&gt;] ret_from_fork+0x14/0x20

Signed-off-by: Marek Szyprowski &lt;m.szyprowski@samsung.com&gt;
Reviewed-by: Lukasz Luba &lt;lukasz.luba@arm.com&gt;
Signed-off-by: Inki Dae &lt;inki.dae@samsung.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/amdgpu: correct ROM_INDEX/DATA offset for VEGA20</title>
<updated>2020-04-01T09:01:53+00:00</updated>
<author>
<name>Hawking Zhang</name>
<email>Hawking.Zhang@amd.com</email>
</author>
<published>2020-03-04T09:03:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=70e0a720038ed591e082b9218c7afbb34060d3b7'/>
<id>70e0a720038ed591e082b9218c7afbb34060d3b7</id>
<content type='text'>
[ Upstream commit f1c2cd3f8fb959123a9beba18c0e8112dcb2e137 ]

The ROMC_INDEX/DATA offset was changed to e4/e5 since
from smuio_v11 (vega20/arcturus).

Signed-off-by: Hawking Zhang &lt;Hawking.Zhang@amd.com&gt;
Tested-by: Candice Li &lt;Candice.Li@amd.com&gt;
Reviewed-by: Candice Li &lt;Candice.Li@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit f1c2cd3f8fb959123a9beba18c0e8112dcb2e137 ]

The ROMC_INDEX/DATA offset was changed to e4/e5 since
from smuio_v11 (vega20/arcturus).

Signed-off-by: Hawking Zhang &lt;Hawking.Zhang@amd.com&gt;
Tested-by: Candice Li &lt;Candice.Li@amd.com&gt;
Reviewed-by: Candice Li &lt;Candice.Li@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/amd/display: update soc bb for nv14</title>
<updated>2020-04-01T09:01:52+00:00</updated>
<author>
<name>Martin Leung</name>
<email>martin.leung@amd.com</email>
</author>
<published>2020-02-24T19:07:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=2e89e4e7f7e18c907898f1ffdce3569e64149776'/>
<id>2e89e4e7f7e18c907898f1ffdce3569e64149776</id>
<content type='text'>
[ Upstream commit d5349775c1726ce997b8eb4982cd85a01f1c8b42 ]

[why]
nv14 previously inherited soc bb from generic dcn 2, did not match
watermark values according to memory team

[how]
add nv14 specific soc bb: copy nv2 generic that it was
using from before, but changed num channels to 8

Signed-off-by: Martin Leung &lt;martin.leung@amd.com&gt;
Reviewed-by: Jun Lei &lt;Jun.Lei@amd.com&gt;
Acked-by: Rodrigo Siqueira &lt;Rodrigo.Siqueira@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit d5349775c1726ce997b8eb4982cd85a01f1c8b42 ]

[why]
nv14 previously inherited soc bb from generic dcn 2, did not match
watermark values according to memory team

[how]
add nv14 specific soc bb: copy nv2 generic that it was
using from before, but changed num channels to 8

Signed-off-by: Martin Leung &lt;martin.leung@amd.com&gt;
Reviewed-by: Jun Lei &lt;Jun.Lei@amd.com&gt;
Acked-by: Rodrigo Siqueira &lt;Rodrigo.Siqueira@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/bridge: dw-hdmi: fix AVI frame colorimetry</title>
<updated>2020-03-25T07:25:59+00:00</updated>
<author>
<name>Jernej Skrabec</name>
<email>jernej.skrabec@siol.net</email>
</author>
<published>2020-03-04T23:25:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=58ffe6b0245eba57c97857ddce2cd356da988a4a'/>
<id>58ffe6b0245eba57c97857ddce2cd356da988a4a</id>
<content type='text'>
commit e8dca30f7118461d47e1c3510d0e31b277439151 upstream.

CTA-861-F explicitly states that for RGB colorspace colorimetry should
be set to "none". Fix that.

Acked-by: Laurent Pinchart &lt;laurent.pinchart@ideasonboard.com&gt;
Fixes: def23aa7e982 ("drm: bridge: dw-hdmi: Switch to V4L bus format and encodings")
Signed-off-by: Jernej Skrabec &lt;jernej.skrabec@siol.net&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20200304232512.51616-2-jernej.skrabec@siol.net
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit e8dca30f7118461d47e1c3510d0e31b277439151 upstream.

CTA-861-F explicitly states that for RGB colorspace colorimetry should
be set to "none". Fix that.

Acked-by: Laurent Pinchart &lt;laurent.pinchart@ideasonboard.com&gt;
Fixes: def23aa7e982 ("drm: bridge: dw-hdmi: Switch to V4L bus format and encodings")
Signed-off-by: Jernej Skrabec &lt;jernej.skrabec@siol.net&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20200304232512.51616-2-jernej.skrabec@siol.net
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>drm/lease: fix WARNING in idr_destroy</title>
<updated>2020-03-25T07:25:56+00:00</updated>
<author>
<name>Qiujun Huang</name>
<email>hqjagain@gmail.com</email>
</author>
<published>2020-03-18T07:53:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=f7ef7a020f3bf51effc0501f7012e32e5faf1a75'/>
<id>f7ef7a020f3bf51effc0501f7012e32e5faf1a75</id>
<content type='text'>
commit b216a8e7908cd750550c0480cf7d2b3a37f06954 upstream.

drm_lease_create takes ownership of leases. And leases will be released
by drm_master_put.

drm_master_put
    -&gt;drm_master_destroy
            -&gt;idr_destroy

So we needn't call idr_destroy again.

Reported-and-tested-by: syzbot+05835159fe322770fe3d@syzkaller.appspotmail.com
Signed-off-by: Qiujun Huang &lt;hqjagain@gmail.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/1584518030-4173-1-git-send-email-hqjagain@gmail.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit b216a8e7908cd750550c0480cf7d2b3a37f06954 upstream.

drm_lease_create takes ownership of leases. And leases will be released
by drm_master_put.

drm_master_put
    -&gt;drm_master_destroy
            -&gt;idr_destroy

So we needn't call idr_destroy again.

Reported-and-tested-by: syzbot+05835159fe322770fe3d@syzkaller.appspotmail.com
Signed-off-by: Qiujun Huang &lt;hqjagain@gmail.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/1584518030-4173-1-git-send-email-hqjagain@gmail.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>drm/amd/amdgpu: Fix GPR read from debugfs (v2)</title>
<updated>2020-03-25T07:25:56+00:00</updated>
<author>
<name>Tom St Denis</name>
<email>tom.stdenis@amd.com</email>
</author>
<published>2020-03-10T12:40:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=b4e798cab8e91d4dfb90d2d349326e292002122b'/>
<id>b4e798cab8e91d4dfb90d2d349326e292002122b</id>
<content type='text'>
commit 5bbc6604a62814511c32f2e39bc9ffb2c1b92cbe upstream.

The offset into the array was specified in bytes but should
be in terms of 32-bit words.  Also prevent large reads that
would also cause a buffer overread.

v2:  Read from correct offset from internal storage buffer.

Signed-off-by: Tom St Denis &lt;tom.stdenis@amd.com&gt;
Acked-by: Christian König &lt;christian.koenig@amd.com&gt;
Reviewed-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 5bbc6604a62814511c32f2e39bc9ffb2c1b92cbe upstream.

The offset into the array was specified in bytes but should
be in terms of 32-bit words.  Also prevent large reads that
would also cause a buffer overread.

v2:  Read from correct offset from internal storage buffer.

Signed-off-by: Tom St Denis &lt;tom.stdenis@amd.com&gt;
Acked-by: Christian König &lt;christian.koenig@amd.com&gt;
Reviewed-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
</feed>
