linux-stable.git/drivers/gpu/drm/amd/display, branch v6.2.7

drm/amd/display: adjust MALL size available for DCN32 and DCN321

2023-03-17T07:58:03+00:00

commit 235fef6c7fd341026eee90cc546e6e8ff8b2c315 upstream.

[Why]
MALL size available can vary for different SKUs.
Use num_chans read from VBIOS to determine the available MALL size we can use

[How]
Define max_chans for DCN32 and DCN321.
If num_chans is max_chans, then return max_chans as we can access the
 entire MALL space.
Otherwise, define avail_chans as the number of available channels we are
 allowed instead.
Return corresponding number of channels back and use this to calculate
 available MALL size.

Reviewed-by: Nevenko Stupar 
Acked-by: Alan Liu 
Signed-off-by: Samson Tam 
Tested-by: Daniel Wheeler 
Signed-off-by: Alex Deucher 
Signed-off-by: Greg Kroah-Hartman

drm/amd/display: Allow subvp on vactive pipes that are 2560x1440@60

2023-03-17T07:58:03+00:00

commit 2ebd1036209c2e7b61e6bc6e5bee4b67c1684ac6 upstream.

Enable subvp on specifically 1440p@60hz displays even though it can
switch in vactive.

Tested-by: Daniel Wheeler 
Reviewed-by: Jun Lei 
Acked-by: Rodrigo Siqueira 
Signed-off-by: Alvin Lee 
Signed-off-by: Alex Deucher 
Signed-off-by: Greg Kroah-Hartman

drm/display/dp_mst: Handle old/new payload states in drm_dp_remove_payload()

2023-03-11T12:50:49+00:00

commit e761cc20946a0094df71cb31a565a6a0d03bd8be upstream.

Atm, drm_dp_remove_payload() uses the same payload state to both get the
vc_start_slot required for the payload removal DPCD message and to
deduct time_slots from vc_start_slot of all payloads after the one being
removed.

The above isn't always correct, as vc_start_slot must be the up-to-date
version contained in the new payload state, but time_slots must be the
one used when the payload was previously added, contained in the old
payload state. The new payload's time_slots can change vs. the old one
if the current atomic commit changes the corresponding mode.

This patch let's drivers pass the old and new payload states to
drm_dp_remove_payload(), but keeps these the same for now in all drivers
not to change the behavior. A follow-up i915 patch will pass in that
driver the correct old and new states to the function.

Cc: Lyude Paul 
Cc: Ville Syrjälä 
Cc: Ben Skeggs 
Cc: Karol Herbst 
Cc: Harry Wentland 
Cc: Alex Deucher 
Cc: Wayne Lin 
Cc: stable@vger.kernel.org # 6.1
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Ville Syrjälä 
Reviewed-by: Lyude Paul 
Acked-by: Lyude Paul 
Acked-by: Daniel Vetter 
Acked-by: Wayne Lin 
Acked-by: Jani Nikula 
Signed-off-by: Imre Deak 
Link: https://patchwork.freedesktop.org/patch/msgid/20230206114856.2665066-2-imre.deak@intel.com
Signed-off-by: Greg Kroah-Hartman

drm/amd/display: disable SubVP + DRR to prevent underflow

2023-03-10T08:29:20+00:00

[ Upstream commit 80c6d6804f31451848a3956a70c2bcb1f07cfcb0 ]

[Why&How]
Temporarily disable SubVP+DRR since Xorg has an architectural limitation
where freesync will not work in a multi monitor configuration. SubVP+DRR
requires that freesync be working.

Whether OS has variable refresh setting enabled or not, the state on
the crtc remains same unless an application requests VRR. Due to this,
there is no way to know whether freesync will actually work or not
while we are on the desktop from the kernel's perspective.

If userspace does not have a limitation with multi-display freesync (for
example wayland), then this feature can be enabled by adding a
dcfeaturemask option to amdgpu on the kernel cmdline like:

amdgpu.dcfeaturemask=0x200

Signed-off-by: Aurabindo Pillai 
Reviewed-by: Rodrigo Siqueira 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin

drm/amd/display: Disable HUBP/DPP PG on DCN314 for now

2023-03-10T08:29:20+00:00

[ Upstream commit b7c67f72408b11b922f23f06c7df0f6743a2e89d ]

[Why]
The DMCUB implementation required to workaround corruption is
not currently stable and may cause intermittent corruption or hangs.

[How]
Disable PG until the sequence is stable.

Reviewed-by: Hansen Dsouza 
Acked-by: Qingqing Zhuo 
Signed-off-by: Nicholas Kazlauskas 
Tested-by: Daniel Wheeler 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin

drm/amd/display: Enable P-state validation checks for DCN314

2023-03-10T08:29:20+00:00

[ Upstream commit 37d184b548db0f64d4a878960b2c6988b38a3e7e ]

[Why]
To align with DCN31 behavior. This helps avoid p-state hangs in
the case where underflow does occur.

[How]
Flip the bit to true.

Reviewed-by: Hansen Dsouza 
Acked-by: Qingqing Zhuo 
Signed-off-by: Nicholas Kazlauskas 
Tested-by: Daniel Wheeler 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin

drm/amd/display: Do not commit pipe when updating DRR

2023-03-10T08:29:20+00:00

[ Upstream commit 8f0d304d21b351d65e8c434c5399a40231876ba1 ]

[WHY]
DRR and Pipe cannot be updated on
the same frame, or else underflow will
occur.

Reviewed-by: Jun Lei 
Acked-by: Qingqing Zhuo 
Signed-off-by: Wesley Chalmers 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin

drm/amd/display: fix FCLK pstate change underflow

2023-03-10T08:29:19+00:00

[ Upstream commit 972243f973eb0821084e5833d5f7f4ed025f42da ]

[Why]
Currently we set FCLK p-state change
watermark calculated based on dummy
p-state latency when UCLK p-state is
not supported

[How]
Calculate FCLK p-state change watermark
based on on FCLK pstate change latency
in case UCLK p-state is not supported

Reviewed-by: Nevenko Stupar 
Acked-by: Alex Hung 
Signed-off-by: Vladimir Stempen 
Tested-by: Daniel Wheeler 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin

drm/amd/display: Set hvm_enabled flag for S/G mode

2023-03-10T08:29:17+00:00

[ Upstream commit 40e9f3f067bc6fb47b878f8ba0a9cc7b93abbf49 ]

[Why]
After enabling S/G on dcn314 a screen corruption may be observed.
HostVM flag should be set in S/G mode to be included in DML calculations.

[How]
In S/G mode gpu_vm_support flag is set.
Use its value to init is_hvm_enabled.

Reviewed-by: Nicholas Kazlauskas 
Acked-by: Alan Liu 
Signed-off-by: Roman Li 
Tested-by: Daniel Wheeler 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin

drm/amd/display: fix mapping to non-allocated address

2023-03-10T08:29:16+00:00

[ Upstream commit 9190d4a263264eabf715f5fc1827da45e3fdc247 ]

[Why]
There is an issue mapping non-allocated location of memory.
It would allocate gpio registers from an array out of bounds.

[How]
Patch correct numbers of bounds for using.

Tested-by: Daniel Wheeler 
Reviewed-by: Martin Leung 
Acked-by: Rodrigo Siqueira 
Signed-off-by: Brandon Syu 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin