The additional output are at the end of sclk/mclk info as
cat pp_dpm_mclk
0: 300Mhz *
1: 1650Mhz
P: 300Mhz
Signed-off-by: Rex Zhu
Change-Id: Idf8eeedb5d399d9ffb7de7a2fb2976c7fa7c01a8
---
drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c | 2 ++
drivers/gpu/drm/amd/powerplay/hwmgr/rv_hwmgr.c
show mclk info as in MHz on Cz/St as
0: 333Mhz *
1: 800Mhz
Change-Id: Ie5932ac81b15565edb154ec6c00b35a99ab52b73
Signed-off-by: Rex Zhu
---
drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmg
From: Michel Dänzer
It means it just didn't find an entry for the GPU in the amdgpu.ids file.
Fixes spurious
amdgpu_parse_asic_ids: Cannot parse ASIC IDs: Resource temporarily unavailable
error messages in that case.
Reported-by: Marek Olšák
Signed-off-by: Michel Dänzer
---
amdgpu/amdgpu_
Windows added by the BIOS are not marked as 64bit because they are
usually not changeable anyway.
This fixes large BAR support on my new Ryzen build system.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
The newly added get_local_mem_info() function prints a phys_addr_t
using 0x%llx, which is wrong on most 32-bit systems, as shown by
this warning:
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c: In function 'get_local_mem_info':
include/linux/kern_levels.h:5:18: error: format '%llx' expects argument of
Reviewed-by: Alex Deucher
From: amd-gfx on behalf of Rex Zhu
Sent: Monday, January 8, 2018 4:57:30 AM
To: amd-gfx@lists.freedesktop.org
Cc: Zhu, Rex
Subject: [PATCH 1/2] drm/amd/pp: Add memory clock info display on Cz/St
show mclk info as in MHz on Cz/St as
0:
Reviewed-by: Marek Olšák
Marek
On Mon, Jan 8, 2018 at 11:24 AM, Michel Dänzer wrote:
> From: Michel Dänzer
>
> It means it just didn't find an entry for the GPU in the amdgpu.ids file.
>
> Fixes spurious
>
> amdgpu_parse_asic_ids: Cannot parse ASIC IDs: Resource temporarily
> unavailable
>
>
[ Not really a new bug, but moving the function makes it show up as a
new bug. - dan ]
Hello Alex Deucher,
The patch 75758255dc0f: "drm/amdgpu: move debugfs functions to their
own file" from Dec 14, 2017, leads to the following static checker
warning:
drivers/gpu/drm/amd/amdgpu/amdgpu
Can we put the 32-bit address space higher? E.g. high bits = 0xfff0 ?
Marek
On Sun, Jan 7, 2018 at 10:11 AM, Christian König
wrote:
> Retire the low range on Vega10 this frees up everything below
> 0x8000 for HMM.
>
> v2: keep the 32bit range working.
>
> Signed-off-by: Christia
On 2018-01-04 07:31 AM, Seung-Woo Kim wrote:
> The amdgpu.ids is only required when building with amdgpu support.
> Fix not to add it without amdgpu.
>
> Signed-off-by: Seung-Woo Kim
> ---
> data/Makefile.am |2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/data/Mak
This commit is Reviewed-by: Felix Kuehling
Thanks,
Felix
On 2018-01-08 07:53 AM, Arnd Bergmann wrote:
> The newly added get_local_mem_info() function prints a phys_addr_t
> using 0x%llx, which is wrong on most 32-bit systems, as shown by
> this warning:
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_a
[+Kent]
What does stable pstate mean? What is it used for?
Hi Kent,
Is this going to confuse rocm_smi?
Regards,
Felix
On 2018-01-08 04:57 AM, Rex Zhu wrote:
> The additional output are at the end of sclk/mclk info as
> cat pp_dpm_mclk
> 0: 300Mhz *
> 1: 1650Mhz
> P: 300Mhz
>
> Signed-off-by
On Mon, Jan 8, 2018 at 2:20 PM, Felix Kuehling wrote:
> [+Kent]
>
> What does stable pstate mean? What is it used for?
This is used for the profiling stuff in force_performance_level. It
disables clock and power gating and sets stable clock levels for doing
performance profiling.
Alex
>
> Hi K
Sorry, I just re-read and saw that this will be in sclk and mclk, not just
mclk. So will this have a direct impact on any other functionality, or will it
just disable clock/power gating and prevent the clocks from changing?
Kent
-Original Message-
From: Russell, Kent
Sent: Monday, Jan
Actually, 0x8000 is fine.
For the series:
Reviewed-by: Marek Olšák
Marek
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
And yes, it will confuse the SMI in a couple functions, but thankfully it's
nice enough that I can fix it with a couple lines.
So just to make sure that I understand this correctly, if a user were to echo P
to the pp_dpm_mclk file, it would disable clockgating and powergating and keep
the memo
Oh perfect. pp_dpm_sclk/pp_dpm_mclk just report what the stable pstate would
be. To enact that pstate, we would use the options available in
force_performance_level. Thank you for the clarification!
Kent
From: Deucher, Alexander
Sent: Monday, January 08, 2018 4:19 PM
To: Russell, Kent; Alex Deu
No, it doesn't do anything today and wouldn't do anything with this patch
either. With this patch, it just prints the stable pstate clock level in the
output if you read the files so you know what the clocks are when you enable
the profiling modes. That's why I think we should expose the stabl
The changes to the pp_dpm_files are purely informational with this patch (you
can't actually interact with the stable pstate) so I think they should be
dropped and exposed some other way. Setting the profile modes via
force_performance_level forces the clocks and disables clock and power gating
19 matches
Mail list logo
