Power reporting is socket power. On APUs this includes
the CPU. Update the documentation to clarify this.
Reviewed-by: Aaron Liu <aaron.liu@amd.com>
Reviewed-by: Evan Quan <evan.quan@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Update queue qpd is done for the first queue creation of the process,
if the device support XNACK mode per process, update qpd setup
sh_mem_config based on the process XNACK mode, to support the process
destroy all queues, change XNACK mode, and then create queues.
Add helper macro KFD_SUPPORT_XNACK_PER_PROCESS to remove duplicate code
and add new ASICs support in future.
Signed-off-by: Philip Yang <Philip.Yang@amd.com>
Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
If early init fails for a single IP block, then no further IP blocks
are evaluated. This means that if a user was missing more than one
firmware binary they would have to keep adding binaries and re-probing
until they discovered the ones missing.
To make this easier, run early init for each IP block and report a single
failure if not all passed.
Reviewed-by: Aaron Liu <aaron.liu@amd.com>
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
There is already a "default" case in the switch block, so there is
no need to have a break after the switch block.
Reviewed-by: Aaron Liu <aaron.liu@amd.com>
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]:
Amdgpu ras uses amdgpu_ras_is_supported to check whether
the ras block supports the ras function. amdgpu_ras_is_supported
uses .ras_enabled to determine whether the ras function of the
block is enabled.
But for special asic with mem ecc enabled but sram ecc not
enabled, some ras blocks support poison mode but their ras function
is not enabled on .ras_enabled, these ras blocks will run abnormally.
[How]:
If the ras block is not supported on .ras_enabled but the asic
supports poison mode and the ras block has ras configuration, it
can be considered that the ras block supports ras function.
Signed-off-by: YiPeng Chai <YiPeng.Chai@amd.com>
Reviewed-by: Tao Zhou <tao.zhou1@amd.com>
Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]:
For special asic with mem ecc enabled but sram ecc
not enabled, some ras blocks can register their ras
configuration to ras list, but these ras blocks are not
enabled on .ras_enabled, so it can not get ras block
object using amdgpu_ras_get_ras_block.
[How]:
Remove ras block support check. Even if the ras block
checked is not in the ras list, it will return a null
pointer and will have no effect.
Signed-off-by: YiPeng Chai <YiPeng.Chai@amd.com>
Reviewed-by: Tao Zhou <tao.zhou1@amd.com>
Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Perform gpu reset after gfx finishes processing
ras poison consumption on gfx_v11_0_3.
V2:
Move gfx poison consumption handler from hw_ops to ip
function level.
V3:
Adjust the calling position of amdgpu_gfx_poison_consumation_handler.
V4:
Since gfx v11_0_3 does not have .hw_ops instance, the .hw_ops null
pointer check in amdgpu_ras_interrupt_poison_consumption_handler
needs to be adjusted.
Signed-off-by: YiPeng Chai <YiPeng.Chai@amd.com>
Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com>
Reviewed-by: Tao Zhou <tao.zhou1@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Add gfx ras function on gfx v11_0_3.
V2:
1. Add separate source files for gfx v11_0_3.
2. Create a common function to initialize gfx ras block.
V3:
1. Rename amdgpu_gfx_ras_block_init to amdgpu_gfx_ras_sw_init.
2. Adjust the calling position of amdgpu_gfx_ras_sw_init.
3. Remove gfx_v11_0_3_ras_ops.
V4:
Revert changes in amdgpu_ras_interrupt_poison_consumption_handler.
V5:
1. Remove invalid include file in gfx_v11_0_3.c.
2. Reduce the number of parameters of amdgpu_gfx_ras_sw_init.
Signed-off-by: YiPeng Chai <YiPeng.Chai@amd.com>
Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com>
Reviewed-by: Tao Zhou <tao.zhou1@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
The existing codebase never had a case for detecting MP0 version on
Renoir and instead relied upon hardcoded chip name. This was missed as
part of the changes to migrate all IP blocks to build filenames from
`amdgpu_ucode.c`.
Consequently, Renoir tries to fetch a binary with 11_0_3 in the filename
and since it's supposed to have "renoir" in the filename fails to probe.
The fbdev still works though so the series worked.
Add a case for Renoir into the legacy table to ensure the right ASD and
TA firmware load again.
Reported-by: Ekene Akuneme <Ekene.Akuneme@amd.com>
Reported-by: Nicholas Choi <Nicholas.Choi@amd.com>
Cc: Alex Hung <Alex.Hung@amd.com>
Fixes: 994a97447e ("drm/amd: Parse both v1 and v2 TA microcode headers using same function")
Fixes: 54a3e03234 ("drm/amd: Add a legacy mapping to "amdgpu_ucode_ip_version_decode"")
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
This version brings along following fixes:
- Revert patches that caused regressions associated with audio and an
old change that checks the DCN version.
- Refactor DDC and HDP.
- Move DPIA and DPCD logic to new files.
- Updates to DMUB.
- Optimization and bug fixes for SUBVP/DRR.
- Drop legacy code.
Tested-by: Daniel Wheeler <Daniel.Wheeler@amd.com>
Reviewed-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Aric Cyr <aric.cyr@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[why]
For MST topology with 1 physical link and multiple connectors (>=2),
e.g. daisy cahined MST + SST, or 1-to-multi MST hub, if userspace
set to enable the HDCP simultaneously on all connected outputs, the
commit tail iteratively call the hdcp_update_display() for each
display (connector). However, the hdcp workqueue data structure for
each link has only one DM connector and encryption status members,
which means the work queue of property_validate/update() would only
be triggered for the last connector within this physical link, and
therefore the HDCP property value of other connectors would stay on
DESIRED instead of switching to ENABLED, which is NOT as expected.
[how]
Use array of AMDGPU_DM_MAX_DISPLAY_INDEX for both aconnector and
encryption status in hdcp workqueue data structure for each physical
link. For property validate/update work queue, we iterates over the
array and do similar operation/check for each connected display.
Tested-by: Daniel Wheeler <Daniel.Wheeler@amd.com>
Signed-off-by: hersen wu <hersenxs.wu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[WHY?]
Cannot only consider the MALL required from top pipes because of the MPO
case.
[HOW?]
Only count a pipe if it fits the following criteria:
1) does not have a top pipe (is the topmost pipe for that plane)
2) it does have a top pipe, but that pipe is associated with a different
plane
Tested-by: Daniel Wheeler <Daniel.Wheeler@amd.com>
Reviewed-by: Nevenko Stupar <Nevenko.Stupar@amd.com>
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Dillon Varone <Dillon.Varone@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Description]
- Request min clocks after disabling pipes on init
- This optimizes for power savings during init sequence
- Also handles the case where we boot up with no display connected
Tested-by: Daniel Wheeler <Daniel.Wheeler@amd.com>
Reviewed-by: Jun Lei <Jun.Lei@amd.com>
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Alvin Lee <Alvin.Lee2@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
When an eDP panel is powered externally from a different GPU, we can avoid
waiting for hardware sequencing delays when switching the backlight on/off
as the display backlight is no longer powered by the original source.
[How]
This commit extends the 'link_powered_externally' variable to allow
bypassing hardware delays for additional backlight commands and force the
backlight on/off when a link is powered by another GPU.
Tested-by: Daniel Wheeler <Daniel.Wheeler@amd.com>
Reviewed-by: Felipe Clark <felipe.clark@amd.com>
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Tony Tascioglu <tony.tascioglu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
DCC meta was found to be detached from usable pixel data. Due to this
DCC meta and the end of the fetched part of the frame will be on not
be on the same mblk. Furthermore if the meta is not aligned to the mblk
size, then we require an extra mblk in MALL to account for this.
[How]
Always add an additional mblk when DCC is enabled for detachment and
misalignment.
Tested-by: Daniel Wheeler <Daniel.Wheeler@amd.com>
Reviewed-by: Dillon Varone <Dillon.Varone@amd.com>
Reviewed-by: Jun Lei <Jun.Lei@amd.com>
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Saaem Rizvi <SyedSaaem.Rizvi@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
When an eDP panel is powered externally by a different GPU, we don't need
to wait for hardware sequencing delays when powering down a link, as the
display is not dependent on the GPU being powered down.
[How]
This commit adds a variable 'link_powered_externally' to indicate when a
link is being powered by another GPU.
Tested-by: Daniel Wheeler <Daniel.Wheeler@amd.com>
Reviewed-by: Felipe Clark <felipe.clark@amd.com>
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Tony Tascioglu <tony.tascioglu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Checking for disabled master pipe on a timing synchronized pipe is
incorrect in the case of ODM combine. This case is acceptable as long as
the disabled master pipe is part of the ODM tree. Skip printing error
message if this condition holds true.
Tested-by: Daniel Wheeler <Daniel.Wheeler@amd.com>
Reviewed-by: Dillon Varone <Dillon.Varone@amd.com>
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[why]
Extract dp link training logic out to their own files.
link_dp_training - high level training sequence and helper functions.
link_dp_training_8b_10b - dp1.x training
link_dp_training_auxless - aux-less training
link_dp_traininig_dpia - dpia training
link_dp_training_fixed_vs_pe_retimer - fixed vs pe retimer training
link_dp_training_128b_132b - dp2.1 training
Tested-by: Daniel Wheeler <Daniel.Wheeler@amd.com>
Reviewed-by: Wesley Chalmers <Wesley.Chalmers@amd.com>
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Wenjing Liu <wenjing.liu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Current implementation of SubVP does not support cases where stream
timing matched neither the destination rect nor the source rect.
Will need to further debug to see how we can support these cases.
Tested-by: Daniel Wheeler <Daniel.Wheeler@amd.com>
Reviewed-by: Alvin Lee <Alvin.Lee2@amd.com>
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Saaem Rizvi <SyedSaaem.Rizvi@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
MALL SS and Subvp use the same calculations for determining the size of
the required allocation for a given surface, which is already done in
DML. Add an interface to extract this information from VBA variables and
use in their respective helper functions. Also refactor existing code to
remove stale workarounds.
Tested-by: Daniel Wheeler <Daniel.Wheeler@amd.com>
Reviewed-by: Alvin Lee <Alvin.Lee2@amd.com>
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Dillon Varone <Dillon.Varone@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Two issues existed:
1) Configs that support DRR, but have it disabled will fail subvp+vblank
validation incorrectly. Use subvp+vblank path for this case.
2) Configs that support DRR and have it enabled can use higher voltage level
than required if they also support subvp+vblank. Use lowest supported voltage
level for this case.
Tested-by: Daniel Wheeler <Daniel.Wheeler@amd.com>
Reviewed-by: Alvin Lee <Alvin.Lee2@amd.com>
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Dillon Varone <Dillon.Varone@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
This tab was deleted accidentally and triggers a Smatch warning:
drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c:1006 gfx_v8_0_init_microcode()
warn: inconsistent indenting
Add it back.
Fixes: 0aaafb7359 ("drm/amd: Use `amdgpu_ucode_*` helpers for GFX8")
Signed-off-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
On MIPS, vmap() and vunmap() are undeclared in ttm_bo_util.c. An
error message is shown below.
CC drivers/gpu/drm/ttm/ttm_bo_util.o
../drivers/gpu/drm/ttm/ttm_bo_util.c: In function 'ttm_bo_kmap_ttm':
../drivers/gpu/drm/ttm/ttm_bo_util.c:364:32: error: implicit declaration of function 'vmap'; did you mean 'kmap'? [-Werror=implicit-function-declaration]
364 | map->virtual = vmap(ttm->pages + start_page, num_pages,
| ^~~~
| kmap
../drivers/gpu/drm/ttm/ttm_bo_util.c:364:30: warning: assignment to 'void *' from 'int' makes pointer from integer without a cast [-Wint-conversion]
364 | map->virtual = vmap(ttm->pages + start_page, num_pages,
| ^
../drivers/gpu/drm/ttm/ttm_bo_util.c: In function 'ttm_bo_kunmap':
../drivers/gpu/drm/ttm/ttm_bo_util.c:429:17: error: implicit declaration of function 'vunmap'; did you mean 'kunmap'? [-Werror=implicit-function-declaration]
429 | vunmap(map->virtual);
| ^~~~~~
| kunmap
../drivers/gpu/drm/ttm/ttm_bo_util.c: In function 'ttm_bo_vmap':
../drivers/gpu/drm/ttm/ttm_bo_util.c:509:23: warning: assignment to 'void *' from 'int' makes pointer from integer without a cast [-Wint-conversion]
509 | vaddr = vmap(ttm->pages, ttm->num_pages, 0, prot);
| ^
Fix this by including <linux/vmalloc.h>.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Christian König <christian.koenig@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230116121023.14245-1-tzimmermann@suse.de
