<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/drivers/gpu/drm/amd/display/modules, branch v5.7</title>
<subtitle>Mirror of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/
</subtitle>
<id>https://git.shady.money/linux/atom?h=v5.7</id>
<link rel='self' href='https://git.shady.money/linux/atom?h=v5.7'/>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/'/>
<updated>2020-03-31T16:26:14Z</updated>
<entry>
<title>drm/amd/display: LFC not working on 2.0x range monitors (v2)</title>
<updated>2020-03-31T16:26:14Z</updated>
<author>
<name>Aric Cyr</name>
<email>aric.cyr@amd.com</email>
</author>
<published>2020-03-11T22:10:20Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=5a6b5458699d8e6fdb5ae09d950935a48b79f8c7'/>
<id>urn:sha1:5a6b5458699d8e6fdb5ae09d950935a48b79f8c7</id>
<content type='text'>
[Why]
Nominal pixel clock and EDID information differ in precision so although
monitor reports maximum refresh is 2x minimum, LFC was not being
enabled.

[How]
Use minimum refresh rate as nominal/2 when EDID dictates that min
refresh = max refresh/2.

v2: squash in 64 bit divide fix

Signed-off-by: Aric Cyr &lt;aric.cyr@amd.com&gt;
Reviewed-by: Nicholas Kazlauskas &lt;Nicholas.Kazlauskas@amd.com&gt;
Acked-by: Rodrigo Siqueira &lt;Rodrigo.Siqueira@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
</content>
</entry>
<entry>
<title>drm/amd/display: Revert change to HDCP display states</title>
<updated>2020-03-31T16:26:14Z</updated>
<author>
<name>Isabel Zhang</name>
<email>isabel.zhang@amd.com</email>
</author>
<published>2020-03-11T19:59:41Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=58edb079102efa2b4029e5fe3dbdad78079bf425'/>
<id>urn:sha1:58edb079102efa2b4029e5fe3dbdad78079bf425</id>
<content type='text'>
[Why]
Change is causing a regression where the OPC app no longer functions
properly.

[How]
Revert the changelist causing the issue.

Signed-off-by: Isabel Zhang &lt;isabel.zhang@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;
</content>
</entry>
<entry>
<title>drm/amd/display: differentiate vsc sdp colorimetry use criteria between MST and SST</title>
<updated>2020-03-19T04:03:04Z</updated>
<author>
<name>Martin Tsai</name>
<email>martin.tsai@amd.com</email>
</author>
<published>2020-03-03T02:04:08Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=c38cc6770fd5f78a0918ed0b01af14de31aba5cb'/>
<id>urn:sha1:c38cc6770fd5f78a0918ed0b01af14de31aba5cb</id>
<content type='text'>
[Why]
We should check MST BU support capability on output port before building
vsc info packet.

[How]
Add a new definition for port and sink capability check.

Signed-off-by: Martin Tsai &lt;martin.tsai@amd.com&gt;
Reviewed-by: Wenjing Liu &lt;Wenjing.Liu@amd.com&gt;
Acked-by: Rodrigo Siqueira &lt;Rodrigo.Siqueira@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
</content>
</entry>
<entry>
<title>drm/amd/display: remove magic numbers in hdcp_ddc</title>
<updated>2020-03-19T04:03:04Z</updated>
<author>
<name>Wenjing Liu</name>
<email>Wenjing.Liu@amd.com</email>
</author>
<published>2020-02-28T17:16:07Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=201a94469fa914e674f73fef446fc9cad02fb00c'/>
<id>urn:sha1:201a94469fa914e674f73fef446fc9cad02fb00c</id>
<content type='text'>
[why]
DP doesn't have message id as the first byte of an hdcp message,
current hdcp psp unifies HDMI and DP message so that it is required
when reading DP HDCP messages in hdcp_ddc, a message id needs to be
added as the first byte of the HDCP message.
The id is currently assigned as a magic number which is not a good
coding practice.

[how]
Replace magic numbers with macro defined in hdcp headers.

Signed-off-by: Wenjing Liu &lt;Wenjing.Liu@amd.com&gt;
Reviewed-by: Ashley Thomas &lt;Ashley.Thomas2@amd.com&gt;
Acked-by: Rodrigo Siqueira &lt;Rodrigo.Siqueira@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
</content>
</entry>
<entry>
<title>drm/amd/display: Remove redundant hdcp display state</title>
<updated>2020-03-19T04:03:04Z</updated>
<author>
<name>Isabel Zhang</name>
<email>isabel.zhang@amd.com</email>
</author>
<published>2020-02-27T16:19:13Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=b45f9a3ed41bdfac339c879732164e18c995c9a0'/>
<id>urn:sha1:b45f9a3ed41bdfac339c879732164e18c995c9a0</id>
<content type='text'>
[Why]
Due to previous code changes displays which are in active state
immediately transition to the active and added state. This makes the two
states redundant and unnecessary.

[How]
Instead of updating the device state to active and added after
successful addition, change state to inactive if addition failed. Also,
change references to active and added state to just added state.

