<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/gpu/drm/amd/display, branch v5.4.222</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v5.4.222</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v5.4.222'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2022-10-26T11:22:52+00:00</updated>
<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: Limit user regamma to a valid value</title>
<updated>2022-09-28T09:04:09+00:00</updated>
<author>
<name>Yao Wang1</name>
<email>Yao.Wang1@amd.com</email>
</author>
<published>2022-08-22T10:30:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=75ed7dee26aba0ab241874569bbe7694a524d944'/>
<id>urn:sha1:75ed7dee26aba0ab241874569bbe7694a524d944</id>
<content type='text'>
[ Upstream commit 3601d620f22e37740cf73f8278eabf9f2aa19eb7 ]

[Why]
For HDR mode, we get total 512 tf_point and after switching to SDR mode
we actually get 400 tf_point and the rest of points(401~512) still use
dirty value from HDR mode. We should limit the rest of the points to max
value.

[How]
Limit the value when coordinates_x.x &gt; 1, just like what we do in
translate_from_linear_space for other re-gamma build paths.

Tested-by: Daniel Wheeler &lt;daniel.wheeler@amd.com&gt;
Reviewed-by: Krunoslav Kovac &lt;Krunoslav.Kovac@amd.com&gt;
Reviewed-by: Aric Cyr &lt;Aric.Cyr@amd.com&gt;
Acked-by: Pavle Kotarac &lt;Pavle.Kotarac@amd.com&gt;
Signed-off-by: Yao Wang1 &lt;Yao.Wang1@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 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>
<entry>
<title>drm/amd/display: clear optc underflow before turn off odm clock</title>
<updated>2022-09-05T08:27:46+00:00</updated>
<author>
<name>Fudong Wang</name>
<email>Fudong.Wang@amd.com</email>
</author>
<published>2022-07-27T04:01:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=814b756d4ec3a8728debb116cf49005feada7750'/>
<id>urn:sha1:814b756d4ec3a8728debb116cf49005feada7750</id>
<content type='text'>
[ Upstream commit b2a93490201300a749ad261b5c5d05cb50179c44 ]

[Why]
After ODM clock off, optc underflow bit will be kept there always and clear not work.
We need to clear that before clock off.

[How]
Clear that if have when clock off.

Reviewed-by: Alvin Lee &lt;alvin.lee2@amd.com&gt;
Acked-by: Tom Chung &lt;chiahsuan.chung@amd.com&gt;
Signed-off-by: Fudong Wang &lt;Fudong.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;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drm/amd/display: Avoid MPC infinite loop</title>
<updated>2022-09-05T08:27:46+00:00</updated>
<author>
<name>Josip Pavic</name>
<email>Josip.Pavic@amd.com</email>
</author>
<published>2022-07-21T19:33:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=a06e4eb6516969fd55cb63c232b508eab82be45e'/>
<id>urn:sha1:a06e4eb6516969fd55cb63c232b508eab82be45e</id>
<content type='text'>
[ Upstream commit 8de297dc046c180651c0500f8611663ae1c3828a ]

[why]
In some cases MPC tree bottom pipe ends up point to itself.  This causes
iterating from top to bottom to hang the system in an infinite loop.

[how]
When looping to next MPC bottom pipe, check that the pointer is not same
as current to avoid infinite loop.

Reviewed-by: Josip Pavic &lt;Josip.Pavic@amd.com&gt;
Reviewed-by: Jun Lei &lt;Jun.Lei@amd.com&gt;
Acked-by: Alex Hung &lt;alex.hung@amd.com&gt;
Signed-off-by: Aric Cyr &lt;aric.cyr@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/dc/gpio/gpio_service: Pass around correct dce_{version, environment} types</title>
<updated>2022-05-15T17:54:46+00:00</updated>
<author>
<name>Lee Jones</name>
<email>lee.jones@linaro.org</email>
</author>
<published>2021-05-26T08:47:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=de542bd765411d410b633d1a716cc751d814701c'/>
<id>urn:sha1:de542bd765411d410b633d1a716cc751d814701c</id>
<content type='text'>
commit 353f7f3a9dd5fd2833b6462bac89ec1654c9c3aa upstream.

Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/amd/amdgpu/../display/dc/gpio/gpio_service.c: In function ‘dal_gpio_service_create’:
 drivers/gpu/drm/amd/amdgpu/../display/dc/gpio/gpio_service.c:71:4: warning: implicit conversion from ‘enum dce_version’ to ‘enum dce_environment’ [-Wenum-conversion]
 drivers/gpu/drm/amd/amdgpu/../display/dc/gpio/gpio_service.c:77:4: warning: implicit conversion from ‘enum dce_version’ to ‘enum dce_environment’ [-Wenum-conversion]

