<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/drivers/gpu/drm/amd/display, branch v5.13.2</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>drm/amd/display: take dc_lock in short pulse handler only</title>
<updated>2021-07-14T15:06:58+00:00</updated>
<author>
<name>Aurabindo Pillai</name>
<email>aurabindo.pillai@amd.com</email>
</author>
<published>2021-05-19T20:51:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=9834e82646233b3ed8ed7a69bdbe7f30a97115e8'/>
<id>9834e82646233b3ed8ed7a69bdbe7f30a97115e8</id>
<content type='text'>
[ Upstream commit d2aa1356834d845ffdac0d8c01b58aa60d1bdc65 ]

[Why]
Conditions that end up modifying the global dc state must be locked.
However, during mst allocate payload sequence, lock is already taken.
With StarTech 1.2 DP hub, we get an HPD RX interrupt for a reason other
than to indicate down reply availability right after sending payload
allocation. The handler again takes dc lock before calling the
dc's HPD RX handler. Due to this contention, the DRM thread which waits
for MST down reply never gets a chance to finish its waiting
successfully and ends up timing out. Once the lock is released, the hpd
rx handler fires and goes ahead to read from the MST HUB, but now its
too late and the HUB doesnt lightup all displays since DRM lacks error
handling when payload allocation fails.

[How]
Take lock only if there is a change in link status or if automated test
pattern bit is set. The latter fixes the null pointer dereference when
running certain DP Link Layer Compliance test.

Fixes: c8ea79a8a276 ("drm/amd/display: NULL pointer error during compliance test")

Signed-off-by: Aurabindo Pillai &lt;aurabindo.pillai@amd.com&gt;
Reviewed-by: Nicholas Kazlauskas &lt;nicholas.kazlauskas@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>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit d2aa1356834d845ffdac0d8c01b58aa60d1bdc65 ]

[Why]
Conditions that end up modifying the global dc state must be locked.
However, during mst allocate payload sequence, lock is already taken.
With StarTech 1.2 DP hub, we get an HPD RX interrupt for a reason other
than to indicate down reply availability right after sending payload
allocation. The handler again takes dc lock before calling the
dc's HPD RX handler. Due to this contention, the DRM thread which waits
for MST down reply never gets a chance to finish its waiting
successfully and ends up timing out. Once the lock is released, the hpd
rx handler fires and goes ahead to read from the MST HUB, but now its
too late and the HUB doesnt lightup all displays since DRM lacks error
handling when payload allocation fails.

[How]
Take lock only if there is a change in link status or if automated test
pattern bit is set. The latter fixes the null pointer dereference when
running certain DP Link Layer Compliance test.

Fixes: c8ea79a8a276 ("drm/amd/display: NULL pointer error during compliance test")

Signed-off-by: Aurabindo Pillai &lt;aurabindo.pillai@amd.com&gt;
Reviewed-by: Nicholas Kazlauskas &lt;nicholas.kazlauskas@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/amd/display: Avoid HPD IRQ in GPU reset state</title>
<updated>2021-07-14T15:06:58+00:00</updated>
<author>
<name>Zhan Liu</name>
<email>zhan.liu@amd.com</email>
</author>
<published>2021-05-09T23:30:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=700c74b34241c30cea0a0a77b9421294ddf10ba0'/>
<id>700c74b34241c30cea0a0a77b9421294ddf10ba0</id>
<content type='text'>
[ Upstream commit 509b9a5b4865dee723296f143695a7774fc96c4a ]

[Why]
If GPU is in reset state, force enabling link will cause
unexpected behaviour.

[How]
Avoid handling HPD IRQ when GPU is in reset state.

Signed-off-by: Zhan Liu &lt;zhan.liu@amd.com&gt;
Reviewed-by: Nikola Cornij &lt;nikola.cornij@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>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 509b9a5b4865dee723296f143695a7774fc96c4a ]

[Why]
If GPU is in reset state, force enabling link will cause
unexpected behaviour.

