<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/gpu/drm/amd/display/dc, branch v5.4.267</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v5.4.267</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v5.4.267'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2023-11-28T16:50:16+00:00</updated>
<entry>
<title>drm/amd/display: Avoid NULL dereference of timing generator</title>
<updated>2023-11-28T16:50:16+00:00</updated>
<author>
<name>Wayne Lin</name>
<email>wayne.lin@amd.com</email>
</author>
<published>2023-09-08T02:14:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=eac3e4760aa12159f7f5475d55a67b7933abc195'/>
<id>urn:sha1:eac3e4760aa12159f7f5475d55a67b7933abc195</id>
<content type='text'>
[ Upstream commit b1904ed480cee3f9f4036ea0e36d139cb5fee2d6 ]

[Why &amp; How]
Check whether assigned timing generator is NULL or not before
accessing its funcs to prevent NULL dereference.

Reviewed-by: Jun Lei &lt;jun.lei@amd.com&gt;
Acked-by: Hersen Wu &lt;hersenxs.wu@amd.com&gt;
Signed-off-by: Wayne Lin &lt;wayne.lin@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/amd/display: Fix a bug when searching for insert_above_mpcc</title>
<updated>2023-09-23T09:00:02+00:00</updated>
<author>
<name>Wesley Chalmers</name>
<email>wesley.chalmers@amd.com</email>
</author>
<published>2023-06-21T23:13:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=4316b8294503b6e6fdc48c85fc190e506c46aeb5'/>
<id>urn:sha1:4316b8294503b6e6fdc48c85fc190e506c46aeb5</id>
<content type='text'>
commit 3d028d5d60d516c536de1ddd3ebf3d55f3f8983b upstream.

[WHY]
Currently, when insert_plane is called with insert_above_mpcc
parameter that is equal to tree-&gt;opp_list, the function returns NULL.

[HOW]
Instead, the function should insert the plane at the top of the tree.

Cc: Mario Limonciello &lt;mario.limonciello@amd.com&gt;
Cc: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Cc: stable@vger.kernel.org
Reviewed-by: Jun Lei &lt;jun.lei@amd.com&gt;
Acked-by: Tom Chung &lt;chiahsuan.chung@amd.com&gt;
Signed-off-by: Wesley Chalmers &lt;wesley.chalmers@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: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>drm/amd/display: check TG is non-null before checking if enabled</title>
<updated>2023-08-30T14:27:23+00:00</updated>
<author>
<name>Taimur Hassan</name>
<email>syed.hassan@amd.com</email>
</author>
<published>2023-06-20T21:00:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=c8920972d0861cbe85322c2a3cb6d2296d48a48d'/>
<id>urn:sha1:c8920972d0861cbe85322c2a3cb6d2296d48a48d</id>
<content type='text'>
[ Upstream commit 5a25cefc0920088bb9afafeb80ad3dcd84fe278b ]

[Why &amp; How]
If there is no TG allocation we can dereference a NULL pointer when
checking if the TG is enabled.

Cc: Mario Limonciello &lt;mario.limonciello@amd.com&gt;
Cc: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Cc: stable@vger.kernel.org
Reviewed-by: Nicholas Kazlauskas &lt;nicholas.kazlauskas@amd.com&gt;
Acked-by: Alan Liu &lt;haoping.liu@amd.com&gt;
Signed-off-by: Taimur Hassan &lt;syed.hassan@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/amd/display: do not wait for mpc idle if tg is disabled</title>
<updated>2023-08-30T14:27:23+00:00</updated>
<author>
<name>Josip Pavic</name>
<email>Josip.Pavic@amd.com</email>
</author>
<published>2022-03-24T16:08:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=7d4174a99b1d122c22301f27c843cd4f06ff1449'/>
<id>urn:sha1:7d4174a99b1d122c22301f27c843cd4f06ff1449</id>
<content type='text'>
[ Upstream commit 2513ed4f937999c0446fd824f7564f76b697d722 ]

