<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/gpu/drm/amd/display, branch v4.19.77</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v4.19.77</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v4.19.77'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2019-10-05T11:10:13+00:00</updated>
<entry>
<title>drm/amd/display: Restore backlight brightness after system resume</title>
<updated>2019-10-05T11:10:13+00:00</updated>
<author>
<name>Kai-Heng Feng</name>
<email>kai.heng.feng@canonical.com</email>
</author>
<published>2019-09-02T08:33:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=2c60da90ec4467adec602e1b81b3ca256f581031'/>
<id>urn:sha1:2c60da90ec4467adec602e1b81b3ca256f581031</id>
<content type='text'>
commit bb264220d9316f6bd7c1fd84b8da398c93912931 upstream.

Laptops with AMD APU doesn't restore display backlight brightness after
system resume.

This issue started when DC was introduced.

Let's use BL_CORE_SUSPENDRESUME so the backlight core calls
update_status callback after system resume to restore the backlight
level.

Tested on Dell Inspiron 3180 (Stoney Ridge) and Dell Latitude 5495
(Raven Ridge).

Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Kai-Heng Feng &lt;kai.heng.feng@canonical.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: readd -msse2 to prevent Clang from emitting libcalls to undefined SW FP routines</title>
<updated>2019-10-01T06:26:00+00:00</updated>
<author>
<name>Nick Desaulniers</name>
<email>ndesaulniers@google.com</email>
</author>
<published>2019-07-22T22:31:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=70ec2eecc550e4ca189cd0ab6bdd6a65bb343988'/>
<id>urn:sha1:70ec2eecc550e4ca189cd0ab6bdd6a65bb343988</id>
<content type='text'>
[ Upstream commit 0f0727d971f6fdf8f1077180d495ddb9928f0c8b ]

arch/x86/Makefile disables SSE and SSE2 for the whole kernel.  The
AMDGPU drivers modified in this patch re-enable SSE but not SSE2.  Turn
on SSE2 to support emitting double precision floating point instructions
rather than calls to non-existent (usually available from gcc_s or
compiler_rt) floating point helper routines for Clang.

This was originally landed in:
commit 10117450735c ("drm/amd/display: add -msse2 to prevent Clang from emitting libcalls to undefined SW FP routines")
but reverted in:
commit 193392ed9f69 ("Revert "drm/amd/display: add -msse2 to prevent Clang from emitting libcalls to undefined SW FP routines"")
due to bugreports from GCC builds. Add guards to only do so for Clang.

Link: https://bugs.freedesktop.org/show_bug.cgi?id=109487
Link: https://github.com/ClangBuiltLinux/linux/issues/327

Suggested-by: Sedat Dilek &lt;sedat.dilek@gmail.com&gt;
Suggested-by: Sami Tolvanen &lt;samitolvanen@google.com&gt;
Signed-off-by: Nick Desaulniers &lt;ndesaulniers@google.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/dm: Understand why attaching path/tile properties are needed</title>
<updated>2019-09-16T06:21:55+00:00</updated>
<author>
<name>Lyude Paul</name>
<email>lyude@redhat.com</email>
</author>
<published>2018-11-19T19:44:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=016218ef6bb057ac494ea59caeb928492c2fcb6e'/>
<id>urn:sha1:016218ef6bb057ac494ea59caeb928492c2fcb6e</id>
<content type='text'>
[ Upstream commit 04ac4b0ed412f65230b456fcd9aa07e13befff89 ]

Path property is used for userspace to know what MST connector goes to what actual DRM DisplayPort connector, the tiling property is for tiling configurations. Not sure what else there is to figure out.

Signed-off-by: Lyude Paul &lt;lyude@redhat.com&gt;
Reviewed-by: Jerry (Fangzhi) Zuo &lt;Jerry.Zuo@amd.com&gt;
Cc: Stable &lt;stable@vger.kernel.org&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: Increase size of audios array</title>
<updated>2019-08-16T08:12:45+00:00</updated>
<author>
<name>Tai Man</name>
<email>taiman.wong@amd.com</email>
</author>
<published>2019-06-28T15:40:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=8d641499bf969a284161d2682b71669c96389773'/>
<id>urn:sha1:8d641499bf969a284161d2682b71669c96389773</id>
<content type='text'>
[ Upstream commit 7352193a33dfc9b69ba3bf6a8caea925b96243b1 ]

[Why]
The audios array defined in "struct resource_pool" is only 6 (MAX_PIPES)
but the max number of audio devices (num_audio) is 7. In some projects,
it will run out of audios array.

[How]
Incraese the audios array size to 7.

Signed-off-by: Tai Man &lt;taiman.wong@amd.com&gt;
Reviewed-by: Joshua Aberback &lt;Joshua.Aberback@amd.com&gt;
Acked-by: Leo Li &lt;sunpeng.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/amd/display: Only enable audio if speaker allocation exists</title>
<updated>2019-08-16T08:12:45+00:00</updated>
<author>
<name>Alvin Lee</name>
<email>alvin.lee2@amd.com</email>
</author>
<published>2019-07-04T19:17:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=f9420bfa29f9ece0b02a5435ae95f1a48bc97723'/>
<id>urn:sha1:f9420bfa29f9ece0b02a5435ae95f1a48bc97723</id>
<content type='text'>
[ Upstream commit 6ac25e6d5b2fbf251e9fa2f4131d42c815b43867 ]

[Why]

In dm_helpers_parse_edid_caps, there is a corner case where no speakers
can be allocated even though the audio mode count is greater than 0.
Enabling audio when no speaker allocations exists can cause issues in
the video stream.

[How]

Add a check to not enable audio unless one or more speaker allocations
exist (since doing this can cause issues in the video stream).

