<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/drivers/gpu/drm/amd/display, branch linux-4.18.y</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: fix gamma not being applied</title>
<updated>2018-11-21T08:21:57+00:00</updated>
<author>
<name>SivapiriyanKumarasamy</name>
<email>sivapiriyan.kumarasamy@amd.com</email>
</author>
<published>2018-09-12T18:15:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=7cb3b831fea3bef8cdaa60b51ee840e4e0bde29f'/>
<id>7cb3b831fea3bef8cdaa60b51ee840e4e0bde29f</id>
<content type='text'>
[ Upstream commit 30049754ab7c4b6148dd3cd64af7d54850604582 ]

[WHY]
Previously night light forced a full update by
applying a  transfer function update regardless of if it was changed.
This logic was removed,

Now gamma surface updates are only applied when there is also a plane
info update, this does not work in cases such as using the night light
slider.

[HOW]
When moving the night light slider we will perform a full update if
the gamma has changed and there is a surface, even when the surface
has not changed. Also get stream updates in setgamma prior to
update planes and stream.

Signed-off-by: SivapiriyanKumarasamy &lt;sivapiriyan.kumarasamy@amd.com&gt;
Reviewed-by: Anthony Koo &lt;Anthony.Koo@amd.com&gt;
Acked-by: Bhawanpreet Lakha &lt;Bhawanpreet.Lakha@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 30049754ab7c4b6148dd3cd64af7d54850604582 ]

[WHY]
Previously night light forced a full update by
applying a  transfer function update regardless of if it was changed.
This logic was removed,

Now gamma surface updates are only applied when there is also a plane
info update, this does not work in cases such as using the night light
slider.

[HOW]
When moving the night light slider we will perform a full update if
the gamma has changed and there is a surface, even when the surface
has not changed. Also get stream updates in setgamma prior to
update planes and stream.

Signed-off-by: SivapiriyanKumarasamy &lt;sivapiriyan.kumarasamy@amd.com&gt;
Reviewed-by: Anthony Koo &lt;Anthony.Koo@amd.com&gt;
Acked-by: Bhawanpreet Lakha &lt;Bhawanpreet.Lakha@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/amd/display: fix bug of accessing invalid memory</title>
<updated>2018-11-21T08:21:56+00:00</updated>
<author>
<name>Su Sung Chung</name>
<email>Su.Chung@amd.com</email>
</author>
<published>2018-09-20T19:03:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=f813b2981fc39472889f10ae82f06162e40e7486'/>
<id>f813b2981fc39472889f10ae82f06162e40e7486</id>
<content type='text'>
[ Upstream commit 43c3ff27a47d83d153c4adc088243ba594582bf5 ]

[Why]
A loop inside of build_evenly_distributed_points function that traverse through
the array of points become an infinite loop when m_GammaUpdates does not
get assigned to any value.

[How]
In DMColor, clear m_gammaIsValid bit just before writting all Zeromem for
m_GammaUpdates, to prevent calling build_evenly_distributed_points
before m_GammaUpdates gets assigned to some value.

Signed-off-by: Su Sung Chung &lt;Su.Chung@amd.com&gt;
Reviewed-by: Aric Cyr &lt;Aric.Cyr@amd.com&gt;
Acked-by: Bhawanpreet Lakha &lt;Bhawanpreet.Lakha@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 43c3ff27a47d83d153c4adc088243ba594582bf5 ]

[Why]
A loop inside of build_evenly_distributed_points function that traverse through
the array of points become an infinite loop when m_GammaUpdates does not
get assigned to any value.

[How]
In DMColor, clear m_gammaIsValid bit just before writting all Zeromem for
m_GammaUpdates, to prevent calling build_evenly_distributed_points
before m_GammaUpdates gets assigned to some value.

