<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/drivers/gpu/drm/amd/display, branch v5.5.7</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>drm/amdgpu/display: handle multiple numbers of fclks in dcn_calcs.c (v2)</title>
<updated>2020-02-24T07:38:51+00:00</updated>
<author>
<name>Alex Deucher</name>
<email>alexander.deucher@amd.com</email>
</author>
<published>2020-01-28T19:39:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=8d12e0b3912e47c9c0160a6bed23cbcb0bbf1ca0'/>
<id>8d12e0b3912e47c9c0160a6bed23cbcb0bbf1ca0</id>
<content type='text'>
[ Upstream commit c37243579d6c881c575dcfb54cf31c9ded88f946 ]

We might get different numbers of clocks from powerplay depending
on what the OEM has populated.

v2: add assert for at least one level

Bug: https://gitlab.freedesktop.org/drm/amd/issues/963
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 c37243579d6c881c575dcfb54cf31c9ded88f946 ]

We might get different numbers of clocks from powerplay depending
on what the OEM has populated.

v2: add assert for at least one level

Bug: https://gitlab.freedesktop.org/drm/amd/issues/963
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: do not allocate display_mode_lib unnecessarily</title>
<updated>2020-02-24T07:38:45+00:00</updated>
<author>
<name>Dor Askayo</name>
<email>dor.askayo@gmail.com</email>
</author>
<published>2020-01-04T12:22:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=c7ef30f0a5bc6aa266a3d6c8a698f05df8fff647'/>
<id>c7ef30f0a5bc6aa266a3d6c8a698f05df8fff647</id>
<content type='text'>
[ Upstream commit bb67bfd2e7101bf2ac5327b0b7a847cd9fb9723f ]

This allocation isn't required and can fail when resuming from suspend.

Bug: https://gitlab.freedesktop.org/drm/amd/issues/1009
Signed-off-by: Dor Askayo &lt;dor.askayo@gmail.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>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit bb67bfd2e7101bf2ac5327b0b7a847cd9fb9723f ]

This allocation isn't required and can fail when resuming from suspend.

Bug: https://gitlab.freedesktop.org/drm/amd/issues/1009
Signed-off-by: Dor Askayo &lt;dor.askayo@gmail.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;
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/amd/display: fixup DML dependencies</title>
<updated>2020-02-24T07:38:33+00:00</updated>
<author>
<name>Jun Lei</name>
<email>Jun.Lei@amd.com</email>
</author>
<published>2019-12-18T19:40:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=e3e70f500d08c1ec58f85e7c725be80863ec624b'/>
<id>e3e70f500d08c1ec58f85e7c725be80863ec624b</id>
<content type='text'>
[ Upstream commit 34ad0230062c39cdcba564d16d122c0fb467a7d6 ]

[why]
Need to fix DML portability issues to enable SW unit testing around DML

[how]
Move calcs into dc include folder since multiple components reference it
Remove relative paths to external dependencies

Signed-off-by: Jun Lei &lt;Jun.Lei@amd.com&gt;
Reviewed-by: Anthony Koo &lt;Anthony.Koo@amd.com&gt;
Acked-by: Harry Wentland &lt;harry.wentland@amd.com&gt;
Acked-by: Rodrigo Siqueira &lt;Rodrigo.Siqueira@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 34ad0230062c39cdcba564d16d122c0fb467a7d6 ]

[why]
Need to fix DML portability issues to enable SW unit testing around DML

[how]
Move calcs into dc include folder since multiple components reference it
Remove relative paths to external dependencies

Signed-off-by: Jun Lei &lt;Jun.Lei@amd.com&gt;
Reviewed-by: Anthony Koo &lt;Anthony.Koo@amd.com&gt;
Acked-by: Harry Wentland &lt;harry.wentland@amd.com&gt;
Acked-by: Rodrigo Siqueira &lt;Rodrigo.Siqueira@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: Lower DPP DTO only when safe</title>
<updated>2020-02-24T07:38:17+00:00</updated>
<author>
<name>Sung Lee</name>
<email>sung.lee@amd.com</email>
</author>
<published>2019-12-04T23:36:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=36a36d16067e3c6b863e68837ef4046ed43bcdb5'/>
<id>36a36d16067e3c6b863e68837ef4046ed43bcdb5</id>
<content type='text'>
[ Upstream commit 5479034576ec8b7166a66efe5de1d911feb43d4a ]

