- 01 Sep, 2022 26 commits
-
-
Asher Song authored
There are duplicated declarations of i, remove one of those. Signed-off-by:
Asher Song <Asher.Song@amd.com> Reviewed-by:
Guchun Chen <guchun.chen@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com>
-
Jane Jian authored
These structures are basically ported from MMSCH v3_0, besides, added RB and RB4 enablement flag to support unified queue Acked-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
Jane Jian <Jane.Jian@amd.com> Reviewed-by:
Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by:
-
Jane Jian authored
Enable unified queue support for sriov, abandon all previous multi-queue settings Acked-by:
Ruijing Dong <ruijing.dong@amd.com> Signed-off-by:
-
Jane Jian authored
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:
-
Jane Jian authored
For sriov, CG and MG are controlled from hypervisor side, no need to manage them again in ip init Acked-by:
Sonny Jiang <sonny.jiang@amd.com> Reviewed-by:
-
Yifan Zha authored
[Why] VF do not need to handle SMU IRQ state. L1 Policy will block VF access THM_THERMAL_INT_CTRL and MP1_SMN_IH_SW_INT/CNTL. [How] Skip smu_v13 init register_irq_handler under SRIOV VF. And add irq_src check in enable/disable thermal alert to avoid thermal alert enable/disable fail. Acked-by:
Yifan Zha <Yifan.Zha@amd.com> Reviewed-by:
-
Yifan Zha authored
[Why] There is no CG(Clock Gating)/PG(Power Gating) requirement on SRIOV VF. For multi VF, VF should not enable any CG/PG features. For one VF, PF will program CG/PG related registers. [How] Do not set any cg/pg flag bit at early init under sriov. Acked-by:
-
Yifan Zha authored
[Why] KIQ register init requires GRBM_GFX_CNTL to select KIQ. [How] As RLCG accessing registers will save the data of GRBM_GFX_CNTL and restore it. Use RLCG indirect accessing register method to select grbm instead of mmio directly access. Acked-by:
-
Yifan Zha authored
[Why] As SDMA0_SEM_WAIT_FAIL_TIMER_CNTL is a PF-only register, L1 would block this register for VF access. [How] VF do not program it. Acked-by:
-
Yifan Zha authored
[Why] As VF cannot read MMMC_VM_FB_OFFSET with L1 Policy(read 0xffffffff). It leads to driver get the incorrect vram base offset. [How] Since SR-IOV is dGPU only, skip reading this register and set the fb_offest to 0. Acked-by:
Horace Chen <horace.chen@amd.com> Reviewed-by:
-
Yifan Zha authored
[Why] vm_l2_bank_select_reserved_cid2 is a PF_only register that cannot be programmed by VF. This feature is only support HDP using GPUVM page tables to access FB memory which should be disabled on SRIOV. [How] Disable the feature on VF. Acked-by:
-
Yifan Zha authored
[Why] VF should not program these registers, the value were defined in the host. [How] Skip writing them in SRIOV environment and program them on host side. Acked-by:
-
Yifan Zha authored
[Why] With L1 Policy applied, IH_RB_CNTL/RING cannot be accessed by VF. [How] Use PSP program IH_RB_CNTL in VF. Acked-by:
-
Horace Chen authored
Add support for PSP 13.0.10 for SR-IOV VF Acked-by:
-
Horace Chen authored
SRIOV needs to initialize mmsch instead of multimedia engines directly. So currently remove them for SR-IOV until the code and firmwares are ready. Acked-by:
-
Horace Chen authored
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:
-
Horace Chen authored
[Why] Under SR-IOV, if VF is switched out then its doorbell will be disabled, SDMA rely on WPTR_POLL to get doorbells which was sent during VF switched-out time. [How] For SR-IOV, set SDMA WPTR_POLL_ENABLE to 1. Acked-by:
-
Horace Chen authored
[Why] Under SR-IOV, we are not sure whether pipe status is good or not when doing initialization. The compute engine maybe fail to bringup if pipe status is bad. [How] Do an RS64 pipe reset for MEC before we do initialization. Also apply to bare-metal. Acked-by:
-
Horace Chen authored
[Why] under SR-IOV, the nbio doorbell range will be defined by PF. So VF nbio doorbell range registers will be blocked. It will cause violation if VF access those registers directly. [How] create an nbio_v4_3_sriov_funcs for sriov nbio_v4_3 initialization to skip the setting for the doorbell range registers. Acked-by:
-
Horace Chen authored
For further chips we will use CHIP_IP_DISCOVERY, so add this support for virtualization Acked-by:
-
Yifan Zhang authored
there is only one SDMA engine in SDMA 6.0.1, the sdma_hqd_mask has to be zeroed for the 2nd engine, otherwise MES scheduler will consider 2nd engine exists and map/unmap SDMA queues to the non-existent engine. Signed-off-by:
Yifan Zhang <yifan1.zhang@amd.com> Reviewed-by:
Tim Huang <Tim.Huang@amd.com> Signed-off-by:
-
Alex Deucher authored
Document missing parameter. Cc: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Cc: Harry Wentland <harry.wentland@amd.com> Fixes: 8889a13f99e5 ("drm/amd/display: Add some extra kernel doc to amdgpu_dm") Reported-by:Stephen Rothwell <sfr@canb.auug.org.au> Reviewed-by:
Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by:
-
Rodrigo Siqueira authored
Multiple plane overlay is a feature supported by AMD hardware, but it has specific details that deserve proper documentation. This commit introduces a documentation that describes some of the features, limitations, and use cases for this feature. Part of this documentation came from some discussion in the public upstream [1][2]. [1]. https://lore.kernel.org/amd-gfx/3qY-QeukF_Q_MJeIXAuBjO4szbS4jRtqkTifXnbnN3bp88SxVodFQRpah3mIIVJq24DUkF6g0rOGdCmSqTvVxx9LCGEItmzLw8uWU44jtXE=@emersion.fr/ [2]. https://lore.kernel.org/amd-gfx/864e45d0-c14b-3b12-0f5b-9d26a9cb41bd@amd.com/ Cc: Harry Wentland <harry.wentland@amd.com> Cc: Nicholas Kazlauskas <Nicholas.Kazlauskas@amd.com> Cc: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Cc: Hersen Wu <hersenxs.wu@amd.com> Cc: Alex Hung <alex.hung@amd.com> Cc: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com> Cc: Simon Ser <contact@emersion.fr> Cc: Pekka Paalanen <pekka.paalanen@collabora.com> Cc: Sean Paul <seanpaul@chromium.org> Cc: Mark Yacoub <markyacoub@chromium.org> Cc: Leo Li <sunpeng.li@amd.com> Cc: Pierre-Loup <pgriffais@valvesoftware.com> Cc: Michel Dänzer <michel.daenzer@mailbox.org> Reviewed-by:
Harry Wentland <Harry.Wentland@amd.com> Signed-off-by:
-
Rodrigo Siqueira authored
In the DCN code, we constantly talk about hardware pipeline, pipeline, or even just pipes, which is a concept that is not obvious to everyone. For this reason, this commit expands the DCN overview explanation by adding a new section that describes what a pipeline is from the DCN perspective. Changes since V1: - Rewrite the first paragraph that describes AMD hardware pipeline. Cc: Harry Wentland <harry.wentland@amd.com> Cc: Nicholas Kazlauskas <Nicholas.Kazlauskas@amd.com> Cc: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Cc: Hersen Wu <hersenxs.wu@amd.com> Cc: Alex Hung <alex.hung@amd.com> Cc: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com> Cc: Leo Li <sunpeng.li@amd.com> Cc: Simon Ser <contact@emersion.fr> Cc: Pekka Paalanen <pekka.paalanen@collabora.com> Cc: Sean Paul <seanpaul@chromium.org> Cc: Mark Yacoub <markyacoub@chromium.org> Cc: Pierre-Loup <pgriffais@valvesoftware.com> Cc: Michel Dänzer <michel.daenzer@mailbox.org> Reviewed-by:
-
Rodrigo Siqueira authored
Amdgpu driver is used in an extensive range of devices, and each ASIC has some specific configuration. As a result of this variety, sometimes it is hard to identify the correct block that might cause the issue. This commit expands the amdgpu kernel-doc to alleviate this issue by introducing one ASIC table that describes dGPU and another one that shares the APU info. Cc: Harry Wentland <harry.wentland@amd.com> Cc: Nicholas Kazlauskas <Nicholas.Kazlauskas@amd.com> Cc: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Cc: Hersen Wu <hersenxs.wu@amd.com> Cc: Alex Hung <alex.hung@amd.com> Cc: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com> Cc: Leo Li <sunpeng.li@amd.com> Cc: Simon Ser <contact@emersion.fr> Cc: Pekka Paalanen <pekka.paalanen@collabora.com> Cc: Sean Paul <seanpaul@chromium.org> Cc: Mark Yacoub <markyacoub@chromium.org> Cc: Pierre-Loup <pgriffais@valvesoftware.com> Cc: Michel Dänzer <michel.daenzer@mailbox.org> Cc: Kent Russell <Kent.Russell@amd.com> Reviewed-by:
-
Chengming Gui authored
Restrict the ucode loading check to avoid frontdoor loading error. Signed-off-by:
Chengming Gui <Jack.Gui@amd.com> Reviewed-by:
-
- 30 Aug, 2022 14 commits
-
-
ye xingchen authored
Return the value sdma_v4_0_start() directly instead of storing it in another redundant variable. Reported-by:
Zeal Robot <zealci@zte.com.cn> Signed-off-by:
ye xingchen <ye.xingchen@zte.com.cn> Signed-off-by:
-
Hawking Zhang authored
Add ip block support for mes v11_0_3. Signed-off-by:
Frank Min <Frank.Min@amd.com> Signed-off-by:
-
Hawking Zhang authored
Add ip block support for gfx v11_0_3. Signed-off-by:
-
Hawking Zhang authored
Set AMDGPU_FAMILY_GC_11_0_0. Signed-off-by:
-
Hawking Zhang authored
All gc v11_0_3 registers in gcvml2 range have different register offset from the ones in gc v11_0_0. v11_0_3 imu_rlc_ram programming has to be separated from v11_0_0 implementation v2: fix checkpatch errors (Alex) Signed-off-by:
Yang Wang <KevinYang.Wang@amd.com> Reviewed-by:
-
David Belanger authored
Added missing cases for GFX 11.0.3 code in a few switch statements. Signed-off-by:
David Belanger <david.belanger@amd.com> Reviewed-by:
-
Hawking Zhang authored
initialize some gfx config for gfx v11_0_3 Signed-off-by:
-
Hawking Zhang authored
To support new mes ip block Signed-off-by:
-
Hawking Zhang authored
To support new gfx ip block Signed-off-by:
-
Hawking Zhang authored
Add ip block support for gmc v11_0_3. Signed-off-by:
-
Hawking Zhang authored
initialize gmc sw config for v11_0_3 Signed-off-by:
-
Yang Wang authored
add gfxhub_v3_0_3 support Signed-off-by:
-
Frank Min authored
Add gc v11_0_3 register offset and shift masks header files v2: update registers (Alex) Signed-off-by:
-
Hawking Zhang authored
Not all the gfx10 variants need to integrate global tap_delay and per se tap_delay firmwares Only init tap_delay ucode when it does include in rlc ucode binary so driver doesn't send a null buffer to psp for firmware loading Signed-off-by:
-
