<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/gpu, branch v5.10.46</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v5.10.46</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v5.10.46'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2021-06-23T12:42:53+00:00</updated>
<entry>
<title>drm/amdgpu/gfx9: fix the doorbell missing when in CGPG issue.</title>
<updated>2021-06-23T12:42:53+00:00</updated>
<author>
<name>Yifan Zhang</name>
<email>yifan1.zhang@amd.com</email>
</author>
<published>2021-06-10T01:55:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=41984d4fbe21d7e0638212c42fdeaead76f5513d'/>
<id>urn:sha1:41984d4fbe21d7e0638212c42fdeaead76f5513d</id>
<content type='text'>
commit 4cbbe34807938e6e494e535a68d5ff64edac3f20 upstream.

If GC has entered CGPG, ringing doorbell &gt; first page doesn't wakeup GC.
Enlarge CP_MEC_DOORBELL_RANGE_UPPER to workaround this issue.

Signed-off-by: Yifan Zhang &lt;yifan1.zhang@amd.com&gt;
Reviewed-by: Felix Kuehling &lt;Felix.Kuehling@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>
</entry>
<entry>
<title>drm/amdgpu/gfx10: enlarge CP_MEC_DOORBELL_RANGE_UPPER to cover full doorbell.</title>
<updated>2021-06-23T12:42:53+00:00</updated>
<author>
<name>Yifan Zhang</name>
<email>yifan1.zhang@amd.com</email>
</author>
<published>2021-06-10T02:10:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=bc58ec307ce93a0bcb14f4cdcd8e18ac7b4ebf10'/>
<id>urn:sha1:bc58ec307ce93a0bcb14f4cdcd8e18ac7b4ebf10</id>
<content type='text'>
commit 1c0b0efd148d5b24c4932ddb3fa03c8edd6097b3 upstream.

If GC has entered CGPG, ringing doorbell &gt; first page doesn't wakeup GC.
Enlarge CP_MEC_DOORBELL_RANGE_UPPER to workaround this issue.

Signed-off-by: Yifan Zhang &lt;yifan1.zhang@amd.com&gt;
Reviewed-by: Felix Kuehling &lt;Felix.Kuehling@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>
</entry>
<entry>
<title>radeon: use memcpy_to/fromio for UVD fw upload</title>
<updated>2021-06-23T12:42:49+00:00</updated>
<author>
<name>Chen Li</name>
<email>chenli@uniontech.com</email>
</author>
<published>2021-06-04T08:43:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=57b21ef118acfc76dd1a73c1240b3bc7a17c8786'/>
<id>urn:sha1:57b21ef118acfc76dd1a73c1240b3bc7a17c8786</id>
<content type='text'>
[ Upstream commit ab8363d3875a83f4901eb1cc00ce8afd24de6c85 ]

I met a gpu addr bug recently and the kernel log
tells me the pc is memcpy/memset and link register is
radeon_uvd_resume.

As we know, in some architectures, optimized memcpy/memset
may not work well on device memory. Trival memcpy_toio/memset_io
can fix this problem.

BTW, amdgpu has already done it in:
commit ba0b2275a678 ("drm/amdgpu: use memcpy_to/fromio for UVD fw upload"),
that's why it has no this issue on the same gpu and platform.

Signed-off-by: Chen Li &lt;chenli@uniontech.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;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drm/sun4i: dw-hdmi: Make HDMI PHY into a platform device</title>
<updated>2021-06-23T12:42:49+00:00</updated>
<author>
<name>Saravana Kannan</name>
<email>saravanak@google.com</email>
</author>
<published>2021-06-07T08:58:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=360609fc8b06e8b1d5925ec4d99d752bbbd2d9dd'/>
<id>urn:sha1:360609fc8b06e8b1d5925ec4d99d752bbbd2d9dd</id>
<content type='text'>
[ Upstream commit 9bf3797796f570b34438235a6a537df85832bdad ]

On sunxi boards that use HDMI output, HDMI device probe keeps being
avoided indefinitely with these repeated messages in dmesg:

  platform 1ee0000.hdmi: probe deferral - supplier 1ef0000.hdmi-phy
    not ready

There's a fwnode_link being created with fw_devlink=on between hdmi
and hdmi-phy nodes, because both nodes have 'compatible' property set.

Fw_devlink code assumes that nodes that have compatible property
set will also have a device associated with them by some driver
eventually. This is not the case with the current sun8i-hdmi
driver.

This commit makes sun8i-hdmi-phy into a proper platform device
and fixes the display pipeline probe on sunxi boards that use HDMI.

More context: https://lkml.org/lkml/2021/5/16/203

Signed-off-by: Saravana Kannan &lt;saravanak@google.com&gt;
Signed-off-by: Ondrej Jirman &lt;megous@megous.com&gt;
Tested-by: Andre Przywara &lt;andre.przywara@arm.com&gt;
Signed-off-by: Maxime Ripard &lt;maxime@cerno.tech&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20210607085836.2827429-1-megous@megous.com
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drm/amd/amdgpu:save psp ring wptr to avoid attack</title>
<updated>2021-06-18T08:00:06+00:00</updated>
<author>
<name>Victor Zhao</name>
<email>Victor.Zhao@amd.com</email>
</author>
<published>2021-03-18T05:44:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=9250f97fd59416448299f923fba2c69c1a308a07'/>
<id>urn:sha1:9250f97fd59416448299f923fba2c69c1a308a07</id>
<content type='text'>
[ Upstream commit 2370eba9f552eaae3d8aa1f70b8e9eec5c560f9e ]

[Why]
When some tools performing psp mailbox attack, the readback value
of register can be a random value which may break psp.

[How]
Use a psp wptr cache machanism to aovid the change made by attack.