Signed-off-by: Su Sung Chung &lt;Su.Chung@amd.com&gt;
Reviewed-by: Aric Cyr &lt;Aric.Cyr@amd.com&gt;
Acked-by: Bhawanpreet Lakha &lt;Bhawanpreet.Lakha@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/amd/display: Signal hw_done() after waiting for flip_done()</title>
<updated>2018-11-04T13:51:47+00:00</updated>
<author>
<name>Shirish S</name>
<email>shirish.s@amd.com</email>
</author>
<published>2018-09-24T13:31:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=43cb734246c0d7fdea02aab272ae550f76a6949f'/>
<id>43cb734246c0d7fdea02aab272ae550f76a6949f</id>
<content type='text'>
[ Upstream commit 987bf116445db5d63a5c2ed94c4479687d9c9973 ]

In amdgpu_dm_commit_tail(), wait until flip_done() is signaled before
we signal hw_done().

[Why]

This is to temporarily address a paging error that occurs when a
nonblocking commit contends with another commit, particularly in a
mirrored display configuration where at least 2 CRTCs are updated.
The error occurs in drm_atomic_helper_wait_for_flip_done(), when we
attempt to access the contents of new_crtc_state-&gt;commit.

Here's the sequence for a mirrored 2 display setup (irrelevant steps
left out for clarity):

**THREAD 1**                        | **THREAD 2**
                                    |
Initialize atomic state for flip    |
                                    |
Queue worker                        |
                                   ...

                                    | Do work for flip
                                    |
                                    | Signal hw_done() on CRTC 1
                                    | Signal hw_done() on CRTC 2
                                    |
                                    | Wait for flip_done() on CRTC 1

                                &lt;---- **PREEMPTED BY THREAD 1**

Initialize atomic state for cursor  |
update (1)                          |
                                    |
Do cursor update work on both CRTCs |
                                    |
Clear atomic state (2)              |
**DONE**                            |
                                   ...
                                    |
                                    | Wait for flip_done() on CRTC 2
                                    | *ERROR*
                                    |

The issue starts with (1). When the atomic state is initialized, the
current CRTC states are duplicated to be the new_crtc_states, and
referenced to be the old_crtc_states. (The new_crtc_states are to be
filled with update data.)

Some things to note:

* Due to the mirrored configuration, the cursor updates on both CRTCs.

* At this point, the pflip IRQ has already been handled, and flip_done
  signaled on all CRTCs. The cursor commit can therefore continue.

* The old_crtc_states used by the cursor update are the **same states**
  as the new_crtc_states used by the flip worker.

At (2), the old_crtc_state is freed (*), and the cursor commit
completes. We then context switch back to the flip worker, where we
attempt to access the new_crtc_state-&gt;commit object. This is
problematic, as this state has already been freed.

(*) Technically, 'state-&gt;crtcs[i].state' is freed, which was made to
    reference old_crtc_state in drm_atomic_helper_swap_state()

[How]

By moving hw_done() after wait_for_flip_done(), we're guaranteed that
the new_crtc_state (from the flip worker's perspective) still exists.
This is because any other commit will be blocked, waiting for the
hw_done() signal.

Note that both the i915 and imx drivers have this sequence flipped
already, masking this problem.

Signed-off-by: Shirish S &lt;shirish.s@amd.com&gt;
Signed-off-by: Leo Li &lt;sunpeng.li@amd.com&gt;
Reviewed-by: Harry Wentland &lt;harry.wentland@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 987bf116445db5d63a5c2ed94c4479687d9c9973 ]

In amdgpu_dm_commit_tail(), wait until flip_done() is signaled before
we signal hw_done().

[Why]

This is to temporarily address a paging error that occurs when a
nonblocking commit contends with another commit, particularly in a
mirrored display configuration where at least 2 CRTCs are updated.
The error occurs in drm_atomic_helper_wait_for_flip_done(), when we
attempt to access the contents of new_crtc_state-&gt;commit.

Here's the sequence for a mirrored 2 display setup (irrelevant steps
left out for clarity):