[How]
Avoid handling HPD IRQ when GPU is in reset state.

Signed-off-by: Zhan Liu &lt;zhan.liu@amd.com&gt;
Reviewed-by: Nikola Cornij &lt;nikola.cornij@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/amd/display: fix potential gpu reset deadlock</title>
<updated>2021-07-14T15:06:58+00:00</updated>
<author>
<name>Roman Li</name>
<email>Roman.Li@amd.com</email>
</author>
<published>2021-04-19T15:47:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=490649a08850c679d2fc7fd8c19d69a5c629f1f7'/>
<id>490649a08850c679d2fc7fd8c19d69a5c629f1f7</id>
<content type='text'>
[ Upstream commit cf8b92a75646735136053ce51107bfa8cfc23191 ]

[Why]
In gpu reset dc_lock acquired in dm_suspend().
Asynchronously handle_hpd_rx_irq can also be called
through amdgpu_dm_irq_suspend-&gt;flush_work, which also
tries to acquire dc_lock. That causes a deadlock.

[How]
Check if amdgpu executing reset before acquiring dc_lock.

Signed-off-by: Lang Yu &lt;Lang.Yu@amd.com&gt;
Signed-off-by: Roman Li &lt;Roman.Li@amd.com&gt;
Reviewed-by: Qingqing Zhuo &lt;Qingqing.Zhuo@amd.com&gt;
Acked-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>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit cf8b92a75646735136053ce51107bfa8cfc23191 ]

[Why]
In gpu reset dc_lock acquired in dm_suspend().
Asynchronously handle_hpd_rx_irq can also be called
through amdgpu_dm_irq_suspend-&gt;flush_work, which also
tries to acquire dc_lock. That causes a deadlock.

[How]
Check if amdgpu executing reset before acquiring dc_lock.

Signed-off-by: Lang Yu &lt;Lang.Yu@amd.com&gt;
Signed-off-by: Roman Li &lt;Roman.Li@amd.com&gt;
Reviewed-by: Qingqing Zhuo &lt;Qingqing.Zhuo@amd.com&gt;
Acked-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;
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/amd/dc: Fix a missing check bug in dm_dp_mst_detect()</title>
<updated>2021-07-14T15:06:55+00:00</updated>
<author>
<name>Yingjie Wang</name>
<email>wangyingjie55@126.com</email>
</author>
<published>2021-04-09T00:57:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=5164492766f4f3a3b09c8773612a0234e710fa51'/>
<id>5164492766f4f3a3b09c8773612a0234e710fa51</id>
<content type='text'>
[ Upstream commit 655c0ed19772d92c9665ed08bdc5202acc096dda ]

In dm_dp_mst_detect(), We should check whether or not @connector
has been unregistered from userspace. If the connector is unregistered,
we should return disconnected status.

Fixes: 4562236b3bc0 ("drm/amd/dc: Add dc display driver (v2)")
Signed-off-by: Yingjie Wang &lt;wangyingjie55@126.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 655c0ed19772d92c9665ed08bdc5202acc096dda ]

In dm_dp_mst_detect(), We should check whether or not @connector
has been unregistered from userspace. If the connector is unregistered,
we should return disconnected status.

Fixes: 4562236b3bc0 ("drm/amd/dc: Add dc display driver (v2)")
Signed-off-by: Yingjie Wang &lt;wangyingjie55@126.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>amd/display: convert DRM_DEBUG_ATOMIC to drm_dbg_atomic</title>
<updated>2021-06-02T21:58:11+00:00</updated>
<author>
<name>Simon Ser</name>
<email>contact@emersion.fr</email>
</author>
<published>2021-05-26T13:55:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=e7591a8d56bab89c617dae055446b6337ec32dc9'/>
<id>e7591a8d56bab89c617dae055446b6337ec32dc9</id>
<content type='text'>
This allows to tie the log message to a specific DRM device.

