linux.git/drivers/gpu/drm/amd/display/dc/core, branch v6.12 Linux kernel source tree drm/amd/display: Handle dml allocation failure to avoid crash 2024-11-11T19:05:22+00:00 Ryan Seto ryanseto@amd.com 2024-11-01T14:19:56+00:00 6825cb07b79ffeb1d90ffaa7a1227462cdca34ae [Why] In the case where a dml allocation fails for any reason, the current state's dml contexts would no longer be valid. Then subsequent calls dc_state_copy_internal would shallow copy invalid memory and if the new state was released, a double free would occur. [How] Reset dml pointers in new_state to NULL and avoid invalid pointer Reviewed-by: Dillon Varone <dillon.varone@amd.com> Signed-off-by: Ryan Seto <ryanseto@amd.com> Signed-off-by: Hamza Mahfooz <hamza.mahfooz@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit bcafdc61529a48f6f06355d78eb41b3aeda5296c) Cc: stable@vger.kernel.org 
[Why]
In the case where a dml allocation fails for any reason, the
current state's dml contexts would no longer be valid. Then
subsequent calls dc_state_copy_internal would shallow copy
invalid memory and if the new state was released, a double
free would occur.

[How]
Reset dml pointers in new_state to NULL and avoid invalid
pointer

Reviewed-by: Dillon Varone <dillon.varone@amd.com>
Signed-off-by: Ryan Seto <ryanseto@amd.com>
Signed-off-by: Hamza Mahfooz <hamza.mahfooz@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit bcafdc61529a48f6f06355d78eb41b3aeda5296c)
Cc: stable@vger.kernel.org
drm/amd/display: Clear update flags after update has been applied 2024-10-07T18:58:58+00:00 Josip Pavic Josip.Pavic@amd.com 2024-09-24T21:25:54+00:00 0a9906cc45d21e21ca8bb2b98b79fd7c05420fda [Why] Since the surface/stream update flags aren't cleared after applying updates, those same updates may be applied again in a future call to update surfaces/streams for surfaces/streams that aren't actually part of that update (i.e. applying an update for one surface/stream can trigger unintended programming on a different surface/stream). For example, when an update results in a call to program_front_end_for_ctx, that function may call program_pipe on all pipes. If there are surface update flags that were never cleared on the surface some pipe is attached to, then the same update will be programmed again. [How] Clear the surface and stream update flags after applying the updates. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3441 Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3616 Cc: Melissa Wen <mwen@igalia.com> Reviewed-by: Aric Cyr <aric.cyr@amd.com> Signed-off-by: Josip Pavic <Josip.Pavic@amd.com> Signed-off-by: Rodrigo Siqueira <rodrigo.siqueira@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 7671f62c10f2a4c77d89b39fd50fab7f918d6809) Cc: stable@vger.kernel.org 
[Why]
Since the surface/stream update flags aren't cleared after applying
updates, those same updates may be applied again in a future call to
update surfaces/streams for surfaces/streams that aren't actually part
of that update (i.e. applying an update for one surface/stream can
trigger unintended programming on a different surface/stream).

For example, when an update results in a call to
program_front_end_for_ctx, that function may call program_pipe on all
pipes. If there are surface update flags that were never cleared on the
surface some pipe is attached to, then the same update will be
programmed again.

[How]
Clear the surface and stream update flags after applying the updates.

Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3441
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3616
Cc: Melissa Wen <mwen@igalia.com>
Reviewed-by: Aric Cyr <aric.cyr@amd.com>
Signed-off-by: Josip Pavic <Josip.Pavic@amd.com>
Signed-off-by: Rodrigo Siqueira <rodrigo.siqueira@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 7671f62c10f2a4c77d89b39fd50fab7f918d6809)
Cc: stable@vger.kernel.org
drm/amd/display: Fix kdoc entry for 'tps' in 'dc_process_dmub_dpia_set_tps_notification' 2024-09-18T20:15:13+00:00 Srinivasan Shanmugam srinivasan.shanmugam@amd.com 2024-09-17T13:09:07+00:00 d5a29e6a61028887bb8480e7c4af3547d6f3862d Correct the parameter descriptor for the function `dc_process_dmub_dpia_set_tps_notification` to match the actual parameters used. Fixes the below with gcc W=1: drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:5768: warning: Function parameter or struct member 'tps' not described in 'dc_process_dmub_dpia_set_tps_notification' drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:5768: warning: Excess function parameter 'ts' description in 'dc_process_dmub_dpia_set_tps_notification' Cc: Tom Chung <chiahsuan.chung@amd.com> Cc: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Cc: Roman Li <roman.li@amd.com> Cc: Alex Hung <alex.hung@amd.com> Cc: Aurabindo Pillai <aurabindo.pillai@amd.com> Cc: Harry Wentland <harry.wentland@amd.com> Cc: Hamza Mahfooz <hamza.mahfooz@amd.com> Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com> Reviewed-by: Tom Chung <chiahsuan.chung@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> 
Correct the parameter descriptor for the function
`dc_process_dmub_dpia_set_tps_notification` to match the actual
parameters used.

