kernel/linux.git/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c, branch v6.1.45

drm/amdgpu: Remove unnecessary domain argument

2023-08-11T10:08:27+00:00

commit 3273f11675ef11959d25a56df3279f712bcd41b7 upstream Remove the "domain" argument to amdgpu_bo_create_kernel_at() since this function takes an "offset" argument which is the offset off of VRAM, and as such allocation always takes place in VRAM. Thus, the "domain" argument is unnecessary. Cc: Alex Deucher Cc: Christian König Cc: AMD Graphics Signed-off-by: Luben Tuikov Reviewed-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Mario Limonciello Signed-off-by: Greg Kroah-Hartman

drm/amd: Add IMU fw version to fw version queries

2022-10-24T18:44:03+00:00

IMU is a new firmware for GFX11. There are four means by which firmware version can be queried from the driver: device attributes, vf2pf, debugfs, and the AMDGPU_INFO_FW_VERSION option in the amdgpu info ioctl. Add IMU as an option for those four methods. V2: Added debugfs Reviewed-by: Likun Gao Reviewed-by: Alex Deucher Signed-off-by: David Francis Signed-off-by: Alex Deucher

drm/amdgpu: set vm_update_mode=0 as default for Sienna Cichlid in SRIOV case

2022-10-19T02:07:58+00:00

For asic with VF MMIO access protection avoid using CPU for VM table updates. CPU pagetable updates have issues with HDP flush as VF MMIO access protection blocks write to mmBIF_BX_DEV0_EPF0_VF0_HDP_MEM_COHERENCY_FLUSH_CNTL register during sriov runtime. v3: introduce virtualization capability flag AMDGPU_VF_MMIO_ACCESS_PROTECT which indicates that VF MMIO write access is not allowed in sriov runtime Signed-off-by: Danijel Slivka Reviewed-by: Felix Kuehling Signed-off-by: Alex Deucher

drm/amdgpu/vcn: Add vcn/vcn1 in white list to load its firmware under sriov

2022-09-01T19:12:04+00:00

Previously since vcn0/vcn1 are not enabled, loading firmware is skipped. Now add firmware loading back since vcn0/vcn1 has already been enabled on sriov Acked-by: Christian König Signed-off-by: Jane Jian Reviewed-by: Hawking Zhang Signed-off-by: Alex Deucher

drm/amdgpu: Support PSP 13.0.10 on SR-IOV

2022-09-01T19:11:26+00:00

Add support for PSP 13.0.10 for SR-IOV VF Acked-by: Christian König Signed-off-by: Horace Chen Reviewed-by: Hawking Zhang Signed-off-by: Alex Deucher

drm/amdgpu: refine virtualization psp fw skip check

2022-09-01T19:11:12+00:00

SR-IOV may need to load different firmwares for different ASIC inside VF. So create a new function in amdgpu_virt to check whether FW load needs to be skipped. Acked-by: Christian König Signed-off-by: Horace Chen Reviewed-by: Hawking Zhang Signed-off-by: Alex Deucher

drm/amdgpu: add CHIP_IP_DISCOVERY support for virtualization

2022-09-01T19:10:54+00:00

For further chips we will use CHIP_IP_DISCOVERY, so add this support for virtualization Acked-by: Christian König Signed-off-by: Horace Chen Reviewed-by: Hawking Zhang Signed-off-by: Alex Deucher

drm/amdgpu: enable mes to access registers v2

2022-06-30T19:28:24+00:00

Enable mes to access registers. v2: squash mes sched ring enablement flag Signed-off-by: Jack Xiao Reviewed-by: Hawking Zhang Signed-off-by: Alex Deucher

drm/amdgpu: do not use passthrough mode in Xen dom0

2022-04-28T21:46:01+00:00

While technically Xen dom0 is a virtual machine too, it does have access to most of the hardware so it doesn't need to be considered a "passthrough". Commit b818a5d37454 ("drm/amdgpu/gmc: use PCI BARs for APUs in passthrough") changed how FB is accessed based on passthrough mode. This breaks amdgpu in Xen dom0 with message like this: [drm:dc_dmub_srv_wait_idle [amdgpu]] *ERROR* Error waiting for DMUB idle: status=3 While the reason for this failure is unclear, the passthrough mode is not really necessary in Xen dom0 anyway. So, to unbreak booting affected kernels, disable passthrough mode in this case. Link: https://gitlab.freedesktop.org/drm/amd/-/issues/1985 Fixes: b818a5d37454 ("drm/amdgpu/gmc: use PCI BARs for APUs in passthrough") Signed-off-by: Marek Marczykowski-Górecki Signed-off-by: Alex Deucher

drm/amd/amdgpu: Remove static from variable in RLCG Reg RW

2022-04-14T19:29:20+00:00

[why] These static variables save the RLC Scratch registers address. When we install multiple GPUs (for example: XGMI setting) and multiple GPUs call the function at same time. The RLC Scratch registers address are changed each other. Then it caused reading/writing from/to wrong GPU. [how] Removed the static from the variables. The variables are on the stack. Fixes: 5d447e29670148 ("drm/amdgpu: add helper for rlcg indirect reg access") Reviewed-by: Alex Deucher Signed-off-by: Gavin Wan Signed-off-by: Alex Deucher