[Why]
When booting, the driver waits for the MPC idle bit to be set as part of
pipe initialization. However, on some systems this occurs before OTG is
enabled, and since the MPC idle bit won't be set until the vupdate
signal occurs (which requires OTG to be enabled), this never happens and
the wait times out. This can add hundreds of milliseconds to the boot
time.

[How]
Do not wait for mpc idle if tg is disabled

Reviewed-by: Jun Lei &lt;Jun.Lei@amd.com&gt;
Acked-by: Pavle Kotarac &lt;Pavle.Kotarac@amd.com&gt;
Signed-off-by: Josip Pavic &lt;Josip.Pavic@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Stable-dep-of: 5a25cefc0920 ("drm/amd/display: check TG is non-null before checking if enabled")
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drm/amd/display: Use DC_LOG_DC in the trasform pixel function</title>
<updated>2023-05-30T11:44:02+00:00</updated>
<author>
<name>Rodrigo Siqueira</name>
<email>Rodrigo.Siqueira@amd.com</email>
</author>
<published>2022-11-01T14:20:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=9b72cb394f962aeb22f0453523c67ac17100cd73'/>
<id>urn:sha1:9b72cb394f962aeb22f0453523c67ac17100cd73</id>
<content type='text'>
[ Upstream commit 7222f5841ff49709ca666b05ff336776e0664a20 ]

[Why &amp; How]
DC now uses a new commit sequence which is more robust since it
addresses cases where we need to reorganize pipes based on planes and
other parameters. As a result, this new commit sequence reset the DC
state by cleaning plane states and re-creating them accordingly with the
need. For this reason, the dce_transform_set_pixel_storage_depth can be
invoked after a plane state is destroyed and before its re-creation. In
this situation and on DCE devices, DC will hit a condition that will
trigger a dmesg log that looks like this:

Console: switching to colour frame buffer device 240x67
------------[ cut here ]------------
[..]
Hardware name: System manufacturer System Product Name/PRIME X370-PRO, BIOS 5603 07/28/2020
RIP: 0010:dce_transform_set_pixel_storage_depth+0x3f8/0x480 [amdgpu]
[..]
RSP: 0018:ffffc9000202b850 EFLAGS: 00010293
RAX: ffffffffa081d100 RBX: ffff888110790000 RCX: 000000000000000c
RDX: ffff888100bedbf8 RSI: 0000000000001a50 RDI: ffff88810463c900
RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000007
R10: 0000000000000001 R11: 0000000000000f00 R12: ffff88810f500010
R13: ffff888100bedbf8 R14: ffff88810f515688 R15: 0000000000000000
FS:  00007ff0159249c0(0000) GS:ffff88840e940000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007ff01528e550 CR3: 0000000002a10000 CR4: 00000000003506e0
Call Trace:
 &lt;TASK&gt;
 ? dm_write_reg_func+0x21/0x80 [amdgpu 340dadd3f7c8cf4be11cf0bdc850245e99abe0e8]
 dc_stream_set_dither_option+0xfb/0x130 [amdgpu 340dadd3f7c8cf4be11cf0bdc850245e99abe0e8]
 amdgpu_dm_crtc_configure_crc_source+0x10b/0x190 [amdgpu 340dadd3f7c8cf4be11cf0bdc850245e99abe0e8]
 amdgpu_dm_atomic_commit_tail+0x20a8/0x2a90 [amdgpu 340dadd3f7c8cf4be11cf0bdc850245e99abe0e8]
 ? free_unref_page_commit+0x98/0x170
 ? free_unref_page+0xcc/0x150
 commit_tail+0x94/0x120
 drm_atomic_helper_commit+0x10f/0x140
 drm_atomic_commit+0x94/0xc0
 ? drm_plane_get_damage_clips.cold+0x1c/0x1c
 drm_client_modeset_commit_atomic+0x203/0x250
 drm_client_modeset_commit_locked+0x56/0x150
 drm_client_modeset_commit+0x21/0x40
 drm_fb_helper_lastclose+0x42/0x70
 amdgpu_driver_lastclose_kms+0xa/0x10 [amdgpu 340dadd3f7c8cf4be11cf0bdc850245e99abe0e8]
 drm_release+0xda/0x110
 __fput+0x89/0x240
 task_work_run+0x5c/0x90
 do_exit+0x333/0xae0
 do_group_exit+0x2d/0x90
 __x64_sys_exit_group+0x14/0x20
 do_syscall_64+0x5b/0x80
 ? exit_to_user_mode_prepare+0x1e/0x140
 entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x7ff016ceaca1