Signed-off-by: Isabel Zhang &lt;isabel.zhang@amd.com&gt;
Reviewed-by: Wenjing Liu &lt;Wenjing.Liu@amd.com&gt;
Acked-by: Rodrigo Siqueira &lt;Rodrigo.Siqueira@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
</content>
</entry>
<entry>
<title>drm/amd/display: fix a minor HDCP logging error</title>
<updated>2020-03-09T17:49:54Z</updated>
<author>
<name>Wenjing Liu</name>
<email>Wenjing.Liu@amd.com</email>
</author>
<published>2020-02-25T19:23:01Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=1450d237836032abeaf478772ddc15bd357161d1'/>
<id>urn:sha1:1450d237836032abeaf478772ddc15bd357161d1</id>
<content type='text'>
[why]
In HDCP Uninitialzed State, a CPIRQ event would cause log output
internal policy error because the CPIRQ event is not recognized as
unexpected event.

[how]
CPIRQ is issued in HDCP uninitialized state is unexpected.  We should
set unexpected event flag in event ctx.

Signed-off-by: Wenjing Liu &lt;Wenjing.Liu@amd.com&gt;
Reviewed-by: Ashley Thomas &lt;Ashley.Thomas2@amd.com&gt;
Acked-by: Rodrigo Siqueira &lt;Rodrigo.Siqueira@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
</content>
</entry>
<entry>
<title>drm/amd/display: determine rx id list bytes to read based on device count</title>
<updated>2020-03-09T17:49:40Z</updated>
<author>
<name>Wenjing Liu</name>
<email>Wenjing.Liu@amd.com</email>
</author>
<published>2020-02-25T21:37:32Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=d7ecf5e37d76bbac5bbcc9d5033119ea0dbfbc92'/>
<id>urn:sha1:d7ecf5e37d76bbac5bbcc9d5033119ea0dbfbc92</id>
<content type='text'>
[why]
Some RX doesn't like us to read rx id list upto max rx id list size.  As
discussed, we decided to read rx id list based on device count.

[how]
According to HDCP specs the actual size of rx id list is calculated as
rx id list size = 2+3+16+5*device_count.  We will read 16 bytes at a
time until it reached or exceeded rx id list size.

Signed-off-by: Wenjing Liu &lt;Wenjing.Liu@amd.com&gt;
Reviewed-by: Ashley Thomas &lt;Ashley.Thomas2@amd.com&gt;
Acked-by: Rodrigo Siqueira &lt;Rodrigo.Siqueira@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
</content>
</entry>
<entry>
<title>drm/amd/display: determine is mst hdcp based on stream instead of sink signal</title>
<updated>2020-03-09T17:49:06Z</updated>
<author>
<name>Wenjing Liu</name>
<email>Wenjing.Liu@amd.com</email>
</author>
<published>2020-02-24T22:22:36Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=b6a1a0e76084c541382050606830580740ef9e84'/>
<id>urn:sha1:b6a1a0e76084c541382050606830580740ef9e84</id>
<content type='text'>
[why]
It is possible even if sink signal is MST but driver enables SST stream.
We should not determine if we should do MST authentication based on
sink's capability.
Instead we should determine whether to do MST authentication based on
what we have enabled in stream.

Signed-off-by: Wenjing Liu &lt;Wenjing.Liu@amd.com&gt;
Reviewed-by: Ashley Thomas &lt;Ashley.Thomas2@amd.com&gt;
Acked-by: Rodrigo Siqueira &lt;Rodrigo.Siqueira@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
</content>
</entry>
<entry>
<title>drm/amd/display: Add stay count and bstatus to HDCP log</title>
<updated>2020-03-09T17:48:59Z</updated>
<author>
<name>Isabel Zhang</name>
<email>isabel.zhang@amd.com</email>
</author>
<published>2020-02-21T23:01:59Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=caa08c58cc10a778bc5c94b7d76905d87f18be9f'/>
<id>urn:sha1:caa08c58cc10a778bc5c94b7d76905d87f18be9f</id>
<content type='text'>
[Why]
So the values of stay count and bstatus can be easily viewed during
debugging.

[How]
Add stay count and bstatus values to be outputted in HDCP log

Signed-off-by: Isabel Zhang &lt;isabel.zhang@amd.com&gt;
Reviewed-by: Wenjing Liu &lt;Wenjing.Liu@amd.com&gt;
Acked-by: Rodrigo Siqueira &lt;Rodrigo.Siqueira@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
</content>
</entry>
<entry>
<title>drm/amd/display: Workaround to do HDCP authentication twice on certain displays</title>
<updated>2020-03-05T05:30:04Z</updated>
<author>
<name>George Shen</name>
<email>george.shen@amd.com</email>
</author>
<published>2020-02-19T00:15:55Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=7bc3807fe1d0694caf59dec983ac5809441cc9ca'/>
<id>urn:sha1:7bc3807fe1d0694caf59dec983ac5809441cc9ca</id>
<content type='text'>
[Why]
When transitioning from SST to MST, the HDCP repeater in some MST
displays will enter a bad state. The HDCP repeater is recovered after
failing and performing authentication again.

[How]
Add monitor patch to trigger HDCP authentication failure after
encryption is enabled and re-authenticate.

Signed-off-by: George Shen &lt;george.shen@amd.com&gt;
Reviewed-by: Wenjing Liu &lt;Wenjing.Liu@amd.com&gt;
Acked-by: Rodrigo Siqueira &lt;Rodrigo.Siqueira@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
</content>
</entry>
</feed>
