<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/gpu/drm/amd/display/dc/optc/dcn35, branch master</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=master</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=master'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2026-03-30T19:12:15+00:00</updated>
<entry>
<title>drm/amd/display: Fixed Silence complier warnings in dc</title>
<updated>2026-03-30T19:12:15+00:00</updated>
<author>
<name>Gaghik Khachatrian</name>
<email>gaghik.khachatrian@amd.com</email>
</author>
<published>2026-03-09T21:18:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=f82480fafedf622541276d48a3b4fed20ce5d866'/>
<id>urn:sha1:f82480fafedf622541276d48a3b4fed20ce5d866</id>
<content type='text'>
[Why]
Resolve compiler warnings by marking unused parameters explicitly.

[How]
In .c and .h function definitions, keep parameter names
in signatures and add a line with `(void)param;` in function body

Preserved function signatures and avoids breaking code paths that
may reference the parameter under conditional compilation.

Reviewed-by: Dillon Varone &lt;dillon.varone@amd.com&gt;
Reviewed-by: Austin Zheng &lt;austin.zheng@amd.com&gt;
Signed-off-by: Gaghik Khachatrian &lt;gaghik.khachatrian@amd.com&gt;
Signed-off-by: Chuanyu Tseng &lt;chuanyu.tseng@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
</content>
</entry>
<entry>
<title>drm/amd/display: Expose functions of other dcn use</title>
<updated>2026-02-19T17:16:10+00:00</updated>
<author>
<name>Dmytro Laktyushkin</name>
<email>dmytro.laktyushkin@amd.com</email>
</author>
<published>2026-01-28T16:09:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=8175ea4159e9c4275503cb287802fae6d6a8a055'/>
<id>urn:sha1:8175ea4159e9c4275503cb287802fae6d6a8a055</id>
<content type='text'>
[Why &amp; HOw]
Expose some functions for later dcns to reuse

Reviewed-by: Charlene Liu &lt;charlene.liu@amd.com&gt;
Reviewed-by: Nicholas Kazlauskas &lt;nicholas.kazlauskas@amd.com&gt;
Signed-off-by: Dmytro Laktyushkin &lt;dmytro.laktyushkin@amd.com&gt;
Signed-off-by: Ray Wu &lt;ray.wu@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: Add CRC 32-bit mode support for DCN3.6+</title>
<updated>2026-02-03T21:43:12+00:00</updated>
<author>
<name>Chenyu Chen</name>
<email>chen-yu.chen@amd.com</email>
</author>
<published>2026-01-22T09:19:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=1a77ecec8b35258c45b6963698e5dc378c67ef32'/>
<id>urn:sha1:1a77ecec8b35258c45b6963698e5dc378c67ef32</id>
<content type='text'>
[Why]
DCN 3.6+ hardware supports CRC-32 polynomial in addition to the
legacy CRC-16. Enable 32-bit CRC values per color component for
improvement of precision in display validation.

[How]
When userspace sets crc_poly_mode (0=CRC-16, 1=CRC-32) via the debugfs
interface, the value is stored in dm_irq_params.crc_poly_mode. When CRC
source configuration triggers amdgpu_dm_crtc_configure_crc_source(),
crc_poly_mode is retrieved from dm_irq_params and passed to
dc_stream_configure_crc().

In the DC layer, dc_stream_configure_crc() sets crc_poly_mode into the
crc_params structure and passes it to optc35_configure_crc(). If the
hardware supports the OTG_CRC_POLY_SEL register, the register is
programmed to select CRC-16 or CRC-32 polynomial.

When reading CRC values, optc35_get_crc() checks whether CRC32 register
masks are available. If present, it reads 32-bit CRC values from
OTG_CRC0/1_DATA_R32/G32/B32 registers; otherwise, it falls back
to reading 16-bit CRC values from legacy OTG_CRC0/1_DATA_RG/B
registers.

Reviewed-by: ChiaHsuan Chung &lt;chiahsuan.chung@amd.com&gt;
Signed-off-by: Chenyu Chen &lt;chen-yu.chen@amd.com&gt;
Signed-off-by: Wayne Lin &lt;wayne.lin@amd.com&gt;
Tested-by: Dan 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: Add more DC HW state info to underflow logging</title>
<updated>2025-10-28T13:57:44+00:00</updated>
<author>
<name>Karen Chen</name>
<email>Karen.Chen@amd.com</email>
</author>
<published>2025-10-15T15:13:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=dbf58a9dad4d80286c5c17e199f595eb0dd3be5a'/>
<id>urn:sha1:dbf58a9dad4d80286c5c17e199f595eb0dd3be5a</id>
<content type='text'>
[Why]
Debugging underflow issues frequently requires knowing the
HW state at the time of underflow. To enable capturing this
HW state information, interface functions are needed for the
various DC HW blocks.

[How]
This change adds the interface functions to read HW state for
the following DC HW blocks:
- HUBBUB
- HUBP
- DPP
- MPC
- OPP
- DSC
- OPTC
- DCCG

Reviewed-by: George Shen &lt;george.shen@amd.com&gt;
Signed-off-by: Karen Chen &lt;Karen.Chen@amd.com&gt;
Signed-off-by: Wayne Lin &lt;wayne.lin@amd.com&gt;
Tested-by: Dan 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: wait for otg update pending latch before clock optimization</title>
<updated>2025-08-27T17:57:50+00:00</updated>
<author>
<name>Yihan Zhu</name>
<email>Yihan.Zhu@amd.com</email>
</author>
<published>2025-08-13T20:05:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=f382e2d0faad0e0d73f626dbd71f2a4fce03975b'/>
<id>urn:sha1:f382e2d0faad0e0d73f626dbd71f2a4fce03975b</id>
<content type='text'>
[WHY &amp; HOW]
OTG pending update unlatched will cause system fail, wait OTG fully disabled to
avoid this error.

