RE: [PATCH] drm/amd/amdgpu: Add pcie indirect support to amdgpu_mm_wreg_mmio_rlc()
[AMD Official Use Only]
Reviewed-by: Hawking Zhang
Regards,
Hawking
-Original Message-
From: amd-gfx On Behalf Of Tom St Denis
Sent: Friday, January 7, 2022 20:08
To: amd-gfx@lists.freedesktop.org
Cc: StDenis, Tom
Subject: [PATCH] drm/amd/amdgpu: Add pcie indirect support to
amdgpu_mm_wreg_mmio_rlc()
The function amdgpu_mm_wreg_mmio_rlc() is used by debugfs to write to MMIO
registers. It didn't support registers beyond the BAR mapped MMIO space. This
adds pcie indirect write support.
Signed-off-by: Tom St Denis
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index c38e0e87090b..53a04095a6db 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -552,7 +552,7 @@ void amdgpu_device_wreg(struct amdgpu_device *adev, }
/**
- * amdgpu_mm_wreg_mmio_rlc - write register either with mmio or with RLC path
if in range
+ * amdgpu_mm_wreg_mmio_rlc - write register either with
+ direct/indirect mmio or with RLC path if in range
*
* this function is invoked only the debugfs register access
*/
@@ -567,6 +567,8 @@ void amdgpu_mm_wreg_mmio_rlc(struct amdgpu_device *adev,
adev->gfx.rlc.funcs->is_rlcg_access_range) {
if (adev->gfx.rlc.funcs->is_rlcg_access_range(adev, reg))
return adev->gfx.rlc.funcs->sriov_wreg(adev, reg, v, 0,
0);
+ } else if ((reg * 4) >= adev->rmmio_size) {
+ adev->pcie_wreg(adev, reg * 4, v);
} else {
writel(v, ((void __iomem *)adev->rmmio) + (reg * 4));
}
--
2.32.0
Re: [PATCH 0/2]
Hi Zhenneng, + some display folks First of all, thanks a lot for your patch. We had a similar patch in the past, but we had to revert it because we cannot simply enable DCN for ARM-based systems. You can refer to this commit message to get a better context: https://gitlab.freedesktop.org/agd5f/linux/-/commit/c241ed2f0ea549c18cff62a3708b43846b84dae3 Before enabling ARM, we first need to isolate all FPU code in the DML folder fully. You can read more about our strategy at the below link: https://patchwork.freedesktop.org/series/93042/ And you can see some examples of this effort in the below links: - https://patchwork.freedesktop.org/series/95504/ - https://patchwork.freedesktop.org/patch/455465/?series=94441=3 - https://patchwork.freedesktop.org/series/98247/ Soon we will submit another series that isolate DCN302, but we still need to isolate code from DCN20, DCN10, DCN303, and DCN301. If you want to help us speed up this process, feel free to look at DCN301 or DCN10. Best Regards Siqueira On 2022-01-07 4:57 a.m., Zhenneng Li wrote: For adapting radeon rx6600 xt on arm64 platform, there report some compile errors. Zhenneng Li (2): drm/amdgpu: fix compile error for dcn on arm64 drm/amdgpu: enable dcn support on arm64 drivers/gpu/drm/amd/display/Kconfig | 2 +- drivers/gpu/drm/amd/display/dc/calcs/Makefile | 6 + .../gpu/drm/amd/display/dc/clk_mgr/Makefile | 7 ++ drivers/gpu/drm/amd/display/dc/dcn10/Makefile | 4 +++ drivers/gpu/drm/amd/display/dc/dcn20/Makefile | 4 +++ .../gpu/drm/amd/display/dc/dcn201/Makefile| 6 + drivers/gpu/drm/amd/display/dc/dcn21/Makefile | 4 +++ drivers/gpu/drm/amd/display/dc/dcn30/Makefile | 6 + .../gpu/drm/amd/display/dc/dcn302/Makefile| 6 + .../gpu/drm/amd/display/dc/dcn303/Makefile| 6 + drivers/gpu/drm/amd/display/dc/dcn31/Makefile | 6 + drivers/gpu/drm/amd/display/dc/dml/Makefile | 25 +++ drivers/gpu/drm/amd/display/dc/dsc/Makefile | 7 ++ 13 files changed, 88 insertions(+), 1 deletion(-)
Re: [PATCH] drm/amd/display: reset dcn31 SMU mailbox on failures
On 2022-01-07 4:40 p.m., Mario Limonciello wrote:
Otherwise future commands may fail as well leading to downstream
problems that look like they stemmed from a timeout the first time
but really didn't.
Signed-off-by: Mario Limonciello
I guess we used to do this but after we started adding the
wait_for_response prior to sending the command this was ignored.
Should be fine.
Reviewed-by: Nicholas Kazlauskas
Regards,
Nicholas Kazlauskas
---
drivers/gpu/drm/amd/display/dc/clk_mgr/dcn31/dcn31_smu.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn31/dcn31_smu.c
b/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn31/dcn31_smu.c
index 8c2b77eb9459..162ae7186124 100644
--- a/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn31/dcn31_smu.c
+++ b/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn31/dcn31_smu.c
@@ -119,6 +119,12 @@ int dcn31_smu_send_msg_with_param(
result = dcn31_smu_wait_for_response(clk_mgr, 10, 20);
+ if (result == VBIOSSMC_Result_Failed) {
+ ASSERT(0);
+ REG_WRITE(MP1_SMN_C2PMSG_91, VBIOSSMC_Result_OK);
+ return -1;
+ }
+
if (IS_SMU_TIMEOUT(result)) {
ASSERT(0);
dm_helpers_smu_timeout(CTX, msg_id, param, 10 * 20);
[PATCH] drm/amd/display: reset dcn31 SMU mailbox on failures
Otherwise future commands may fail as well leading to downstream
problems that look like they stemmed from a timeout the first time
but really didn't.
Signed-off-by: Mario Limonciello
---
drivers/gpu/drm/amd/display/dc/clk_mgr/dcn31/dcn31_smu.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn31/dcn31_smu.c
b/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn31/dcn31_smu.c
index 8c2b77eb9459..162ae7186124 100644
--- a/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn31/dcn31_smu.c
+++ b/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn31/dcn31_smu.c
@@ -119,6 +119,12 @@ int dcn31_smu_send_msg_with_param(
result = dcn31_smu_wait_for_response(clk_mgr, 10, 20);
+ if (result == VBIOSSMC_Result_Failed) {
+ ASSERT(0);
+ REG_WRITE(MP1_SMN_C2PMSG_91, VBIOSSMC_Result_OK);
+ return -1;
+ }
+
if (IS_SMU_TIMEOUT(result)) {
ASSERT(0);
dm_helpers_smu_timeout(CTX, msg_id, param, 10 * 20);
--
2.25.1
[PATCH v3] drm/amd/display: move calcs folder into DML
The calcs folder has FPU code on it, which should be isolated inside the
DML folder as per https://patchwork.freedesktop.org/series/93042/.
This commit aims single-handedly to correct the location of such FPU
code and does not refactor any functions.
Changes since v2:
- Corrected problems to compile when DCN was disabled.
Signed-off-by: Isabella Basso
---
drivers/gpu/drm/amd/display/dc/Makefile | 4 +-
drivers/gpu/drm/amd/display/dc/calcs/Makefile | 68 ---
drivers/gpu/drm/amd/display/dc/dml/Makefile | 10 ++-
.../amd/display/dc/{ => dml}/calcs/bw_fixed.c | 0
.../display/dc/{ => dml}/calcs/calcs_logger.h | 0
.../display/dc/{ => dml}/calcs/custom_float.c | 0
.../display/dc/{ => dml}/calcs/dce_calcs.c| 0
.../dc/{ => dml}/calcs/dcn_calc_auto.c| 0
.../dc/{ => dml}/calcs/dcn_calc_auto.h| 0
.../dc/{ => dml}/calcs/dcn_calc_math.c| 0
.../display/dc/{ => dml}/calcs/dcn_calcs.c| 0
11 files changed, 11 insertions(+), 71 deletions(-)
delete mode 100644 drivers/gpu/drm/amd/display/dc/calcs/Makefile
rename drivers/gpu/drm/amd/display/dc/{ => dml}/calcs/bw_fixed.c (100%)
rename drivers/gpu/drm/amd/display/dc/{ => dml}/calcs/calcs_logger.h (100%)
rename drivers/gpu/drm/amd/display/dc/{ => dml}/calcs/custom_float.c (100%)
rename drivers/gpu/drm/amd/display/dc/{ => dml}/calcs/dce_calcs.c (100%)
rename drivers/gpu/drm/amd/display/dc/{ => dml}/calcs/dcn_calc_auto.c (100%)
rename drivers/gpu/drm/amd/display/dc/{ => dml}/calcs/dcn_calc_auto.h (100%)
rename drivers/gpu/drm/amd/display/dc/{ => dml}/calcs/dcn_calc_math.c (100%)
rename drivers/gpu/drm/amd/display/dc/{ => dml}/calcs/dcn_calcs.c (100%)
diff --git a/drivers/gpu/drm/amd/display/dc/Makefile
b/drivers/gpu/drm/amd/display/dc/Makefile
index b1f0d6260226..a4ef8f314307 100644
--- a/drivers/gpu/drm/amd/display/dc/Makefile
+++ b/drivers/gpu/drm/amd/display/dc/Makefile
@@ -23,12 +23,12 @@
# Makefile for Display Core (dc) component.
#
-DC_LIBS = basics bios calcs clk_mgr dce gpio irq virtual
+DC_LIBS = basics bios clk_mgr dce dml gpio irq virtual
ifdef CONFIG_DRM_AMD_DC_DCN
DC_LIBS += dcn20
DC_LIBS += dsc
-DC_LIBS += dcn10 dml
+DC_LIBS += dcn10
DC_LIBS += dcn21
DC_LIBS += dcn201
DC_LIBS += dcn30
diff --git a/drivers/gpu/drm/amd/display/dc/calcs/Makefile
b/drivers/gpu/drm/amd/display/dc/calcs/Makefile
deleted file mode 100644
index f3c00f479e1c..
--- a/drivers/gpu/drm/amd/display/dc/calcs/Makefile
+++ /dev/null
@@ -1,68 +0,0 @@
-#
-# Copyright 2017 Advanced Micro Devices, Inc.
-# Copyright 2019 Raptor Engineering, LLC
-#
-# Permission is hereby granted, free of charge, to any person obtaining a
-# copy of this software and associated documentation files (the "Software"),
-# to deal in the Software without restriction, including without limitation
-# the rights to use, copy, modify, merge, publish, distribute, sublicense,
-# and/or sell copies of the Software, and to permit persons to whom the
-# Software is furnished to do so, subject to the following conditions:
-#
-# The above copyright notice and this permission notice shall be included in
-# all copies or substantial portions of the Software.
-#
-# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
-# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
-# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
-# THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
-# OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
-# ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
-# OTHER DEALINGS IN THE SOFTWARE.
-#
-#
-# Makefile for the 'calcs' sub-component of DAL.
-# It calculates Bandwidth and Watermarks values for HW programming
-#
-
-ifdef CONFIG_X86
-calcs_ccflags := -mhard-float -msse
-endif
-
-ifdef CONFIG_PPC64
-calcs_ccflags := -mhard-float -maltivec
-endif
-
-ifdef CONFIG_CC_IS_GCC
-ifeq ($(call cc-ifversion, -lt, 0701, y), y)
-IS_OLD_GCC = 1
-endif
-endif
-
-ifdef CONFIG_X86
-ifdef IS_OLD_GCC
-# Stack alignment mismatch, proceed with caution.
-# GCC < 7.1 cannot compile code using `double` and -mpreferred-stack-boundary=3
-# (8B stack alignment).
-calcs_ccflags += -mpreferred-stack-boundary=4
-else
-calcs_ccflags += -msse2
-endif
-endif
-
-CFLAGS_$(AMDDALPATH)/dc/calcs/dcn_calcs.o := $(calcs_ccflags)
-CFLAGS_$(AMDDALPATH)/dc/calcs/dcn_calc_auto.o := $(calcs_ccflags)
-CFLAGS_$(AMDDALPATH)/dc/calcs/dcn_calc_math.o := $(calcs_ccflags)
-Wno-tautological-compare
-CFLAGS_REMOVE_$(AMDDALPATH)/dc/calcs/dcn_calcs.o := $(calcs_rcflags)
-CFLAGS_REMOVE_$(AMDDALPATH)/dc/calcs/dcn_calc_auto.o := $(calcs_rcflags)
-CFLAGS_REMOVE_$(AMDDALPATH)/dc/calcs/dcn_calc_math.o := $(calcs_rcflags)
-
-BW_CALCS = dce_calcs.o bw_fixed.o custom_float.o
-
-ifdef CONFIG_DRM_AMD_DC_DCN
-BW_CALCS += dcn_calcs.o dcn_calc_math.o dcn_calc_auto.o
-endif
-
-AMD_DAL_BW_CALCS = $(addprefix $(AMDDALPATH)/dc/calcs/,$(BW_CALCS))
-
Re: [PATCH] drm/amdkfd: use default_groups in kobj_type
On Thu, Jan 6, 2022 at 4:57 AM Greg Kroah-Hartman
wrote:
>
> There are currently 2 ways to create a set of sysfs files for a
> kobj_type, through the default_attrs field, and the default_groups
> field. Move the amdkfd sysfs code to use default_groups field which has
> been the preferred way since aa30f47cf666 ("kobject: Add support for
> default attribute groups to kobj_type") so that we can soon get rid of
> the obsolete default_attrs field.
>
> Cc: Felix Kuehling
> Cc: Alex Deucher
> Cc: "Christian König"
> Cc: "Pan, Xinhui"
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: amd-gfx@lists.freedesktop.org
> Cc: dri-de...@lists.freedesktop.org
> Signed-off-by: Greg Kroah-Hartman
Applied. Thanks!
Alex
> ---
> drivers/gpu/drm/amd/amdkfd/kfd_process.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_process.c
> b/drivers/gpu/drm/amd/amdkfd/kfd_process.c
> index b993011cfa64..1f4a07f984eb 100644
> --- a/drivers/gpu/drm/amd/amdkfd/kfd_process.c
> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_process.c
> @@ -462,6 +462,7 @@ static struct attribute *procfs_queue_attrs[] = {
> _queue_gpuid,
> NULL
> };
> +ATTRIBUTE_GROUPS(procfs_queue);
>
> static const struct sysfs_ops procfs_queue_ops = {
> .show = kfd_procfs_queue_show,
> @@ -469,7 +470,7 @@ static const struct sysfs_ops procfs_queue_ops = {
>
> static struct kobj_type procfs_queue_type = {
> .sysfs_ops = _queue_ops,
> - .default_attrs = procfs_queue_attrs,
> + .default_groups = procfs_queue_groups,
> };
>
> static const struct sysfs_ops procfs_stats_ops = {
> --
> 2.34.1
>
Re: [PATCH] drm/amdgpu: use default_groups in kobj_type
On Thu, Jan 6, 2022 at 4:56 AM Greg Kroah-Hartman
wrote:
>
> There are currently 2 ways to create a set of sysfs files for a
> kobj_type, through the default_attrs field, and the default_groups
> field. Move the amdgpu sysfs code to use default_groups field which has
> been the preferred way since aa30f47cf666 ("kobject: Add support for
> default attribute groups to kobj_type") so that we can soon get rid of
> the obsolete default_attrs field.
>
> Cc: Alex Deucher
> Cc: "Christian König"
> Cc: "Pan, Xinhui"
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: Hawking Zhang
> Cc: John Clements
> Cc: Felix Kuehling
> Cc: Jonathan Kim
> Cc: Kevin Wang
> Cc: shaoyunl
> Cc: Tao Zhou
> Cc: amd-gfx@lists.freedesktop.org
> Cc: dri-de...@lists.freedesktop.org
> Signed-off-by: Greg Kroah-Hartman
Applied. Thanks!
Alex
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c
> index 567df2db23ac..94dcb004988d 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c
> @@ -208,6 +208,7 @@ static struct attribute *amdgpu_xgmi_hive_attrs[] = {
> _xgmi_hive_id,
> NULL
> };
> +ATTRIBUTE_GROUPS(amdgpu_xgmi_hive);
>
> static ssize_t amdgpu_xgmi_show_attrs(struct kobject *kobj,
> struct attribute *attr, char *buf)
> @@ -237,7 +238,7 @@ static const struct sysfs_ops amdgpu_xgmi_hive_ops = {
> struct kobj_type amdgpu_xgmi_hive_type = {
> .release = amdgpu_xgmi_hive_release,
> .sysfs_ops = _xgmi_hive_ops,
> - .default_attrs = amdgpu_xgmi_hive_attrs,
> + .default_groups = amdgpu_xgmi_hive_groups,
> };
>
> static ssize_t amdgpu_xgmi_show_device_id(struct device *dev,
> --
> 2.34.1
>
Re: [PATCH] Revert "i2c: core: support bus regulator controlling in adapter"
On Thu, Jan 06, 2022 at 01:24:52PM +0100, Wolfram Sang wrote: > This largely reverts commit 5a7b95fb993ec399c8a685552aa6a8fc995c40bd. It > breaks suspend with AMD GPUs, and we couldn't incrementally fix it. So, > let's remove the code and go back to the drawing board. We keep the > header extension to not break drivers already populating the regulator. > We expect to re-add the code handling it soon. > > Reported-by: "Tareque Md.Hanif" > Link: https://lore.kernel.org/r/1295184560.182511.1639075777...@mail.yahoo.com > Reported-by: Konstantin Kharlamov > Link: > https://lore.kernel.org/r/7143a7147978f4104171072d9f5225d2ce355ec1.ca...@yandex.ru > BugLink: https://gitlab.freedesktop.org/drm/amd/-/issues/1850 > Signed-off-by: Wolfram Sang Applied to for-current, thanks! signature.asc Description: PGP signature
Re: [PATCH] Revert "i2c: core: support bus regulator controlling in adapter"
> Tested-by: Konstantin Kharlamov Thanks! > By the way, shouldn't the patch include a field > > Cc: # 5.14+ Yes, but I add such lines only when applying to my tree. If I add it when sending out patches, the mail gets CCed to stable although the patch is not upstream yet. signature.asc Description: PGP signature
Re: [PATCH] drm/radeon: use kernel is_power_of_2 rather than local version
Applied. Thanks!
Alex
On Thu, Dec 30, 2021 at 11:32 AM Christian König
wrote:
>
> Am 30.12.21 um 06:00 schrieb Jonathan Gray:
> > Follow the amdgpu change made in
> > 7611750784664db46d0db95631e322aeb263dde7
> > and replace local radeon function with is_power_of_2().
> >
> > Signed-off-by: Jonathan Gray
>
> Reviewed-by: Christian König
>
> > ---
> > drivers/gpu/drm/radeon/radeon_device.c | 19 +++
> > 1 file changed, 3 insertions(+), 16 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/radeon/radeon_device.c
> > b/drivers/gpu/drm/radeon/radeon_device.c
> > index 4f0fbf667431..15692cb241fc 100644
> > --- a/drivers/gpu/drm/radeon/radeon_device.c
> > +++ b/drivers/gpu/drm/radeon/radeon_device.c
> > @@ -1085,19 +1085,6 @@ static unsigned int radeon_vga_set_decode(struct
> > pci_dev *pdev, bool state)
> > return VGA_RSRC_NORMAL_IO | VGA_RSRC_NORMAL_MEM;
> > }
> >
> > -/**
> > - * radeon_check_pot_argument - check that argument is a power of two
> > - *
> > - * @arg: value to check
> > - *
> > - * Validates that a certain argument is a power of two (all asics).
> > - * Returns true if argument is valid.
> > - */
> > -static bool radeon_check_pot_argument(int arg)
> > -{
> > - return (arg & (arg - 1)) == 0;
> > -}
> > -
> > /**
> >* radeon_gart_size_auto - Determine a sensible default GART size
> >* according to ASIC family.
> > @@ -1126,7 +1113,7 @@ static int radeon_gart_size_auto(enum radeon_family
> > family)
> > static void radeon_check_arguments(struct radeon_device *rdev)
> > {
> > /* vramlimit must be a power of two */
> > - if (!radeon_check_pot_argument(radeon_vram_limit)) {
> > + if (!is_power_of_2(radeon_vram_limit)) {
> > dev_warn(rdev->dev, "vram limit (%d) must be a power of 2\n",
> > radeon_vram_limit);
> > radeon_vram_limit = 0;
> > @@ -1140,7 +1127,7 @@ static void radeon_check_arguments(struct
> > radeon_device *rdev)
> > dev_warn(rdev->dev, "gart size (%d) too small\n",
> > radeon_gart_size);
> > radeon_gart_size = radeon_gart_size_auto(rdev->family);
> > - } else if (!radeon_check_pot_argument(radeon_gart_size)) {
> > + } else if (!is_power_of_2(radeon_gart_size)) {
> > dev_warn(rdev->dev, "gart size (%d) must be a power of 2\n",
> > radeon_gart_size);
> > radeon_gart_size = radeon_gart_size_auto(rdev->family);
> > @@ -1163,7 +1150,7 @@ static void radeon_check_arguments(struct
> > radeon_device *rdev)
> > break;
> > }
> >
> > - if (!radeon_check_pot_argument(radeon_vm_size)) {
> > + if (!is_power_of_2(radeon_vm_size)) {
> > dev_warn(rdev->dev, "VM size (%d) must be a power of 2\n",
> >radeon_vm_size);
> > radeon_vm_size = 4;
>
Re: [PATCH v2] drm/amd/display: move calcs folder into DML
Hi Isabelle,
Using the dml makefile for everything sounds better to me.
Could you send the v3 version using your way to me?
Regards,
Jasdeep
From: Isabella Basso
Sent: January 3, 2022 2:52 PM
To: Dhillon, Jasdeep
Cc: Deucher, Alexander ; Koenig, Christian
; dan...@ffwll.ch ; Wentland, Harry
; Siqueira, Rodrigo ; Li, Sun
peng (Leo) ; Pan, Xinhui ; Zhuo,
Qingqing (Lillian) ; m...@igalia.com ;
amd-gfx@lists.freedesktop.org ;
~lkcamp/patc...@lists.sr.ht <~lkcamp/patc...@lists.sr.ht>
Subject: Re: [PATCH v2] drm/amd/display: move calcs folder into DML
Hello, Jasdeep,
On 2021-12-23 17:44, Dhillon, Jasdeep wrote:
> [AMD Official Use Only]
>
> Hi Isabbasso,
>
> The patch fails to compile when there is No DCN because the calc
> object files fail to generate since dml depends on the
> CONFIG_DRM_AMD_DC_DCN being enabled (Makefile inside dc folder):
>
> ifdef CONFIG_DRM_AMD_DC_DCN
> DC_LIBS += dcn20
> DC_LIBS += dsc
> DC_LIBS += dcn10 dml
> DC_LIBS += dcn21
> DC_LIBS += dcn30
> DC_LIBS += dcn301
> DC_LIBS += dcn302
> DC_LIBS += dcn303 endif
>
> A few changes need to be made to the patch, which are:
>
> -The Makefile in dc needs the line: DC_LIBS+= dml/calcs
> -the Makefile in the calcs folder that the patch deletes can be
> placed inside of dc/dml/calcs instead of adding it to the Makefiles in
> dc/dml
>
Siqueira had warned me of this issue just before you emailed me, so I'd
already
prepared a v3 with no calcs Makefile but actually using the dml one for
everything, as it's pretty much set up for working with or without the
DRM_AMD_DC_DCN config turned on. Would this be alright, or would you
rather
have it as you suggested?
>From what I tested locally both work pretty much the same. I think my
solution
is a little harder to test but ends up being a little more compact,
which might
translate into being more maintainable (maybe?).
Please let me know what you think :).
Cheers,
--
Isabella Basso
> Could you revise your patch based on these changes.
>
> Regards,
> Jasdeep
>
> -
>
> From: isabba...@riseup.net
> Sent: December 20, 2021 6:23 PM
> To: Deucher, Alexander ; Koenig, Christian
> ; dan...@ffwll.ch ;
> Wentland, Harry ; Siqueira, Rodrigo
> ; Li, Sun peng (Leo) ;
> Pan, Xinhui ; Zhuo, Qingqing (Lillian)
> ; Dhillon, Jasdeep ;
> m...@igalia.com
> Cc: amd-gfx@lists.freedesktop.org ;
> ~lkcamp/patc...@lists.sr.ht <~lkcamp/patc...@lists.sr.ht>
> Subject: Re: [PATCH v2] drm/amd/display: move calcs folder into DML
>
> On 2021-12-20 20:20, Isabella Basso wrote:
>> The calcs folder has FPU code on it, which should be isolated inside
> the
>> DML folder as per
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.freedesktop.org%2Fseries%2F93042%2Fdata=04%7C01%7CJasdeep.Dhillon%40amd.com%7C8a3d537d1fb64bac26c308d9cef28d37%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637768363894413584%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=rpKQjmK4atQn0U3RMCmkMTe9Yyj0dq4YDBhQeA48lyM%3Dreserved=0
> [1].
>>
>> This commit aims single-handedly to correct the location of such FPU
>> code and does not refactor any functions.
>>
>> Signed-off-by: Isabella Basso
>> ---
>> drivers/gpu/drm/amd/display/dc/Makefile | 2 +-
>> drivers/gpu/drm/amd/display/dc/calcs/Makefile | 68
> ---
>> drivers/gpu/drm/amd/display/dc/dml/Makefile | 13 +++-
>> .../amd/display/dc/{ => dml}/calcs/bw_fixed.c | 0
>> .../display/dc/{ => dml}/calcs/calcs_logger.h | 0
>> .../display/dc/{ => dml}/calcs/custom_float.c | 0
>> .../display/dc/{ => dml}/calcs/dce_calcs.c| 0
>> .../dc/{ => dml}/calcs/dcn_calc_auto.c| 0
>> .../dc/{ => dml}/calcs/dcn_calc_auto.h| 0
>> .../dc/{ => dml}/calcs/dcn_calc_math.c| 0
>> .../display/dc/{ => dml}/calcs/dcn_calcs.c| 0
>> 11 files changed, 13 insertions(+), 70 deletions(-)
>> delete mode 100644 drivers/gpu/drm/amd/display/dc/calcs/Makefile
>> rename drivers/gpu/drm/amd/display/dc/{ => dml}/calcs/bw_fixed.c
> (100%)
>> rename drivers/gpu/drm/amd/display/dc/{ =>
> dml}/calcs/calcs_logger.h (100%)
>> rename drivers/gpu/drm/amd/display/dc/{ =>
> dml}/calcs/custom_float.c (100%)
>> rename drivers/gpu/drm/amd/display/dc/{ => dml}/calcs/dce_calcs.c
> (100%)
>> rename drivers/gpu/drm/amd/display/dc/{ =>
> dml}/calcs/dcn_calc_auto.c (100%)
>> rename drivers/gpu/drm/amd/display/dc/{ =>
> dml}/calcs/dcn_calc_auto.h (100%)
>> rename drivers/gpu/drm/amd/display/dc/{ =>
> dml}/calcs/dcn_calc_math.c (100%)
>> rename drivers/gpu/drm/amd/display/dc/{ => dml}/calcs/dcn_calcs.c
> (100%)
>>
>> diff --git a/drivers/gpu/drm/amd/display/dc/Makefile
>> b/drivers/gpu/drm/amd/display/dc/Makefile
>> index b1f0d6260226..1872adc96a00 100644
>> --- a/drivers/gpu/drm/amd/display/dc/Makefile
>> +++ b/drivers/gpu/drm/amd/display/dc/Makefile
>> @@ -23,7 +23,7 @@
>> # Makefile for Display Core (dc) component.
>> #
>>
>> -DC_LIBS
Re: [PATCH 2/4] drm/amdkfd: remove unused function
I think this is still used on the DKMS branch. But it's fine upstream.
Thanks for catching this.
Reviewed-by: Felix Kuehling
Regards,
Felix
Am 2022-01-07 um 5:18 a.m. schrieb Nirmoy:
> Found the commit that removed usages of this function.
>
>
> Fixes: dfcbe6d5f ("drm/amdgpu: Remove unused function pointers")
>
> On 1/7/22 09:51, Nirmoy Das wrote:
>> Remove unused amdgpu_amdkfd_get_vram_usage()
>>
>> CC: felix.kuehl...@amd.com
>>
>> Signed-off-by: Nirmoy Das
>> ---
>> drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c | 7 ---
>> drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h | 1 -
>> 2 files changed, 8 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
>> index 776a947b45df..6ca1db3c243f 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
>> @@ -514,13 +514,6 @@ int amdgpu_amdkfd_get_dmabuf_info(struct
>> amdgpu_device *adev, int dma_buf_fd,
>> return r;
>> }
>>
>> -uint64_t amdgpu_amdkfd_get_vram_usage(struct amdgpu_device *adev)
>> -{
>> - struct ttm_resource_manager *vram_man =
>> ttm_manager_type(>mman.bdev, TTM_PL_VRAM);
>> -
>> - return amdgpu_vram_mgr_usage(vram_man);
>> -}
>> -
>> uint8_t amdgpu_amdkfd_get_xgmi_hops_count(struct amdgpu_device *dst,
>> struct amdgpu_device *src)
>> {
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
>> index 61f899e54fd5..ac841ae8f5cc 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
>> @@ -223,7 +223,6 @@ int amdgpu_amdkfd_get_dmabuf_info(struct
>> amdgpu_device *adev, int dma_buf_fd,
>> uint64_t *bo_size, void *metadata_buffer,
>> size_t buffer_size, uint32_t *metadata_size,
>> uint32_t *flags);
>> -uint64_t amdgpu_amdkfd_get_vram_usage(struct amdgpu_device *adev);
>> uint8_t amdgpu_amdkfd_get_xgmi_hops_count(struct amdgpu_device *dst,
>> struct amdgpu_device *src);
>> int amdgpu_amdkfd_get_xgmi_bandwidth_mbytes(struct amdgpu_device *dst,
>> --
>> 2.33.1
>>
RE: [PATCH v5] drm/amd/display: Revert W/A for hard hangs on DCN20/DCN21
[AMD Official Use Only]
> I think the revert is fine once we figure out where we're missing calls to:
>
> .optimize_pwr_state = dcn21_optimize_pwr_state,
> .exit_optimized_pwr_state = dcn21_exit_optimized_pwr_state,
>
> These are already part of dc_link_detect, so I suspect there's another
> interface
> in DC that should be using these.
>
> I think the best way to debug this is to revert the patch locally and add a
> stack
> dump when DMCUB hangs our times out.
OK so I did this on top of amd-staging-drm-next with my v5 patch (this revert
in place)
diff --git a/drivers/gpu/drm/amd/display/dmub/src/dmub_srv.c
b/drivers/gpu/drm/amd/display/dmub/src/dmub_srv.c
index 9280f2abd973..0bd32f82f3db 100644
--- a/drivers/gpu/drm/amd/display/dmub/src/dmub_srv.c
+++ b/drivers/gpu/drm/amd/display/dmub/src/dmub_srv.c
@@ -789,8 +789,10 @@ enum dmub_status dmub_srv_cmd_with_reply_data(struct
dmub_srv *dmub,
// Execute command
status = dmub_srv_cmd_execute(dmub);
- if (status != DMUB_STATUS_OK)
+ if (status != DMUB_STATUS_OK) {
+ ASSERT(0);
return status;
+ }
// Wait for DMUB to process command
status = dmub_srv_wait_for_idle(dmub, 10);
>
> That way you can know where the PHY was trying to be accessed without the
> refclk being on.
>
> We had a similar issue in DCN31 which didn't require a W/A like DCN21.
>
> I'd like to hold off on merging this until that hang is verified as gone.
>
Then I took a RN laptop running DMUB 0x01010019 and disabled eDP, and confirmed
no CRTC was configured but plugged in an HDMI cable:
connector[78]: eDP-1
crtc=(null)
self_refresh_aware=0
connector[85]: HDMI-A-1
crtc=crtc-1
self_refresh_aware=0
I triggered 100 hotplugs like this:
#!/bin/bash
for i in {0..100..1}
do
echo 1 | tee /sys/kernel/debug/dri/0/HDMI-A-1/trigger_hotplug
sleep 3
done
Unfortunately, no hang or traceback to be seen (and HDMI continues to work).
I also manually pulled the plug a handful of times I don't know the specifics
that Lillian had the
failure though, so this might not be a good enough check.
I'll try to upgrade DMUB to 0x101001c (the latest version) and double check
that as well.
Re: [PATCH v2] drm/amd/display: explicitly update clocks when DC is set to D3 in s0i3
Hi, this is your Linux kernel regression tracker speaking.
On 05.01.22 18:06, Mario Limonciello wrote:
> The WA from commit 5965280abd30 ("drm/amd/display: Apply w/a for
> hard hang on HPD") causes a regression in s0ix where the system will
> fail to resume properly. This may be because an HPD was active the last
> time clocks were updated but clocks didn't get updated again during s0ix.
>
> So add an extra call to update clocks as part of the suspend routine:
> dm_suspend->dc_set_power_state->clk_mgr_optimize_pwr_state
>
> In case HPD is set during this time, also check if the call happened during
> suspend to allow overriding the WA.
Thx for this. Our of interest: is that something that should still go
into v5.16?
> Cc: Qingqing Zhuo
> Reported-by: Scott Bruce
> Reported-by: Chris Hixon
> Reported-by: spassw...@web.de
> BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=215436
> BugLink: https://gitlab.freedesktop.org/drm/amd/-/issues/1821
> BugLink: https://gitlab.freedesktop.org/drm/amd/-/issues/1852
What is "BugLink"? It's not mention in the kernel's documentation, which
tells people to use "Link:" for linking to bug reports:
https://www.kernel.org/doc/html/latest/process/submitting-patches.html
That is not new, bug recently was made more explicit.
Hence, please consider changing them to "Link:", there are tools out
there that repy on them (I'm running such a tool, but there might be
others out there we are not aware of).
FWIW, in principe I agree that we need a seperate tag for this. But then
we should get this discussed and blessed through the usual channels.
That's why I recently proposed "Reported:", without much success so far:
https://lore.kernel.org/lkml/c6724c7fb534a46e095e6aef13d996ed9589e578.1639042966.git.li...@leemhuis.info/
Ciao, Thorsten
> Fixes: 5965280abd30 ("drm/amd/display: Apply w/a for hard hang on HPD")
> Fixes: 1bd3bc745e7f ("drm/amd/display: Extend w/a for hard hang on HPD to
> dcn20")
> Signed-off-by: Mario Limonciello
> ---
> changes from v1->v2:
> * Add fallthrough statement
> * Extend case to check if call was explicitly in s0ix since #1852 showed
> hpd_state
>can be set at this time too
> * Adjust commit message and title
> * Add extra commit and bug fixed to metadata
> drivers/gpu/drm/amd/display/dc/clk_mgr/dcn21/rn_clk_mgr.c | 5 -
> drivers/gpu/drm/amd/display/dc/core/dc.c | 3 +++
> 2 files changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn21/rn_clk_mgr.c
> b/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn21/rn_clk_mgr.c
> index fbda42313bfe..fa5efe10b779 100644
> --- a/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn21/rn_clk_mgr.c
> +++ b/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn21/rn_clk_mgr.c
> @@ -23,6 +23,8 @@
> *
> */
>
> +#include "amdgpu.h"
> +
> #include "dccg.h"
> #include "clk_mgr_internal.h"
>
> @@ -126,6 +128,7 @@ static void rn_update_clocks(struct clk_mgr *clk_mgr_base,
> bool safe_to_lower)
> {
> struct clk_mgr_internal *clk_mgr = TO_CLK_MGR_INTERNAL(clk_mgr_base);
> + struct amdgpu_device *adev = clk_mgr_base->ctx->driver_context;
> struct dc_clocks *new_clocks = >bw_ctx.bw.dcn.clk;
> struct dc *dc = clk_mgr_base->ctx->dc;
> int display_count;
> @@ -157,7 +160,7 @@ static void rn_update_clocks(struct clk_mgr *clk_mgr_base,
> }
>
> /* if we can go lower, go lower */
> - if (display_count == 0 && !hpd_state) {
> + if (display_count == 0 && (adev->in_s0ix ||
> !hpd_state)) {
> rn_vbios_smu_set_dcn_low_power_state(clk_mgr,
> DCN_PWR_STATE_LOW_POWER);
> /* update power state */
> clk_mgr_base->clks.pwr_state =
> DCN_PWR_STATE_LOW_POWER;
> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c
> b/drivers/gpu/drm/amd/display/dc/core/dc.c
> index 91c4874473d6..8e0c820f6892 100644
> --- a/drivers/gpu/drm/amd/display/dc/core/dc.c
> +++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
> @@ -3299,6 +3299,9 @@ void dc_set_power_state(
> }
>
> break;
> + case DC_ACPI_CM_POWER_STATE_D3:
> + clk_mgr_optimize_pwr_state(dc, dc->clk_mgr);
> + fallthrough;
> default:
> ASSERT(dc->current_state->stream_count == 0);
> /* Zero out the current context so that on resume we start with
Re: [PATCH] Revert "i2c: core: support bus regulator controlling in adapter"
Thank you! I tested it (had to resolve a small conflict), works for me. So, in
case you need it, the patch is
Tested-by: Konstantin Kharlamov
By the way, shouldn't the patch include a field
Cc: # 5.14+
?
P.S.: sorry, for all mangled up CC fields. For some reason I didn't get your
email, I found this patch in the archive. And the mbox that archive provides
breaks all TO and CC fields, so I manually restored addresses that I have.
On Thu, 2022-01-06 at 12:24 +, Wolfram Sang wrote:
> This largely reverts commit 5a7b95fb993ec399c8a685552aa6a8fc995c40bd. It
> breaks suspend with AMD GPUs, and we couldn't incrementally fix it. So,
> let's remove the code and go back to the drawing board. We keep the
> header extension to not break drivers already populating the regulator.
> We expect to re-add the code handling it soon.
>
> Reported-by: "Tareque Md.Hanif"
> Link: https://lore.kernel.org/r/1295184560.182511.1639075777...@mail.yahoo.com
> Reported-by: Konstantin Kharlamov
> Link:
> https://lore.kernel.org/r/7143a7147978f4104171072d9f5225d2ce355ec1.ca...@yandex.ru
> BugLink: https://gitlab.freedesktop.org/drm/amd/-/issues/1850
> Signed-off-by: Wolfram Sang
> ---
>
> So far, I tested it on a Renesas R-Car M3-N board verifying that I2C
> still works. I'll apply it to my for-next branch right away to get the
> buildbots involved as well. But I am still open for comments until I
> apply it to my for-current branch, probably tomorrow.
>
> drivers/i2c/i2c-core-base.c | 95 -
> 1 file changed, 95 deletions(-)
>
> diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c
> index f193f9058584..73253e667de1 100644
> --- a/drivers/i2c/i2c-core-base.c
> +++ b/drivers/i2c/i2c-core-base.c
> @@ -466,14 +466,12 @@ static int i2c_smbus_host_notify_to_irq(const struct
> i2c_client *client)
> static int i2c_device_probe(struct device *dev)
> {
> struct i2c_client *client = i2c_verify_client(dev);
> - struct i2c_adapter *adap;
> struct i2c_driver *driver;
> int status;
>
> if (!client)
> return 0;
>
> - adap = client->adapter;
> client->irq = client->init_irq;
>
> if (!client->irq) {
> @@ -539,14 +537,6 @@ static int i2c_device_probe(struct device *dev)
>
> dev_dbg(dev, "probe\n");
>
> - if (adap->bus_regulator) {
> - status = regulator_enable(adap->bus_regulator);
> - if (status < 0) {
> - dev_err(>dev, "Failed to enable bus
> regulator\n");
> - goto err_clear_wakeup_irq;
> - }
> - }
> -
> status = of_clk_set_defaults(dev->of_node, false);
> if (status < 0)
> goto err_clear_wakeup_irq;
> @@ -605,10 +595,8 @@ static int i2c_device_probe(struct device *dev)
> static void i2c_device_remove(struct device *dev)
> {
> struct i2c_client *client = to_i2c_client(dev);
> - struct i2c_adapter *adap;
> struct i2c_driver *driver;
>
> - adap = client->adapter;
> driver = to_i2c_driver(dev->driver);
> if (driver->remove) {
> int status;
> @@ -623,8 +611,6 @@ static void i2c_device_remove(struct device *dev)
> devres_release_group(>dev, client->devres_group_id);
>
> dev_pm_domain_detach(>dev, !i2c_acpi_waive_d0_probe(dev));
> - if (!pm_runtime_status_suspended(>dev) && adap->bus_regulator)
> - regulator_disable(adap->bus_regulator);
>
> dev_pm_clear_wake_irq(>dev);
> device_init_wakeup(>dev, false);
> @@ -634,86 +620,6 @@ static void i2c_device_remove(struct device *dev)
> pm_runtime_put(>adapter->dev);
> }
>
> -#ifdef CONFIG_PM_SLEEP
> -static int i2c_resume_early(struct device *dev)
> -{
> - struct i2c_client *client = i2c_verify_client(dev);
> - int err;
> -
> - if (!client)
> - return 0;
> -
> - if (pm_runtime_status_suspended(>dev) &&
> - client->adapter->bus_regulator) {
> - err = regulator_enable(client->adapter->bus_regulator);
> - if (err)
> - return err;
> - }
> -
> - return pm_generic_resume_early(>dev);
> -}
> -
> -static int i2c_suspend_late(struct device *dev)
> -{
> - struct i2c_client *client = i2c_verify_client(dev);
> - int err;
> -
> - if (!client)
> - return 0;
> -
> - err = pm_generic_suspend_late(>dev);
> - if (err)
> - return err;
> -
> - if (!pm_runtime_status_suspended(>dev) &&
> - client->adapter->bus_regulator)
> - return regulator_disable(client->adapter->bus_regulator);
> -
> - return 0;
> -}
> -#endif
> -
> -#ifdef CONFIG_PM
> -static int i2c_runtime_resume(struct device *dev)
> -{
> - struct i2c_client *client =
[PATCH] drm/amdgpu: use default_groups in kobj_type
There are currently 2 ways to create a set of sysfs files for a
kobj_type, through the default_attrs field, and the default_groups
field. Move the amdgpu sysfs code to use default_groups field which has
been the preferred way since aa30f47cf666 ("kobject: Add support for
default attribute groups to kobj_type") so that we can soon get rid of
the obsolete default_attrs field.
Cc: Alex Deucher
Cc: "Christian König"
Cc: "Pan, Xinhui"
Cc: David Airlie
Cc: Daniel Vetter
Cc: Hawking Zhang
Cc: John Clements
Cc: Felix Kuehling
Cc: Jonathan Kim
Cc: Kevin Wang
Cc: shaoyunl
Cc: Tao Zhou
Cc: amd-gfx@lists.freedesktop.org
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c
index 567df2db23ac..94dcb004988d 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c
@@ -208,6 +208,7 @@ static struct attribute *amdgpu_xgmi_hive_attrs[] = {
_xgmi_hive_id,
NULL
};
+ATTRIBUTE_GROUPS(amdgpu_xgmi_hive);
static ssize_t amdgpu_xgmi_show_attrs(struct kobject *kobj,
struct attribute *attr, char *buf)
@@ -237,7 +238,7 @@ static const struct sysfs_ops amdgpu_xgmi_hive_ops = {
struct kobj_type amdgpu_xgmi_hive_type = {
.release = amdgpu_xgmi_hive_release,
.sysfs_ops = _xgmi_hive_ops,
- .default_attrs = amdgpu_xgmi_hive_attrs,
+ .default_groups = amdgpu_xgmi_hive_groups,
};
static ssize_t amdgpu_xgmi_show_device_id(struct device *dev,
--
2.34.1
[PATCH 0/2]
For adapting radeon rx6600 xt on arm64 platform, there report some compile errors. Zhenneng Li (2): drm/amdgpu: fix compile error for dcn on arm64 drm/amdgpu: enable dcn support on arm64 drivers/gpu/drm/amd/display/Kconfig | 2 +- drivers/gpu/drm/amd/display/dc/calcs/Makefile | 6 + .../gpu/drm/amd/display/dc/clk_mgr/Makefile | 7 ++ drivers/gpu/drm/amd/display/dc/dcn10/Makefile | 4 +++ drivers/gpu/drm/amd/display/dc/dcn20/Makefile | 4 +++ .../gpu/drm/amd/display/dc/dcn201/Makefile| 6 + drivers/gpu/drm/amd/display/dc/dcn21/Makefile | 4 +++ drivers/gpu/drm/amd/display/dc/dcn30/Makefile | 6 + .../gpu/drm/amd/display/dc/dcn302/Makefile| 6 + .../gpu/drm/amd/display/dc/dcn303/Makefile| 6 + drivers/gpu/drm/amd/display/dc/dcn31/Makefile | 6 + drivers/gpu/drm/amd/display/dc/dml/Makefile | 25 +++ drivers/gpu/drm/amd/display/dc/dsc/Makefile | 7 ++ 13 files changed, 88 insertions(+), 1 deletion(-) -- 2.25.1 No virus found Checked by Hillstone Network AntiVirus
[PATCH 1/2] drm/amdgpu: fix compile error for dcn on arm64
For adapting radeon rx6600 xt on arm64, I enabled dcn on arm64 platform, compiler report not compatible with -mgeneral-regs-only and -mhard-float when compiling some source file. Signed-off-by: Zhenneng Li --- drivers/gpu/drm/amd/display/dc/calcs/Makefile | 6 + .../gpu/drm/amd/display/dc/clk_mgr/Makefile | 7 ++ drivers/gpu/drm/amd/display/dc/dcn10/Makefile | 4 +++ drivers/gpu/drm/amd/display/dc/dcn20/Makefile | 4 +++ .../gpu/drm/amd/display/dc/dcn201/Makefile| 6 + drivers/gpu/drm/amd/display/dc/dcn21/Makefile | 4 +++ drivers/gpu/drm/amd/display/dc/dcn30/Makefile | 6 + .../gpu/drm/amd/display/dc/dcn302/Makefile| 6 + .../gpu/drm/amd/display/dc/dcn303/Makefile| 6 + drivers/gpu/drm/amd/display/dc/dcn31/Makefile | 6 + drivers/gpu/drm/amd/display/dc/dml/Makefile | 25 +++ drivers/gpu/drm/amd/display/dc/dsc/Makefile | 7 ++ 12 files changed, 87 insertions(+) diff --git a/drivers/gpu/drm/amd/display/dc/calcs/Makefile b/drivers/gpu/drm/amd/display/dc/calcs/Makefile index f3c00f479e1c..1cb9925d9949 100644 --- a/drivers/gpu/drm/amd/display/dc/calcs/Makefile +++ b/drivers/gpu/drm/amd/display/dc/calcs/Makefile @@ -57,6 +57,12 @@ CFLAGS_REMOVE_$(AMDDALPATH)/dc/calcs/dcn_calcs.o := $(calcs_rcflags) CFLAGS_REMOVE_$(AMDDALPATH)/dc/calcs/dcn_calc_auto.o := $(calcs_rcflags) CFLAGS_REMOVE_$(AMDDALPATH)/dc/calcs/dcn_calc_math.o := $(calcs_rcflags) +ifdef CONFIG_ARM64 +CFLAGS_REMOVE_$(AMDDALPATH)/dc/calcs/dcn_calcs.o += -mgeneral-regs-only +CFLAGS_REMOVE_$(AMDDALPATH)/dc/calcs/dcn_calc_auto.o += -mgeneral-regs-only +CFLAGS_REMOVE_$(AMDDALPATH)/dc/calcs/dcn_calc_math.o += -mgeneral-regs-only +endif + BW_CALCS = dce_calcs.o bw_fixed.o custom_float.o ifdef CONFIG_DRM_AMD_DC_DCN diff --git a/drivers/gpu/drm/amd/display/dc/clk_mgr/Makefile b/drivers/gpu/drm/amd/display/dc/clk_mgr/Makefile index 6bd73e49a6d2..6779c236ea30 100644 --- a/drivers/gpu/drm/amd/display/dc/clk_mgr/Makefile +++ b/drivers/gpu/drm/amd/display/dc/clk_mgr/Makefile @@ -145,6 +145,13 @@ AMD_DAL_CLK_MGR_DCN301 = $(addprefix $(AMDDALPATH)/dc/clk_mgr/dcn301/,$(CLK_MGR_ AMD_DISPLAY_FILES += $(AMD_DAL_CLK_MGR_DCN301) +ifdef CONFIG_ARM64 +CFLAGS_REMOVE_$(AMDDALPATH)/dc/clk_mgr/dcn21/rn_clk_mgr.o += -mgeneral-regs-only +CFLAGS_REMOVE_$(AMDDALPATH)/dc/clk_mgr/dcn301/dcn30_clk_mgr.o += -mgeneral-regs-only +CFLAGS_REMOVE_$(AMDDALPATH)/dc/clk_mgr/dcn301/vg_clk_mgr.o += -mgeneral-regs-only +CFLAGS_REMOVE_$(AMDDALPATH)/dc/clk_mgr/dcn30/dcn30_clk_mgr.o += -mgeneral-regs-only +endif + ### # DCN31 ### diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/Makefile b/drivers/gpu/drm/amd/display/dc/dcn10/Makefile index 62ad1a11bff9..5dc61ea5070c 100644 --- a/drivers/gpu/drm/amd/display/dc/dcn10/Makefile +++ b/drivers/gpu/drm/amd/display/dc/dcn10/Makefile @@ -29,6 +29,10 @@ DCN10 = dcn10_init.o dcn10_resource.o dcn10_ipp.o dcn10_hw_sequencer.o \ dcn10_dpp_dscl.o dcn10_dpp_cm.o dcn10_cm_common.o \ dcn10_hubbub.o dcn10_stream_encoder.o dcn10_link_encoder.o +ifdef CONFIG_ARM64 +CFLAGS_REMOVE_$(AMDDALPATH)/dc/dcn10/dcn10_resource.o += -mgeneral-regs-only +endif + AMD_DAL_DCN10 = $(addprefix $(AMDDALPATH)/dc/dcn10/,$(DCN10)) AMD_DISPLAY_FILES += $(AMD_DAL_DCN10) diff --git a/drivers/gpu/drm/amd/display/dc/dcn20/Makefile b/drivers/gpu/drm/amd/display/dc/dcn20/Makefile index 5fcaf78334ff..88c35a24e0cf 100644 --- a/drivers/gpu/drm/amd/display/dc/dcn20/Makefile +++ b/drivers/gpu/drm/amd/display/dc/dcn20/Makefile @@ -17,6 +17,10 @@ ifdef CONFIG_PPC64 CFLAGS_$(AMDDALPATH)/dc/dcn20/dcn20_resource.o := -mhard-float -maltivec endif +ifdef CONFIG_ARM64 +CFLAGS_REMOVE_$(AMDDALPATH)/dc/dcn20/dcn20_resource.o += -mgeneral-regs-only +endif + ifdef CONFIG_CC_IS_GCC ifeq ($(call cc-ifversion, -lt, 0701, y), y) IS_OLD_GCC = 1 diff --git a/drivers/gpu/drm/amd/display/dc/dcn201/Makefile b/drivers/gpu/drm/amd/display/dc/dcn201/Makefile index f68038ceb1b1..2124414d629f 100644 --- a/drivers/gpu/drm/amd/display/dc/dcn201/Makefile +++ b/drivers/gpu/drm/amd/display/dc/dcn201/Makefile @@ -14,12 +14,18 @@ ifdef CONFIG_PPC64 CFLAGS_$(AMDDALPATH)/dc/dcn201/dcn201_resource.o := -mhard-float -maltivec endif +ifdef CONFIG_ARM64 +CFLAGS_REMOVE_$(AMDDALPATH)/dc/dcn201/dcn201_resource.o += -mgeneral-regs-only +endif + ifdef CONFIG_CC_IS_GCC ifeq ($(call cc-ifversion, -lt, 0701, y), y) IS_OLD_GCC = 1 endif +ifndef CONFIG_ARM64 CFLAGS_$(AMDDALPATH)/dc/dcn201/dcn201_resource.o += -mhard-float endif +endif ifdef CONFIG_X86 ifdef IS_OLD_GCC diff --git a/drivers/gpu/drm/amd/display/dc/dcn21/Makefile b/drivers/gpu/drm/amd/display/dc/dcn21/Makefile index bb8c95141082..df8ed3401b7f 100644 --- a/drivers/gpu/drm/amd/display/dc/dcn21/Makefile +++ b/drivers/gpu/drm/amd/display/dc/dcn21/Makefile @@ -30,6 +30,10 @@
[PATCH] drm/amdkfd: use default_groups in kobj_type
There are currently 2 ways to create a set of sysfs files for a
kobj_type, through the default_attrs field, and the default_groups
field. Move the amdkfd sysfs code to use default_groups field which has
been the preferred way since aa30f47cf666 ("kobject: Add support for
default attribute groups to kobj_type") so that we can soon get rid of
the obsolete default_attrs field.
Cc: Felix Kuehling
Cc: Alex Deucher
Cc: "Christian König"
Cc: "Pan, Xinhui"
Cc: David Airlie
Cc: Daniel Vetter
Cc: amd-gfx@lists.freedesktop.org
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/amd/amdkfd/kfd_process.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_process.c
b/drivers/gpu/drm/amd/amdkfd/kfd_process.c
index b993011cfa64..1f4a07f984eb 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_process.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_process.c
@@ -462,6 +462,7 @@ static struct attribute *procfs_queue_attrs[] = {
_queue_gpuid,
NULL
};
+ATTRIBUTE_GROUPS(procfs_queue);
static const struct sysfs_ops procfs_queue_ops = {
.show = kfd_procfs_queue_show,
@@ -469,7 +470,7 @@ static const struct sysfs_ops procfs_queue_ops = {
static struct kobj_type procfs_queue_type = {
.sysfs_ops = _queue_ops,
- .default_attrs = procfs_queue_attrs,
+ .default_groups = procfs_queue_groups,
};
static const struct sysfs_ops procfs_stats_ops = {
--
2.34.1
[PATCH 2/2] drm/amdgpu: enable dcn support on arm64
Signed-off-by: Zhenneng Li --- drivers/gpu/drm/amd/display/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/display/Kconfig b/drivers/gpu/drm/amd/display/Kconfig index 127667e549c1..1c6c4cb1fd0a 100644 --- a/drivers/gpu/drm/amd/display/Kconfig +++ b/drivers/gpu/drm/amd/display/Kconfig @@ -6,7 +6,7 @@ config DRM_AMD_DC bool "AMD DC - Enable new display engine" default y select SND_HDA_COMPONENT if SND_HDA_CORE - select DRM_AMD_DC_DCN if (X86 || PPC64) && !(KCOV_INSTRUMENT_ALL && KCOV_ENABLE_COMPARISONS) + select DRM_AMD_DC_DCN if (X86 || PPC64 || (ARM64 && KERNEL_MODE_NEON)) && !(KCOV_INSTRUMENT_ALL && KCOV_ENABLE_COMPARISONS) help Choose this option if you want to use the new display engine support for AMDGPU. This adds required support for Vega and -- 2.25.1 No virus found Checked by Hillstone Network AntiVirus
Re: [PATCH] drm/ttm: Don't inherit GEM object VMAs in child process
Am 2022-01-07 um 3:56 a.m. schrieb Christian König: > Am 06.01.22 um 17:51 schrieb Felix Kuehling: >> Am 2022-01-06 um 11:48 a.m. schrieb Christian König: >>> Am 06.01.22 um 17:45 schrieb Felix Kuehling: Am 2022-01-06 um 4:05 a.m. schrieb Christian König: [SNIP] Also, why does your ACK or NAK depend on this at all. If it's the right thing to do, it's the right thing to do regardless of who benefits from it. In addition, how can a child process that doesn't even use the GPU be in violation of any GPU-driver related specifications. >>> The argument is that the application is broken and needs to be fixed >>> instead of worked around inside the kernel. >> I still don't get how they the application is broken. Like I said, the >> child process is not using the GPU. How can the application be fixed in >> this case? > > Sounds like I'm still missing some important puzzle pieces for the > full picture to figure out why this doesn't work. > >> Are you saying, any application that forks and doesn't immediately call >> exec is broken? > > More or less yes. We essentially have three possible cases here: > > 1. Application is already using (for example) OpenGL or OpenCL to do > some rendering on the GPU and then calls fork() and expects to use > OpenGL both in the parent and the child at the same time. > As far as I know that's illegal from the Khronos specification > point of view and working around inside the kernel for something not > allowed in the first place is seen as futile effort. > > 2. Application opened the file descriptor, forks and then initializes > OpenGL/Vulkan/OpenCL. > That's what some compositors are doing to drop into the backround > and is explicitly legal. > > 3. Application calls fork() and then doesn't use the GPU in the child. > Either by not using it or calling exec. > That should be legal and not cause any problems in the first place. > > But from your description I still don't get why we are running into > problems here. > > I was assuming that you have case #1 because we previously had some > examples of this with this python library, but from your description > it seems to be case #3. Correct. #3 has at least one issue we previously worked around in the Thunk: The inherited VMAs prevent BOs from being freed in the parent process. This manifests as an apparent memory leak. Therefore the Thunk calls madvise(..., MADV_DONTFORK) on all its VRAM allocation. The BOs that are causing problems with CRIU are GTT BOs that weren't covered by this previous workaround. The new issue with CRIU is, that CRIU saves and restores all the VMAs. When trying to restore the inherited VMAs in the child process, the mmap call fails because the child process' render node FD is no longer inherited from the parent, but is instead created by its own "open" system call. The mmap call in the child fails for at least two reasons: * The child process' render node FD doesn't have permission to map the parent process' BO any more * The parent BO doesn't get restored in the child process, so its mmap offset doesn't get updated to the new mmap offset of the restored parent BO by the amdgpu CRIU plugin We could maybe add a whole bunch of complexity in CRIU and our CRIU plugin to fix this. But it's pointless because like you said, actually doing anything with the BO in the child process is illegal anyway (scenario #1 above). The easiest solution seems to be, to just not inherit the VMA in the first place. Regards, Felix > >> Or does an application that forks need to be aware that some other part >> of the application used the GPU and explicitly free any GPU resources? > > Others might fill that information in, but I think that was the plan > for newer APIs like Vulkan. > > Regards, > Christian. > >> >> Thanks, >> Felix >> >> >>> Regards, >>> Christian. >>> Regards, Felix > Let's talk about this on Mondays call. Thanks for giving the whole > context. > > Regards, > Christian. > >> Regards, >> Felix >> >
RE: [PATCH v5] drm/amd/display: Revert W/A for hard hangs on DCN20/DCN21
[AMD Official Use Only]
> -Original Message-
> From: Limonciello, Mario
> Sent: January 7, 2022 11:50 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Limonciello, Mario ; Kazlauskas, Nicholas
> ; Zhuo, Qingqing (Lillian)
> ; Scott Bruce ; Chris
> Hixon ; spassw...@web.de
> Subject: [PATCH v5] drm/amd/display: Revert W/A for hard hangs on
> DCN20/DCN21
> Importance: High
>
> The WA from commit 2a50edbf10c8 ("drm/amd/display: Apply w/a for hard
> hang
> on HPD") and commit 1bd3bc745e7f ("drm/amd/display: Extend w/a for hard
> hang on HPD to dcn20") causes a regression in s0ix where the system will
> fail to resume properly on many laptops. Pull the workarounds out to
> avoid that s0ix regression in the common case. This HPD hang happens with
> an external device and a new W/A will need to be developed for this in the
> future.
>
> Cc: Kazlauskas Nicholas
> Cc: Qingqing Zhuo
> Reported-by: Scott Bruce
> Reported-by: Chris Hixon
> Reported-by: spassw...@web.de
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=215436
> Link: https://gitlab.freedesktop.org/drm/amd/-/issues/1821
> Link: https://gitlab.freedesktop.org/drm/amd/-/issues/1852
> Fixes: 2a50edbf10c8 ("drm/amd/display: Apply w/a for hard hang on HPD")
> Fixes: 1bd3bc745e7f ("drm/amd/display: Extend w/a for hard hang on HPD to
> dcn20")
> Signed-off-by: Mario Limonciello
I think the revert is fine once we figure out where we're missing calls to:
.optimize_pwr_state = dcn21_optimize_pwr_state,
.exit_optimized_pwr_state = dcn21_exit_optimized_pwr_state,
These are already part of dc_link_detect, so I suspect there's another
interface in DC that should be using these.
I think the best way to debug this is to revert the patch locally and add a
stack dump when DMCUB hangs our times out.
That way you can know where the PHY was trying to be accessed without the
refclk being on.
We had a similar issue in DCN31 which didn't require a W/A like DCN21.
I'd like to hold off on merging this until that hang is verified as gone.
Regards,
Nicholas Kazlauskas
> ---
> .../display/dc/clk_mgr/dcn20/dcn20_clk_mgr.c | 11 +---
> .../amd/display/dc/clk_mgr/dcn21/rn_clk_mgr.c | 11 +---
> .../display/dc/irq/dcn20/irq_service_dcn20.c | 25 ---
> .../display/dc/irq/dcn20/irq_service_dcn20.h | 2 --
> .../display/dc/irq/dcn21/irq_service_dcn21.c | 25 ---
> .../display/dc/irq/dcn21/irq_service_dcn21.h | 2 --
> .../gpu/drm/amd/display/dc/irq/irq_service.c | 2 +-
> .../gpu/drm/amd/display/dc/irq/irq_service.h | 4 ---
> 8 files changed, 3 insertions(+), 79 deletions(-)
>
> diff --git
> a/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn20/dcn20_clk_mgr.c
> b/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn20/dcn20_clk_mgr.c
> index 9f35f2e8f971..cac80ba69072 100644
> --- a/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn20/dcn20_clk_mgr.c
> +++ b/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn20/dcn20_clk_mgr.c
> @@ -38,7 +38,6 @@
> #include "clk/clk_11_0_0_offset.h"
> #include "clk/clk_11_0_0_sh_mask.h"
>
> -#include "irq/dcn20/irq_service_dcn20.h"
>
> #undef FN
> #define FN(reg_name, field_name) \
> @@ -223,8 +222,6 @@ void dcn2_update_clocks(struct clk_mgr
> *clk_mgr_base,
> bool force_reset = false;
> bool p_state_change_support;
> int total_plane_count;
> - int irq_src;
> - uint32_t hpd_state;
>
> if (dc->work_arounds.skip_clock_update)
> return;
> @@ -242,13 +239,7 @@ void dcn2_update_clocks(struct clk_mgr
> *clk_mgr_base,
> if (dc->res_pool->pp_smu)
> pp_smu = >res_pool->pp_smu->nv_funcs;
>
> - for (irq_src = DC_IRQ_SOURCE_HPD1; irq_src <=
> DC_IRQ_SOURCE_HPD6; irq_src++) {
> - hpd_state = dc_get_hpd_state_dcn20(dc->res_pool->irqs,
> irq_src);
> - if (hpd_state)
> - break;
> - }
> -
> - if (display_count == 0 && !hpd_state)
> + if (display_count == 0)
> enter_display_off = true;
>
> if (enter_display_off == safe_to_lower) {
> diff --git a/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn21/rn_clk_mgr.c
> b/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn21/rn_clk_mgr.c
> index fbda42313bfe..f4dee0e48a67 100644
> --- a/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn21/rn_clk_mgr.c
> +++ b/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn21/rn_clk_mgr.c
> @@ -42,7 +42,6 @@
> #include "clk/clk_10_0_2_sh_mask.h"
> #include "renoir_ip_offset.h"
>
> -#include "irq/dcn21/irq_service_dcn21.h"
>
> /* Constants */
>
> @@ -129,11 +128,9 @@ static void rn_update_clocks(struct clk_mgr
> *clk_mgr_base,
> struct dc_clocks *new_clocks = >bw_ctx.bw.dcn.clk;
> struct dc *dc = clk_mgr_base->ctx->dc;
> int display_count;
> - int irq_src;
> bool update_dppclk = false;
> bool update_dispclk = false;
> bool dpp_clock_lowered = false;
> - uint32_t hpd_state;
>
> struct dmcu *dmcu = clk_mgr_base->ctx->dc->res_pool->dmcu;
>
> @@ -150,14 +147,8 @@ static
[PATCH v5] drm/amd/display: Revert W/A for hard hangs on DCN20/DCN21
The WA from commit 2a50edbf10c8 ("drm/amd/display: Apply w/a for hard hang
on HPD") and commit 1bd3bc745e7f ("drm/amd/display: Extend w/a for hard
hang on HPD to dcn20") causes a regression in s0ix where the system will
fail to resume properly on many laptops. Pull the workarounds out to
avoid that s0ix regression in the common case. This HPD hang happens with
an external device and a new W/A will need to be developed for this in the
future.
Cc: Kazlauskas Nicholas
Cc: Qingqing Zhuo
Reported-by: Scott Bruce
Reported-by: Chris Hixon
Reported-by: spassw...@web.de
Link: https://bugzilla.kernel.org/show_bug.cgi?id=215436
Link: https://gitlab.freedesktop.org/drm/amd/-/issues/1821
Link: https://gitlab.freedesktop.org/drm/amd/-/issues/1852
Fixes: 2a50edbf10c8 ("drm/amd/display: Apply w/a for hard hang on HPD")
Fixes: 1bd3bc745e7f ("drm/amd/display: Extend w/a for hard hang on HPD to
dcn20")
Signed-off-by: Mario Limonciello
---
.../display/dc/clk_mgr/dcn20/dcn20_clk_mgr.c | 11 +---
.../amd/display/dc/clk_mgr/dcn21/rn_clk_mgr.c | 11 +---
.../display/dc/irq/dcn20/irq_service_dcn20.c | 25 ---
.../display/dc/irq/dcn20/irq_service_dcn20.h | 2 --
.../display/dc/irq/dcn21/irq_service_dcn21.c | 25 ---
.../display/dc/irq/dcn21/irq_service_dcn21.h | 2 --
.../gpu/drm/amd/display/dc/irq/irq_service.c | 2 +-
.../gpu/drm/amd/display/dc/irq/irq_service.h | 4 ---
8 files changed, 3 insertions(+), 79 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn20/dcn20_clk_mgr.c
b/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn20/dcn20_clk_mgr.c
index 9f35f2e8f971..cac80ba69072 100644
--- a/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn20/dcn20_clk_mgr.c
+++ b/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn20/dcn20_clk_mgr.c
@@ -38,7 +38,6 @@
#include "clk/clk_11_0_0_offset.h"
#include "clk/clk_11_0_0_sh_mask.h"
-#include "irq/dcn20/irq_service_dcn20.h"
#undef FN
#define FN(reg_name, field_name) \
@@ -223,8 +222,6 @@ void dcn2_update_clocks(struct clk_mgr *clk_mgr_base,
bool force_reset = false;
bool p_state_change_support;
int total_plane_count;
- int irq_src;
- uint32_t hpd_state;
if (dc->work_arounds.skip_clock_update)
return;
@@ -242,13 +239,7 @@ void dcn2_update_clocks(struct clk_mgr *clk_mgr_base,
if (dc->res_pool->pp_smu)
pp_smu = >res_pool->pp_smu->nv_funcs;
- for (irq_src = DC_IRQ_SOURCE_HPD1; irq_src <= DC_IRQ_SOURCE_HPD6;
irq_src++) {
- hpd_state = dc_get_hpd_state_dcn20(dc->res_pool->irqs, irq_src);
- if (hpd_state)
- break;
- }
-
- if (display_count == 0 && !hpd_state)
+ if (display_count == 0)
enter_display_off = true;
if (enter_display_off == safe_to_lower) {
diff --git a/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn21/rn_clk_mgr.c
b/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn21/rn_clk_mgr.c
index fbda42313bfe..f4dee0e48a67 100644
--- a/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn21/rn_clk_mgr.c
+++ b/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn21/rn_clk_mgr.c
@@ -42,7 +42,6 @@
#include "clk/clk_10_0_2_sh_mask.h"
#include "renoir_ip_offset.h"
-#include "irq/dcn21/irq_service_dcn21.h"
/* Constants */
@@ -129,11 +128,9 @@ static void rn_update_clocks(struct clk_mgr *clk_mgr_base,
struct dc_clocks *new_clocks = >bw_ctx.bw.dcn.clk;
struct dc *dc = clk_mgr_base->ctx->dc;
int display_count;
- int irq_src;
bool update_dppclk = false;
bool update_dispclk = false;
bool dpp_clock_lowered = false;
- uint32_t hpd_state;
struct dmcu *dmcu = clk_mgr_base->ctx->dc->res_pool->dmcu;
@@ -150,14 +147,8 @@ static void rn_update_clocks(struct clk_mgr *clk_mgr_base,
display_count = rn_get_active_display_cnt_wa(dc,
context);
- for (irq_src = DC_IRQ_SOURCE_HPD1; irq_src <=
DC_IRQ_SOURCE_HPD5; irq_src++) {
- hpd_state =
dc_get_hpd_state_dcn21(dc->res_pool->irqs, irq_src);
- if (hpd_state)
- break;
- }
-
/* if we can go lower, go lower */
- if (display_count == 0 && !hpd_state) {
+ if (display_count == 0) {
rn_vbios_smu_set_dcn_low_power_state(clk_mgr,
DCN_PWR_STATE_LOW_POWER);
/* update power state */
clk_mgr_base->clks.pwr_state =
DCN_PWR_STATE_LOW_POWER;
diff --git a/drivers/gpu/drm/amd/display/dc/irq/dcn20/irq_service_dcn20.c
b/drivers/gpu/drm/amd/display/dc/irq/dcn20/irq_service_dcn20.c
index 9ccafe007b23..c4b067d01895 100644
--- a/drivers/gpu/drm/amd/display/dc/irq/dcn20/irq_service_dcn20.c
+++ b/drivers/gpu/drm/amd/display/dc/irq/dcn20/irq_service_dcn20.c
@@ -132,31
[PATCH v2] drm/amdgpu: Use correct VIEWPORT_DIMENSION for DCN2
For some reason this file isn't using the appropriate register
headers for DCN headers, which means that on DCN2 we're getting
the VIEWPORT_DIMENSION offset wrong.
This means that we're not correctly carving out the framebuffer
memory correctly for a framebuffer allocated by EFI and
therefore see corruption when loading amdgpu before the display
driver takes over control of the framebuffer scanout.
Fix this by checking the DCE_HWIP and picking the correct offset
accordingly.
Long-term we should expose this info from DC as GMC shouldn't
need to know about DCN registers.
Cc: sta...@vger.kernel.org
Signed-off-by: Harry Wentland
Reviewed-by: Huang Rui
Acked-by: Christian König
Reviewed-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
index 57f2729a7bd0..c1a22a8a4c85 100644
--- a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
@@ -72,6 +72,9 @@
#define mmDCHUBBUB_SDPIF_MMIO_CNTRL_0
0x049d
#define mmDCHUBBUB_SDPIF_MMIO_CNTRL_0_BASE_IDX
2
+#define mmHUBP0_DCSURF_PRI_VIEWPORT_DIMENSION_DCN2
0x05ea
+#define mmHUBP0_DCSURF_PRI_VIEWPORT_DIMENSION_DCN2_BASE_IDX
2
+
static const char *gfxhub_client_ids[] = {
"CB",
@@ -1134,6 +1137,8 @@ static unsigned gmc_v9_0_get_vbios_fb_size(struct
amdgpu_device *adev)
u32 d1vga_control = RREG32_SOC15(DCE, 0, mmD1VGA_CONTROL);
unsigned size;
+ /* TODO move to DC so GMC doesn't need to hard-code DCN registers */
+
if (REG_GET_FIELD(d1vga_control, D1VGA_CONTROL, D1VGA_MODE_ENABLE)) {
size = AMDGPU_VBIOS_VGA_ALLOCATION;
} else {
@@ -1142,7 +1147,6 @@ static unsigned gmc_v9_0_get_vbios_fb_size(struct
amdgpu_device *adev)
switch (adev->ip_versions[DCE_HWIP][0]) {
case IP_VERSION(1, 0, 0):
case IP_VERSION(1, 0, 1):
- case IP_VERSION(2, 1, 0):
viewport = RREG32_SOC15(DCE, 0,
mmHUBP0_DCSURF_PRI_VIEWPORT_DIMENSION);
size = (REG_GET_FIELD(viewport,
HUBP0_DCSURF_PRI_VIEWPORT_DIMENSION, PRI_VIEWPORT_HEIGHT) *
@@ -1150,6 +1154,14 @@ static unsigned gmc_v9_0_get_vbios_fb_size(struct
amdgpu_device *adev)
HUBP0_DCSURF_PRI_VIEWPORT_DIMENSION, PRI_VIEWPORT_WIDTH) *
4);
break;
+ case IP_VERSION(2, 1, 0):
+ viewport = RREG32_SOC15(DCE, 0,
mmHUBP0_DCSURF_PRI_VIEWPORT_DIMENSION_DCN2);
+ size = (REG_GET_FIELD(viewport,
+
HUBP0_DCSURF_PRI_VIEWPORT_DIMENSION, PRI_VIEWPORT_HEIGHT) *
+ REG_GET_FIELD(viewport,
+
HUBP0_DCSURF_PRI_VIEWPORT_DIMENSION, PRI_VIEWPORT_WIDTH) *
+ 4);
+ break;
default:
viewport = RREG32_SOC15(DCE, 0, mmSCL0_VIEWPORT_SIZE);
size = (REG_GET_FIELD(viewport, SCL0_VIEWPORT_SIZE,
VIEWPORT_HEIGHT) *
--
2.34.1
Re: [PATCH] drm/amd/amdgpu: Add pcie indirect support to amdgpu_mm_wreg_mmio_rlc()
[AMD Official Use Only]
Acked-by: Alex Deucher
From: amd-gfx on behalf of Tom St Denis
Sent: Friday, January 7, 2022 7:07 AM
To: amd-gfx@lists.freedesktop.org
Cc: StDenis, Tom
Subject: [PATCH] drm/amd/amdgpu: Add pcie indirect support to
amdgpu_mm_wreg_mmio_rlc()
The function amdgpu_mm_wreg_mmio_rlc() is used by debugfs to write to
MMIO registers. It didn't support registers beyond the BAR mapped MMIO
space. This adds pcie indirect write support.
Signed-off-by: Tom St Denis
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index c38e0e87090b..53a04095a6db 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -552,7 +552,7 @@ void amdgpu_device_wreg(struct amdgpu_device *adev,
}
/**
- * amdgpu_mm_wreg_mmio_rlc - write register either with mmio or with RLC path
if in range
+ * amdgpu_mm_wreg_mmio_rlc - write register either with direct/indirect mmio
or with RLC path if in range
*
* this function is invoked only the debugfs register access
*/
@@ -567,6 +567,8 @@ void amdgpu_mm_wreg_mmio_rlc(struct amdgpu_device *adev,
adev->gfx.rlc.funcs->is_rlcg_access_range) {
if (adev->gfx.rlc.funcs->is_rlcg_access_range(adev, reg))
return adev->gfx.rlc.funcs->sriov_wreg(adev, reg, v,
0, 0);
+ } else if ((reg * 4) >= adev->rmmio_size) {
+ adev->pcie_wreg(adev, reg * 4, v);
} else {
writel(v, ((void __iomem *)adev->rmmio) + (reg * 4));
}
--
2.32.0
Re: [RFC v2 8/8] drm/amd/virt: Drop concurrent GPU reset protection for SRIOV
On 2022-01-07 12:46 a.m., JingWen Chen wrote: On 2022/1/7 上午11:57, JingWen Chen wrote: On 2022/1/7 上午3:13, Andrey Grodzovsky wrote: On 2022-01-06 12:18 a.m., JingWen Chen wrote: On 2022/1/6 下午12:59, JingWen Chen wrote: On 2022/1/6 上午2:24, Andrey Grodzovsky wrote: On 2022-01-05 2:59 a.m., Christian König wrote: Am 05.01.22 um 08:34 schrieb JingWen Chen: On 2022/1/5 上午12:56, Andrey Grodzovsky wrote: On 2022-01-04 6:36 a.m., Christian König wrote: Am 04.01.22 um 11:49 schrieb Liu, Monk: [AMD Official Use Only] See the FLR request from the hypervisor is just another source of signaling the need for a reset, similar to each job timeout on each queue. Otherwise you have a race condition between the hypervisor and the scheduler. No it's not, FLR from hypervisor is just to notify guest the hw VF FLR is about to start or was already executed, but host will do FLR anyway without waiting for guest too long Then we have a major design issue in the SRIOV protocol and really need to question this. How do you want to prevent a race between the hypervisor resetting the hardware and the client trying the same because of a timeout? As far as I can see the procedure should be: 1. We detect that a reset is necessary, either because of a fault a timeout or signal from hypervisor. 2. For each of those potential reset sources a work item is send to the single workqueue. 3. One of those work items execute first and prepares the reset. 4. We either do the reset our self or notify the hypervisor that we are ready for the reset. 5. Cleanup after the reset, eventually resubmit jobs etc.. 6. Cancel work items which might have been scheduled from other reset sources. It does make sense that the hypervisor resets the hardware without waiting for the clients for too long, but if we don't follow this general steps we will always have a race between the different components. Monk, just to add to this - if indeed as you say that 'FLR from hypervisor is just to notify guest the hw VF FLR is about to start or was already executed, but host will do FLR anyway without waiting for guest too long' and there is no strict waiting from the hypervisor for IDH_READY_TO_RESET to be recived from guest before starting the reset then setting in_gpu_reset and locking reset_sem from guest side is not really full proof protection from MMIO accesses by the guest - it only truly helps if hypervisor waits for that message before initiation of HW reset. Hi Andrey, this cannot be done. If somehow guest kernel hangs and never has the chance to send the response back, then other VFs will have to wait it reset. All the vfs will hang in this case. Or sometimes the mailbox has some delay and other VFs will also wait. The user of other VFs will be affected in this case. Yeah, agree completely with JingWen. The hypervisor is the one in charge here, not the guest. What the hypervisor should do (and it already seems to be designed that way) is to send the guest a message that a reset is about to happen and give it some time to response appropriately. The guest on the other hand then tells the hypervisor that all processing has stopped and it is ready to restart. If that doesn't happen in time the hypervisor should eliminate the guest probably trigger even more severe consequences, e.g. restart the whole VM etc... Christian. So what's the end conclusion here regarding dropping this particular patch ? Seems to me we still need to drop it to prevent driver's MMIO access to the GPU during reset from various places in the code. Andrey Hi Andrey & Christian, I have ported your patch(drop the reset_sem and in_gpu_reset in flr work) and run some tests. If a engine hang during an OCL benchmark(using kfd), we can see the logs below: Did you port the entire patchset or just 'drm/amd/virt: Drop concurrent GPU reset protection for SRIOV' ? I ported the entire patchset [ 397.190727] amdgpu :00:07.0: amdgpu: wait for kiq fence error: 0. [ 397.301496] amdgpu :00:07.0: amdgpu: wait for kiq fence error: 0. [ 397.406601] amdgpu :00:07.0: amdgpu: wait for kiq fence error: 0. [ 397.532343] amdgpu :00:07.0: amdgpu: wait for kiq fence error: 0. [ 397.642251] amdgpu :00:07.0: amdgpu: wait for kiq fence error: 0. [ 397.746634] amdgpu :00:07.0: amdgpu: wait for kiq fence error: 0. [ 397.850761] amdgpu :00:07.0: amdgpu: wait for kiq fence error: 0. [ 397.960544] amdgpu :00:07.0: amdgpu: wait for kiq fence error: 0. [ 398.065218] amdgpu :00:07.0: amdgpu: wait for kiq fence error: 0. [ 398.182173] amdgpu :00:07.0: amdgpu: wait for kiq fence error: 0. [ 398.288264] amdgpu :00:07.0: amdgpu: wait for kiq fence error: 0. [ 398.394712] amdgpu :00:07.0: amdgpu: wait for kiq fence error: 0. [ 428.400582] [drm] clean up the vf2pf work item [ 428.500528] amdgpu :00:07.0: amdgpu: [gfxhub] page fault (src_id:0 ring:153 vmid:8 pasid:32771, for process xgemmStandalone pid 3557
Re: [PATCH v6 1/6] drm: move the buddy allocator from i915 into common drm
Am 07.01.22 um 16:49 schrieb Matthew Auld:
On 26/12/2021 22:24, Arunpravin wrote:
Move the base i915 buddy allocator code into drm
- Move i915_buddy.h to include/drm
- Move i915_buddy.c to drm root folder
- Rename "i915" string with "drm" string wherever applicable
- Rename "I915" string with "DRM" string wherever applicable
- Fix header file dependencies
- Fix alignment issues
- add Makefile support for drm buddy
- export functions and write kerneldoc description
- Remove i915 selftest config check condition as buddy selftest
will be moved to drm selftest folder
cleanup i915 buddy references in i915 driver module
and replace with drm buddy
v2:
- include header file in alphabetical order(Thomas)
- merged changes listed in the body section into a single patch
to keep the build intact(Christian, Jani)
v3:
- make drm buddy a separate module(Thomas, Christian)
v4:
- Fix build error reported by kernel test robot
- removed i915 buddy selftest from i915_mock_selftests.h to
avoid build error
- removed selftests/i915_buddy.c file as we create a new set of
buddy test cases in drm/selftests folder
v5:
- Fix merge conflict issue
Signed-off-by: Arunpravin
+int drm_buddy_init(struct drm_buddy_mm *mm, u64 size, u64 chunk_size)
+{
+ unsigned int i;
+ u64 offset;
+
+ if (size < chunk_size)
+ return -EINVAL;
+
+ if (chunk_size < PAGE_SIZE)
+ return -EINVAL;
+
+ if (!is_power_of_2(chunk_size))
+ return -EINVAL;
+
+ size = round_down(size, chunk_size);
+
+ mm->size = size;
+ mm->avail = size;
+ mm->chunk_size = chunk_size;
+ mm->max_order = ilog2(size) - ilog2(chunk_size);
+
+ BUG_ON(mm->max_order > DRM_BUDDY_MAX_ORDER);
+
+ mm->slab_blocks = KMEM_CACHE(drm_buddy_block, 0);
+ if (!mm->slab_blocks)
+ return -ENOMEM;
It looks like every KMEM_CACHE() also creates a debugfs entry? See the
error here[1]. I guess because we end with multiple instances in i915.
If so, is it possible to have a single KMEM_CACHE() as part of the
buddy module, similar to what i915 was doing previously?
Oh, that is a really good point, this code here doesn't make to much sense.
The value of a KMEM_CACHE() is to allow speeding up allocation of the
same structure size between different drm_buddy object. If you allocate
one cache per drm_buddy that makes the whole functionality useless.
Please fix, this is actually a bug.
Christian.
[1]
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fintel-gfx-ci.01.org%2Ftree%2Fdrm-tip%2FTrybot_8217%2Fshard-skl4%2Figt%40i915_selftest%40mock%40memory_region.htmldata=04%7C01%7Cchristian.koenig%40amd.com%7C56202fbe886f415c3b8308d9d1f5409c%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637771673545453215%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=ZnRmAQo%2BjX414hbqHigL4R18oBDKLIugUQIVcwhFI%2BY%3Dreserved=0
Re: [PATCH v6 1/6] drm: move the buddy allocator from i915 into common drm
On 26/12/2021 22:24, Arunpravin wrote:
Move the base i915 buddy allocator code into drm
- Move i915_buddy.h to include/drm
- Move i915_buddy.c to drm root folder
- Rename "i915" string with "drm" string wherever applicable
- Rename "I915" string with "DRM" string wherever applicable
- Fix header file dependencies
- Fix alignment issues
- add Makefile support for drm buddy
- export functions and write kerneldoc description
- Remove i915 selftest config check condition as buddy selftest
will be moved to drm selftest folder
cleanup i915 buddy references in i915 driver module
and replace with drm buddy
v2:
- include header file in alphabetical order(Thomas)
- merged changes listed in the body section into a single patch
to keep the build intact(Christian, Jani)
v3:
- make drm buddy a separate module(Thomas, Christian)
v4:
- Fix build error reported by kernel test robot
- removed i915 buddy selftest from i915_mock_selftests.h to
avoid build error
- removed selftests/i915_buddy.c file as we create a new set of
buddy test cases in drm/selftests folder
v5:
- Fix merge conflict issue
Signed-off-by: Arunpravin
+int drm_buddy_init(struct drm_buddy_mm *mm, u64 size, u64 chunk_size)
+{
+ unsigned int i;
+ u64 offset;
+
+ if (size < chunk_size)
+ return -EINVAL;
+
+ if (chunk_size < PAGE_SIZE)
+ return -EINVAL;
+
+ if (!is_power_of_2(chunk_size))
+ return -EINVAL;
+
+ size = round_down(size, chunk_size);
+
+ mm->size = size;
+ mm->avail = size;
+ mm->chunk_size = chunk_size;
+ mm->max_order = ilog2(size) - ilog2(chunk_size);
+
+ BUG_ON(mm->max_order > DRM_BUDDY_MAX_ORDER);
+
+ mm->slab_blocks = KMEM_CACHE(drm_buddy_block, 0);
+ if (!mm->slab_blocks)
+ return -ENOMEM;
It looks like every KMEM_CACHE() also creates a debugfs entry? See the
error here[1]. I guess because we end with multiple instances in i915.
If so, is it possible to have a single KMEM_CACHE() as part of the buddy
module, similar to what i915 was doing previously?
[1]
https://intel-gfx-ci.01.org/tree/drm-tip/Trybot_8217/shard-skl4/igt@i915_selftest@mock@memory_region.html
Re: [PATCH REBASED 1/4] drm/amdgpu: do not pass ttm_resource_manager to gtt_mgr
I've just pushed the whole set to amd-staging-drm-next.
Thanks,
Christian.
Am 07.01.22 um 09:51 schrieb Nirmoy Das:
Do not allow exported amdgpu_gtt_mgr_*() to accept
any ttm_resource_manager pointer. Also there is no need
to force other module to call a ttm function just to
eventually call gtt_mgr functions.
v4: remove unused adev.
v3: upcast mgr from ttm resopurce manager instead of
getting it from adev.
v2: pass adev's gtt_mgr instead of adev.
Reviewed-by: Christian König
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c | 22 ++---
drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 4 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h | 4 ++--
4 files changed, 16 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 3aab187520c6..58b9a5176082 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -4357,7 +4357,7 @@ static int amdgpu_device_reset_sriov(struct amdgpu_device
*adev,
amdgpu_virt_init_data_exchange(adev);
/* we need recover gart prior to run SMC/CP/SDMA resume */
- amdgpu_gtt_mgr_recover(ttm_manager_type(>mman.bdev, TTM_PL_TT));
+ amdgpu_gtt_mgr_recover(>mman.gtt_mgr);
r = amdgpu_device_fw_loading(adev);
if (r)
@@ -4677,7 +4677,7 @@ int amdgpu_do_asic_reset(struct list_head
*device_list_handle,
amdgpu_inc_vram_lost(tmp_adev);
}
-r = amdgpu_gtt_mgr_recover(ttm_manager_type(_adev->mman.bdev, TTM_PL_TT));
+ r =
amdgpu_gtt_mgr_recover(_adev->mman.gtt_mgr);
if (r)
goto out;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
index c18f16b3be9c..9151950e0cc3 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
@@ -77,10 +77,8 @@ static ssize_t amdgpu_mem_info_gtt_used_show(struct device
*dev,
{
struct drm_device *ddev = dev_get_drvdata(dev);
struct amdgpu_device *adev = drm_to_adev(ddev);
- struct ttm_resource_manager *man;
- man = ttm_manager_type(>mman.bdev, TTM_PL_TT);
- return sysfs_emit(buf, "%llu\n", amdgpu_gtt_mgr_usage(man));
+ return sysfs_emit(buf, "%llu\n",
amdgpu_gtt_mgr_usage(>mman.gtt_mgr));
}
static DEVICE_ATTR(mem_info_gtt_total, S_IRUGO,
@@ -206,14 +204,15 @@ static void amdgpu_gtt_mgr_del(struct
ttm_resource_manager *man,
/**
* amdgpu_gtt_mgr_usage - return usage of GTT domain
*
- * @man: TTM memory type manager
+ * @mgr: amdgpu_gtt_mgr pointer
*
* Return how many bytes are used in the GTT domain
*/
-uint64_t amdgpu_gtt_mgr_usage(struct ttm_resource_manager *man)
+uint64_t amdgpu_gtt_mgr_usage(struct amdgpu_gtt_mgr *mgr)
{
- struct amdgpu_gtt_mgr *mgr = to_gtt_mgr(man);
- s64 result = man->size - atomic64_read(>available);
+ s64 result;
+
+ result = mgr->manager.size - atomic64_read(>available);
return (result > 0 ? result : 0) * PAGE_SIZE;
}
@@ -221,16 +220,15 @@ uint64_t amdgpu_gtt_mgr_usage(struct ttm_resource_manager
*man)
/**
* amdgpu_gtt_mgr_recover - re-init gart
*
- * @man: TTM memory type manager
+ * @mgr: amdgpu_gtt_mgr pointer
*
* Re-init the gart for each known BO in the GTT.
*/
-int amdgpu_gtt_mgr_recover(struct ttm_resource_manager *man)
+int amdgpu_gtt_mgr_recover(struct amdgpu_gtt_mgr *mgr)
{
- struct amdgpu_gtt_mgr *mgr = to_gtt_mgr(man);
- struct amdgpu_device *adev;
struct amdgpu_gtt_node *node;
struct drm_mm_node *mm_node;
+ struct amdgpu_device *adev;
int r = 0;
adev = container_of(mgr, typeof(*adev), mman.gtt_mgr);
@@ -267,7 +265,7 @@ static void amdgpu_gtt_mgr_debug(struct
ttm_resource_manager *man,
drm_printf(printer, "man size:%llu pages, gtt available:%lld pages, usage:%lluMB\n",
man->size, (u64)atomic64_read(>available),
- amdgpu_gtt_mgr_usage(man) >> 20);
+ amdgpu_gtt_mgr_usage(mgr) >> 20);
}
static const struct ttm_resource_manager_func amdgpu_gtt_mgr_func = {
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
index 651c7abfde03..763de822afa1 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
@@ -678,7 +678,7 @@ int amdgpu_info_ioctl(struct drm_device *dev, void *data,
struct drm_file *filp)
ui64 =
amdgpu_vram_mgr_vis_usage(ttm_manager_type(>mman.bdev, TTM_PL_VRAM));
return copy_to_user(out, , min(size, 8u)) ? -EFAULT : 0;
case AMDGPU_INFO_GTT_USAGE:
- ui64 =
[PATCH] drm/amd/amdgpu: Add pcie indirect support to amdgpu_mm_wreg_mmio_rlc()
The function amdgpu_mm_wreg_mmio_rlc() is used by debugfs to write to
MMIO registers. It didn't support registers beyond the BAR mapped MMIO
space. This adds pcie indirect write support.
Signed-off-by: Tom St Denis
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index c38e0e87090b..53a04095a6db 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -552,7 +552,7 @@ void amdgpu_device_wreg(struct amdgpu_device *adev,
}
/**
- * amdgpu_mm_wreg_mmio_rlc - write register either with mmio or with RLC path
if in range
+ * amdgpu_mm_wreg_mmio_rlc - write register either with direct/indirect mmio
or with RLC path if in range
*
* this function is invoked only the debugfs register access
*/
@@ -567,6 +567,8 @@ void amdgpu_mm_wreg_mmio_rlc(struct amdgpu_device *adev,
adev->gfx.rlc.funcs->is_rlcg_access_range) {
if (adev->gfx.rlc.funcs->is_rlcg_access_range(adev, reg))
return adev->gfx.rlc.funcs->sriov_wreg(adev, reg, v, 0,
0);
+ } else if ((reg * 4) >= adev->rmmio_size) {
+ adev->pcie_wreg(adev, reg * 4, v);
} else {
writel(v, ((void __iomem *)adev->rmmio) + (reg * 4));
}
--
2.32.0
Re: [PATCH 2/4] drm/amdkfd: remove unused function
Found the commit that removed usages of this function.
Fixes: dfcbe6d5f ("drm/amdgpu: Remove unused function pointers")
On 1/7/22 09:51, Nirmoy Das wrote:
Remove unused amdgpu_amdkfd_get_vram_usage()
CC: felix.kuehl...@amd.com
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c | 7 ---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h | 1 -
2 files changed, 8 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
index 776a947b45df..6ca1db3c243f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
@@ -514,13 +514,6 @@ int amdgpu_amdkfd_get_dmabuf_info(struct amdgpu_device
*adev, int dma_buf_fd,
return r;
}
-uint64_t amdgpu_amdkfd_get_vram_usage(struct amdgpu_device *adev)
-{
- struct ttm_resource_manager *vram_man =
ttm_manager_type(>mman.bdev, TTM_PL_VRAM);
-
- return amdgpu_vram_mgr_usage(vram_man);
-}
-
uint8_t amdgpu_amdkfd_get_xgmi_hops_count(struct amdgpu_device *dst,
struct amdgpu_device *src)
{
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
index 61f899e54fd5..ac841ae8f5cc 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
@@ -223,7 +223,6 @@ int amdgpu_amdkfd_get_dmabuf_info(struct amdgpu_device
*adev, int dma_buf_fd,
uint64_t *bo_size, void *metadata_buffer,
size_t buffer_size, uint32_t *metadata_size,
uint32_t *flags);
-uint64_t amdgpu_amdkfd_get_vram_usage(struct amdgpu_device *adev);
uint8_t amdgpu_amdkfd_get_xgmi_hops_count(struct amdgpu_device *dst,
struct amdgpu_device *src);
int amdgpu_amdkfd_get_xgmi_bandwidth_mbytes(struct amdgpu_device *dst,
--
2.33.1
Re: [PATCH] drm/ttm: Don't inherit GEM object VMAs in child process
Am 06.01.22 um 17:51 schrieb Felix Kuehling: Am 2022-01-06 um 11:48 a.m. schrieb Christian König: Am 06.01.22 um 17:45 schrieb Felix Kuehling: Am 2022-01-06 um 4:05 a.m. schrieb Christian König: [SNIP] Also, why does your ACK or NAK depend on this at all. If it's the right thing to do, it's the right thing to do regardless of who benefits from it. In addition, how can a child process that doesn't even use the GPU be in violation of any GPU-driver related specifications. The argument is that the application is broken and needs to be fixed instead of worked around inside the kernel. I still don't get how they the application is broken. Like I said, the child process is not using the GPU. How can the application be fixed in this case? Sounds like I'm still missing some important puzzle pieces for the full picture to figure out why this doesn't work. Are you saying, any application that forks and doesn't immediately call exec is broken? More or less yes. We essentially have three possible cases here: 1. Application is already using (for example) OpenGL or OpenCL to do some rendering on the GPU and then calls fork() and expects to use OpenGL both in the parent and the child at the same time. As far as I know that's illegal from the Khronos specification point of view and working around inside the kernel for something not allowed in the first place is seen as futile effort. 2. Application opened the file descriptor, forks and then initializes OpenGL/Vulkan/OpenCL. That's what some compositors are doing to drop into the backround and is explicitly legal. 3. Application calls fork() and then doesn't use the GPU in the child. Either by not using it or calling exec. That should be legal and not cause any problems in the first place. But from your description I still don't get why we are running into problems here. I was assuming that you have case #1 because we previously had some examples of this with this python library, but from your description it seems to be case #3. Or does an application that forks need to be aware that some other part of the application used the GPU and explicitly free any GPU resources? Others might fill that information in, but I think that was the plan for newer APIs like Vulkan. Regards, Christian. Thanks, Felix Regards, Christian. Regards, Felix Let's talk about this on Mondays call. Thanks for giving the whole context. Regards, Christian. Regards, Felix
[PATCH REBASED 4/4] drm/amdgpu: recover gart table at resume
Get rid off pin/unpin of gart BO at resume/suspend and
instead pin only once and try to recover gart content
at resume time. This is much more stable in case there
is OOM situation at 2nd call to amdgpu_device_evict_resources()
while evicting GART table.
v3: remove gart recovery from other places
v2: pin gart at amdgpu_gart_table_vram_alloc()
Reviewed-by: Christian König
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 11 ---
drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c | 84 ++
drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c | 3 +-
drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c | 3 +-
drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c | 3 +-
drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c | 3 +-
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 3 +-
7 files changed, 11 insertions(+), 99 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 58b9a5176082..a89e08e44fea 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -4004,16 +4004,11 @@ int amdgpu_device_suspend(struct drm_device *dev, bool
fbcon)
if (!adev->in_s0ix)
amdgpu_amdkfd_suspend(adev, adev->in_runpm);
- /* First evict vram memory */
amdgpu_device_evict_resources(adev);
amdgpu_fence_driver_hw_fini(adev);
amdgpu_device_ip_suspend_phase2(adev);
- /* This second call to evict device resources is to evict
-* the gart page table using the CPU.
-*/
- amdgpu_device_evict_resources(adev);
return 0;
}
@@ -4356,8 +4351,6 @@ static int amdgpu_device_reset_sriov(struct amdgpu_device
*adev,
goto error;
amdgpu_virt_init_data_exchange(adev);
- /* we need recover gart prior to run SMC/CP/SDMA resume */
- amdgpu_gtt_mgr_recover(>mman.gtt_mgr);
r = amdgpu_device_fw_loading(adev);
if (r)
@@ -4677,10 +4670,6 @@ int amdgpu_do_asic_reset(struct list_head
*device_list_handle,
amdgpu_inc_vram_lost(tmp_adev);
}
- r =
amdgpu_gtt_mgr_recover(_adev->mman.gtt_mgr);
- if (r)
- goto out;
-
r = amdgpu_device_fw_loading(tmp_adev);
if (r)
return r;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c
index d3e4203f6217..645950a653a0 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c
@@ -114,80 +114,12 @@ void amdgpu_gart_dummy_page_fini(struct amdgpu_device
*adev)
*/
int amdgpu_gart_table_vram_alloc(struct amdgpu_device *adev)
{
- int r;
-
- if (adev->gart.bo == NULL) {
- struct amdgpu_bo_param bp;
-
- memset(, 0, sizeof(bp));
- bp.size = adev->gart.table_size;
- bp.byte_align = PAGE_SIZE;
- bp.domain = AMDGPU_GEM_DOMAIN_VRAM;
- bp.flags = AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED |
- AMDGPU_GEM_CREATE_VRAM_CONTIGUOUS;
- bp.type = ttm_bo_type_kernel;
- bp.resv = NULL;
- bp.bo_ptr_size = sizeof(struct amdgpu_bo);
-
- r = amdgpu_bo_create(adev, , >gart.bo);
- if (r) {
- return r;
- }
- }
- return 0;
-}
-
-/**
- * amdgpu_gart_table_vram_pin - pin gart page table in vram
- *
- * @adev: amdgpu_device pointer
- *
- * Pin the GART page table in vram so it will not be moved
- * by the memory manager (pcie r4xx, r5xx+). These asics require the
- * gart table to be in video memory.
- * Returns 0 for success, error for failure.
- */
-int amdgpu_gart_table_vram_pin(struct amdgpu_device *adev)
-{
- int r;
-
- r = amdgpu_bo_reserve(adev->gart.bo, false);
- if (unlikely(r != 0))
- return r;
- r = amdgpu_bo_pin(adev->gart.bo, AMDGPU_GEM_DOMAIN_VRAM);
- if (r) {
- amdgpu_bo_unreserve(adev->gart.bo);
- return r;
- }
- r = amdgpu_bo_kmap(adev->gart.bo, >gart.ptr);
- if (r)
- amdgpu_bo_unpin(adev->gart.bo);
- amdgpu_bo_unreserve(adev->gart.bo);
- return r;
-}
-
-/**
- * amdgpu_gart_table_vram_unpin - unpin gart page table in vram
- *
- * @adev: amdgpu_device pointer
- *
- * Unpin the GART page table in vram (pcie r4xx, r5xx+).
- * These asics require the gart table to be in video memory.
- */
-void amdgpu_gart_table_vram_unpin(struct amdgpu_device *adev)
-{
- int r;
+ if (adev->gart.bo != NULL)
+ return 0;
- if (adev->gart.bo == NULL) {
- return;
- }
- r = amdgpu_bo_reserve(adev->gart.bo, true);
- if (likely(r
[PATCH 2/4] drm/amdkfd: remove unused function
Remove unused amdgpu_amdkfd_get_vram_usage()
CC: felix.kuehl...@amd.com
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c | 7 ---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h | 1 -
2 files changed, 8 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
index 776a947b45df..6ca1db3c243f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
@@ -514,13 +514,6 @@ int amdgpu_amdkfd_get_dmabuf_info(struct amdgpu_device
*adev, int dma_buf_fd,
return r;
}
-uint64_t amdgpu_amdkfd_get_vram_usage(struct amdgpu_device *adev)
-{
- struct ttm_resource_manager *vram_man =
ttm_manager_type(>mman.bdev, TTM_PL_VRAM);
-
- return amdgpu_vram_mgr_usage(vram_man);
-}
-
uint8_t amdgpu_amdkfd_get_xgmi_hops_count(struct amdgpu_device *dst,
struct amdgpu_device *src)
{
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
index 61f899e54fd5..ac841ae8f5cc 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
@@ -223,7 +223,6 @@ int amdgpu_amdkfd_get_dmabuf_info(struct amdgpu_device
*adev, int dma_buf_fd,
uint64_t *bo_size, void *metadata_buffer,
size_t buffer_size, uint32_t *metadata_size,
uint32_t *flags);
-uint64_t amdgpu_amdkfd_get_vram_usage(struct amdgpu_device *adev);
uint8_t amdgpu_amdkfd_get_xgmi_hops_count(struct amdgpu_device *dst,
struct amdgpu_device *src);
int amdgpu_amdkfd_get_xgmi_bandwidth_mbytes(struct amdgpu_device *dst,
--
2.33.1
[PATCH REBASED 3/4] drm/amdgpu: do not pass ttm_resource_manager to vram_mgr
Do not allow exported amdgpu_vram_mgr_*() to accept
any ttm_resource_manager pointer. Also there is no need
to force other module to call a ttm function just to
eventually call vram_mgr functions.
v2: pass adev's vram_mgr instead of adev
Reviewed-by: Christian König
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 5 +--
drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 10 ++---
drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 6 +--
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h | 8 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c | 5 +--
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 40
6 files changed, 30 insertions(+), 44 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index 76fe5b71e35d..7e745164a624 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -298,7 +298,6 @@ static void amdgpu_cs_get_threshold_for_moves(struct
amdgpu_device *adev,
{
s64 time_us, increment_us;
u64 free_vram, total_vram, used_vram;
- struct ttm_resource_manager *vram_man =
ttm_manager_type(>mman.bdev, TTM_PL_VRAM);
/* Allow a maximum of 200 accumulated ms. This is basically per-IB
* throttling.
*
@@ -315,7 +314,7 @@ static void amdgpu_cs_get_threshold_for_moves(struct
amdgpu_device *adev,
}
total_vram = adev->gmc.real_vram_size -
atomic64_read(>vram_pin_size);
- used_vram = amdgpu_vram_mgr_usage(vram_man);
+ used_vram = amdgpu_vram_mgr_usage(>mman.vram_mgr);
free_vram = used_vram >= total_vram ? 0 : total_vram - used_vram;
spin_lock(>mm_stats.lock);
@@ -362,7 +361,7 @@ static void amdgpu_cs_get_threshold_for_moves(struct
amdgpu_device *adev,
if (!amdgpu_gmc_vram_full_visible(>gmc)) {
u64 total_vis_vram = adev->gmc.visible_vram_size;
u64 used_vis_vram =
- amdgpu_vram_mgr_vis_usage(vram_man);
+ amdgpu_vram_mgr_vis_usage(>mman.vram_mgr);
if (used_vis_vram < total_vis_vram) {
u64 free_vis_vram = total_vis_vram - used_vis_vram;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
index 763de822afa1..289521aafb79 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
@@ -672,10 +672,10 @@ int amdgpu_info_ioctl(struct drm_device *dev, void *data,
struct drm_file *filp)
ui64 = atomic64_read(>num_vram_cpu_page_faults);
return copy_to_user(out, , min(size, 8u)) ? -EFAULT : 0;
case AMDGPU_INFO_VRAM_USAGE:
- ui64 = amdgpu_vram_mgr_usage(ttm_manager_type(>mman.bdev,
TTM_PL_VRAM));
+ ui64 = amdgpu_vram_mgr_usage(>mman.vram_mgr);
return copy_to_user(out, , min(size, 8u)) ? -EFAULT : 0;
case AMDGPU_INFO_VIS_VRAM_USAGE:
- ui64 =
amdgpu_vram_mgr_vis_usage(ttm_manager_type(>mman.bdev, TTM_PL_VRAM));
+ ui64 = amdgpu_vram_mgr_vis_usage(>mman.vram_mgr);
return copy_to_user(out, , min(size, 8u)) ? -EFAULT : 0;
case AMDGPU_INFO_GTT_USAGE:
ui64 = amdgpu_gtt_mgr_usage(>mman.gtt_mgr);
@@ -709,8 +709,6 @@ int amdgpu_info_ioctl(struct drm_device *dev, void *data,
struct drm_file *filp)
}
case AMDGPU_INFO_MEMORY: {
struct drm_amdgpu_memory_info mem;
- struct ttm_resource_manager *vram_man =
- ttm_manager_type(>mman.bdev, TTM_PL_VRAM);
struct ttm_resource_manager *gtt_man =
ttm_manager_type(>mman.bdev, TTM_PL_TT);
memset(, 0, sizeof(mem));
@@ -719,7 +717,7 @@ int amdgpu_info_ioctl(struct drm_device *dev, void *data,
struct drm_file *filp)
atomic64_read(>vram_pin_size) -
AMDGPU_VM_RESERVED_VRAM;
mem.vram.heap_usage =
- amdgpu_vram_mgr_usage(vram_man);
+ amdgpu_vram_mgr_usage(>mman.vram_mgr);
mem.vram.max_allocation = mem.vram.usable_heap_size * 3 / 4;
mem.cpu_accessible_vram.total_heap_size =
@@ -729,7 +727,7 @@ int amdgpu_info_ioctl(struct drm_device *dev, void *data,
struct drm_file *filp)
atomic64_read(>visible_pin_size),
mem.vram.usable_heap_size);
mem.cpu_accessible_vram.heap_usage =
- amdgpu_vram_mgr_vis_usage(vram_man);
+ amdgpu_vram_mgr_vis_usage(>mman.vram_mgr);
mem.cpu_accessible_vram.max_allocation =
mem.cpu_accessible_vram.usable_heap_size * 3 / 4;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
index 3f5bf5780ebf..4a9970423e7d 100644
---
[PATCH REBASED 1/4] drm/amdgpu: do not pass ttm_resource_manager to gtt_mgr
Do not allow exported amdgpu_gtt_mgr_*() to accept
any ttm_resource_manager pointer. Also there is no need
to force other module to call a ttm function just to
eventually call gtt_mgr functions.
v4: remove unused adev.
v3: upcast mgr from ttm resopurce manager instead of
getting it from adev.
v2: pass adev's gtt_mgr instead of adev.
Reviewed-by: Christian König
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c | 22 ++---
drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 4 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h | 4 ++--
4 files changed, 16 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 3aab187520c6..58b9a5176082 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -4357,7 +4357,7 @@ static int amdgpu_device_reset_sriov(struct amdgpu_device
*adev,
amdgpu_virt_init_data_exchange(adev);
/* we need recover gart prior to run SMC/CP/SDMA resume */
- amdgpu_gtt_mgr_recover(ttm_manager_type(>mman.bdev, TTM_PL_TT));
+ amdgpu_gtt_mgr_recover(>mman.gtt_mgr);
r = amdgpu_device_fw_loading(adev);
if (r)
@@ -4677,7 +4677,7 @@ int amdgpu_do_asic_reset(struct list_head
*device_list_handle,
amdgpu_inc_vram_lost(tmp_adev);
}
- r =
amdgpu_gtt_mgr_recover(ttm_manager_type(_adev->mman.bdev, TTM_PL_TT));
+ r =
amdgpu_gtt_mgr_recover(_adev->mman.gtt_mgr);
if (r)
goto out;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
index c18f16b3be9c..9151950e0cc3 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
@@ -77,10 +77,8 @@ static ssize_t amdgpu_mem_info_gtt_used_show(struct device
*dev,
{
struct drm_device *ddev = dev_get_drvdata(dev);
struct amdgpu_device *adev = drm_to_adev(ddev);
- struct ttm_resource_manager *man;
- man = ttm_manager_type(>mman.bdev, TTM_PL_TT);
- return sysfs_emit(buf, "%llu\n", amdgpu_gtt_mgr_usage(man));
+ return sysfs_emit(buf, "%llu\n",
amdgpu_gtt_mgr_usage(>mman.gtt_mgr));
}
static DEVICE_ATTR(mem_info_gtt_total, S_IRUGO,
@@ -206,14 +204,15 @@ static void amdgpu_gtt_mgr_del(struct
ttm_resource_manager *man,
/**
* amdgpu_gtt_mgr_usage - return usage of GTT domain
*
- * @man: TTM memory type manager
+ * @mgr: amdgpu_gtt_mgr pointer
*
* Return how many bytes are used in the GTT domain
*/
-uint64_t amdgpu_gtt_mgr_usage(struct ttm_resource_manager *man)
+uint64_t amdgpu_gtt_mgr_usage(struct amdgpu_gtt_mgr *mgr)
{
- struct amdgpu_gtt_mgr *mgr = to_gtt_mgr(man);
- s64 result = man->size - atomic64_read(>available);
+ s64 result;
+
+ result = mgr->manager.size - atomic64_read(>available);
return (result > 0 ? result : 0) * PAGE_SIZE;
}
@@ -221,16 +220,15 @@ uint64_t amdgpu_gtt_mgr_usage(struct ttm_resource_manager
*man)
/**
* amdgpu_gtt_mgr_recover - re-init gart
*
- * @man: TTM memory type manager
+ * @mgr: amdgpu_gtt_mgr pointer
*
* Re-init the gart for each known BO in the GTT.
*/
-int amdgpu_gtt_mgr_recover(struct ttm_resource_manager *man)
+int amdgpu_gtt_mgr_recover(struct amdgpu_gtt_mgr *mgr)
{
- struct amdgpu_gtt_mgr *mgr = to_gtt_mgr(man);
- struct amdgpu_device *adev;
struct amdgpu_gtt_node *node;
struct drm_mm_node *mm_node;
+ struct amdgpu_device *adev;
int r = 0;
adev = container_of(mgr, typeof(*adev), mman.gtt_mgr);
@@ -267,7 +265,7 @@ static void amdgpu_gtt_mgr_debug(struct
ttm_resource_manager *man,
drm_printf(printer, "man size:%llu pages, gtt available:%lld pages,
usage:%lluMB\n",
man->size, (u64)atomic64_read(>available),
- amdgpu_gtt_mgr_usage(man) >> 20);
+ amdgpu_gtt_mgr_usage(mgr) >> 20);
}
static const struct ttm_resource_manager_func amdgpu_gtt_mgr_func = {
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
index 651c7abfde03..763de822afa1 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
@@ -678,7 +678,7 @@ int amdgpu_info_ioctl(struct drm_device *dev, void *data,
struct drm_file *filp)
ui64 =
amdgpu_vram_mgr_vis_usage(ttm_manager_type(>mman.bdev, TTM_PL_VRAM));
return copy_to_user(out, , min(size, 8u)) ? -EFAULT : 0;
case AMDGPU_INFO_GTT_USAGE:
- ui64 = amdgpu_gtt_mgr_usage(ttm_manager_type(>mman.bdev,
TTM_PL_TT));
+ ui64 = amdgpu_gtt_mgr_usage(>mman.gtt_mgr);