Code: Unable to access opcode bytes at RIP 0x7ff016ceac77.
RSP: 002b:00007ffe7a2357e8 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7
RAX: ffffffffffffffda RBX: 00007ff016e15a00 RCX: 00007ff016ceaca1
RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000000
RBP: 0000000000000000 R08: ffffffffffffff78 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00007ff016e15a00
R13: 0000000000000000 R14: 00007ff016e1aee8 R15: 00007ff016e1af00
 &lt;/TASK&gt;

Since this issue only happens in a transition state on DC, this commit
replace BREAK_TO_DEBUGGER with DC_LOG_DC.

Reviewed-by: Harry Wentland &lt;Harry.Wentland@amd.com&gt;
Acked-by: Qingqing Zhuo &lt;qingqing.zhuo@amd.com&gt;
Signed-off-by: Rodrigo Siqueira &lt;Rodrigo.Siqueira@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/amd/display: Fix hang when skipping modeset</title>
<updated>2023-05-17T09:36:05+00:00</updated>
<author>
<name>Aurabindo Pillai</name>
<email>aurabindo.pillai@amd.com</email>
</author>
<published>2023-03-24T14:42:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=d60f15682a5ce51e8119c1b9ff522494554e33b5'/>
<id>urn:sha1:d60f15682a5ce51e8119c1b9ff522494554e33b5</id>
<content type='text'>
commit da5e14909776edea4462672fb4a3007802d262e7 upstream.

[Why&amp;How]

When skipping full modeset since the only state change was a front porch
change, the DC commit sequence requires extra checks to handle non
existant plane states being asked to be removed from context.

Reviewed-by: Alvin Lee &lt;Alvin.Lee2@amd.com&gt;
Acked-by: Qingqing Zhuo &lt;qingqing.zhuo@amd.com&gt;
Signed-off-by: Aurabindo Pillai &lt;aurabindo.pillai@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: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>drm/amd/display: Fix COLOR_SPACE_YCBCR2020_TYPE matrix</title>
<updated>2023-01-24T06:18:01+00:00</updated>
<author>
<name>Joshua Ashton</name>
<email>joshua@froggi.es</email>
</author>
<published>2023-01-10T22:50:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=2b1375fac0de483dc2f2423279731ea8cfb4111a'/>
<id>urn:sha1:2b1375fac0de483dc2f2423279731ea8cfb4111a</id>
<content type='text'>
commit 973a9c810c785ac270a6d50d8cf862b0c1643a10 upstream.

The YCC conversion matrix for RGB -&gt; COLOR_SPACE_YCBCR2020_TYPE is
missing the values for the fourth column of the matrix.

The fourth column of the matrix is essentially just a value that is
added given that the color is 3 components in size.
These values are needed to bias the chroma from the [-1, 1] -&gt; [0, 1]
range.

This fixes color being very green when using Gamescope HDR on HDMI
output which prefers YCC 4:4:4.