**THREAD 1**                        | **THREAD 2**
                                    |
Initialize atomic state for flip    |
                                    |
Queue worker                        |
                                   ...

                                    | Do work for flip
                                    |
                                    | Signal hw_done() on CRTC 1
                                    | Signal hw_done() on CRTC 2
                                    |
                                    | Wait for flip_done() on CRTC 1

                                &lt;---- **PREEMPTED BY THREAD 1**

Initialize atomic state for cursor  |
update (1)                          |
                                    |
Do cursor update work on both CRTCs |
                                    |
Clear atomic state (2)              |
**DONE**                            |
                                   ...
                                    |
                                    | Wait for flip_done() on CRTC 2
                                    | *ERROR*
                                    |

The issue starts with (1). When the atomic state is initialized, the
current CRTC states are duplicated to be the new_crtc_states, and
referenced to be the old_crtc_states. (The new_crtc_states are to be
filled with update data.)

Some things to note:

* Due to the mirrored configuration, the cursor updates on both CRTCs.

* At this point, the pflip IRQ has already been handled, and flip_done
  signaled on all CRTCs. The cursor commit can therefore continue.

* The old_crtc_states used by the cursor update are the **same states**
  as the new_crtc_states used by the flip worker.

At (2), the old_crtc_state is freed (*), and the cursor commit
completes. We then context switch back to the flip worker, where we
attempt to access the new_crtc_state-&gt;commit object. This is
problematic, as this state has already been freed.

(*) Technically, 'state-&gt;crtcs[i].state' is freed, which was made to
    reference old_crtc_state in drm_atomic_helper_swap_state()

[How]

By moving hw_done() after wait_for_flip_done(), we're guaranteed that
the new_crtc_state (from the flip worker's perspective) still exists.
This is because any other commit will be blocked, waiting for the
hw_done() signal.

Note that both the i915 and imx drivers have this sequence flipped
already, masking this problem.

Signed-off-by: Shirish S &lt;shirish.s@amd.com&gt;
Signed-off-by: Leo Li &lt;sunpeng.li@amd.com&gt;
Reviewed-by: Harry Wentland &lt;harry.wentland@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 use of uninitialized memory</title>
<updated>2018-10-03T23:59:05+00:00</updated>
<author>
<name>Wesley Chalmers</name>
<email>Wesley.Chalmers@amd.com</email>
</author>
<published>2018-05-29T21:45:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=dd5ac3dcb22eb0f30cfa3137542fdec260bca0ef'/>
<id>dd5ac3dcb22eb0f30cfa3137542fdec260bca0ef</id>
<content type='text'>
[ Upstream commit f3e077d95ca0a016fdf3d6b1e97a9910dfdaff17 ]

DML does not calculate chroma values for RQ when surface is not YUV, but DC
will unconditionally use the uninitialized values for HW programming.
This does not cause visual corruption since HW will ignore garbage chroma
values when surface is not YUV, but causes presubmission tests to fail
golden value comparison.

Signed-off-by: Wesley Chalmers &lt;Wesley.Chalmers@amd.com&gt;
Signed-off-by: Eryk Brol &lt;eryk.brol@amd.com&gt;
Reviewed-by: Wenjing Liu &lt;Wenjing.Liu@amd.com&gt;
Acked-by: Harry Wentland &lt;harry.wentland@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit f3e077d95ca0a016fdf3d6b1e97a9910dfdaff17 ]

DML does not calculate chroma values for RQ when surface is not YUV, but DC
will unconditionally use the uninitialized values for HW programming.
This does not cause visual corruption since HW will ignore garbage chroma
values when surface is not YUV, but causes presubmission tests to fail
golden value comparison.