[Why]
A corner case currently exists where DPP DTO is lowered before
pipes are updated to a higher viewport. This causes underflow
as the DPPCLK is too low for the current viewport.

[How]
Only lower DPP DTO when it is safe to lower, or if
the newer clocks are higher than the current ones.

Signed-off-by: Sung Lee &lt;sung.lee@amd.com&gt;
Reviewed-by: Dmytro Laktyushkin &lt;Dmytro.Laktyushkin@amd.com&gt;
Reviewed-by: Tony Cheng &lt;Tony.Cheng@amd.com&gt;
Acked-by: Rodrigo Siqueira &lt;Rodrigo.Siqueira@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 5479034576ec8b7166a66efe5de1d911feb43d4a ]

[Why]
A corner case currently exists where DPP DTO is lowered before
pipes are updated to a higher viewport. This causes underflow
as the DPPCLK is too low for the current viewport.

[How]
Only lower DPP DTO when it is safe to lower, or if
the newer clocks are higher than the current ones.

Signed-off-by: Sung Lee &lt;sung.lee@amd.com&gt;
Reviewed-by: Dmytro Laktyushkin &lt;Dmytro.Laktyushkin@amd.com&gt;
Reviewed-by: Tony Cheng &lt;Tony.Cheng@amd.com&gt;
Acked-by: Rodrigo Siqueira &lt;Rodrigo.Siqueira@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 update_bw_bounding_box Calcs</title>
<updated>2020-02-24T07:38:17+00:00</updated>
<author>
<name>Sung Lee</name>
<email>sung.lee@amd.com</email>
</author>
<published>2019-12-02T21:45:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=5ede16d673b71aaaaa4629de2ffea8d3747df4ea'/>
<id>5ede16d673b71aaaaa4629de2ffea8d3747df4ea</id>
<content type='text'>
[ Upstream commit 615b9b585eb57c1d49382d16a62de768f2c6a340 ]

[Why]
Previously update_bw_bounding_box for RN was commented out
due to incorrect values causing BSOD on Hybrid Graphics.
However, commenting out this function also may cause issues
such as underflow in certain cases such as 2x4K displays.

[How]
Fix dram_speed_mts calculations.
Update from proper index of clock_limits[]

Signed-off-by: Sung Lee &lt;sung.lee@amd.com&gt;
Reviewed-by: Yongqiang Sun &lt;yongqiang.sun@amd.com&gt;
Acked-by: Rodrigo Siqueira &lt;Rodrigo.Siqueira@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 615b9b585eb57c1d49382d16a62de768f2c6a340 ]

[Why]
Previously update_bw_bounding_box for RN was commented out
due to incorrect values causing BSOD on Hybrid Graphics.
However, commenting out this function also may cause issues
such as underflow in certain cases such as 2x4K displays.

[How]
Fix dram_speed_mts calculations.
Update from proper index of clock_limits[]

Signed-off-by: Sung Lee &lt;sung.lee@amd.com&gt;
Reviewed-by: Yongqiang Sun &lt;yongqiang.sun@amd.com&gt;
Acked-by: Rodrigo Siqueira &lt;Rodrigo.Siqueira@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/amdgpu/dm: Do not throw an error for a display with no audio</title>
<updated>2020-02-24T07:38:11+00:00</updated>
<author>
<name>Chris Wilson</name>
<email>chris@chris-wilson.co.uk</email>
</author>
<published>2019-11-14T20:44:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=7255b9422cc266c23df73b35c2d6e58b4d592fc5'/>
<id>7255b9422cc266c23df73b35c2d6e58b4d592fc5</id>
<content type='text'>
[ Upstream commit 852a91d627e9ce849d68df9d3f5336689003bdc7 ]