Cc: Harry Wentland &lt;harry.wentland@amd.com&gt;
Cc: Leo Li &lt;sunpeng.li@amd.com&gt;
Cc: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Cc: "Christian König" &lt;christian.koenig@amd.com&gt;
Cc: David Airlie &lt;airlied@linux.ie&gt;
Cc: Daniel Vetter &lt;daniel@ffwll.ch&gt;
Cc: amd-gfx@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones &lt;lee.jones@linaro.org&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Cc: Nathan Chancellor &lt;nathan@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>drm/amd/display: Fix memory leak in dcn21_clock_source_create</title>
<updated>2022-05-09T07:03:26+00:00</updated>
<author>
<name>Miaoqian Lin</name>
<email>linmq006@gmail.com</email>
</author>
<published>2022-04-21T09:03:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=cd5cec3a0c8fc1c03f676f6be41b176bd9d43f46'/>
<id>urn:sha1:cd5cec3a0c8fc1c03f676f6be41b176bd9d43f46</id>
<content type='text'>
[ Upstream commit 65e54987508b6f0771f56bdfa3ee1926d52785ae ]

When dcn20_clk_src_construct() fails, we need to release clk_src.

Fixes: 6f4e6361c3ff ("drm/amd/display: Add Renoir resource (v2)")
Signed-off-by: Miaoqian Lin &lt;linmq006@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: don't ignore alpha property on pre-multiplied mode</title>
<updated>2022-04-20T07:19:39+00:00</updated>
<author>
<name>Melissa Wen</name>
<email>mwen@igalia.com</email>
</author>
<published>2022-03-29T20:18:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=f616ecec0faef8f5df75fe9917c84a68156603fe'/>
<id>urn:sha1:f616ecec0faef8f5df75fe9917c84a68156603fe</id>
<content type='text'>
commit e4f1541caf60fcbe5a59e9d25805c0b5865e546a upstream.

"Pre-multiplied" is the default pixel blend mode for KMS/DRM, as
documented in supported_modes of drm_plane_create_blend_mode_property():
https://cgit.freedesktop.org/drm/drm-misc/tree/drivers/gpu/drm/drm_blend.c

In this mode, both 'pixel alpha' and 'plane alpha' participate in the
calculation, as described by the pixel blend mode formula in KMS/DRM
documentation:

out.rgb = plane_alpha * fg.rgb +
          (1 - (plane_alpha * fg.alpha)) * bg.rgb

Considering the blend config mechanisms we have in the driver so far,
the alpha mode that better fits this blend mode is the
_PER_PIXEL_ALPHA_COMBINED_GLOBAL_GAIN, where the value for global_gain
is the plane alpha (global_alpha).

With this change, alpha property stops to be ignored. It also addresses
Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1734

v2:
 * keep the 8-bit value for global_alpha_value (Nicholas)
 * correct the logical ordering for combined global gain (Nicholas)
 * apply to dcn10 too (Nicholas)

Signed-off-by: Melissa Wen &lt;mwen@igalia.com&gt;
Tested-by: Rodrigo Siqueira &lt;Rodrigo.Siqueira@amd.com&gt;
Reviewed-by: Harry Wentland &lt;harry.wentland@amd.com&gt;
Tested-by: Simon Ser &lt;contact@emersion.fr&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/display: Fix allocate_mst_payload assert on resume</title>
<updated>2022-04-20T07:19:37+00:00</updated>
<author>
<name>Roman Li</name>
<email>Roman.Li@amd.com</email>
</author>
<published>2022-03-17T23:55:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=dd9b4b435a56a7a29c7d1ccc6479847354842255'/>
<id>urn:sha1:dd9b4b435a56a7a29c7d1ccc6479847354842255</id>
<content type='text'>
[ Upstream commit f4346fb3edf7720db3f7f5e1cab1f667cd024280 ]

[Why]
On resume we do link detection for all non-MST connectors.
MST is handled separately. However the condition for telling
if connector is on mst branch is not enough for mst hub case.
Link detection for mst branch link leads to mst topology reset.
That causes assert in dc_link_allocate_mst_payload()

[How]
Use link type as indicator for mst link.

Reviewed-by: Wayne Lin &lt;Wayne.Lin@amd.com&gt;
Acked-by: Alex Hung &lt;alex.hung@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;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drm/amd/display: Update VTEM Infopacket definition</title>
<updated>2022-04-20T07:19:36+00:00</updated>
<author>
<name>Leo (Hanghong) Ma</name>
<email>hanghong.ma@amd.com</email>
</author>
<published>2022-03-11T16:35:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=46ca8233f12d3d2081b3ff83d59b5ebd0d43879f'/>
<id>urn:sha1:46ca8233f12d3d2081b3ff83d59b5ebd0d43879f</id>
<content type='text'>
[ Upstream commit c9fbf6435162ed5fb7201d1d4adf6585c6a8c327 ]

[Why &amp; How]
The latest HDMI SPEC has updated the VTEM packet structure,
so change the VTEM Infopacket defined in the driver side to align
with the SPEC.

Reviewed-by: Chris Park &lt;Chris.Park@amd.com&gt;
Acked-by: Alex Hung &lt;alex.hung@amd.com&gt;
Signed-off-by: Leo (Hanghong) Ma &lt;hanghong.ma@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>