Fixes the below with gcc W=1:
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:5768: warning: Function parameter or struct member 'tps' not described in 'dc_process_dmub_dpia_set_tps_notification'
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:5768: warning: Excess function parameter 'ts' description in 'dc_process_dmub_dpia_set_tps_notification'

Cc: Tom Chung <chiahsuan.chung@amd.com>
Cc: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Cc: Roman Li <roman.li@amd.com>
Cc: Alex Hung <alex.hung@amd.com>
Cc: Aurabindo Pillai <aurabindo.pillai@amd.com>
Cc: Harry Wentland <harry.wentland@amd.com>
Cc: Hamza Mahfooz <hamza.mahfooz@amd.com>
Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com>
Reviewed-by: Tom Chung <chiahsuan.chung@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
drm/amd/display: Use full update for swizzle mode change 2024-09-18T20:15:08+00:00 Charlene Liu Charlene.Liu@amd.com 2024-09-04T19:58:25+00:00 b74571a83fd3e50f804f090aae60c864d458187c [WHY & HOW] 1) We did linear/non linear transition properly long ago 2) We used that path to handle SystemDisplayEnable 3) We fixed a SystemDisplayEnable inability to fallback to passive by impacting the transition flow generically 4) AFMF later relied on the generic transition behavior Separating the two flows to make (3) non-generic is the best immediate coarse of action. DC can discern SSAMPO3 very easily from SDE. Cc: Mario Limonciello <mario.limonciello@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Reviewed-by: Chris Park <chris.park@amd.com> Signed-off-by: Charlene Liu <Charlene.Liu@amd.com> Signed-off-by: Alex Hung <alex.hung@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> 
[WHY & HOW]
1) We did linear/non linear transition properly long ago
2) We used that path to handle SystemDisplayEnable
3) We fixed a SystemDisplayEnable inability to fallback to passive by
   impacting the transition flow generically
4) AFMF later relied on the generic transition behavior

Separating the two flows to make (3) non-generic is the best immediate
coarse of action.

DC can discern SSAMPO3 very easily from SDE.

Cc: Mario Limonciello <mario.limonciello@amd.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Reviewed-by: Chris Park <chris.park@amd.com>
Signed-off-by: Charlene Liu <Charlene.Liu@amd.com>
Signed-off-by: Alex Hung <alex.hung@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
drm/amd/display: Check null pointer before dereferencing se 2024-09-18T20:15:08+00:00 Alex Hung alex.hung@amd.com 2024-08-29T23:30:26+00:00 ff599ef6970ee000fa5bc38d02fa5ff5f3fc7575 [WHAT & HOW] se is null checked previously in the same function, indicating it might be null; therefore, it must be checked when used again. This fixes 1 FORWARD_NULL issue reported by Coverity. Acked-by: Alex Hung <alex.hung@amd.com> Reviewed-by: Rodrigo Siqueira <rodrigo.siqueira@amd.com> Signed-off-by: Alex Hung <alex.hung@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> 
[WHAT & HOW]
se is null checked previously in the same function, indicating
it might be null; therefore, it must be checked when used again.

This fixes 1 FORWARD_NULL issue reported by Coverity.

Acked-by: Alex Hung <alex.hung@amd.com>
Reviewed-by: Rodrigo Siqueira <rodrigo.siqueira@amd.com>
Signed-off-by: Alex Hung <alex.hung@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
drm/amd/display: Restructure dpia link training 2024-09-18T20:15:07+00:00 Peichen Huang PeiChen.Huang@amd.com 2024-08-22T06:50:07+00:00 cf4cebcec619d963fa7496018f03cb0ff00dc257 [WHY] We intend to consolidate dp tunneling and conventional dp link training. [HOW] 1. Use the same link training entry for both dp and dpia 2. Move SET_CONFIG of non-transparent mode to dmub side 3. Add set_tps_notification dmub_cmd to notify tps request for non-transparent dpia link training 4. Check dpcd request result and abort link training early if dpia aux tunneling fails 5. Add option to avoid affect old product 6. Separately handle wait_time_microsec for dpia Reviewed-by: Cruise Hung <cruise.hung@amd.com> Reviewed-by: George Shen <george.shen@amd.com> Reviewed-by: Meenakshikumar Somasundaram <meenakshikumar.somasundaram@amd.com> Signed-off-by: Peichen Huang <PeiChen.Huang@amd.com> Signed-off-by: Alex Hung <alex.hung@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> 
[WHY]
We intend to consolidate dp tunneling and conventional dp link training.

[HOW]
1. Use the same link training entry for both dp and dpia
2. Move SET_CONFIG of non-transparent mode to dmub side
3. Add set_tps_notification dmub_cmd to notify tps request for
   non-transparent dpia link training
4. Check dpcd request result and abort link training early if dpia
   aux tunneling fails
5. Add option to avoid affect old product
6. Separately handle wait_time_microsec for dpia