An old display with no audio may not have an EDID with a CEA block, or
it may simply be too old to support audio. This is not a driver error,
so don't flag it as such.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112140
References: ae2a3495973e ("drm/amd: be quiet when no SAD block is found")
Signed-off-by: Chris Wilson &lt;chris@chris-wilson.co.uk&gt;
Cc: Harry Wentland &lt;harry.wentland@amd.com&gt;
Cc: Jean Delvare &lt;jdelvare@suse.de&gt;
Cc: Alex Deucher &lt;alexander.deucher@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 852a91d627e9ce849d68df9d3f5336689003bdc7 ]

An old display with no audio may not have an EDID with a CEA block, or
it may simply be too old to support audio. This is not a driver error,
so don't flag it as such.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112140
References: ae2a3495973e ("drm/amd: be quiet when no SAD block is found")
Signed-off-by: Chris Wilson &lt;chris@chris-wilson.co.uk&gt;
Cc: Harry Wentland &lt;harry.wentland@amd.com&gt;
Cc: Jean Delvare &lt;jdelvare@suse.de&gt;
Cc: Alex Deucher &lt;alexander.deucher@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: Renoir chroma viewport WA</title>
<updated>2020-02-24T07:38:10+00:00</updated>
<author>
<name>Eric Yang</name>
<email>Eric.Yang2@amd.com</email>
</author>
<published>2019-10-11T19:34:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=aee053bd0d397b43b32f5a0f4b7fd9b7d8228590'/>
<id>aee053bd0d397b43b32f5a0f4b7fd9b7d8228590</id>
<content type='text'>
[ Upstream commit 1cad8ff7ecc6b70a062b8e8b74a0cd08c928341d ]

[Why]
For unknown reason, immediate flip with host VM translation on NV12
surface will underflow on last row of PTE.

[How]
Hack chroma viewport height to make fetch one more row of PTE.
Note that this will cause hubp underflow on all video underlay
cases, but the underflow is not user visible since it is in
blank region.

Signed-off-by: Eric Yang &lt;Eric.Yang2@amd.com&gt;
Reviewed-by: Tony Cheng &lt;Tony.Cheng@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;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 1cad8ff7ecc6b70a062b8e8b74a0cd08c928341d ]

[Why]
For unknown reason, immediate flip with host VM translation on NV12
surface will underflow on last row of PTE.

[How]
Hack chroma viewport height to make fetch one more row of PTE.
Note that this will cause hubp underflow on all video underlay
cases, but the underflow is not user visible since it is in
blank region.

Signed-off-by: Eric Yang &lt;Eric.Yang2@amd.com&gt;
Reviewed-by: Tony Cheng &lt;Tony.Cheng@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;
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/amd/display: Retrain dongles when SINK_COUNT becomes non-zero</title>
<updated>2020-02-24T07:38:09+00:00</updated>
<author>
<name>Harry Wentland</name>
<email>harry.wentland@amd.com</email>
</author>
<published>2020-01-21T21:12:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=fc1be5273e93dc951d9e0e6590101a8f15a8f963'/>
<id>fc1be5273e93dc951d9e0e6590101a8f15a8f963</id>
<content type='text'>
[ Upstream commit 3eb6d7aca53d81ce888624f09cd44dc0302161e8 ]

[WHY]
Two years ago the patch referenced by the Fixes tag stopped running
dp_verify_link_cap_with_retries during DP detection when the reason
for the detection was a short-pulse interrupt. This effectively meant
that we were no longer doing the verify_link_cap training on active
dongles when their SINK_COUNT changed from 0 to 1.

A year ago this was partly remedied with:
commit 80adaebd2d41 ("drm/amd/display: Don't skip link training for empty dongle")

This made sure that we trained the dongle on initial hotplug (without
connected downstream devices).

