<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-dev/drivers/gpu/drm/amd/display, branch master</title>
<subtitle>Linux kernel development work - see feature branches</subtitle>
<id>https://git.zx2c4.com/linux-dev/atom/drivers/gpu/drm/amd/display?h=master</id>
<link rel='self' href='https://git.zx2c4.com/linux-dev/atom/drivers/gpu/drm/amd/display?h=master'/>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/'/>
<updated>2022-11-09T23:07:59Z</updated>
<entry>
<title>drm/amd/display: only fill dirty rectangles when PSR is enabled</title>
<updated>2022-11-09T23:07:59Z</updated>
<author>
<name>Hamza Mahfooz</name>
<email>hamza.mahfooz@amd.com</email>
</author>
<published>2022-11-09T17:06:27Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=675d84621a24490e1de3d59a4992a17fa9ff92b5'/>
<id>urn:sha1:675d84621a24490e1de3d59a4992a17fa9ff92b5</id>
<content type='text'>
Currently, we are calling fill_dc_dirty_rects() even if PSR isn't
supported by the relevant link in amdgpu_dm_commit_planes(), this is
undesirable especially because when drm.debug is enabled we are printing
messages in fill_dc_dirty_rects() that are only useful for debugging PSR
(and confusing otherwise). So, we can instead limit the filling of dirty
rectangles to only when PSR is enabled.

Reviewed-by: Leo Li &lt;sunpeng.li@amd.com&gt;
Signed-off-by: Hamza Mahfooz &lt;hamza.mahfooz@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
</content>
</entry>
<entry>
<title>drm/amd/display: Enforce minimum prefetch time for low memclk on DCN32</title>
<updated>2022-11-09T23:04:13Z</updated>
<author>
<name>Dillon Varone</name>
<email>Dillon.Varone@amd.com</email>
</author>
<published>2022-10-27T20:22:26Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=ce902d987a8caa5c9a96080e280ecc992414a127'/>
<id>urn:sha1:ce902d987a8caa5c9a96080e280ecc992414a127</id>
<content type='text'>
[WHY?]
Data return times when using lowest memclk can be &lt;= 60us, which can cause
underflow on high bandwidth displays with a workload.

[HOW?]
Enforce a minimum prefetch time during validation for low memclk modes.

Reviewed-by: Jun Lei &lt;Jun.Lei@amd.com&gt;
Acked-by: Alan Liu &lt;HaoPing.Liu@amd.com&gt;
Signed-off-by: Dillon Varone &lt;Dillon.Varone@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>
</entry>
<entry>
<title>drm/amd/display: Fix gpio port mapping issue</title>
<updated>2022-11-09T23:03:13Z</updated>
<author>
<name>Steve Su</name>
<email>steve.su@amd.com</email>
</author>
<published>2022-10-27T21:52:32Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=c0b2753f5db281b07013899c79b5f06a614055f9'/>
<id>urn:sha1:c0b2753f5db281b07013899c79b5f06a614055f9</id>
<content type='text'>
[Why]
1. Port of gpio has different mapping.

[How]
1. Add a dummy entry in mapping table.
2. Fix incorrect mask bit field access.

Reviewed-by: Alvin Lee &lt;Alvin.Lee2@amd.com&gt;
Acked-by: Alan Liu &lt;HaoPing.Liu@amd.com&gt;
Signed-off-by: Steve Su &lt;steve.su@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>
</entry>
<entry>
<title>drm/amd/display: Fix reg timeout in enc314_enable_fifo</title>
<updated>2022-11-09T23:01:59Z</updated>
<author>
<name>Nicholas Kazlauskas</name>
<email>nicholas.kazlauskas@amd.com</email>
</author>
<published>2022-10-27T19:34:33Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=ce62198d8b62734a985d22652e75a649be052390'/>
<id>urn:sha1:ce62198d8b62734a985d22652e75a649be052390</id>
<content type='text'>
[Why]
The link enablement sequence can end up resetting the encoder while
the PHY symclk isn't yet on.