Reviewed-by: Nicholas Kazlauskas &lt;nicholas.kazlauskas@amd.com&gt;
Signed-off-by: Yihan Zhu &lt;Yihan.Zhu@amd.com&gt;
Signed-off-by: Aurabindo Pillai &lt;aurabindo.pillai@amd.com&gt;
Tested-by: Dan 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: Constify struct timing_generator_funcs</title>
<updated>2025-05-29T14:57:31+00:00</updated>
<author>
<name>Christophe JAILLET</name>
<email>christophe.jaillet@wanadoo.fr</email>
</author>
<published>2025-05-24T16:51:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=347efe5b396c61bc129832910665d899ee86448e'/>
<id>urn:sha1:347efe5b396c61bc129832910665d899ee86448e</id>
<content type='text'>
'struct timing_generator_funcs' are not modified in these drivers.

Constifying these structures moves some data to a read-only section, so
increases overall security, especially when the structure holds some
function pointers.

Signed-off-by: Christophe JAILLET &lt;christophe.jaillet@wanadoo.fr&gt;
Reviewed-by: Alex Hung &lt;alex.hung@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
</content>
</entry>
<entry>
<title>drm/amd/display: wait for updates to latch before locking</title>
<updated>2025-04-07T22:01:08+00:00</updated>
<author>
<name>Ausef Yousof</name>
<email>Ausef.Yousof@amd.com</email>
</author>
<published>2025-03-28T15:06:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=556db637c27a463cd6bafa40714ea1245414456a'/>
<id>urn:sha1:556db637c27a463cd6bafa40714ea1245414456a</id>
<content type='text'>
[why&amp;how]
It is possible for an update to acquire otg lock and begin programming
while the previous update has not completed and its values have not
latched. The correct way to go about this is to wait until the vupdate
pulses so we can be sure that previous updates have latched and we can
continue with the current update pipe programming, otherwise during
consecutive full updates we will have corruption flash on the screen.

The corruption flash occurs specifically on configs that require odm
combine, and its local to a specific pipe (will not flash across whole
screen). This ticket is across the otg slave, but it may also appear
across master.

Reviewed-by: Leo Chen &lt;leo.chen@amd.com&gt;
Signed-off-by: Ausef Yousof &lt;Ausef.Yousof@amd.com&gt;
Signed-off-by: Roman Li &lt;roman.li@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: log destination of vertical interrupt</title>
<updated>2025-02-13T02:02:57+00:00</updated>
<author>
<name>Josip Pavic</name>
<email>Josip.Pavic@amd.com</email>
</author>
<published>2025-01-07T16:00:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=06b0a4ad7162b9dd7e52dbec320ea9d080d9e551'/>
<id>urn:sha1:06b0a4ad7162b9dd7e52dbec320ea9d080d9e551</id>
<content type='text'>
[Why]
Knowing the destination of OTG's vertical interrupt 2 is useful for
debugging, but it is not currently included in the OTG state readback
logic

[How]
Read the OTG interrupt destination register to get the vertical interrupt
2 destination on ASICs that have this register when reading back the OTG
state from hardware

Reviewed-by: Sung Lee &lt;sung.lee@amd.com&gt;
Reviewed-by: Aric Cyr &lt;aric.cyr@amd.com&gt;
Signed-off-by: Josip Pavic &lt;Josip.Pavic@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;
</content>
</entry>
<entry>
<title>drm/amd/display: Add support to configure CRC window on specific CRC instance</title>
<updated>2025-01-10T17:03:45+00:00</updated>
<author>
<name>Wayne Lin</name>
<email>Wayne.Lin@amd.com</email>
</author>
<published>2024-12-06T05:51:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=b6fcc3867d746c181d253b110236985b9b2ee2aa'/>
<id>urn:sha1:b6fcc3867d746c181d253b110236985b9b2ee2aa</id>
<content type='text'>
[Why]
Have the need to specify the CRC window on specific CRC engine.
dc_stream_configure_crc() today calculates CRC on crc engine 0 only and always
resets CRC engine at first.

[How]
Add index parameter to dc_stream_configure_crc() for selecting the desired crc
engine. Additionally, add another parameter to specify whether to skip the
default reset of crc engine.

Reviewed-by: HaoPing Liu &lt;haoping.liu@amd.com&gt;
Signed-off-by: Wayne Lin &lt;Wayne.Lin@amd.com&gt;
Signed-off-by: Tom Chung &lt;chiahsuan.chung@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: Wait for all pending cleared before full update</title>
<updated>2024-10-01T21:30:47+00:00</updated>
<author>
<name>Alvin Lee</name>
<email>Alvin.Lee2@amd.com</email>
</author>
<published>2024-09-09T20:24:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=faee3edfcff750fe5dd760177f52978aefefeb70'/>
<id>urn:sha1:faee3edfcff750fe5dd760177f52978aefefeb70</id>
<content type='text'>
[Description]
Before every full update we must wait for all pending updates to be
cleared - this is particularly important for minimal transitions
because if we don't wait for pending cleared, it will be as if
there was no minimal transition at all. In OTG we must read 3 different
status registers for pending cleared, one specifically for OTG updates,
one specifically for OPTC updates, and the last for surface related
updates.

Reviewed-by: Dillon Varone &lt;dillon.varone@amd.com&gt;
Signed-off-by: Alvin Lee &lt;Alvin.Lee2@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;
</content>
</entry>
</feed>