This is all fine and dandy if it weren't for the fact that there are
some dongles on the market that don't like link training when SINK_COUNT
is 0 These dongles will in fact indicate a SINK_COUNT of 0 immediately
after hotplug, even when a downstream device is connected, and then
trigger a shortpulse interrupt indicating a SINK_COUNT change to 1.

In order to play nicely we will need our policy to not link train an
active DP dongle when SINK_COUNT is 0 but ensure we train it when the
SINK_COUNT changes to 1.

[HOW]
Call dp_verify_link_cap_with_retries on detection even when the detection
is triggered from a short pulse interrupt.

With this change we can also revert this commit which we'll do in a separate
follow-up change:
commit 80adaebd2d41 ("drm/amd/display: Don't skip link training for empty dongle")

Fixes: 0301ccbaf67d ("drm/amd/display: DP Compliance 400.1.1 failure")
Suggested-by: Louis Li &lt;Ching-shih.Li@amd.com&gt;
Tested-by: Louis Li &lt;Ching-shih.Li@amd.com&gt;
Cc: Wenjing Liu &lt;Wenjing.Liu@amd.com&gt;
Cc: Hersen Wu &lt;hersenxs.wu@amd.com&gt;
Cc: Eric Yang &lt;Eric.Yang2@amd.com&gt;
Reviewed-by: Wenjing Liu &lt;Wenjing.Liu@amd.com&gt;
Signed-off-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 3eb6d7aca53d81ce888624f09cd44dc0302161e8 ]

[WHY]
Two years ago the patch referenced by the Fixes tag stopped running
dp_verify_link_cap_with_retries during DP detection when the reason
for the detection was a short-pulse interrupt. This effectively meant
that we were no longer doing the verify_link_cap training on active
dongles when their SINK_COUNT changed from 0 to 1.

A year ago this was partly remedied with:
commit 80adaebd2d41 ("drm/amd/display: Don't skip link training for empty dongle")

This made sure that we trained the dongle on initial hotplug (without
connected downstream devices).

This is all fine and dandy if it weren't for the fact that there are
some dongles on the market that don't like link training when SINK_COUNT
is 0 These dongles will in fact indicate a SINK_COUNT of 0 immediately
after hotplug, even when a downstream device is connected, and then
trigger a shortpulse interrupt indicating a SINK_COUNT change to 1.

In order to play nicely we will need our policy to not link train an
active DP dongle when SINK_COUNT is 0 but ensure we train it when the
SINK_COUNT changes to 1.

[HOW]
Call dp_verify_link_cap_with_retries on detection even when the detection
is triggered from a short pulse interrupt.

With this change we can also revert this commit which we'll do in a separate
follow-up change:
commit 80adaebd2d41 ("drm/amd/display: Don't skip link training for empty dongle")

Fixes: 0301ccbaf67d ("drm/amd/display: DP Compliance 400.1.1 failure")
Suggested-by: Louis Li &lt;Ching-shih.Li@amd.com&gt;
Tested-by: Louis Li &lt;Ching-shih.Li@amd.com&gt;
Cc: Wenjing Liu &lt;Wenjing.Liu@amd.com&gt;
Cc: Hersen Wu &lt;hersenxs.wu@amd.com&gt;
Cc: Eric Yang &lt;Eric.Yang2@amd.com&gt;
Reviewed-by: Wenjing Liu &lt;Wenjing.Liu@amd.com&gt;
Signed-off-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: Clear state after exiting fixed active VRR state</title>
<updated>2020-02-24T07:38:06+00:00</updated>
<author>
<name>Amanda Liu</name>
<email>amanda.liu@amd.com</email>
</author>
<published>2019-12-06T20:12:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=c183d59ba7a0cda10e01729e98fd97a457337bdb'/>
<id>c183d59ba7a0cda10e01729e98fd97a457337bdb</id>
<content type='text'>
[ Upstream commit 6f8f76444baf405bacb0591d97549a71a9aaa1ac ]

[why]
Upon exiting a fixed active VRR state, the state isn't cleared. This
leads to the variable VRR range to be calculated incorrectly.