This means that waiting for symclk on will timeout, along with the reset
bit never asserting high.

This causes unnecessary delay when enabling the link and produces a
warning affecting multiple IGT tests.

[How]
Don't wait for the symclk to be on here because firmware already does.

Don't wait for reset if we know the symclk isn't on.

Split the reset into a helper function that checks the bit and decides
whether or not a delay is sufficient.

Reviewed-by: Roman Li &lt;Roman.Li@amd.com&gt;
Acked-by: Alan Liu &lt;HaoPing.Liu@amd.com&gt;
Signed-off-by: Nicholas Kazlauskas &lt;nicholas.kazlauskas@amd.com&gt;
Tested-by: Daniel Wheeler &lt;daniel.wheeler@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Cc: stable@vger.kernel.org # 6.0.x
</content>
</entry>
<entry>
<title>drm/amd/display: Fix FCLK deviation and tool compile issues</title>
<updated>2022-11-09T23:01:47Z</updated>
<author>
<name>Chaitanya Dhere</name>
<email>chaitanya.dhere@amd.com</email>
</author>
<published>2022-10-27T13:51:19Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=0d5c5c210a4d4e655feb93b379647f0b179cdafe'/>
<id>urn:sha1:0d5c5c210a4d4e655feb93b379647f0b179cdafe</id>
<content type='text'>
[Why]
Recent backports from open source do not have header inclusion pattern
that is consistent with inclusion style in the rest of the file. This
breaks the internal tool builds as well. A recent commit erronously
modified the original DML formula for calculating
ActiveClockChangeLatencyHidingY. This resulted in a FCLK deviation
from the golden values.

[How]
Change the way in which display_mode_vba.h is included so that it is
consistent with the inclusion style in rest of the file which also fixes
the tool build. Restore the DML formula to its original state to fix the
FCLK deviation.

Reviewed-by: Aurabindo Pillai &lt;Aurabindo.Pillai@amd.com&gt;
Reviewed-by: Jun Lei &lt;Jun.Lei@amd.com&gt;
Acked-by: Alan Liu &lt;HaoPing.Liu@amd.com&gt;
Signed-off-by: Chaitanya Dhere &lt;chaitanya.dhere@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>
</entry>
<entry>
<title>drm/amd/display: Zeromem mypipe heap struct before using it</title>
<updated>2022-11-09T23:00:11Z</updated>
<author>
<name>Aurabindo Pillai</name>
<email>aurabindo.pillai@amd.com</email>
</author>
<published>2022-10-20T21:26:24Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=ab4b35008db9b7ae747679250e5c26d7c3a90cea'/>
<id>urn:sha1:ab4b35008db9b7ae747679250e5c26d7c3a90cea</id>
<content type='text'>
[Why&amp;How]
Bug was caused when moving variable from stack to heap because it was reusable
and garbage was left over, so we need to zero mem.

Reviewed-by: Martin Leung &lt;Martin.Leung@amd.com&gt;
Acked-by: Alan Liu &lt;HaoPing.Liu@amd.com&gt;
Signed-off-by: Aurabindo Pillai &lt;aurabindo.pillai@amd.com&gt;
Signed-off-by: Martin Leung &lt;Martin.Leung@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>
</entry>
<entry>
<title>drm/amd/display: Update SR watermarks for DCN314</title>
<updated>2022-11-09T22:59:10Z</updated>
<author>
<name>Nicholas Kazlauskas</name>
<email>nicholas.kazlauskas@amd.com</email>
</author>
<published>2022-10-25T15:26:04Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=632d06985235d988c9d7e6eec8fa655be0761fd0'/>
<id>urn:sha1:632d06985235d988c9d7e6eec8fa655be0761fd0</id>
<content type='text'>
[Why &amp; How]
New values requested by hardware after fine-tuning.
Update for all memory types.