Signed-off-by: Simon Ser &lt;contact@emersion.fr&gt;
Cc: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Cc: Harry Wentland &lt;hwentlan@amd.com&gt;
Cc: Nicholas Kazlauskas &lt;nicholas.kazlauskas@amd.com&gt;
Reviewed-by: Bas Nieuwenhuizen &lt;bas@basnieuwenhuizen.nl&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This allows to tie the log message to a specific DRM device.

Signed-off-by: Simon Ser &lt;contact@emersion.fr&gt;
Cc: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Cc: Harry Wentland &lt;hwentlan@amd.com&gt;
Cc: Nicholas Kazlauskas &lt;nicholas.kazlauskas@amd.com&gt;
Reviewed-by: Bas Nieuwenhuizen &lt;bas@basnieuwenhuizen.nl&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/amd/display: Fix potential memory leak in DMUB hw_init</title>
<updated>2021-06-02T21:55:10+00:00</updated>
<author>
<name>Roman Li</name>
<email>roman.li@amd.com</email>
</author>
<published>2021-05-10T15:58:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=c5699e2d863f58221044efdc3fa712dd32d55cde'/>
<id>c5699e2d863f58221044efdc3fa712dd32d55cde</id>
<content type='text'>
[Why]
On resume we perform DMUB hw_init which allocates memory:
dm_resume-&gt;dm_dmub_hw_init-&gt;dc_dmub_srv_create-&gt;kzalloc
That results in memory leak in suspend/resume scenarios.

[How]
Allocate memory for the DC wrapper to DMUB only if it was not
allocated before.
No need to reallocate it on suspend/resume.

Signed-off-by: Lang Yu &lt;Lang.Yu@amd.com&gt;
Signed-off-by: Roman Li &lt;roman.li@amd.com&gt;
Reviewed-by: Nicholas Kazlauskas &lt;Nicholas.Kazlauskas@amd.com&gt;
Acked-by: Qingqing Zhuo &lt;qingqing.zhuo@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>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[Why]
On resume we perform DMUB hw_init which allocates memory:
dm_resume-&gt;dm_dmub_hw_init-&gt;dc_dmub_srv_create-&gt;kzalloc
That results in memory leak in suspend/resume scenarios.

[How]
Allocate memory for the DC wrapper to DMUB only if it was not
allocated before.
No need to reallocate it on suspend/resume.

Signed-off-by: Lang Yu &lt;Lang.Yu@amd.com&gt;
Signed-off-by: Roman Li &lt;roman.li@amd.com&gt;
Reviewed-by: Nicholas Kazlauskas &lt;Nicholas.Kazlauskas@amd.com&gt;
Acked-by: Qingqing Zhuo &lt;qingqing.zhuo@amd.com&gt;
Tested-by: Daniel Wheeler &lt;daniel.wheeler@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/amd/display: Fix overlay validation by considering cursors</title>
<updated>2021-06-02T21:51:53+00:00</updated>
<author>
<name>Rodrigo Siqueira</name>
<email>Rodrigo.Siqueira@amd.com</email>
</author>
<published>2021-05-14T11:47:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=33f409e60eb0c59a4d0d06a62ab4642a988e17f7'/>
<id>33f409e60eb0c59a4d0d06a62ab4642a988e17f7</id>
<content type='text'>
A few weeks ago, we saw a two cursor issue in a ChromeOS system. We
fixed it in the commit:

 drm/amd/display: Fix two cursor duplication when using overlay
 (read the commit message for more details)

After this change, we noticed that some IGT subtests related to
kms_plane and kms_plane_scaling started to fail. After investigating
this issue, we noticed that all subtests that fail have a primary plane
covering the overlay plane, which is currently rejected by amdgpu dm.
Fail those IGT tests highlight that our verification was too broad and
compromises the overlay usage in our drive. This patch fixes this issue
by ensuring that we only reject commits where the primary plane is not
fully covered by the overlay when the cursor hardware is enabled. With
this fix, all IGT tests start to pass again, which means our overlay
support works as expected.