Signed-off-by: Wesley Chalmers &lt;Wesley.Chalmers@amd.com&gt;
Signed-off-by: Eryk Brol &lt;eryk.brol@amd.com&gt;
Reviewed-by: Wenjing Liu &lt;Wenjing.Liu@amd.com&gt;
Acked-by: Harry Wentland &lt;harry.wentland@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/amd/display/dc/dce: Fix multiple potential integer overflows</title>
<updated>2018-10-03T23:59:05+00:00</updated>
<author>
<name>Gustavo A. R. Silva</name>
<email>gustavo@embeddedor.com</email>
</author>
<published>2018-07-04T13:22:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=e21238f1be65530a0d747e9f91202820fe73ce32'/>
<id>e21238f1be65530a0d747e9f91202820fe73ce32</id>
<content type='text'>
[ Upstream commit 6f3472a993e7cb63cde5d818dcabc8e42fc03744 ]

Add suffix ULL to constant 5 and cast variables target_pix_clk_khz and
feedback_divider to uint64_t in order to avoid multiple potential integer
overflows and give the compiler complete information about the proper
arithmetic to use.

Notice that such constant and variables are used in contexts that
expect expressions of type uint64_t (64 bits, unsigned). The current
casts to uint64_t effectively apply to each expression as a whole,
but they do not prevent them from being evaluated using 32-bit
arithmetic instead of 64-bit arithmetic.

Also, once the expressions are properly evaluated using 64-bit
arithmentic, there is no need for the parentheses that enclose
them.

Addresses-Coverity-ID: 1460245 ("Unintentional integer overflow")
Addresses-Coverity-ID: 1460286 ("Unintentional integer overflow")
Addresses-Coverity-ID: 1460401 ("Unintentional integer overflow")
Fixes: 4562236b3bc0 ("drm/amd/dc: Add dc display driver (v2)")
Signed-off-by: Gustavo A. R. Silva &lt;gustavo@embeddedor.com&gt;
Reviewed-by: Harry Wentland &lt;harry.wentland@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 6f3472a993e7cb63cde5d818dcabc8e42fc03744 ]

Add suffix ULL to constant 5 and cast variables target_pix_clk_khz and
feedback_divider to uint64_t in order to avoid multiple potential integer
overflows and give the compiler complete information about the proper
arithmetic to use.

Notice that such constant and variables are used in contexts that
expect expressions of type uint64_t (64 bits, unsigned). The current
casts to uint64_t effectively apply to each expression as a whole,
but they do not prevent them from being evaluated using 32-bit
arithmetic instead of 64-bit arithmetic.

Also, once the expressions are properly evaluated using 64-bit
arithmentic, there is no need for the parentheses that enclose
them.

Addresses-Coverity-ID: 1460245 ("Unintentional integer overflow")
Addresses-Coverity-ID: 1460286 ("Unintentional integer overflow")
Addresses-Coverity-ID: 1460401 ("Unintentional integer overflow")
Fixes: 4562236b3bc0 ("drm/amd/dc: Add dc display driver (v2)")
Signed-off-by: Gustavo A. R. Silva &lt;gustavo@embeddedor.com&gt;
Reviewed-by: Harry Wentland &lt;harry.wentland@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/amd/display: support access ddc for mst branch</title>
<updated>2018-09-26T06:39:40+00:00</updated>
<author>
<name>Eric Yang</name>
<email>Eric.Yang2@amd.com</email>
</author>
<published>2018-06-12T22:37:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=b0442208f62f77b100b55f114f128f54e01dd07a'/>
<id>b0442208f62f77b100b55f114f128f54e01dd07a</id>
<content type='text'>
[ Upstream commit 0a14544661fad1606cc96aece30b2950fd9c4c81 ]

[Why]
Megachip dockings accesses ddc line through display driver when
installing FW. Previously, we would fail every transaction because
link attached to mst branch did not have their ddc transaction type
set.

[How]
Set ddc transaction type when mst branch is connected.

Signed-off-by: Eric Yang &lt;Eric.Yang2@amd.com&gt;
Reviewed-by: Charlene Liu &lt;Charlene.Liu@amd.com&gt;
Acked-by: Harry Wentland &lt;harry.wentland@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 0a14544661fad1606cc96aece30b2950fd9c4c81 ]