Fixes: 40df2f809e8f ("drm/amd/display: color space ycbcr709 support")
Reviewed-by: Melissa Wen &lt;mwen@igalia.com&gt;
Signed-off-by: Joshua Ashton &lt;joshua@froggi.es&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/amd/dc/dce120: Fix audio register mapping, stop triggering KASAN</title>
<updated>2022-12-08T10:23:01+00:00</updated>
<author>
<name>Lyude Paul</name>
<email>lyude@redhat.com</email>
</author>
<published>2022-11-14T22:20:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=d4e9bab771aa4e64474de2bf67401755862cc53a'/>
<id>urn:sha1:d4e9bab771aa4e64474de2bf67401755862cc53a</id>
<content type='text'>
commit 44035ec2fde1114254ee465f9ba3bb246b0b6283 upstream.

There's been a very long running bug that seems to have been neglected for
a while, where amdgpu consistently triggers a KASAN error at start:

  BUG: KASAN: global-out-of-bounds in read_indirect_azalia_reg+0x1d4/0x2a0 [amdgpu]
  Read of size 4 at addr ffffffffc2274b28 by task modprobe/1889

After digging through amd's rather creative method for accessing registers,
I eventually discovered the problem likely has to do with the fact that on
my dce120 GPU there are supposedly 7 sets of audio registers. But we only
define a register mapping for 6 sets.

So, fix this and fix the KASAN warning finally.

Signed-off-by: Lyude Paul &lt;lyude@redhat.com&gt;
Cc: stable@vger.kernel.org
Reviewed-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>drm/amd/display: fix overflow on MIN_I64 definition</title>
<updated>2022-10-26T11:22:52+00:00</updated>
<author>
<name>David Gow</name>
<email>davidgow@google.com</email>
</author>
<published>2022-08-11T20:43:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=8f6cad7c4b682e36afd7ff777be6d1558adcc116'/>
<id>urn:sha1:8f6cad7c4b682e36afd7ff777be6d1558adcc116</id>
<content type='text'>
[ Upstream commit 6ae0632d17759852c07e2d1e0a31c728eb6ba246 ]

The definition of MIN_I64 in bw_fixed.c can cause gcc to whinge about
integer overflow, because it is treated as a positive value, which is
then negated. The temporary positive value is not necessarily
representable.

This causes the following warning:
../drivers/gpu/drm/amd/amdgpu/../display/dc/dml/calcs/bw_fixed.c:30:19:
warning: integer overflow in expression ‘-9223372036854775808’ of type
‘long long int’ results in ‘-9223372036854775808’ [-Woverflow]
  30 |         (int64_t)(-(1LL &lt;&lt; 63))
     |                   ^

Writing out (-MAX_I64 - 1) works instead.

Signed-off-by: David Gow &lt;davidgow@google.com&gt;
Signed-off-by: Tales Aparecida &lt;tales.aparecida@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>
</entry>
<entry>
<title>drm/amd/display: Fix pixel clock programming</title>
<updated>2022-09-05T08:27:47+00:00</updated>
<author>
<name>Ilya Bakoulin</name>
<email>Ilya.Bakoulin@amd.com</email>
</author>
<published>2022-07-26T20:19:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=5c5cd52ab09d408839f55ccf6fae4a3a58fd0bb7'/>
<id>urn:sha1:5c5cd52ab09d408839f55ccf6fae4a3a58fd0bb7</id>
<content type='text'>
[ Upstream commit 04fb918bf421b299feaee1006e82921d7d381f18 ]

[Why]
Some pixel clock values could cause HDMI TMDS SSCPs to be misaligned
between different HDMI lanes when using YCbCr420 10-bit pixel format.

BIOS functions for transmitter/encoder control take pixel clock in kHz
increments, whereas the function for setting the pixel clock is in 100Hz
increments. Setting pixel clock to a value that is not on a kHz boundary
will cause the issue.

[How]
Round pixel clock down to nearest kHz in 10/12-bpc cases.

Reviewed-by: Aric Cyr &lt;Aric.Cyr@amd.com&gt;
Acked-by: Brian Chang &lt;Brian.Chang@amd.com&gt;
Signed-off-by: Ilya Bakoulin &lt;Ilya.Bakoulin@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>
</feed>