Cc: Tianci.Yin &lt;tianci.yin@amd.com&gt;
Cc: Harry Wentland &lt;harry.wentland@amd.com&gt;
Cc: Nicholas Choi &lt;nicholas.choi@amd.com&gt;
Cc: Bhawanpreet Lakha &lt;bhawanpreet.lakha@amd.com&gt;
Cc: Nicholas Kazlauskas &lt;Nicholas.Kazlauskas@amd.com&gt;
Cc: Mark Yacoub &lt;markyacoub@google.com&gt;
Cc: Daniel Wheeler &lt;daniel.wheeler@amd.com&gt;

Tested-by: Daniel Wheeler &lt;daniel.wheeler@amd.com&gt;
Signed-off-by: Rodrigo Siqueira &lt;Rodrigo.Siqueira@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
A few weeks ago, we saw a two cursor issue in a ChromeOS system. We
fixed it in the commit:

 drm/amd/display: Fix two cursor duplication when using overlay
 (read the commit message for more details)

After this change, we noticed that some IGT subtests related to
kms_plane and kms_plane_scaling started to fail. After investigating
this issue, we noticed that all subtests that fail have a primary plane
covering the overlay plane, which is currently rejected by amdgpu dm.
Fail those IGT tests highlight that our verification was too broad and
compromises the overlay usage in our drive. This patch fixes this issue
by ensuring that we only reject commits where the primary plane is not
fully covered by the overlay when the cursor hardware is enabled. With
this fix, all IGT tests start to pass again, which means our overlay
support works as expected.

Cc: Tianci.Yin &lt;tianci.yin@amd.com&gt;
Cc: Harry Wentland &lt;harry.wentland@amd.com&gt;
Cc: Nicholas Choi &lt;nicholas.choi@amd.com&gt;
Cc: Bhawanpreet Lakha &lt;bhawanpreet.lakha@amd.com&gt;
Cc: Nicholas Kazlauskas &lt;Nicholas.Kazlauskas@amd.com&gt;
Cc: Mark Yacoub &lt;markyacoub@google.com&gt;
Cc: Daniel Wheeler &lt;daniel.wheeler@amd.com&gt;

Tested-by: Daniel Wheeler &lt;daniel.wheeler@amd.com&gt;
Signed-off-by: Rodrigo Siqueira &lt;Rodrigo.Siqueira@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/amd/display: Fix GPU scaling regression by FS video support</title>
<updated>2021-06-02T21:48:32+00:00</updated>
<author>
<name>Nicholas Kazlauskas</name>
<email>nicholas.kazlauskas@amd.com</email>
</author>
<published>2021-05-19T20:12:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=a53085c1d20f914590fe446d01d4546150758983'/>
<id>a53085c1d20f914590fe446d01d4546150758983</id>
<content type='text'>
[Why]
FS video support regressed GPU scaling and the scaled buffer ends up
stuck in the top left of the screen at native size - full, aspect,
center scaling modes do not function.

This is because decide_crtc_timing_for_drm_display_mode() does not
get called when scaling is enabled.

[How]
Split recalculate timing and scaling into two different flags.

We don't want to call drm_mode_set_crtcinfo() for scaling, but we
do want to call it for FS video.

Optimize and move preferred_refresh calculation next to
decide_crtc_timing_for_drm_display_mode() like it used to be since
that's not used for FS video.

We don't need to copy over the VIC or polarity in the case of FS video
modes because those don't change.

Fixes: 6f59f229f8ed7a ("drm/amd/display: Skip modeset for front porch change")

Cc: Aurabindo Pillai &lt;aurabindo.pillai@amd.com&gt;
Signed-off-by: Nicholas Kazlauskas &lt;nicholas.kazlauskas@amd.com&gt;
Reviewed-by: Aurabindo Pillai &lt;aurabindo.pillai@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[Why]
FS video support regressed GPU scaling and the scaled buffer ends up
stuck in the top left of the screen at native size - full, aspect,
center scaling modes do not function.