[Why]
Megachip dockings accesses ddc line through display driver when
installing FW. Previously, we would fail every transaction because
link attached to mst branch did not have their ddc transaction type
set.

[How]
Set ddc transaction type when mst branch is connected.

Signed-off-by: Eric Yang &lt;Eric.Yang2@amd.com&gt;
Reviewed-by: Charlene Liu &lt;Charlene.Liu@amd.com&gt;
Acked-by: Harry Wentland &lt;harry.wentland@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/amd/display: Prevent PSR from being enabled if initialization fails</title>
<updated>2018-09-19T20:41:35+00:00</updated>
<author>
<name>Anthony Koo</name>
<email>Anthony.Koo@amd.com</email>
</author>
<published>2018-07-17T13:43:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=088ce054c745f94a3d7a48ceedb483164b8724d0'/>
<id>088ce054c745f94a3d7a48ceedb483164b8724d0</id>
<content type='text'>
[ Upstream commit 9907704174e0ad4ed02766fac4049971e583323d ]

[Why]
PSR_SET command is sent to the microcontroller in order to initialize
parameters needed for PSR feature, such as telling the microcontroller
which pipe is driving the PSR supported panel. When this command is
skipped or fails, the microcontroller may program the wrong thing if
driver tries to enable PSR.

[How]
If PSR_SET fails, do not set psr_enable flag to indicate the feature is
not yet initialized.

Signed-off-by: Anthony Koo &lt;Anthony.Koo@amd.com&gt;
Reviewed-by: Aric Cyr &lt;Aric.Cyr@amd.com&gt;
Acked-by: Bhawanpreet Lakha &lt;Bhawanpreet.Lakha@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 9907704174e0ad4ed02766fac4049971e583323d ]

[Why]
PSR_SET command is sent to the microcontroller in order to initialize
parameters needed for PSR feature, such as telling the microcontroller
which pipe is driving the PSR supported panel. When this command is
skipped or fails, the microcontroller may program the wrong thing if
driver tries to enable PSR.

[How]
If PSR_SET fails, do not set psr_enable flag to indicate the feature is
not yet initialized.

Signed-off-by: Anthony Koo &lt;Anthony.Koo@amd.com&gt;
Reviewed-by: Aric Cyr &lt;Aric.Cyr@amd.com&gt;
Acked-by: Bhawanpreet Lakha &lt;Bhawanpreet.Lakha@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/amd/display: Check if clock source in use before disabling</title>
<updated>2018-09-15T07:46:59+00:00</updated>
<author>
<name>Mikita Lipski</name>
<email>mikita.lipski@amd.com</email>
</author>
<published>2018-08-02T13:45:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=1e7e7a541e0812df95ebeb73828118a88283a35d'/>
<id>1e7e7a541e0812df95ebeb73828118a88283a35d</id>
<content type='text'>
commit ad8960a6cb06c446d0a391ce095f6f28edf36aff upstream.

[why]
We are disabling clock source while other pipes are still using
it, because we don't verify the number of pipes that share it.

[how]
- Adding a function in resources to return the number of pipes
sharing the clock source.
- Checking that no one is sharing the clock source before disabling

Signed-off-by: Mikita Lipski &lt;mikita.lipski@amd.com&gt;
Reviewed-by: Harry Wentland &lt;Harry.Wentland@amd.com&gt;
Acked-by: Leo Li &lt;sunpeng.li@amd.com&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>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit ad8960a6cb06c446d0a391ce095f6f28edf36aff upstream.

[why]
We are disabling clock source while other pipes are still using
it, because we don't verify the number of pipes that share it.

[how]
- Adding a function in resources to return the number of pipes
sharing the clock source.
- Checking that no one is sharing the clock source before disabling

