- 23 Jul, 2021 36 commits
-
-
Anson Jacob authored
Add new line to phy_settings output Signed-off-by:
Anson Jacob <Anson.Jacob@amd.com> Reviewed-by:
Harry Wentland <harry.wentland@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com>
-
Anson Jacob authored
link_rate is updated via debugfs using hex values, set it to output in hex as well. eg: Resolution: 1920x1080@144Hz cat /sys/kernel/debug/dri/0/DP-1/link_settings Current: 4 0x14 0 Verified: 4 0x1e 0 Reported: 4 0x1e 16 Preferred: 0 0x0 0 echo "4 0x1e" > /sys/kernel/debug/dri/0/DP-1/link_settings cat /sys/kernel/debug/dri/0/DP-1/link_settings Current: 4 0x1e 0 Verified: 4 0x1e 0 Reported: 4 0x1e 16 Preferred: 4 0x1e 0 Signed-off-by:
-
Oak Zeng authored
start_cpsch and stop_cpsch can be called during kfd device initialization or during gpu reset/recovery. So they can run concurrently. Currently in start_cpsch and stop_cpsch, pm_init and pm_uninit is not protected by the dpm lock. Imagine such a case that user use packet manager's function to submit a pm4 packet to hang hws (ie through command cat /sys/class/kfd/kfd/topology/nodes/1/gpu_id | sudo tee /sys/kernel/debug/kfd/hang_hws), while kfd device is under device reset/recovery so packet manager can be not initialized. There will be unpredictable protection fault in such case. This patch moves pm_init/uninit inside the dpm lock and check packet manager is initialized before using packet manager function. Signed-off-by:
Oak Zeng <Oak.Zeng@amd.com> Acked-by:
Christian Konig <christian.koenig@amd.com> Reviewed-by:
Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by:
-
Oak Zeng authored
This variable will be used to determine whether packet manager is initialized or not, in a future patch. Signed-off-by:
-
Oak Zeng authored
Renaming packets to packet_mgr to reflect the real meaning of this variable. Signed-off-by:
-
Oak Zeng authored
Function name "psp_np_fw_load" is not proper as people don't know _np_fw_ means "non psp firmware". Change the function name to psp_load_non_psp_fw for better understanding. Same thing for function psp_execute_np_fw_load. Signed-off-by:
-
Oak Zeng authored
The printing message "PSP loading VCN firmware" is mis-leading because people might think driver is loading VCN firmware. Actually when this message is printed, driver is just preparing some VCN ucode, not loading VCN firmware yet. The actual VCN firmware loading will be in the PSP block hw_init. Fix the printing message Signed-off-by:
-
Roy Sun authored
Squash in warning fix (Alex) Signed-off-by:
Roy Sun <Roy.Sun@amd.com> Reviewed-by:
Zhou pengju <pengju.zhou@amd.com> Signed-off-by:
-
Roy Sun authored
The callback functions are used for SRIOV read/write instead of just for rlcg read/write Signed-off-by:
-
Veerabadhran Gopalakrishnan authored
Signed-off-by:
Veerabadhran Gopalakrishnan <veerabadhran.gopalakrishnan@amd.com> Reviewed-by:
James Zhu <James.Zhu@amd.com> Signed-off-by:
-
Jonathan Kim authored
Similar to xGMI reporting the min/max bandwidth between direct peers, PCIe will report the min/max bandwidth to the KFD. Signed-off-by:
Jonathan Kim <jonathan.kim@amd.com> Reviewed-by:
-
Jonathan Kim authored
Report the min/max bandwidth in megabytes to the kfd for direct xgmi connections only. Indirect peers will report 0 since indirect route is unknown. Signed-off-by:
-
Jonathan Kim authored
The TA can now be invoked to provide the number of xgmi links connecting a direct source and destination peer. Non-direct peers will report zero links. Signed-off-by:
-
Anson Jacob authored
make htmldocs complaints about parameter for amdgpu_bo_add_to_shadow_list ./drivers/gpu/drm/amd/amdgpu/amdgpu_object.c:739: warning: Excess function parameter 'bo' description in 'amdgpu_bo_add_to_shadow_list' ./drivers/gpu/drm/amd/amdgpu/amdgpu_object.c:739: warning: Function parameter or member 'vmbo' not described in 'amdgpu_bo_add_to_shadow_list' ./drivers/gpu/drm/amd/amdgpu/amdgpu_object.c:739: warning: Excess function parameter 'bo' description in 'amdgpu_bo_add_to_shadow_list' Signed-off-by:
-
Lijo Lazar authored
Add support for board power calibration on Aldebaran. Board calibration is done after DC offset calibration. Signed-off-by:
Lijo Lazar <lijo.lazar@amd.com> Reviewed-by:
Kevin Wang <kevin1.wang@amd.com> Signed-off-by:
-
Eric Yang authored
[Why] PMFW message which previously thought to only control Z9 controls both Z9 and Z10. Also HW design team requested that Z9 must only be supported on eDP due to content protection interop. [How] Change zstate support condition to match updated policy Reviewed-by:
Nicholas Kazlauskas <Nicholas.Kazlauskas@amd.com> Acked-by:
Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by:
Eric Yang <Eric.Yang2@amd.com> Signed-off-by:
-
Aric Cyr authored
DC version 3.2.145 brings improvements in multiple areas. In summary, we highlight: - Code improvements for passive - Cursor manipulation enhancements - Expand debug in some areas - Fix problems in DML - Other minor code refactors Reviewed-by:
Aric Cyr <aric.cyr@amd.com> Signed-off-by:
-
Anthony Koo authored
- Add reserved bits for future feature development - Fix issue with mismatch with type const - Replaced problematic code with old memcpy and casted problematic pointers to unsigned char pointers Reviewed-by:
Anthony Koo <Anthony.Koo@amd.com> Signed-off-by:
-
Krunoslav Kovac authored
[why] There's a special case where upper plane is not the main plane. If it owns the cursor, it will be invisible in the majority of the screen. [How] The condition for disabling cursor is changed: - check if upper viewport completely covers current. This was the previous change that doesn't handle all scenarios with pipe splitting. - if not, show the cursor only if it's not scaled or no upper pipe. Reviewed-by:
Krunoslav Kovac <Krunoslav.Kovac@amd.com> Signed-off-by:
-
Bindu Ramamurthy authored
[Why] Populate dtbclk values from bwparams for dcn302, dcn303. [How] dtbclk values are fetched from bandwidthparams for all DPM levels and for DPM levels where smu returns 0, previous level values are reported. Reviewed-by:
Roman Li <Roman.Li@amd.com> Acked-by:
Bindu Ramamurthy <bindu.r@amd.com> Signed-off-by:
-
Eric Yang authored
[Why] When an riommu invalidation request come at the same time as a pipe is disabled there can be a case where DCN cannot ACK the request if only one VMID is setup in the inuse list. [How] Setup a second unused VMID will work around the issue. Reviewed-by:
Jun Lei <jun.lei@amd.com> Acked-by:
-
Nevenko Stupar authored
DCN 3x increased Line buffer size for DCHUB latency hiding, from 4 lines of 4K resolution lines to 5 lines of 4K resolution lines. All Line Buffer can be used as extended memory for P State change latency hiding. The maximum number of lines is increased to 32 lines. Finally, LB_MEMORY_CONFIG_1 (LB memory piece 1) and LB_MEMORY _CONFIG_2 (LB memory piece 2) are not affected, no change in size, only 3 pieces is affected, i.e., when all 3 pieces are used in both LB_MEMORY_CONFIG_0 and LB_MEMORY_CONFIG_3 (for 4:2:0) modes. Reviewed-by:
Nevenko Stupar <Nevenko.Stupar@amd.com> Signed-off-by:
-
Mikita Lipski authored
[why] DCN31 doesn't have MALL in DMUB so to avoid sending unknown commands to DMUB just remove the function pointer. [how] Remove apply_idle_power_optimizations from function pointers structure for DCN31 Reviewed-by:
Mikita Lipski <mikita.lipski@amd.com> Signed-off-by:
-
sunglee authored
[WHY] When finding a second pipe for pipe split, currently will look for bottom pipe in context first to decide the second pipe. This causes issues in 2 plane to 1 plane transitions like fullscreen video where bottom pipe no longer exists in the new configuration. [HOW] If previous context had an ODM pipe, use that to find the secondary pipe first before looking at bottom pipe. Reviewed-by:
Dmytro Laktyushkin <Dmytro.Laktyushkin@amd.com> Acked-by:
sunglee <sunglee@amd.com> Signed-off-by:
-
Camille Cho authored
[Why] We used to unconditionally set backlight path as AUX for panels capable of backlight adjustment via DPCD in set default brightness. [How] This should be limited to OLED panel only since we control backlight via PWM path for SDR mode in LCD HDR panel. Reviewed-by:
Camille Cho <Camille.Cho@amd.com> Signed-off-by:
-
Nicholas Kazlauskas authored
[Why & How] We're missing a default value for dram_channel_width_bytes in the DCN3.1 SOC bounding box and we don't currently have the interface in place to query the actual value from VBIOS. Put in a hardcoded default until we have the interface in place. Reviewed-by:
-
Nicholas Kazlauskas authored
[Why] Hardcoding the VCO frequency isn't correct since we don't own or control the value. In the case where the hardcode is also missing we can't lightup display. [How] Query from the CLK register instead. Update the DFS frequency to be able to compute the VCO frequency. Reviewed-by:
-
Bindu Ramamurthy authored
[Why] Initialize socclk entries in bandwidth params for dcn302, dcn303. [How] Fetch the sockclk values from smu for the DPM levels and for the DPM levels where smu returns 0, previous level values are reported. Reviewed-by:
-
Nicholas Kazlauskas authored
[Why] Vertical and horizontal borders in timings are treated as increasing the active area - vblank and hblank actually shrink. Our input into DML does not include these borders so it incorrectly assumes it has more time than available for vstartup and tmdl calculations for some modes with borders. An example of such a timing would be 640x480@72Hz: h_total: 832 h_border_left: 8 h_addressable: 640 h_border_right: 8 h_front_porch: 16 h_sync_width: 40 v_total: 520 v_border_top: 8 v_addressable: 480 v_border_bottom: 8 v_front_porch: 1 v_sync_width: 3 pix_clk_100hz: 315000 [How] Include borders as part of destination vactive/hactive. This change DCN20+ so it has wide impact, but the destination vactive and hactive are only really used for vstartup calculation anyway. Most modes do not have vertical or horizontal borders. Reviewed-by:
-
Michael Strauss authored
[WHY] Enable feature for 21.40 Reviewed-by:
Sung Lee <Sung.Lee@amd.com> Acked-by:
Michael Strauss <michael.strauss@amd.com> Signed-off-by:
-
Aric Cyr authored
Reviewed-by:
Shahin Khayyer <Shahin.Khayyer@amd.com> Acked-by:
-
Victor Lu authored
[why] A comparison error made it possible to not iterate through all the specified prefetch modes. [how] Correct "<" to "<=" Reviewed-by:
Yongqiang Sun <Yongqiang.Sun@amd.com> Acked-by:
Victor Lu <victorchengchi.lu@amd.com> Signed-off-by:
-
Jake Wang authored
[Why] During headless boot, DIG may be on which causes HW/SW discrepancies. To avoid this we power down hardware on boot if DIG is turned on. With introduction of multiple eDP, hardware power down is being bypassed under certain conditions. [How] Fixed hardware power down bypass, and ensured hardware will power down if DIG is on and seamless boot is not enabled. Reviewed-by:
Jake Wang <haonan.wang2@amd.com> Signed-off-by:
-
Wesley Chalmers authored
Reviewed-by:
Wesley Chalmers <Wesley.Chalmers@amd.com> Signed-off-by:
-
Zhan Liu authored
[Why] Theoretically, per DP 1.4a spec, sink device needs to AUX_ACK 00340h write. However, due to hardware limitation, some sink devices have no 00340h dpcd address at all. This results in sink side fails to reply ACK, and consequently cause source side keep retrying DPCD write on DPCD 00340h. This results in significant delay when DPCD 00340h write is triggered (e.g. at S3 resume). [How] Check whether sink device could ACK on DPCD 00340h write on boot. If sink device fails to ACK, then remember that, so we won't write to DPCD 00340h later on. There will be a drm.debug KMS level message to inform user once a 00340h DPCD write is skipped on purpose. Reviewed-by:
Nikola Cornij <Nikola.Cornij@amd.com> Acked-by:
Zhan Liu <zhan.liu@amd.com> Signed-off-by:
-
Aurabindo Pillai authored
[Why&How] Print a debug message when dcc validation fails in the display driver. Most DCC enablement related errors are from userspace. Adding a debug print in case of a failure from display driver will aid quicker triage. Reviewed-by:
Aurabindo Pillai <aurabindo.pillai@amd.com> Signed-off-by:
-
- 21 Jul, 2021 4 commits
-
-
Aric Cyr authored
Acked-by:
-
Anthony Koo authored
- Add reserved bits for future feature development - Fix issue with mismatch with type const Acked-by:
-
Dmytro Laktyushkin authored
This tends to take miliseconds in certain scenarios and we'd rather not wait that long. Due to how this interacts with det size update and locking waiting should not be necessary as compbuf updates before unlock. Add a watch for config error instead as that is something we actually do care about. Acked-by:
-
Ian Chen authored
Reserve padding bytes for new feature implementation Acked-by:
Ian Chen <ian.chen@amd.com> Signed-off-by:
-