This is because decide_crtc_timing_for_drm_display_mode() does not
get called when scaling is enabled.

[How]
Split recalculate timing and scaling into two different flags.

We don't want to call drm_mode_set_crtcinfo() for scaling, but we
do want to call it for FS video.

Optimize and move preferred_refresh calculation next to
decide_crtc_timing_for_drm_display_mode() like it used to be since
that's not used for FS video.

We don't need to copy over the VIC or polarity in the case of FS video
modes because those don't change.

Fixes: 6f59f229f8ed7a ("drm/amd/display: Skip modeset for front porch change")

Cc: Aurabindo Pillai &lt;aurabindo.pillai@amd.com&gt;
Signed-off-by: Nicholas Kazlauskas &lt;nicholas.kazlauskas@amd.com&gt;
Reviewed-by: Aurabindo Pillai &lt;aurabindo.pillai@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/amd/display: Allow bandwidth validation for 0 streams.</title>
<updated>2021-06-02T21:48:20+00:00</updated>
<author>
<name>Bindu Ramamurthy</name>
<email>bindu.r@amd.com</email>
</author>
<published>2021-05-20T14:06:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=ba8e59773ae59818695d1e20b8939282da80ec8c'/>
<id>ba8e59773ae59818695d1e20b8939282da80ec8c</id>
<content type='text'>
[Why]
Bandwidth calculations are triggered for non zero streams, and
in case of 0 streams, these calculations were skipped with
pstate status not being updated.

[How]
As the pstate status is applicable for non zero streams, check
added for allowing 0 streams inline with dcn internal bandwidth
validations.

Signed-off-by: Bindu Ramamurthy &lt;bindu.r@amd.com&gt;
Reviewed-by: Roman Li &lt;Roman.Li@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[Why]
Bandwidth calculations are triggered for non zero streams, and
in case of 0 streams, these calculations were skipped with
pstate status not being updated.

[How]
As the pstate status is applicable for non zero streams, check
added for allowing 0 streams inline with dcn internal bandwidth
validations.

Signed-off-by: Bindu Ramamurthy &lt;bindu.r@amd.com&gt;
Reviewed-by: Roman Li &lt;Roman.Li@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/amd/display: Disconnect non-DP with no EDID</title>
<updated>2021-05-19T22:03:30+00:00</updated>
<author>
<name>Chris Park</name>
<email>Chris.Park@amd.com</email>
</author>
<published>2021-05-04T20:20:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=080039273b126eeb0185a61c045893a25dbc046e'/>
<id>080039273b126eeb0185a61c045893a25dbc046e</id>
<content type='text'>
[Why]
Active DP dongles return no EDID when dongle
is connected, but VGA display is taken out.
Current driver behavior does not remove the
active display when this happens, and this is
a gap between dongle DTP and dongle behavior.

[How]
For active DP dongles and non-DP scenario,
disconnect sink on detection when no EDID
is read due to timeout.

Signed-off-by: Chris Park &lt;Chris.Park@amd.com&gt;
Reviewed-by: Nicholas Kazlauskas &lt;Nicholas.Kazlauskas@amd.com&gt;
Acked-by: Stylon Wang &lt;stylon.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;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[Why]
Active DP dongles return no EDID when dongle
is connected, but VGA display is taken out.
Current driver behavior does not remove the
active display when this happens, and this is
a gap between dongle DTP and dongle behavior.

[How]
For active DP dongles and non-DP scenario,
disconnect sink on detection when no EDID
is read due to timeout.

Signed-off-by: Chris Park &lt;Chris.Park@amd.com&gt;
Reviewed-by: Nicholas Kazlauskas &lt;Nicholas.Kazlauskas@amd.com&gt;
Acked-by: Stylon Wang &lt;stylon.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;
</pre>
</div>
</content>
</entry>
</feed>