Signed-off-by: Mikita Lipski &lt;mikita.lipski@amd.com&gt;
Reviewed-by: Harry Wentland &lt;Harry.Wentland@amd.com&gt;
Acked-by: Leo Li &lt;sunpeng.li@amd.com&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;

</pre>
</div>
</content>
</entry>
<entry>
<title>drm/amd/display: Pass connector id when executing VBIOS CT</title>
<updated>2018-09-15T07:46:59+00:00</updated>
<author>
<name>Mikita Lipski</name>
<email>mikita.lipski@amd.com</email>
</author>
<published>2018-07-17T14:52:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=dfe84b71296f6d28a60038287d5159ca0f177f06'/>
<id>dfe84b71296f6d28a60038287d5159ca0f177f06</id>
<content type='text'>
commit 433149130c31de3f63b17b4ce08b45dab208f7e8 upstream.

[why]
Older ASICs require both phys_id and connector_id
to execute bios command table. If we are not passing the
right connector_id - it can lead to a black screen.

[how]
Set connector_obj_id when executing vbios command table

Signed-off-by: Mikita Lipski &lt;mikita.lipski@amd.com&gt;
Reviewed-by: Hersen Wu &lt;hersenxs.wu@amd.com&gt;
Acked-by: Leo Li &lt;sunpeng.li@amd.com&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>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 433149130c31de3f63b17b4ce08b45dab208f7e8 upstream.

[why]
Older ASICs require both phys_id and connector_id
to execute bios command table. If we are not passing the
right connector_id - it can lead to a black screen.

[how]
Set connector_obj_id when executing vbios command table

Signed-off-by: Mikita Lipski &lt;mikita.lipski@amd.com&gt;
Reviewed-by: Hersen Wu &lt;hersenxs.wu@amd.com&gt;
Acked-by: Leo Li &lt;sunpeng.li@amd.com&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;

</pre>
</div>
</content>
</entry>
<entry>
<title>drm/amd/display: Report non-DP display as disconnected without EDID</title>
<updated>2018-09-15T07:46:58+00:00</updated>
<author>
<name>Harry Wentland</name>
<email>harry.wentland@amd.com</email>
</author>
<published>2018-08-01T14:48:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=590eda32ee4291e3862c607f69711192a6612b03'/>
<id>590eda32ee4291e3862c607f69711192a6612b03</id>
<content type='text'>
commit 01dc285d5cd89b77686d8baef8482c58d7dc3ead upstream.

[Why]
Some boards seem to have a problem where HPD is high on HDMI even though
no display is connected. We don't want to report these as connected. DP
spec still requires us to report DP displays as connected when HPD is
high but we can't read the EDID in order to go to fail-safe mode.

[How]
If connector_signal is not DP abort detection if we can't retrieve the
EDID.

v2: Add Bugzilla and stable

Bugzilla: https://bugs.freedesktop.org/107390
Bugzilla: https://bugs.freedesktop.org/106846
Cc: stable@vger.kernel.org
Signed-off-by: Harry Wentland &lt;harry.wentland@amd.com&gt;
Acked-by: Alex Deucher &lt;alexander.deucher@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: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 01dc285d5cd89b77686d8baef8482c58d7dc3ead upstream.

[Why]
Some boards seem to have a problem where HPD is high on HDMI even though
no display is connected. We don't want to report these as connected. DP
spec still requires us to report DP displays as connected when HPD is
high but we can't read the EDID in order to go to fail-safe mode.

[How]
If connector_signal is not DP abort detection if we can't retrieve the
EDID.

v2: Add Bugzilla and stable

Bugzilla: https://bugs.freedesktop.org/107390
Bugzilla: https://bugs.freedesktop.org/106846
Cc: stable@vger.kernel.org
Signed-off-by: Harry Wentland &lt;harry.wentland@amd.com&gt;
Acked-by: Alex Deucher &lt;alexander.deucher@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: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
</feed>