Reviewed-by: Jun Lei &lt;Jun.Lei@amd.com&gt;
Acked-by: Alan Liu &lt;HaoPing.Liu@amd.com&gt;
Signed-off-by: Nicholas Kazlauskas &lt;nicholas.kazlauskas@amd.com&gt;
Tested-by: Daniel Wheeler &lt;daniel.wheeler@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Cc: stable@vger.kernel.org # 6.0.x
</content>
</entry>
<entry>
<title>drm/amd/display: Investigate tool reported FCLK P-state deviations</title>
<updated>2022-11-02T21:16:25Z</updated>
<author>
<name>Nevenko Stupar</name>
<email>Nevenko.Stupar@amd.com</email>
</author>
<published>2022-05-06T20:32:38Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=7461016c5706eb8c477752bf69e5c9f5a38f502b'/>
<id>urn:sha1:7461016c5706eb8c477752bf69e5c9f5a38f502b</id>
<content type='text'>
[Why]
Fix for some of the tool reported modes for FCLK
P-state deviations and UCLK P-state deviations that
are coming from DSC terms and/or Scaling terms
causing MinActiveFCLKChangeLatencySupported
and MaxActiveDRAMClockChangeLatencySupported
incorrectly calculated in DML for these configurations.

Reviewed-by: Chaitanya Dhere &lt;Chaitanya.Dhere@amd.com&gt;
Acked-by: Jasdeep Dhillon &lt;jdhillon@amd.com&gt;
Acked-by: Alex Hung &lt;alex.hung@amd.com&gt;
Signed-off-by: Nevenko Stupar &lt;Nevenko.Stupar@amd.com&gt;
Tested-by: Mark Broadworth &lt;mark.broadworth@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
</content>
</entry>
<entry>
<title>drm/amd/display: Add DSC delay factor workaround</title>
<updated>2022-11-02T21:16:25Z</updated>
<author>
<name>George Shen</name>
<email>george.shen@amd.com</email>
</author>
<published>2022-10-14T21:46:03Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=d5e0fb0d9dea545defb963ec1073bd9a1a8b5395'/>
<id>urn:sha1:d5e0fb0d9dea545defb963ec1073bd9a1a8b5395</id>
<content type='text'>
[Why]
Certain 4K high refresh rate modes requiring DSC are exhibiting top
of screen underflow corruption. Increasing the DSC delay by a factor
of 6 percent stops the underflow for most use cases.

[How]
Multiply DSC delay requirement in DML by a factor.
Add debug option to make this DSC delay factor configurable.

Reviewed-by: Alvin Lee &lt;Alvin.Lee2@amd.com&gt;
Acked-by: Alex Hung &lt;alex.hung@amd.com&gt;
Signed-off-by: George Shen &lt;george.shen@amd.com&gt;
Tested-by: Mark Broadworth &lt;mark.broadworth@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
</content>
</entry>
<entry>
<title>drm/amd/display: Round up DST_after_scaler to nearest int</title>
<updated>2022-11-02T21:16:25Z</updated>
<author>
<name>George Shen</name>
<email>george.shen@amd.com</email>
</author>
<published>2022-10-14T21:40:08Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=8dc323133d74518e3b5b07242e2b2f088799ea6e'/>
<id>urn:sha1:8dc323133d74518e3b5b07242e2b2f088799ea6e</id>
<content type='text'>
[Why]
The DST_after_scaler value that DML spreadsheet outputs is
generally the driver value round up to the nearest int.

Reviewed-by: Alvin Lee &lt;Alvin.Lee2@amd.com&gt;
Acked-by: Alex Hung &lt;alex.hung@amd.com&gt;
Signed-off-by: George Shen &lt;george.shen@amd.com&gt;
Tested-by: Mark Broadworth &lt;mark.broadworth@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
</content>
</entry>
</feed>