v2: unify change and add detailed reason

Signed-off-by: Victor Zhao &lt;Victor.Zhao@amd.com&gt;
Signed-off-by: Jingwen Chen &lt;Jingwen.Chen2@amd.com&gt;
Reviewed-by: Monk Liu &lt;monk.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>
</entry>
<entry>
<title>drm/amd/display: Fix potential memory leak in DMUB hw_init</title>
<updated>2021-06-18T08:00:06+00:00</updated>
<author>
<name>Roman Li</name>
<email>roman.li@amd.com</email>
</author>
<published>2021-05-10T15:58:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=9e8c2af010463197315fa54a6c17e74988b5259c'/>
<id>urn:sha1:9e8c2af010463197315fa54a6c17e74988b5259c</id>
<content type='text'>
[ Upstream commit c5699e2d863f58221044efdc3fa712dd32d55cde ]

[Why]
On resume we perform DMUB hw_init which allocates memory:
dm_resume-&gt;dm_dmub_hw_init-&gt;dc_dmub_srv_create-&gt;kzalloc
That results in memory leak in suspend/resume scenarios.

[How]
Allocate memory for the DC wrapper to DMUB only if it was not
allocated before.
No need to reallocate it on suspend/resume.

Signed-off-by: Lang Yu &lt;Lang.Yu@amd.com&gt;
Signed-off-by: Roman Li &lt;roman.li@amd.com&gt;
Reviewed-by: Nicholas Kazlauskas &lt;Nicholas.Kazlauskas@amd.com&gt;
Acked-by: Qingqing Zhuo &lt;qingqing.zhuo@amd.com&gt;
Tested-by: Daniel Wheeler &lt;daniel.wheeler@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>
</entry>
<entry>
<title>drm/amdgpu: refine amdgpu_fru_get_product_info</title>
<updated>2021-06-18T08:00:06+00:00</updated>
<author>
<name>Jiansong Chen</name>
<email>Jiansong.Chen@amd.com</email>
</author>
<published>2021-05-25T06:14:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=75fa7fbef1325ab56404b0afcd5822d11b844664'/>
<id>urn:sha1:75fa7fbef1325ab56404b0afcd5822d11b844664</id>
<content type='text'>
[ Upstream commit 5cfc912582e13b05d71fb7acc4ec69ddfa9af320 ]

1. eliminate potential array index out of bounds.
2. return meaningful value for failure.

Signed-off-by: Jiansong Chen &lt;Jiansong.Chen@amd.com&gt;
Reviewed-by: Jack Gui &lt;Jack.Gui@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>
</entry>
<entry>
<title>drm/amd/display: Allow bandwidth validation for 0 streams.</title>
<updated>2021-06-18T08:00:06+00:00</updated>
<author>
<name>Bindu Ramamurthy</name>
<email>bindu.r@amd.com</email>
</author>
<published>2021-05-20T14:06:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=34fe4ccb1fe52b5c58d3730c6732e6971dc3564b'/>
<id>urn:sha1:34fe4ccb1fe52b5c58d3730c6732e6971dc3564b</id>
<content type='text'>
[ Upstream commit ba8e59773ae59818695d1e20b8939282da80ec8c ]

[Why]
Bandwidth calculations are triggered for non zero streams, and
in case of 0 streams, these calculations were skipped with
pstate status not being updated.

[How]
As the pstate status is applicable for non zero streams, check
added for allowing 0 streams inline with dcn internal bandwidth
validations.

Signed-off-by: Bindu Ramamurthy &lt;bindu.r@amd.com&gt;
Reviewed-by: Roman Li &lt;Roman.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>
</entry>
<entry>
<title>drm/tegra: sor: Fully initialize SOR before registration</title>
<updated>2021-06-18T08:00:04+00:00</updated>
<author>
<name>Thierry Reding</name>
<email>treding@nvidia.com</email>
</author>
<published>2021-04-01T15:41:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=3c0ad70cba1f103e829bd4f233f9f4a63d30f5bb'/>
<id>urn:sha1:3c0ad70cba1f103e829bd4f233f9f4a63d30f5bb</id>
<content type='text'>
[ Upstream commit 5dea42759bcef74b0802ea64b904409bc37f9045 ]

Before registering the SOR host1x client, make sure that it is fully
initialized. This avoids a potential race condition between the SOR's
probe and the host1x device initialization in cases where the SOR is
the final sub-device to register to a host1x instance.

Reported-by: Jonathan Hunter &lt;jonathanh@nvidia.com&gt;
Signed-off-by: Thierry Reding &lt;treding@nvidia.com&gt;
Tested-by: Jon Hunter &lt;jonathanh@nvidia.com&gt;
Signed-off-by: Thierry Reding &lt;treding@nvidia.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>gpu: host1x: Split up client initalization and registration</title>
<updated>2021-06-18T08:00:04+00:00</updated>
<author>
<name>Thierry Reding</name>
<email>treding@nvidia.com</email>
</author>
<published>2021-04-01T15:41:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=9c1d492baa9128b970524b9baa4b9baa7dc01c64'/>
<id>urn:sha1:9c1d492baa9128b970524b9baa4b9baa7dc01c64</id>
<content type='text'>
[ Upstream commit 0cfe5a6e758fb20be8ad3e8f10cb087cc8033eeb ]

In some cases we may need to initialize the host1x client first before
registering it. This commit adds a new helper that will do nothing but
the initialization of the data structure.

At the same time, the initialization is removed from the registration
function. Note, however, that for simplicity we explicitly initialize
the client when the host1x_client_register() function is called, as
opposed to the low-level __host1x_client_register() function. This
allows existing callers to remain unchanged.

Signed-off-by: Thierry Reding &lt;treding@nvidia.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
</feed>
