<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/gpu/drm/amd/display, branch v5.2.16</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v5.2.16</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v5.2.16'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2019-08-16T08:11:02+00:00</updated>
<entry>
<title>drm/amd/display: Increase size of audios array</title>
<updated>2019-08-16T08:11:02+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=72d4d51a2d600a2da6ac54f59d86b798eb4cd5bb'/>
<id>urn:sha1:72d4d51a2d600a2da6ac54f59d86b798eb4cd5bb</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:11:02+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=456d33270ae03b37397baa73fc458e2b7feda1aa'/>
<id>urn:sha1:456d33270ae03b37397baa73fc458e2b7feda1aa</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:11:01+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=94e0d52ab718f7926450cbab0f50d620da31e29a'/>
<id>urn:sha1:94e0d52ab718f7926450cbab0f50d620da31e29a</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: allocate 4 ddc engines for RV2</title>
<updated>2019-08-16T08:11:01+00:00</updated>
<author>
<name>Derek Lai</name>
<email>Derek.Lai@amd.com</email>
</author>
<published>2019-07-02T09:50:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=2961a5916cb43938690aa56393ca1a6f1069b318'/>
<id>urn:sha1:2961a5916cb43938690aa56393ca1a6f1069b318</id>
<content type='text'>
[ Upstream commit 67fd6c0d2de8e51e84ff3fa6e68bbd524f823e49 ]

[Why]
Driver will create 0, 1, and 2 ddc engines for RV2,
but some platforms used 0, 1, and 3.

[How]
Still allocate 4 ddc engines for RV2.

Signed-off-by: Derek Lai &lt;Derek.Lai@amd.com&gt;
Reviewed-by: Aric Cyr &lt;Aric.Cyr@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: put back front end initialization sequence</title>
<updated>2019-08-16T08:11:01+00:00</updated>
<author>
<name>Eric Yang</name>
<email>Eric.Yang2@amd.com</email>
</author>
<published>2019-06-24T22:18:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=5b4fb99c395076fd88bc038caa2dc91718b7292c'/>
<id>urn:sha1:5b4fb99c395076fd88bc038caa2dc91718b7292c</id>
<content type='text'>
[ Upstream commit feb7eb522e0a7a22c1e60d386bd3c3bfa1d5e4f7 ]

[Why]
Seamless boot optimization removed proper front end power off sequence.
In driver disable enable case, this causes driver to power gate hubp
and dpp while there is still memory fetching going on, this can cause
invalid memory requests to be generated which will hang data fabric.

[How]
Put back proper front end power off sequence

Signed-off-by: Eric Yang &lt;Eric.Yang2@amd.com&gt;
Reviewed-by: Anthony Koo &lt;Anthony.Koo@amd.com&gt;
Acked-by: Leo Li &lt;sunpeng.li@amd.com&gt;
Acked-by: Tony Cheng &lt;Tony.Cheng@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:11:01+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=74c3128d6d99338a6a860f2372dd70bd2ec610d8'/>
<id>urn:sha1:74c3128d6d99338a6a860f2372dd70bd2ec610d8</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: fix DMCU hang when going into Modern Standby</title>
<updated>2019-08-16T08:11:01+00:00</updated>
<author>
<name>Zi Yu Liao</name>
<email>ziyu.liao@amd.com</email>
</author>
<published>2019-06-20T14:55:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=8f17b4dcd46b54c5f6f38e85d87d7527310ff075'/>
<id>urn:sha1:8f17b4dcd46b54c5f6f38e85d87d7527310ff075</id>
<content type='text'>
[ Upstream commit 1ca068ed34d6b39d336c1b0d618ed73ba8f04548 ]

[why]
When the system is going into suspend, set_backlight gets called
after the eDP got blanked. Since smooth brightness is enabled,
the driver will make a call into the DMCU to ramp the brightness.
The DMCU would try to enable ABM to do so. But since the display is
blanked, this ends up causing ABM1_ACE_DBUF_REG_UPDATE_PENDING to
get stuck at 1, which results in a dead lock in the DMCU firmware.

[how]
Disable brightness ramping when the eDP display is blanked.

Signed-off-by: Zi Yu Liao &lt;ziyu.liao@amd.com&gt;
Reviewed-by: Eric Yang &lt;eric.yang2@amd.com&gt;
Acked-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: Wait for backlight programming completion in set backlight level</title>
<updated>2019-08-16T08:11:01+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=26341f1139404362785132fe9ce7f3dc86a85992'/>
<id>urn:sha1:26341f1139404362785132fe9ce7f3dc86a85992</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: Clock does not lower in Updateplanes</title>
<updated>2019-08-16T08:11:00+00:00</updated>
<author>
<name>Murton Liu</name>
<email>murton.liu@amd.com</email>
</author>
<published>2019-06-10T21:55:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=98d0152c2da000d48d78458874abf259a80d0c4c'/>
<id>urn:sha1:98d0152c2da000d48d78458874abf259a80d0c4c</id>
<content type='text'>
[ Upstream commit 492d9ec244923420af96db6b69ad7d575859aa92 ]

[why]
We reset the optimized_required in atomic_plane_disable
flag immediately after it is set in atomic_plane_disconnect, causing us to
never have flag set during next flip in UpdatePlanes.

[how]
Optimize directly after each time plane is removed.

Signed-off-by: Murton Liu &lt;murton.liu@amd.com&gt;
Reviewed-by: Tony Cheng &lt;Tony.Cheng@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: No audio endpoint for Dell MST display</title>
<updated>2019-08-16T08:11:00+00:00</updated>
<author>
<name>Harmanprit Tatla</name>
<email>harmanprit.tatla@amd.com</email>
</author>
<published>2019-06-04T18:12:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=840e427020ace71b13ca862591a41f47fef29d68'/>
<id>urn:sha1:840e427020ace71b13ca862591a41f47fef29d68</id>
<content type='text'>
[ Upstream commit 5b25e5f1a97284020abee7348427f89abdb674e8 ]

[Why]
There are certain MST displays (i.e. Dell P2715Q)
that although have the MST feature set to off may still
report it is a branch device and a non-zero
value for downstream port present.
This can lead to us incorrectly classifying a
dp dongle connection as being active and
disabling the audio endpoint for the display.

[How]
Modified the placement and
condition used to assign
the is_branch_dev bit.

Signed-off-by: Harmanprit Tatla &lt;harmanprit.tatla@amd.com&gt;
Reviewed-by: Aric Cyr &lt;aric.cyr@amd.com&gt;
Acked-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>
</feed>
