pm24.git/drivers/gpu/drm/amd, branch v6.11

drm/amd/display: Add all planes on CRTC to state for overlay cursor

2024-09-11T14:40:52Z

[Why] DC has a special commit path for native cursor, which use the built-in cursor pipe within DCN planes. This update path does not require all enabled planes to be added to the list of surface updates sent to DC. This is not the case for overlay cursor; it uses the same path as MPO commits. This update path requires all enabled planes to be added to the list of surface updates sent to DC. Otherwise, DC will disable planes not inside the list. [How] If overlay cursor is needed, add all planes on the same CRTC as this cursor to the atomic state. This is already done for non-cursor planes (MPO), just before the added lines. Fixes: 1b04dcca4fb1 ("drm/amd/display: Introduce overlay cursor mode") Closes: https://lore.kernel.org/lkml/f68020a3-c413-482d-beb2-5432d98a1d3e@amd.com Reviewed-by: Harry Wentland Signed-off-by: Leo Li Tested-by: Mikhail Gavrilov Signed-off-by: Alex Deucher (cherry picked from commit 0c8c5bdd7eaf291b6f727e98506fb68acee3a4cc)

drm/amdgpu/atomfirmware: Silence UBSAN warning

2024-09-10T21:27:17Z

Per the comments, these are variable sized arrays. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3613 Reviewed-by: Harry Wentland Signed-off-by: Alex Deucher (cherry picked from commit 81f7804ba84ee617ed594de934ed87bcc4f83531) Cc: stable@vger.kernel.org

drm/amd/amdgpu: apply command submission parser for JPEG v1

2024-09-10T21:26:55Z

Similar to jpeg_v2_dec_ring_parse_cs() but it has different register ranges and a few other registers access. Acked-by: Alex Deucher Signed-off-by: David (Ming Qiang) Wu Signed-off-by: Alex Deucher (cherry picked from commit 3d5adbdf1d01708777f2eda375227cbf7a98b9fe) Cc: stable@vger.kernel.org

drm/amd/amdgpu: apply command submission parser for JPEG v2+

2024-09-10T21:26:49Z

This patch extends the same cs parser from JPEG v4.0.3 to other JPEG versions (v2 and above). Rename to more common name as jpeg_v2_dec_ring_parse_cs() from jpeg_v4_0_3_dec_ring_parse_cs(). Acked-by: Alex Deucher Signed-off-by: David (Ming Qiang) Wu Signed-off-by: Alex Deucher (cherry picked from commit 88dcad2d07c8d82e6a097c8e74239eb67333bcf7) Cc: stable@vger.kernel.org

drm/amd/pm: fix the pp_dpm_pcie issue on smu v14.0.2/3

2024-09-10T21:23:18Z

fix the pp_dpm_pcie issue on smu v14.0.2/3 as below: 0: 2.5GT/s, x4 250Mhz 1: 8.0GT/s, x4 616Mhz * 2: 8.0GT/s, x4 1143Mhz * the middle level can be removed since it is always skipped on smu v14.0.2/3 Signed-off-by: Kenneth Feng Acked-by: Alex Deucher Signed-off-by: Alex Deucher (cherry picked from commit fedf6db3ea9dc5eda0b78cfbbb8f7a88b97e5b24)

drm/amd/pm: update the features set on smu v14.0.2/3

2024-09-10T21:23:07Z

update the features set on smu v14.0.2/3 Signed-off-by: Kenneth Feng Reviewed-by: Yang Wang Signed-off-by: Alex Deucher (cherry picked from commit 25d48f2eb0af1f0e6f09f54a1a1716f48c0722c9)

drm/amd/display: Do not reset planes based on crtc zpos_changed

2024-09-10T21:08:09Z

[Why] drm_normalize_zpos will set the crtc_state->zpos_changed to 1 if any of it's assigned planes changes zpos, or is removed/added from it. To have amdgpu_dm request a plane reset on this is too broad. For example, if only the cursor plane was moved from one crtc to another, the crtc's zpos_changed will be set to true. But that does not mean that the underlying primary plane requires a reset. [How] Narrow it down so that only the plane that has a change in zpos will require a reset. As a future TODO, we can further optimize this by only requiring a reset on z-order change. Z-order is different from z-pos, since a zpos change doesn't necessarily mean the z-ordering changed, and DC should only require a reset if the z-ordering changed. For example, the following zpos update does not change z-ordering: Plane A: zpos 2 -> 3 Plane B: zpos 1 -> 2 => Plane A is still on top of plane B: no reset needed Whereas this one does change z-ordering: Plane A: zpos 2 -> 1 Plane B: zpos 1 -> 2 => Plane A changed from on top, to below plane B: reset needed Fixes: 38e0c3df6dbd ("drm/amd/display: Move PRIMARY plane zpos higher") Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3569 Signed-off-by: Leo Li Reviewed-by: Harry Wentland Signed-off-by: Alex Deucher (cherry picked from commit 578aab4ecc73476393389440724b7a391cc0cea9)

drm/amd/display: Avoid race between dcn35_set_drr() and dc_state_destruct()

2024-09-10T20:31:44Z

dc_state_destruct() nulls the resource context of the DC state. The pipe context passed to dcn35_set_drr() is a member of this resource context. If dc_state_destruct() is called parallel to the IRQ processing (which calls dcn35_set_drr() at some point), we can end up using already nulled function callback fields of struct stream_resource. The logic in dcn35_set_drr() already tries to avoid this, by checking tg against NULL. But if the nulling happens exactly after the NULL check and before the next access, then we get a race. Avoid this by copying tg first to a local variable, and then use this variable for all the operations. This should work, as long as nobody frees the resource pool where the timing generators live. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3142 Fixes: 06ad7e164256 ("drm/amd/display: Destroy DC context while keeping DML and DML2") Signed-off-by: Tobias Jakobi Reviewed-by: Harry Wentland Signed-off-by: Mario Limonciello Signed-off-by: Alex Deucher (cherry picked from commit 0607a50c004798a96e62c089a4c34c220179dcb5) Cc: stable@vger.kernel.org

drm/amd/display: Avoid race between dcn10_set_drr() and dc_state_destruct()

2024-09-10T20:15:59Z

dc_state_destruct() nulls the resource context of the DC state. The pipe context passed to dcn10_set_drr() is a member of this resource context. If dc_state_destruct() is called parallel to the IRQ processing (which calls dcn10_set_drr() at some point), we can end up using already nulled function callback fields of struct stream_resource. The logic in dcn10_set_drr() already tries to avoid this, by checking tg against NULL. But if the nulling happens exactly after the NULL check and before the next access, then we get a race. Avoid this by copying tg first to a local variable, and then use this variable for all the operations. This should work, as long as nobody frees the resource pool where the timing generators live. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3142 Fixes: 06ad7e164256 ("drm/amd/display: Destroy DC context while keeping DML and DML2") Signed-off-by: Tobias Jakobi Tested-by: Raoul van Rüschen Tested-by: Christopher Snowhill Reviewed-by: Harry Wentland Tested-by: Sefa Eyeoglu Signed-off-by: Mario Limonciello Signed-off-by: Alex Deucher (cherry picked from commit a3cc326a43bdc48fbdf53443e1027a03e309b643) Cc: stable@vger.kernel.org

drm/amdkfd: Add cache line size info

2024-09-10T20:15:16Z

Populate cache line size info in topology based on information from IP discovery table. Signed-off-by: David Belanger Reviewed-by: Sreekant Somasekharan Signed-off-by: Alex Deucher (cherry picked from commit 4e9fadacddca96a2e6fcee9cc9488b78eb7a6953)