[how]
Set fixed active state to false when updating vrr params

Signed-off-by: Amanda Liu &lt;amanda.liu@amd.com&gt;
Reviewed-by: Anthony Koo &lt;Anthony.Koo@amd.com&gt;
Acked-by: Harry Wentland &lt;harry.wentland@amd.com&gt;
Acked-by: Rodrigo Siqueira &lt;Rodrigo.Siqueira@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 6f8f76444baf405bacb0591d97549a71a9aaa1ac ]

[why]
Upon exiting a fixed active VRR state, the state isn't cleared. This
leads to the variable VRR range to be calculated incorrectly.

[how]
Set fixed active state to false when updating vrr params

Signed-off-by: Amanda Liu &lt;amanda.liu@amd.com&gt;
Reviewed-by: Anthony Koo &lt;Anthony.Koo@amd.com&gt;
Acked-by: Harry Wentland &lt;harry.wentland@amd.com&gt;
Acked-by: Rodrigo Siqueira &lt;Rodrigo.Siqueira@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: Map ODM memory correctly when doing ODM combine</title>
<updated>2020-02-24T07:38:01+00:00</updated>
<author>
<name>Nikola Cornij</name>
<email>nikola.cornij@amd.com</email>
</author>
<published>2019-11-26T20:18:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=91cbd7ad5f94f335f3d58dd86085e939e6819528'/>
<id>91cbd7ad5f94f335f3d58dd86085e939e6819528</id>
<content type='text'>
[ Upstream commit ec5b356c58941bb8930858155d9ce14ceb3d30a0 ]

[why]
Up to 4 ODM memory pieces are required per ODM combine and cannot
overlap, i.e. each ODM "session" has to use its own memory pieces.
The ODM-memory mapping is currently broken for generic case.

The maximum number of memory pieces is ASIC-dependent, but it's always
big enough to satisfy maximum number of ODM combines. Memory pieces
are mapped as a bit-map, i.e. one memory piece corresponds to one bit.
The OPTC doing ODM needs to select memory pieces by setting the
corresponding bits, making sure there's no overlap with other OPTC
instances that might be doing ODM.

The current mapping works only for OPTC instance indexes smaller than
3. For instance indexes 3 and up it practically maps no ODM memory,
causing black, gray or white screen in display configs that include
ODM on OPTC instance 3 or up.

[how]
Statically map two unique ODM memory pieces for each OPTC instance
and piece them together when programming ODM combine mode.

Signed-off-by: Nikola Cornij &lt;nikola.cornij@amd.com&gt;
Reviewed-by: Jun Lei &lt;Jun.Lei@amd.com&gt;
Acked-by: Rodrigo Siqueira &lt;Rodrigo.Siqueira@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 ec5b356c58941bb8930858155d9ce14ceb3d30a0 ]

[why]
Up to 4 ODM memory pieces are required per ODM combine and cannot
overlap, i.e. each ODM "session" has to use its own memory pieces.
The ODM-memory mapping is currently broken for generic case.

The maximum number of memory pieces is ASIC-dependent, but it's always
big enough to satisfy maximum number of ODM combines. Memory pieces
are mapped as a bit-map, i.e. one memory piece corresponds to one bit.
The OPTC doing ODM needs to select memory pieces by setting the
corresponding bits, making sure there's no overlap with other OPTC
instances that might be doing ODM.

The current mapping works only for OPTC instance indexes smaller than
3. For instance indexes 3 and up it practically maps no ODM memory,
causing black, gray or white screen in display configs that include
ODM on OPTC instance 3 or up.

[how]
Statically map two unique ODM memory pieces for each OPTC instance
and piece them together when programming ODM combine mode.

Signed-off-by: Nikola Cornij &lt;nikola.cornij@amd.com&gt;
Reviewed-by: Jun Lei &lt;Jun.Lei@amd.com&gt;
Acked-by: Rodrigo Siqueira &lt;Rodrigo.Siqueira@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>
</feed>
