<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/gpu/drm/amd/display, branch v5.13.1</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v5.13.1</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v5.13.1'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2021-06-02T21:58:11+00:00</updated>
<entry>
<title>amd/display: convert DRM_DEBUG_ATOMIC to drm_dbg_atomic</title>
<updated>2021-06-02T21:58:11+00:00</updated>
<author>
<name>Simon Ser</name>
<email>contact@emersion.fr</email>
</author>
<published>2021-05-26T13:55:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e7591a8d56bab89c617dae055446b6337ec32dc9'/>
<id>urn:sha1:e7591a8d56bab89c617dae055446b6337ec32dc9</id>
<content type='text'>
This allows to tie the log message to a specific DRM device.

Signed-off-by: Simon Ser &lt;contact@emersion.fr&gt;
Cc: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Cc: Harry Wentland &lt;hwentlan@amd.com&gt;
Cc: Nicholas Kazlauskas &lt;nicholas.kazlauskas@amd.com&gt;
Reviewed-by: Bas Nieuwenhuizen &lt;bas@basnieuwenhuizen.nl&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
</content>
</entry>
<entry>
<title>drm/amd/display: Fix potential memory leak in DMUB hw_init</title>
<updated>2021-06-02T21:55:10+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=c5699e2d863f58221044efdc3fa712dd32d55cde'/>
<id>urn:sha1:c5699e2d863f58221044efdc3fa712dd32d55cde</id>
<content type='text'>
[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;
</content>
</entry>
<entry>
<title>drm/amd/display: Fix overlay validation by considering cursors</title>
<updated>2021-06-02T21:51:53+00:00</updated>
<author>
<name>Rodrigo Siqueira</name>
<email>Rodrigo.Siqueira@amd.com</email>
</author>
<published>2021-05-14T11:47:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=33f409e60eb0c59a4d0d06a62ab4642a988e17f7'/>
<id>urn:sha1:33f409e60eb0c59a4d0d06a62ab4642a988e17f7</id>
<content type='text'>
A few weeks ago, we saw a two cursor issue in a ChromeOS system. We
fixed it in the commit:

 drm/amd/display: Fix two cursor duplication when using overlay
 (read the commit message for more details)

After this change, we noticed that some IGT subtests related to
kms_plane and kms_plane_scaling started to fail. After investigating
this issue, we noticed that all subtests that fail have a primary plane
covering the overlay plane, which is currently rejected by amdgpu dm.
Fail those IGT tests highlight that our verification was too broad and
compromises the overlay usage in our drive. This patch fixes this issue
by ensuring that we only reject commits where the primary plane is not
fully covered by the overlay when the cursor hardware is enabled. With
this fix, all IGT tests start to pass again, which means our overlay
support works as expected.

Cc: Tianci.Yin &lt;tianci.yin@amd.com&gt;
Cc: Harry Wentland &lt;harry.wentland@amd.com&gt;
Cc: Nicholas Choi &lt;nicholas.choi@amd.com&gt;
Cc: Bhawanpreet Lakha &lt;bhawanpreet.lakha@amd.com&gt;
Cc: Nicholas Kazlauskas &lt;Nicholas.Kazlauskas@amd.com&gt;
Cc: Mark Yacoub &lt;markyacoub@google.com&gt;
Cc: Daniel Wheeler &lt;daniel.wheeler@amd.com&gt;

Tested-by: Daniel Wheeler &lt;daniel.wheeler@amd.com&gt;
Signed-off-by: Rodrigo Siqueira &lt;Rodrigo.Siqueira@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
</content>
</entry>
<entry>
<title>drm/amd/display: Fix GPU scaling regression by FS video support</title>
<updated>2021-06-02T21:48:32+00:00</updated>
<author>
<name>Nicholas Kazlauskas</name>
<email>nicholas.kazlauskas@amd.com</email>
</author>
<published>2021-05-19T20:12:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=a53085c1d20f914590fe446d01d4546150758983'/>
<id>urn:sha1:a53085c1d20f914590fe446d01d4546150758983</id>
<content type='text'>
[Why]
FS video support regressed GPU scaling and the scaled buffer ends up
stuck in the top left of the screen at native size - full, aspect,
center scaling modes do not function.

This is because decide_crtc_timing_for_drm_display_mode() does not
get called when scaling is enabled.

[How]
Split recalculate timing and scaling into two different flags.

We don't want to call drm_mode_set_crtcinfo() for scaling, but we
do want to call it for FS video.

Optimize and move preferred_refresh calculation next to
decide_crtc_timing_for_drm_display_mode() like it used to be since
that's not used for FS video.

We don't need to copy over the VIC or polarity in the case of FS video
modes because those don't change.

Fixes: 6f59f229f8ed7a ("drm/amd/display: Skip modeset for front porch change")

Cc: Aurabindo Pillai &lt;aurabindo.pillai@amd.com&gt;
Signed-off-by: Nicholas Kazlauskas &lt;nicholas.kazlauskas@amd.com&gt;
Reviewed-by: Aurabindo Pillai &lt;aurabindo.pillai@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
</content>
</entry>
<entry>
<title>drm/amd/display: Allow bandwidth validation for 0 streams.</title>
<updated>2021-06-02T21:48:20+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=ba8e59773ae59818695d1e20b8939282da80ec8c'/>
<id>urn:sha1:ba8e59773ae59818695d1e20b8939282da80ec8c</id>
<content type='text'>
[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;
</content>
</entry>
<entry>
<title>drm/amd/display: Disconnect non-DP with no EDID</title>
<updated>2021-05-19T22:03:30+00:00</updated>
<author>
<name>Chris Park</name>
<email>Chris.Park@amd.com</email>
</author>
<published>2021-05-04T20:20:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=080039273b126eeb0185a61c045893a25dbc046e'/>
<id>urn:sha1:080039273b126eeb0185a61c045893a25dbc046e</id>
<content type='text'>
[Why]
Active DP dongles return no EDID when dongle
is connected, but VGA display is taken out.
Current driver behavior does not remove the
active display when this happens, and this is
a gap between dongle DTP and dongle behavior.

[How]
For active DP dongles and non-DP scenario,
disconnect sink on detection when no EDID
is read due to timeout.

Signed-off-by: Chris Park &lt;Chris.Park@amd.com&gt;
Reviewed-by: Nicholas Kazlauskas &lt;Nicholas.Kazlauskas@amd.com&gt;
Acked-by: Stylon Wang &lt;stylon.wang@amd.com&gt;
Tested-by: Daniel Wheeler &lt;daniel.wheeler@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
</content>
</entry>
<entry>
<title>drm/amd/display: Use the correct max downscaling value for DCN3.x family</title>
<updated>2021-05-19T21:59:06+00:00</updated>
<author>
<name>Nikola Cornij</name>
<email>nikola.cornij@amd.com</email>
</author>
<published>2021-05-07T02:46:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=84c63d040938f64a7dc195696301166e75231bf5'/>
<id>urn:sha1:84c63d040938f64a7dc195696301166e75231bf5</id>
<content type='text'>
[why]
As per spec, DCN3.x can do 6:1 downscaling and DCN2.x can do 4:1. The
max downscaling limit value for DCN2.x is 250, which means it's
calculated as 1000 / 4 = 250. For DCN3.x this then gives 1000 / 6 = 167.

[how]
Set maximum downscaling limit to 167 for DCN3.x

Signed-off-by: Nikola Cornij &lt;nikola.cornij@amd.com&gt;
Reviewed-by: Charlene Liu &lt;Charlene.Liu@amd.com&gt;
Reviewed-by: Harry Wentland &lt;Harry.Wentland@amd.com&gt;
Acked-by: Stylon Wang &lt;stylon.wang@amd.com&gt;
Tested-by: Daniel Wheeler &lt;daniel.wheeler@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Cc: stable@vger.kernel.org
</content>
</entry>
<entry>
<title>drm/amd/display: Initialize attribute for hdcp_srm sysfs file</title>
<updated>2021-05-13T14:46:06+00:00</updated>
<author>
<name>David Ward</name>
<email>david.ward@gatech.edu</email>
</author>
<published>2021-05-10T09:30:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=fe1c97d008f86f672f0e9265f180c22451ca3b9f'/>
<id>urn:sha1:fe1c97d008f86f672f0e9265f180c22451ca3b9f</id>
<content type='text'>
It is stored in dynamically allocated memory, so sysfs_bin_attr_init() must
be called to initialize it. (Note: "initialization" only sets the .attr.key
member in this struct; it does not change the value of any other members.)

Otherwise, when CONFIG_DEBUG_LOCK_ALLOC=y this message appears during boot:

    BUG: key ffff9248900cd148 has not been registered!

Fixes: 9037246bb2da ("drm/amd/display: Add sysfs interface for set/get srm")
Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1586
Reported-by: Mikhail Gavrilov &lt;mikhail.v.gavrilov@gmail.com&gt;
Signed-off-by: David Ward &lt;david.ward@gatech.edu&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Cc: stable@vger.kernel.org
</content>
</entry>
<entry>
<title>Merge tag 'amd-drm-fixes-5.13-2021-05-05' of https://gitlab.freedesktop.org/agd5f/linux into drm-next</title>
<updated>2021-05-07T02:44:51+00:00</updated>
<author>
<name>Dave Airlie</name>
<email>airlied@redhat.com</email>
</author>
<published>2021-05-07T02:44:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=0844708ac3d2dbdace70f4a6020669d56958697f'/>
<id>urn:sha1:0844708ac3d2dbdace70f4a6020669d56958697f</id>
<content type='text'>
amd-drm-fixes-5.13-2021-05-05:

amdgpu:
- MPO hang workaround
- Fix for concurrent VM flushes on vega/navi
- dcefclk is not adjustable on navi1x and newer
- MST HPD debugfs fix
- Suspend/resumes fixes
- Register VGA clients late in case driver fails to load
- Fix GEM leak in user framebuffer create
- Add support for polaris12 with 32 bit memory interface
- Fix duplicate cursor issue when using overlay
- Fix corruption with tiled surfaces on VCN3
- Add BO size and stride check to fix BO size verification

radeon:
- Fix off-by-one in power state parsing
- Fix possible memory leak in power state parsing

Signed-off-by: Dave Airlie &lt;airlied@redhat.com&gt;
From: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20210506033929.3875-1-alexander.deucher@amd.com
</content>
</entry>
<entry>
<title>drm/amd/display: Fix two cursor duplication when using overlay</title>
<updated>2021-05-04T21:35:52+00:00</updated>
<author>
<name>Rodrigo Siqueira</name>
<email>Rodrigo.Siqueira@amd.com</email>
</author>
<published>2021-04-14T00:06:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=16e9b3e58bc3fce7391539e0eb3fd167cbf9951f'/>
<id>urn:sha1:16e9b3e58bc3fce7391539e0eb3fd167cbf9951f</id>
<content type='text'>
Our driver supports overlay planes, and as expected, some userspace
compositor takes advantage of these features. If the userspace is not
enabling the cursor, they can use multiple planes as they please.
Nevertheless, we start to have constraints when userspace tries to
enable hardware cursor with various planes. Basically, we cannot draw
the cursor at the same size and position on two separated pipes since it
uses extra bandwidth and DML only run with one cursor.

For those reasons, when we enable hardware cursor and multiple planes,
our driver should accept variations like the ones described below:

  +-------------+   +--------------+
  | +---------+ |   |              |
  | |Primary  | |   | Primary      |
  | |         | |   | Overlay      |
  | +---------+ |   |              |
  |Overlay      |   |              |
  +-------------+   +--------------+

In this scenario, we can have the desktop UI in the overlay and some
other framebuffer attached to the primary plane (e.g., video). However,
userspace needs to obey some rules and avoid scenarios like the ones
described below (when enabling hw cursor):

                                      +--------+
                                      |Overlay |
 +-------------+    +-----+-------+ +-|        |--+
 | +--------+  | +--------+       | | +--------+  |
 | |Overlay |  | |Overlay |       | |             |
 | |        |  | |        |       | |             |
 | +--------+  | +--------+       | |             |
 | Primary     |    | Primary     | | Primary     |
 +-------------+    +-------------+ +-------------+

 +-------------+   +-------------+
 |     +--------+  |  Primary    |
 |     |Overlay |  |             |
 |     |        |  |             |
 |     +--------+  | +--------+  |
 | Primary     |   | |Overlay |  |
 +-------------+   +-|        |--+
                     +--------+

If the userspace violates some of the above scenarios, our driver needs
to reject the commit; otherwise, we can have unexpected behavior. Since
we don't have a proper driver validation for the above case, we can see
some problems like a duplicate cursor in applications that use multiple
planes. This commit fixes the cursor issue and others by adding adequate
verification for multiple planes.

Change since V1 (Harry and Sean):
- Remove cursor verification from the equation.

Cc: Louis Li &lt;Ching-shih.Li@amd.com&gt;
Cc: Nicholas Kazlauskas &lt;Nicholas.Kazlauskas@amd.com&gt;
Cc: Harry Wentland &lt;Harry.Wentland@amd.com&gt;
Cc: Hersen Wu &lt;hersenxs.wu@amd.com&gt;
Cc: Sean Paul &lt;seanpaul@chromium.org&gt;
Signed-off-by: Rodrigo Siqueira &lt;Rodrigo.Siqueira@amd.com&gt;
Reviewed-by: Harry Wentland &lt;harry.wentland@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
</content>
</entry>
</feed>