Signed-off-by: Alvin Lee &lt;alvin.lee2@amd.com&gt;
Reviewed-by: Jun Lei &lt;Jun.Lei@amd.com&gt;
Acked-by: Leo Li &lt;sunpeng.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/amd/display: Fix dc_create failure handling and 666 color depths</title>
<updated>2019-08-16T08:12:45+00:00</updated>
<author>
<name>Julian Parkin</name>
<email>julian.parkin@amd.com</email>
</author>
<published>2019-06-25T18:55:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=3998e684463a7fa1721c171172ca085978d03a00'/>
<id>urn:sha1:3998e684463a7fa1721c171172ca085978d03a00</id>
<content type='text'>
[ Upstream commit 0905f32977268149f06e3ce6ea4bd6d374dd891f ]

[Why]
It is possible (but very unlikely) that constructing dc fails
before current_state is created.

We support 666 color depth in some scenarios, but this
isn't handled in get_norm_pix_clk. It uses exactly the
same pixel clock as the 888 case.

[How]
Check for non null current_state before destructing.

Add case for 666 color depth to get_norm_pix_clk to
avoid assertion.

Signed-off-by: Julian Parkin &lt;julian.parkin@amd.com&gt;
Reviewed-by: Charlene Liu &lt;Charlene.Liu@amd.com&gt;
Acked-by: Leo Li &lt;sunpeng.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/amd/display: use encoder's engine id to find matched free audio device</title>
<updated>2019-08-16T08:12:44+00:00</updated>
<author>
<name>Tai Man</name>
<email>taiman.wong@amd.com</email>
</author>
<published>2019-06-07T21:32:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e7a8a794109c07e0b8d7bd55fbfcb3082991626a'/>
<id>urn:sha1:e7a8a794109c07e0b8d7bd55fbfcb3082991626a</id>
<content type='text'>
[ Upstream commit 74eda776d7a4e69ec7aa1ce30a87636f14220fbb ]

[Why]
On some platforms, the encoder id 3 is not populated. So the encoders
are not stored in right order as index (id: 0, 1, 2, 4, 5) at pool. This
would cause encoders id 4 &amp; id 5 to fail when finding corresponding
audio device, defaulting to the first available audio device. As result,
we cannot stream audio into two DP ports with encoders id 4 &amp; id 5.

[How]
It need to create enough audio device objects (0 - 5) to perform matching.
Then use encoder engine id to find matched audio device.

Signed-off-by: Tai Man &lt;taiman.wong@amd.com&gt;
Reviewed-by: Charlene Liu &lt;Charlene.Liu@amd.com&gt;
Acked-by: Leo Li &lt;sunpeng.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/amd/display: Wait for backlight programming completion in set backlight level</title>
<updated>2019-08-16T08:12:44+00:00</updated>
<author>
<name>SivapiriyanKumarasamy</name>
<email>sivapiriyan.kumarasamy@amd.com</email>
</author>
<published>2019-06-14T19:04:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=2a5e21adc71b46beec9232cc6418676fd2255bc5'/>
<id>urn:sha1:2a5e21adc71b46beec9232cc6418676fd2255bc5</id>
<content type='text'>
[ Upstream commit c7990daebe71d11a9e360b5c3b0ecd1846a3a4bb ]

[WHY]
Currently we don't wait for blacklight programming completion in DMCU
when setting backlight level. Some sequences such as PSR static screen
event trigger reprogramming requires it to be complete.

[How]
Add generic wait for dmcu command completion in set backlight level.

Signed-off-by: SivapiriyanKumarasamy &lt;sivapiriyan.kumarasamy@amd.com&gt;
Reviewed-by: Anthony Koo &lt;Anthony.Koo@amd.com&gt;
Acked-by: Leo Li &lt;sunpeng.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/amd/display: fix compilation error</title>
<updated>2019-07-31T05:27:00+00:00</updated>
<author>
<name>Hariprasad Kelam</name>
<email>hariprasad.kelam@gmail.com</email>
</author>
<published>2019-06-13T02:32:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=6a7047471073c2cf8e375b2fe5a71bacf9799973'/>
<id>urn:sha1:6a7047471073c2cf8e375b2fe5a71bacf9799973</id>
<content type='text'>
[ Upstream commit 88099f53cc3717437f5fc9cf84205c5b65118377 ]

this patch fixes below compilation error

drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_hw_sequencer.c: In
function ‘dcn10_apply_ctx_for_surface’:
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_hw_sequencer.c:2378:3:
error: implicit declaration of function ‘udelay’
[-Werror=implicit-function-declaration]
   udelay(underflow_check_delay_us);

Signed-off-by: Hariprasad Kelam &lt;hariprasad.kelam@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: Always allocate initial connector state state</title>
<updated>2019-07-31T05:27:00+00:00</updated>
<author>
<name>Nicholas Kazlauskas</name>
<email>nicholas.kazlauskas@amd.com</email>
</author>
<published>2019-06-04T19:21:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=11b4e9f3695c155f71cb2bc56d761284bf5e65b1'/>
<id>urn:sha1:11b4e9f3695c155f71cb2bc56d761284bf5e65b1</id>
<content type='text'>
[ Upstream commit f04bee34d6e35df26cbb2d65e801adfd0d8fe20d ]

[Why]
Unlike our regular connectors, MST connectors don't start off with
an initial connector state. This causes a NULL pointer dereference to
occur when attaching the bpc property since it tries to modify the
connector state.

We need an initial connector state on the connector to avoid the crash.

[How]
Use our reset helper to allocate an initial state and reset the values
to their defaults. We were already doing this before, just not for
MST connectors.

Signed-off-by: Nicholas Kazlauskas &lt;nicholas.kazlauskas@amd.com&gt;
Reviewed-by: Leo Li &lt;sunpeng.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>
</feed>