Reviewed-by: Cruise Hung <cruise.hung@amd.com>
Reviewed-by: George Shen <george.shen@amd.com>
Reviewed-by: Meenakshikumar Somasundaram <meenakshikumar.somasundaram@amd.com>
Signed-off-by: Peichen Huang <PeiChen.Huang@amd.com>
Signed-off-by: Alex Hung <alex.hung@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
drm/amd/display: Use SDR white level to calculate matrix coefficients 2024-09-18T20:15:06+00:00 Samson Tam Samson.Tam@amd.com 2024-08-23T20:57:33+00:00 c2ed7002c0614c5eab6c8f62a7a76be5df5805cf [WHY] Certain profiles have higher HDR multiplier than SDR white level max which is not currently supported. [HOW] Use SDR white level when calculating matrix coefficients for HDR RGB MPO path instead of HDR multiplier. Cc: Mario Limonciello <mario.limonciello@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Reviewed-by: Jun Lei <jun.lei@amd.com> Signed-off-by: Samson Tam <Samson.Tam@amd.com> Signed-off-by: Alex Hung <alex.hung@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> 
[WHY]
Certain profiles have higher HDR multiplier than SDR white level max
which is not currently supported.

[HOW]
Use SDR white level when calculating matrix coefficients for HDR RGB MPO
path instead of HDR multiplier.

Cc: Mario Limonciello <mario.limonciello@amd.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Reviewed-by: Jun Lei <jun.lei@amd.com>
Signed-off-by: Samson Tam <Samson.Tam@amd.com>
Signed-off-by: Alex Hung <alex.hung@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
drm/amd/display: Add sharpness control interface 2024-09-02T15:38:23+00:00 Relja Vojvodic Relja.Vojvodic@amd.com 2024-08-21T13:34:21+00:00 efaf15752d113e81a5e9f25f57dc203f7c3007ab - Add interface for controlling shapness level input into DCN. - Update SPL to support custom sharpness values. - Add support for different sharpness values depending on YUV/RGB content. Reviewed-by: Samson Tam <samson.tam@amd.com> Signed-off-by: Relja Vojvodic <Relja.Vojvodic@amd.com> Signed-off-by: Hamza Mahfooz <hamza.mahfooz@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> 
- Add interface for controlling shapness level input into DCN.
- Update SPL to support custom sharpness values.
- Add support for different sharpness values depending on YUV/RGB
  content.

Reviewed-by: Samson Tam <samson.tam@amd.com>
Signed-off-by: Relja Vojvodic <Relja.Vojvodic@amd.com>
Signed-off-by: Hamza Mahfooz <hamza.mahfooz@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Revert "drm/amd/display: Wait for all pending cleared before full update" 2024-09-02T15:37:29+00:00 Dillon Varone Dillon.Varone@amd.com 2024-08-20T19:13:14+00:00 6e8410944767381524544390ce030c86f07399da This reverts commit f0b7dcf25834afd17df316367dfe5d4c890c713c. It is causing graphics hangs. Reviewed-by: Martin Leung <martin.leung@amd.com> Signed-off-by: Dillon Varone <Dillon.Varone@amd.com> Signed-off-by: Hamza Mahfooz <hamza.mahfooz@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> 
This reverts commit f0b7dcf25834afd17df316367dfe5d4c890c713c.

It is causing graphics hangs.

Reviewed-by: Martin Leung <martin.leung@amd.com>
Signed-off-by: Dillon Varone <Dillon.Varone@amd.com>
Signed-off-by: Hamza Mahfooz <hamza.mahfooz@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
drm/amd/display: add back quality EASF and ISHARP and dc dependency changes 2024-08-27T21:53:58+00:00 Samson Tam Samson.Tam@amd.com 2024-08-16T15:42:35+00:00 6efc0ab3b05de0d7bab8ec0597214e4788251071 [Why] Addressed previous issues with quality changes and new issues due to rolling back quality changes. [How] This reverts commit f9e6759888866748f31b6b6c2142a481d587f51f, fixes merge conflicts, and fixed some formatting errors. Store current sharpness level for each pregen table to minimize calculating sharpness table every time. Disable dynamic ODM when sharpness is enabled. Reviewed-by: Jun Lei <jun.lei@amd.com> Signed-off-by: Samson Tam <Samson.Tam@amd.com> Signed-off-by: Zaeem Mohamed <zaeem.mohamed@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> 
[Why]
Addressed previous issues with quality changes and new issues due to
 rolling back quality changes.

[How]
This reverts commit f9e6759888866748f31b6b6c2142a481d587f51f, fixes merge conflicts, and fixed some
 formatting errors.
Store current sharpness level for each pregen table to minimize
 calculating sharpness table every time.
Disable dynamic ODM when sharpness is enabled.

Reviewed-by: Jun Lei <jun.lei@amd.com>
Signed-off-by: Samson Tam <Samson.Tam@amd.com>
Signed-off-by: Zaeem Mohamed <zaeem.mohamed@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>