Re: [PATCH v2 1/4] drm/amdgpu: add pmlog structure definition

[StDenis, Tom]

[AMD Official Use Only - General]

I'm lost are we talking about the pmlog?  umr currently just uses the 
pmfw_version as a key to find the correct decoding table.

Is that value not specific to a given table version?

Tom


From: Lazar, Lijo 
Sent: Friday, October 6, 2023 08:36
To: Wang, Yang(Kevin); amd-gfx@lists.freedesktop.org; Deucher, Alexander; 
StDenis, Tom
Cc: Zhang, Hawking
Subject: RE: [PATCH v2 1/4] drm/amdgpu: add pmlog structure definition

[AMD Official Use Only - General]

Presently only a byte stream is intended. If version is needed, uint16_t pad 
can be converted to format/content revision.

@Deucher, Alexander/@StDenis, Tom, any comments on keeping a version?

Thanks,
Lijo

-Original Message-
From: Wang, Yang(Kevin) 
Sent: Friday, October 6, 2023 5:08 PM
To: Lazar, Lijo ; amd-gfx@lists.freedesktop.org
Cc: Zhang, Hawking ; Deucher, Alexander 

Subject: RE: [PATCH v2 1/4] drm/amdgpu: add pmlog structure definition

[AMD Official Use Only - General]

Hi Lijo,

I prefer to add a version field in header, which is used for compatible in the 
future, what is your idea?
When the user attempts to parse this node, they cannot accurately determine the 
format of the content.

Best Regards,
Kevin

-Original Message-
From: Lazar, Lijo 
Sent: Friday, October 6, 2023 1:22 PM
To: amd-gfx@lists.freedesktop.org
Cc: Zhang, Hawking ; Deucher, Alexander 
; Wang, Yang(Kevin) ; 
Deucher, Alexander 
Subject: [PATCH v2 1/4] drm/amdgpu: add pmlog structure definition

From: Alex Deucher 

Define the pmlog structures to be exposed via sysfs.

Signed-off-by: Alex Deucher 
Signed-off-by: Lijo Lazar 
---
 drivers/gpu/drm/amd/include/kgd_pp_interface.h | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/drivers/gpu/drm/amd/include/kgd_pp_interface.h 
b/drivers/gpu/drm/amd/include/kgd_pp_interface.h
index e0bb6d39f0c3..9905228fd89c 100644
--- a/drivers/gpu/drm/amd/include/kgd_pp_interface.h
+++ b/drivers/gpu/drm/amd/include/kgd_pp_interface.h
@@ -980,4 +980,19 @@ struct gpu_metrics_v2_4 {
uint16_taverage_soc_current;
uint16_taverage_gfx_current;
 };
+
+struct amdgpu_pmlog_header {
+   uint16_t structure_size;
+   uint16_t pad;
+   uint32_t mp1_ip_discovery_version;
+   uint32_t pmfw_version;
+   uint32_t pmlog_version;
+};
+
+struct amdgpu_pmlog {
+   struct amdgpu_pmlog_header common_header;
+
+   uint8_t data[];
+};
+
 #endif
--
2.25.1

Re: [PATCH umr 02/17] Use the correct prefix for Navi3 in halt_waves

[StDenis, Tom]

[Public]

This shouldn't be necessary as it tries both mm and then reg...



From: Haehnle, Nicolai 
Sent: Tuesday, June 6, 2023 05:17
To: amd-gfx@lists.freedesktop.org; StDenis, Tom
Cc: Haehnle, Nicolai
Subject: [PATCH umr 02/17] Use the correct prefix for Navi3 in halt_waves

Signed-off-by: Nicolai Hähnle 
---
 src/lib/sq_cmd_halt_waves.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/lib/sq_cmd_halt_waves.c b/src/lib/sq_cmd_halt_waves.c
index 368e701..841b1d3 100644
--- a/src/lib/sq_cmd_halt_waves.c
+++ b/src/lib/sq_cmd_halt_waves.c
@@ -36,21 +36,22 @@ int umr_sq_cmd_halt_waves(struct umr_asic *asic, enum 
umr_sq_cmd_halt_resume mod
uint32_t value;
uint64_t addr;
struct {
uint32_t se, sh, instance, use_grbm;
} grbm;

// SQ_CMD is not present on SI
if (asic->family == FAMILY_SI)
return 0;

-   reg = umr_find_reg_data_by_ip_by_instance(asic, "gfx", 
asic->options.vm_partition, "mmSQ_CMD");
+   reg = umr_find_reg_data_by_ip_by_instance(asic, "gfx", 
asic->options.vm_partition,
+ asic->family >= FAMILY_GFX11 
? "regSQ_CMD" : "mmSQ_CMD");
if (!reg) {
asic->err_msg("[BUG]: Cannot find SQ_CMD register in 
umr_sq_cmd_halt_waves()\n");
return -1;
}

// compose value
if (asic->family == FAMILY_CIK) {
value = umr_bitslice_compose_value(asic, reg, "CMD", mode == 
UMR_SQ_CMD_HALT ? 1 : 2); // SETHALT
} else {
value = umr_bitslice_compose_value(asic, reg, "CMD", 1); // 
SETHALT
--
2.40.0

Re: Fix for UMR on newer C++

[StDenis, Tom]

Thanks I'll apply it upon the morrow

From: Newton, Jeremy 
Sent: Monday, January 23, 2023 18:04
To: amd-gfx@lists.freedesktop.org 
Cc: StDenis, Tom 
Subject: Fix for UMR on newer C++


[AMD Official Use Only - General]


I noticed this today; it's required to explicitly include "" in newer 
GCC's, which I think has to do with newer C++ standards.

None the less, see the attached patch.

Re: [PATCH] drm/amdgpu: expand cg_flags from u32 to u64

[StDenis, Tom]

[AMD Official Use Only]

I'll update umr once this goes live.  Unless you have a umr patch handy :-)

Tom


From: Zhang, Hawking 
Sent: Thursday, March 31, 2022 00:12
To: Quan, Evan; amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander; StDenis, Tom; Quan, Evan
Subject: RE: [PATCH] drm/amdgpu: expand cg_flags from u32 to u64

[AMD Official Use Only]

Reviewed-by: Hawking Zhang 

Regards,
Hawking
-Original Message-
From: amd-gfx  On Behalf Of Evan Quan
Sent: Thursday, March 31, 2022 11:33
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander ; StDenis, Tom 
; Quan, Evan 
Subject: [PATCH] drm/amdgpu: expand cg_flags from u32 to u64

With this, we can support more CG flags.

Signed-off-by: Evan Quan 
Acked-by: Alex Deucher 
Change-Id: Iccf13c2f9c570ca6a4654291fc4876556125c3b8
--
v1->v2:
  - amdgpu_debugfs_gca_config_read: add a new rev to
support CG flag upper 32 bits(Alex)
---
 drivers/gpu/drm/amd/amdgpu/amdgpu.h |  6 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c |  5 +-  
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c  |  2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_df.h  |  2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c |  8 +--
 drivers/gpu/drm/amd/amdgpu/amdgpu_hdp.h |  2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_mmhub.h   |  2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_nbio.h|  2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_smuio.h   |  2 +-
 drivers/gpu/drm/amd/amdgpu/athub_v1_0.c |  2 +-
 drivers/gpu/drm/amd/amdgpu/athub_v1_0.h |  2 +-
 drivers/gpu/drm/amd/amdgpu/athub_v2_0.c |  2 +-
 drivers/gpu/drm/amd/amdgpu/athub_v2_0.h |  2 +-
 drivers/gpu/drm/amd/amdgpu/athub_v2_1.c |  2 +-
 drivers/gpu/drm/amd/amdgpu/athub_v2_1.h |  2 +-
 drivers/gpu/drm/amd/amdgpu/df_v1_7.c|  2 +-
 drivers/gpu/drm/amd/amdgpu/df_v3_6.c|  2 +-
 drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c  |  2 +-
 drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c   |  2 +-
 drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c   |  2 +-
 drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c  |  2 +-
 drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c   |  2 +-
 drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c   |  2 +-
 drivers/gpu/drm/amd/amdgpu/hdp_v4_0.c   |  2 +-
 drivers/gpu/drm/amd/amdgpu/hdp_v5_0.c   |  2 +-
 drivers/gpu/drm/amd/amdgpu/mmhub_v1_0.c |  2 +-
 drivers/gpu/drm/amd/amdgpu/mmhub_v1_7.c |  2 +-
 drivers/gpu/drm/amd/amdgpu/mmhub_v2_0.c |  2 +-
 drivers/gpu/drm/amd/amdgpu/mmhub_v2_3.c |  2 +-
 drivers/gpu/drm/amd/amdgpu/mmhub_v9_4.c |  2 +-
 drivers/gpu/drm/amd/amdgpu/navi10_ih.c  |  2 +-
 drivers/gpu/drm/amd/amdgpu/nbio_v2_3.c  |  2 +-
 drivers/gpu/drm/amd/amdgpu/nbio_v6_1.c  |  2 +-
 drivers/gpu/drm/amd/amdgpu/nbio_v7_0.c  |  2 +-
 drivers/gpu/drm/amd/amdgpu/nbio_v7_2.c  |  2 +-
 drivers/gpu/drm/amd/amdgpu/nbio_v7_4.c  |  2 +-
 drivers/gpu/drm/amd/amdgpu/nv.c |  2 +-
 drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c  |  2 +-
 drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c  |  2 +-
 drivers/gpu/drm/amd/amdgpu/sdma_v5_0.c  |  2 +-
 drivers/gpu/drm/amd/amdgpu/sdma_v5_2.c  |  2 +-
 drivers/gpu/drm/amd/amdgpu/smuio_v11_0.c|  2 +-
 drivers/gpu/drm/amd/amdgpu/smuio_v11_0_6.c  |  2 +-
 drivers/gpu/drm/amd/amdgpu/smuio_v13_0.c|  2 +-
 drivers/gpu/drm/amd/amdgpu/smuio_v9_0.c |  2 +-
 drivers/gpu/drm/amd/amdgpu/soc15.c  |  2 +-
 drivers/gpu/drm/amd/amdgpu/uvd_v5_0.c   |  2 +-
 drivers/gpu/drm/amd/amdgpu/uvd_v6_0.c   |  2 +-
 drivers/gpu/drm/amd/amdgpu/vce_v3_0.c   |  2 +-
 drivers/gpu/drm/amd/amdgpu/vi.c |  2 +-
 drivers/gpu/drm/amd/include/amd_shared.h| 66 ++---
 drivers/gpu/drm/amd/pm/amdgpu_pm.c  |  4 +-
 drivers/gpu/drm/amd/pm/inc/amdgpu_pm.h  |  2 +-
 53 files changed, 94 insertions(+), 91 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 22eeddd01014..dfc5b46c6a11 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -179,7 +179,7 @@ extern int amdgpu_sched_jobs;  extern int 
amdgpu_sched_hw_submission;  extern uint amdgpu_pcie_gen_cap;  extern uint 
amdgpu_pcie_lane_cap; -extern uint amdgpu_cg_mask;
+extern u64 amdgpu_cg_mask;
 extern uint amdgpu_pg_mask;
 extern uint amdgpu_sdma_phase_quantum;
 extern char *amdgpu_disable_cu;
@@ -322,7 +322,7 @@ int amdgpu_device_ip_set_powergating_state(void *dev,
   enum amd_ip_block_type block_type,
   enum amd_powergating_state state);  
void amdgpu_device_ip_get_clockgating_state(struct amdgpu_device *adev,
-   u32 *flags);
+   u64 *flags);
 int amdgpu_device_ip_wait_for_idle(struct amdgpu_device *adev,
   enum amd_ip_block_type block_type);  bool 
amdgpu_device_ip_is_idle(struct amdgpu_device *adev, @@ -860,7 +860,7 @@ str

Re: [PATCH 5/5] umr: Completion: update new format options

[StDenis, Tom]

[AMD Official Use Only]

Thanks Luben, I've committed and pushed out these patches.

Cheers,
Tom


From: Tuikov, Luben 
Sent: Sunday, March 27, 2022 06:42
To: amd-gfx@lists.freedesktop.org
Cc: Tuikov, Luben; StDenis, Tom; Su, Jinzhou (Joe)
Subject: [PATCH 5/5] umr: Completion: update new format options

Update completion for "--ppt-read" and "--gpu-metrics".

Cc: Tom StDenis 
Cc: Jinzhou.Su 
Signed-off-by: Luben Tuikov 
---
 scripts/umr-completion.bash | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/umr-completion.bash b/scripts/umr-completion.bash
index 0e1444357c82a9..bd0b61b2d38831 100644
--- a/scripts/umr-completion.bash
+++ b/scripts/umr-completion.bash
@@ -333,7 +333,7 @@ _umr_comp_ring_stream()

 _umr_completion()
 {
-local ALL_LONG_ARGS=(--database-path --option --gpu --instance --force 
--pci --gfxoff --vm_partition --bank --sbank --cbank --config --enumerate 
--list-blocks --list-regs --dump-discovery-table --lookup --write --writebit 
--read --scan --logscan --top --waves --profiler --vm-decode --vm-read 
--vm-write --vm-write-word --vm-disasm --ring-stream --dump-ib --dump-ib-file 
--header-dump --power --clock-scan --clock-manual --clock-high --clock-low 
--clock-auto --ppt_read --gpu_metrics --power --vbios_info --test-log 
--test-harness --server --gui)
+local ALL_LONG_ARGS=(--database-path --option --gpu --instance --force 
--pci --gfxoff --vm_partition --bank --sbank --cbank --config --enumerate 
--list-blocks --list-regs --dump-discovery-table --lookup --write --writebit 
--read --scan --logscan --top --waves --profiler --vm-decode --vm-read 
--vm-write --vm-write-word --vm-disasm --ring-stream --dump-ib --dump-ib-file 
--header-dump --power --clock-scan --clock-manual --clock-high --clock-low 
--clock-auto --ppt-read --gpu-metrics --power --vbios_info --test-log 
--test-harness --server --gui)

 local cur prev

--
2.35.1.607.gf01e51a7cf

Re: [PATCH 0/6] Complete and add dynamic completion to umr

[StDenis, Tom]

[AMD Official Use Only]

Thanks Luben, I've added my Rb and pushed out the series to main.

Cheers,
Tom


From: Tuikov, Luben 
Sent: Wednesday, March 23, 2022 07:48
To: amd-gfx@lists.freedesktop.org
Cc: Tuikov, Luben; Deucher, Alexander; Pelloux-Prayer, Pierre-Eric; StDenis, 
Tom; Koenig, Christian
Subject: [PATCH 0/6] Complete and add dynamic completion to umr

Complete and add dynamic completion to umr.

Some of the difficulties seen in this work were,

*) slightly different output of sysfs files depending on the system
   configuration and the number of controllers in the system.

*) Merging of the IP Discovery sysfs discovery mechanism.

*) The varied and finicky user input strings.

This work was tested on two different systems with different ASICs,
with three distinct configurations, one of which includes two
different AMD GPU controllers in the same system.

Luben Tuikov (6):
  umr: Rename "scripts/umr" --> "scripts/umr-completion.bash"
  umr: Rename completion function
  umr: Complete umr completion
  umr: Replace and reuse asic.ipblock.reg completion
  umr: Replace and reuse ipblock completion
  umr: Add FILES section to the man page

Cc: Alex Deucher 
Cc: Pierre-Eric Pelloux-Prayer 
Cc: Tom StDenis 
Cc: Christian König 

 doc/umr.1   |  13 +-
 scripts/umr |  83 
 scripts/umr-completion.bash | 402 
 src/app/CMakeLists.txt  |   2 +-
 4 files changed, 414 insertions(+), 86 deletions(-)
 delete mode 100644 scripts/umr
 create mode 100644 scripts/umr-completion.bash


base-commit: d773ac6b1f529c02d8d2021d69e2dcfad736628d
--
2.35.1.607.gf01e51a7cf

Re: [PATCH 4/4] umr: Fix unhandled enumeration value in switch

[StDenis, Tom]

[AMD Official Use Only]

Patches 2-4 look great.  With #1 swapped out to use asic->errmsg() you can 
throw my Rb on them.

Tom


From: Tuikov, Luben 
Sent: Wednesday, March 9, 2022 19:42
To: amd-gfx@lists.freedesktop.org
Cc: Tuikov, Luben; Deucher, Alexander; StDenis, Tom
Subject: [PATCH 4/4] umr: Fix unhandled enumeration value in switch

Add a default case in the switch, instead of the last unhandled value,
FAMILY_CONFIGURE. This solves the case when in the future other families
are not handled--they'll all fall into the default case.

Also, in the diagnostic print, print the value of the unhandled
enumeration--this could help debug easily, as opposed to having to
reproduce the issue locally.

Cc: Alex Deucher 
Cc: Tom StDenis 
Signed-off-by: Luben Tuikov 
---
 src/lib/ih_decode_vectors.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/lib/ih_decode_vectors.c b/src/lib/ih_decode_vectors.c
index ed5705059c542f..f2057df825f5c0 100644
--- a/src/lib/ih_decode_vectors.c
+++ b/src/lib/ih_decode_vectors.c
@@ -77,11 +77,11 @@ int umr_ih_decode_vectors(struct umr_asic *asic, struct 
umr_ih_decode_ui *ui, ui
}
return off / 8;

-   case FAMILY_CONFIGURE:
case FAMILY_SI:
case FAMILY_CIK:
case FAMILY_NPI:
-   asic->err_msg("[BUG]: unhandled family case in 
umr_ih_decode_vectors()\n");
+   default:
+   asic->err_msg("[BUG]: unhandled family case:%d in 
umr_ih_decode_vectors()\n", asic->family);
return -1;
}
return 0;
--
2.35.1.291.gdab1b7905d

Re: [PATCH 1/4] umr: Print errors to stderr

[StDenis, Tom]

[AMD Official Use Only]

The asic structure has a function callback "errmsg" which should be used for 
this.

Tom


From: Tuikov, Luben 
Sent: Wednesday, March 9, 2022 19:42
To: amd-gfx@lists.freedesktop.org
Cc: Tuikov, Luben; Deucher, Alexander; StDenis, Tom
Subject: [PATCH 1/4] umr: Print errors to stderr

Print the following error message,
   Invalid gca config data header
to stderr, since printing it to stdout,
confuses parser scripts.

Also modify this message to be clearer. For instance,
   Invalid or unknown GCA config data header version:4

Cc: Alex Deucher 
Cc: Tom StDenis 
Signed-off-by: Luben Tuikov 
---
 src/lib/scan_config.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/src/lib/scan_config.c b/src/lib/scan_config.c
index c7f4e9d3c69faa..3503bbd92a104a 100644
--- a/src/lib/scan_config.c
+++ b/src/lib/scan_config.c
@@ -122,7 +122,7 @@ static uint64_t read_int_drm(int cardno, char *fname)
 }

 /**
- * umr_scan_config - Scan the debugfs confiruration data
+ * umr_scan_config - Scan the debugfs configuration data
  */
 int umr_scan_config(struct umr_asic *asic, int xgmi_scan)
 {
@@ -246,7 +246,9 @@ gca_config:
case 4: parse_rev4(asic, data, );
break;
default:
-   printf("Invalid gca config data header\n");
+   fprintf(stderr,
+   "Invalid or unknown GCA config data header 
version:%d\n",
+   data[0]);
return -1;
}


base-commit: 818bb1e8f1b5a26fda0e3d7abfc1e68605ebad28
--
2.35.1.291.gdab1b7905d

Re: [PATCH] drm/amdgpu: Dynamically initialize IP instance attributes

[StDenis, Tom]

[AMD Official Use Only]

I can do IP name substitutions but that's kinda not the point.  We put headers 
called "vcn_x_y_z*.h" in the source tree but call the IP block UVD.

As for SDMA ... the IP discovery has entries for SDMA0 and SDMA1 IP blocks on 
my navi10...

[root@fedora umr]# cat 
/sys/class/drm/card0/device/ip_discovery/die/0/SDMA0/0/major
5
[root@fedora umr]# cat 
/sys/class/drm/card0/device/ip_discovery/die/0/SDMA1/0/major
5

If they're "behind the GC block" then there really isn't an SDMA block right?

Right now umr just ignores anything it can't pair up but I imagine it'll cause 
some confusion later on.

Tom


From: Alex Deucher 
Sent: Thursday, February 17, 2022 13:32
To: StDenis, Tom
Cc: Tuikov, Luben; amd-gfx@lists.freedesktop.org; Deucher, Alexander
Subject: Re: [PATCH] drm/amdgpu: Dynamically initialize IP instance attributes

On Thu, Feb 17, 2022 at 1:25 PM StDenis, Tom  wrote:
>
> [AMD Official Use Only]
>
> This works, now I'm facing other issues.  Like we call the VCN block on 
> navi10 a "uvd 2.0.0".  Originally I was only accepting exact major hits which 
> meant my navi10 model had no video enc/dec block once I programmed it to take 
> the closest match it hit UVD 4.0.0 (pre-soc15/etc) and that's obviously wrong.
>  Shouldn't IP discovered video enc/dec be name VCN?

They used the UVD name since VCN was derived from UVD.  Not sure why
they didn't rename it.  Still, all asics that use IP discovery use
VCN, so no need to worry about UVD/VCE for IP discovery.

>
> On a semi related note we have no SDMA v5.x.y headers in the tree but navi10+ 
> uses it.  I guess the driver just uses SDMA 4.x.y headers because they're 
> close enough but it means umr won't load in an SDMA model.
>

For navi10+, SDMA moved into the graphics block so the SDMA registers
are part of the GC headers on navi1x and newer.

> Which then gets us into weird conditions.  Right now I'm programming umr to 
> find the closet abs() major hit, then minor, then revision.  But I imagine 
> we'll hit cases where say version X.Y+1.Z is better than X.Y-1.Z and vice 
> versa (etc with the other fields).   There's no way for umr to know if a 
> newer or older header is better.
>
> Tom
>
> 
> From: Tuikov, Luben 
> Sent: Thursday, February 17, 2022 11:35
> To: amd-gfx@lists.freedesktop.org
> Cc: Tuikov, Luben; Deucher, Alexander; StDenis, Tom
> Subject: [PATCH] drm/amdgpu: Dynamically initialize IP instance attributes
>
> Dynamically initialize IP instance attributes. This eliminates bugs
> stemming from adding new attributes to an IP instance.
>
> Cc: Alex Deucher 
> Reported-by: Tom StDenis 
> Fixes: c10b6aa7417b0a ("drm/amdgpu: Add "harvest" to IP discovery sysfs")
> Signed-off-by: Luben Tuikov 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c | 17 ++---
>  1 file changed, 6 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
> index 6c7ec058125e1d..5848fec5c39251 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
> @@ -482,16 +482,7 @@ static struct ip_hw_instance_attr ip_hw_attr[] = {
> __ATTR_RO(base_addr),
>  };
>
> -static struct attribute *ip_hw_instance_attrs[] = {
> -   _hw_attr[0].attr,
> -   _hw_attr[1].attr,
> -   _hw_attr[2].attr,
> -   _hw_attr[3].attr,
> -   _hw_attr[4].attr,
> -   _hw_attr[5].attr,
> -   _hw_attr[6].attr,
> -   NULL,
> -};
> +static struct attribute *ip_hw_instance_attrs[ARRAY_SIZE(ip_hw_attr) + 1];
>  ATTRIBUTE_GROUPS(ip_hw_instance);
>
>  #define to_ip_hw_instance(x) container_of(x, struct ip_hw_instance, kobj)
> @@ -789,7 +780,7 @@ static int amdgpu_discovery_sysfs_recurse(struct 
> amdgpu_device *adev)
>  static int amdgpu_discovery_sysfs_init(struct amdgpu_device *adev)
>  {
> struct kset *die_kset;
> -   int res;
> +   int res, ii;
>
> adev->ip_top = kzalloc(sizeof(*adev->ip_top), GFP_KERNEL);
> if (!adev->ip_top)
> @@ -814,6 +805,10 @@ static int amdgpu_discovery_sysfs_init(struct 
> amdgpu_device *adev)
> goto Err;
> }
>
> +   for (ii = 0; ii < ARRAY_SIZE(ip_hw_attr); ii++)
> +   ip_hw_instance_attrs[ii] = _hw_attr[ii].attr;
> +   ip_hw_instance_attrs[ii] = NULL;
> +
> res = amdgpu_discovery_sysfs_recurse(adev);
>
> return res;
>
> base-commit: f736148ca7bf82654141a4411409c2d7a9e2269b
> --
> 2.35.1.129.gb80121027d
>

Re: [PATCH] drm/amdgpu: Dynamically initialize IP instance attributes

[StDenis, Tom]

[AMD Official Use Only]

This works, now I'm facing other issues.  Like we call the VCN block on navi10 
a "uvd 2.0.0".  Originally I was only accepting exact major hits which meant my 
navi10 model had no video enc/dec block once I programmed it to take the 
closest match it hit UVD 4.0.0 (pre-soc15/etc) and that's obviously wrong.
 Shouldn't IP discovered video enc/dec be name VCN?

On a semi related note we have no SDMA v5.x.y headers in the tree but navi10+ 
uses it.  I guess the driver just uses SDMA 4.x.y headers because they're close 
enough but it means umr won't load in an SDMA model.

Which then gets us into weird conditions.  Right now I'm programming umr to 
find the closet abs() major hit, then minor, then revision.  But I imagine 
we'll hit cases where say version X.Y+1.Z is better than X.Y-1.Z and vice versa 
(etc with the other fields).   There's no way for umr to know if a newer or 
older header is better.

Tom


From: Tuikov, Luben 
Sent: Thursday, February 17, 2022 11:35
To: amd-gfx@lists.freedesktop.org
Cc: Tuikov, Luben; Deucher, Alexander; StDenis, Tom
Subject: [PATCH] drm/amdgpu: Dynamically initialize IP instance attributes

Dynamically initialize IP instance attributes. This eliminates bugs
stemming from adding new attributes to an IP instance.

Cc: Alex Deucher 
Reported-by: Tom StDenis 
Fixes: c10b6aa7417b0a ("drm/amdgpu: Add "harvest" to IP discovery sysfs")
Signed-off-by: Luben Tuikov 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c | 17 ++---
 1 file changed, 6 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
index 6c7ec058125e1d..5848fec5c39251 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
@@ -482,16 +482,7 @@ static struct ip_hw_instance_attr ip_hw_attr[] = {
__ATTR_RO(base_addr),
 };

-static struct attribute *ip_hw_instance_attrs[] = {
-   _hw_attr[0].attr,
-   _hw_attr[1].attr,
-   _hw_attr[2].attr,
-   _hw_attr[3].attr,
-   _hw_attr[4].attr,
-   _hw_attr[5].attr,
-   _hw_attr[6].attr,
-   NULL,
-};
+static struct attribute *ip_hw_instance_attrs[ARRAY_SIZE(ip_hw_attr) + 1];
 ATTRIBUTE_GROUPS(ip_hw_instance);

 #define to_ip_hw_instance(x) container_of(x, struct ip_hw_instance, kobj)
@@ -789,7 +780,7 @@ static int amdgpu_discovery_sysfs_recurse(struct 
amdgpu_device *adev)
 static int amdgpu_discovery_sysfs_init(struct amdgpu_device *adev)
 {
struct kset *die_kset;
-   int res;
+   int res, ii;

adev->ip_top = kzalloc(sizeof(*adev->ip_top), GFP_KERNEL);
if (!adev->ip_top)
@@ -814,6 +805,10 @@ static int amdgpu_discovery_sysfs_init(struct 
amdgpu_device *adev)
goto Err;
}

+   for (ii = 0; ii < ARRAY_SIZE(ip_hw_attr); ii++)
+   ip_hw_instance_attrs[ii] = _hw_attr[ii].attr;
+   ip_hw_instance_attrs[ii] = NULL;
+
res = amdgpu_discovery_sysfs_recurse(adev);

return res;

base-commit: f736148ca7bf82654141a4411409c2d7a9e2269b
--
2.35.1.129.gb80121027d

Re: [PATCH] drm/amd/amdgpu: Add APU flag to gca_config debugfs data (v2)

[StDenis, Tom]

[AMD Official Use Only]

umr uses the config debugfs during init anyways so adding apu status here 
instead of fetching it out of DRM makes sense (for umr).

I'll send a v3.

Tom


From: Alex Deucher 
Sent: Wednesday, February 16, 2022 09:36
To: StDenis, Tom
Cc: amd-gfx list
Subject: Re: [PATCH] drm/amd/amdgpu: Add APU flag to gca_config debugfs data 
(v2)

On Tue, Feb 15, 2022 at 6:47 PM Tom St Denis  wrote:
>
> Needed by umr to detect if ip discovered ASIC is an APU or not.
>
> (v2): Remove asic type from packet it's not strictly needed
>
> Signed-off-by: Tom St Denis 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
> index 4b950de9bf66..8f0ca71862b1 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
> @@ -728,7 +728,7 @@ static ssize_t amdgpu_debugfs_gca_config_read(struct file 
> *f, char __user *buf,
> return -ENOMEM;
>
> /* version, increment each time something is added */
> -   config[no_regs++] = 3;
> +   config[no_regs++] = 4;
> config[no_regs++] = adev->gfx.config.max_shader_engines;
> config[no_regs++] = adev->gfx.config.max_tile_pipes;
> config[no_regs++] = adev->gfx.config.max_cu_per_sh;
> @@ -768,6 +768,9 @@ static ssize_t amdgpu_debugfs_gca_config_read(struct file 
> *f, char __user *buf,
> config[no_regs++] = adev->pdev->subsystem_device;
> config[no_regs++] = adev->pdev->subsystem_vendor;
>
> +   /* rev==4 asic_type and APU flag */

Fix the comment here. Also, we already expose the APU flag as
AMDGPU_IDS_FLAGS_FUSION via the AMDGPU_INFO_DEV_INFO query to the INFO
ioctl.  If you already use that, you should already have this.  If
not, with the comment fixed:
Reviewed-by: Alex Deucher 

> +   config[no_regs++] = adev->flags & AMD_IS_APU ? 1 : 0;
> +
> while (size && (*pos < no_regs * 4)) {
> uint32_t value;
>
> --
> 2.32.0
>

Re: FIx for UMR arm build

[StDenis, Tom]

[AMD Official Use Only]

Pushed out, with your Rb.




From: Alex Deucher 
Sent: Thursday, January 27, 2022 09:11
To: Newton, Jeremy
Cc: amd-gfx@lists.freedesktop.org; StDenis, Tom
Subject: Re: FIx for UMR arm build

Reviewed-by: Alex Deucher 

On Thu, Jan 27, 2022 at 8:39 AM Newton, Jeremy  wrote:
>
> [AMD Official Use Only]
>
>
> Sorry I think I forgot to attach the patch 
> 
> From: Newton, Jeremy
> Sent: January 27, 2022 8:39 AM
> To: amd-gfx@lists.freedesktop.org 
> Cc: StDenis, Tom 
> Subject: FIx for UMR arm build
>
> I know we only technically only care about x86, but this just fixes a syntax 
> issue if you build on arm.

Re: [PATCH 2/2] drm/amdgpu: add sysfs files for XGMI segment size and physical node id

[StDenis, Tom]

[AMD Official Use Only]

Sadly I don't control any XGMI hosts to try it out.  So if they pick it up in 
their builds I can but otherwise we'll have to wait.

Tom


From: Tuikov, Luben 
Sent: Wednesday, January 26, 2022 07:55
To: Christian König; StDenis, Tom
Cc: amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH 2/2] drm/amdgpu: add sysfs files for XGMI segment size and 
physical node id

This seems reasonable. Hope it works out for umr.

Reviewed-by: Luben Tuikov 

Regards,
Luben

On 2022-01-26 06:59, Christian König wrote:
> umr needs that to correctly calculate the VRAM base address
> inside the MC address space.
>
> Only compile tested!
>
> Signed-off-by: Christian König 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c | 34 
>  1 file changed, 34 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c
> index 68509f619ba3..21a5d07a1abf 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c
> @@ -252,6 +252,26 @@ static ssize_t amdgpu_xgmi_show_device_id(struct device 
> *dev,
>
>  }
>
> +static ssize_t amdgpu_xgmi_show_node_segment_size(struct device *dev,
> +   struct device_attribute *attr,
> +   char *buf)
> +{
> + struct drm_device *ddev = dev_get_drvdata(dev);
> + struct amdgpu_device *adev = drm_to_adev(ddev);
> +
> + return sysfs_emit(buf, "%llu\n", adev->gmc.xgmi.node_segment_size);
> +}
> +
> +static ssize_t amdgpu_xgmi_show_physical_node_id(struct device *dev,
> +  struct device_attribute *attr,
> +  char *buf)
> +{
> + struct drm_device *ddev = dev_get_drvdata(dev);
> + struct amdgpu_device *adev = drm_to_adev(ddev);
> +
> + return sysfs_emit(buf, "%u\n", adev->gmc.xgmi.physical_node_id);
> +}
> +
>  #define AMDGPU_XGMI_SET_FICAA(o) ((o) | 0x456801)
>  static ssize_t amdgpu_xgmi_show_error(struct device *dev,
> struct device_attribute *attr,
> @@ -287,6 +307,10 @@ static ssize_t amdgpu_xgmi_show_error(struct device *dev,
>
>
>  static DEVICE_ATTR(xgmi_device_id, S_IRUGO, amdgpu_xgmi_show_device_id, 
> NULL);
> +static DEVICE_ATTR(xgmi_node_segment_size, S_IRUGO,
> +amdgpu_xgmi_show_node_segment_size, NULL);
> +static DEVICE_ATTR(xgmi_physical_node_id, S_IRUGO,
> +amdgpu_xgmi_show_physical_node_id, NULL);
>  static DEVICE_ATTR(xgmi_error, S_IRUGO, amdgpu_xgmi_show_error, NULL);
>
>  static void amdgpu_xgmi_sysfs_rem_dev_info(struct amdgpu_device *adev,
> @@ -295,6 +319,8 @@ static void amdgpu_xgmi_sysfs_rem_dev_info(struct 
> amdgpu_device *adev,
>   char node[10];
>
>   device_remove_file(adev->dev, _attr_xgmi_device_id);
> + device_remove_file(adev->dev, _attr_xgmi_node_segment_size);
> + device_remove_file(adev->dev, _attr_xgmi_physical_node_id);
>   device_remove_file(adev->dev, _attr_xgmi_error);
>
>   if (hive->kobj.parent != (>dev->kobj))
> @@ -318,6 +344,14 @@ static int amdgpu_xgmi_sysfs_add_dev_info(struct 
> amdgpu_device *adev,
>   if (r)
>   goto error;
>
> + r = device_create_file(adev->dev, _attr_xgmi_node_segment_size);
> + if (r)
> + goto error;
> +
> + r = device_create_file(adev->dev, _attr_xgmi_physical_node_id);
> + if (r)
> + goto error;
> +
>   /* Create sysfs link to hive info folder on the first device */
>   if (hive->kobj.parent != (>dev->kobj)) {
>   r = sysfs_create_link(>dev->kobj, >kobj,

Regards,
--
Luben

Re: [PATCH] drm/amd/amdgpu: Add ip_discovery_text sysfs entry

[StDenis, Tom]

I literally brought this up in our initial discussion

Frankly from umrs point of view a single file is easier.

But I can't code anything until it's in the tree...


Tom





From: Alex Deucher 
Sent: Tuesday, January 25, 2022 11:39
To: StDenis, Tom 
Cc: amd-gfx list 
Subject: Re: [PATCH] drm/amd/amdgpu: Add ip_discovery_text sysfs entry

On Mon, Jan 24, 2022 at 1:07 PM Tom St Denis  wrote:
>
> Newer hardware has a discovery table in hardware that the kernel will
> rely on instead of header files for things like IP offsets.  This
> sysfs entry adds a simple to parse table of IP instances and segment
> offsets.
>
> Produces output that looks like:
>
> $ cat ip_discovery_text
> ATHUB{0} v2.0.0: 0c00 02408c00
> CLKA{0} v11.0.0: 00016c00 02401800
> CLKA{1} v11.0.0: 00016e00 02401c00
> CLKA{2} v11.0.0: 00017000 02402000
> CLKA{3} v11.0.0: 00017200 02402400
> CLKA{4} v11.0.0: 0001b000 0242d800
> CLKB{0} v11.0.0: 00017e00 0240bc00
> DBGU_NBIO{0} v3.0.0: 01c0 02409000
> DBGU0{0} v3.0.0: 0180 02409800
> DBGU1{0} v3.0.0: 01a0 02409c00
> DF{0} v3.0.0: 7000 0240b800
> DFX{0} v4.1.0: 0580 02409400
> DFX_DAP{0} v2.0.0: 05a0 00b8 0240c400
> DMU{0} v2.0.2: 0012 00c0 34c0 9000 02403c00
> FUSE{0} v11.0.0: 00017400 02401400
> GC{0} v10.1.10: 1260 a000 02402c00

I'm not opposed to this, but the general rule is one value per file
with sysfs.  Maybe something like:

$ ls ip_discovery
ATHUB CLKA CLKB DBGU_NBIO DBGU0 DBGU1
$ ls ip_discovery/CLKA
0 1 2 3 4
$ ls ip_discovery/CLKA/0
version offset0 offset1

Alex

>
> Signed-off-by: Tom St Denis 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu.h   |  1 +
>  drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c | 77 ++-
>  2 files changed, 77 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> index 3bc76759c143..6920f73bbe73 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> @@ -1019,6 +1019,7 @@ struct amdgpu_device {
> struct amdgpu_ip_block  ip_blocks[AMDGPU_MAX_IP_NUM];
> uint32_tharvest_ip_mask;
> int num_ip_blocks;
> +   char*ip_discovery_text;
> struct mutexmn_lock;
> DECLARE_HASHTABLE(mn_hash, 7);
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
> index 285811509d94..c64cab0ad18e 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
> @@ -267,6 +267,19 @@ static void amdgpu_discovery_harvest_config_quirk(struct 
> amdgpu_device *adev)
> }
>  }
>
> +static ssize_t ip_discovery_text_show(struct device *dev,
> +   struct device_attribute *attr, char *buf)
> +{
> +   struct drm_device *ddev = dev_get_drvdata(dev);
> +   struct amdgpu_device *adev = drm_to_adev(ddev);
> +
> +   return sysfs_emit(buf, "%s", adev->ip_discovery_text);
> +}
> +
> +static DEVICE_ATTR(ip_discovery_text, S_IRUGO,
> +   ip_discovery_text_show, NULL);
> +
> +
>  static int amdgpu_discovery_init(struct amdgpu_device *adev)
>  {
> struct table_info *info;
> @@ -351,6 +364,11 @@ static int amdgpu_discovery_init(struct amdgpu_device 
> *adev)
> goto out;
> }
>
> +   // init sysfs for ip_discovery
> +   r = sysfs_create_file(>dev->kobj, 
> _attr_ip_discovery_text.attr);
> +   if (r)
> +   dev_err(adev->dev, "Could not create amdgpu device attr\n");
> +
> return 0;
>
>  out:
> @@ -363,7 +381,11 @@ static int amdgpu_discovery_init(struct amdgpu_device 
> *adev)
>  void amdgpu_discovery_fini(struct amdgpu_device *adev)
>  {
> kfree(adev->mman.discovery_bin);
> +   kfree(adev->ip_discovery_text);
> +   sysfs_remove_file(>dev->kobj, _attr_ip_discovery_text.attr);
> +
> adev->mman.discovery_bin = NULL;
> +   adev->ip_discovery_text = NULL;
>  }
>
>  static int amdgpu_discovery_validate_ip(const struct ip *ip)
> @@ -382,6 +404,20 @@ static int amdgpu_discovery_validate_ip(const struct ip 
> *ip)
> return 0;
>  }
>
> +static int add_string(char **dst, unsigned *size, char *src)
> +{
> +   if (strlen(src) + strlen(*dst) >= *size) {
> +   void *tmp = krealloc(*dst, *size + 4096, GFP_KERNEL);
> +   if (!tmp) {
> +   return -1;
> +   }
> +   

Re: [PATCH] drm/amd/display: Fix surface optimization regression on Carrizo

[StDenis, Tom]

[AMD Official Use Only]

Tested-by: Tom St Denis 

Thanks.


From: Alex Deucher 
Sent: Tuesday, October 12, 2021 10:15
To: Kazlauskas, Nicholas
Cc: amd-gfx list; Lakha, Bhawanpreet; Lipski, Mikita; StDenis, Tom
Subject: Re: [PATCH] drm/amd/display: Fix surface optimization regression on 
Carrizo

On Tue, Oct 12, 2021 at 10:11 AM Nicholas Kazlauskas
 wrote:
>
> [Why]
> DCE legacy optimization path isn't well tested under new DC optimization
> flow which can result in underflow occuring when initializing X11 on
> Carrizo.
>
> [How]
> Retain the legacy optimization flow for DCE and keep the new one for DCN
> to satisfy optimizations being correctly applied for ASIC that can
> support it.
>
> Fixes: ab37c6527bb1 ("drm/amd/display: Optimize bandwidth on following fast 
> update")
> Cc: Bhawanpreet Lakha 
> Cc: Mikita Lipski 
> Reported-by: Tom St Denis 
> Signed-off-by: Nicholas Kazlauskas 

Acked-by: Alex Deucher 

> ---
>  drivers/gpu/drm/amd/display/dc/core/dc.c | 15 +--
>  1 file changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c 
> b/drivers/gpu/drm/amd/display/dc/core/dc.c
> index da942e9f5142..f9876e429f26 100644
> --- a/drivers/gpu/drm/amd/display/dc/core/dc.c
> +++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
> @@ -3118,8 +3118,13 @@ void dc_commit_updates_for_stream(struct dc *dc,
> if (new_pipe->plane_state && new_pipe->plane_state != 
> old_pipe->plane_state)
> new_pipe->plane_state->force_full_update = 
> true;
> }
> -   } else if (update_type == UPDATE_TYPE_FAST) {
> -   /* Previous frame finished and HW is ready for optimization. 
> */
> +   } else if (update_type == UPDATE_TYPE_FAST && dc_ctx->dce_version >= 
> DCE_VERSION_MAX) {
> +   /*
> +* Previous frame finished and HW is ready for optimization.
> +*
> +* Only relevant for DCN behavior where we can guarantee the 
> optimization
> +* is safe to apply - retain the legacy behavior for DCE.
> +*/
> dc_post_update_surfaces_to_stream(dc);
> }
>
> @@ -3178,6 +3183,12 @@ void dc_commit_updates_for_stream(struct dc *dc,
> }
> }
>
> +   /* Legacy optimization path for DCE. */
> +   if (update_type >= UPDATE_TYPE_FULL && dc_ctx->dce_version < 
> DCE_VERSION_MAX) {
> +   dc_post_update_surfaces_to_stream(dc);
> +   TRACE_DCE_CLOCK_STATE(>bw_ctx.bw.dce);
> +   }
> +
> return;
>
>  }
> --
> 2.25.1
>

Re: [PATCH] drm/amd/amdgpu: New debugfs interface for MMIO registers (v5)

[StDenis, Tom]

[AMD Official Use Only]

The state is set with one syscall and used with a different syscall.  They're 
not atomic.

(I also don't see the need to bikeshed this anymore than we already have).

Tom


From: Lazar, Lijo 
Sent: Thursday, August 26, 2021 08:26
To: StDenis, Tom; amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/amd/amdgpu: New debugfs interface for MMIO registers 
(v5)

Does that really need a lock? Can't local variables solve it?

Thanks,
Lijo

On 8/26/2021 5:52 PM, StDenis, Tom wrote:
> [AMD Official Use Only]
>
> The issue is someone can issue an ioctl WHILE a read/write is happening.  In 
> that case a read could take a [say] SRBM lock but then never free it.
>
> Two threads racing operations WITH the lock in place just means the userspace 
> gets undefined outputs which from the kernel is fine.
>
> Tom
>
> 
> From: Lazar, Lijo 
> Sent: Thursday, August 26, 2021 08:19
> To: StDenis, Tom; amd-gfx@lists.freedesktop.org
> Subject: Re: [PATCH] drm/amd/amdgpu: New debugfs interface for MMIO registers 
> (v5)
>
> If there are two threads using the same fd, I don't see anything that
> prevent this order
>
>  set_state (T1) // State1
>  set_state (T2) // State2
>  read (T1)
>  write (T2)
>
> If there are separate fds, I guess the device level mutex takes care anyway.
>
> Thanks,
> Lijo
>
> On 8/26/2021 5:45 PM, StDenis, Tom wrote:
>> [AMD Official Use Only]
>>
>> While umr uses this as a constant two-step dance that doesn't mean another 
>> user task couldn't misbehave.  Two threads firing read/write and IOCTL at 
>> the same time could cause a lock imbalance.
>>
>> As I remarked to Christian offline that's unlikely to happen since umr is 
>> the only likely user of this it's still ideal to avoid potential race 
>> conditions as a matter of correctness.
>>
>> Tom
>>
>> 
>> From: Lazar, Lijo 
>> Sent: Thursday, August 26, 2021 08:12
>> To: StDenis, Tom; amd-gfx@lists.freedesktop.org
>> Subject: Re: [PATCH] drm/amd/amdgpu: New debugfs interface for MMIO 
>> registers (v5)
>>
>>
>>
>> On 8/25/2021 10:56 PM, Tom St Denis wrote:
>>> This new debugfs interface uses an IOCTL interface in order to pass
>>> along state information like SRBM and GRBM bank switching.  This
>>> new interface also allows a full 32-bit MMIO address range which
>>> the previous didn't.  With this new design we have room to grow
>>> the flexibility of the file as need be.
>>>
>>> (v2): Move read/write to .read/.write, fix style, add comment
>>>  for IOCTL data structure
>>>
>>> (v3): C style comments
>>>
>>> (v4): use u32 in struct and remove offset variable
>>>
>>> (v5): Drop flag clearing in op function, use 0x for broadcast
>>>  instead of 0x3FF, use mutex for op/ioctl.
>>>
>>> Signed-off-by: Tom St Denis 
>>> ---
>>> drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 150 
>>> drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.h |   1 -
>>> drivers/gpu/drm/amd/amdgpu/amdgpu_umr.h |  51 +++
>>> 3 files changed, 201 insertions(+), 1 deletion(-)
>>> create mode 100644 drivers/gpu/drm/amd/amdgpu/amdgpu_umr.h
>>>
>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c 
>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
>>> index 277128846dd1..87766fef0b1c 100644
>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
>>> @@ -36,6 +36,7 @@
>>> #include "amdgpu_rap.h"
>>> #include "amdgpu_securedisplay.h"
>>> #include "amdgpu_fw_attestation.h"
>>> +#include "amdgpu_umr.h"
>>>
>>> int amdgpu_debugfs_wait_dump(struct amdgpu_device *adev)
>>> {
>>> @@ -279,6 +280,143 @@ static ssize_t amdgpu_debugfs_regs_write(struct file 
>>> *f, const char __user *buf,
>>> return amdgpu_debugfs_process_reg_op(false, f, (char __user *)buf, 
>>> size, pos);
>>> }
>>>
>>> +static int amdgpu_debugfs_regs2_open(struct inode *inode, struct file 
>>> *file)
>>> +{
>>> + struct amdgpu_debugfs_regs2_data *rd;
>>> +
>>> + rd = kzalloc(sizeof *rd, GFP_KERNEL);
>>> + if (!rd)
>>> + return -ENOMEM;
>>> + rd->adev = f

Re: [PATCH] drm/amd/amdgpu: New debugfs interface for MMIO registers (v5)

[StDenis, Tom]

[AMD Official Use Only]

The issue is someone can issue an ioctl WHILE a read/write is happening.  In 
that case a read could take a [say] SRBM lock but then never free it.

Two threads racing operations WITH the lock in place just means the userspace 
gets undefined outputs which from the kernel is fine.

Tom


From: Lazar, Lijo 
Sent: Thursday, August 26, 2021 08:19
To: StDenis, Tom; amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/amd/amdgpu: New debugfs interface for MMIO registers 
(v5)

If there are two threads using the same fd, I don't see anything that
prevent this order

set_state (T1) // State1
set_state (T2) // State2
read (T1)
write (T2)

If there are separate fds, I guess the device level mutex takes care anyway.

Thanks,
Lijo

On 8/26/2021 5:45 PM, StDenis, Tom wrote:
> [AMD Official Use Only]
>
> While umr uses this as a constant two-step dance that doesn't mean another 
> user task couldn't misbehave.  Two threads firing read/write and IOCTL at the 
> same time could cause a lock imbalance.
>
> As I remarked to Christian offline that's unlikely to happen since umr is the 
> only likely user of this it's still ideal to avoid potential race conditions 
> as a matter of correctness.
>
> Tom
>
> 
> From: Lazar, Lijo 
> Sent: Thursday, August 26, 2021 08:12
> To: StDenis, Tom; amd-gfx@lists.freedesktop.org
> Subject: Re: [PATCH] drm/amd/amdgpu: New debugfs interface for MMIO registers 
> (v5)
>
>
>
> On 8/25/2021 10:56 PM, Tom St Denis wrote:
>> This new debugfs interface uses an IOCTL interface in order to pass
>> along state information like SRBM and GRBM bank switching.  This
>> new interface also allows a full 32-bit MMIO address range which
>> the previous didn't.  With this new design we have room to grow
>> the flexibility of the file as need be.
>>
>> (v2): Move read/write to .read/.write, fix style, add comment
>> for IOCTL data structure
>>
>> (v3): C style comments
>>
>> (v4): use u32 in struct and remove offset variable
>>
>> (v5): Drop flag clearing in op function, use 0x for broadcast
>> instead of 0x3FF, use mutex for op/ioctl.
>>
>> Signed-off-by: Tom St Denis 
>> ---
>>drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 150 
>>drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.h |   1 -
>>drivers/gpu/drm/amd/amdgpu/amdgpu_umr.h |  51 +++
>>3 files changed, 201 insertions(+), 1 deletion(-)
>>create mode 100644 drivers/gpu/drm/amd/amdgpu/amdgpu_umr.h
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c 
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
>> index 277128846dd1..87766fef0b1c 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
>> @@ -36,6 +36,7 @@
>>#include "amdgpu_rap.h"
>>#include "amdgpu_securedisplay.h"
>>#include "amdgpu_fw_attestation.h"
>> +#include "amdgpu_umr.h"
>>
>>int amdgpu_debugfs_wait_dump(struct amdgpu_device *adev)
>>{
>> @@ -279,6 +280,143 @@ static ssize_t amdgpu_debugfs_regs_write(struct file 
>> *f, const char __user *buf,
>>return amdgpu_debugfs_process_reg_op(false, f, (char __user *)buf, 
>> size, pos);
>>}
>>
>> +static int amdgpu_debugfs_regs2_open(struct inode *inode, struct file *file)
>> +{
>> + struct amdgpu_debugfs_regs2_data *rd;
>> +
>> + rd = kzalloc(sizeof *rd, GFP_KERNEL);
>> + if (!rd)
>> + return -ENOMEM;
>> + rd->adev = file_inode(file)->i_private;
>> + file->private_data = rd;
>> + mutex_init(>lock);
>> +
>> + return 0;
>> +}
>> +
>> +static int amdgpu_debugfs_regs2_release(struct inode *inode, struct file 
>> *file)
>> +{
>> + kfree(file->private_data);
>> + return 0;
>> +}
>> +
>> +static ssize_t amdgpu_debugfs_regs2_op(struct file *f, char __user *buf, 
>> u32 offset, size_t size, int write_en)
>> +{
>> + struct amdgpu_debugfs_regs2_data *rd = f->private_data;
>> + struct amdgpu_device *adev = rd->adev;
>> + ssize_t result = 0;
>> + int r;
>> + uint32_t value;
>> +
>> + if (size & 0x3 || offset & 0x3)
>> + return -EINVAL;
>> +
>> + r = pm_runtime_get_sync(adev_to_drm(adev)->dev);
>> + if (r < 0) {
>> + pm_runtime_put_autosuspend(adev_t

Re: [PATCH] drm/amd/amdgpu: New debugfs interface for MMIO registers (v5)

[StDenis, Tom]

[AMD Official Use Only]

While umr uses this as a constant two-step dance that doesn't mean another user 
task couldn't misbehave.  Two threads firing read/write and IOCTL at the same 
time could cause a lock imbalance.

As I remarked to Christian offline that's unlikely to happen since umr is the 
only likely user of this it's still ideal to avoid potential race conditions as 
a matter of correctness.

Tom


From: Lazar, Lijo 
Sent: Thursday, August 26, 2021 08:12
To: StDenis, Tom; amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/amd/amdgpu: New debugfs interface for MMIO registers 
(v5)



On 8/25/2021 10:56 PM, Tom St Denis wrote:
> This new debugfs interface uses an IOCTL interface in order to pass
> along state information like SRBM and GRBM bank switching.  This
> new interface also allows a full 32-bit MMIO address range which
> the previous didn't.  With this new design we have room to grow
> the flexibility of the file as need be.
>
> (v2): Move read/write to .read/.write, fix style, add comment
>for IOCTL data structure
>
> (v3): C style comments
>
> (v4): use u32 in struct and remove offset variable
>
> (v5): Drop flag clearing in op function, use 0x for broadcast
>instead of 0x3FF, use mutex for op/ioctl.
>
> Signed-off-by: Tom St Denis 
> ---
>   drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 150 
>   drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.h |   1 -
>   drivers/gpu/drm/amd/amdgpu/amdgpu_umr.h |  51 +++
>   3 files changed, 201 insertions(+), 1 deletion(-)
>   create mode 100644 drivers/gpu/drm/amd/amdgpu/amdgpu_umr.h
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
> index 277128846dd1..87766fef0b1c 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
> @@ -36,6 +36,7 @@
>   #include "amdgpu_rap.h"
>   #include "amdgpu_securedisplay.h"
>   #include "amdgpu_fw_attestation.h"
> +#include "amdgpu_umr.h"
>
>   int amdgpu_debugfs_wait_dump(struct amdgpu_device *adev)
>   {
> @@ -279,6 +280,143 @@ static ssize_t amdgpu_debugfs_regs_write(struct file 
> *f, const char __user *buf,
>   return amdgpu_debugfs_process_reg_op(false, f, (char __user *)buf, 
> size, pos);
>   }
>
> +static int amdgpu_debugfs_regs2_open(struct inode *inode, struct file *file)
> +{
> + struct amdgpu_debugfs_regs2_data *rd;
> +
> + rd = kzalloc(sizeof *rd, GFP_KERNEL);
> + if (!rd)
> + return -ENOMEM;
> + rd->adev = file_inode(file)->i_private;
> + file->private_data = rd;
> + mutex_init(>lock);
> +
> + return 0;
> +}
> +
> +static int amdgpu_debugfs_regs2_release(struct inode *inode, struct file 
> *file)
> +{
> + kfree(file->private_data);
> + return 0;
> +}
> +
> +static ssize_t amdgpu_debugfs_regs2_op(struct file *f, char __user *buf, u32 
> offset, size_t size, int write_en)
> +{
> + struct amdgpu_debugfs_regs2_data *rd = f->private_data;
> + struct amdgpu_device *adev = rd->adev;
> + ssize_t result = 0;
> + int r;
> + uint32_t value;
> +
> + if (size & 0x3 || offset & 0x3)
> + return -EINVAL;
> +
> + r = pm_runtime_get_sync(adev_to_drm(adev)->dev);
> + if (r < 0) {
> + pm_runtime_put_autosuspend(adev_to_drm(adev)->dev);
> + return r;
> + }
> +
> + r = amdgpu_virt_enable_access_debugfs(adev);
> + if (r < 0) {
> + pm_runtime_put_autosuspend(adev_to_drm(adev)->dev);
> + return r;
> + }
> +
> + mutex_lock(>lock);
> +
> + if (rd->id.use_grbm) {
> + if ((rd->id.grbm.sh != 0x && rd->id.grbm.sh >= 
> adev->gfx.config.max_sh_per_se) ||
> + (rd->id.grbm.se != 0x && rd->id.grbm.se >= 
> adev->gfx.config.max_shader_engines)) {
> + pm_runtime_mark_last_busy(adev_to_drm(adev)->dev);
> + pm_runtime_put_autosuspend(adev_to_drm(adev)->dev);
> + amdgpu_virt_disable_access_debugfs(adev);
> + mutex_unlock(>lock);
> + return -EINVAL;
> + }
> + mutex_lock(>grbm_idx_mutex);
> + amdgpu_gfx_select_se_sh(adev, rd->id.grbm.se,
> + rd->id.grbm.sh,
> + 
> rd->id.grbm.instance);
> + }
> +
> + if (r

Re: [PATCH] drm/amd/amdgpu: New debugfs interface for MMIO registers

[StDenis, Tom]

[AMD Official Use Only]

What do you mean a "shared header?"  How would they be shared between kernel 
and user?

As for why not read/write.  Jus wanted to keep it simple.  It's not really 
performance bound.  umr never does reads/writes larger than 32-bits anyways.  
It doesn't have to be this way though but I figured the fewer LOC the better.

Tom


From: Christian König 
Sent: Tuesday, August 24, 2021 08:20
To: StDenis, Tom; amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/amd/amdgpu: New debugfs interface for MMIO registers



Am 24.08.21 um 14:16 schrieb Tom St Denis:
> This new debugfs interface uses an IOCTL interface in order to pass
> along state information like SRBM and GRBM bank switching.  This
> new interface also allows a full 32-bit MMIO address range which
> the previous didn't.  With this new design we have room to grow
> the flexibility of the file as need be.
>
> Signed-off-by: Tom St Denis 
> ---
>   drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 177 
>   drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.h |  32 
>   2 files changed, 209 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
> index 277128846dd1..ab2d92f84da5 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
> @@ -279,6 +279,173 @@ static ssize_t amdgpu_debugfs_regs_write(struct file 
> *f, const char __user *buf,
>   return amdgpu_debugfs_process_reg_op(false, f, (char __user *)buf, 
> size, pos);
>   }
>
> +static int amdgpu_debugfs_regs2_open(struct inode *inode, struct file *file)
> +{
> + struct amdgpu_debugfs_regs2_data *rd;
> +
> + rd = kzalloc(sizeof *rd, GFP_KERNEL);
> + if (!rd)
> + return -ENOMEM;
> + rd->adev = file_inode(file)->i_private;
> + file->private_data = rd;
> +
> + return 0;
> +}
> +
> +static int amdgpu_debugfs_regs2_release(struct inode *inode, struct file 
> *file)
> +{
> + kfree(file->private_data);
> + return 0;
> +}
> +
> +static int amdgpu_debugfs_regs2_op(struct file *f, char __user *buf, int 
> write_en)
> +{
> + struct amdgpu_debugfs_regs2_data *rd = f->private_data;
> + struct amdgpu_device *adev = rd->adev;
> + int result = 0, r;
> + uint32_t value;
> +
> + if (rd->state.offset & 0x3)
> + return -EINVAL;
> +
> + if (rd->state.use_grbm) {
> + if (rd->state.grbm.se == 0x3FF)
> + rd->state.grbm.se = 0x;
> + if (rd->state.grbm.sh == 0x3FF)
> + rd->state.grbm.sh = 0x;
> + if (rd->state.grbm.instance == 0x3FF)
> + rd->state.grbm.instance = 0x;
> + }
> +
> + r = pm_runtime_get_sync(adev_to_drm(adev)->dev);
> + if (r < 0) {
> + pm_runtime_put_autosuspend(adev_to_drm(adev)->dev);
> + return r;
> + }
> +
> + r = amdgpu_virt_enable_access_debugfs(adev);
> + if (r < 0) {
> + pm_runtime_put_autosuspend(adev_to_drm(adev)->dev);
> + return r;
> + }
> +
> + if (rd->state.use_grbm) {
> + if ((rd->state.grbm.sh != 0x && rd->state.grbm.sh >= 
> adev->gfx.config.max_sh_per_se) ||
> + (rd->state.grbm.se != 0x && rd->state.grbm.se >= 
> adev->gfx.config.max_shader_engines)) {
> + pm_runtime_mark_last_busy(adev_to_drm(adev)->dev);
> + pm_runtime_put_autosuspend(adev_to_drm(adev)->dev);
> + amdgpu_virt_disable_access_debugfs(adev);
> + return -EINVAL;
> + }
> + mutex_lock(>grbm_idx_mutex);
> + amdgpu_gfx_select_se_sh(adev, rd->state.grbm.se,
> + 
> rd->state.grbm.sh,
> + 
> rd->state.grbm.instance);
> + } else if (rd->state.use_grbm) {
> + mutex_lock(>srbm_mutex);
> + amdgpu_gfx_select_me_pipe_q(adev, rd->state.srbm.me, 
> rd->state.srbm.pipe,
> + 
> rd->state.srbm.queue, rd->state.srbm.vmid);
> + }
> +
> + if (rd->state.pg_lock)
> + mutex_lock(>pm.mutex);
> +
> + if (!write_en) {
> + value = RREG32(rd->state.offset >> 2);
> + r = put_user(value, (uin

Re: [PATCH v2 umr 3/3] Enhance printing of page tables in AI+

[StDenis, Tom]

[AMD Official Use Only]

Tested and pushed out to main.

Thanks,
Tom


From: Greathouse, Joseph 
Sent: Monday, June 21, 2021 12:37
To: amd-gfx@lists.freedesktop.org
Cc: StDenis, Tom; Greathouse, Joseph
Subject: [PATCH v2 umr 3/3] Enhance printing of page tables in AI+

Pulls print functions for GPUVM page tables on AI+ chips into their
own set of generalized functions, so that we don't have subtly
different printouts for different layers.

Explicitly prints PDEs with P bit (which makes it a PTE) and makes
the PTE with F bit set (further, which makes it a PDE) properly
indent the next layer of the print.

Prints remaining fields from the PTE and PDE printouts, such as
read/write/execute bits and MTYPE from PTE.

v2: Correctly handle printing translate-further PTEs

Signed-off-by: Joseph Greathouse 
---
 src/lib/read_vram.c | 184 ++--
 1 file changed, 127 insertions(+), 57 deletions(-)

diff --git a/src/lib/read_vram.c b/src/lib/read_vram.c
index 2998873..bea1232 100644
--- a/src/lib/read_vram.c
+++ b/src/lib/read_vram.c
@@ -415,6 +415,112 @@ static pte_fields_ai_t decode_pte_entry_ai(uint64_t 
pte_entry)
return pte_fields;
 }

+static void print_pde_fields_ai(struct umr_asic *asic,
+   pde_fields_ai_t pde_fields)
+{
+   asic->mem_funcs.vm_message(
+   ", PBA==0x%012" PRIx64 ", V=%" PRIu64
+   ", S=%" PRIu64 ", C=%" PRIu64
+   ", P=%" PRIu64 ", FS=%" PRIu64 "\n",
+   pde_fields.pte_base_addr,
+   pde_fields.valid,
+   pde_fields.system,
+   pde_fields.coherent,
+   pde_fields.pte,
+   pde_fields.frag_size);
+}
+static void print_base_ai(struct umr_asic *asic,
+ uint64_t pde_entry, uint64_t address,
+ uint64_t va_mask, pde_fields_ai_t pde_fields,
+ int is_base_not_pde)
+{
+   if (is_base_not_pde)
+   asic->mem_funcs.vm_message("BASE");
+   else
+   asic->mem_funcs.vm_message("PDE");
+   asic->mem_funcs.vm_message("=0x%016" PRIx64 ", VA=0x%012" PRIx64,
+   pde_entry,
+   address & va_mask);
+   print_pde_fields_ai(asic, pde_fields);
+}
+
+static void print_pde_ai(struct umr_asic *asic,
+   const char * indentation, int pde_cnt,
+   int page_table_depth, uint64_t prev_addr,
+   uint64_t pde_idx, uint64_t pde_entry, uint64_t address,
+   uint64_t va_mask, pde_fields_ai_t pde_fields)
+{
+   asic->mem_funcs.vm_message("%s ", [18-pde_cnt*3]);
+   if (pde_fields.further)
+   asic->mem_funcs.vm_message("PTE-FURTHER");
+   else
+   asic->mem_funcs.vm_message("PDE%d", page_table_depth - pde_cnt);
+
+   asic->mem_funcs.vm_message("@{0x%" PRIx64 "/%" PRIx64
+   "}=0x%016" PRIx64 ", VA=0x%012" PRIx64,
+   prev_addr,
+   pde_idx,
+   pde_entry,
+   address & va_mask);
+   print_pde_fields_ai(asic, pde_fields);
+}
+
+static void print_pte_ai(struct umr_asic *asic,
+   const char * indentation, int pde_cnt, uint64_t prev_addr,
+   uint64_t pte_idx, uint64_t pte_entry, uint64_t address,
+   uint64_t va_mask, pte_fields_ai_t pte_fields)
+{
+   if (asic == NULL) {
+   asic->mem_funcs.vm_message("\\-> PTE");
+   } else {
+   asic->mem_funcs.vm_message("%s ",
+   [18-pde_cnt*3]);
+   if (pte_fields.pde)
+   asic->mem_funcs.vm_message("PDE0-as-PTE");
+   else
+   asic->mem_funcs.vm_message("PTE");
+   asic->mem_funcs.vm_message("@{0x%" PRIx64 "/%" PRIx64"}",
+   prev_addr,
+   pte_idx);
+   }
+   asic->mem_funcs.vm_message("=0x%016" PRIx64 ", VA=0x%012" PRIx64
+   ", PBA==0x%012" PRIx64 ", V=%" PRIu64
+   ", S=%" PRIu64 ", C=%" PRIu64 ", Z=%" PRIu64
+   ", X=%" PRIu64 ", R=%" PRIu64 ", W=%" PRIu64
+   ", FS=%" PRIu64 ", T=%" PRIu64 ", MTYPE=",
+   pte_entry,
+   address & va_mask,
+   pte_fields.p

Re: [PATCH v2 umr 3/3] Enhance printing of page tables in AI+

[StDenis, Tom]

[AMD Official Use Only]

Hi,

Just a quick update.  Your first vector passes with your v2 patch in place.  
I'll add the other 3 and then start reviewing the code.

Thanks,
Tom


From: Greathouse, Joseph 
Sent: Monday, June 21, 2021 12:37
To: amd-gfx@lists.freedesktop.org
Cc: StDenis, Tom; Greathouse, Joseph
Subject: [PATCH v2 umr 3/3] Enhance printing of page tables in AI+

Pulls print functions for GPUVM page tables on AI+ chips into their
own set of generalized functions, so that we don't have subtly
different printouts for different layers.

Explicitly prints PDEs with P bit (which makes it a PTE) and makes
the PTE with F bit set (further, which makes it a PDE) properly
indent the next layer of the print.

Prints remaining fields from the PTE and PDE printouts, such as
read/write/execute bits and MTYPE from PTE.

v2: Correctly handle printing translate-further PTEs

Signed-off-by: Joseph Greathouse 
---
 src/lib/read_vram.c | 184 ++--
 1 file changed, 127 insertions(+), 57 deletions(-)

diff --git a/src/lib/read_vram.c b/src/lib/read_vram.c
index 2998873..bea1232 100644
--- a/src/lib/read_vram.c
+++ b/src/lib/read_vram.c
@@ -415,6 +415,112 @@ static pte_fields_ai_t decode_pte_entry_ai(uint64_t 
pte_entry)
return pte_fields;
 }

+static void print_pde_fields_ai(struct umr_asic *asic,
+   pde_fields_ai_t pde_fields)
+{
+   asic->mem_funcs.vm_message(
+   ", PBA==0x%012" PRIx64 ", V=%" PRIu64
+   ", S=%" PRIu64 ", C=%" PRIu64
+   ", P=%" PRIu64 ", FS=%" PRIu64 "\n",
+   pde_fields.pte_base_addr,
+   pde_fields.valid,
+   pde_fields.system,
+   pde_fields.coherent,
+   pde_fields.pte,
+   pde_fields.frag_size);
+}
+static void print_base_ai(struct umr_asic *asic,
+ uint64_t pde_entry, uint64_t address,
+ uint64_t va_mask, pde_fields_ai_t pde_fields,
+ int is_base_not_pde)
+{
+   if (is_base_not_pde)
+   asic->mem_funcs.vm_message("BASE");
+   else
+   asic->mem_funcs.vm_message("PDE");
+   asic->mem_funcs.vm_message("=0x%016" PRIx64 ", VA=0x%012" PRIx64,
+   pde_entry,
+   address & va_mask);
+   print_pde_fields_ai(asic, pde_fields);
+}
+
+static void print_pde_ai(struct umr_asic *asic,
+   const char * indentation, int pde_cnt,
+   int page_table_depth, uint64_t prev_addr,
+   uint64_t pde_idx, uint64_t pde_entry, uint64_t address,
+   uint64_t va_mask, pde_fields_ai_t pde_fields)
+{
+   asic->mem_funcs.vm_message("%s ", [18-pde_cnt*3]);
+   if (pde_fields.further)
+   asic->mem_funcs.vm_message("PTE-FURTHER");
+   else
+   asic->mem_funcs.vm_message("PDE%d", page_table_depth - pde_cnt);
+
+   asic->mem_funcs.vm_message("@{0x%" PRIx64 "/%" PRIx64
+   "}=0x%016" PRIx64 ", VA=0x%012" PRIx64,
+   prev_addr,
+   pde_idx,
+   pde_entry,
+   address & va_mask);
+   print_pde_fields_ai(asic, pde_fields);
+}
+
+static void print_pte_ai(struct umr_asic *asic,
+   const char * indentation, int pde_cnt, uint64_t prev_addr,
+   uint64_t pte_idx, uint64_t pte_entry, uint64_t address,
+   uint64_t va_mask, pte_fields_ai_t pte_fields)
+{
+   if (asic == NULL) {
+   asic->mem_funcs.vm_message("\\-> PTE");
+   } else {
+   asic->mem_funcs.vm_message("%s ",
+   [18-pde_cnt*3]);
+   if (pte_fields.pde)
+   asic->mem_funcs.vm_message("PDE0-as-PTE");
+   else
+   asic->mem_funcs.vm_message("PTE");
+   asic->mem_funcs.vm_message("@{0x%" PRIx64 "/%" PRIx64"}",
+   prev_addr,
+   pte_idx);
+   }
+   asic->mem_funcs.vm_message("=0x%016" PRIx64 ", VA=0x%012" PRIx64
+   ", PBA==0x%012" PRIx64 ", V=%" PRIu64
+   ", S=%" PRIu64 ", C=%" PRIu64 ", Z=%" PRIu64
+   ", X=%" PRIu64 ", R=%" PRIu64 ", W=%" PRIu64
+   ", FS=%" PRIu64 ", T=%" PRIu64 ", MTYPE

Re: display regression on Carrizo

[StDenis, Tom]

[AMD Official Use Only]

Hi Mario,

Yes, this diff fixes the display on my Carrizo:

[root@carrizo linux]# git diff
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_resource.c 
b/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
index cd864cc83539..ca7739c9f6cb 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
@@ -1044,7 +1044,7 @@ bool resource_build_scaling_params(struct pipe_ctx 
*pipe_ctx)
 * SURFACE_PIXEL_FORMAT_GRPH_ABGR16161616 with actual > 10 bpc
 * precision on at least DCN display engines.
 */
-   pipe_ctx->plane_res.scl_data.lb_params.depth = LB_PIXEL_DEPTH_36BPP;
+   pipe_ctx->plane_res.scl_data.lb_params.depth = LB_PIXEL_DEPTH_30BPP;
pipe_ctx->plane_res.scl_data.lb_params.alpha_en = 
plane_state->per_pixel_alpha;

if (pipe_ctx->plane_res.xfm != NULL)

Tom


From: Mario Kleiner 
Sent: Tuesday, June 1, 2021 09:17
To: StDenis, Tom
Cc: amd-gfx list; Deucher, Alexander
Subject: Re: display regression on Carrizo

On Mon, May 31, 2021 at 4:14 PM StDenis, Tom  wrote:
>
> [AMD Official Use Only]
>
> Hi Mario,
>

Hi Tom,

> The following commit causes a display regression on my Carrizo when booting 
> linux into a console (e.g. no WM).  When the driver inits the display goes 
> green and is unusable.  The commit prior to this one on amd-staging-drm-next 
> results in a clean init.
>

That's sad. What happens if you only revert the change to
drivers/gpu/drm/amd/display/dc/core/dc_resource.c in this commit,ie.
change the assignment in resource_build_scaling_params() back to:

pipe_ctx->plane_res.scl_data.lb_params.depth = LB_PIXEL_DEPTH_30BPP;

As my testing on Polaris / DCE11.2 showed, for some reason the change
in linebuffer pixeldepth was not required for my Polaris11 to get
12bpc output, only for my Raven Ridge / DCN-1. Maybe I could make a
followup patch to make it conditional on asic? Either only increase lb
depth on DCN-1+, leave it off for DCE, or just exclude DCE-11.0 from
the change, as Carrizo is DCE-11? I seem to remember there were some
other DCE-11 specific restrictions wrt. 64bpp fp16 and the scaler.
Maybe something similar happens here?

-mario

> commit b1114ddd63be03825182d6162ff25fa3492cd6f5
> Author: Mario Kleiner 
> Date:   Fri Mar 19 22:03:15 2021 +0100
>
> drm/amd/display: Increase linebuffer pixel depth to 36bpp.
>
> Testing with the photometer shows that at least Raven Ridge DCN-1.0
> does not achieve more than 10 bpc effective output precision with a
> 16 bpc unorm surface of type SURFACE_PIXEL_FORMAT_GRPH_ABGR16161616,
> unless linebuffer depth is increased from LB_PIXEL_DEPTH_30BPP to
> LB_PIXEL_DEPTH_36BPP. Otherwise precision gets truncated somewhere
> to 10 bpc effective depth.
>
> Strangely this increase was not needed on Polaris11 DCE-11.2 during
> testing to get 12 bpc effective precision. It also is not needed for
> fp16 framebuffers.
>
> Tested on DCN-1.0 and DCE-11.2.
>
> Signed-off-by: Mario Kleiner 
> Signed-off-by: Alex Deucher 
>
>  drivers/gpu/drm/amd/display/dc/core/dc_resource.c  | 7 +--
>  drivers/gpu/drm/amd/display/dc/dce/dce_transform.c | 6 --
>  drivers/gpu/drm/amd/display/dc/dce110/dce110_transform_v.c | 3 ++-
>  drivers/gpu/drm/amd/display/dc/dcn10/dcn10_dpp.c   | 3 ++-
>  drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c  | 2 +-
>  drivers/gpu/drm/amd/display/dc/dcn20/dcn20_dpp.c   | 3 ++-
>  drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hwseq.c | 2 +-
>  drivers/gpu/drm/amd/display/dc/dcn30/dcn30_dpp.c   | 3 ++-
>  8 files changed, 19 insertions(+), 10 deletions(-)
>
> Tom
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

display regression on Carrizo

[StDenis, Tom]

[AMD Official Use Only]

Hi Mario,

The following commit causes a display regression on my Carrizo when booting 
linux into a console (e.g. no WM).  When the driver inits the display goes 
green and is unusable.  The commit prior to this one on amd-staging-drm-next 
results in a clean init.

commit b1114ddd63be03825182d6162ff25fa3492cd6f5
Author: Mario Kleiner 
Date:   Fri Mar 19 22:03:15 2021 +0100

drm/amd/display: Increase linebuffer pixel depth to 36bpp.

Testing with the photometer shows that at least Raven Ridge DCN-1.0
does not achieve more than 10 bpc effective output precision with a
16 bpc unorm surface of type SURFACE_PIXEL_FORMAT_GRPH_ABGR16161616,
unless linebuffer depth is increased from LB_PIXEL_DEPTH_30BPP to
LB_PIXEL_DEPTH_36BPP. Otherwise precision gets truncated somewhere
to 10 bpc effective depth.

Strangely this increase was not needed on Polaris11 DCE-11.2 during
testing to get 12 bpc effective precision. It also is not needed for
fp16 framebuffers.

Tested on DCN-1.0 and DCE-11.2.

Signed-off-by: Mario Kleiner 
Signed-off-by: Alex Deucher 

 drivers/gpu/drm/amd/display/dc/core/dc_resource.c  | 7 +--
 drivers/gpu/drm/amd/display/dc/dce/dce_transform.c | 6 --
 drivers/gpu/drm/amd/display/dc/dce110/dce110_transform_v.c | 3 ++-
 drivers/gpu/drm/amd/display/dc/dcn10/dcn10_dpp.c   | 3 ++-
 drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c  | 2 +-
 drivers/gpu/drm/amd/display/dc/dcn20/dcn20_dpp.c   | 3 ++-
 drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hwseq.c | 2 +-
 drivers/gpu/drm/amd/display/dc/dcn30/dcn30_dpp.c   | 3 ++-
 8 files changed, 19 insertions(+), 10 deletions(-)

Tom
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] drm/amdgpu: Add vbios info ioctl interface

[StDenis, Tom]

[AMD Official Use Only - Internal Distribution Only]

If changing the ioctl is an issue why not just use sysfs?  umr already makes 
uses of all three for it's purposes so it's fine by me for either.

Tom


From: amd-gfx  on behalf of Christian 
König 
Sent: Tuesday, May 18, 2021 09:17
To: Gu, JiaWei (Will); amd-gfx@lists.freedesktop.org; Nieto, David M; 
mar...@gmail.com; Deucher, Alexander
Cc: Deng, Emily
Subject: Re: [PATCH] drm/amdgpu: Add vbios info ioctl interface

Well not an expert on that stuff, but looks like that should work for me.

Question is can you provide a patch to use that information in Mesa as
well? Umr might be sufficient as well as justification for upstreaming,
but I want to be better save than sorry.

Unless Marek has a better idea maybe add the vbios version to the string
returned by GLX_MESA_query_renderer or something like that.

Thanks,
Christian.

Am 18.05.21 um 14:19 schrieb Gu, JiaWei (Will):
> [AMD Official Use Only - Internal Distribution Only]
>
> Hi all,
>
> Please help confirm that we're all fine with this new struct in uapi in this 
> V3 patch:
>
> +struct drm_amdgpu_info_vbios {
> + __u8 name[64];
> + __u8 vbios_pn[64];
> + __u32 version;
> + __u8 vbios_ver_str[32];
> + __u8 date[32];
> +};
>
> Best regards,
> Jiawei
>
> -Original Message-
> From: Jiawei Gu 
> Sent: Tuesday, May 18, 2021 8:16 PM
> To: amd-gfx@lists.freedesktop.org; Koenig, Christian 
> ; Nieto, David M ; 
> mar...@gmail.com; Deucher, Alexander 
> Cc: Deng, Emily ; Gu, JiaWei (Will) 
> Subject: [PATCH] drm/amdgpu: Add vbios info ioctl interface
>
> Add AMDGPU_INFO_VBIOS_INFO subquery id for detailed vbios info.
>
> Provides a way for the user application to get the VBIOS information without 
> having to parse the binary.
> It is useful for the user to be able to display in a simple way the VBIOS 
> version in their system if they happen to encounter an issue.
>
> V2:
> Use numeric serial.
> Parse and expose vbios version string.
>
> V3:
> Remove redundant data in drm_amdgpu_info_vbios struct.
>
> Signed-off-by: Jiawei Gu 
> ---
>   drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c|  15 ++
>   drivers/gpu/drm/amd/amdgpu/atom.c  | 172 +
>   drivers/gpu/drm/amd/amdgpu/atom.h  |  10 ++
>   drivers/gpu/drm/amd/include/atomfirmware.h |   5 +
>   include/uapi/drm/amdgpu_drm.h  |  10 ++
>   5 files changed, 212 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> index 8d12e474745a..524e4fe5efe8 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> @@ -861,6 +861,21 @@ int amdgpu_info_ioctl(struct drm_device *dev, void 
> *data, struct drm_file *filp)
>   min((size_t)size, 
> (size_t)(bios_size - bios_offset)))
>   ? -EFAULT : 0;
>   }
> + case AMDGPU_INFO_VBIOS_INFO: {
> + struct drm_amdgpu_info_vbios vbios_info = {};
> + struct atom_context *atom_context;
> +
> + atom_context = adev->mode_info.atom_context;
> + memcpy(vbios_info.name, atom_context->name, 
> sizeof(atom_context->name));
> + memcpy(vbios_info.vbios_pn, atom_context->vbios_pn, 
> sizeof(atom_context->vbios_pn));
> + vbios_info.version = atom_context->version;
> + memcpy(vbios_info.vbios_ver_str, 
> atom_context->vbios_ver_str,
> + 
> sizeof(atom_context->vbios_ver_str));
> + memcpy(vbios_info.date, atom_context->date,
> +sizeof(atom_context->date));
> +
> + return copy_to_user(out, _info,
> + min((size_t)size, 
> sizeof(vbios_info))) ? -EFAULT : 0;
> + }
>   default:
>   DRM_DEBUG_KMS("Invalid request %d\n",
>   info->vbios_info.type);
> diff --git a/drivers/gpu/drm/amd/amdgpu/atom.c 
> b/drivers/gpu/drm/amd/amdgpu/atom.c
> index 3dcb8b32f48b..6fa2229b7229 100644
> --- a/drivers/gpu/drm/amd/amdgpu/atom.c
> +++ b/drivers/gpu/drm/amd/amdgpu/atom.c
> @@ -31,6 +31,7 @@
>
>   #define ATOM_DEBUG
>
> +#include "atomfirmware.h"
>   #include "atom.h"
>   #include "atom-names.h"
>   #include "atom-bits.h"
> @@ -1299,12 +1300,168 @@ static void atom_index_iio(struct atom_context *ctx, 
> int base)
>   }
>   }
>
> +static void atom_get_vbios_name(struct atom_context *ctx) {
> + unsigned char *p_rom;
> + unsigned char str_num;
> + unsigned short off_to_vbios_str;
> + unsigned char *c_ptr;
> + int name_size;
> + int i;
> +
> + const char *na = "--N/A--";
> + char *back;
> +
> + p_rom = ctx->bios;
> +
> + str_num = *(p_rom + 

Re: [PATCH] drm/amdgpu: Add vbios info ioctl interface

[StDenis, Tom]

[AMD Official Use Only - Internal Distribution Only]

Done.


From: Alex Deucher 
Sent: Wednesday, April 28, 2021 16:53
To: StDenis, Tom
Cc: Gu, JiaWei (Will); Christian König; Nieto, David M; 
amd-gfx@lists.freedesktop.org; Deucher, Alexander
Subject: Re: [PATCH] drm/amdgpu: Add vbios info ioctl interface

Please revert the patch in umr until the kernel side lands in upstream drm-next.

Alex

On Wed, Apr 28, 2021 at 7:30 AM StDenis, Tom  wrote:
>
> [AMD Official Use Only - Internal Distribution Only]
>
> Hi Will,
>
> I've merged in your v2 patch last week.  If that's still the latest you 
> should be good to go.
>
> Tom
>
> 
> From: Gu, JiaWei (Will) 
> Sent: Wednesday, April 28, 2021 06:38
> To: Christian König; Nieto, David M; amd-gfx@lists.freedesktop.org; StDenis, 
> Tom
> Cc: Deucher, Alexander
> Subject: RE: [PATCH] drm/amdgpu: Add vbios info ioctl interface
>
> [AMD Official Use Only - Internal Distribution Only]
>
> Hi @StDenis, Tom<mailto:tom.stde...@amd.com>,
>
> We have merged vbios info ioctl patch.
> Could you help re-merge the UMR side one again if it was reverted before?
>
> Thanks in advance!
> Jiawei
>
> From: Gu, JiaWei (Will)
> Sent: Wednesday, April 28, 2021 4:21 PM
> To: Christian König ; Nieto, David M 
> ; amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander ; StDenis, Tom 
> 
> Subject: RE: [PATCH] drm/amdgpu: Add vbios info ioctl interface
>
>
> [AMD Official Use Only - Internal Distribution Only]
>
> Thanks Christian,
>
> I amended the commit message and resend the patch out.
> Please feel free to let me know if message is not clear enough.
>
> Best regards,
> Jiawei
>
> From: Christian König 
> mailto:ckoenig.leichtzumer...@gmail.com>>
> Sent: Wednesday, April 28, 2021 3:43 PM
> To: Nieto, David M mailto:david.ni...@amd.com>>; Gu, 
> JiaWei (Will) mailto:jiawei...@amd.com>>; 
> amd-gfx@lists.freedesktop.org<mailto:amd-gfx@lists.freedesktop.org>
> Cc: Deucher, Alexander 
> mailto:alexander.deuc...@amd.com>>; StDenis, Tom 
> mailto:tom.stde...@amd.com>>
> Subject: Re: [PATCH] drm/amdgpu: Add vbios info ioctl interface
>
> Yeah, makes sense. Please note that in the commit message.
>
> With that feel free to put an Acked-by: Christian König 
> <mailto:christian.koe...@amd.com> on it.
>
> Regards,
> Christian.
> Am 28.04.21 um 09:25 schrieb Nieto, David M:
> I think this change may be orthogonal to that. Here we want to provide a way 
> for the user application to get the VBIOS information without having to parse 
> the binary…
>
> And I agree that we should not have strong dependencies unless the encounter 
> buggy VBIOS on the field, but I still think it is useful for the user to be 
> able to display in a simple way the VBIOS version in their system if they 
> happen to encounter an issue.
>
> Regards,
> David
>
> From: Christian König 
> <mailto:ckoenig.leichtzumer...@gmail.com>
> Date: Wednesday, April 28, 2021 at 12:15 AM
> To: "Nieto, David M" <mailto:david.ni...@amd.com>, "Gu, 
> JiaWei (Will)" <mailto:jiawei...@amd.com>, 
> "amd-gfx@lists.freedesktop.org"<mailto:amd-gfx@lists.freedesktop.org> 
> <mailto:amd-gfx@lists.freedesktop.org>
> Cc: "Deucher, Alexander" 
> <mailto:alexander.deuc...@amd.com>, "StDenis, Tom" 
> <mailto:tom.stde...@amd.com>
> Subject: Re: [PATCH] drm/amdgpu: Add vbios info ioctl interface
>
> Well displaying the VBIOS information along with the other firmware in 
> userspace is certainly useful.
>
> We should just avoid making strong dependencies on that.
>
> Firmware and VBIOS must always be backward compatible and the driver must 
> always work with any released firmware and VBIOS combination.
>
> What we can do is to display a warning when we detect and/or old/buggy 
> firmware.
>
> Regards,
> Christian.
> Am 28.04.21 um 08:47 schrieb Nieto, David M:
> Besides system management, it provides parseable details on the VBIOS version 
> and information. This is useful renderer information as the GPU behavior 
> depends not only on the driver version but also on the firmwares running on 
> the GPU.
>
> The AMDGPU_INFO ioctl contains a method to get the versions of the ucode for 
> all the IPs, but for VBIOS, only a way to dump the entire image is provided. 
> While it Is possible to implement the whole logic of VBIOS parsing on 
> userspace, it requires the application to have details on the header and 
> table formats to parse the data. Moreover there is no guarantee that the 
> format and header 

Re: [PATCH] drm/amdgpu: Add vbios info ioctl interface

[StDenis, Tom]

[AMD Official Use Only - Internal Distribution Only]

Hi Will,

I've merged in your v2 patch last week.  If that's still the latest you should 
be good to go.

Tom


From: Gu, JiaWei (Will) 
Sent: Wednesday, April 28, 2021 06:38
To: Christian König; Nieto, David M; amd-gfx@lists.freedesktop.org; StDenis, Tom
Cc: Deucher, Alexander
Subject: RE: [PATCH] drm/amdgpu: Add vbios info ioctl interface

[AMD Official Use Only - Internal Distribution Only]

Hi @StDenis, Tom<mailto:tom.stde...@amd.com>,

We have merged vbios info ioctl patch.
Could you help re-merge the UMR side one again if it was reverted before?

Thanks in advance!
Jiawei

From: Gu, JiaWei (Will)
Sent: Wednesday, April 28, 2021 4:21 PM
To: Christian König ; Nieto, David M 
; amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander ; StDenis, Tom 

Subject: RE: [PATCH] drm/amdgpu: Add vbios info ioctl interface


[AMD Official Use Only - Internal Distribution Only]

Thanks Christian,

I amended the commit message and resend the patch out.
Please feel free to let me know if message is not clear enough.

Best regards,
Jiawei

From: Christian König 
mailto:ckoenig.leichtzumer...@gmail.com>>
Sent: Wednesday, April 28, 2021 3:43 PM
To: Nieto, David M mailto:david.ni...@amd.com>>; Gu, 
JiaWei (Will) mailto:jiawei...@amd.com>>; 
amd-gfx@lists.freedesktop.org<mailto:amd-gfx@lists.freedesktop.org>
Cc: Deucher, Alexander 
mailto:alexander.deuc...@amd.com>>; StDenis, Tom 
mailto:tom.stde...@amd.com>>
Subject: Re: [PATCH] drm/amdgpu: Add vbios info ioctl interface

Yeah, makes sense. Please note that in the commit message.

With that feel free to put an Acked-by: Christian König 
<mailto:christian.koe...@amd.com> on it.

Regards,
Christian.
Am 28.04.21 um 09:25 schrieb Nieto, David M:
I think this change may be orthogonal to that. Here we want to provide a way 
for the user application to get the VBIOS information without having to parse 
the binary…

And I agree that we should not have strong dependencies unless the encounter 
buggy VBIOS on the field, but I still think it is useful for the user to be 
able to display in a simple way the VBIOS version in their system if they 
happen to encounter an issue.

Regards,
David

From: Christian König 
<mailto:ckoenig.leichtzumer...@gmail.com>
Date: Wednesday, April 28, 2021 at 12:15 AM
To: "Nieto, David M" <mailto:david.ni...@amd.com>, "Gu, 
JiaWei (Will)" <mailto:jiawei...@amd.com>, 
"amd-gfx@lists.freedesktop.org"<mailto:amd-gfx@lists.freedesktop.org> 
<mailto:amd-gfx@lists.freedesktop.org>
Cc: "Deucher, Alexander" 
<mailto:alexander.deuc...@amd.com>, "StDenis, Tom" 
<mailto:tom.stde...@amd.com>
Subject: Re: [PATCH] drm/amdgpu: Add vbios info ioctl interface

Well displaying the VBIOS information along with the other firmware in 
userspace is certainly useful.

We should just avoid making strong dependencies on that.

Firmware and VBIOS must always be backward compatible and the driver must 
always work with any released firmware and VBIOS combination.

What we can do is to display a warning when we detect and/or old/buggy firmware.

Regards,
Christian.
Am 28.04.21 um 08:47 schrieb Nieto, David M:
Besides system management, it provides parseable details on the VBIOS version 
and information. This is useful renderer information as the GPU behavior 
depends not only on the driver version but also on the firmwares running on the 
GPU.

The AMDGPU_INFO ioctl contains a method to get the versions of the ucode for 
all the IPs, but for VBIOS, only a way to dump the entire image is provided. 
While it Is possible to implement the whole logic of VBIOS parsing on 
userspace, it requires the application to have details on the header and table 
formats to parse the data. Moreover there is no guarantee that the format and 
header locations will remain constant across ASIC generations, so the 
maintainance cost and complexity seems unreasonable.

Providing a simple, and stable interface to the application seems to us like a 
sensible choice.

Thanks,
David

From: amd-gfx 
<mailto:amd-gfx-boun...@lists.freedesktop.org>
 on behalf of "Gu, JiaWei (Will)" <mailto:jiawei...@amd.com>
Date: Thursday, April 22, 2021 at 8:25 PM
To: Christian König 
<mailto:ckoenig.leichtzumer...@gmail.com>, 
"amd-gfx@lists.freedesktop.org"<mailto:amd-gfx@lists.freedesktop.org> 
<mailto:amd-gfx@lists.freedesktop.org>
Cc: "Deucher, Alexander" 
<mailto:alexander.deuc...@amd.com>, "StDenis, Tom" 
<mailto:tom.stde...@amd.com>, "Nieto, David M" 
<mailto:david.ni...@amd.com>
Subject: RE: [PATCH] drm/amdgpu: Add vbios info ioctl interface


[AMD Official Use Only - Internal Distribution Only]

Hi Christian,
It will be used by a user space SMI-lib for GPU status query.

Re: [PATCH 1/1] drm/amdgpu: make BO type check less restrictive

[StDenis, Tom]

[AMD Official Use Only - Internal Distribution Only]

FWIW the patch seems to fix the issue I was seeing :-)

Tom


From: Koenig, Christian 
Sent: Monday, March 15, 2021 11:22
To: Das, Nirmoy
Cc: amd-gfx@lists.freedesktop.org; StDenis, Tom
Subject: Re: [PATCH 1/1] drm/amdgpu: make BO type check less restrictive

Am 15.03.21 um 16:14 schrieb Nirmoy Das:
> BO with ttm_bo_type_sg type can also have tiling_flag and metadata.
> So so BO type check for only ttm_bo_type_kernel.
>
> Signed-off-by: Nirmoy Das 
> Reported-by: Tom StDenis 

At some point we should probably add a amdgpu_bo_is_user() helper
function, but for now that should work.

Reviewed-by: Christian König 

> ---
>   drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 8 
>   1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> index ac0e1cd83858..fdf23e439b42 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> @@ -1167,7 +1167,7 @@ int amdgpu_bo_set_tiling_flags(struct amdgpu_bo *bo, 
> u64 tiling_flags)
>   struct amdgpu_device *adev = amdgpu_ttm_adev(bo->tbo.bdev);
>   struct amdgpu_bo_user *ubo;
>
> - BUG_ON(bo->tbo.type != ttm_bo_type_device);
> + BUG_ON(bo->tbo.type == ttm_bo_type_kernel);
>   if (adev->family <= AMDGPU_FAMILY_CZ &&
>   AMDGPU_TILING_GET(tiling_flags, TILE_SPLIT) > 6)
>   return -EINVAL;
> @@ -1189,7 +1189,7 @@ void amdgpu_bo_get_tiling_flags(struct amdgpu_bo *bo, 
> u64 *tiling_flags)
>   {
>   struct amdgpu_bo_user *ubo;
>
> - BUG_ON(bo->tbo.type != ttm_bo_type_device);
> + BUG_ON(bo->tbo.type == ttm_bo_type_kernel);
>   dma_resv_assert_held(bo->tbo.base.resv);
>   ubo = to_amdgpu_bo_user(bo);
>
> @@ -1216,7 +1216,7 @@ int amdgpu_bo_set_metadata (struct amdgpu_bo *bo, void 
> *metadata,
>   struct amdgpu_bo_user *ubo;
>   void *buffer;
>
> - BUG_ON(bo->tbo.type != ttm_bo_type_device);
> + BUG_ON(bo->tbo.type == ttm_bo_type_kernel);
>   ubo = to_amdgpu_bo_user(bo);
>   if (!metadata_size) {
>   if (ubo->metadata_size) {
> @@ -1266,7 +1266,7 @@ int amdgpu_bo_get_metadata(struct amdgpu_bo *bo, void 
> *buffer,
>   if (!buffer && !metadata_size)
>   return -EINVAL;
>
> - BUG_ON(bo->tbo.type != ttm_bo_type_device);
> + BUG_ON(bo->tbo.type == ttm_bo_type_kernel);
>   ubo = to_amdgpu_bo_user(bo);
>   if (buffer) {
>   if (buffer_size < ubo->metadata_size)

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH umr] Fix register name lookup for sdma POLL_REGMEM packet

[StDenis, Tom]

[AMD Official Use Only - Internal Distribution Only]

Hi Xiaojie,

I've pushed your patch out to main.  In reviewing the SDMA opcode I actually 
noticed a couple of other minor things to fix up so I've pushed that out too.

Cheers,
Tom


From: Yuan, Xiaojie 
Sent: Monday, September 21, 2020 23:02
To: amd-gfx@lists.freedesktop.org; StDenis, Tom
Cc: Yuan, Xiaojie
Subject: [PATCH umr] Fix register name lookup for sdma POLL_REGMEM packet

POLL_REGMEM_ADDR_LO/HI are in byte but umr_reg_name() expects register address 
in dword

Signed-off-by: Xiaojie Yuan 
---
 src/lib/ring_decode.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/lib/ring_decode.c b/src/lib/ring_decode.c
index a74229d..b5838d1 100644
--- a/src/lib/ring_decode.c
+++ b/src/lib/ring_decode.c
@@ -1904,10 +1904,10 @@ static void parse_next_sdma_pkt(struct umr_asic *asic, 
struct umr_ring_decoder *
case 0: // WAIT_REG_MEM
switch (decoder->sdma.cur_word) {
case 1: 
printf("POLL_REGMEM_ADDR_LO: %s0x%08lx%s", YELLOW, (unsigned long)ib, RST);
-   if 
(!(decoder->sdma.header_dw & (1UL << 31))) printf("(%s)", umr_reg_name(asic, 
ib));
+   if 
(!(decoder->sdma.header_dw & (1UL << 31))) printf("(%s)", umr_reg_name(asic, ib 
>> 2));
break;
case 2: 
printf("POLL_REGMEM_ADDR_HI: %s0x%08lx%s", YELLOW, (unsigned long)ib, RST);
-   if 
(!(decoder->sdma.header_dw & (1UL << 31))) printf("(%s)", umr_reg_name(asic, 
ib));
+   if 
(!(decoder->sdma.header_dw & (1UL << 31))) printf("(%s)", umr_reg_name(asic, ib 
>> 2));
break;
case 3: 
printf("POLL_REGMEM_ADDR_VALUE: %s0x%08lx%s", BLUE, (unsigned long)ib, RST);
break;
--
2.20.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] drm/amd/powerplay: Fix uninitialized warning in arcturus ppt driver

[StDenis, Tom]

[AMD Official Use Only - Internal Distribution Only]

Hi Kevin,

Ah ok disregard the (v2) I just sent then :-)

Thanks,
Tom


From: Wang, Kevin(Yang) 
Sent: Wednesday, August 12, 2020 22:47
To: Quan, Evan; StDenis, Tom; amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/amd/powerplay: Fix uninitialized warning in arcturus 
ppt driver

[AMD Official Use Only - Internal Distribution Only]

Hi Tom,

drm/amdgpu: fix uninit-value in arcturus_log_thermal_throttling_event()

the fixed patch has been merged into drm-next branch.

Best Regards,
Kevin


From: amd-gfx  on behalf of Quan, Evan 

Sent: Thursday, August 13, 2020 10:07 AM
To: StDenis, Tom ; amd-gfx@lists.freedesktop.org 

Cc: StDenis, Tom 
Subject: RE: [PATCH] drm/amd/powerplay: Fix uninitialized warning in arcturus 
ppt driver

[AMD Official Use Only - Internal Distribution Only]

[AMD Official Use Only - Internal Distribution Only]

Your change below should be able to suppress the compile warning.
-arcturus_get_smu_metrics_data(smu,
+ret = arcturus_get_smu_metrics_data(smu,
   METRICS_THROTTLER_STATUS,
   _status);

+if (ret) {
+dev_err(adev->dev, "Could not read from arcturus_get_smu_metrics_data()\n");
+return;
+}
+
Setting *value as 0 may be unnecessary.  However anyway this patch is 
reviewed-by: Evan Quan 

BR
Evan
-Original Message-
From: amd-gfx  On Behalf Of Tom St Denis
Sent: Wednesday, August 12, 2020 8:21 PM
To: amd-gfx@lists.freedesktop.org
Cc: StDenis, Tom 
Subject: [PATCH] drm/amd/powerplay: Fix uninitialized warning in arcturus ppt 
driver

Fixes:

  CC [M]  drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_mst_types.o
drivers/gpu/drm/amd/amdgpu/../powerplay/arcturus_ppt.c: In function 
‘arcturus_log_thermal_throttling_event’:
drivers/gpu/drm/amd/amdgpu/../powerplay/arcturus_ppt.c:2223:24: warning: 
‘throttler_status’ may be used uninitialized in this function 
[-Wmaybe-uninitialized]
 2223 |   if (throttler_status & logging_label[throttler_idx].feature_mask) {

by making arcturus_get_smu_metrics_data() assign a default value (of zero) 
before any possible return point as well as simply error out of 
arcturus_log_thermal_throttling_event() if it fails.

Signed-off-by: Tom St Denis 
---
 drivers/gpu/drm/amd/powerplay/arcturus_ppt.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/powerplay/arcturus_ppt.c 
b/drivers/gpu/drm/amd/powerplay/arcturus_ppt.c
index 8b1025dc54fd..78f7ec95e4f5 100644
--- a/drivers/gpu/drm/amd/powerplay/arcturus_ppt.c
+++ b/drivers/gpu/drm/amd/powerplay/arcturus_ppt.c
@@ -551,6 +551,9 @@ static int arcturus_get_smu_metrics_data(struct smu_context 
*smu,

 mutex_lock(>metrics_lock);

+// assign default value
+*value = 0;
+
 ret = smu_cmn_get_metrics_table_locked(smu,
NULL,
false);
@@ -2208,15 +2211,20 @@ static const struct throttling_logging_label {  };  
static void arcturus_log_thermal_throttling_event(struct smu_context *smu)  {
-int throttler_idx, throtting_events = 0, buf_idx = 0;
+int throttler_idx, throtting_events = 0, buf_idx = 0, ret;
 struct amdgpu_device *adev = smu->adev;
 uint32_t throttler_status;
 char log_buf[256];

-arcturus_get_smu_metrics_data(smu,
+ret = arcturus_get_smu_metrics_data(smu,
   METRICS_THROTTLER_STATUS,
   _status);

+if (ret) {
+dev_err(adev->dev, "Could not read from arcturus_get_smu_metrics_data()\n");
+return;
+}
+
 memset(log_buf, 0, sizeof(log_buf));
 for (throttler_idx = 0; throttler_idx < ARRAY_SIZE(logging_label);
  throttler_idx++) {
--
2.26.2

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfxdata=02%7C01%7CKevin1.Wang%40amd.com%7Cf47512097dfc40168e1a08d83f2db359%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637328812813110771sdata=xedbRrZeOi0PK3EM%2FKBYhfXxdfpOkocXPjQjcQ5ErI0%3Dreserved=0
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfxdata=02%7C01%7CKevin1.Wang%40amd.com%7Cf47512097dfc40168e1a08d83f2db359%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637328812813110771sdata=xedbRrZeOi0PK3EM%2FKBYhfXxdfpOkocXPjQjcQ5ErI0%3Dreserved=0
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] drm/amd/powerplay: Fix uninitialized warning in arcturus ppt driver

[StDenis, Tom]

[AMD Official Use Only - Internal Distribution Only]

Possibly, but since the arcturus_get_smu_metrics_data() can error out we should 
check that return value no?

(also setting *value to 0 avoids this bug in the future...).

Tom


From: Das, Nirmoy 
Sent: Wednesday, August 12, 2020 08:40
To: StDenis, Tom; amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/amd/powerplay: Fix uninitialized warning in arcturus 
ppt driver


On 8/12/20 2:20 PM, Tom St Denis wrote:
> Fixes:
>
>CC [M]  
> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_mst_types.o
> drivers/gpu/drm/amd/amdgpu/../powerplay/arcturus_ppt.c: In function 
> ‘arcturus_log_thermal_throttling_event’:
> drivers/gpu/drm/amd/amdgpu/../powerplay/arcturus_ppt.c:2223:24: warning: 
> ‘throttler_status’ may be used uninitialized in this function 
> [-Wmaybe-uninitialized]
>   2223 |   if (throttler_status & logging_label[throttler_idx].feature_mask) {
>
> by making arcturus_get_smu_metrics_data() assign a default value
> (of zero) before any possible return point as well as simply error
> out of arcturus_log_thermal_throttling_event() if it fails.
>
> Signed-off-by: Tom St Denis 
> ---
>   drivers/gpu/drm/amd/powerplay/arcturus_ppt.c | 12 ++--
>   1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/powerplay/arcturus_ppt.c 
> b/drivers/gpu/drm/amd/powerplay/arcturus_ppt.c
> index 8b1025dc54fd..78f7ec95e4f5 100644
> --- a/drivers/gpu/drm/amd/powerplay/arcturus_ppt.c
> +++ b/drivers/gpu/drm/amd/powerplay/arcturus_ppt.c
> @@ -551,6 +551,9 @@ static int arcturus_get_smu_metrics_data(struct 
> smu_context *smu,
>
>   mutex_lock(>metrics_lock);
>
> + // assign default value
> + *value = 0;
> +
>   ret = smu_cmn_get_metrics_table_locked(smu,
>  NULL,
>  false);
> @@ -2208,15 +2211,20 @@ static const struct throttling_logging_label {
>   };
>   static void arcturus_log_thermal_throttling_event(struct smu_context *smu)
>   {
> - int throttler_idx, throtting_events = 0, buf_idx = 0;
> + int throttler_idx, throtting_events = 0, buf_idx = 0, ret;
>   struct amdgpu_device *adev = smu->adev;
>   uint32_t throttler_status;


I think initializing throttler_status here should resolve the warning.

>   char log_buf[256];
>
> - arcturus_get_smu_metrics_data(smu,
> + ret = arcturus_get_smu_metrics_data(smu,
> METRICS_THROTTLER_STATUS,
> _status);
>
> + if (ret) {
> + dev_err(adev->dev, "Could not read from 
> arcturus_get_smu_metrics_data()\n");
> + return;
> + }
> +
>   memset(log_buf, 0, sizeof(log_buf));
>   for (throttler_idx = 0; throttler_idx < ARRAY_SIZE(logging_label);
>throttler_idx++) {
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH UMR] Fix off-by-one error for decoding sdma linear write packet

[StDenis, Tom]

[AMD Official Use Only - Internal Distribution Only]

Applied and pushed out to master.

Thanks!

Tom


From: Yuan, Xiaojie 
Sent: Tuesday, July 14, 2020 11:35
To: StDenis, Tom; amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH UMR] Fix off-by-one error for decoding sdma linear write 
packet

[AMD Official Use Only - Internal Distribution Only]

Sure Tom, here it is.

BR,
Xiaojie


From: StDenis, Tom 
Sent: Tuesday, July 14, 2020 10:11 PM
To: Yuan, Xiaojie; amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH UMR] Fix off-by-one error for decoding sdma linear write 
packet

[AMD Official Use Only - Internal Distribution Only]

Thanks, can you attach the patch to your email instead though so it applies 
cleanly?

Cheers,
Tom


From: Yuan, Xiaojie 
Sent: Tuesday, July 14, 2020 00:18
To: amd-gfx@lists.freedesktop.org; StDenis, Tom
Cc: Yuan, Xiaojie
Subject: [PATCH UMR] Fix off-by-one error for decoding sdma linear write packet

COUNT in linear write packet represents dword number - 1

Before fix:
navi10.sdma0.ring[   0] == 0x0002.w. OPCODE: [WRITE], SUB-OPCODE: [0], 
LINEAR_WRITE
navi10.sdma0.ring[   1] == 0x00400a60... |---+ WORD [1]: DST_ADDR_LO: 
0x00400a60
navi10.sdma0.ring[   2] == 0x... |---+ WORD [2]: DST_ADDR_HI: 
0x
navi10.sdma0.ring[   3] == 0x... |---+ WORD [3]: COUNT: 0x
navi10.sdma0.ring[   4] == 0xdeadbeef...

After fix:
navi10.sdma0.ring[   0] == 0x0002.w. OPCODE: [WRITE], SUB-OPCODE: [0], 
LINEAR_WRITE
navi10.sdma0.ring[   1] == 0x00400a60... |---+ WORD [1]: DST_ADDR_LOa: 
0x00400a60
navi10.sdma0.ring[   2] == 0x... |---+ WORD [2]: DST_ADDR_HIb: 
0x
navi10.sdma0.ring[   3] == 0x... |---+ WORD [3]: COUNTc: 0x
navi10.sdma0.ring[   4] == 0xdeadbeef... \---+ WORD [4]: DATA: 0xdeadbeef

Signed-off-by: Xiaojie Yuan 
---
 src/lib/ring_decode.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/lib/ring_decode.c b/src/lib/ring_decode.c
index c3b5d18..a74229d 100644
--- a/src/lib/ring_decode.c
+++ b/src/lib/ring_decode.c
@@ -1819,7 +1819,7 @@ static void parse_next_sdma_pkt(struct umr_asic *asic, 
struct umr_ring_decoder *
case 2: printf("DST_ADDR_HI: 
%s0x%08lx%s", YELLOW, (unsigned long)ib, RST);
break;
case 3: printf("COUNT: 
%s0x%08lx%s", BLUE, (unsigned long)ib, RST);
-   decoder->sdma.n_words 
+= ib - 1;
+   decoder->sdma.n_words 
+= ib;
break;
default: printf("DATA: 
%s0x%08lx%s", BLUE, (unsigned long)ib, RST);
break;
--
2.20.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH UMR] Fix off-by-one error for decoding sdma linear write packet

[StDenis, Tom]

[AMD Official Use Only - Internal Distribution Only]

Thanks, can you attach the patch to your email instead though so it applies 
cleanly?

Cheers,
Tom


From: Yuan, Xiaojie 
Sent: Tuesday, July 14, 2020 00:18
To: amd-gfx@lists.freedesktop.org; StDenis, Tom
Cc: Yuan, Xiaojie
Subject: [PATCH UMR] Fix off-by-one error for decoding sdma linear write packet

COUNT in linear write packet represents dword number - 1

Before fix:
navi10.sdma0.ring[   0] == 0x0002.w. OPCODE: [WRITE], SUB-OPCODE: [0], 
LINEAR_WRITE
navi10.sdma0.ring[   1] == 0x00400a60... |---+ WORD [1]: DST_ADDR_LO: 
0x00400a60
navi10.sdma0.ring[   2] == 0x... |---+ WORD [2]: DST_ADDR_HI: 
0x
navi10.sdma0.ring[   3] == 0x... |---+ WORD [3]: COUNT: 0x
navi10.sdma0.ring[   4] == 0xdeadbeef...

After fix:
navi10.sdma0.ring[   0] == 0x0002.w. OPCODE: [WRITE], SUB-OPCODE: [0], 
LINEAR_WRITE
navi10.sdma0.ring[   1] == 0x00400a60... |---+ WORD [1]: DST_ADDR_LOa: 
0x00400a60
navi10.sdma0.ring[   2] == 0x... |---+ WORD [2]: DST_ADDR_HIb: 
0x
navi10.sdma0.ring[   3] == 0x... |---+ WORD [3]: COUNTc: 0x
navi10.sdma0.ring[   4] == 0xdeadbeef... \---+ WORD [4]: DATA: 0xdeadbeef

Signed-off-by: Xiaojie Yuan 
---
 src/lib/ring_decode.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/lib/ring_decode.c b/src/lib/ring_decode.c
index c3b5d18..a74229d 100644
--- a/src/lib/ring_decode.c
+++ b/src/lib/ring_decode.c
@@ -1819,7 +1819,7 @@ static void parse_next_sdma_pkt(struct umr_asic *asic, 
struct umr_ring_decoder *
case 2: printf("DST_ADDR_HI: 
%s0x%08lx%s", YELLOW, (unsigned long)ib, RST);
break;
case 3: printf("COUNT: 
%s0x%08lx%s", BLUE, (unsigned long)ib, RST);
-   decoder->sdma.n_words 
+= ib - 1;
+   decoder->sdma.n_words 
+= ib;
break;
default: printf("DATA: 
%s0x%08lx%s", BLUE, (unsigned long)ib, RST);
break;
--
2.20.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] drm/amdgpu: remove PT BOs when unmapping

[StDenis, Tom]

I could try it on my carrizo/polaris setup.  Is there a test procedure I 
could folllow to trigger the changed code paths?


Tom

On 2019-10-31 6:41 a.m., Koenig, Christian wrote:
> Just tested this and amdgpu_vm_update_ptes() indeed works as expected.
>
> When you free at least a 2MB the lowest level of page tables is freed 
> up again.
>
> BTW: What hardware have you tested this on? On gfx8 and older it is 
> expected that page tables are never freed.
>
> Regards,
> Christian.
>
> Am 30.10.19 um 19:11 schrieb Christian König:
>> Then I don't see how this patch actually changes anything.
>>
>> Could only be a bug in amdgpu_vm_update_ptes(). Going to investigate 
>> this, but I won't have time to look into the ticket in detail.
>>
>> Regards,
>> Christian.
>>
>> Am 30.10.19 um 19:00 schrieb Huang, JinHuiEric:
>>>
>>> Actually I do prevent to remove in-use pts by this:
>>>
>>> +   r = amdgpu_vm_remove_ptes(adev, vm,
>>> +   (mapping->start + 0x1ff) & (~0x1ffll),
>>> +   (mapping->last + 1) & (~0x1ffll));
>>>
>>> Which is only removing aligned page table for 2M. And I have tested 
>>> it at least on KFD tests without anything broken.
>>>
>>> By the way, I am not familiar with memory staff. This patch is the 
>>> best I can do for now. Could you take a look at the Jira ticket 
>>> SWDEV-201443 ? and find the better solution. Thanks!
>>>
>>> Regards,
>>>
>>> Eric
>>>
>>> On 2019-10-30 1:57 p.m., Christian König wrote:
 One thing I've forgotten:

 What you could maybe do to improve the situation is to join 
 adjacent ranges in amdgpu_vm_clear_freed(), but I'm not sure how 
 the chances are that the ranges are freed all together.

 The only other alternative I can see would be to check the mappings 
 of a range in amdgpu_update_ptes() and see if you could walk the 
 tree up if the valid flag is not set and there are no mappings left 
 for a page table.

 Regards,
 Christian.

 Am 30.10.19 um 18:42 schrieb Koenig, Christian:
>> The vaild flag doesn't take effect in this function.
> That's irrelevant.
>
> See what amdgpu_vm_update_ptes() does is to first determine the 
> fragment size:
>> amdgpu_vm_fragment(params, frag_start, end, flags, , _end);
>
> Then we walk down the tree:
>>     amdgpu_vm_pt_start(adev, params->vm, start, );
>>     while (cursor.pfn < end) {
>
> And make sure that the page tables covering the address range are 
> actually allocated:
>>     r = amdgpu_vm_alloc_pts(params->adev, params->vm, 
>> );
>
> Then we update the tables with the flags and addresses and free up 
> subsequent tables in the case of huge pages or freed up areas:
>>     /* Free all child entries */
>>     while (cursor.pfn < frag_start) {
>> amdgpu_vm_free_pts(adev, params->vm, );
>> amdgpu_vm_pt_next(adev, );
>>     }
>
> This is the maximum you can free, cause all other page tables are 
> not completely covered by the range and so potentially still in use.
>
> And I have the strong suspicion that this is what your patch is 
> actually doing wrong. In other words you are also freeing page 
> tables which are only partially covered by the range and so 
> potentially still in use.
>
> Since we don't have any tracking how many entries in a page table 
> are currently valid and how many are invalid we actually can't 
> implement what you are trying to do here. So the patch is 
> definitely somehow broken.
>
> Regards,
> Christian.
>
> Am 30.10.19 um 17:55 schrieb Huang, JinHuiEric:
>>
>> The vaild flag doesn't take effect in this function. 
>> amdgpu_vm_alloc_pts() is always executed that only depended on 
>> "cursor.pfn < end". The valid flag has only been checked on here 
>> for asic below GMC v9:
>>
>> if (adev->asic_type < CHIP_VEGA10 &&
>>             (flags & AMDGPU_PTE_VALID))...
>>
>> Regards,
>>
>> Eric
>>
>> On 2019-10-30 12:30 p.m., Koenig, Christian wrote:
>>>
>>>
>>> Am 30.10.2019 17:19 schrieb "Huang, JinHuiEric" 
>>> :
>>>
>>> I tested it that it saves a lot of vram on KFD big buffer
>>> stress test. I think there are two reasons:
>>>
>>> 1. Calling amdgpu_vm_update_ptes() during unmapping will
>>> allocate unnecessary pts, because there is no flag to
>>> determine if the VA is mapping or unmapping in function
>>> amdgpu_vm_update_ptes(). It saves the most of memory.
>>>
>>> That's not correct. The valid flag is used for this.
>>>
>>> 2. Intentionally removing those unmapping pts is logical
>>> expectation, although it is not removing so much pts.
>>>
>>> Well I actually don't see a 

Re: [PATCH 1/1] drm/amdgpu: add missing amdgpu_ras.h header include

[StDenis, Tom]

Compiles fine.


Tested-by: Tom St Denis 


On 2019-10-29 8:43 a.m., Deucher, Alexander wrote:
> Acked-by: Alex Deucher 
> 
> *From:* amd-gfx  on behalf of 
> Le Ma 
> *Sent:* Tuesday, October 29, 2019 8:42 AM
> *To:* amd-gfx@lists.freedesktop.org 
> *Cc:* StDenis, Tom ; Ma, Le 
> *Subject:* [PATCH 1/1] drm/amdgpu: add missing amdgpu_ras.h header 
> include
> Fix compilation error.
>
> Change-Id: I461c558778f9a52378269324dc41b8d639f3ccbe
> Signed-off-by: Le Ma 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
> index fce206f..bbe9ac7 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
> @@ -34,6 +34,8 @@
>  #include "psp_v11_0.h"
>  #include "psp_v12_0.h"
>
> +#include "amdgpu_ras.h"
> +
>  static void psp_set_funcs(struct amdgpu_device *adev);
>
>  static int psp_early_init(void *handle)
> -- 
> 2.7.4
>
> ___
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] Ring range argument improvements (v3)

[StDenis, Tom]

Thanks, pushed out.


Cheers,

Tom

On 2019-10-24 2:27 p.m., Tuikov, Luben wrote:
> The valid contents of rings is invariably the
> range [rptr, wptr). Augment the ring range to
> interpret the '.' ("here") notation to mean rptr
> or wptr when given on the left or right of the
> range limits. This augments the range notation as
> follows:
>
> 1) No range given, print the whole ring.
>
> 2) [.] or [.:.], print [rptr, wptr],
>
> 3) [.:k], k >= 0, print [rptr, rptr + k], this is
> a range relative to the left limit, rptr, the
> consumer pointer.
>
> 4) [k:.] or [k], k >= 0, print [wptr - k, wptr], this is
> a range relative to the right limit, wptr, the
> producer pointer.
>
> 5) [k:r], both greater than 0, print [k,r] of the
> named ring. This is an absolute range limit
> notation.
>
> In any case, the ring contents is interpreted, if
> the ring contents can be interpreted.
>
> v2: Fix spelling mistake in the commit message:
> "then" --> "than".
> v3: Fix decoding.
>
> Signed-off-by: Luben Tuikov 
> ---
>   doc/umr.1   | 33 +
>   src/app/ring_read.c | 59 +++--
>   2 files changed, 59 insertions(+), 33 deletions(-)
>
> diff --git a/doc/umr.1 b/doc/umr.1
> index 1e585fa..137ff1e 100644
> --- a/doc/umr.1
> +++ b/doc/umr.1
> @@ -216,17 +216,30 @@ Disassemble 'size' bytes (in hex) from a given address 
> (in hex).  The size can b
>   specified as zero to have umr try and compute the shader size.
>   
>   .SH Ring and PM4 Decoding
> -.IP "--ring, -R (from:to)"
> -Read the contents of a ring named by the string without the
> -.B amdgpu_ring_
> -prefix.  By default it will read and display the entire ring.  A
> -starting and ending address can be specified in decimal or a '.' can
> -be used to indicate relative to the current
> +.IP "--ring, -R [range]"
> +Read the contents of the ring named by the string
> +.B amdgpu_ring_,
> +i.e. without the
> +.B amdgpu_ring
> +prefix. By default it reads and prints the entire ring.  A
> +range is optional and has the format '[start:end]'. The
> +starting and ending address are non-negative integers or
> +the '.' (dot) symbol, which indicates the
> +.B rptr
> +when on the left side and
>   .B wptr
> -pointer.  For example, "-R gfx" would read the entire gfx ring,
> -"-R gfx[0:16]" would display the contents from 0 to 16 inclusively, and
> -"-R gfx[.]" or "-R gfx[.:.]" would display the last 32 words relative
> -to rptr.
> +when on the right side of the range.
> +For instance,
> +"-R gfx" prints the entire gfx ring, "-R gfx[0:16]" prints
> +the contents from 0 to 16 inclusively, and "-R gfx[.]" or
> +"-R gfx[.:.]" prints the range [rptr,wptr]. When one of
> +the range limits is a number while the other is the dot, '.',
> +then the number indicates the relative range before or after the
> +corresponding ring pointer. For instance, "-R sdma0[16:.]"
> +prints [wptr-16, wptr] words of the SDMA0 ring, and
> +"-R sdma1[.:32]" prints [rptr, rptr+32] double-words of the
> +SDMA1 ring. The contents of the ring is always interpreted,
> +if it can be interpreted.
>   .IP "--dump-ib, -di [vmid@]address length [pm]"
>   Dump an IB packet at an address with an optional VMID.  The length is 
> specified
>   in bytes.  The type of decoder  is optional and defaults to PM4 packets.
> diff --git a/src/app/ring_read.c b/src/app/ring_read.c
> index ef0c711..b995188 100644
> --- a/src/app/ring_read.c
> +++ b/src/app/ring_read.c
> @@ -28,7 +28,7 @@
>   void umr_read_ring(struct umr_asic *asic, char *ringpath)
>   {
>   char ringname[32], from[32], to[32];
> - int use_decoder, enable_decoder, gprs;
> + int  enable_decoder, gprs;
>   uint32_t wptr, rptr, drv_wptr, ringsize, start, end, value,
>*ring_data;
>   struct umr_ring_decoder decoder, *pdecoder, *ppdecoder;
> @@ -73,33 +73,46 @@ void umr_read_ring(struct umr_asic *asic, char *ringpath)
>   drv_wptr = ring_data[2]<<2;
>   
>   /* default to reading entire ring */
> - use_decoder = 0;
>   if (!from[0]) {
>   start = 0;
>   end   = ringsize-4;
>   } else {
> - if (from[0] == '.' || !to[0] || to[0] == '.') {
> - /* start from 32 words prior to rptr up to wptr */
> - end = wptr;
> - if (rptr < (31*4)) {
> - start = rptr - 31*4;
> - start += ringsize;
> + if (from[0] == '.') {
> + if (to[0] == 0 || to[0] == '.') {
> + /* Notation: [.] or [.:.], meaning
> +  * [rptr, wptr].
> +  */
> + start = rptr;
> + end = wptr;
>   } else {
> - start = rptr - 31*4;
> + /* Notation: [.:k], k >=0, meaning
> +  * [rptr, 

Re: [PATCH] Ring range argument improvements (v2)

[StDenis, Tom]

This diff fixes your patch, can you resend please?


diff --git a/src/app/ring_read.c b/src/app/ring_read.c
index 9cbecb0..c1c9187 100644
--- a/src/app/ring_read.c
+++ b/src/app/ring_read.c
@@ -120,16 +120,16 @@ void umr_read_ring(struct umr_asic *asic, char 
*ringpath)
     asic->asicname, ringname, (unsigned long)wptr >> 2,
     asic->asicname, ringname, (unsigned long)drv_wptr >> 2);

+   if (enable_decoder) {
+   decoder.pm4.cur_opcode = 0x;
+   decoder.sdma.cur_opcode = 0x;
+   }
     do {
     value = ring_data[(start+12)>>2];
     printf("%s.%s.ring[%s%4lu%s] == %s0x%08lx%s   ",
     asic->asicname, ringname,
     BLUE, (unsigned long)start >> 2, RST,
     YELLOW, (unsigned long)value, RST);
-   if (enable_decoder) {
-   decoder.pm4.cur_opcode = 0x;
-   decoder.sdma.cur_opcode = 0x;
-   }
     printf(" %c%c%c ",
     (start == rptr) ? 'r' : '.',
     (start == wptr) ? 'w' : '.',

On 2019-10-23 5:11 p.m., Tuikov, Luben wrote:
> The valid contents of rings is invariably the
> range [rptr, wptr). Augment the ring range to
> interpret the '.' ("here") notation to mean rptr
> or wptr when given on the left or right of the
> range limits. This augments the range notation as
> follows:
>
> 1) No range given, print the whole ring.
>
> 2) [.] or [.:.], print [rptr, wptr],
>
> 3) [.:k], k >= 0, print [rptr, rptr + k], this is
> a range relative to the left limit, rptr, the
> consumer pointer.
>
> 4) [k:.] or [k], k >= 0, print [wptr - k, wptr], this is
> a range relative to the right limit, wptr, the
> producer pointer.
>
> 5) [k:r], both greater than 0, print [k,r] of the
> named ring. This is an absolute range limit
> notation.
>
> In any case, the ring contents is interpreted, if
> the ring contents can be interpreted.
>
> v2: Fix spelling mistake in the commit message:
> "then" --> "than".
>
> Signed-off-by: Luben Tuikov 
> ---
>   doc/umr.1   | 33 +++-
>   src/app/ring_read.c | 52 -
>   2 files changed, 55 insertions(+), 30 deletions(-)
>
> diff --git a/doc/umr.1 b/doc/umr.1
> index 1e585fa..137ff1e 100644
> --- a/doc/umr.1
> +++ b/doc/umr.1
> @@ -216,17 +216,30 @@ Disassemble 'size' bytes (in hex) from a given address 
> (in hex).  The size can b
>   specified as zero to have umr try and compute the shader size.
>   
>   .SH Ring and PM4 Decoding
> -.IP "--ring, -R (from:to)"
> -Read the contents of a ring named by the string without the
> -.B amdgpu_ring_
> -prefix.  By default it will read and display the entire ring.  A
> -starting and ending address can be specified in decimal or a '.' can
> -be used to indicate relative to the current
> +.IP "--ring, -R [range]"
> +Read the contents of the ring named by the string
> +.B amdgpu_ring_,
> +i.e. without the
> +.B amdgpu_ring
> +prefix. By default it reads and prints the entire ring.  A
> +range is optional and has the format '[start:end]'. The
> +starting and ending address are non-negative integers or
> +the '.' (dot) symbol, which indicates the
> +.B rptr
> +when on the left side and
>   .B wptr
> -pointer.  For example, "-R gfx" would read the entire gfx ring,
> -"-R gfx[0:16]" would display the contents from 0 to 16 inclusively, and
> -"-R gfx[.]" or "-R gfx[.:.]" would display the last 32 words relative
> -to rptr.
> +when on the right side of the range.
> +For instance,
> +"-R gfx" prints the entire gfx ring, "-R gfx[0:16]" prints
> +the contents from 0 to 16 inclusively, and "-R gfx[.]" or
> +"-R gfx[.:.]" prints the range [rptr,wptr]. When one of
> +the range limits is a number while the other is the dot, '.',
> +then the number indicates the relative range before or after the
> +corresponding ring pointer. For instance, "-R sdma0[16:.]"
> +prints [wptr-16, wptr] words of the SDMA0 ring, and
> +"-R sdma1[.:32]" prints [rptr, rptr+32] double-words of the
> +SDMA1 ring. The contents of the ring is always interpreted,
> +if it can be interpreted.
>   .IP "--dump-ib, -di [vmid@]address length [pm]"
>   Dump an IB packet at an address with an optional VMID.  The length is 
> specified
>   in bytes.  The type of decoder  is optional and defaults to PM4 packets.
> diff --git a/src/app/ring_read.c b/src/app/ring_read.c
> index ef0c711..9cbecb0 100644
> --- a/src/app/ring_read.c
> +++ b/src/app/ring_read.c
> @@ -28,7 +28,7 @@
>   void umr_read_ring(struct umr_asic *asic, char *ringpath)
>   {
>   char ringname[32], from[32], to[32];
> - int use_decoder, enable_decoder, gprs;
> + int  enable_decoder, gprs;
>   uint32_t wptr, rptr, drv_wptr, ringsize, start, end, value,
>*ring_data;
>   struct umr_ring_decoder decoder, *pdecoder, *ppdecoder;
> @@ -73,33 

Re: [PATCH] Ring range argument improvements (v2)

[StDenis, Tom]

NAK, this patch breaks something in decoding the words of the packets.  
Instead of decoding I get a lot of PKT0 lines.  I'll see if I can debug 
this.


Tom

On 2019-10-23 5:11 p.m., Tuikov, Luben wrote:
> The valid contents of rings is invariably the
> range [rptr, wptr). Augment the ring range to
> interpret the '.' ("here") notation to mean rptr
> or wptr when given on the left or right of the
> range limits. This augments the range notation as
> follows:
>
> 1) No range given, print the whole ring.
>
> 2) [.] or [.:.], print [rptr, wptr],
>
> 3) [.:k], k >= 0, print [rptr, rptr + k], this is
> a range relative to the left limit, rptr, the
> consumer pointer.
>
> 4) [k:.] or [k], k >= 0, print [wptr - k, wptr], this is
> a range relative to the right limit, wptr, the
> producer pointer.
>
> 5) [k:r], both greater than 0, print [k,r] of the
> named ring. This is an absolute range limit
> notation.
>
> In any case, the ring contents is interpreted, if
> the ring contents can be interpreted.
>
> v2: Fix spelling mistake in the commit message:
> "then" --> "than".
>
> Signed-off-by: Luben Tuikov 
> ---
>   doc/umr.1   | 33 +++-
>   src/app/ring_read.c | 52 -
>   2 files changed, 55 insertions(+), 30 deletions(-)
>
> diff --git a/doc/umr.1 b/doc/umr.1
> index 1e585fa..137ff1e 100644
> --- a/doc/umr.1
> +++ b/doc/umr.1
> @@ -216,17 +216,30 @@ Disassemble 'size' bytes (in hex) from a given address 
> (in hex).  The size can b
>   specified as zero to have umr try and compute the shader size.
>   
>   .SH Ring and PM4 Decoding
> -.IP "--ring, -R (from:to)"
> -Read the contents of a ring named by the string without the
> -.B amdgpu_ring_
> -prefix.  By default it will read and display the entire ring.  A
> -starting and ending address can be specified in decimal or a '.' can
> -be used to indicate relative to the current
> +.IP "--ring, -R [range]"
> +Read the contents of the ring named by the string
> +.B amdgpu_ring_,
> +i.e. without the
> +.B amdgpu_ring
> +prefix. By default it reads and prints the entire ring.  A
> +range is optional and has the format '[start:end]'. The
> +starting and ending address are non-negative integers or
> +the '.' (dot) symbol, which indicates the
> +.B rptr
> +when on the left side and
>   .B wptr
> -pointer.  For example, "-R gfx" would read the entire gfx ring,
> -"-R gfx[0:16]" would display the contents from 0 to 16 inclusively, and
> -"-R gfx[.]" or "-R gfx[.:.]" would display the last 32 words relative
> -to rptr.
> +when on the right side of the range.
> +For instance,
> +"-R gfx" prints the entire gfx ring, "-R gfx[0:16]" prints
> +the contents from 0 to 16 inclusively, and "-R gfx[.]" or
> +"-R gfx[.:.]" prints the range [rptr,wptr]. When one of
> +the range limits is a number while the other is the dot, '.',
> +then the number indicates the relative range before or after the
> +corresponding ring pointer. For instance, "-R sdma0[16:.]"
> +prints [wptr-16, wptr] words of the SDMA0 ring, and
> +"-R sdma1[.:32]" prints [rptr, rptr+32] double-words of the
> +SDMA1 ring. The contents of the ring is always interpreted,
> +if it can be interpreted.
>   .IP "--dump-ib, -di [vmid@]address length [pm]"
>   Dump an IB packet at an address with an optional VMID.  The length is 
> specified
>   in bytes.  The type of decoder  is optional and defaults to PM4 packets.
> diff --git a/src/app/ring_read.c b/src/app/ring_read.c
> index ef0c711..9cbecb0 100644
> --- a/src/app/ring_read.c
> +++ b/src/app/ring_read.c
> @@ -28,7 +28,7 @@
>   void umr_read_ring(struct umr_asic *asic, char *ringpath)
>   {
>   char ringname[32], from[32], to[32];
> - int use_decoder, enable_decoder, gprs;
> + int  enable_decoder, gprs;
>   uint32_t wptr, rptr, drv_wptr, ringsize, start, end, value,
>*ring_data;
>   struct umr_ring_decoder decoder, *pdecoder, *ppdecoder;
> @@ -73,33 +73,46 @@ void umr_read_ring(struct umr_asic *asic, char *ringpath)
>   drv_wptr = ring_data[2]<<2;
>   
>   /* default to reading entire ring */
> - use_decoder = 0;
>   if (!from[0]) {
>   start = 0;
>   end   = ringsize-4;
>   } else {
> - if (from[0] == '.' || !to[0] || to[0] == '.') {
> - /* start from 32 words prior to rptr up to wptr */
> - end = wptr;
> - if (rptr < (31*4)) {
> - start = rptr - 31*4;
> - start += ringsize;
> + if (from[0] == '.') {
> + if (to[0] == 0 || to[0] == '.') {
> + /* Notation: [.] or [.:.], meaning
> +  * [rptr, wptr].
> +  */
> + start = rptr;
> + end = wptr;
>   } else {
> - start = rptr - 31*4;
> +

[PATCH] drm/amd/amdgpu: Disable GFX_PG on laptop raven part

[StDenis, Tom]

GFX_PG causes visual (and likely memory) corruption on laptop
raven parts.  Until it's fully diagnosed let's disable it to ensure
stable operation.

Tested on a Dell Latitude 5495.

Signed-off-by: Tom St Denis 
---
 drivers/gpu/drm/amd/amdgpu/soc15.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/soc15.c 
b/drivers/gpu/drm/amd/amdgpu/soc15.c
index 77e679920c1c..27a500f75f57 100644
--- a/drivers/gpu/drm/amd/amdgpu/soc15.c
+++ b/drivers/gpu/drm/amd/amdgpu/soc15.c
@@ -1138,6 +1138,11 @@ static int soc15_common_early_init(void *handle)
adev->pg_flags |= AMD_PG_SUPPORT_GFX_PG |
AMD_PG_SUPPORT_CP |
AMD_PG_SUPPORT_RLC_SMU_HS;
+
+   // disable GFX_PG until debugged.
+   if (adev->external_rev_id == 0x21)
+   adev->pg_flags &= ~AMD_PG_SUPPORT_GFX_PG;
+
break;
case CHIP_ARCTURUS:
adev->asic_funcs = _asic_funcs;
-- 
2.21.0

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 5/5] drm/amd/powerplay: implment sysfs feature status function in smu

[StDenis, Tom]

No it doesn't.  We get clocks for --top from the sensors interface.


On 2019-07-25 9:01 a.m., Deucher, Alexander wrote:
> Tom, does umr use it?
>
> Alex
> 
> *From:* Huang, Ray 
> *Sent:* Thursday, July 25, 2019 4:49 AM
> *To:* Wang, Kevin(Yang) ; Quan, Evan 
> ; amd-gfx@lists.freedesktop.org 
> ; Zhang, Hawking 
> ; Deucher, Alexander 
> *Cc:* Feng, Kenneth 
> *Subject:* RE: [PATCH 5/5] drm/amd/powerplay: implment sysfs feature 
> status function in smu
>
> Any other user mode tool use the “ppfeature” sysfs interface?
>
> Thanks,
>
> Ray
>
> *From:* Wang, Kevin(Yang) 
> *Sent:* Thursday, July 25, 2019 4:44 PM
> *To:* Quan, Evan ; amd-gfx@lists.freedesktop.org; 
> Zhang, Hawking ; Deucher, Alexander 
> 
> *Cc:* Huang, Ray ; Feng, Kenneth 
> *Subject:* Re: [PATCH 5/5] drm/amd/powerplay: implment sysfs feature 
> status function in smu
>
> in fact, i don't want to change this sysfs name from "ppfeatures" to 
> "pp_features",
>
> but it seems that don't have same name format with other pp sysfs node.
>
> the other powerplay sysfs name have "pp_" prefix, i think we'd better 
> to change it name to "pp_features"
>
> eg:
>
> pp_cur_state    pp_dpm_fclk  pp_dpm_pcie  pp_dpm_socclk 
>  pp_force_state  pp_num_states  pp_sclk_od
> pp_dpm_dcefclk  pp_dpm_mclk  pp_dpm_sclk  pp_features    pp_mclk_od   
>    pp_power_profile_mode  pp_table
>
> @Deucher, Alexander  @Zhang, Hawking 
> 
>
> Could you give us some idea about it,
>
> Thanks.
>
> Best Regards,
> Kevin
>
> 
>
> *From:*Quan, Evan mailto:evan.q...@amd.com>>
> *Sent:* Thursday, July 25, 2019 4:30 PM
> *To:* Wang, Kevin(Yang)  >; amd-gfx@lists.freedesktop.org 
>   >
> *Cc:* Deucher, Alexander  >; Huang, Ray  >; Feng, Kenneth  >
> *Subject:* RE: [PATCH 5/5] drm/amd/powerplay: implment sysfs feature 
> status function in smu
>
> To keep backward compatibility, we cannot change the sysfs file naming.
>
> But it’s a good idea to summarize these as common APIs.
>
> Regards,
>
> Evan
>
> *From:* amd-gfx  > *On Behalf Of *Wang, 
> Kevin(Yang)
> *Sent:* Thursday, July 25, 2019 4:10 PM
> *To:* amd-gfx@lists.freedesktop.org 
> *Cc:* Deucher, Alexander  >; Huang, Ray  >; Feng, Kenneth  >
> *Subject:* Re: [PATCH 5/5] drm/amd/powerplay: implment sysfs feature 
> status function in smu
>
> add sample data from sysfs pp_features with this patch.
>
> print format:
>
> index. feature name (Hardware Message ID): state
>
> /sudo find /sys -name "pp_features" -exec cat {} \;/
>
> features high: 0x0623 low: 0xb3cdaffb
>
> 00. DPM_PREFETCHER       ( 0) : enabeld
>
> 01. DPM_GFXCLK           ( 1) : enabeld
>
> 02. DPM_UCLK             ( 3) : enabeld
>
> 03. DPM_SOCCLK           ( 4) : enabeld
>
> 04. DPM_MP0CLK           ( 5) : enabeld
>
> 05. DPM_LINK             ( 6) : enabeld
>
> 06. DPM_DCEFCLK          ( 7) : enabeld
>
> 07. DS_GFXCLK            (10) : enabeld
>
> 08. DS_SOCCLK            (11) : enabeld
>
> 09. DS_LCLK              (12) : disabled
>
> 10. PPT                (23) : enabeld
>
> 11. TDC                (24) : enabeld
>
> 12. THERMAL              (33) : enabeld
>
> 13. RM                 (35) : disabled
>
> 14. DS_DCEFCLK           (13) : enabeld
>
> 15. ACDC                 (28) : enabeld
>
> 16. VR0HOT               (29) : enabeld
>
> 17. VR1HOT               (30) : disabled
>
> 18. FW_CTF               (31) : enabeld
>
> 19. LED_DISPLAY          (36) : disabled
>
> 20. FAN_CONTROL          (32) : enabeld
>
> 21. GFX_EDC              (25) : enabeld
>
> 22. GFXOFF               (17) : disabled
>
> 23. DPM_GFX_PACE         ( 2) : disabled
>
> 24. MEM_VDDCI_SCALING    ( 8) : enabeld
>
> 25. MEM_MVDD_SCALING     ( 9) : enabeld
>
> 26. DS_UCLK              (14) : disabled
>
> 27. GFX_ULV              (15) : enabeld
>
> 28. FW_DSTATE            (16) : enabeld
>
> 29. BACO                 (18) : enabeld
>
> 30. VCN_PG               (19) : enabeld
>
> 31. JPEG_PG              (20) : disabled
>
> 32. USB_PG               (21) : disabled
>
> 33. RSMU_SMN_CG          (22) : enabeld
>
> 34. APCC_PLUS            (26) : disabled
>
> 35. GTHR                 (27) : disabled
>
> 36. GFX_DCS              (34) : disabled
>
> 37. GFX_SS               (37) : enabeld
>
> 38. OUT_OF_BAND_MONITOR  (38) : disabled
>
> 39. TEMP_DEPENDENT_VMIN  (39) : disabled
>
> 40. MMHUB_PG             (40) : disabled
>
> 41. ATHUB_PG             (41) : enabeld
>
> 

[PATCH] Collect all page_base_address bits for pte-further addresses (v2)

[StDenis, Tom]

The specification says to treat a PTE with the F bit set "like a PDE"
which means that all but the lower 6 bits are part of the page base
address.  Indeed, in the wild a comment came back indicating that
we were stripping off bits needed to properly fetch the next
PTE.

(v2): Only capture excess bits if it is a PTE-FURTHER entry

Signed-off-by: Tom St Denis 
---
 src/lib/read_vram.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/lib/read_vram.c b/src/lib/read_vram.c
index cba8f6b..e83a85c 100644
--- a/src/lib/read_vram.c
+++ b/src/lib/read_vram.c
@@ -676,7 +676,7 @@ pde_is_pte:
pte_idx = (address >> 12) & ((1ULL << 
pde_fields.frag_size) - 1);
 
// grab PTE base address from the PTE that has 
the F bit set.
-   pde_fields.pte_base_addr = 
pte_fields.page_base_addr;
+   pde_fields.pte_base_addr = pte_entry & 
0xFFC0ULL;
goto pte_further;
}
 
-- 
2.21.0

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH] Collect all page_base_address bits for pte-further addresses

[StDenis, Tom]

The specification says to treat a PTE with the F bit set "like a PDE"
which means that all but the lower 6 bits are part of the page base
address.  Indeed, in the wild a comment came back indicating that
we were stripping off bits needed to properly fetch the next
PTE.

Signed-off-by: Tom St Denis 
---
 src/lib/read_vram.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/lib/read_vram.c b/src/lib/read_vram.c
index cba8f6b..209ca84 100644
--- a/src/lib/read_vram.c
+++ b/src/lib/read_vram.c
@@ -654,7 +654,7 @@ pte_further:
 
// decode PTE values
 pde_is_pte:
-   pte_fields.page_base_addr = pte_entry & 
0xF000ULL;
+   pte_fields.page_base_addr = pte_entry & 
0xFFC0ULL; // all but bottom 6 bits are PBA
pte_fields.fragment   = (pte_entry >> 7)  & 0x1F;
pte_fields.system = (pte_entry >> 1) & 1;
pte_fields.valid  = pte_entry & 1;
-- 
2.21.0

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] drm/amd/amdgpu: Fix offset for vmid selection in debugfs interface

[StDenis, Tom]

Thanks.


Alex can I grab an R-b please?


Cheers,

Tom

On 2019-07-16 7:30 a.m., Christian König wrote:
> Am 16.07.19 um 13:24 schrieb StDenis, Tom:
>> The register debugfs interface was using the wrong bitmask for vmid
>> selection for GFX_CNTL.
>>
>> Signed-off-by: Tom St Denis 
>
> Acked-by: Christian König 
>
>> ---
>>   drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c 
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
>> index 87b32873046f..59849ed9797d 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
>> @@ -132,7 +132,7 @@ static int amdgpu_debugfs_process_reg_op(bool 
>> read, struct file *f,
>>   me = (*pos & GENMASK_ULL(33, 24)) >> 24;
>>   pipe = (*pos & GENMASK_ULL(43, 34)) >> 34;
>>   queue = (*pos & GENMASK_ULL(53, 44)) >> 44;
>> -    vmid = (*pos & GENMASK_ULL(48, 45)) >> 54;
>> +    vmid = (*pos & GENMASK_ULL(58, 54)) >> 54;
>>     use_ring = 1;
>>   } else {
>
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH] drm/amd/amdgpu: Fix offset for vmid selection in debugfs interface

[StDenis, Tom]

The register debugfs interface was using the wrong bitmask for vmid
selection for GFX_CNTL.

Signed-off-by: Tom St Denis 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
index 87b32873046f..59849ed9797d 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
@@ -132,7 +132,7 @@ static int  amdgpu_debugfs_process_reg_op(bool read, struct 
file *f,
me = (*pos & GENMASK_ULL(33, 24)) >> 24;
pipe = (*pos & GENMASK_ULL(43, 34)) >> 34;
queue = (*pos & GENMASK_ULL(53, 44)) >> 44;
-   vmid = (*pos & GENMASK_ULL(48, 45)) >> 54;
+   vmid = (*pos & GENMASK_ULL(58, 54)) >> 54;
 
use_ring = 1;
} else {
-- 
2.21.0

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH 2/2] drm/amd/amdgpu: Add missing select_me_pipe_q() for gfx10

[StDenis, Tom]

Signed-off-by: Tom St Denis 
---
 drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c 
b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
index 0d94c812df1b..7d5207bbe382 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
@@ -1061,6 +1061,12 @@ static void gfx_v10_0_read_wave_vgprs(struct 
amdgpu_device *adev, uint32_t simd,
start + SQIND_WAVE_VGPRS_OFFSET, size, dst);
 }
 
+static void gfx_v10_0_select_me_pipe_q(struct amdgpu_device *adev,
+ u32 
me, u32 pipe, u32 q, u32 vm)
+ {
+   nv_grbm_select(adev, me, pipe, q, vm);
+ }
+
 
 static const struct amdgpu_gfx_funcs gfx_v10_0_gfx_funcs = {
.get_gpu_clock_counter = _v10_0_get_gpu_clock_counter,
@@ -1068,6 +1074,7 @@ static const struct amdgpu_gfx_funcs gfx_v10_0_gfx_funcs 
= {
.read_wave_data = _v10_0_read_wave_data,
.read_wave_sgprs = _v10_0_read_wave_sgprs,
.read_wave_vgprs = _v10_0_read_wave_vgprs,
+   .select_me_pipe_q = _v10_0_select_me_pipe_q,
 };
 
 static void gfx_v10_0_gpu_early_init(struct amdgpu_device *adev)
-- 
2.21.0

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH 1/2] drm/amd/amdgpu: Add VMID to SRBM debugfs bank selection

[StDenis, Tom]

Add 5 bits to the offset for SRBM selection to handle VMIDs.  Also
update the select_me_pipe_q() callback to also select VMID.

Signed-off-by: Tom St Denis 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 9 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h | 4 ++--
 drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c   | 2 +-
 drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c   | 4 ++--
 drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c   | 4 ++--
 drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c   | 4 ++--
 6 files changed, 14 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
index 4997efa09ce7..87b32873046f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
@@ -103,10 +103,10 @@ static int  amdgpu_debugfs_process_reg_op(bool read, 
struct file *f,
ssize_t result = 0;
int r;
bool pm_pg_lock, use_bank, use_ring;
-   unsigned instance_bank, sh_bank, se_bank, me, pipe, queue;
+   unsigned instance_bank, sh_bank, se_bank, me, pipe, queue, vmid;
 
pm_pg_lock = use_bank = use_ring = false;
-   instance_bank = sh_bank = se_bank = me = pipe = queue = 0;
+   instance_bank = sh_bank = se_bank = me = pipe = queue = vmid = 0;
 
if (size & 0x3 || *pos & 0x3 ||
((*pos & (1ULL << 62)) && (*pos & (1ULL << 61
@@ -132,6 +132,7 @@ static int  amdgpu_debugfs_process_reg_op(bool read, struct 
file *f,
me = (*pos & GENMASK_ULL(33, 24)) >> 24;
pipe = (*pos & GENMASK_ULL(43, 34)) >> 34;
queue = (*pos & GENMASK_ULL(53, 44)) >> 44;
+   vmid = (*pos & GENMASK_ULL(48, 45)) >> 54;
 
use_ring = 1;
} else {
@@ -149,7 +150,7 @@ static int  amdgpu_debugfs_process_reg_op(bool read, struct 
file *f,
sh_bank, instance_bank);
} else if (use_ring) {
mutex_lock(>srbm_mutex);
-   amdgpu_gfx_select_me_pipe_q(adev, me, pipe, queue);
+   amdgpu_gfx_select_me_pipe_q(adev, me, pipe, queue, vmid);
}
 
if (pm_pg_lock)
@@ -182,7 +183,7 @@ static int  amdgpu_debugfs_process_reg_op(bool read, struct 
file *f,
amdgpu_gfx_select_se_sh(adev, 0x, 0x, 
0x);
mutex_unlock(>grbm_idx_mutex);
} else if (use_ring) {
-   amdgpu_gfx_select_me_pipe_q(adev, 0, 0, 0);
+   amdgpu_gfx_select_me_pipe_q(adev, 0, 0, 0, 0);
mutex_unlock(>srbm_mutex);
}
 
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h
index f96407ba9770..1199b5828b90 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h
@@ -195,7 +195,7 @@ struct amdgpu_gfx_funcs {
uint32_t wave, uint32_t start, uint32_t size,
uint32_t *dst);
void (*select_me_pipe_q)(struct amdgpu_device *adev, u32 me, u32 pipe,
-u32 queue);
+u32 queue, u32 vmid);
 };
 
 struct amdgpu_ngg_buf {
@@ -327,7 +327,7 @@ struct amdgpu_gfx {
 
 #define amdgpu_gfx_get_gpu_clock_counter(adev) 
(adev)->gfx.funcs->get_gpu_clock_counter((adev))
 #define amdgpu_gfx_select_se_sh(adev, se, sh, instance) 
(adev)->gfx.funcs->select_se_sh((adev), (se), (sh), (instance))
-#define amdgpu_gfx_select_me_pipe_q(adev, me, pipe, q) 
(adev)->gfx.funcs->select_me_pipe_q((adev), (me), (pipe), (q))
+#define amdgpu_gfx_select_me_pipe_q(adev, me, pipe, q, vmid) 
(adev)->gfx.funcs->select_me_pipe_q((adev), (me), (pipe), (q), (vmid))
 
 /**
  * amdgpu_gfx_create_bitmask - create a bitmask
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c 
b/drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c
index 0745370493f3..8c27c305e692 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c
@@ -3041,7 +3041,7 @@ static void gfx_v6_0_read_wave_sgprs(struct amdgpu_device 
*adev, uint32_t simd,
 }
 
 static void gfx_v6_0_select_me_pipe_q(struct amdgpu_device *adev,
- u32 me, u32 pipe, u32 q)
+ u32 me, u32 pipe, u32 q, u32 vm)
 {
DRM_INFO("Not implemented\n");
 }
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c 
b/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c
index bc5ff82565d2..e1e2a44ee13c 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c
@@ -4167,9 +4167,9 @@ static void gfx_v7_0_read_wave_sgprs(struct amdgpu_device 
*adev, uint32_t simd,
 }
 
 static void gfx_v7_0_select_me_pipe_q(struct amdgpu_device *adev,
- u32 me, u32 pipe, u32 q)
+ u32 me, u32 pipe, u32 q, u32 vm)
 {
-   cik_srbm_select(adev, me, pipe, q, 0);
+   cik_srbm_select(adev, me, pipe, q, vm);
 }
 
 

[PATCH] Fix VM handling for VMID 0 w.r.t. SYSTEM_APERTURE

[StDenis, Tom]

Signed-off-by: Tom St Denis 
---
 src/lib/read_vram.c | 47 +
 1 file changed, 43 insertions(+), 4 deletions(-)

diff --git a/src/lib/read_vram.c b/src/lib/read_vram.c
index 131cec3..812de96 100644
--- a/src/lib/read_vram.c
+++ b/src/lib/read_vram.c
@@ -300,7 +300,7 @@ static int umr_access_vram_ai(struct umr_asic *asic, 
uint32_t vmid,
uint64_t start_addr, page_table_start_addr, page_table_base_addr,
 page_table_size, pte_idx, pde_idx, pte_entry, pde_entry,
 pde_address, vga_base_address, vm_fb_offset, vm_fb_base,
-va_mask, offset_mask;
+va_mask, offset_mask, system_aperture_low, 
system_aperture_high;
uint32_t chunk_size, tmp;
int pde_cnt, current_depth, page_table_depth, first;
struct {
@@ -312,7 +312,10 @@ static int umr_access_vram_ai(struct umr_asic *asic, 
uint32_t vmid,
mmVM_CONTEXTx_PAGE_TABLE_BASE_ADDR_HI32,
mmVGA_MEMORY_BASE_ADDRESS,
mmVGA_MEMORY_BASE_ADDRESS_HIGH,
-   mmMC_VM_FB_OFFSET;
+   mmMC_VM_FB_OFFSET,
+   mmMC_VM_MX_L1_TLB_CNTL,
+   mmMC_VM_SYSTEM_APERTURE_LOW_ADDR,
+   mmMC_VM_SYSTEM_APERTURE_HIGH_ADDR;
} registers;
struct {
uint64_t
@@ -381,6 +384,11 @@ static int umr_access_vram_ai(struct umr_asic *asic, 
uint32_t vmid,
}
 
// read vm registers
+   registers.mmMC_VM_SYSTEM_APERTURE_HIGH_ADDR = 
umr_read_reg_by_name_by_ip(asic, hub, "mmMC_VM_SYSTEM_APERTURE_HIGH_ADDR");
+   registers.mmMC_VM_SYSTEM_APERTURE_LOW_ADDR = 
umr_read_reg_by_name_by_ip(asic, hub, "mmMC_VM_SYSTEM_APERTURE_LOW_ADDR");
+   system_aperture_low = 
((uint64_t)registers.mmMC_VM_SYSTEM_APERTURE_LOW_ADDR) << 18;
+   system_aperture_high = 
((uint64_t)registers.mmMC_VM_SYSTEM_APERTURE_HIGH_ADDR) << 18;
+   registers.mmMC_VM_MX_L1_TLB_CNTL = umr_read_reg_by_name_by_ip(asic, 
hub, "mmMC_VM_MX_L1_TLB_CNTL");
sprintf(buf, "mmVM_CONTEXT%" PRIu32 "_PAGE_TABLE_START_ADDR_LO32", 
vmid);
registers.mmVM_CONTEXTx_PAGE_TABLE_START_ADDR_LO32 = 
umr_read_reg_by_name_by_ip(asic, hub, buf);
page_table_start_addr = 
(uint64_t)registers.mmVM_CONTEXTx_PAGE_TABLE_START_ADDR_LO32 << 12;
@@ -425,7 +433,10 @@ static int umr_access_vram_ai(struct umr_asic *asic, 
uint32_t vmid,
"mmVGA_MEMORY_BASE_ADDRESS=0x%" PRIx32 "\n"
"mmVGA_MEMORY_BASE_ADDRESS_HIGH=0x%" PRIx32 "\n"
"mmMC_VM_FB_OFFSET=0x%" PRIx32 "\n"
-   "mmMC_VM_FB_LOCATION_BASE=0x%" PRIx64 "\n",
+   "mmMC_VM_FB_LOCATION_BASE=0x%" PRIx64 "\n"
+   "mmMC_VM_MX_L1_TLB_CNTL=0x%" PRIx32 "\n"
+   "mmMC_VM_SYSTEM_APERTURE_LOW_ADDR=0x%" PRIx32 
"\n"
+   "mmMC_VM_SYSTEM_APERTURE_HIGH_ADDR=0x%" PRIx32 
"\n",
vmid, 
registers.mmVM_CONTEXTx_PAGE_TABLE_START_ADDR_LO32,
vmid, 
registers.mmVM_CONTEXTx_PAGE_TABLE_START_ADDR_HI32,
vmid, registers.mmVM_CONTEXTx_PAGE_TABLE_BASE_ADDR_LO32,
@@ -434,10 +445,38 @@ static int umr_access_vram_ai(struct umr_asic *asic, 
uint32_t vmid,
registers.mmVGA_MEMORY_BASE_ADDRESS,
registers.mmVGA_MEMORY_BASE_ADDRESS_HIGH,
registers.mmMC_VM_FB_OFFSET,
-   vm_fb_base);
+   vm_fb_base,
+   registers.mmMC_VM_MX_L1_TLB_CNTL,
+   registers.mmMC_VM_SYSTEM_APERTURE_LOW_ADDR,
+   registers.mmMC_VM_SYSTEM_APERTURE_HIGH_ADDR
+   );
 
// transform page_table_base
page_table_base_addr -= vm_fb_offset;
+
+   if (vmid == 0) {
+   uint32_t sam = umr_bitslice_reg_by_name_by_ip(asic, hub, 
"mmMC_VM_MX_L1_TLB_CNTL", "SYSTEM_ACCESS_MODE", 
registers.mmMC_VM_MX_L1_TLB_CNTL);
+   // addresses in VMID0 need special handling w.r.t. 
PAGE_TABLE_START_ADDR
+   switch (sam) {
+   case 0: // physical access
+   return umr_access_vram(asic, UMR_LINEAR_HUB, 
address, size, dst, write_en);
+   case 1: // always VM access
+   break;
+   case 2: // inside system aperture is mapped, otherwise 
unmapped
+   if (!(address >= system_aperture_low && address 
< system_aperture_high))
+   return umr_access_vram(asic, 
UMR_LINEAR_HUB, address, size, dst, write_en);
+   break;
+   case 3: // inside system aperture is unmapped, 

[PATCH] drm/amd/amdgpu: Indentation and simplification fixes for DF driver

[StDenis, Tom]

Minor indentation and simplifications for the DF 3.6 driver.  No
functional changes.

Signed-off-by: Tom St Denis 
---
 drivers/gpu/drm/amd/amdgpu/df_v3_6.c | 50 ++--
 1 file changed, 18 insertions(+), 32 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/df_v3_6.c 
b/drivers/gpu/drm/amd/amdgpu/df_v3_6.c
index e079ee066d87..21b214b2d652 100644
--- a/drivers/gpu/drm/amd/amdgpu/df_v3_6.c
+++ b/drivers/gpu/drm/amd/amdgpu/df_v3_6.c
@@ -27,8 +27,8 @@
 #include "df/df_3_6_offset.h"
 #include "df/df_3_6_sh_mask.h"
 
-static u32 df_v3_6_channel_number[] = {1, 2, 0, 4, 0, 8, 0,
-  16, 32, 0, 0, 0, 2, 4, 8};
+static u32 df_v3_6_channel_number[] = { 1, 2, 0, 4, 0, 8, 0,
+   
16, 32, 0, 0, 0, 2, 4, 8};
 
 static void df_v3_6_init(struct amdgpu_device *adev)
 {
@@ -43,9 +43,10 @@ static void df_v3_6_enable_broadcast_mode(struct 
amdgpu_device *adev,
tmp = RREG32_SOC15(DF, 0, mmFabricConfigAccessControl);
tmp &= ~FabricConfigAccessControl__CfgRegInstAccEn_MASK;
WREG32_SOC15(DF, 0, mmFabricConfigAccessControl, tmp);
-   } else
+   } else {
WREG32_SOC15(DF, 0, mmFabricConfigAccessControl,
-mmFabricConfigAccessControl_DEFAULT);
+mmFabricConfigAccessControl_DEFAULT);
+   }
 }
 
 static u32 df_v3_6_get_fb_channel_number(struct amdgpu_device *adev)
@@ -78,17 +79,13 @@ static void df_v3_6_update_medium_grain_clock_gating(struct 
amdgpu_device *adev,
/* Put DF on broadcast mode */
adev->df_funcs->enable_broadcast_mode(adev, true);
 
-   if (enable && (adev->cg_flags & AMD_CG_SUPPORT_DF_MGCG)) {
-   tmp = RREG32_SOC15(DF, 0, mmDF_PIE_AON0_DfGlobalClkGater);
-   tmp &= ~DF_PIE_AON0_DfGlobalClkGater__MGCGMode_MASK;
+   tmp = RREG32_SOC15(DF, 0, mmDF_PIE_AON0_DfGlobalClkGater);
+   tmp &= ~DF_PIE_AON0_DfGlobalClkGater__MGCGMode_MASK;
+   if (enable && (adev->cg_flags & AMD_CG_SUPPORT_DF_MGCG))
tmp |= DF_V3_6_MGCG_ENABLE_15_CYCLE_DELAY;
-   WREG32_SOC15(DF, 0, mmDF_PIE_AON0_DfGlobalClkGater, tmp);
-   } else {
-   tmp = RREG32_SOC15(DF, 0, mmDF_PIE_AON0_DfGlobalClkGater);
-   tmp &= ~DF_PIE_AON0_DfGlobalClkGater__MGCGMode_MASK;
+   else
tmp |= DF_V3_6_MGCG_DISABLE;
-   WREG32_SOC15(DF, 0, mmDF_PIE_AON0_DfGlobalClkGater, tmp);
-   }
+   WREG32_SOC15(DF, 0, mmDF_PIE_AON0_DfGlobalClkGater, tmp);
 
/* Exit broadcast mode */
adev->df_funcs->enable_broadcast_mode(adev, false);
@@ -113,8 +110,8 @@ struct df_v3_6_event_mask {
 
 /* get assigned df perfmon ctr as int */
 static void df_v3_6_pmc_config_2_cntr(struct amdgpu_device *adev,
- uint64_t config,
- int *counter)
+ 
uint64_t config,
+ int 
*counter)
 {
struct df_v3_6_event_mask *mask;
int i;
@@ -225,7 +222,6 @@ static int df_v3_6_pmc_assign_cntr(struct amdgpu_device 
*adev,
int i, target_cntr;
 
target_cntr = -1;
-
*is_assigned = 0;
 
df_v3_6_pmc_config_2_cntr(adev, config, _cntr);
@@ -348,11 +344,11 @@ static int df_v3_6_add_xgmi_link_cntr(struct 
amdgpu_device *adev,
return ret;
 
ret = df_v3_6_pmc_get_ctrl_settings(adev,
-   config,
-   _base_addr,
-   _base_addr,
-   _val,
-   _val);
+   
config,
+   
_base_addr,
+   
_base_addr,
+   
_val,
+   
_val);
 
if (ret)
return ret;
@@ -379,20 +375,14 @@ static int df_v3_6_start_xgmi_link_cntr(struct 
amdgpu_device *adev,
 {
uint32_t lo_base_addr, hi_base_addr, lo_val;
uint64_t config;
-   int ret;
+   int ret = 0;
 
if (instance < 0 || instance > 1)
return -EINVAL;
 
if (is_enable) {
-
ret = df_v3_6_add_xgmi_link_cntr(adev, instance);
-
-   if (ret)
-   return ret;
-
} else {
-
config = GET_INSTANCE_CONFIG(instance);
 
df_v3_6_pmc_get_ctrl_settings(adev,
@@ -408,8 +398,6 @@ static int df_v3_6_start_xgmi_link_cntr(struct 
amdgpu_device *adev,
lo_val = 

Re: [PATCH] drm/amd/amdgpu: cast mem->num_pages to 64-bits when shifting

[StDenis, Tom]

Ok no worries I'll fix it up and push it later today.

Btw I didn't use an inline cast because the macro kept breaking. I tried 
variants of parentheses and nothing worked Odd...


Thanks,
Tom

On June 17, 2019 3:32:03 PM EDT, "Kuehling, Felix"  
wrote:

On 2019-06-17 3:28 p.m., Christian König wrote:
Am 17.06.19 um 21:15 schrieb Kuehling, Felix:
 Looks good to me. One cosmetic comment inline. With that fixed this
 patch is Reviewed-by:  Felix Kuehling 

 On 2019-06-14 12:51 p.m., StDenis, Tom wrote:
 On 32-bit hosts mem->num_pages is 32-bits and can overflow
 when shifted.  Add a cast to avoid this.

 Signed-off-by: Tom St Denis 

drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)

 diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
 b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
 index c963ad86072e..31895d3c33de 100644
 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
 +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
 @@ -279,14 +279,16 @@ static int amdgpu_vram_mgr_new(struct
 ttm_mem_type_manager *man,
uint64_t vis_usage = 0;
unsigned i;
int r;
 +uint64_t mem_bytes;
Christian likes the "upside-down christmas tree" to help readability of
local variable declarations.

 Ah, yeah. Thanks for the note.

 I actually don't care about that much, but I always get rejects from
 upstream subsystem maintainers if I don't do this.

 It's most likely not even documented somewhere,

Right. The fact that I even noticed it probably means that I have a mild
case of OCD myself. If it was a strict requirement, it should be caught
by checkpatch.pl.

Cheers,
   Felix


 Christian.



  lpfn = place->lpfn;
   if (!lpfn)
   lpfn = man->size;
  /* bail out quickly if there's likely not enough VRAM for
this BO */
-if (atomic64_add_return(mem->num_pages << PAGE_SHIFT,
>usage) > adev->gmc.mc_vram_size) {
-atomic64_sub(mem->num_pages << PAGE_SHIFT, >usage);
+mem_bytes = (u64)mem->num_pages << PAGE_SHIFT;
+if (atomic64_add_return(mem_bytes, >usage) >
adev->gmc.mc_vram_size) {
+atomic64_sub(mem_bytes, >usage);
   mem->mm_node = NULL;
   return 0;
   }
@@ -308,7 +310,7 @@ static int amdgpu_vram_mgr_new(struct
ttm_mem_type_manager *man,
   nodes = kvmalloc_array((uint32_t)num_nodes, sizeof(*nodes),
  GFP_KERNEL | __GFP_ZERO);
   if (!nodes) {
-atomic64_sub(mem->num_pages << PAGE_SHIFT, >usage);
+atomic64_sub(mem_bytes, >usage);
   return -ENOMEM;
   }

amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH] drm/amd/amdgpu: cast mem->num_pages to 64-bits when shifting

[StDenis, Tom]

On 32-bit hosts mem->num_pages is 32-bits and can overflow
when shifted.  Add a cast to avoid this.

Signed-off-by: Tom St Denis 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
index c963ad86072e..31895d3c33de 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
@@ -279,14 +279,16 @@ static int amdgpu_vram_mgr_new(struct 
ttm_mem_type_manager *man,
uint64_t vis_usage = 0;
unsigned i;
int r;
+   uint64_t mem_bytes;
 
lpfn = place->lpfn;
if (!lpfn)
lpfn = man->size;
 
/* bail out quickly if there's likely not enough VRAM for this BO */
-   if (atomic64_add_return(mem->num_pages << PAGE_SHIFT, >usage) > 
adev->gmc.mc_vram_size) {
-   atomic64_sub(mem->num_pages << PAGE_SHIFT, >usage);
+   mem_bytes = (u64)mem->num_pages << PAGE_SHIFT;
+   if (atomic64_add_return(mem_bytes, >usage) > 
adev->gmc.mc_vram_size) {
+   atomic64_sub(mem_bytes, >usage);
mem->mm_node = NULL;
return 0;
}
@@ -308,7 +310,7 @@ static int amdgpu_vram_mgr_new(struct ttm_mem_type_manager 
*man,
nodes = kvmalloc_array((uint32_t)num_nodes, sizeof(*nodes),
   GFP_KERNEL | __GFP_ZERO);
if (!nodes) {
-   atomic64_sub(mem->num_pages << PAGE_SHIFT, >usage);
+   atomic64_sub(mem_bytes, >usage);
return -ENOMEM;
}
 
-- 
2.21.0

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH] drm/amd/amdgpu: Bail out of BO node creation if not enough VRAM (v3)

[StDenis, Tom]

(v2): Return 0 and set mem->mm_node to NULL.
(v3): Use atomic64_add_return instead.

Signed-off-by: Tom St Denis 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 17 -
 1 file changed, 12 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
index 8aea2f21b202..c963ad86072e 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
@@ -276,7 +276,7 @@ static int amdgpu_vram_mgr_new(struct ttm_mem_type_manager 
*man,
struct drm_mm_node *nodes;
enum drm_mm_insert_mode mode;
unsigned long lpfn, num_nodes, pages_per_node, pages_left;
-   uint64_t usage = 0, vis_usage = 0;
+   uint64_t vis_usage = 0;
unsigned i;
int r;
 
@@ -284,6 +284,13 @@ static int amdgpu_vram_mgr_new(struct ttm_mem_type_manager 
*man,
if (!lpfn)
lpfn = man->size;
 
+   /* bail out quickly if there's likely not enough VRAM for this BO */
+   if (atomic64_add_return(mem->num_pages << PAGE_SHIFT, >usage) > 
adev->gmc.mc_vram_size) {
+   atomic64_sub(mem->num_pages << PAGE_SHIFT, >usage);
+   mem->mm_node = NULL;
+   return 0;
+   }
+
if (place->flags & TTM_PL_FLAG_CONTIGUOUS) {
pages_per_node = ~0ul;
num_nodes = 1;
@@ -300,8 +307,10 @@ static int amdgpu_vram_mgr_new(struct ttm_mem_type_manager 
*man,
 
nodes = kvmalloc_array((uint32_t)num_nodes, sizeof(*nodes),
   GFP_KERNEL | __GFP_ZERO);
-   if (!nodes)
+   if (!nodes) {
+   atomic64_sub(mem->num_pages << PAGE_SHIFT, >usage);
return -ENOMEM;
+   }
 
mode = DRM_MM_INSERT_BEST;
if (place->flags & TTM_PL_FLAG_TOPDOWN)
@@ -321,7 +330,6 @@ static int amdgpu_vram_mgr_new(struct ttm_mem_type_manager 
*man,
if (unlikely(r))
break;
 
-   usage += nodes[i].size << PAGE_SHIFT;
vis_usage += amdgpu_vram_mgr_vis_size(adev, [i]);
amdgpu_vram_mgr_virt_start(mem, [i]);
pages_left -= pages;
@@ -341,14 +349,12 @@ static int amdgpu_vram_mgr_new(struct 
ttm_mem_type_manager *man,
if (unlikely(r))
goto error;
 
-   usage += nodes[i].size << PAGE_SHIFT;
vis_usage += amdgpu_vram_mgr_vis_size(adev, [i]);
amdgpu_vram_mgr_virt_start(mem, [i]);
pages_left -= pages;
}
spin_unlock(>lock);
 
-   atomic64_add(usage, >usage);
atomic64_add(vis_usage, >vis_usage);
 
mem->mm_node = nodes;
@@ -359,6 +365,7 @@ static int amdgpu_vram_mgr_new(struct ttm_mem_type_manager 
*man,
while (i--)
drm_mm_remove_node([i]);
spin_unlock(>lock);
+   atomic64_sub(mem->num_pages << PAGE_SHIFT, >usage);
 
kvfree(nodes);
return r == -ENOSPC ? 0 : r;
-- 
2.21.0

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH] drm/amd/amdgpu: Bail out of BO node creation if not enough VRAM (v2)

[StDenis, Tom]

(v2): Return 0 and set mem->mm_node to NULL.

Signed-off-by: Tom St Denis 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 18 +-
 1 file changed, 13 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
index 8aea2f21b202..c2730e5c1081 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
@@ -276,7 +276,7 @@ static int amdgpu_vram_mgr_new(struct ttm_mem_type_manager 
*man,
struct drm_mm_node *nodes;
enum drm_mm_insert_mode mode;
unsigned long lpfn, num_nodes, pages_per_node, pages_left;
-   uint64_t usage = 0, vis_usage = 0;
+   uint64_t vis_usage = 0;
unsigned i;
int r;
 
@@ -284,6 +284,14 @@ static int amdgpu_vram_mgr_new(struct ttm_mem_type_manager 
*man,
if (!lpfn)
lpfn = man->size;
 
+   /* bail out quickly if there's likely not enough VRAM for this BO */
+   atomic64_add(mem->num_pages << PAGE_SHIFT, >usage);
+   if (atomic64_read(>usage) > adev->gmc.mc_vram_size) {
+   atomic64_sub(mem->num_pages << PAGE_SHIFT, >usage);
+   mem->mm_node = NULL;
+   return 0;
+   }
+
if (place->flags & TTM_PL_FLAG_CONTIGUOUS) {
pages_per_node = ~0ul;
num_nodes = 1;
@@ -300,8 +308,10 @@ static int amdgpu_vram_mgr_new(struct ttm_mem_type_manager 
*man,
 
nodes = kvmalloc_array((uint32_t)num_nodes, sizeof(*nodes),
   GFP_KERNEL | __GFP_ZERO);
-   if (!nodes)
+   if (!nodes) {
+   atomic64_sub(mem->num_pages << PAGE_SHIFT, >usage);
return -ENOMEM;
+   }
 
mode = DRM_MM_INSERT_BEST;
if (place->flags & TTM_PL_FLAG_TOPDOWN)
@@ -321,7 +331,6 @@ static int amdgpu_vram_mgr_new(struct ttm_mem_type_manager 
*man,
if (unlikely(r))
break;
 
-   usage += nodes[i].size << PAGE_SHIFT;
vis_usage += amdgpu_vram_mgr_vis_size(adev, [i]);
amdgpu_vram_mgr_virt_start(mem, [i]);
pages_left -= pages;
@@ -341,14 +350,12 @@ static int amdgpu_vram_mgr_new(struct 
ttm_mem_type_manager *man,
if (unlikely(r))
goto error;
 
-   usage += nodes[i].size << PAGE_SHIFT;
vis_usage += amdgpu_vram_mgr_vis_size(adev, [i]);
amdgpu_vram_mgr_virt_start(mem, [i]);
pages_left -= pages;
}
spin_unlock(>lock);
 
-   atomic64_add(usage, >usage);
atomic64_add(vis_usage, >vis_usage);
 
mem->mm_node = nodes;
@@ -359,6 +366,7 @@ static int amdgpu_vram_mgr_new(struct ttm_mem_type_manager 
*man,
while (i--)
drm_mm_remove_node([i]);
spin_unlock(>lock);
+   atomic64_sub(mem->num_pages << PAGE_SHIFT, >usage);
 
kvfree(nodes);
return r == -ENOSPC ? 0 : r;
-- 
2.21.0

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] drm/amd/amdgpu: Bail out of BO node creation if not enough VRAM

[StDenis, Tom]

On 2019-06-11 9:34 a.m., Christian König wrote:
> Am 10.06.19 um 16:32 schrieb StDenis, Tom:
>> Signed-off-by: Tom St Denis 
>> ---
>>   drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 17 -
>>   1 file changed, 12 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c 
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
>> index 8aea2f21b202..70b4a5a97ed2 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
>> @@ -276,7 +276,7 @@ static int amdgpu_vram_mgr_new(struct 
>> ttm_mem_type_manager *man,
>>   struct drm_mm_node *nodes;
>>   enum drm_mm_insert_mode mode;
>>   unsigned long lpfn, num_nodes, pages_per_node, pages_left;
>> -    uint64_t usage = 0, vis_usage = 0;
>> +    uint64_t vis_usage = 0;
>>   unsigned i;
>>   int r;
>>   @@ -284,6 +284,13 @@ static int amdgpu_vram_mgr_new(struct 
>> ttm_mem_type_manager *man,
>>   if (!lpfn)
>>   lpfn = man->size;
>>   +    /* bail out quickly if there's likely not enough VRAM for this 
>> BO */
>> +    atomic64_add(mem->num_pages << PAGE_SHIFT, >usage);
>> +    if (atomic64_read(>usage) > adev->gmc.mc_vram_size) {
>> +    atomic64_sub(mem->num_pages << PAGE_SHIFT, >usage);
>> +    return -ENOSPC;
>> +    }
>
> That's not 100% correct IIRC. See TTM expects a return value of 0, but 
> mem->node to be NULL when allocation fails.


Yup, the node creation returns -ENOSPC which this function then 
translates to 0.  I'll submit a v2 in a minute once I pass a piglit test :-)


Tom

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH] drm/amd/amdgpu: Bail out of BO node creation if not enough VRAM

[StDenis, Tom]

Signed-off-by: Tom St Denis 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 17 -
 1 file changed, 12 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
index 8aea2f21b202..70b4a5a97ed2 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
@@ -276,7 +276,7 @@ static int amdgpu_vram_mgr_new(struct ttm_mem_type_manager 
*man,
struct drm_mm_node *nodes;
enum drm_mm_insert_mode mode;
unsigned long lpfn, num_nodes, pages_per_node, pages_left;
-   uint64_t usage = 0, vis_usage = 0;
+   uint64_t vis_usage = 0;
unsigned i;
int r;
 
@@ -284,6 +284,13 @@ static int amdgpu_vram_mgr_new(struct ttm_mem_type_manager 
*man,
if (!lpfn)
lpfn = man->size;
 
+   /* bail out quickly if there's likely not enough VRAM for this BO */
+   atomic64_add(mem->num_pages << PAGE_SHIFT, >usage);
+   if (atomic64_read(>usage) > adev->gmc.mc_vram_size) {
+   atomic64_sub(mem->num_pages << PAGE_SHIFT, >usage);
+   return -ENOSPC;
+   }
+
if (place->flags & TTM_PL_FLAG_CONTIGUOUS) {
pages_per_node = ~0ul;
num_nodes = 1;
@@ -300,8 +307,10 @@ static int amdgpu_vram_mgr_new(struct ttm_mem_type_manager 
*man,
 
nodes = kvmalloc_array((uint32_t)num_nodes, sizeof(*nodes),
   GFP_KERNEL | __GFP_ZERO);
-   if (!nodes)
+   if (!nodes) {
+   atomic64_sub(mem->num_pages << PAGE_SHIFT, >usage);
return -ENOMEM;
+   }
 
mode = DRM_MM_INSERT_BEST;
if (place->flags & TTM_PL_FLAG_TOPDOWN)
@@ -321,7 +330,6 @@ static int amdgpu_vram_mgr_new(struct ttm_mem_type_manager 
*man,
if (unlikely(r))
break;
 
-   usage += nodes[i].size << PAGE_SHIFT;
vis_usage += amdgpu_vram_mgr_vis_size(adev, [i]);
amdgpu_vram_mgr_virt_start(mem, [i]);
pages_left -= pages;
@@ -341,14 +349,12 @@ static int amdgpu_vram_mgr_new(struct 
ttm_mem_type_manager *man,
if (unlikely(r))
goto error;
 
-   usage += nodes[i].size << PAGE_SHIFT;
vis_usage += amdgpu_vram_mgr_vis_size(adev, [i]);
amdgpu_vram_mgr_virt_start(mem, [i]);
pages_left -= pages;
}
spin_unlock(>lock);
 
-   atomic64_add(usage, >usage);
atomic64_add(vis_usage, >vis_usage);
 
mem->mm_node = nodes;
@@ -359,6 +365,7 @@ static int amdgpu_vram_mgr_new(struct ttm_mem_type_manager 
*man,
while (i--)
drm_mm_remove_node([i]);
spin_unlock(>lock);
+   atomic64_sub(mem->num_pages << PAGE_SHIFT, >usage);
 
kvfree(nodes);
return r == -ENOSPC ? 0 : r;
-- 
2.21.0

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] drm/amd/amdgpu: remove vram_page_split kernel option (v3)

[StDenis, Tom]

On 2019-06-06 7:49 a.m., Christian König wrote:
> Am 06.06.19 um 12:50 schrieb StDenis, Tom:
>> This option is no longer needed.  The default code paths
>> are now the only option.
>>
>> v2: Add HPAGE support and a default for non contiguous maps
>> v3: Misread 512 pages as MiB ...
>>
>> Signed-off-by: Tom St Denis 
>> ---
>>   drivers/gpu/drm/amd/amdgpu/amdgpu.h  |  1 -
>>   drivers/gpu/drm/amd/amdgpu/amdgpu_device.c   |  7 ---
>>   drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c  |  8 
>>   drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 14 +-
>>   4 files changed, 9 insertions(+), 21 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>> index 19a00282e34c..e54f31865f60 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>> @@ -142,7 +142,6 @@ extern uint amdgpu_sdma_phase_quantum;
>>   extern char *amdgpu_disable_cu;
>>   extern char *amdgpu_virtual_display;
>>   extern uint amdgpu_pp_feature_mask;
>> -extern int amdgpu_vram_page_split;
>>   extern int amdgpu_ngg;
>>   extern int amdgpu_prim_buf_per_se;
>>   extern int amdgpu_pos_buf_per_se;
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>> index 0212c9ee317c..2e13b8ef6681 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>> @@ -973,13 +973,6 @@ static int amdgpu_device_check_arguments(struct 
>> amdgpu_device *adev)
>>     amdgpu_device_check_block_size(adev);
>>   -    if (amdgpu_vram_page_split != -1 && (amdgpu_vram_page_split < 
>> 16 ||
>> -    !is_power_of_2(amdgpu_vram_page_split))) {
>> -    dev_warn(adev->dev, "invalid VRAM page split (%d)\n",
>> - amdgpu_vram_page_split);
>> -    amdgpu_vram_page_split = 1024;
>> -    }
>> -
>>   ret = amdgpu_device_get_job_timeout_settings(adev);
>>   if (ret) {
>>   dev_err(adev->dev, "invalid lockup_timeout parameter 
>> syntax\n");
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
>> index 1f38d6fc1fe3..ef22a2a25448 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
>> @@ -108,7 +108,6 @@ int amdgpu_vm_fragment_size = -1;
>>   int amdgpu_vm_block_size = -1;
>>   int amdgpu_vm_fault_stop = 0;
>>   int amdgpu_vm_debug = 0;
>> -int amdgpu_vram_page_split = 512;
>>   int amdgpu_vm_update_mode = -1;
>>   int amdgpu_exp_hw_support = 0;
>>   int amdgpu_dc = -1;
>> @@ -342,13 +341,6 @@ module_param_named(vm_debug, amdgpu_vm_debug, 
>> int, 0644);
>>   MODULE_PARM_DESC(vm_update_mode, "VM update using CPU (0 = never 
>> (default except for large BAR(LB)), 1 = Graphics only, 2 = Compute 
>> only (default for LB), 3 = Both");
>>   module_param_named(vm_update_mode, amdgpu_vm_update_mode, int, 0444);
>>   -/**
>> - * DOC: vram_page_split (int)
>> - * Override the number of pages after we split VRAM allocations 
>> (default 512, -1 = disable). The default is 512.
>> - */
>> -MODULE_PARM_DESC(vram_page_split, "Number of pages after we split 
>> VRAM allocations (default 512, -1 = disable)");
>> -module_param_named(vram_page_split, amdgpu_vram_page_split, int, 0444);
>> -
>>   /**
>>    * DOC: exp_hw_support (int)
>>    * Enable experimental hw support (1 = enable). The default is 0 
>> (disabled).
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c 
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
>> index ec9ea3fdbb4a..8aea2f21b202 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
>> @@ -284,17 +284,21 @@ static int amdgpu_vram_mgr_new(struct 
>> ttm_mem_type_manager *man,
>>   if (!lpfn)
>>   lpfn = man->size;
>>   -    if (place->flags & TTM_PL_FLAG_CONTIGUOUS ||
>> -    amdgpu_vram_page_split == -1) {
>> +    if (place->flags & TTM_PL_FLAG_CONTIGUOUS) {
>>   pages_per_node = ~0ul;
>>   num_nodes = 1;
>>   } else {
>> -    pages_per_node = max((uint32_t)amdgpu_vram_page_split,
>> - mem->page_alignment);
>> +#ifdef CONFIG_TRANSPARENT_HUGEPAGE
>> +    pages_per_node = HPAGE_PMD_NR;
>> +#else
>> +    /* defaul

Re: [PATCH] drm/amd/amdgpu: remove vram_page_split kernel option (v2)

[StDenis, Tom]

Ah ya I misread the original default as MiB instead of pages.


Tom

On 2019-06-06 6:35 a.m., Christian König wrote:
> Am 04.06.19 um 19:15 schrieb StDenis, Tom:
>> This option is no longer needed.  The default code paths
>> are now the only option.
>>
>> v2: Add HPAGE support and a default for non contiguous maps
>>
>> Signed-off-by: Tom St Denis 
>> ---
>>   drivers/gpu/drm/amd/amdgpu/amdgpu.h  |  1 -
>>   drivers/gpu/drm/amd/amdgpu/amdgpu_device.c   |  7 ---
>>   drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c  |  8 
>>   drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 14 +-
>>   4 files changed, 9 insertions(+), 21 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>> index 19a00282e34c..e54f31865f60 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>> @@ -142,7 +142,6 @@ extern uint amdgpu_sdma_phase_quantum;
>>   extern char *amdgpu_disable_cu;
>>   extern char *amdgpu_virtual_display;
>>   extern uint amdgpu_pp_feature_mask;
>> -extern int amdgpu_vram_page_split;
>>   extern int amdgpu_ngg;
>>   extern int amdgpu_prim_buf_per_se;
>>   extern int amdgpu_pos_buf_per_se;
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>> index d00fd5dd307a..ef7d99ebe92d 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>> @@ -973,13 +973,6 @@ static int amdgpu_device_check_arguments(struct 
>> amdgpu_device *adev)
>>     amdgpu_device_check_block_size(adev);
>>   -    if (amdgpu_vram_page_split != -1 && (amdgpu_vram_page_split < 
>> 16 ||
>> -    !is_power_of_2(amdgpu_vram_page_split))) {
>> -    dev_warn(adev->dev, "invalid VRAM page split (%d)\n",
>> - amdgpu_vram_page_split);
>> -    amdgpu_vram_page_split = 1024;
>> -    }
>> -
>>   ret = amdgpu_device_get_job_timeout_settings(adev);
>>   if (ret) {
>>   dev_err(adev->dev, "invalid lockup_timeout parameter 
>> syntax\n");
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
>> index 1f38d6fc1fe3..ef22a2a25448 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
>> @@ -108,7 +108,6 @@ int amdgpu_vm_fragment_size = -1;
>>   int amdgpu_vm_block_size = -1;
>>   int amdgpu_vm_fault_stop = 0;
>>   int amdgpu_vm_debug = 0;
>> -int amdgpu_vram_page_split = 512;
>>   int amdgpu_vm_update_mode = -1;
>>   int amdgpu_exp_hw_support = 0;
>>   int amdgpu_dc = -1;
>> @@ -342,13 +341,6 @@ module_param_named(vm_debug, amdgpu_vm_debug, 
>> int, 0644);
>>   MODULE_PARM_DESC(vm_update_mode, "VM update using CPU (0 = never 
>> (default except for large BAR(LB)), 1 = Graphics only, 2 = Compute 
>> only (default for LB), 3 = Both");
>>   module_param_named(vm_update_mode, amdgpu_vm_update_mode, int, 0444);
>>   -/**
>> - * DOC: vram_page_split (int)
>> - * Override the number of pages after we split VRAM allocations 
>> (default 512, -1 = disable). The default is 512.
>> - */
>> -MODULE_PARM_DESC(vram_page_split, "Number of pages after we split 
>> VRAM allocations (default 512, -1 = disable)");
>> -module_param_named(vram_page_split, amdgpu_vram_page_split, int, 0444);
>> -
>>   /**
>>    * DOC: exp_hw_support (int)
>>    * Enable experimental hw support (1 = enable). The default is 0 
>> (disabled).
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c 
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
>> index ec9ea3fdbb4a..0bc01e25a0b4 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
>> @@ -284,17 +284,21 @@ static int amdgpu_vram_mgr_new(struct 
>> ttm_mem_type_manager *man,
>>   if (!lpfn)
>>   lpfn = man->size;
>>   -    if (place->flags & TTM_PL_FLAG_CONTIGUOUS ||
>> -    amdgpu_vram_page_split == -1) {
>> +    if (place->flags & TTM_PL_FLAG_CONTIGUOUS) {
>>   pages_per_node = ~0ul;
>>   num_nodes = 1;
>>   } else {
>> -    pages_per_node = max((uint32_t)amdgpu_vram_page_split,
>> - mem->page_alignment);
>> +#ifdef CONFIG_TRANSPARENT_HUGEPAGE
>> +    pages_per_node = HPAGE_PMD_NR;
>> +#else

[PATCH] drm/amd/amdgpu: remove vram_page_split kernel option (v3)

[StDenis, Tom]

This option is no longer needed.  The default code paths
are now the only option.

v2: Add HPAGE support and a default for non contiguous maps
v3: Misread 512 pages as MiB ...

Signed-off-by: Tom St Denis 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu.h  |  1 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c   |  7 ---
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c  |  8 
 drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 14 +-
 4 files changed, 9 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 19a00282e34c..e54f31865f60 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -142,7 +142,6 @@ extern uint amdgpu_sdma_phase_quantum;
 extern char *amdgpu_disable_cu;
 extern char *amdgpu_virtual_display;
 extern uint amdgpu_pp_feature_mask;
-extern int amdgpu_vram_page_split;
 extern int amdgpu_ngg;
 extern int amdgpu_prim_buf_per_se;
 extern int amdgpu_pos_buf_per_se;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 0212c9ee317c..2e13b8ef6681 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -973,13 +973,6 @@ static int amdgpu_device_check_arguments(struct 
amdgpu_device *adev)
 
amdgpu_device_check_block_size(adev);
 
-   if (amdgpu_vram_page_split != -1 && (amdgpu_vram_page_split < 16 ||
-   !is_power_of_2(amdgpu_vram_page_split))) {
-   dev_warn(adev->dev, "invalid VRAM page split (%d)\n",
-amdgpu_vram_page_split);
-   amdgpu_vram_page_split = 1024;
-   }
-
ret = amdgpu_device_get_job_timeout_settings(adev);
if (ret) {
dev_err(adev->dev, "invalid lockup_timeout parameter syntax\n");
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 1f38d6fc1fe3..ef22a2a25448 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -108,7 +108,6 @@ int amdgpu_vm_fragment_size = -1;
 int amdgpu_vm_block_size = -1;
 int amdgpu_vm_fault_stop = 0;
 int amdgpu_vm_debug = 0;
-int amdgpu_vram_page_split = 512;
 int amdgpu_vm_update_mode = -1;
 int amdgpu_exp_hw_support = 0;
 int amdgpu_dc = -1;
@@ -342,13 +341,6 @@ module_param_named(vm_debug, amdgpu_vm_debug, int, 0644);
 MODULE_PARM_DESC(vm_update_mode, "VM update using CPU (0 = never (default 
except for large BAR(LB)), 1 = Graphics only, 2 = Compute only (default for 
LB), 3 = Both");
 module_param_named(vm_update_mode, amdgpu_vm_update_mode, int, 0444);
 
-/**
- * DOC: vram_page_split (int)
- * Override the number of pages after we split VRAM allocations (default 512, 
-1 = disable). The default is 512.
- */
-MODULE_PARM_DESC(vram_page_split, "Number of pages after we split VRAM 
allocations (default 512, -1 = disable)");
-module_param_named(vram_page_split, amdgpu_vram_page_split, int, 0444);
-
 /**
  * DOC: exp_hw_support (int)
  * Enable experimental hw support (1 = enable). The default is 0 (disabled).
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
index ec9ea3fdbb4a..8aea2f21b202 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
@@ -284,17 +284,21 @@ static int amdgpu_vram_mgr_new(struct 
ttm_mem_type_manager *man,
if (!lpfn)
lpfn = man->size;
 
-   if (place->flags & TTM_PL_FLAG_CONTIGUOUS ||
-   amdgpu_vram_page_split == -1) {
+   if (place->flags & TTM_PL_FLAG_CONTIGUOUS) {
pages_per_node = ~0ul;
num_nodes = 1;
} else {
-   pages_per_node = max((uint32_t)amdgpu_vram_page_split,
-mem->page_alignment);
+#ifdef CONFIG_TRANSPARENT_HUGEPAGE
+   pages_per_node = HPAGE_PMD_NR;
+#else
+   /* default to 2MB */
+   pages_per_node = (2UL << (20UL - PAGE_SHIFT));
+#endif
+   pages_per_node = max((uint32_t)pages_per_node, 
mem->page_alignment);
num_nodes = DIV_ROUND_UP(mem->num_pages, pages_per_node);
}
 
-   nodes = kvmalloc_array(num_nodes, sizeof(*nodes),
+   nodes = kvmalloc_array((uint32_t)num_nodes, sizeof(*nodes),
   GFP_KERNEL | __GFP_ZERO);
if (!nodes)
return -ENOMEM;
-- 
2.21.0

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH] drm/amd/amdgpu: remove vram_page_split kernel option (v2)

[StDenis, Tom]

This option is no longer needed.  The default code paths
are now the only option.

v2: Add HPAGE support and a default for non contiguous maps

Signed-off-by: Tom St Denis 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu.h  |  1 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c   |  7 ---
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c  |  8 
 drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 14 +-
 4 files changed, 9 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 19a00282e34c..e54f31865f60 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -142,7 +142,6 @@ extern uint amdgpu_sdma_phase_quantum;
 extern char *amdgpu_disable_cu;
 extern char *amdgpu_virtual_display;
 extern uint amdgpu_pp_feature_mask;
-extern int amdgpu_vram_page_split;
 extern int amdgpu_ngg;
 extern int amdgpu_prim_buf_per_se;
 extern int amdgpu_pos_buf_per_se;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index d00fd5dd307a..ef7d99ebe92d 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -973,13 +973,6 @@ static int amdgpu_device_check_arguments(struct 
amdgpu_device *adev)
 
amdgpu_device_check_block_size(adev);
 
-   if (amdgpu_vram_page_split != -1 && (amdgpu_vram_page_split < 16 ||
-   !is_power_of_2(amdgpu_vram_page_split))) {
-   dev_warn(adev->dev, "invalid VRAM page split (%d)\n",
-amdgpu_vram_page_split);
-   amdgpu_vram_page_split = 1024;
-   }
-
ret = amdgpu_device_get_job_timeout_settings(adev);
if (ret) {
dev_err(adev->dev, "invalid lockup_timeout parameter syntax\n");
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 1f38d6fc1fe3..ef22a2a25448 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -108,7 +108,6 @@ int amdgpu_vm_fragment_size = -1;
 int amdgpu_vm_block_size = -1;
 int amdgpu_vm_fault_stop = 0;
 int amdgpu_vm_debug = 0;
-int amdgpu_vram_page_split = 512;
 int amdgpu_vm_update_mode = -1;
 int amdgpu_exp_hw_support = 0;
 int amdgpu_dc = -1;
@@ -342,13 +341,6 @@ module_param_named(vm_debug, amdgpu_vm_debug, int, 0644);
 MODULE_PARM_DESC(vm_update_mode, "VM update using CPU (0 = never (default 
except for large BAR(LB)), 1 = Graphics only, 2 = Compute only (default for 
LB), 3 = Both");
 module_param_named(vm_update_mode, amdgpu_vm_update_mode, int, 0444);
 
-/**
- * DOC: vram_page_split (int)
- * Override the number of pages after we split VRAM allocations (default 512, 
-1 = disable). The default is 512.
- */
-MODULE_PARM_DESC(vram_page_split, "Number of pages after we split VRAM 
allocations (default 512, -1 = disable)");
-module_param_named(vram_page_split, amdgpu_vram_page_split, int, 0444);
-
 /**
  * DOC: exp_hw_support (int)
  * Enable experimental hw support (1 = enable). The default is 0 (disabled).
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
index ec9ea3fdbb4a..0bc01e25a0b4 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
@@ -284,17 +284,21 @@ static int amdgpu_vram_mgr_new(struct 
ttm_mem_type_manager *man,
if (!lpfn)
lpfn = man->size;
 
-   if (place->flags & TTM_PL_FLAG_CONTIGUOUS ||
-   amdgpu_vram_page_split == -1) {
+   if (place->flags & TTM_PL_FLAG_CONTIGUOUS) {
pages_per_node = ~0ul;
num_nodes = 1;
} else {
-   pages_per_node = max((uint32_t)amdgpu_vram_page_split,
-mem->page_alignment);
+#ifdef CONFIG_TRANSPARENT_HUGEPAGE
+   pages_per_node = HPAGE_PMD_NR;
+#else
+   /* default to 512MB */
+   pages_per_node = (512UL << (20UL - PAGE_SHIFT));
+#endif
+   pages_per_node = max((uint32_t)pages_per_node, 
mem->page_alignment);
num_nodes = DIV_ROUND_UP(mem->num_pages, pages_per_node);
}
 
-   nodes = kvmalloc_array(num_nodes, sizeof(*nodes),
+   nodes = kvmalloc_array((uint32_t)num_nodes, sizeof(*nodes),
   GFP_KERNEL | __GFP_ZERO);
if (!nodes)
return -ENOMEM;
-- 
2.21.0

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH] drm/amd/amdgpu: remove vram_page_split kernel option

[StDenis, Tom]

This option is no longer needed.  The default code paths
are now the only option.

Signed-off-by: Tom St Denis 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu.h  | 1 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c   | 7 ---
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c  | 8 
 drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 7 +--
 4 files changed, 1 insertion(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 19a00282e34c..e54f31865f60 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -142,7 +142,6 @@ extern uint amdgpu_sdma_phase_quantum;
 extern char *amdgpu_disable_cu;
 extern char *amdgpu_virtual_display;
 extern uint amdgpu_pp_feature_mask;
-extern int amdgpu_vram_page_split;
 extern int amdgpu_ngg;
 extern int amdgpu_prim_buf_per_se;
 extern int amdgpu_pos_buf_per_se;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index d00fd5dd307a..ef7d99ebe92d 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -973,13 +973,6 @@ static int amdgpu_device_check_arguments(struct 
amdgpu_device *adev)
 
amdgpu_device_check_block_size(adev);
 
-   if (amdgpu_vram_page_split != -1 && (amdgpu_vram_page_split < 16 ||
-   !is_power_of_2(amdgpu_vram_page_split))) {
-   dev_warn(adev->dev, "invalid VRAM page split (%d)\n",
-amdgpu_vram_page_split);
-   amdgpu_vram_page_split = 1024;
-   }
-
ret = amdgpu_device_get_job_timeout_settings(adev);
if (ret) {
dev_err(adev->dev, "invalid lockup_timeout parameter syntax\n");
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 1f38d6fc1fe3..ef22a2a25448 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -108,7 +108,6 @@ int amdgpu_vm_fragment_size = -1;
 int amdgpu_vm_block_size = -1;
 int amdgpu_vm_fault_stop = 0;
 int amdgpu_vm_debug = 0;
-int amdgpu_vram_page_split = 512;
 int amdgpu_vm_update_mode = -1;
 int amdgpu_exp_hw_support = 0;
 int amdgpu_dc = -1;
@@ -342,13 +341,6 @@ module_param_named(vm_debug, amdgpu_vm_debug, int, 0644);
 MODULE_PARM_DESC(vm_update_mode, "VM update using CPU (0 = never (default 
except for large BAR(LB)), 1 = Graphics only, 2 = Compute only (default for 
LB), 3 = Both");
 module_param_named(vm_update_mode, amdgpu_vm_update_mode, int, 0444);
 
-/**
- * DOC: vram_page_split (int)
- * Override the number of pages after we split VRAM allocations (default 512, 
-1 = disable). The default is 512.
- */
-MODULE_PARM_DESC(vram_page_split, "Number of pages after we split VRAM 
allocations (default 512, -1 = disable)");
-module_param_named(vram_page_split, amdgpu_vram_page_split, int, 0444);
-
 /**
  * DOC: exp_hw_support (int)
  * Enable experimental hw support (1 = enable). The default is 0 (disabled).
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
index ec9ea3fdbb4a..4f77a6056a3b 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
@@ -284,14 +284,9 @@ static int amdgpu_vram_mgr_new(struct ttm_mem_type_manager 
*man,
if (!lpfn)
lpfn = man->size;
 
-   if (place->flags & TTM_PL_FLAG_CONTIGUOUS ||
-   amdgpu_vram_page_split == -1) {
+   if (place->flags & TTM_PL_FLAG_CONTIGUOUS) {
pages_per_node = ~0ul;
num_nodes = 1;
-   } else {
-   pages_per_node = max((uint32_t)amdgpu_vram_page_split,
-mem->page_alignment);
-   num_nodes = DIV_ROUND_UP(mem->num_pages, pages_per_node);
}
 
nodes = kvmalloc_array(num_nodes, sizeof(*nodes),
-- 
2.21.0

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH] drm/amd/doc: add rough outline of tracepoint documentation

[StDenis, Tom]

Signed-off-by: Tom St Denis 
---
 Documentation/gpu/amdgpu.rst  |  10 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h | 221 ++
 2 files changed, 231 insertions(+)

diff --git a/Documentation/gpu/amdgpu.rst b/Documentation/gpu/amdgpu.rst
index 86138798128f..3564765110e5 100644
--- a/Documentation/gpu/amdgpu.rst
+++ b/Documentation/gpu/amdgpu.rst
@@ -89,6 +89,16 @@ AMDGPU RAS debugfs control interface
 .. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
:internal:
 
+AMDGPU Tracing Support
+==
+
+.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
+   :doc: AMDGPU Tracing Support
+
+
+.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
+   :internal:
+
 
 GPU Power/Thermal Controls and Monitoring
 =
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
index d3ca2424b5fe..71febb90d3e3 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
@@ -37,6 +37,227 @@
 #define AMDGPU_JOB_GET_TIMELINE_NAME(job) \
 
job->base.s_fence->finished.ops->get_timeline_name(>base.s_fence->finished)
 
+/**
+ * DOC: AMDGPU Tracing Support
+ *
+ * The AMDGPU driver provides numerous trace points that can aid
+ * in debugging.  They are globally enabled by the file:
+ *
+ * /sys/kernel/debug/tracing/events/amdgpu/enable
+ *
+ * or individually by the enable files in the sub-directories
+ * of that directory.
+ *
+ * amdgpu_mm_rreg, amdgpu_mm_wreg
+ * --
+ *
+ * These trace points track reads and writes to MMIO registers by
+ * the kernel driver (activity inside ring/indirect buffers are not
+ * traced) which can be used to diagnose IP block activity and
+ * responses.
+ *
+ * The trace captures the following information:
+ *
+ * - DID of the device being used
+ * - Register address
+ * - Value being read or written
+ *
+ * It does not differentiate between multiple instances of the same
+ * ASIC. The register address is the DWORD address of the register
+ * being used.
+ *
+ * amdgpu_iv
+ * -
+ *
+ * This tracepoint captures data from an IRQ event before dispatching
+ * control to the respective IP block IRQ handler.  The trace
+ * captures the following information:
+ *
+ *- client ID
+ *- source ID
+ *- ring ID
+ *- VM ID
+ *- VM ID source
+ *- Timestamp
+ *- Timestamp source
+ *- PAS ID
+ *- 4 SRC data words
+ *
+ * amdgpu_bo_create
+ * 
+ *
+ * This tracepoint captures the state of a successfully created
+ * buffer object (BO).  The trace captures the following information:
+ *
+ *- kernel address of the BO
+ *- Number of (GPU) pages
+ *- Memory type
+ *- Preferred domain
+ *- Allowed domains
+ *- Buffer Object Flags
+ *
+ * amdgpu_cs
+ * -
+ *
+ * This tracepoint captures data about a command submission prior
+ * to being submitted to a ring (or queue).  The trace captures all
+ * indirect buffers (ibs) at once before issuing any commands.  The
+ * trace captures the following information:
+ *
+ *- kernel address of the buffer object (BO) list
+ *- The ring (index) being submitted to
+ *- The number of words
+ *- The number of fences emitted
+ *
+ * amdgpu_cs_ioctl
+ * ---
+ *
+ * This tracepoint captures information from the IOCTL query that
+ * submits commands to a ring.  It is part of the DRM userspace
+ * infrastructure.  The trace captures the following information:
+ *
+ *- Schedule job ID
+ *- Timeline (name of ring the fence is emitted to)
+ *- Fence context
+ *- Fence sequence number
+ *- Ring name being submitted to
+ *- Number of indirect buffers (ibs)
+ *
+ * amdgpu_sched_run_job
+ * 
+ *
+ * This tracepoint captures information about a job submission
+ * at the point of scheduling for submission to a ring.  The trace
+ * captures the following information:
+ *
+ *- Job ID
+ *- Timeline (name of ring the fence is emitted to)
+ *- Context ID
+ *- Sequence Number
+ *- Ring name being submitted to
+ *- Number of indirect buffers (ibs)
+ *
+ * amdgpu_vm_grab_id
+ * -
+ *
+ * This tracepoint captures information about a VM allocation.
+ * The trace captures the following information:
+ *
+ *- PAS ID
+ *- Ring name
+ *- Ring index
+ *- VM ID that is assigned
+ *- VM hub assigned (depends on ring)
+ *- Page Directory base address
+ *- Flag indicating whether it needs to be flushed or not
+ *
+ * amdgpu_vm_bo_map
+ * 
+ *
+ * This tracepoint captures information when a new mapping is inserted
+ * into a VM space.  The trace captures the following information:
+ *
+ *- Kernel address of the buffer object (bo)
+ *- Start page address of mapping
+ *- Last page address of mapping
+ *- Offset into mapping
+ *- Flags 

[PATCH 2/2] drm/amd/doc: Add RAS documentation to guide

[StDenis, Tom]

Signed-off-by: Tom St Denis 
---
 Documentation/gpu/amdgpu.rst| 11 +++
 drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c |  4 ++--
 2 files changed, 13 insertions(+), 2 deletions(-)

diff --git a/Documentation/gpu/amdgpu.rst b/Documentation/gpu/amdgpu.rst
index cacfcfad2356..86138798128f 100644
--- a/Documentation/gpu/amdgpu.rst
+++ b/Documentation/gpu/amdgpu.rst
@@ -79,6 +79,17 @@ AMDGPU XGMI Support
 .. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c
:internal:
 
+AMDGPU RAS debugfs control interface
+
+
+.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
+   :doc: AMDGPU RAS debugfs control interface
+
+
+.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
+   :internal:
+
+
 GPU Power/Thermal Controls and Monitoring
 =
 
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
index d5719b0fb82c..7c8a4aedf07c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
@@ -244,8 +244,8 @@ static int amdgpu_ras_debugfs_ctrl_parse_data(struct file 
*f,
 
return 0;
 }
-/*
- * DOC: ras debugfs control interface
+/**
+ * DOC: AMDGPU RAS debugfs control interface
  *
  * It accepts struct ras_debug_if who has two members.
  *
-- 
2.21.0

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH 1/2] drm/amd/doc: Add XGMI sysfs documentation

[StDenis, Tom]

Signed-off-by: Tom St Denis 
---
 Documentation/gpu/amdgpu.rst |  9 
 drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c | 28 
 2 files changed, 37 insertions(+)

diff --git a/Documentation/gpu/amdgpu.rst b/Documentation/gpu/amdgpu.rst
index a740e491dfcc..cacfcfad2356 100644
--- a/Documentation/gpu/amdgpu.rst
+++ b/Documentation/gpu/amdgpu.rst
@@ -70,6 +70,15 @@ Interrupt Handling
 .. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c
:internal:
 
+AMDGPU XGMI Support
+===
+
+.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c
+   :doc: AMDGPU XGMI Support
+
+.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c
+   :internal:
+
 GPU Power/Thermal Controls and Monitoring
 =
 
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c
index e48e9394f1e4..d11eba09eadd 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c
@@ -40,6 +40,34 @@ void *amdgpu_xgmi_hive_try_lock(struct amdgpu_hive_info 
*hive)
return >device_list;
 }
 
+/**
+ * DOC: AMDGPU XGMI Support
+ *
+ * XGMI is a high speed interconnect that joins multiple GPU cards
+ * into a homogeneous memory space that is organized by a collective
+ * hive ID and individual node IDs, both of which are 64-bit numbers.
+ *
+ * The file xgmi_device_id contains the unique per GPU device ID and
+ * is stored in the /sys/class/drm/card${cardno}/device/ directory.
+ *
+ * Inside the device directory a sub-directory 'xgmi_hive_info' is
+ * created which contains the hive ID and the list of nodes.
+ *
+ * The hive ID is stored in:
+ *   /sys/class/drm/card${cardno}/device/xgmi_hive_info/xgmi_hive_id
+ *
+ * The node information is stored in numbered directories:
+ *   
/sys/class/drm/card${cardno}/device/xgmi_hive_info/node${nodeno}/xgmi_device_id
+ *
+ * Each device has their own xgmi_hive_info direction with a mirror
+ * set of node sub-directories.
+ *
+ * The XGMI memory space is built by contiguously adding the power of
+ * two padded VRAM space from each node to each other.
+ *
+ */
+
+
 static ssize_t amdgpu_xgmi_show_hive_id(struct device *dev,
struct device_attribute *attr, char *buf)
 {
-- 
2.21.0

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH] drm/amd/amdgpu: Add MEM_LOAD to amdgpu_pm_info debugfs file

[StDenis, Tom]

Signed-off-by: Tom St Denis 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
index 5e2d039e09ad..e0789f0f2670 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
@@ -2955,6 +2955,10 @@ static int amdgpu_debugfs_pm_info_pp(struct seq_file *m, 
struct amdgpu_device *a
/* GPU Load */
if (!amdgpu_dpm_read_sensor(adev, AMDGPU_PP_SENSOR_GPU_LOAD, (void 
*), ))
seq_printf(m, "GPU Load: %u %%\n", value);
+   /* MEM Load */
+   if (!amdgpu_dpm_read_sensor(adev, AMDGPU_PP_SENSOR_MEM_LOAD, (void 
*), ))
+   seq_printf(m, "MEM Load: %u %%\n", value);
+
seq_printf(m, "\n");
 
/* SMC feature mask */
-- 
2.20.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] drm/amdgpu: add one rlc version into gfxoff blacklist

[StDenis, Tom]

FWIW when I manually apply this to my drm-next kernel on my raven1 devel 
box it works fine.


Tested-by: Tom St Denis 

Tom

On 2019-03-19 9:31 a.m., Huang Rui wrote:
> RLC #53815 ucode has the noise issue on 4k playback while gfxoff enabled.
>
> Signed-off-by: Huang Rui 
> ---
>   drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 1 +
>   1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c 
> b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
> index 6b48d4c..3765d97 100644
> --- a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
> @@ -589,6 +589,7 @@ static void gfx_v9_0_check_if_need_gfxoff(struct 
> amdgpu_device *adev)
>   if (adev->rev_id >= 0x8 || adev->pdev->device == 0x15d8)
>   break;
>   if ((adev->gfx.rlc_fw_version < 531) ||
> + (adev->gfx.rlc_fw_version == 53815) ||
>   (adev->gfx.rlc_feature_version < 1) ||
>   !adev->gfx.rlc.is_rlc_v2_1)
>   adev->pm.pp_feature &= ~PP_GFXOFF_MASK;
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: kernel errors with HMM enabled

[StDenis, Tom]

On 2019-03-14 12:37 p.m., Alex Deucher wrote:
> Make sure you have this patch:
> https://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-next-5.2-wip=e811b0a799981eaa6fef1809278367471f14ba13

Hi Alex,

The tip of our amd-staging-drm-next includes this patch (about 126 down 
from the tip).

Tom
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

kernel errors with HMM enabled

[StDenis, Tom]

Hi Philip,

With your HMM patches enabled I'm seeing (attached) kernel errors while 
running piglit.  Are these known?  I see it all along 
amd-staging-drm-next until I roll back before your very first HMM patches.

Tom


log.gz
Description: log.gz
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] drm/amdgpu: Add sysfs entries for xgmi hive.

[StDenis, Tom]

On 2019-03-05 2:16 p.m., Grodzovsky, Andrey wrote:
> In each /sys/class/drm/cardX/device/ device you will see the following
> 
> xgmi_device_id /* contains the device id within the hive */
> xgmi_hive_info ->
> ../../../../:00:01.1/:02:00.0/:03:00.0/:04:00.0/xgmi_hive_info/
> /* hive info folder */
> 
> inside xgmi_hive_info are back pointers to /sys/class/drm/cardX/device/
> for each hive member -
> 
> lrwxrwxrwx  1 root root    0 Mar  5 12:27 node1 -> ../../:04:00.0/
> lrwxrwxrwx  1 root root    0 Mar  5 12:27 node2 ->
> ../../../../../:00:1b.0/:05:00.0/:06:00.0/:07:00.0/
> 
> -r--r--r--  1 root root 4096 Mar  5 12:27 xgmi_hive_id /* contains the
> hive id */

Could I get an ssh on such a box to test out the umr code (which I 
haven't written yet)?

Thanks,
Tom
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] drm/amdgpu: Add sysfs entries for xgmi hive.

[StDenis, Tom]

Couple of comments inline.

Since I don't have any XGMI gear it would probably help to see what the 
final directory layout/contents look like so I can update umr to 
automagically scan all of this.

Tom

On 2019-03-05 12:47 p.m., Andrey Grodzovsky wrote:
> For each device a file xgmi_device_id is created.
> On the first device a subdirectory named xgmi_hive_info is created,
> It contains  a file named hive_id and symlinks named node 1-4 linking
> to each device in the hive.
> 
> Signed-off-by: Andrey Grodzovsky 
> ---
>   drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c | 145 
> ++-
>   drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.h |   6 +-
>   2 files changed, 146 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c
> index 407dd16c..394be10 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c
> @@ -34,12 +34,132 @@ static DEFINE_MUTEX(xgmi_mutex);
>   static struct amdgpu_hive_info xgmi_hives[AMDGPU_MAX_XGMI_HIVE];
>   static unsigned hive_count = 0;
>   
> -
>   void *amdgpu_xgmi_hive_try_lock(struct amdgpu_hive_info *hive)
>   {
>   return >device_list;
>   }
>   
> +static ssize_t amdgpu_xgmi_show_hive_id(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + struct amdgpu_hive_info *hive =
> + container_of(attr, struct amdgpu_hive_info, dev_attr);
> +
> + return snprintf(buf, PAGE_SIZE, "%llu\n", hive->hive_id);
> +}
> +
> +static int amdgpu_xgmi_sysfs_create(struct amdgpu_device *adev,
> + struct amdgpu_hive_info *hive)
> +{
> + int ret = 0;
> +
> + if (WARN_ON(hive->kobj))
> + return -1;
> +
> + hive->kobj = kobject_create_and_add("xgmi_hive_info", >dev->kobj);
> + if (!hive->kobj) {
> + dev_err(adev->dev, "XGMI: Failed to allocate sysfs entry!\n");
> + return -1;
> + }
> +
> + hive->dev_attr = (struct device_attribute) {
> + .attr = {
> + .name = "xgmi_hive_id",
> + .mode = S_IRUGO,
> +
> + },
> + .show = amdgpu_xgmi_show_hive_id,
> + };
> +
> + ret = sysfs_create_file(hive->kobj, >dev_attr.attr);
> + if (ret) {
> + dev_err(adev->dev, "XGMI: Failed to create device file 
> xgmi_hive_id\n");
> + kobject_del(hive->kobj);
> + kobject_put(hive->kobj);
> + hive->kobj = NULL;
> + }
> +
> + return ret;
> +}
> +
> +static void amdgpu_xgmi_sysfs_destroy(struct amdgpu_device *adev,
> + struct amdgpu_hive_info *hive)
> +{
> + sysfs_remove_file(hive->kobj, >dev_attr.attr);
> + kobject_del(hive->kobj);
> + kobject_put(hive->kobj);
> + hive->kobj = NULL;
> +}
> +
> +static ssize_t amdgpu_xgmi_show_device_id(struct device *dev,
> +  struct device_attribute *attr,
> +  char *buf)
> +{
> + struct drm_device *ddev = dev_get_drvdata(dev);
> + struct amdgpu_device *adev = ddev->dev_private;
> +
> + return snprintf(buf, PAGE_SIZE, "%llu\n", adev->gmc.xgmi.node_id);
> +
> +}
> +
> +
> +static DEVICE_ATTR(xgmi_device_id, S_IRUGO, amdgpu_xgmi_show_device_id, 
> NULL);
> +
> +
> +static int amdgpu_xgmi_sysf_add_dev_info(struct amdgpu_device *adev,
> +  struct amdgpu_hive_info *hive)

Probably meant "sysfs" here right?

> +{
> + int ret = 0;
> + char node[10] = { 0 };
> +
> + /* Create xgmi device id file */
> + ret = device_create_file(adev->dev, _attr_xgmi_device_id);
> + if (ret) {
> + dev_err(adev->dev, "XGMI: Failed to create device file 
> xgmi_device_id\n");
> + return ret;
> + }
> +
> + /* Create sysfs link to hive info folder on the first device */
> + if (adev != hive->adev) {
> + ret = sysfs_create_link(>dev->kobj, hive->kobj,
> + "xgmi_hive_info");
> + if (ret) {
> + dev_err(adev->dev, "XGMI: Failed to create link to hive 
> info");
> + goto remove_file;
> + }
> + }
> +
> + sprintf(node, "node%d", hive->number_devices);
> + /* Create sysfs link form the hive folder to yorself */

"yourself"

> + ret = sysfs_create_link(hive->kobj, >dev->kobj, node);
> + if (ret) {
> + dev_err(adev->dev, "XGMI: Failed to create link from hive 
> info");
> + goto remove_link;
> + }
> +
> + goto success;
> +
> +
> +remove_link:
> + sysfs_remove_link(>dev->kobj, adev->ddev->unique);
> +
> +remove_file:
> + device_remove_file(adev->dev, _attr_xgmi_device_id);
> +
> +success:
> + return ret;
> +}
> +
> +static void amdgpu_xgmi_sysf_rem_dev_info(struct amdgpu_device *adev,
> + 

[PATCH] drm/amd/amdgpu: Add ENGINE_CNTL register to vcn10 headers

[StDenis, Tom]

Signed-off-by: Tom St Denis 
---
 drivers/gpu/drm/amd/include/asic_reg/vcn/vcn_1_0_offset.h  | 2 ++
 drivers/gpu/drm/amd/include/asic_reg/vcn/vcn_1_0_sh_mask.h | 5 +
 2 files changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/amd/include/asic_reg/vcn/vcn_1_0_offset.h 
b/drivers/gpu/drm/amd/include/asic_reg/vcn/vcn_1_0_offset.h
index 442ca7c471a5..6109f5ad25ad 100644
--- a/drivers/gpu/drm/amd/include/asic_reg/vcn/vcn_1_0_offset.h
+++ b/drivers/gpu/drm/amd/include/asic_reg/vcn/vcn_1_0_offset.h
@@ -141,6 +141,8 @@
 #define mmUVD_GPCOM_VCPU_DATA0_BASE_IDX
1
 #define mmUVD_GPCOM_VCPU_DATA1 
0x03c5
 #define mmUVD_GPCOM_VCPU_DATA1_BASE_IDX
1
+#define mmUVD_ENGINE_CNTL  
0x03c6
+#define mmUVD_ENGINE_CNTL_BASE_IDX 
1
 #define mmUVD_UDEC_DBW_UV_ADDR_CONFIG  
0x03d2
 #define mmUVD_UDEC_DBW_UV_ADDR_CONFIG_BASE_IDX 
1
 #define mmUVD_UDEC_ADDR_CONFIG 
0x03d3
diff --git a/drivers/gpu/drm/amd/include/asic_reg/vcn/vcn_1_0_sh_mask.h 
b/drivers/gpu/drm/amd/include/asic_reg/vcn/vcn_1_0_sh_mask.h
index 63457f9df4c5..f84bed6eecb9 100644
--- a/drivers/gpu/drm/amd/include/asic_reg/vcn/vcn_1_0_sh_mask.h
+++ b/drivers/gpu/drm/amd/include/asic_reg/vcn/vcn_1_0_sh_mask.h
@@ -312,6 +312,11 @@
 //UVD_GPCOM_VCPU_DATA1
 #define UVD_GPCOM_VCPU_DATA1__DATA1__SHIFT 
   0x0
 #define UVD_GPCOM_VCPU_DATA1__DATA1_MASK   
   0xL
+//UVD_ENGINE_CNTL
+#define UVD_ENGINE_CNTL__ENGINE_START_MASK 0x1
+#define UVD_ENGINE_CNTL__ENGINE_START__SHIFT 0x0
+#define UVD_ENGINE_CNTL__ENGINE_START_MODE_MASK 0x2
+#define UVD_ENGINE_CNTL__ENGINE_START_MODE__SHIFT 0x1
 //UVD_UDEC_DBW_UV_ADDR_CONFIG
 #define UVD_UDEC_DBW_UV_ADDR_CONFIG__NUM_PIPES__SHIFT  
   0x0
 #define UVD_UDEC_DBW_UV_ADDR_CONFIG__PIPE_INTERLEAVE_SIZE__SHIFT   
   0x3
-- 
2.17.2

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: amd-staging-drm-next: Oops - BUG: unable to handle kernel NULL pointer dereference, bisected.

[StDenis, Tom]

On 2019-01-31 4:23 a.m., Przemek Socha wrote:
> Dnia środa, 30 stycznia 2019 13:42:33 CET piszesz:
>> Does the attached patch fix the issue?
>>
>> Christian.
> 
> I have tested this one also - "drm/amdgpu: partial revert cleanup setting
> bulk_movable v2"
> 
>> We still need to set bulk_movable to false when new BOs are added or removed.
>>
>> v2: also set it to false on removal
>>
>> Signed-off-by: Christian König 
>> ---
>> drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 4 
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c b/drivers/gpu/drm/amd/
>> amdgpu/amdgpu_vm.c
>> index 79f9dde70bc0..822546a149fa 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
>> @@ -332,6 +332,7 @@  static void amdgpu_vm_bo_base_init(struct
>> amdgpu_vm_bo_base *base,
>>  if (bo->tbo.resv != vm->root.base.bo->tbo.resv)
>>  return;
>>
>> +vm->bulk_moveable = false;
>>  if (bo->tbo.type == ttm_bo_type_kernel)
>>  amdgpu_vm_bo_relocated(base);
>>  else
>> @@ -2772,6 +2773,9 @@  void amdgpu_vm_bo_rmv(struct amdgpu_device *adev,
>>  struct amdgpu_vm_bo_base **base;
>>
>>  if (bo) {
>> +if (bo->tbo.resv == vm->root.base.bo->tbo.resv)
>> +vm->bulk_moveable = false;
>> +
>>  for (base = _va->base.bo->vm_bo; *base;
>>   base = &(*base)->next) {
>>  if (*base != _va->base)
> 
> and so far I have no lockup and Oops, so I think this one is ok.

In my experience only the last chunk of the patch is necessary.  Can you 
try this without:

 >> +   vm->bulk_moveable = false;

Too?

Thanks,
Tom
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: amd-staging-drm-next: Oops - BUG: unable to handle kernel NULL pointer dereference, bisected.

[StDenis, Tom]

On 2019-01-30 7:42 a.m., Koenig, Christian wrote:
> Does the attached patch fix the issue?

No.  Now I get a lockup when I start GNOME and try to bring up a 
terminal.  The patch also didn't apply cleanly on top of drm-next but I 
was able to just manually add the line.

[   88.018735] general protection fault:  [#1] SMP NOPTI
[   88.018741] CPU: 5 PID: 4164 Comm: gnome-shel:cs0 Tainted: GW 
 5.0.0-rc1+ #20
[   88.018743] Hardware name: System manufacturer System Product 
Name/TUF B350M-PLUS GAMING, BIOS 4011 04/19/2018
[   88.018750] RIP: 0010:ttm_bo_bulk_move_lru_tail+0x36/0x190 [ttm]
[   88.018753] Code: 90 48 85 d2 74 66 48 8b 4c 37 98 4c 8b 92 b0 00 00 
00 4c 8d 9a a8 00 00 00 4c 8b 0a 48 8b 81 a8 00 00 00 48 81 c1 a8 00 00 
00 <49> 89 02 4c 8b 92 b0 00 00 00 4c 89 50 08 44 89 c0 48 c1 e0 04 4c
[   88.018755] RSP: 0018:b419c1fefb18 EFLAGS: 00010296
[   88.018757] RAX: 9692d9a013a0 RBX:  RCX: 
9693032f2f90
[   88.018759] RDX: 9692e099cad8 RSI: 0070 RDI: 
9693058a7598
[   88.018761] RBP: 9692ed34f4e8 R08:  R09: 
6b6b6b6b6b6b6b6b
[   88.018762] R10: 6b6b6b6b6b6b6b6b R11: 9692e099cb80 R12: 
9693058a7598
[   88.018763] R13: 9693058a6fc8 R14: 0001 R15: 
c033dbc0
[   88.018765] FS:  7fc351843700() GS:969337b4() 
knlGS:
[   88.018767] CS:  0010 DS:  ES:  CR0: 80050033
[   88.018769] CR2: 7fa78adb08a0 CR3: 000206d56000 CR4: 
003406e0
[   88.018770] Call Trace:
[   88.018807]  amdgpu_vm_move_to_lru_tail+0xe1/0x100 [amdgpu]
[   88.018842]  amdgpu_cs_ioctl+0x14de/0x1ad0 [amdgpu]
[   88.018846]  ? __switch_to_asm+0x34/0x70
[   88.018881]  ? amdgpu_cs_find_mapping+0x110/0x110 [amdgpu]
[   88.018884]  drm_ioctl_kernel+0xa4/0xf0
[   88.018887]  drm_ioctl+0x1db/0x370
[   88.018921]  ? amdgpu_cs_find_mapping+0x110/0x110 [amdgpu]
[   88.018970]  amdgpu_drm_ioctl+0x44/0x80 [amdgpu]
[   88.018975]  do_vfs_ioctl+0x9f/0x610
[   88.018980]  ? __x64_sys_futex+0x137/0x180
[   88.018983]  ksys_ioctl+0x5b/0x90
[   88.018986]  __x64_sys_ioctl+0x11/0x20
[   88.018989]  do_syscall_64+0x43/0xf0
[   88.018992]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[   88.018995] RIP: 0033:0x7fc37a1b1c97
[   88.018997] Code: 00 00 90 48 8b 05 09 82 2c 00 64 c7 00 26 00 00 00 
48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 
05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d d9 81 2c 00 f7 d8 64 89 01 48
[   88.018999] RSP: 002b:7fc3518425d8 EFLAGS: 0202 ORIG_RAX: 
0010
[   88.019002] RAX: ffda RBX:  RCX: 
7fc37a1b1c97
[   88.019004] RDX: 7fc3518426b0 RSI: c0186444 RDI: 
000c
[   88.019005] RBP: 7fc351842610 R08: 7fc351842720 R09: 
7fc351842798
[   88.019007] R10:  R11: 0202 R12: 
7ffdf8dc068e
[   88.019009] R13: 7ffdf8dc068f R14: 7ffdf8dc0690 R15: 

[   88.019011] Modules linked in: fuse amdgpu mfd_core chash gpu_sched 
ttm ax88179_178a usbnet
[   88.019019] ---[ end trace dc532cd45c6dc064 ]---

Tom

> 
> Christian.
> 
> Am 30.01.19 um 13:06 schrieb Christian König:
>> Sorry I accidentally replied to the wrong mail.
>>
>> This is a new issue. Going to take a look now.
>>
>> Christian.
>>
>> Am 30.01.19 um 13:02 schrieb Christian König:
>>> This is a known issue, see here as well 
>>> https://bugs.freedesktop.org/show_bug.cgi?id=109487
>>>
>>> Christian.
>>>
>>> Am 30.01.19 um 12:07 schrieb Przemek Socha:
 Good morning,

 after last pull from the amd-staging-drm-next tree (29th of February) I 
 have
 random Oops on A6 6310 APU with r4 Mullins.

 Here is the Oops part of the log taken from pstore:

 <1>[   55.166270] BUG: unable to handle kernel NULL pointer dereference at
 0208
 <1>[   55.166281] #PF error: [normal kernel read fault]
 <6>[   55.166285] PGD 0 P4D 0
 <4>[   55.166293] Oops:  [#1] PREEMPT SMP
 <4>[   55.166301] CPU: 3 PID: 11006 Comm: kwin_x11:cs0 Not tainted 
 5.0.0-rc1+
 #44
 <4>[   55.166305] Hardware name: LENOVO 80E3/Lancer 5B2, BIOS 
 A2CN45WW(V2.13)
 08/04/2016
 <4>[   55.166320] RIP: 0010:ttm_bo_bulk_move_lru_tail+0xd3/0x188 [ttm]
 <4>[   55.166326] Code: 00 4c 8b 0a 48 8b 81 a8 00 00 00 48 81 c1 a8 00 00 
 00
 49 89 02 4c 8b 92 b0 00 00 00 4c 89 50 08 44 89 c0 48 c1 e0 04 4c 01 c8 
 <4c>
 8b 90 08 02 00 00 4d 89 1a 4c 8b 90 08 02 00 00 4c 89 92 b0 00
 <4>[   55.166330] RSP: 0018:a8bdc0f33b18 EFLAGS: 00010246
 <4>[   55.166335] RAX:  RBX:  RCX:
 9cfa935778f8
 <4>[   55.166339] RDX: 9cfa950c5050 RSI: 0070 RDI:
 9cfa93575dd0
 <4>[   55.166342] RBP: 9cfa5d44d800 R08:  R09:
 
 <4>[   55.166346] R10: 9cfa8f7730f8 R11: 9cfa950c50f8 R12: 
 

regression in dcn linked to -msse2

[StDenis, Tom]

Testing with the new 5.0.0-rc1 amd-staging-drm-next branch results in 
this commit causing the attached lockup on init with my Raven + Polaris 
system:

10117450735c7a7c0858095fb46a860e7037cb9a is the first bad commit
commit 10117450735c7a7c0858095fb46a860e7037cb9a
Author: ndesaulni...@google.com 
Date:   Thu Jan 24 16:52:59 2019 -0800

 drm/amd/display: add -msse2 to prevent Clang from emitting libcalls 
to undefined SW FP routines

 arch/x86/Makefile disables SSE and SSE2 for the whole kernel.  The
 AMDGPU drivers modified in this patch re-enable SSE but not SSE2.  Turn
 on SSE2 to support emitting double precision floating point 
instructions
 rather than calls to non-existent (usually available from gcc_s or
 compiler_rt) floating point helper routines.

 Link: 
https://gcc.gnu.org/onlinedocs/gccint/Soft-float-library-routines.html
 Link: https://github.com/ClangBuiltLinux/linux/issues/327
 Cc: sta...@vger.kernel.org # 4.19
 Reported-by: S, Shirish 
 Reported-by: Matthias Kaehlcke 
 Suggested-by: James Y Knight 
 Suggested-by: Nathan Chancellor 
 Signed-off-by: Nick Desaulniers 
 Tested-by: Guenter Roeck 
 Tested-by:  Matthias Kaehlcke 
 Tested-by: Nathan Chancellor 
 Reviewed-by: Harry Wentland 
 Signed-off-by: Harry Wentland 
 Signed-off-by: Alex Deucher 

:04 04 39f89ea177b8a69a3a2aa098aef8b1a7e58056b9 
71edb262be0608ffae0996253f47492b2e714b5c M  drivers


Cheers,
Tom


log.gz
Description: log.gz
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: After Vega 56/64 GPU hang I unable reboot system

[StDenis, Tom]

Hi Mike,

This might be an issue better suited for our llvm team since umr just 
uses llvm-dev to access the diassembly code.

I'll make sure the key folk are aware.

Cheers,
Tom


On 2019-01-10 10:22 a.m., Mikhail Gavrilov wrote:
> On Thu, 10 Jan 2019 at 00:36, Mikhail Gavrilov
>  wrote:
>>
>> All new one logs attached here.
>>
>> Thanks.
>>
>> P.S. This time I had to terminate command `./umr -O verbose,follow -R
>> gfx[.] > gfx.log 2>&1` cause it tried to write log infinitely.
>> I also had to terminate command `./umr -O verbose,follow -R gfx[.] >
>> gfx.log 2>&1` cause it stuck for a long time.
>>
>>
> 
> It became clear why umr stuck at the gfx dump. I ran umr under gdb and
> I got  a segfault at a moment when umr was stuck earlier.
> Tom, are you here? Can you look attached backtrace?
> 
> 
> --
> Best Regards,
> Mike Gavrilov.
> 

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH] add missing mutex lock to amdgpu_get_xgmi_hive() (v3)

[StDenis, Tom]

v2: Move locks around in other functions so that this
function can stand on its own.  Also only hold the hive
specific lock for add/remove device instead of the driver
global lock so you can't add/remove devices in parallel from
one hive.

v3: add reset_lock

Signed-off-by: Tom St Denis 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |  6 ++--
 drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c   | 41 ++
 drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.h   |  5 +--
 3 files changed, 33 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 39d5d058b2c7..1a558dc41ba6 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -3525,9 +3525,9 @@ int amdgpu_device_gpu_recover(struct amdgpu_device *adev,
 * by different nodes. No point also since the one node already 
executing
 * reset will also reset all the other nodes in the hive.
 */
-   hive = amdgpu_get_xgmi_hive(adev);
+   hive = amdgpu_get_xgmi_hive(adev, 0);
if (hive && adev->gmc.xgmi.num_physical_nodes > 1 &&
-   !mutex_trylock(>hive_lock))
+   !mutex_trylock(>reset_lock))
return 0;
 
/* Start with adev pre asic reset first for soft reset check.*/
@@ -3606,7 +3606,7 @@ int amdgpu_device_gpu_recover(struct amdgpu_device *adev,
}
 
if (hive && adev->gmc.xgmi.num_physical_nodes > 1)
-   mutex_unlock(>hive_lock);
+   mutex_unlock(>reset_lock);
 
if (r)
dev_info(adev->dev, "GPU reset end with ret = %d\n", r);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c
index 8a8bc60cb6b4..9e98ab8b1525 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c
@@ -40,26 +40,40 @@ void *amdgpu_xgmi_hive_try_lock(struct amdgpu_hive_info 
*hive)
return >device_list;
 }
 
-struct amdgpu_hive_info *amdgpu_get_xgmi_hive(struct amdgpu_device *adev)
+struct amdgpu_hive_info *amdgpu_get_xgmi_hive(struct amdgpu_device *adev, int 
lock)
 {
int i;
struct amdgpu_hive_info *tmp;
 
if (!adev->gmc.xgmi.hive_id)
return NULL;
+
+   mutex_lock(_mutex);
+
for (i = 0 ; i < hive_count; ++i) {
tmp = _hives[i];
-   if (tmp->hive_id == adev->gmc.xgmi.hive_id)
+   if (tmp->hive_id == adev->gmc.xgmi.hive_id) {
+   if (lock)
+   mutex_lock(>hive_lock);
+   mutex_unlock(_mutex);
return tmp;
+   }
}
-   if (i >= AMDGPU_MAX_XGMI_HIVE)
+   if (i >= AMDGPU_MAX_XGMI_HIVE) {
+   mutex_unlock(_mutex);
return NULL;
+   }
 
/* initialize new hive if not exist */
tmp = _hives[hive_count++];
tmp->hive_id = adev->gmc.xgmi.hive_id;
INIT_LIST_HEAD(>device_list);
mutex_init(>hive_lock);
+   mutex_init(>reset_lock);
+   if (lock)
+   mutex_lock(>hive_lock);
+
+   mutex_unlock(_mutex);
 
return tmp;
 }
@@ -111,8 +125,8 @@ int amdgpu_xgmi_add_device(struct amdgpu_device *adev)
return ret;
}
 
-   mutex_lock(_mutex);
-   hive = amdgpu_get_xgmi_hive(adev);
+   /* find hive and take lock */
+   hive = amdgpu_get_xgmi_hive(adev, 1);
if (!hive)
goto exit;
 
@@ -142,8 +156,8 @@ int amdgpu_xgmi_add_device(struct amdgpu_device *adev)
break;
}
 
+   mutex_unlock(>hive_lock);
 exit:
-   mutex_unlock(_mutex);
return ret;
 }
 
@@ -154,15 +168,14 @@ void amdgpu_xgmi_remove_device(struct amdgpu_device *adev)
if (!adev->gmc.xgmi.supported)
return;
 
-   mutex_lock(_mutex);
-
-   hive = amdgpu_get_xgmi_hive(adev);
+   hive = amdgpu_get_xgmi_hive(adev, 1);
if (!hive)
-   goto exit;
+   return;
 
-   if (!(hive->number_devices--))
+   if (!(hive->number_devices--)) {
mutex_destroy(>hive_lock);
-
-exit:
-   mutex_unlock(_mutex);
+   mutex_destroy(>reset_lock);
+   } else {
+   mutex_unlock(>hive_lock);
+   }
 }
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.h
index 6151eb9c8ad3..14bc60664159 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.h
@@ -29,10 +29,11 @@ struct amdgpu_hive_info {
struct list_headdevice_list;
struct psp_xgmi_topology_info   topology_info;
int number_devices;
-   struct mutex hive_lock;
+   struct mutex hive_lock,
+reset_lock;
 };
 
-struct amdgpu_hive_info *amdgpu_get_xgmi_hive(struct amdgpu_device *adev);
+struct amdgpu_hive_info 

Re: [PATCH] add missing mutex lock to amdgpu_get_xgmi_hive() (v2)

[StDenis, Tom]

On 2019-01-07 12:00 p.m., Grodzovsky, Andrey wrote:
> 
> 
> On 01/07/2019 11:53 AM, StDenis, Tom wrote:
>> On 2019-01-07 11:51 a.m., Grodzovsky, Andrey wrote:
>>>
>>> On 01/07/2019 11:36 AM, StDenis, Tom wrote:
>>>> On 2019-01-07 11:33 a.m., Grodzovsky, Andrey wrote:
>>>>> On 01/07/2019 11:16 AM, Liu, Shaoyun wrote:
>>>>>> I think it's reasonable to use the hive  specific lock for hive  
>>>>>> specific functions.
>>>>>> The changes is acked-by  Shaoyun.liu < shaoyun@amd.com>
>>>>>>
>>>>>> -Original Message-
>>>>>> From: amd-gfx  On Behalf Of 
>>>>>> StDenis, Tom
>>>>>> Sent: Monday, January 7, 2019 10:16 AM
>>>>>> To: amd-gfx@lists.freedesktop.org
>>>>>> Cc: StDenis, Tom 
>>>>>> Subject: [PATCH] add missing mutex lock to amdgpu_get_xgmi_hive() (v2)
>>>>>>
>>>>>> v2: Move locks around in other functions so that this function can stand 
>>>>>> on its own.  Also only hold the hive specific lock for add/remove device 
>>>>>> instead of the driver global lock so you can't add/remove devices in 
>>>>>> parallel from one hive.
>>>>>>
>>>>>> Signed-off-by: Tom St Denis 
>>>>>> ---
>>>>>>drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |  2 +-
>>>>>>drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c   | 36 
>>>>>> ++
>>>>>>drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.h   |  2 +-
>>>>>>3 files changed, 25 insertions(+), 15 deletions(-)
>>>>>>
>>>>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
>>>>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>>>>>> index 39d5d058b2c7..13d8e2ad2f7a 100644
>>>>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>>>>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>>>>>> @@ -3525,7 +3525,7 @@ int amdgpu_device_gpu_recover(struct amdgpu_device 
>>>>>> *adev,
>>>>>>   * by different nodes. No point also since the one node already 
>>>>>> executing
>>>>>>   * reset will also reset all the other nodes in the hive.
>>>>>>   */
>>>>>> -hive = amdgpu_get_xgmi_hive(adev);
>>>>>> +hive = amdgpu_get_xgmi_hive(adev, 0);
>>>>>>  if (hive && adev->gmc.xgmi.num_physical_nodes > 1 &&
>>>>>>  !mutex_trylock(>hive_lock))
>>>>>>  return 0;
>>>>> Let's say i have device 0 in hive A and it just got a gpu reset and at
>>>>> the same time device 1 is being added to same have though
>>>>> amdgpu_xgmi_add_device, hive->hive_lock is acquired by this new device
>>>>> being added and so gpu reset for device 0 bails out on
>>>>> '!mutex_trylock(>hive_lock))' without completing the reset.
>>>>> Also in general i feel a bit uncomfortable about the confusing
>>>>> acquisition scheme in the function and  the fact that you take the
>>>>> hive->hive_lock inside amdgpu_get_xgmi_hive but release is still outside
>>>>> of the function.
>>>> Is adding a device while resetting a device even a valid operation
>>>> anyways?
>>> In theory it's valid if you have hot pluggable devices
>>>> I think this means more so that the reset logic is broken.  Instead
>>>> there should be a per-hive reset lock that is taken and that is tested
>>>> instead.
>>>>
>>>> Tom
>>> The hive->hive_lock was added exactly for this purpose and used only for
>>> that purpose. Maybe the naming i gave it wasn't reflective of it's
>>> purpose :)
>>
>> But the add/remove should use per-hive locks not the global lock... :-)
>>
>> (I'm honestly not trying to bike shed I just thought the get_hive
>> function looked wrong :-)).
>>
>> Tom
> 
> Totally agree with you, if Shayun (who origianlly added the global
> xgmi_mutex) is fine with switching to per hive mutex then me too, I just
> point out the problem with gpu reset and as you said we then need to
> rename the existing hive_lock into reset_lock and then and another per
> hive lock to do what you propose. Also - is there a way to not take the
> hive lock inside amdgpu_get_xgmi_hive but release it outside ? AFAIK
> it's an opening for problems where people use it but forget to call
> release.

I wanted to take the per-hive lock inside get_hive because it also takes 
the global lock so that add/remove couldn't happen in parallel.

For instance, deleting the last node while adding a new node means the 
per-hive mutex could be in limbo (because remove will delete the lock).

Adding a per-hive reset lock would fix the remaining issues no?

Tom
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] add missing mutex lock to amdgpu_get_xgmi_hive() (v2)

[StDenis, Tom]

On 2019-01-07 11:51 a.m., Grodzovsky, Andrey wrote:
> 
> 
> On 01/07/2019 11:36 AM, StDenis, Tom wrote:
>> On 2019-01-07 11:33 a.m., Grodzovsky, Andrey wrote:
>>>
>>> On 01/07/2019 11:16 AM, Liu, Shaoyun wrote:
>>>> I think it's reasonable to use the hive  specific lock for hive  specific 
>>>> functions.
>>>> The changes is acked-by  Shaoyun.liu < shaoyun@amd.com>
>>>>
>>>> -Original Message-
>>>> From: amd-gfx  On Behalf Of 
>>>> StDenis, Tom
>>>> Sent: Monday, January 7, 2019 10:16 AM
>>>> To: amd-gfx@lists.freedesktop.org
>>>> Cc: StDenis, Tom 
>>>> Subject: [PATCH] add missing mutex lock to amdgpu_get_xgmi_hive() (v2)
>>>>
>>>> v2: Move locks around in other functions so that this function can stand 
>>>> on its own.  Also only hold the hive specific lock for add/remove device 
>>>> instead of the driver global lock so you can't add/remove devices in 
>>>> parallel from one hive.
>>>>
>>>> Signed-off-by: Tom St Denis 
>>>> ---
>>>>  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |  2 +-
>>>>  drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c   | 36 ++
>>>>  drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.h   |  2 +-
>>>>  3 files changed, 25 insertions(+), 15 deletions(-)
>>>>
>>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
>>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>>>> index 39d5d058b2c7..13d8e2ad2f7a 100644
>>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>>>> @@ -3525,7 +3525,7 @@ int amdgpu_device_gpu_recover(struct amdgpu_device 
>>>> *adev,
>>>> * by different nodes. No point also since the one node already 
>>>> executing
>>>> * reset will also reset all the other nodes in the hive.
>>>> */
>>>> -  hive = amdgpu_get_xgmi_hive(adev);
>>>> +  hive = amdgpu_get_xgmi_hive(adev, 0);
>>>>if (hive && adev->gmc.xgmi.num_physical_nodes > 1 &&
>>>>!mutex_trylock(>hive_lock))
>>>>return 0;
>>> Let's say i have device 0 in hive A and it just got a gpu reset and at
>>> the same time device 1 is being added to same have though
>>> amdgpu_xgmi_add_device, hive->hive_lock is acquired by this new device
>>> being added and so gpu reset for device 0 bails out on
>>> '!mutex_trylock(>hive_lock))' without completing the reset.
>>> Also in general i feel a bit uncomfortable about the confusing
>>> acquisition scheme in the function and  the fact that you take the
>>> hive->hive_lock inside amdgpu_get_xgmi_hive but release is still outside
>>> of the function.
>> Is adding a device while resetting a device even a valid operation
>> anyways?
> 
> In theory it's valid if you have hot pluggable devices
>>
>> I think this means more so that the reset logic is broken.  Instead
>> there should be a per-hive reset lock that is taken and that is tested
>> instead.
>>
>> Tom
> 
> The hive->hive_lock was added exactly for this purpose and used only for
> that purpose. Maybe the naming i gave it wasn't reflective of it's
> purpose :)


But the add/remove should use per-hive locks not the global lock... :-)

(I'm honestly not trying to bike shed I just thought the get_hive 
function looked wrong :-)).

Tom
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] add missing mutex lock to amdgpu_get_xgmi_hive() (v2)

[StDenis, Tom]

On 2019-01-07 11:33 a.m., Grodzovsky, Andrey wrote:
> 
> 
> On 01/07/2019 11:16 AM, Liu, Shaoyun wrote:
>> I think it's reasonable to use the hive  specific lock for hive  specific 
>> functions.
>> The changes is acked-by  Shaoyun.liu < shaoyun@amd.com>
>>
>> -Original Message-
>> From: amd-gfx  On Behalf Of StDenis, 
>> Tom
>> Sent: Monday, January 7, 2019 10:16 AM
>> To: amd-gfx@lists.freedesktop.org
>> Cc: StDenis, Tom 
>> Subject: [PATCH] add missing mutex lock to amdgpu_get_xgmi_hive() (v2)
>>
>> v2: Move locks around in other functions so that this function can stand on 
>> its own.  Also only hold the hive specific lock for add/remove device 
>> instead of the driver global lock so you can't add/remove devices in 
>> parallel from one hive.
>>
>> Signed-off-by: Tom St Denis 
>> ---
>>drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |  2 +-
>>drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c   | 36 ++
>>drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.h   |  2 +-
>>3 files changed, 25 insertions(+), 15 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>> index 39d5d058b2c7..13d8e2ad2f7a 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>> @@ -3525,7 +3525,7 @@ int amdgpu_device_gpu_recover(struct amdgpu_device 
>> *adev,
>>   * by different nodes. No point also since the one node already 
>> executing
>>   * reset will also reset all the other nodes in the hive.
>>   */
>> -hive = amdgpu_get_xgmi_hive(adev);
>> +hive = amdgpu_get_xgmi_hive(adev, 0);
>>  if (hive && adev->gmc.xgmi.num_physical_nodes > 1 &&
>>  !mutex_trylock(>hive_lock))
>>  return 0;
> 
> Let's say i have device 0 in hive A and it just got a gpu reset and at
> the same time device 1 is being added to same have though
> amdgpu_xgmi_add_device, hive->hive_lock is acquired by this new device
> being added and so gpu reset for device 0 bails out on
> '!mutex_trylock(>hive_lock))' without completing the reset.
> Also in general i feel a bit uncomfortable about the confusing
> acquisition scheme in the function and  the fact that you take the
> hive->hive_lock inside amdgpu_get_xgmi_hive but release is still outside
> of the function.

Is adding a device while resetting a device even a valid operation 
anyways?

I think this means more so that the reset logic is broken.  Instead 
there should be a per-hive reset lock that is taken and that is tested 
instead.

Tom


> 
> Andrey
> 
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c 
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c
>> index 8a8bc60cb6b4..ebf50809485f 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c
>> @@ -40,26 +40,39 @@ void *amdgpu_xgmi_hive_try_lock(struct amdgpu_hive_info 
>> *hive)
>>  return >device_list;
>>}
>>
>> -struct amdgpu_hive_info *amdgpu_get_xgmi_hive(struct amdgpu_device *adev)
>> +struct amdgpu_hive_info *amdgpu_get_xgmi_hive(struct amdgpu_device
>> +*adev, int lock)
>>{
>>  int i;
>>  struct amdgpu_hive_info *tmp;
>>
>>  if (!adev->gmc.xgmi.hive_id)
>>  return NULL;
>> +
>> +mutex_lock(_mutex);
>> +
>>  for (i = 0 ; i < hive_count; ++i) {
>>  tmp = _hives[i];
>> -if (tmp->hive_id == adev->gmc.xgmi.hive_id)
>> +if (tmp->hive_id == adev->gmc.xgmi.hive_id) {
>> +if (lock)
>> +mutex_lock(>hive_lock);
>> +mutex_unlock(_mutex);
>>  return tmp;
>> +}
>>  }
>> -if (i >= AMDGPU_MAX_XGMI_HIVE)
>> +if (i >= AMDGPU_MAX_XGMI_HIVE) {
>> +mutex_unlock(_mutex);
>>  return NULL;
>> +}
>>
>>  /* initialize new hive if not exist */
>>  tmp = _hives[hive_count++];
>>  tmp->hive_id = adev->gmc.xgmi.hive_id;
>>  INIT_LIST_HEAD(>device_list);
>>  mutex_init(>hive_lock);
>> +if (lock)
>> +mutex_lock(>hive_lock);
>> +
>> +mutex_unlock(_mutex);
>>
>>  return tmp;
>>}
>> @@ -111,8 +124,8 @@ int amdgpu_xgmi_add_device(struct amdgpu_device *adev)
>>  

[PATCH] add missing mutex lock to amdgpu_get_xgmi_hive() (v2)

[StDenis, Tom]

v2: Move locks around in other functions so that this
function can stand on its own.  Also only hold the hive
specific lock for add/remove device instead of the driver
global lock so you can't add/remove devices in parallel from
one hive.

Signed-off-by: Tom St Denis 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |  2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c   | 36 ++
 drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.h   |  2 +-
 3 files changed, 25 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 39d5d058b2c7..13d8e2ad2f7a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -3525,7 +3525,7 @@ int amdgpu_device_gpu_recover(struct amdgpu_device *adev,
 * by different nodes. No point also since the one node already 
executing
 * reset will also reset all the other nodes in the hive.
 */
-   hive = amdgpu_get_xgmi_hive(adev);
+   hive = amdgpu_get_xgmi_hive(adev, 0);
if (hive && adev->gmc.xgmi.num_physical_nodes > 1 &&
!mutex_trylock(>hive_lock))
return 0;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c
index 8a8bc60cb6b4..ebf50809485f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c
@@ -40,26 +40,39 @@ void *amdgpu_xgmi_hive_try_lock(struct amdgpu_hive_info 
*hive)
return >device_list;
 }
 
-struct amdgpu_hive_info *amdgpu_get_xgmi_hive(struct amdgpu_device *adev)
+struct amdgpu_hive_info *amdgpu_get_xgmi_hive(struct amdgpu_device *adev, int 
lock)
 {
int i;
struct amdgpu_hive_info *tmp;
 
if (!adev->gmc.xgmi.hive_id)
return NULL;
+
+   mutex_lock(_mutex);
+
for (i = 0 ; i < hive_count; ++i) {
tmp = _hives[i];
-   if (tmp->hive_id == adev->gmc.xgmi.hive_id)
+   if (tmp->hive_id == adev->gmc.xgmi.hive_id) {
+   if (lock)
+   mutex_lock(>hive_lock);
+   mutex_unlock(_mutex);
return tmp;
+   }
}
-   if (i >= AMDGPU_MAX_XGMI_HIVE)
+   if (i >= AMDGPU_MAX_XGMI_HIVE) {
+   mutex_unlock(_mutex);
return NULL;
+   }
 
/* initialize new hive if not exist */
tmp = _hives[hive_count++];
tmp->hive_id = adev->gmc.xgmi.hive_id;
INIT_LIST_HEAD(>device_list);
mutex_init(>hive_lock);
+   if (lock)
+   mutex_lock(>hive_lock);
+
+   mutex_unlock(_mutex);
 
return tmp;
 }
@@ -111,8 +124,8 @@ int amdgpu_xgmi_add_device(struct amdgpu_device *adev)
return ret;
}
 
-   mutex_lock(_mutex);
-   hive = amdgpu_get_xgmi_hive(adev);
+   /* find hive and take lock */
+   hive = amdgpu_get_xgmi_hive(adev, 1);
if (!hive)
goto exit;
 
@@ -142,8 +155,8 @@ int amdgpu_xgmi_add_device(struct amdgpu_device *adev)
break;
}
 
+   mutex_unlock(>hive_lock);
 exit:
-   mutex_unlock(_mutex);
return ret;
 }
 
@@ -154,15 +167,12 @@ void amdgpu_xgmi_remove_device(struct amdgpu_device *adev)
if (!adev->gmc.xgmi.supported)
return;
 
-   mutex_lock(_mutex);
-
-   hive = amdgpu_get_xgmi_hive(adev);
+   hive = amdgpu_get_xgmi_hive(adev, 1);
if (!hive)
-   goto exit;
+   return;
 
if (!(hive->number_devices--))
mutex_destroy(>hive_lock);
-
-exit:
-   mutex_unlock(_mutex);
+   else
+   mutex_unlock(>hive_lock);
 }
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.h
index 6151eb9c8ad3..8d7984844174 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.h
@@ -32,7 +32,7 @@ struct amdgpu_hive_info {
struct mutex hive_lock;
 };
 
-struct amdgpu_hive_info *amdgpu_get_xgmi_hive(struct amdgpu_device *adev);
+struct amdgpu_hive_info *amdgpu_get_xgmi_hive(struct amdgpu_device *adev, int 
lock);
 int amdgpu_xgmi_update_topology(struct amdgpu_hive_info *hive, struct 
amdgpu_device *adev);
 int amdgpu_xgmi_add_device(struct amdgpu_device *adev);
 void amdgpu_xgmi_remove_device(struct amdgpu_device *adev);
-- 
2.17.2

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] add missing mutex lock to amdgpu_get_xgmi_hive()

[StDenis, Tom]

Self NAK this ... calling functions take the same lock

We should remove the locks from the callers so this function is thread 
safe on its own...

Tom


On 2019-01-07 10:00 a.m., StDenis, Tom wrote:
> Signed-off-by: Tom St Denis 
> ---
>   drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c | 13 +++--
>   1 file changed, 11 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c
> index 8a8bc60cb6b4..587a5f73ae8c 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c
> @@ -47,13 +47,20 @@ struct amdgpu_hive_info *amdgpu_get_xgmi_hive(struct 
> amdgpu_device *adev)
>   
>   if (!adev->gmc.xgmi.hive_id)
>   return NULL;
> +
> + mutex_lock(_mutex);
> +
>   for (i = 0 ; i < hive_count; ++i) {
>   tmp = _hives[i];
> - if (tmp->hive_id == adev->gmc.xgmi.hive_id)
> + if (tmp->hive_id == adev->gmc.xgmi.hive_id) {
> + mutex_unlock(_mutex);
>   return tmp;
> + }
>   }
> - if (i >= AMDGPU_MAX_XGMI_HIVE)
> + if (i >= AMDGPU_MAX_XGMI_HIVE) {
> + mutex_unlock(_mutex);
>   return NULL;
> + }
>   
>   /* initialize new hive if not exist */
>   tmp = _hives[hive_count++];
> @@ -61,6 +68,8 @@ struct amdgpu_hive_info *amdgpu_get_xgmi_hive(struct 
> amdgpu_device *adev)
>   INIT_LIST_HEAD(>device_list);
>   mutex_init(>hive_lock);
>   
> + mutex_unlock(_mutex);
> +
>   return tmp;
>   }
>   
> 

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH] add missing mutex lock to amdgpu_get_xgmi_hive()

[StDenis, Tom]

Signed-off-by: Tom St Denis 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c | 13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c
index 8a8bc60cb6b4..587a5f73ae8c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c
@@ -47,13 +47,20 @@ struct amdgpu_hive_info *amdgpu_get_xgmi_hive(struct 
amdgpu_device *adev)
 
if (!adev->gmc.xgmi.hive_id)
return NULL;
+
+   mutex_lock(_mutex);
+
for (i = 0 ; i < hive_count; ++i) {
tmp = _hives[i];
-   if (tmp->hive_id == adev->gmc.xgmi.hive_id)
+   if (tmp->hive_id == adev->gmc.xgmi.hive_id) {
+   mutex_unlock(_mutex);
return tmp;
+   }
}
-   if (i >= AMDGPU_MAX_XGMI_HIVE)
+   if (i >= AMDGPU_MAX_XGMI_HIVE) {
+   mutex_unlock(_mutex);
return NULL;
+   }
 
/* initialize new hive if not exist */
tmp = _hives[hive_count++];
@@ -61,6 +68,8 @@ struct amdgpu_hive_info *amdgpu_get_xgmi_hive(struct 
amdgpu_device *adev)
INIT_LIST_HEAD(>device_list);
mutex_init(>hive_lock);
 
+   mutex_unlock(_mutex);
+
return tmp;
 }
 
-- 
2.17.2

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: After Vega 56/64 GPU hang I unable reboot system

[StDenis, Tom]

On 2018-12-20 11:07 a.m., Mikhail Gavrilov wrote:
> On Thu, 20 Dec 2018 at 19:19, StDenis, Tom  wrote:
>>
>> Ya I was right.  With a plain build I can access the files just fine.
>>
>>
>>
>> I did manage to get into a weird shell where I couldn't cat
>> amdgpu_gca_config from bash though after a reboot (had updates pending)
>> it works fine.
>>
>> If you can't cat those files then neither can umr.
>>
>> So NOTABUG :-)
>>
> 
> I am very happy for you. But what about me?
> I don't have idea how make this files available on my system.
> And of course I tried reboot and try again cat amdgpu_gca_config
> several times but all times without success.

Sorry I didn't mean to be dismissive.  It's just not a bug in umr though.

On Fedora I can access those files as root just fine:

tom@fx8:~$ sudo bash
[sudo] password for tom:
root@fx8:/home/tom# cd /sys/kernel/debug/dri/0
root@fx8:/sys/kernel/debug/dri/0# xxd -e amdgpu_gca_config
: 0003 0001 0004 000b  
0010: 0001 0002 0004 0100  
0020: 0020 0008 0020 0100   ... ...
0030: 0030 04c0  0003  0...
0040:      
0050:   2442 0002  B..$
0060: 0001 4100 017f9fcf 008e  .A..
0070: 0001 15dd 00c6 d000  
0080: 1458 X...
root@fx8:/sys/kernel/debug/dri/0#

There must be some sort of ACL or something going on here.

Tom

> 
> Also I note that not all files not permitted for read from
> /sys/kernel/debug/dri/0/*
> I was able to dump contents of some files in debugfs.txt (see attachments)
> List of available for readind files:
> amdgpu_evict_gtt
> amdgpu_evict_vram
> amdgpu_fence_info
> amdgpu_firmware_info
> amdgpu_gds_mm
> amdgpu_gem_info
> amdgpu_gpu_recover
> amdgpu_gtt_mm
> amdgpu_gws_mm
> amdgpu_oa_mm
> amdgpu_pm_info
> amdgpu_sa_info
> amdgpu_test_ib
> amdgpu_vbios
> amdgpu_vram_mm
> clients
> framebuffer
> gem_names
> internal_clients
> name
> state
> ttm_page_pool
> 
> May some kernel options restrict access for files in debugfs (for
> example to amdgpu_gca_config)?
> If yes on which options should I pay attention?
> I have no more ideas. I tried everything.
> 
> 
> 
> 
> --
> Best Regards,
> Mike Gavrilov.
> 

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: After Vega 56/64 GPU hang I unable reboot system

[StDenis, Tom]

On 2018-12-20 9:08 a.m., Tom St Denis wrote:
> On 2018-12-20 9:06 a.m., Tom St Denis wrote:
>> On 2018-12-20 6:45 a.m., Mikhail Gavrilov wrote:
>>> On Thu, 20 Dec 2018 at 16:17, StDenis, Tom  wrote:
>>>>
>>>> Well yup the kernel is not letting you open the files:
>>>>
>>>>
>>>> As sudo/root you should be able to open these files with umr.  What
>>>> happens if you just open a shell as root and run it?
>>>>
>>>
>>> [root@localhost ~]# touch /sys/kernel/debug/dri/0/amdgpu_ring_gfx
>>> [root@localhost ~]# cat /sys/kernel/debug/dri/0/amdgpu_ring_gfx
>>> cat: /sys/kernel/debug/dri/0/amdgpu_ring_gfx: Operation not permitted
>>> [root@localhost ~]# ls -laZ /sys/kernel/debug/dri/0/amdgpu_ring_gfx
>>> -r--r--r--. 1 root root system_u:object_r:debugfs_t:s0 8204 Dec 20
>>> 16:31 /sys/kernel/debug/dri/0/amdgpu_ring_gfx
>>> [root@localhost ~]# getenforce
>>> Permissive
>>> [root@localhost ~]# /home/mikhail/packaging-work/umr/build/src/app/umr
>>> -O verbose,halt_waves -wa
>>> Cannot seek to MMIO address: Bad file descriptor
>>> [ERROR]: Could not open ring debugfs fileSegmentation fault (core 
>>> dumped)
>>>
>>> I am already tried launch `umr` under root user, but kernel don't let
>>> open `amdgpu_ring_gfx` again.
>>>
>>> What else kernel options I should to check?
>>>
>>> I am also attached current kernel config to this message.
>>
>> I can replicate this by doing
>>
>> chmod u+s umr
>> sudo ./umr -R gfx[.]
>>
>> You need to remove the u+s bit you are literally not running umr as root!
> 
> Actually disregard that.  I'm confused at this point.
> 
> I run umr 100s of times a day on my devel box just fine as root.
> 
> Let me fiddle and see if I can sort this out.


Ya I was right.  With a plain build I can access the files just fine.

tom@fx8:~/stuff/public/umr/src/app $ stat ./umr
   File: ./umr
   Size: 89204248   Blocks: 174240 IO Block: 4096   regular file
Device: fd01h/64769dInode: 14946407Links: 1
Access: (0775/-rwxrwxr-x)  Uid: ( 1000/ tom)   Gid: ( 1000/ tom)
Access: 2018-12-20 09:15:03.348320256 -0500
Modify: 2018-12-20 09:05:48.148724423 -0500
Change: 2018-12-20 09:14:43.964948557 -0500
  Birth: -
tom@fx8:~/stuff/public/umr/src/app $ sudo ./umr -R gfx[.]

raven1.gfx.rptr == 768
raven1.gfx.wptr == 768
raven1.gfx.drv_wptr == 768
raven1.gfx.ring[ 737] == 0x1000...
raven1.gfx.ring[ 738] == 0x1000...
raven1.gfx.ring[ 739] == 0x1000...
raven1.gfx.ring[ 740] == 0x1000...
raven1.gfx.ring[ 741] == 0x1000...
raven1.gfx.ring[ 742] == 0x1000...
raven1.gfx.ring[ 743] == 0x1000...
raven1.gfx.ring[ 744] == 0x1000...
raven1.gfx.ring[ 745] == 0x1000...
raven1.gfx.ring[ 746] == 0x1000...
raven1.gfx.ring[ 747] == 0x1000...
raven1.gfx.ring[ 748] == 0x1000...
raven1.gfx.ring[ 749] == 0x1000...
raven1.gfx.ring[ 750] == 0x1000...
raven1.gfx.ring[ 751] == 0x1000...
raven1.gfx.ring[ 752] == 0x1000...
raven1.gfx.ring[ 753] == 0x1000...
raven1.gfx.ring[ 754] == 0x1000...
raven1.gfx.ring[ 755] == 0x1000...
raven1.gfx.ring[ 756] == 0x1000...
raven1.gfx.ring[ 757] == 0x1000...
raven1.gfx.ring[ 758] == 0x1000...
raven1.gfx.ring[ 759] == 0x1000...
raven1.gfx.ring[ 760] == 0x1000...
raven1.gfx.ring[ 761] == 0x1000...
raven1.gfx.ring[ 762] == 0x1000...
raven1.gfx.ring[ 763] == 0x1000...
raven1.gfx.ring[ 764] == 0x1000...
raven1.gfx.ring[ 765] == 0x1000...
raven1.gfx.ring[ 766] == 0x1000...
raven1.gfx.ring[ 767] == 0x1000...
raven1.gfx.ring[ 768] == 0xc0032200rwD


I did manage to get into a weird shell where I couldn't cat 
amdgpu_gca_config from bash though after a reboot (had updates pending) 
it works fine.

If you can't cat those files then neither can umr.

So NOTABUG :-)

Tom
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: After Vega 56/64 GPU hang I unable reboot system

[StDenis, Tom]

On 2018-12-20 9:06 a.m., Tom St Denis wrote:
> On 2018-12-20 6:45 a.m., Mikhail Gavrilov wrote:
>> On Thu, 20 Dec 2018 at 16:17, StDenis, Tom  wrote:
>>>
>>> Well yup the kernel is not letting you open the files:
>>>
>>>
>>> As sudo/root you should be able to open these files with umr.  What
>>> happens if you just open a shell as root and run it?
>>>
>>
>> [root@localhost ~]# touch /sys/kernel/debug/dri/0/amdgpu_ring_gfx
>> [root@localhost ~]# cat /sys/kernel/debug/dri/0/amdgpu_ring_gfx
>> cat: /sys/kernel/debug/dri/0/amdgpu_ring_gfx: Operation not permitted
>> [root@localhost ~]# ls -laZ /sys/kernel/debug/dri/0/amdgpu_ring_gfx
>> -r--r--r--. 1 root root system_u:object_r:debugfs_t:s0 8204 Dec 20
>> 16:31 /sys/kernel/debug/dri/0/amdgpu_ring_gfx
>> [root@localhost ~]# getenforce
>> Permissive
>> [root@localhost ~]# /home/mikhail/packaging-work/umr/build/src/app/umr
>> -O verbose,halt_waves -wa
>> Cannot seek to MMIO address: Bad file descriptor
>> [ERROR]: Could not open ring debugfs fileSegmentation fault (core dumped)
>>
>> I am already tried launch `umr` under root user, but kernel don't let
>> open `amdgpu_ring_gfx` again.
>>
>> What else kernel options I should to check?
>>
>> I am also attached current kernel config to this message.
> 
> I can replicate this by doing
> 
> chmod u+s umr
> sudo ./umr -R gfx[.]
> 
> You need to remove the u+s bit you are literally not running umr as root!

Actually disregard that.  I'm confused at this point.

I run umr 100s of times a day on my devel box just fine as root.

Let me fiddle and see if I can sort this out.

Tom
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: After Vega 56/64 GPU hang I unable reboot system

[StDenis, Tom]

On 2018-12-20 6:45 a.m., Mikhail Gavrilov wrote:
> On Thu, 20 Dec 2018 at 16:17, StDenis, Tom  wrote:
>>
>> Well yup the kernel is not letting you open the files:
>>
>>
>> As sudo/root you should be able to open these files with umr.  What
>> happens if you just open a shell as root and run it?
>>
> 
> [root@localhost ~]# touch /sys/kernel/debug/dri/0/amdgpu_ring_gfx
> [root@localhost ~]# cat /sys/kernel/debug/dri/0/amdgpu_ring_gfx
> cat: /sys/kernel/debug/dri/0/amdgpu_ring_gfx: Operation not permitted
> [root@localhost ~]# ls -laZ /sys/kernel/debug/dri/0/amdgpu_ring_gfx
> -r--r--r--. 1 root root system_u:object_r:debugfs_t:s0 8204 Dec 20
> 16:31 /sys/kernel/debug/dri/0/amdgpu_ring_gfx
> [root@localhost ~]# getenforce
> Permissive
> [root@localhost ~]# /home/mikhail/packaging-work/umr/build/src/app/umr
> -O verbose,halt_waves -wa
> Cannot seek to MMIO address: Bad file descriptor
> [ERROR]: Could not open ring debugfs fileSegmentation fault (core dumped)
> 
> I am already tried launch `umr` under root user, but kernel don't let
> open `amdgpu_ring_gfx` again.
> 
> What else kernel options I should to check?
> 
> I am also attached current kernel config to this message.

I can replicate this by doing

chmod u+s umr
sudo ./umr -R gfx[.]

You need to remove the u+s bit you are literally not running umr as root!

:-)

Tom


> 
> --
> Best Regards,
> Mike Gavrilov.
> 

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: After Vega 56/64 GPU hang I unable reboot system

[StDenis, Tom]

On 2018-12-19 4:21 p.m., Mikhail Gavrilov wrote:
> I see that backtrace in my previous message are borked.
> I place backtrace in text file for more comfort reading in this message.

The backtrace points to the segfault in umr caused when it fails to read 
the file.  We want to know why it can't open the file.  Something like

sudo strace umr -R gfx[.] 2>&1 | tee strace.log

will capture everything.

In the mean time I can fix at least the segfault.

The issue is why can't it open "amdgpu_ring_gfx".

Tom

> 
> 
> --
> Best Regards,
> Mike Gavrilov.
> 

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: After Vega 56/64 GPU hang I unable reboot system

[StDenis, Tom]

No gfx ring? You can specify a ring name for --waves should be in the docs.

It's not on the web docs but in the help text

https://cgit.freedesktop.org/amd/umr/tree/src/app/main.c#n643

I'll fix the web docs when I'm in next.

Tom

On December 19, 2018 3:21:25 PM EST, "Grodzovsky, Andrey" 
 wrote:

+Tom

Andrey


On 12/19/2018 01:35 PM, Mikhail Gavrilov wrote:
On Tue, 18 Dec 2018 at 00:08, Grodzovsky, Andrey
 wrote:
 Please install UMR and dump gfx ring content and waves after the hang is
 happening.

 UMR at - https://cgit.freedesktop.org/amd/umr/
 Waves dump
 sudo umr -O verbose,halt_waves -wa
 GFX ring dump
 sudo umr -O verbose,follow -R gfx[.]

 Andrey

 Thanks for respond.

 What options should I specify in kernel command line?

 On my setup `umr` terminated with message `Could not open ring debugfs
 file` and crashes. But I am sure that debugfs enabled.

 $ sudo umr -O verbose,halt_waves -wa
 Cannot seek to MMIO address: Bad file descriptor
 [ERROR]: Could not open ring debugfs fileSegmentation fault


 # ls /sys/kernel/debug/dri/0/
   amdgpu_dm_dtn_logamdgpu_ring_comp_1.1.0 amdgpu_vram_mm
   amdgpu_evict_gtt amdgpu_ring_comp_1.1.1 amdgpu_wave
   amdgpu_evict_vramamdgpu_ring_comp_1.2.0 clients
   amdgpu_fence_infoamdgpu_ring_comp_1.2.1 crtc-0
   amdgpu_firmware_info amdgpu_ring_comp_1.3.0 crtc-1
   amdgpu_gca_configamdgpu_ring_comp_1.3.1 crtc-2
   amdgpu_gds_mmamdgpu_ring_gfxcrtc-3
   amdgpu_gem_info  amdgpu_ring_kiq_2.1.0  crtc-4
   amdgpu_gpr   amdgpu_ring_sdma0  crtc-5
   amdgpu_gpu_recover   amdgpu_ring_sdma1  DP-1
   amdgpu_gtt_mm   'amdgpu_ring_uvd<0>'DP-2
   amdgpu_gws_mm   'amdgpu_ring_uvd_enc0<0>'   DP-3
   amdgpu_iomem'amdgpu_ring_uvd_enc1<0>'   framebuffer
   amdgpu_oa_mm amdgpu_ring_vce0   gem_names
   amdgpu_pm_info   amdgpu_ring_vce1   HDMI-A-1
   amdgpu_regs  amdgpu_ring_vce2   HDMI-A-2
   amdgpu_regs_didt amdgpu_sa_info HDMI-A-3
   amdgpu_regs_pcie amdgpu_sensors internal_clients
   amdgpu_regs_smc  amdgpu_test_ib name
   amdgpu_ring_comp_1.0.0   amdgpu_vbios   state
   amdgpu_ring_comp_1.0.1   amdgpu_vramttm_page_pool




 --
 Best Regards,
 Mike Gavrilov.

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

amdkfd build regression if HSA_AMD is disabled

[StDenis, Tom]

Hi All,

The commit:

commit 62f65d3cb34a8300bf1e07fc478e03c3c02634d4
Refs: v4.20-rc3-524-g62f65d3cb34a
Author: Felix Kuehling 
AuthorDate: Mon Nov 19 20:05:54 2018 -0500
Commit: Felix Kuehling 
CommitDate: Fri Dec 7 17:17:11 2018 -0500

 drm/amdgpu: Add KFD VRAM limit checking

 We don't want KFD processes evicting each other over VRAM usage.
 Therefore prevent overcommitting VRAM among KFD applications with
 a per-GPU limit. Also leave enough room for page tables on top
 of the application memory usage.

 Signed-off-by: Felix Kuehling 
 Reviewed-by: Eric Huang 
 Acked-by: Alex Deucher 

Breaks the build if HSA_AMD is not enabled:

scripts/kconfig/conf  --syncconfig Kconfig
   DESCEND  objtool
   CALLscripts/checksyscalls.sh
   CHK include/generated/compile.h
   Building modules, stage 2.
   MODPOST 63 modules
Kernel: arch/x86/boot/bzImage is ready  (#58)
ERROR: "amdgpu_amdkfd_unreserve_memory_limit" 
[drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
make[1]: *** [scripts/Makefile.modpost:92: __modpost] Error 1
make: *** [Makefile:1271: modules] Error 2

This is because the function being used is not included in the build 
(the previous function called was part of amdgpu_amdkfd.c which is 
unconditionally built).

Cheers,
Tom
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

build broken on drm-next

[StDenis, Tom]

Hi,

This commit

commit e421c656beefa1044f65cf50d7a7455df60cd703 

Refs: v4.20-rc3-530-ge421c656beef 

Author: Tiecheng Zhou  

AuthorDate: Fri Dec 7 09:11:35 2018 +0800 

Commit: Tiecheng Zhou  

CommitDate: Mon Dec 10 11:14:27 2018 +0800 


 drm/amdgpu: bypass RLC init under sriov for Tonga

 RLC will go wrong in soft_reset under sriov

 Workaroound: only need to init RLC csb, and skip RLC stop, reset, start
 this is because host-driver has already done full 
initialization on RLC

 Signed-off-by: Tiecehng Zhou  

 Acked-by: Alex Deucher  


Causes a build error on amd-staging-drm-next:

drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c: In function ‘gfx_v8_0_rlc_resume’:
drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c:4071:6: error: implicit 
declaration of function ‘amdgpu_sriov’; did you mean ‘amdgpu_sriov_vf’? 
[-Werror=implicit-function-declaration]
   if (amdgpu_sriov(adev)) {
   ^~~~
   amdgpu_sriov_vf
   CC [M]  drivers/gpu/drm/amd/amdgpu/sdma_v3_0.o
   CC [M]  drivers/gpu/drm/amd/amdgpu/sdma_v4_0.o
   CC [M]  drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.o
cc1: some warnings being treated as errors
make[4]: *** [scripts/Makefile.build:293: 
drivers/gpu/drm/amd/amdgpu/gfx_v8_0.o] Error 1
make[4]: *** Waiting for unfinished jobs
make[3]: *** [scripts/Makefile.build:518: drivers/gpu/drm/amd/amdgpu] 
Error 2
make[2]: *** [scripts/Makefile.build:518: drivers/gpu/drm] Error 2
make[1]: *** [scripts/Makefile.build:518: drivers/gpu] Error 2
make: *** [Makefile:1060: drivers] Error 2


Tom
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

regression in ttm

[StDenis, Tom]

This commit causes a regression on my Carrizo running piglit (dmesg 
attached)

commit 5786b66c9e3b7b18f3c24566e70cae450969cb14
Refs: v4.20-rc3-498-g5786b66c9e3b
Author: Christian König 
AuthorDate: Mon Sep 24 13:35:53 2018 +0200
Commit: Christian König 
CommitDate: Tue Dec 4 10:22:22 2018 +0100

 drm/ttm: drop the extra reservation for pipelined BO moves

 The driver is now responsible to allocate enough shared slots.

 Signed-off-by: Christian König 
 Reviewed-by: Michel Dänzer 
 Reviewed-by: Junwei Zhang 
 Reviewed-by: Huang Rui 

Tom.


dmesg.log.gz
Description: dmesg.log.gz
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: regression on RV1

[StDenis, Tom]

I had sent a patch to the list but yours is prettier.  You can add my 
Tested-By: to your patch.

Tom



On 2018-10-17 12:40 p.m., Deucher, Alexander wrote:
> I think something like this should fix it.
> 
> 
> Alex
> 
> 
> *From:* amd-gfx  on behalf of 
> Deucher, Alexander 
> *Sent:* Wednesday, October 17, 2018 12:15:21 PM
> *To:* StDenis, Tom; Koenig, Christian; amd-gfx mailing list
> *Cc:* Huang, Ray
> *Subject:* Re: regression on RV1
> 
> IIRC, APUs do not have a paging queue.  Only dGPUs have it.
> 
> 
> Alex
> 
> ------------
> *From:* amd-gfx  on behalf of 
> StDenis, Tom 
> *Sent:* Wednesday, October 17, 2018 11:54:33 AM
> *To:* Koenig, Christian; amd-gfx mailing list
> *Cc:* Huang, Ray
> *Subject:* regression on RV1
> This commit:
> 
> commit 6cbd074831a423e0d30b386fc056d6c2c3559147 (HEAD, refs/bisect/bad)
> Author: Christian König 
> Date:   Mon Oct 8 14:38:22 2018 +0200
> 
>   drm/amdgpu: activate paging queue on SDMA v4
> 
>   Implement all the necessary stuff to get those extra rings working.
> 
>   Signed-off-by: Christian König 
>   Reviewed-by: Huang Rui 
> 
> Breaks my RV1 init.
> 
> Tom

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH] drm/amd/amdgpu: Don't use paging functions on APU

[StDenis, Tom]

Signed-off-by: Tom St Denis 
---
 drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c | 46 --
 1 file changed, 28 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c 
b/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c
index 33a62d5a4949..b7f6db39d357 100644
--- a/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c
@@ -1115,7 +1115,8 @@ static int sdma_v4_0_start(struct amdgpu_device *adev)
 
WREG32_SDMA(i, mmSDMA0_SEM_WAIT_FAIL_TIMER_CNTL, 0);
sdma_v4_0_gfx_resume(adev, i);
-   sdma_v4_0_page_resume(adev, i);
+   if (!(adev->flags & AMD_IS_APU))
+   sdma_v4_0_page_resume(adev, i);
 
/* set utc l1 enable flag always to 1 */
temp = RREG32_SDMA(i, mmSDMA0_CNTL);
@@ -1522,18 +1523,20 @@ static int sdma_v4_0_sw_init(void *handle)
if (r)
return r;
 
-   ring = >sdma.instance[i].page;
-   ring->ring_obj = NULL;
-   ring->use_doorbell = false;
-
-   sprintf(ring->name, "page%d", i);
-   r = amdgpu_ring_init(adev, ring, 1024,
->sdma.trap_irq,
-(i == 0) ?
-AMDGPU_SDMA_IRQ_TRAP0 :
-AMDGPU_SDMA_IRQ_TRAP1);
-   if (r)
-   return r;
+   if (!(adev->flags & AMD_IS_APU)) {
+   ring = >sdma.instance[i].page;
+   ring->ring_obj = NULL;
+   ring->use_doorbell = false;
+
+   sprintf(ring->name, "page%d", i);
+   r = amdgpu_ring_init(adev, ring, 1024,
+>sdma.trap_irq,
+(i == 0) ?
+AMDGPU_SDMA_IRQ_TRAP0 :
+AMDGPU_SDMA_IRQ_TRAP1);
+   if (r)
+   return r;
+   }
}
 
return r;
@@ -1546,7 +1549,8 @@ static int sdma_v4_0_sw_fini(void *handle)
 
for (i = 0; i < adev->sdma.num_instances; i++) {
amdgpu_ring_fini(>sdma.instance[i].ring);
-   amdgpu_ring_fini(>sdma.instance[i].page);
+   if (!(adev->flags & AMD_IS_APU))
+   amdgpu_ring_fini(>sdma.instance[i].page);
}
 
for (i = 0; i < adev->sdma.num_instances; i++) {
@@ -1686,7 +1690,8 @@ static int sdma_v4_0_process_trap_irq(struct 
amdgpu_device *adev,
/* XXX compute */
break;
case 3:
-   amdgpu_fence_process(>sdma.instance[instance].page);
+   if (!(adev->flags & AMD_IS_APU))
+   
amdgpu_fence_process(>sdma.instance[instance].page);
break;
}
return 0;
@@ -1953,8 +1958,10 @@ static void sdma_v4_0_set_ring_funcs(struct 
amdgpu_device *adev)
for (i = 0; i < adev->sdma.num_instances; i++) {
adev->sdma.instance[i].ring.funcs = _v4_0_ring_funcs;
adev->sdma.instance[i].ring.me = i;
-   adev->sdma.instance[i].page.funcs = _v4_0_page_ring_funcs;
-   adev->sdma.instance[i].page.me = i;
+   if (!(adev->flags & AMD_IS_APU)) {
+   adev->sdma.instance[i].page.funcs = 
_v4_0_page_ring_funcs;
+   adev->sdma.instance[i].page.me = i;
+   }
}
 }
 
@@ -2054,7 +2061,10 @@ static void sdma_v4_0_set_vm_pte_funcs(struct 
amdgpu_device *adev)
 
adev->vm_manager.vm_pte_funcs = _v4_0_vm_pte_funcs;
for (i = 0; i < adev->sdma.num_instances; i++) {
-   sched = >sdma.instance[i].page.sched;
+   if (!(adev->flags & AMD_IS_APU))
+   sched = >sdma.instance[i].page.sched;
+   else
+   sched = >sdma.instance[i].ring.sched;
adev->vm_manager.vm_pte_rqs[i] =
>sched_rq[DRM_SCHED_PRIORITY_KERNEL];
}
-- 
2.17.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

regression on RV1

[StDenis, Tom]

This commit:

commit 6cbd074831a423e0d30b386fc056d6c2c3559147 (HEAD, refs/bisect/bad)
Author: Christian König 
Date:   Mon Oct 8 14:38:22 2018 +0200

 drm/amdgpu: activate paging queue on SDMA v4

 Implement all the necessary stuff to get those extra rings working.

 Signed-off-by: Christian König 
 Reviewed-by: Huang Rui 

Breaks my RV1 init.

Tom
[0.00] Linux version 4.19.0-rc1+ (root@raven) (gcc version 8.1.1 
20180712 (Red Hat 8.1.1-5) (GCC)) #36 SMP Mon Oct 15 11:34:58 EDT 2018
[0.00] Command line: BOOT_IMAGE=/vmlinuz-4.19.0-rc1+ 
root=UUID=66163c80-0ca1-4beb-aeba-5cc130b813e6 ro rhgb quiet 
modprobe.blacklist=amdgpu,radeon LANG=en_CA.UTF-8
[0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point 
registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
[0.00] x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
[0.00] x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, 
using 'compacted' format.
[0.00] BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009d3ff] usable
[0.00] BIOS-e820: [mem 0x0009d400-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000e-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0x03ff] usable
[0.00] BIOS-e820: [mem 0x0400-0x04009fff] ACPI NVS
[0.00] BIOS-e820: [mem 0x0400a000-0x09bf] usable
[0.00] BIOS-e820: [mem 0x09c0-0x09ff] reserved
[0.00] BIOS-e820: [mem 0x0a00-0x0aff] usable
[0.00] BIOS-e820: [mem 0x0b00-0x0b01] reserved
[0.00] BIOS-e820: [mem 0x0b02-0x73963fff] usable
[0.00] BIOS-e820: [mem 0x73964000-0x7397cfff] ACPI data
[0.00] BIOS-e820: [mem 0x7397d000-0x7a5aafff] usable
[0.00] BIOS-e820: [mem 0x7a5ab000-0x7a6c2fff] reserved
[0.00] BIOS-e820: [mem 0x7a6c3000-0x7a6cefff] ACPI data
[0.00] BIOS-e820: [mem 0x7a6cf000-0x7a7d1fff] usable
[0.00] BIOS-e820: [mem 0x7a7d2000-0x7ab89fff] ACPI NVS
[0.00] BIOS-e820: [mem 0x7ab8a000-0x7b942fff] reserved
[0.00] BIOS-e820: [mem 0x7b943000-0x7dff] usable
[0.00] BIOS-e820: [mem 0x7e00-0xbfff] reserved
[0.00] BIOS-e820: [mem 0xf800-0xfbff] reserved
[0.00] BIOS-e820: [mem 0xfd80-0xfdff] reserved
[0.00] BIOS-e820: [mem 0xfea0-0xfea0] reserved
[0.00] BIOS-e820: [mem 0xfeb8-0xfec01fff] reserved
[0.00] BIOS-e820: [mem 0xfec1-0xfec10fff] reserved
[0.00] BIOS-e820: [mem 0xfec3-0xfec30fff] reserved
[0.00] BIOS-e820: [mem 0xfed0-0xfed00fff] reserved
[0.00] BIOS-e820: [mem 0xfed4-0xfed44fff] reserved
[0.00] BIOS-e820: [mem 0xfed8-0xfed8] reserved
[0.00] BIOS-e820: [mem 0xfedc2000-0xfedc] reserved
[0.00] BIOS-e820: [mem 0xfedd4000-0xfedd5fff] reserved
[0.00] BIOS-e820: [mem 0xfee0-0xfeef] reserved
[0.00] BIOS-e820: [mem 0xff00-0x] reserved
[0.00] BIOS-e820: [mem 0x0001-0x00023f33] usable
[0.00] NX (Execute Disable) protection: active
[0.00] SMBIOS 3.1.1 present.
[0.00] DMI: System manufacturer System Product Name/TUF B350M-PLUS 
GAMING, BIOS 4011 04/19/2018
[0.00] tsc: Fast TSC calibration failed
[0.00] e820: update [mem 0x-0x0fff] usable ==> reserved
[0.00] e820: remove [mem 0x000a-0x000f] usable
[0.00] last_pfn = 0x23f340 max_arch_pfn = 0x4
[0.00] MTRR default type: uncachable
[0.00] MTRR fixed ranges enabled:
[0.00]   0-9 write-back
[0.00]   A-B write-through
[0.00]   C-F write-protect
[0.00] MTRR variable ranges enabled:
[0.00]   0 base  mask 8000 write-back
[0.00]   1 base 8000 mask C000 write-back
[0.00]   2 disabled
[0.00]   3 disabled
[0.00]   4 disabled
[0.00]   5 disabled
[0.00]   6 disabled
[0.00]   7 disabled
[0.00] TOM2: 00024000 aka 9216M
[0.00] x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WP  UC- WT  
[0.00] e820: update [mem 0xc000-0x] usable ==> reserved
[0.00] last_pfn = 0x7e000 max_arch_pfn = 

Re: vcn regression on raven1

[StDenis, Tom]

Hi Jerry,

Like I said it's (now well) past EOD (meaning my workstation is powered off) so 
I'll have to check tomorrow.  But I do pull from gerrit daily and build from 
that.

I'll take a look in the morning.

Cheers,
Tom

From: Zhang, Jerry
Sent: Tuesday, May 1, 2018 21:39
To: StDenis, Tom; Deucher, Alexander
Cc: Koenig, Christian; amd-gfx@lists.freedesktop.org
Subject: Re: vcn regression on raven1

Hi Tom,

Do you mean you cannot find the patch from gerrit/amd-staging-dkms-next either?

I do find it.

the tip of gerrit/amd-staging-drm-next is
   * bb54e82 2018-04-30 12:17:07 -0400 drm/amdgpu: Switch to interruptable wait
to recover from ring hang. 

while the tip of freedesktop is
   * a11008c 2018-04-25 20:32:05 -0500 drm/powerplay: Add powertune table for
VEGAM 

Jerry

On 05/02/2018 09:29 AM, StDenis, Tom wrote:
> I pull from gerrit.  I'm just pointing out that it's not on drm-next upstream 
> either.
>
> It may have been missed in a rebase or something.
>
> Tom
> 
> From: Zhang, Jerry
> Sent: Tuesday, May 1, 2018 21:07
> To: StDenis, Tom; Deucher, Alexander
> Cc: Koenig, Christian; amd-gfx@lists.freedesktop.org
> Subject: Re: vcn regression on raven1
>
> Hi Tom,
>
> Sound you get the code from freedesktop rather than the internal drm-next.
> Unfortunately freedesktop looks delay to sync the code from internal drm-next.
> That's the gap it happened as issue in the test.
>
> Hi Alex,
>
> Is that a issue for code syncing between freedesktop and internal drm-next?
> Or it's a known issue of delay syncing code.
>
> Jerry
>
> On 05/02/2018 08:57 AM, StDenis, Tom wrote:
>> Hi Jerry,
>>
>> It's well past EOD for me I'll pick this up in the morning.
>>
>> I'm fairly certain I wrote my patch against the tip of amd-staging-drm-next 
>> as of my pull this morning though.
>>
>> If it's in there and I missed it somehow I apologize otherwise it'd be nice 
>> to make sure it's in there.
>>
>> Based on the public copy of the tree it's not there
>>
>> https://cgit.freedesktop.org/~agd5f/linux/tree/drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c?h=amd-staging-drm-next#n1110
>>
>> Cheers,
>> Tom
>> 
>> From: Zhang, Jerry
>> Sent: Tuesday, May 1, 2018 20:52
>> To: StDenis, Tom; Deucher, Alexander
>> Cc: Koenig, Christian; amd-gfx@lists.freedesktop.org
>> Subject: Re: vcn regression on raven1
>>
>> Hi Tom,
>>
>> It was landed in the latest drm-next, like
>>  * 964933a 2018-04-27 10:26:09 +0800 drm/amdgpu/uvd7: add
>> emit_reg_write_reg_wait ring callback 
>>
>> Did you test with that included?
>> Please try to get the latest drm-next, if not.
>> They look the same issue from the log.
>>
>> Jerry
>>
>> On 05/02/2018 08:47 AM, StDenis, Tom wrote:
>>> Hi Jerry,
>>>
>>> So far as I know this wasn't included on the tip of drm-next.  I hit this 
>>> this morning in my semi-regular pull/build/test cycle.
>>>
>>> Was this missed in a recent rebase?
>>>
>>> Tom
>>> 
>>> From: Zhang, Jerry
>>> Sent: Tuesday, May 1, 2018 20:43
>>> To: StDenis, Tom; Deucher, Alexander
>>> Cc: Koenig, Christian; amd-gfx@lists.freedesktop.org
>>> Subject: Re: vcn regression on raven1
>>>
>>> On 05/01/2018 09:34 PM, Tom St Denis wrote:
>>>> Hi all,
>>>>
>>>> I've noticed that on the tip of drm-next vcn playback of video is broken 
>>>> (see
>>>> dmesg below).  I've bisected it to this commit
>>>
>>> It may be fixed here as a common issue.
>>>
>>>   * https://patchwork.freedesktop.org/patch/218909/
>>>
>>> Jerry
>>>
>>>>
>>>> [root@raven linux]# git bisect good
>>>> 701372349fd55b5396b335580e979ac4dde3dd02 is the first bad commit
>>>> commit 701372349fd55b5396b335580e979ac4dde3dd02
>>>> Author: Alex Deucher <alexander.deuc...@amd.com>
>>>> Date:   Tue Mar 27 17:10:56 2018 -0500
>>>>
>>>> drm/amdgpu/gmc9: use amdgpu_ring_emit_reg_write_reg_wait in gpu 
>>>> tlb flush
>>>>
>>>> Use amdgpu_ring_emit_reg_write_reg_wait.  On engines that support 
>>>> it,
>>>> it provides a write and wait in a single packet which avoids a 
>>>> missed
>>>> ack if a world switch happens between the request and waiting for 
>>>> the
>>

Re: vcn regression on raven1

[StDenis, Tom]

I pull from gerrit.  I'm just pointing out that it's not on drm-next upstream 
either.

It may have been missed in a rebase or something.

Tom

From: Zhang, Jerry
Sent: Tuesday, May 1, 2018 21:07
To: StDenis, Tom; Deucher, Alexander
Cc: Koenig, Christian; amd-gfx@lists.freedesktop.org
Subject: Re: vcn regression on raven1

Hi Tom,

Sound you get the code from freedesktop rather than the internal drm-next.
Unfortunately freedesktop looks delay to sync the code from internal drm-next.
That's the gap it happened as issue in the test.

Hi Alex,

Is that a issue for code syncing between freedesktop and internal drm-next?
Or it's a known issue of delay syncing code.

Jerry

On 05/02/2018 08:57 AM, StDenis, Tom wrote:
> Hi Jerry,
>
> It's well past EOD for me I'll pick this up in the morning.
>
> I'm fairly certain I wrote my patch against the tip of amd-staging-drm-next 
> as of my pull this morning though.
>
> If it's in there and I missed it somehow I apologize otherwise it'd be nice 
> to make sure it's in there.
>
> Based on the public copy of the tree it's not there
>
> https://cgit.freedesktop.org/~agd5f/linux/tree/drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c?h=amd-staging-drm-next#n1110
>
> Cheers,
> Tom
> 
> From: Zhang, Jerry
> Sent: Tuesday, May 1, 2018 20:52
> To: StDenis, Tom; Deucher, Alexander
> Cc: Koenig, Christian; amd-gfx@lists.freedesktop.org
> Subject: Re: vcn regression on raven1
>
> Hi Tom,
>
> It was landed in the latest drm-next, like
> * 964933a 2018-04-27 10:26:09 +0800 drm/amdgpu/uvd7: add
> emit_reg_write_reg_wait ring callback 
>
> Did you test with that included?
> Please try to get the latest drm-next, if not.
> They look the same issue from the log.
>
> Jerry
>
> On 05/02/2018 08:47 AM, StDenis, Tom wrote:
>> Hi Jerry,
>>
>> So far as I know this wasn't included on the tip of drm-next.  I hit this 
>> this morning in my semi-regular pull/build/test cycle.
>>
>> Was this missed in a recent rebase?
>>
>> Tom
>> 
>> From: Zhang, Jerry
>> Sent: Tuesday, May 1, 2018 20:43
>> To: StDenis, Tom; Deucher, Alexander
>> Cc: Koenig, Christian; amd-gfx@lists.freedesktop.org
>> Subject: Re: vcn regression on raven1
>>
>> On 05/01/2018 09:34 PM, Tom St Denis wrote:
>>> Hi all,
>>>
>>> I've noticed that on the tip of drm-next vcn playback of video is broken 
>>> (see
>>> dmesg below).  I've bisected it to this commit
>>
>> It may be fixed here as a common issue.
>>
>>  * https://patchwork.freedesktop.org/patch/218909/
>>
>> Jerry
>>
>>>
>>> [root@raven linux]# git bisect good
>>> 701372349fd55b5396b335580e979ac4dde3dd02 is the first bad commit
>>> commit 701372349fd55b5396b335580e979ac4dde3dd02
>>> Author: Alex Deucher <alexander.deuc...@amd.com>
>>> Date:   Tue Mar 27 17:10:56 2018 -0500
>>>
>>>drm/amdgpu/gmc9: use amdgpu_ring_emit_reg_write_reg_wait in gpu tlb 
>>> flush
>>>
>>>Use amdgpu_ring_emit_reg_write_reg_wait.  On engines that support it,
>>>it provides a write and wait in a single packet which avoids a missed
>>>ack if a world switch happens between the request and waiting for the
>>>ack.
>>>
>>>Reviewed-by: Huang Rui <ray.hu...@amd.com>
>>>Reviewed-by: Christian König <christian.koe...@amd.com>
>>>Signed-off-by: Alex Deucher <alexander.deuc...@amd.com>
>>>
>>> :04 04 4e4312de03f4b34abd65f4bb12dba4c7093055ba
>>> ccc4abc78c0b6f24328fd998f998fa06bf0618b1 M  drivers
>>>
>>> Which is odd because the commit before this is the vcn change and it works 
>>> fine
>>> (playing BBB right now).
>>>
>>> Here's the dmesg:
>>>
>>> [ 2925.640102] BUG: unable to handle kernel NULL pointer dereference at
>>> 
>>> [ 2925.640113] IP:   (null)
>>> [ 2925.640116] PGD 0 P4D 0
>>> [ 2925.640122] Oops: 0010 [#1] SMP KASAN NOPTI
>>> [ 2925.640126] Modules linked in: tun fuse amdkfd amdgpu mfd_core chash
>>> gpu_sched ttm ax88179_178a usbnet
>>> [ 2925.640139] CPU: 4 PID: 3791 Comm: vcn_dec Not tainted 4.16.0-rc7+ #20
>>> [ 2925.640142] Hardware name: System manufacturer System Product Name/TUF
>>> B350M-PLUS GAMING, BIOS 3803 01/22/2018
>>> [ 2925.640146] RIP: 0010:  (null)
>>> [ 2925.640148] RSP: 0018:8801d54f7790 E

Re: vcn regression on raven1

[StDenis, Tom]

Hi Jerry,

It's well past EOD for me I'll pick this up in the morning.

I'm fairly certain I wrote my patch against the tip of amd-staging-drm-next as 
of my pull this morning though.

If it's in there and I missed it somehow I apologize otherwise it'd be nice to 
make sure it's in there.

Based on the public copy of the tree it's not there 

https://cgit.freedesktop.org/~agd5f/linux/tree/drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c?h=amd-staging-drm-next#n1110

Cheers,
Tom

From: Zhang, Jerry
Sent: Tuesday, May 1, 2018 20:52
To: StDenis, Tom; Deucher, Alexander
Cc: Koenig, Christian; amd-gfx@lists.freedesktop.org
Subject: Re: vcn regression on raven1

Hi Tom,

It was landed in the latest drm-next, like
   * 964933a 2018-04-27 10:26:09 +0800 drm/amdgpu/uvd7: add
emit_reg_write_reg_wait ring callback 

Did you test with that included?
Please try to get the latest drm-next, if not.
They look the same issue from the log.

Jerry

On 05/02/2018 08:47 AM, StDenis, Tom wrote:
> Hi Jerry,
>
> So far as I know this wasn't included on the tip of drm-next.  I hit this 
> this morning in my semi-regular pull/build/test cycle.
>
> Was this missed in a recent rebase?
>
> Tom
> 
> From: Zhang, Jerry
> Sent: Tuesday, May 1, 2018 20:43
> To: StDenis, Tom; Deucher, Alexander
> Cc: Koenig, Christian; amd-gfx@lists.freedesktop.org
> Subject: Re: vcn regression on raven1
>
> On 05/01/2018 09:34 PM, Tom St Denis wrote:
>> Hi all,
>>
>> I've noticed that on the tip of drm-next vcn playback of video is broken (see
>> dmesg below).  I've bisected it to this commit
>
> It may be fixed here as a common issue.
>
> * https://patchwork.freedesktop.org/patch/218909/
>
> Jerry
>
>>
>> [root@raven linux]# git bisect good
>> 701372349fd55b5396b335580e979ac4dde3dd02 is the first bad commit
>> commit 701372349fd55b5396b335580e979ac4dde3dd02
>> Author: Alex Deucher <alexander.deuc...@amd.com>
>> Date:   Tue Mar 27 17:10:56 2018 -0500
>>
>>   drm/amdgpu/gmc9: use amdgpu_ring_emit_reg_write_reg_wait in gpu tlb 
>> flush
>>
>>   Use amdgpu_ring_emit_reg_write_reg_wait.  On engines that support it,
>>   it provides a write and wait in a single packet which avoids a missed
>>   ack if a world switch happens between the request and waiting for the
>>   ack.
>>
>>   Reviewed-by: Huang Rui <ray.hu...@amd.com>
>>   Reviewed-by: Christian König <christian.koe...@amd.com>
>>   Signed-off-by: Alex Deucher <alexander.deuc...@amd.com>
>>
>> :04 04 4e4312de03f4b34abd65f4bb12dba4c7093055ba
>> ccc4abc78c0b6f24328fd998f998fa06bf0618b1 M  drivers
>>
>> Which is odd because the commit before this is the vcn change and it works 
>> fine
>> (playing BBB right now).
>>
>> Here's the dmesg:
>>
>> [ 2925.640102] BUG: unable to handle kernel NULL pointer dereference at
>> 
>> [ 2925.640113] IP:   (null)
>> [ 2925.640116] PGD 0 P4D 0
>> [ 2925.640122] Oops: 0010 [#1] SMP KASAN NOPTI
>> [ 2925.640126] Modules linked in: tun fuse amdkfd amdgpu mfd_core chash
>> gpu_sched ttm ax88179_178a usbnet
>> [ 2925.640139] CPU: 4 PID: 3791 Comm: vcn_dec Not tainted 4.16.0-rc7+ #20
>> [ 2925.640142] Hardware name: System manufacturer System Product Name/TUF
>> B350M-PLUS GAMING, BIOS 3803 01/22/2018
>> [ 2925.640146] RIP: 0010:  (null)
>> [ 2925.640148] RSP: 0018:8801d54f7790 EFLAGS: 00010206
>> [ 2925.640153] RAX:  RBX: 8801d8b38420 RCX: 
>> 007c0080
>> [ 2925.640156] RDX: 0001a6fa RSI: 0001a6e8 RDI: 
>> 8801d8b38420
>> [ 2925.640159] RBP: 0001a6fa R08: 0080 R09: 
>> ed003aa9eef9
>> [ 2925.640162] R10: 09c74f08 R11: fbfff0f5d1e7 R12: 
>> 8801d8b3277c
>> [ 2925.640164] R13: 8801d8b3001c R14: 0005 R15: 
>> 
>> [ 2925.640168] FS:  () GS:8801dcf0()
>> knlGS:
>> [ 2925.640171] CS:  0010 DS:  ES:  CR0: 80050033
>> [ 2925.640174] CR2:  CR3: 0001d9712000 CR4: 
>> 003406e0
>> [ 2925.640176] Call Trace:
>> [ 2925.640272]  ? gmc_v9_0_emit_flush_gpu_tlb+0x260/0x2a0 [amdgpu]
>> [ 2925.640368]  ? vcn_v1_0_dec_ring_insert_start+0x360/0x360 [amdgpu]
>> [ 2925.640459]  ? mmhub_v1_0_get_clockgating+0xc0/0xc0 [amdgpu]
>> [ 2925.640545]  ? amdgpu_vmid_had_gpu_reset+0x89/0xc0 [amdgpu]
>> [ 2925.640640]  ? vcn_v1_0_dec_ring_emit_vm_flush+0x64/0xb0 [amdgpu]
>> [

Re: vcn regression on raven1

[StDenis, Tom]

Hi Jerry,

So far as I know this wasn't included on the tip of drm-next.  I hit this this 
morning in my semi-regular pull/build/test cycle.

Was this missed in a recent rebase?

Tom

From: Zhang, Jerry
Sent: Tuesday, May 1, 2018 20:43
To: StDenis, Tom; Deucher, Alexander
Cc: Koenig, Christian; amd-gfx@lists.freedesktop.org
Subject: Re: vcn regression on raven1

On 05/01/2018 09:34 PM, Tom St Denis wrote:
> Hi all,
>
> I've noticed that on the tip of drm-next vcn playback of video is broken (see
> dmesg below).  I've bisected it to this commit

It may be fixed here as a common issue.

   * https://patchwork.freedesktop.org/patch/218909/

Jerry

>
> [root@raven linux]# git bisect good
> 701372349fd55b5396b335580e979ac4dde3dd02 is the first bad commit
> commit 701372349fd55b5396b335580e979ac4dde3dd02
> Author: Alex Deucher <alexander.deuc...@amd.com>
> Date:   Tue Mar 27 17:10:56 2018 -0500
>
>  drm/amdgpu/gmc9: use amdgpu_ring_emit_reg_write_reg_wait in gpu tlb flush
>
>  Use amdgpu_ring_emit_reg_write_reg_wait.  On engines that support it,
>  it provides a write and wait in a single packet which avoids a missed
>  ack if a world switch happens between the request and waiting for the
>  ack.
>
>  Reviewed-by: Huang Rui <ray.hu...@amd.com>
>  Reviewed-by: Christian König <christian.koe...@amd.com>
>  Signed-off-by: Alex Deucher <alexander.deuc...@amd.com>
>
> :04 04 4e4312de03f4b34abd65f4bb12dba4c7093055ba
> ccc4abc78c0b6f24328fd998f998fa06bf0618b1 M  drivers
>
> Which is odd because the commit before this is the vcn change and it works 
> fine
> (playing BBB right now).
>
> Here's the dmesg:
>
> [ 2925.640102] BUG: unable to handle kernel NULL pointer dereference at
> 
> [ 2925.640113] IP:   (null)
> [ 2925.640116] PGD 0 P4D 0
> [ 2925.640122] Oops: 0010 [#1] SMP KASAN NOPTI
> [ 2925.640126] Modules linked in: tun fuse amdkfd amdgpu mfd_core chash
> gpu_sched ttm ax88179_178a usbnet
> [ 2925.640139] CPU: 4 PID: 3791 Comm: vcn_dec Not tainted 4.16.0-rc7+ #20
> [ 2925.640142] Hardware name: System manufacturer System Product Name/TUF
> B350M-PLUS GAMING, BIOS 3803 01/22/2018
> [ 2925.640146] RIP: 0010:  (null)
> [ 2925.640148] RSP: 0018:8801d54f7790 EFLAGS: 00010206
> [ 2925.640153] RAX:  RBX: 8801d8b38420 RCX: 
> 007c0080
> [ 2925.640156] RDX: 0001a6fa RSI: 0001a6e8 RDI: 
> 8801d8b38420
> [ 2925.640159] RBP: 0001a6fa R08: 0080 R09: 
> ed003aa9eef9
> [ 2925.640162] R10: 09c74f08 R11: fbfff0f5d1e7 R12: 
> 8801d8b3277c
> [ 2925.640164] R13: 8801d8b3001c R14: 0005 R15: 
> 
> [ 2925.640168] FS:  () GS:8801dcf0()
> knlGS:
> [ 2925.640171] CS:  0010 DS:  ES:  CR0: 80050033
> [ 2925.640174] CR2:  CR3: 0001d9712000 CR4: 
> 003406e0
> [ 2925.640176] Call Trace:
> [ 2925.640272]  ? gmc_v9_0_emit_flush_gpu_tlb+0x260/0x2a0 [amdgpu]
> [ 2925.640368]  ? vcn_v1_0_dec_ring_insert_start+0x360/0x360 [amdgpu]
> [ 2925.640459]  ? mmhub_v1_0_get_clockgating+0xc0/0xc0 [amdgpu]
> [ 2925.640545]  ? amdgpu_vmid_had_gpu_reset+0x89/0xc0 [amdgpu]
> [ 2925.640640]  ? vcn_v1_0_dec_ring_emit_vm_flush+0x64/0xb0 [amdgpu]
> [ 2925.640725]  ? amdgpu_vm_flush+0xb43/0xcc0 [amdgpu]
> [ 2925.640810]  ? amdgpu_vm_need_pipeline_sync+0x260/0x260 [amdgpu]
> [ 2925.640897]  ? amdgpu_vmid_had_gpu_reset+0xc0/0xc0 [amdgpu]
> [ 2925.641003]  ? vcn_v1_0_dec_ring_insert_start+0x2d7/0x360 [amdgpu]
> [ 2925.641095]  ? amdgpu_ib_schedule+0x1b5/0x800 [amdgpu]
> [ 2925.641102]  ? dma_fence_add_callback+0x15f/0x360
> [ 2925.641201]  ? amdgpu_job_run+0x32f/0x370 [amdgpu]
> [ 2925.641297]  ? amdgpu_job_free_resources+0xd0/0xd0 [amdgpu]
> [ 2925.641302]  ? __queue_delayed_work+0x144/0x1d0
> [ 2925.641306]  ? delayed_work_timer_fn+0x40/0x40
> [ 2925.641312]  ? prepare_to_wait_exclusive+0x1d0/0x1d0
> [ 2925.641318]  ? drm_sched_main+0x68c/0x940 [gpu_sched]
> [ 2925.641323]  ? drm_sched_entity_fini+0x60/0x60 [gpu_sched]
> [ 2925.641328]  ? save_stack+0x89/0xb0
> [ 2925.641332]  ? wait_woken+0x110/0x110
> [ 2925.641337]  ? ret_from_fork+0x22/0x40
> [ 2925.641343]  ? __schedule+0xd30/0xd30
> [ 2925.641346]  ? remove_wait_queue+0x150/0x150
> [ 2925.641353]  ? rcu_note_context_switch+0x2a0/0x2a0
> [ 2925.641359]  ? __lock_text_start+0x8/0x8
> [ 2925.641367]  ? drm_sched_entity_fini+0x60/0x60 [gpu_sched]
> [ 2925.641371]  ? kthread+0x19b/0x1c0
> [ 2925.641376]  ? kthread_create_worker_on_cpu+0xc0/0xc0
> [ 2925.641382]  ? ret_from_fork+0x22/0x40
> [ 2925.6

iomem debugfs patches

[StDenis, Tom]

Hi Christian,

I've been running with the last two patches from the ttm changes (that included 
your iomem patch with my write method addition) for a while now.  Through 
piglit, various GL games, with both normal and restricted VRAM without ill 
effect.

Is there anything else that might be required before pushing them?

Thanks,
Tom
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 5/5] drm/amdgpu: replace iova debugfs file with iomem

[StDenis, Tom]

I haven't tried the patch but just like to point out this breaks umr :-)  I'll 
have to craft something on Monday to support this and iova in parallel until 
the iova kernels are realistically EOL'ed.

On the other hand I support this idea since it eliminates the need for an fmem 
hack.  So much appreciated.

Cheers,
Tom


From: amd-gfx  on behalf of Christian 
König 
Sent: Friday, February 2, 2018 14:09
To: amd-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org
Subject: [PATCH 5/5] drm/amdgpu: replace iova debugfs file with iomem

This allows access to pages allocated through the driver with optional
IOMMU mapping.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 57 -
 1 file changed, 35 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 648c449aaa79..795ceaeb82d5 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -1929,38 +1929,51 @@ static const struct file_operations amdgpu_ttm_gtt_fops 
= {

 #endif

-static ssize_t amdgpu_iova_to_phys_read(struct file *f, char __user *buf,
-  size_t size, loff_t *pos)
+static ssize_t amdgpu_iomem_read(struct file *f, char __user *buf,
+size_t size, loff_t *pos)
 {
struct amdgpu_device *adev = file_inode(f)->i_private;
-   int r;
-   uint64_t phys;
struct iommu_domain *dom;
+   ssize_t result = 0;
+   int r;

-   // always return 8 bytes
-   if (size != 8)
-   return -EINVAL;
+   dom = iommu_get_domain_for_dev(adev->dev);

-   // only accept page addresses
-   if (*pos & 0xFFF)
-   return -EINVAL;
+   while (size) {
+   phys_addr_t addr = *pos & PAGE_MASK;
+   loff_t off = *pos & ~PAGE_MASK;
+   size_t bytes = PAGE_SIZE - off;
+   unsigned long pfn;
+   struct page *p;
+   void *ptr;

-   dom = iommu_get_domain_for_dev(adev->dev);
-   if (dom)
-   phys = iommu_iova_to_phys(dom, *pos);
-   else
-   phys = *pos;
+   addr = dom ? iommu_iova_to_phys(dom, addr) : addr;

-   r = copy_to_user(buf, , 8);
-   if (r)
-   return -EFAULT;
+   pfn = addr >> PAGE_SHIFT;
+   if (!pfn_valid(pfn))
+   return -EPERM;
+
+   p = pfn_to_page(pfn);
+   if (p->mapping != adev->mman.bdev.dev_mapping)
+   return -EPERM;
+
+   ptr = kmap(p);
+   r = copy_to_user(buf, ptr, bytes);
+   kunmap(p);
+   if (r)
+   return -EFAULT;

-   return 8;
+   size -= bytes;
+   *pos += bytes;
+   result += bytes;
+   }
+
+   return result;
 }

-static const struct file_operations amdgpu_ttm_iova_fops = {
+static const struct file_operations amdgpu_ttm_iomem_fops = {
.owner = THIS_MODULE,
-   .read = amdgpu_iova_to_phys_read,
+   .read = amdgpu_iomem_read,
.llseek = default_llseek
 };

@@ -1973,7 +1986,7 @@ static const struct {
 #ifdef CONFIG_DRM_AMDGPU_GART_DEBUGFS
{ "amdgpu_gtt", _ttm_gtt_fops, TTM_PL_TT },
 #endif
-   { "amdgpu_iova", _ttm_iova_fops, TTM_PL_SYSTEM },
+   { "amdgpu_iomem", _ttm_iomem_fops, TTM_PL_SYSTEM },
 };

 #endif
--
2.14.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 02/30] drm/amd/display: Remove dead enable_plane function definition and call

[StDenis, Tom]

I tried the latest drm-next as of this morning and still had gfx corruption.

I added you to the watchers list for a JIRA ticket I opened about this.

Cheers,
Tom


From: Wentland, Harry
Sent: Thursday, December 14, 2017 10:41
To: StDenis, Tom; amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH 02/30] drm/amd/display: Remove dead enable_plane function 
definition and call

On 2017-12-13 05:39 PM, Tom St Denis wrote:
> Would this fix the regression I found on Carrizo after the drm-next rebase?
>

This shouldn't have any functional impact. It was just a bit of unused code 
that we missed cleaning up in a previous change.

Regarding the regression you found, the fallout from 138a3358c179 
(drm/amd/display: Optimize programming front end) should have been resolved a 
while ago. Do you still see issues with amd-staging-drm-next?

Harry

> Tom
>
>
>
> On December 13, 2017 5:34:34 PM EST, Harry Wentland <harry.wentl...@amd.com> 
> wrote:
>> Signed-off-by: Harry Wentland <harry.wentl...@amd.com>
>> Reviewed-by: Jordan Lazare <jordan.laz...@amd.com>
>> Reviewed-by: Tony Cheng <tony.ch...@amd.com>
>> Acked-by: Harry Wentland <harry.wentl...@amd.com>
>> ---
>> drivers/gpu/drm/amd/display/dc/dce110/dce110_hw_sequencer.c | 3 ---
>> drivers/gpu/drm/amd/display/dc/inc/hw_sequencer.h   | 4 
>> 2 files changed, 7 deletions(-)
>>
>> diff --git
>> a/drivers/gpu/drm/amd/display/dc/dce110/dce110_hw_sequencer.c
>> b/drivers/gpu/drm/amd/display/dc/dce110/dce110_hw_sequencer.c
>> index 80d36610c302..f0002d63eb63 100644
>> --- a/drivers/gpu/drm/amd/display/dc/dce110/dce110_hw_sequencer.c
>> +++ b/drivers/gpu/drm/amd/display/dc/dce110/dce110_hw_sequencer.c
>> @@ -2053,9 +2053,6 @@ enum dc_status dce110_apply_ctx_to_hw(
>>  context,
>>  dc);
>>
>> -if (dc->hwss.enable_plane)
>> -dc->hwss.enable_plane(dc, pipe_ctx, context);
>> -
>>  if (DC_OK != status)
>>  return status;
>>  }
>> diff --git a/drivers/gpu/drm/amd/display/dc/inc/hw_sequencer.h
>> b/drivers/gpu/drm/amd/display/dc/inc/hw_sequencer.h
>> index b6215ba514d8..5d2b05b93e76 100644
>> --- a/drivers/gpu/drm/amd/display/dc/inc/hw_sequencer.h
>> +++ b/drivers/gpu/drm/amd/display/dc/inc/hw_sequencer.h
>> @@ -138,10 +138,6 @@ struct hw_sequencer_funcs {
>>
>>  void (*disable_plane)(struct dc *dc, struct pipe_ctx *pipe_ctx);
>>
>> -void (*enable_plane)(struct dc *dc,
>> -struct pipe_ctx *pipe,
>> -struct dc_state *context);
>> -
>>  void (*update_info_frame)(struct pipe_ctx *pipe_ctx);
>>
>>  void (*enable_stream)(struct pipe_ctx *pipe_ctx);
>> --
>> 2.14.1
>>
>> ___
>> amd-gfx mailing list
>> amd-gfx@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
> ___
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: remove ttm trace and add iova debugfs (v2)

[StDenis, Tom]

Should add I was able to read/write system memory mapped by amdgpu with these 
patches in place on my polaris10 device (with iommu enabled of course).


From: amd-gfx  on behalf of Tom St Denis 

Sent: Monday, September 18, 2017 13:33
To: amd-gfx@lists.freedesktop.org
Cc: dri-de...@lists.freedesktop.org
Subject: remove ttm trace and add iova debugfs (v2)

In this respin I add some changes per feedback and make the iova
entry have proper read/write methods which access pages mapped
by amdgpu.  So there is no need for /dev/mem or /dev/fmem anymore
when reading system memory.

Patches 3/4 are unchanged and remove the TTM trace from amdgpu
and from TTM itself.


___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 18/19] drm/amdgpu: Disable GFX PG on CZ

[StDenis, Tom]

Hi Felix,

Well it's really up to Christian and Alex but I'd keep an eye on this since 
it'll cause issues with embedded down the road.

I happen to have a CZ system so I could possibly try and bisect 4.11/4.12 and 
see if there's any stable points for you guys.  Is there a short and simple KFD 
setup I can install/run to test it?  Or is simply loading a KFD merged/rebased 
kernel enough to cause the hang (and thus I guess a bisect doesn't make sense).

Cheers,
Tom


From: Kuehling, Felix
Sent: Friday, August 11, 2017 20:40
To: StDenis, Tom; amd-gfx@lists.freedesktop.org; oded.gab...@gmail.com
Subject: Re: [PATCH 18/19] drm/amdgpu: Disable GFX PG on CZ

With the next change that adds programming of RLC_CP_SCHEDULERS it's a
VM fault and hard hang during boot, just after HWS initialization.
Without that change it's only a MEC hang when the first application
tries to create a user mode queue.

Regards,
  Felix

On 2017-08-11 08:08 PM, StDenis, Tom wrote:
> Hmm, I'd still be careful about disabling GFX PG since we may fail to meet 
> energy star requirements.
>
> Does the system hard hang or simply GPU hang?
>
> Tom
>
> 
> From: Kuehling, Felix
> Sent: Friday, August 11, 2017 19:56
> To: StDenis, Tom; amd-gfx@lists.freedesktop.org; oded.gab...@gmail.com
> Subject: Re: [PATCH 18/19] drm/amdgpu: Disable GFX PG on CZ
>
> Yes, I'm up-to-date. KFD doesn't use the KIQ to map the HIQ. And HIQ
> maps all our other queues (unless we're disabling the hardware scheduler).
>
> Regards,
>   Felix
>
>
> On 2017-08-11 07:45 PM, StDenis, Tom wrote:
>> Hi Felix,
>>
>> I'm assuming your tree is up to date with amd-staging-4.11 or 4.12 but we 
>> did previously have issues with compute rings if PG was enabled 
>> (specifically CGCG + PG) on Carrizo.  Then David committed some KIQ upgrades 
>> and it started working properly.
>>
>> Could that be related?  Because GFX PG "should work" on Carrizo is the 
>> official line last I heard from the GFX IP team.
>>
>> Cheers,
>> Tom
>> 
>> From: amd-gfx <amd-gfx-boun...@lists.freedesktop.org> on behalf of Felix 
>> Kuehling <felix.kuehl...@amd.com>
>> Sent: Friday, August 11, 2017 17:56
>> To: amd-gfx@lists.freedesktop.org; oded.gab...@gmail.com
>> Cc: Kuehling, Felix
>> Subject: [PATCH 18/19] drm/amdgpu: Disable GFX PG on CZ
>>
>> It's causing problems with user mode queues and the HIQ, and can
>> lead to hard hangs during boot after programming RLC_CP_SCHEDULERS.
>>
>> Signed-off-by: Felix Kuehling <felix.kuehl...@amd.com>
>> ---
>>  drivers/gpu/drm/amd/amdgpu/vi.c | 3 +--
>>  1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/vi.c 
>> b/drivers/gpu/drm/amd/amdgpu/vi.c
>> index 18bb3cb..495c8a3 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/vi.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/vi.c
>> @@ -1029,8 +1029,7 @@ static int vi_common_early_init(void *handle)
>> /* rev0 hardware requires workarounds to support PG */
>> adev->pg_flags = 0;
>> if (adev->rev_id != 0x00 || 
>> CZ_REV_BRISTOL(adev->pdev->revision)) {
>> -   adev->pg_flags |= AMD_PG_SUPPORT_GFX_PG |
>> -   AMD_PG_SUPPORT_GFX_SMG |
>> +   adev->pg_flags |= AMD_PG_SUPPORT_GFX_SMG |
>> AMD_PG_SUPPORT_GFX_PIPELINE |
>> AMD_PG_SUPPORT_CP |
>> AMD_PG_SUPPORT_UVD |
>> --
>> 2.7.4
>>
>> ___
>> amd-gfx mailing list
>> amd-gfx@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx