RE: [PATCH] Release the mutex hold before backtracing for not supported mxgpu.

2017-12-19 Thread Yu, Xiangliang 
> This patch releases the mutex held soon before entering the initialization
> function in case the device doesn't support mxgpu.
> 
> Signed-off-by: José Pekkarinen 
> ---
>  drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
> b/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
> index c25a831f94ec..cac1d8b003e6 100644
> --- a/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
> +++ b/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
> @@ -307,6 +307,7 @@ void xgpu_vi_init_golden_registers(struct
> amdgpu_device *adev)
> 
> xgpu_tonga_golden_common_all));
>   break;
>   default:
> + mutex_unlock(>grbm_idx_mutex);
>   BUG_ON("Doesn't support chip type.\n");
>   break;
>   }

The release mutex in here has no meaning as kernel will hang later. And Alex 
has submitted patch to check ASIC IP during detecting SRIOV, so we can't see 
the case anymore. Please drop the patch.

Thanks!

> --
> 2.13.6
> 
> ___
> 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 1/2] drm/amdgpu: only check mmBIF_IOV_FUNC_IDENTIFIER on tonga/fiji

2017-12-19 Thread Yu, Xiangliang 
Reviewed-by: Xiangliang Yu 


> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Alex Deucher
> Sent: Tuesday, December 19, 2017 11:07 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander 
> Subject: [PATCH 1/2] drm/amdgpu: only check
> mmBIF_IOV_FUNC_IDENTIFIER on tonga/fiji
> 
> We only support SR-IOV on tonga/fiji.  Don't check this register on other VI
> parts.
> 
> Signed-off-by: Alex Deucher 
> ---
>  drivers/gpu/drm/amd/amdgpu/vi.c | 21 +
>  1 file changed, 13 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/vi.c
> b/drivers/gpu/drm/amd/amdgpu/vi.c index d9bb26322850..c59b37365e4d
> 100644
> --- a/drivers/gpu/drm/amd/amdgpu/vi.c
> +++ b/drivers/gpu/drm/amd/amdgpu/vi.c
> @@ -449,14 +449,19 @@ static bool vi_read_bios_from_rom(struct
> amdgpu_device *adev,
> 
>  static void vi_detect_hw_virtualization(struct amdgpu_device *adev)  {
> - uint32_t reg = RREG32(mmBIF_IOV_FUNC_IDENTIFIER);
> - /* bit0: 0 means pf and 1 means vf */
> - /* bit31: 0 means disable IOV and 1 means enable */
> - if (reg & 1)
> - adev->virt.caps |= AMDGPU_SRIOV_CAPS_IS_VF;
> -
> - if (reg & 0x8000)
> - adev->virt.caps |= AMDGPU_SRIOV_CAPS_ENABLE_IOV;
> + uint32_t reg = 0;
> +
> + if (adev->asic_type == CHIP_TONGA ||
> + adev->asic_type == CHIP_FIJI) {
> +reg = RREG32(mmBIF_IOV_FUNC_IDENTIFIER);
> +/* bit0: 0 means pf and 1 means vf */
> +/* bit31: 0 means disable IOV and 1 means enable */
> +if (reg & 1)
> +adev->virt.caps |= AMDGPU_SRIOV_CAPS_IS_VF;
> +
> +if (reg & 0x8000)
> +adev->virt.caps |= AMDGPU_SRIOV_CAPS_ENABLE_IOV;
> + }
> 
>   if (reg == 0) {
>   if (is_virtual_machine()) /* passthrough mode exclus sr-iov
> mode */
> --
> 2.13.6
> 
> ___
> 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] drm/amdgpu: Simplify amdgpu_lockup_timeout usage.

2017-12-19 Thread Christian König 
Yeah, that is a known issue which came to front again because Andrey's 
patch is slightly buggy.


Please test and review the attached (only compile tested) fix for 
Andrey's patch.


Still working on finding the root cause, but so far didn't had time for 
that.


Regards,
Christian.

Am 19.12.2017 um 18:26 schrieb Michel Dänzer:

On 2017-12-13 08:44 PM, Andrey Grodzovsky wrote:

With introduction of amdgpu_gpu_recovery we don't need any more
to rely on amdgpu_lockup_timeout == 0 for disabling GPU reset.

Signed-off-by: Andrey Grodzovsky 

Since this change landed, I'm once again unable to finish a piglit run
on my development machine, see the attached dmesg output (happens pretty
quickly, after ~5% of piglit tests have run). I realized that with
lockup_timeout != 0, the

WARN_ON_ONCE(bo->tbo.mem.mem_type == TTM_PL_SYSTEM);

at the top of amdgpu_bo_gpu_offset has been triggering since the 4.15
development cycle. See the bisection result below. Note that I'm not
100% sure this is the correct guilty commit, since it's probably been
the most painful bisection I've ever done so far (14 skips, had to
revert 4 commits causing other regressions). But I'm quite sure this
regression happened in the
84d43463a2d09c28c9222fbb7d1082c078e2523a..3ff8a0e90ac26f84ed7b0aa344efce695c08
range.


3ff8a0e90ac26f84ed7b0aa344efce695c08 is the first bad commit
commit 3ff8a0e90ac26f84ed7b0aa344efce695c08
Author: Christian König 
Date:   Thu Aug 3 14:02:13 2017 +0200

 drm/amdgpu: track evicted page tables v2

 Instead of validating all page tables when one was evicted,
 track which one needs a validation.

 v2: simplify amdgpu_vm_ready as well

 Signed-off-by: Christian König 
 Reviewed-by: Alex Deucher  (v1)
 Reviewed-by: Chunming Zhou 




>From 769eb5d08910e16058902fada499d21655ccdba4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Christian=20K=C3=B6nig?= 
Date: Tue, 19 Dec 2017 18:44:43 +0100
Subject: [PATCH] drm/amdgpu: fix test for shadow page tables
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

They don't work 100% correctly at the moment.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 3c87b7f902c9..9fac284315cb 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -2833,7 +2833,11 @@ bool amdgpu_need_backup(struct amdgpu_device *adev)
 	if (adev->flags & AMD_IS_APU)
 		return false;
 
-	return amdgpu_gpu_recovery;
+	if (amdgpu_gpu_recovery == 0 ||
+	(amdgpu_gpu_recovery == -1  && !amdgpu_sriov_vf(adev)))
+		return false;
+
+	return true;
 }
 
 static int amdgpu_recover_vram_from_shadow(struct amdgpu_device *adev,
-- 
2.11.0

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

Re: [PATCH] drm/amdgpu: Simplify amdgpu_lockup_timeout usage.

2017-12-19 Thread Michel Dänzer 
On 2017-12-13 08:44 PM, Andrey Grodzovsky wrote:
> With introduction of amdgpu_gpu_recovery we don't need any more
> to rely on amdgpu_lockup_timeout == 0 for disabling GPU reset.
> 
> Signed-off-by: Andrey Grodzovsky 

Since this change landed, I'm once again unable to finish a piglit run
on my development machine, see the attached dmesg output (happens pretty
quickly, after ~5% of piglit tests have run). I realized that with
lockup_timeout != 0, the

WARN_ON_ONCE(bo->tbo.mem.mem_type == TTM_PL_SYSTEM);

at the top of amdgpu_bo_gpu_offset has been triggering since the 4.15
development cycle. See the bisection result below. Note that I'm not
100% sure this is the correct guilty commit, since it's probably been
the most painful bisection I've ever done so far (14 skips, had to
revert 4 commits causing other regressions). But I'm quite sure this
regression happened in the
84d43463a2d09c28c9222fbb7d1082c078e2523a..3ff8a0e90ac26f84ed7b0aa344efce695c08
range.


3ff8a0e90ac26f84ed7b0aa344efce695c08 is the first bad commit
commit 3ff8a0e90ac26f84ed7b0aa344efce695c08
Author: Christian König 
Date:   Thu Aug 3 14:02:13 2017 +0200

drm/amdgpu: track evicted page tables v2

Instead of validating all page tables when one was evicted,
track which one needs a validation.

v2: simplify amdgpu_vm_ready as well

Signed-off-by: Christian König 
Reviewed-by: Alex Deucher  (v1)
Reviewed-by: Chunming Zhou 


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
Dec 19 18:20:17 kaveri kernel: [   72.365066] WARNING: CPU: 7 PID: 3412 at drivers/gpu/drm//amd/amdgpu/amdgpu_object.c:1027 amdgpu_bo_gpu_offset+0x2b7/0x380 [amdgpu]
Dec 19 18:20:17 kaveri kernel: [   72.365089] Modules linked in: lz4 lz4_compress cpufreq_powersave cpufreq_userspace cpufreq_conservative binfmt_misc nls_ascii nls_cp437 vfat fat edac_mce_amd kvm amdkfd(O) irqbypass crct10dif_pclmul crc32_pclmul snd_hda_codec_realtek ghash_clmulni_intel amdgpu(O) radeon(O) pcbc snd_hda_codec_generic snd_hda_codec_hdmi efi_pstore ttm(O) snd_hda_intel drm_kms_helper(O) ppdev wmi_bmof snd_hda_codec drm(O) snd_hda_core snd_hwdep aesni_intel ccp snd_pcm aes_x86_64 crypto_simd i2c_algo_bit glue_helper fb_sys_fops snd_timer r8169 syscopyarea sp5100_tco sysfillrect cryptd efivars pcspkr snd mfd_core sysimgblt soundcore rng_core i2c_piix4 mii sg parport_pc parport i2c_designware_platform i2c_designware_core wmi button acpi_cpufreq tcp_bbr sch_fq nct6775 hwmon_vid sunrpc efivarfs ip_tables x_tables autofs4
Dec 19 18:20:17 kaveri kernel: [   72.365154]  ext4 crc16 mbcache jbd2 fscrypto dm_mod raid10 raid1 raid0 multipath linear md_mod sd_mod evdev hid_generic usbhid hid ahci libahci xhci_pci crc32c_intel libata xhci_hcd usbcore scsi_mod shpchp gpio_amdpt gpio_generic
Dec 19 18:20:17 kaveri kernel: [   72.365179] CPU: 7 PID: 3412 Comm: amdgpu_cs:0 Tainted: G   O4.13.0-rc5+ #53
Dec 19 18:20:17 kaveri kernel: [   72.365185] Hardware name: Micro-Star International Co., Ltd. MS-7A34/B350 TOMAHAWK (MS-7A34), BIOS 1.80 09/13/2017
Dec 19 18:20:17 kaveri kernel: [   72.365187] task: 88039fc18f80 task.stack: 880392cb
Dec 19 18:20:17 kaveri kernel: [   72.365231] RIP: 0010:amdgpu_bo_gpu_offset+0x2b7/0x380 [amdgpu]
Dec 19 18:20:17 kaveri kernel: [   72.365235] RSP: 0018:880392cb6b30 EFLAGS: 00010246
Dec 19 18:20:17 kaveri kernel: [   72.365237] RAX:  RBX: 880384f9 RCX: 
Dec 19 18:20:17 kaveri kernel: [   72.365239] RDX: 880392cb6b98 RSI:  RDI: 880384f9
Dec 19 18:20:17 kaveri kernel: [   72.365242] RBP: 880392cb6bc0 R08: 880392cb6cc8 R09: 0004
Dec 19 18:20:17 kaveri kernel: [   72.365244] R10: 00100480 R11: 00100460 R12: 880384f900b4
Dec 19 18:20:17 kaveri kernel: [   72.365245] R13: 880358102800 R14: 110072596d67 R15: dc00
Dec 19 18:20:17 kaveri kernel: [   72.365247] FS:  7fc0a896e700() GS:8803ae5c() knlGS:
Dec 19 18:20:17 kaveri kernel: [   72.365249] CS:  0010 DS:  ES:  CR0: 80050033
Dec 19 18:20:17 kaveri kernel: [   72.365250] CR2: 7f6a85312000 CR3: 0003806de000 CR4: 003406e0
Dec 19 18:20:17 kaveri kernel: [   72.365251] Call Trace:
Dec 19 18:20:17 kaveri kernel: [   72.365298]  ? amdgpu_bo_fence+0x70/0x70 [amdgpu]
Dec 19 18:20:17 kaveri kernel: [   72.365305]  ? unwind_get_return_address+0x66/0xb0
Dec 19 18:20:17 kaveri kernel: [   72.365351]  amdgpu_vm_update_ptes+0x4d5/0xa20 [amdgpu]
Dec 19 18:20:17 kaveri kernel: [   72.365397]  ? amdgpu_vm_free_mapping.isra.21+0x70/0x70 [amdgpu]
Dec 19 18:20:17 kaveri kernel: [   72.365450]  ? amdgpu_vm_free_mapping.isra.21+0x70/0x70 [amdgpu]
Dec 19 18:20:17 kaveri

[PATCH] Release the mutex hold before backtracing for not supported mxgpu.

2017-12-19 Thread José Pekkarinen 
This patch releases the mutex held soon before entering the initialization
function in case the device doesn't support mxgpu.

Signed-off-by: José Pekkarinen 
---
 drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c 
b/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
index c25a831f94ec..cac1d8b003e6 100644
--- a/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
+++ b/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
@@ -307,6 +307,7 @@ void xgpu_vi_init_golden_registers(struct amdgpu_device 
*adev)
 xgpu_tonga_golden_common_all));
break;
default:
+   mutex_unlock(>grbm_idx_mutex);
BUG_ON("Doesn't support chip type.\n");
break;
}
-- 
2.13.6

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

Re: [trivial PATCH] treewide: Align function definition open/close braces

2017-12-19 Thread Mauro Carvalho Chehab 
Em Sun, 17 Dec 2017 16:28:44 -0800
Joe Perches  escreveu:

> Some functions definitions have either the initial open brace and/or
> the closing brace outside of column 1.
> 
> Move those braces to column 1.
> 
> This allows various function analyzers like gnu complexity to work
> properly for these modified functions.
> 
> Miscellanea:
> 
> o Remove extra trailing ; and blank line from xfs_agf_verify
> 
> Signed-off-by: Joe Perches 

For the media patch:

Acked-by: Mauro Carvalho Chehab 

> ---
> git diff -w shows no difference other than the above 'Miscellanea'
> 
> (this is against -next, but it applies against Linus' tree
>  with a couple offsets)
> 
>  arch/x86/include/asm/atomic64_32.h   |  2 +-
>  drivers/acpi/custom_method.c |  2 +-
>  drivers/acpi/fan.c   |  2 +-
>  drivers/gpu/drm/amd/display/dc/core/dc.c |  2 +-
>  drivers/media/i2c/msp3400-kthreads.c |  2 +-
>  drivers/message/fusion/mptsas.c  |  2 +-
>  drivers/net/ethernet/qlogic/netxen/netxen_nic_init.c |  2 +-
>  drivers/net/wireless/ath/ath9k/xmit.c|  2 +-
>  drivers/platform/x86/eeepc-laptop.c  |  2 +-
>  drivers/rtc/rtc-ab-b5ze-s3.c |  2 +-
>  drivers/scsi/dpt_i2o.c   |  2 +-
>  drivers/scsi/sym53c8xx_2/sym_glue.c  |  2 +-
>  fs/locks.c   |  2 +-
>  fs/ocfs2/stack_user.c|  2 +-
>  fs/xfs/libxfs/xfs_alloc.c|  5 ++---
>  fs/xfs/xfs_export.c  |  2 +-
>  kernel/audit.c   |  6 +++---
>  kernel/trace/trace_printk.c  |  4 ++--
>  lib/raid6/sse2.c | 14 +++---
>  sound/soc/fsl/fsl_dma.c  |  2 +-
>  20 files changed, 30 insertions(+), 31 deletions(-)
> 
> diff --git a/arch/x86/include/asm/atomic64_32.h 
> b/arch/x86/include/asm/atomic64_32.h
> index 97c46b8169b7..d4d4883080fa 100644
> --- a/arch/x86/include/asm/atomic64_32.h
> +++ b/arch/x86/include/asm/atomic64_32.h
> @@ -122,7 +122,7 @@ static inline long long atomic64_read(const atomic64_t *v)
>   long long r;
>   alternative_atomic64(read, "=" (r), "c" (v) : "memory");
>   return r;
> - }
> +}
>  
>  /**
>   * atomic64_add_return - add and return
> diff --git a/drivers/acpi/custom_method.c b/drivers/acpi/custom_method.c
> index c68e72414a67..e967c1173ba3 100644
> --- a/drivers/acpi/custom_method.c
> +++ b/drivers/acpi/custom_method.c
> @@ -94,7 +94,7 @@ static void __exit acpi_custom_method_exit(void)
>  {
>   if (cm_dentry)
>   debugfs_remove(cm_dentry);
> - }
> +}
>  
>  module_init(acpi_custom_method_init);
>  module_exit(acpi_custom_method_exit);
> diff --git a/drivers/acpi/fan.c b/drivers/acpi/fan.c
> index 6cf4988206f2..3563103590c6 100644
> --- a/drivers/acpi/fan.c
> +++ b/drivers/acpi/fan.c
> @@ -219,7 +219,7 @@ fan_set_cur_state(struct thermal_cooling_device *cdev, 
> unsigned long state)
>   return fan_set_state_acpi4(device, state);
>   else
>   return fan_set_state(device, state);
> - }
> +}
>  
>  static const struct thermal_cooling_device_ops fan_cooling_ops = {
>   .get_max_state = fan_get_max_state,
> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c 
> b/drivers/gpu/drm/amd/display/dc/core/dc.c
> index d1488d5ee028..1e0d1e7c5324 100644
> --- a/drivers/gpu/drm/amd/display/dc/core/dc.c
> +++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
> @@ -461,7 +461,7 @@ static void disable_dangling_plane(struct dc *dc, struct 
> dc_state *context)
>   
> **/
>  
>  struct dc *dc_create(const struct dc_init_data *init_params)
> - {
> +{
>   struct dc *dc = kzalloc(sizeof(*dc), GFP_KERNEL);
>   unsigned int full_pipe_count;
>  
> diff --git a/drivers/media/i2c/msp3400-kthreads.c 
> b/drivers/media/i2c/msp3400-kthreads.c
> index 4dd01e9f553b..dc6cb8d475b3 100644
> --- a/drivers/media/i2c/msp3400-kthreads.c
> +++ b/drivers/media/i2c/msp3400-kthreads.c
> @@ -885,7 +885,7 @@ static int msp34xxg_modus(struct i2c_client *client)
>  }
>  
>  static void msp34xxg_set_source(struct i2c_client *client, u16 reg, int in)
> - {
> +{
>   struct msp_state *state = to_state(i2c_get_clientdata(client));
>   int source, matrix;
>  
> diff --git a/drivers/message/fusion/mptsas.c b/drivers/message/fusion/mptsas.c
> index 345f6035599e..69a62d23514b 100644
> --- a/drivers/message/fusion/mptsas.c
> +++ b/drivers/message/fusion/mptsas.c
> @@ -2968,7 +2968,7 @@ mptsas_exp_repmanufacture_info(MPT_ADAPTER *ioc,
>   mutex_unlock(>sas_mgmt.mutex);
>  out:
>   return ret;
> - }
> +}
>  
>  static void
>

[PATCH 2/2] drm/amdgpu: use defines for mmBIF_IOV_FUNC_IDENTIFIER fields

2017-12-19 Thread Alex Deucher 
Rather than magic numbers.

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/amd/amdgpu/vi.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/vi.c b/drivers/gpu/drm/amd/amdgpu/vi.c
index c59b37365e4d..da2b99c2d95f 100644
--- a/drivers/gpu/drm/amd/amdgpu/vi.c
+++ b/drivers/gpu/drm/amd/amdgpu/vi.c
@@ -455,11 +455,10 @@ static void vi_detect_hw_virtualization(struct 
amdgpu_device *adev)
adev->asic_type == CHIP_FIJI) {
   reg = RREG32(mmBIF_IOV_FUNC_IDENTIFIER);
   /* bit0: 0 means pf and 1 means vf */
-  /* bit31: 0 means disable IOV and 1 means enable */
-  if (reg & 1)
+  if (REG_GET_FIELD(reg, BIF_IOV_FUNC_IDENTIFIER, FUNC_IDENTIFIER))
   adev->virt.caps |= AMDGPU_SRIOV_CAPS_IS_VF;
-
-  if (reg & 0x8000)
+  /* bit31: 0 means disable IOV and 1 means enable */
+  if (REG_GET_FIELD(reg, BIF_IOV_FUNC_IDENTIFIER, IOV_ENABLE))
   adev->virt.caps |= AMDGPU_SRIOV_CAPS_ENABLE_IOV;
}
 
-- 
2.13.6

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

[PATCH 1/2] drm/amdgpu: only check mmBIF_IOV_FUNC_IDENTIFIER on tonga/fiji

2017-12-19 Thread Alex Deucher 
We only support SR-IOV on tonga/fiji.  Don't check this register
on other VI parts.

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/amd/amdgpu/vi.c | 21 +
 1 file changed, 13 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/vi.c b/drivers/gpu/drm/amd/amdgpu/vi.c
index d9bb26322850..c59b37365e4d 100644
--- a/drivers/gpu/drm/amd/amdgpu/vi.c
+++ b/drivers/gpu/drm/amd/amdgpu/vi.c
@@ -449,14 +449,19 @@ static bool vi_read_bios_from_rom(struct amdgpu_device 
*adev,
 
 static void vi_detect_hw_virtualization(struct amdgpu_device *adev)
 {
-   uint32_t reg = RREG32(mmBIF_IOV_FUNC_IDENTIFIER);
-   /* bit0: 0 means pf and 1 means vf */
-   /* bit31: 0 means disable IOV and 1 means enable */
-   if (reg & 1)
-   adev->virt.caps |= AMDGPU_SRIOV_CAPS_IS_VF;
-
-   if (reg & 0x8000)
-   adev->virt.caps |= AMDGPU_SRIOV_CAPS_ENABLE_IOV;
+   uint32_t reg = 0;
+
+   if (adev->asic_type == CHIP_TONGA ||
+   adev->asic_type == CHIP_FIJI) {
+  reg = RREG32(mmBIF_IOV_FUNC_IDENTIFIER);
+  /* bit0: 0 means pf and 1 means vf */
+  /* bit31: 0 means disable IOV and 1 means enable */
+  if (reg & 1)
+  adev->virt.caps |= AMDGPU_SRIOV_CAPS_IS_VF;
+
+  if (reg & 0x8000)
+  adev->virt.caps |= AMDGPU_SRIOV_CAPS_ENABLE_IOV;
+   }
 
if (reg == 0) {
if (is_virtual_machine()) /* passthrough mode exclus sr-iov 
mode */
-- 
2.13.6

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

PCIe3 atomics requirement for amdkfd

2017-12-19 Thread Tom Stellard 
Hi,

How hard of a requirement is PCIe3 atomics for dGPUs with the amdkfd
kernel driver?  Is it possible to make modifications to the runtime/kernel
driver to drop this requirement?

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

Re: [PATCH 4/4] drm/amd/pp: implement force_dpm_level on rv

2017-12-19 Thread Alex Deucher 
On Tue, Dec 19, 2017 at 3:11 AM, Rex Zhu  wrote:
> user can change engine/mclk/soc/vcn clocks on Rv
>
> v3: add smu version check
> v2: fix no return statement

Reviewed-by: Alex Deucher 

>
> Signed-off-by: Rex Zhu 
> ---
>  drivers/gpu/drm/amd/powerplay/hwmgr/rv_hwmgr.c | 123 
> +
>  drivers/gpu/drm/amd/powerplay/hwmgr/rv_hwmgr.h |  15 +++
>  2 files changed, 138 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/rv_hwmgr.c 
> b/drivers/gpu/drm/amd/powerplay/hwmgr/rv_hwmgr.c
> index ae11a85..569073e 100644
> --- a/drivers/gpu/drm/amd/powerplay/hwmgr/rv_hwmgr.c
> +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/rv_hwmgr.c
> @@ -484,6 +484,129 @@ static int rv_hwmgr_backend_fini(struct pp_hwmgr *hwmgr)
>  static int rv_dpm_force_dpm_level(struct pp_hwmgr *hwmgr,
> enum amd_dpm_forced_level level)
>  {
> +   if (hwmgr->smu_version < 0x1E3700) {
> +   pr_info("smu firmware version too old, can not set dpm 
> level\n");
> +   return 0;
> +   }
> +
> +   switch (level) {
> +   case AMD_DPM_FORCED_LEVEL_HIGH:
> +   case AMD_DPM_FORCED_LEVEL_PROFILE_PEAK:
> +   smum_send_msg_to_smc_with_parameter(hwmgr,
> +   PPSMC_MSG_SetHardMinGfxClk,
> +   RAVEN_UMD_PSTATE_PEAK_GFXCLK);
> +   smum_send_msg_to_smc_with_parameter(hwmgr,
> +   
> PPSMC_MSG_SetHardMinFclkByFreq,
> +   RAVEN_UMD_PSTATE_PEAK_FCLK);
> +   smum_send_msg_to_smc_with_parameter(hwmgr,
> +   
> PPSMC_MSG_SetHardMinSocclkByFreq,
> +   RAVEN_UMD_PSTATE_PEAK_SOCCLK);
> +   smum_send_msg_to_smc_with_parameter(hwmgr,
> +   PPSMC_MSG_SetHardMinVcn,
> +   RAVEN_UMD_PSTATE_VCE);
> +
> +   smum_send_msg_to_smc_with_parameter(hwmgr,
> +   PPSMC_MSG_SetSoftMaxGfxClk,
> +   RAVEN_UMD_PSTATE_PEAK_GFXCLK);
> +   smum_send_msg_to_smc_with_parameter(hwmgr,
> +   
> PPSMC_MSG_SetSoftMaxFclkByFreq,
> +   RAVEN_UMD_PSTATE_PEAK_FCLK);
> +   smum_send_msg_to_smc_with_parameter(hwmgr,
> +   
> PPSMC_MSG_SetSoftMaxSocclkByFreq,
> +   RAVEN_UMD_PSTATE_PEAK_SOCCLK);
> +   smum_send_msg_to_smc_with_parameter(hwmgr,
> +   PPSMC_MSG_SetSoftMaxVcn,
> +   RAVEN_UMD_PSTATE_VCE);
> +   break;
> +   case AMD_DPM_FORCED_LEVEL_PROFILE_MIN_SCLK:
> +   smum_send_msg_to_smc_with_parameter(hwmgr,
> +   PPSMC_MSG_SetHardMinGfxClk,
> +   RAVEN_UMD_PSTATE_MIN_GFXCLK);
> +   smum_send_msg_to_smc_with_parameter(hwmgr,
> +   PPSMC_MSG_SetSoftMaxGfxClk,
> +   RAVEN_UMD_PSTATE_MIN_GFXCLK);
> +   break;
> +   case AMD_DPM_FORCED_LEVEL_PROFILE_MIN_MCLK:
> +   smum_send_msg_to_smc_with_parameter(hwmgr,
> +   
> PPSMC_MSG_SetHardMinFclkByFreq,
> +   RAVEN_UMD_PSTATE_MIN_FCLK);
> +   smum_send_msg_to_smc_with_parameter(hwmgr,
> +   
> PPSMC_MSG_SetSoftMaxFclkByFreq,
> +   RAVEN_UMD_PSTATE_MIN_FCLK);
> +   break;
> +   case AMD_DPM_FORCED_LEVEL_PROFILE_STANDARD:
> +   smum_send_msg_to_smc_with_parameter(hwmgr,
> +   PPSMC_MSG_SetHardMinGfxClk,
> +   RAVEN_UMD_PSTATE_GFXCLK);
> +   smum_send_msg_to_smc_with_parameter(hwmgr,
> +   
> PPSMC_MSG_SetHardMinFclkByFreq,
> +   RAVEN_UMD_PSTATE_FCLK);
> +   smum_send_msg_to_smc_with_parameter(hwmgr,
> +   
> PPSMC_MSG_SetHardMinSocclkByFreq,
> +   RAVEN_UMD_PSTATE_SOCCLK);
> +   smum_send_msg_to_smc_with_parameter(hwmgr,
> +   PPSMC_MSG_SetHardMinVcn,
> +   RAVEN_UMD_PSTATE_VCE);
>

Re: [PATCH 3/4] drm/amd/pp: get Rv smu_version and notify amdgpu

2017-12-19 Thread Alex Deucher 
On Tue, Dec 19, 2017 at 3:11 AM, Rex Zhu  wrote:

Please include a patch description.  E.g.,
The smu firmware is loaded by the sbios on APUs, so query it from the
smu and update the
smu fw version info that is reported to userspace.

With that fixed:
Reviewed-by: Alex Deucher 

Can you update CZ/ST as well if you get a chance?

Thanks,

Alex


> Signed-off-by: Rex Zhu 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c  | 3 +++
>  drivers/gpu/drm/amd/powerplay/smumgr/rv_smumgr.c | 8 
>  2 files changed, 11 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c
> index 85d2149..13607e2 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c
> @@ -801,6 +801,9 @@ static int amdgpu_cgs_get_firmware_info(struct cgs_device 
> *cgs_device,
> else
> strcpy(fw_name, 
> "amdgpu/vega10_smc.bin");
> break;
> +   case CHIP_RAVEN:
> +   adev->pm.fw_version = info->version;
> +   return 0;
> default:
> DRM_ERROR("SMC firmware not supported\n");
> return -EINVAL;
> diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/rv_smumgr.c 
> b/drivers/gpu/drm/amd/powerplay/smumgr/rv_smumgr.c
> index b98ade6..2d662b4 100644
> --- a/drivers/gpu/drm/amd/powerplay/smumgr/rv_smumgr.c
> +++ b/drivers/gpu/drm/amd/powerplay/smumgr/rv_smumgr.c
> @@ -305,6 +305,14 @@ static int rv_smu_fini(struct pp_hwmgr *hwmgr)
>
>  static int rv_start_smu(struct pp_hwmgr *hwmgr)
>  {
> +   struct cgs_firmware_info info = {0};
> +
> +   smum_send_msg_to_smc(hwmgr, PPSMC_MSG_GetSmuVersion);
> +   rv_read_arg_from_smc(hwmgr, >smu_version);
> +   info.version = hwmgr->smu_version >> 8;
> +
> +   cgs_get_firmware_info(hwmgr->device, CGS_UCODE_ID_SMU, );
> +
> if (rv_verify_smc_interface(hwmgr))
> return -EINVAL;
> if (rv_smc_enable_sdma(hwmgr))
> --
> 1.9.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 2/4] drm/amd/pp: update smu_version value for CI/VI

2017-12-19 Thread Alex Deucher 
On Tue, Dec 19, 2017 at 3:11 AM, Rex Zhu  wrote:
> Change-Id: Ia55a0bc2cde45cb995d92ff054e57b07ed548f08

Missing your signed-off-by.  Please also include a patch description.  E.g.,
Set the new common smu firmware version for smu7 parts (CI and VI).

With those things fixed:
Reviewed-by: Alex Deucher 

> ---
>  drivers/gpu/drm/amd/powerplay/smumgr/ci_smumgr.c  | 1 +
>  drivers/gpu/drm/amd/powerplay/smumgr/iceland_smumgr.c | 2 +-
>  drivers/gpu/drm/amd/powerplay/smumgr/smu7_smumgr.c| 2 +-
>  3 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/ci_smumgr.c 
> b/drivers/gpu/drm/amd/powerplay/smumgr/ci_smumgr.c
> index c6c741a..0b4a556 100644
> --- a/drivers/gpu/drm/amd/powerplay/smumgr/ci_smumgr.c
> +++ b/drivers/gpu/drm/amd/powerplay/smumgr/ci_smumgr.c
> @@ -2316,6 +2316,7 @@ static int ci_load_smc_ucode(struct pp_hwmgr *hwmgr)
> cgs_get_firmware_info(hwmgr->device, CGS_UCODE_ID_SMU, );
>
> hwmgr->is_kicker = info.is_kicker;
> +   hwmgr->smu_version = info.version;
> byte_count = info.image_size;
> src = (uint8_t *)info.kptr;
> start_addr = info.ucode_start_address;
> diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/iceland_smumgr.c 
> b/drivers/gpu/drm/amd/powerplay/smumgr/iceland_smumgr.c
> index d75bb99..1253126 100644
> --- a/drivers/gpu/drm/amd/powerplay/smumgr/iceland_smumgr.c
> +++ b/drivers/gpu/drm/amd/powerplay/smumgr/iceland_smumgr.c
> @@ -204,7 +204,7 @@ static int iceland_smu_upload_firmware_image(struct 
> pp_hwmgr *hwmgr)
> pr_err("[ powerplay ] SMC address is beyond the SMC RAM 
> area\n");
> return -EINVAL;
> }
> -
> +   hwmgr->smu_version = info.version;
> /* wait for smc boot up */
> PHM_WAIT_INDIRECT_FIELD_UNEQUAL(hwmgr, SMC_IND,
>  RCU_UC_EVENTS, boot_seq_done, 0);
> diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/smu7_smumgr.c 
> b/drivers/gpu/drm/amd/powerplay/smumgr/smu7_smumgr.c
> index 7f5359a..cb95e88 100644
> --- a/drivers/gpu/drm/amd/powerplay/smumgr/smu7_smumgr.c
> +++ b/drivers/gpu/drm/amd/powerplay/smumgr/smu7_smumgr.c
> @@ -535,7 +535,7 @@ int smu7_upload_smu_firmware_image(struct pp_hwmgr *hwmgr)
> smu7_convert_fw_type_to_cgs(UCODE_ID_SMU_SK), );
>
> hwmgr->is_kicker = info.is_kicker;
> -
> +   hwmgr->smu_version = info.version;
> result = smu7_upload_smc_firmware_data(hwmgr, info.image_size, 
> (uint32_t *)info.kptr, SMU7_SMC_SIZE);
>
> return result;
> --
> 1.9.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 1/4] drm/amd/pp: move smu_version out vega to hwmgr

2017-12-19 Thread Alex Deucher 
On Tue, Dec 19, 2017 at 3:11 AM, Rex Zhu  wrote:

Please include a better patch description.  Something like:
Move the smu_version to common code so it can be shared by other asics.

With that fixed:
Reviewed-by: Alex Deucher 

> Change-Id: Ie8c32663aa0d61a1dfdd8e019509cb551f137aa0
> Signed-off-by: Rex Zhu 
> ---
>  drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c | 8 
>  drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.h | 1 -
>  drivers/gpu/drm/amd/powerplay/inc/hwmgr.h  | 1 +
>  3 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c 
> b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
> index f0295fa..2d55dab 100644
> --- a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
> +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
> @@ -426,9 +426,9 @@ static void vega10_init_dpm_defaults(struct pp_hwmgr 
> *hwmgr)
> data->smu_features[GNLD_VR0HOT].supported = true;
>
> smum_send_msg_to_smc(hwmgr, PPSMC_MSG_GetSmuVersion);
> -   vega10_read_arg_from_smc(hwmgr, &(data->smu_version));
> +   vega10_read_arg_from_smc(hwmgr, &(hwmgr->smu_version));
> /* ACG firmware has major version 5 */
> -   if ((data->smu_version & 0xff00) == 0x500)
> +   if ((hwmgr->smu_version & 0xff00) == 0x500)
> data->smu_features[GNLD_ACG].supported = true;
>
> if (data->registry_data.didt_support)
> @@ -2879,8 +2879,8 @@ static int vega10_enable_dpm_tasks(struct pp_hwmgr 
> *hwmgr)
> "DPM is already running right , skipping 
> re-enablement!",
> return 0);
>
> -   if ((data->smu_version == 0x001c2c00) ||
> -   (data->smu_version == 0x001c2d00)) {
> +   if ((hwmgr->smu_version == 0x001c2c00) ||
> +   (hwmgr->smu_version == 0x001c2d00)) {
> tmp_result = smum_send_msg_to_smc_with_parameter(hwmgr,
> PPSMC_MSG_UpdatePkgPwrPidAlpha, 1);
> PP_ASSERT_WITH_CODE(!tmp_result,
> diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.h 
> b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.h
> index 8f7358c..e8507ff 100644
> --- a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.h
> +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.h
> @@ -387,7 +387,6 @@ struct vega10_hwmgr {
> struct vega10_smc_state_table  smc_state_table;
>
> uint32_t   config_telemetry;
> -   uint32_t   smu_version;
> uint32_t   acg_loop_state;
> uint32_t   mem_channels;
>  };
> diff --git a/drivers/gpu/drm/amd/powerplay/inc/hwmgr.h 
> b/drivers/gpu/drm/amd/powerplay/inc/hwmgr.h
> index 39eedbc..565fe08 100644
> --- a/drivers/gpu/drm/amd/powerplay/inc/hwmgr.h
> +++ b/drivers/gpu/drm/amd/powerplay/inc/hwmgr.h
> @@ -692,6 +692,7 @@ enum PP_TABLE_VERSION {
>  struct pp_hwmgr {
> uint32_t chip_family;
> uint32_t chip_id;
> +   uint32_t smu_version;
>
> uint32_t pp_table_version;
> void *device;
> --
> 1.9.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: Topaz mistakenly reported as vf

2017-12-19 Thread Deucher, Alexander 
Please make sure we only check that register on asics where it is relevant.  
There are a bunch of VI asics.  It should probably be restricted to tonga and 
fiji only.


Alex



From: Yu, Xiangliang
Sent: Tuesday, December 19, 2017 2:44 AM
To: José Pekkarinen
Cc: amd-gfx@lists.freedesktop.org; Deucher, Alexander; Koenig, Christian
Subject: RE: Topaz mistakenly reported as vf

We can add ASIC check in vi_detect_hw_virtualization function to avoid to entry 
error path.
I'll submit patch later.

Thanks!

> -Original Message-
> From: José Pekkarinen [mailto:jose.pekkari...@canonical.com]
> Sent: Tuesday, December 19, 2017 3:27 PM
> To: Yu, Xiangliang 
> Cc: amd-gfx@lists.freedesktop.org; Deucher, Alexander
> ; Koenig, Christian
> 
> Subject: Re: Topaz mistakenly reported as vf
>
> On Tuesday, 19 December 2017 09:19:02 EET Yu, Xiangliang wrote:
> > Topaz doesn't support SRIOV.
> >
>
>Hi Xiangliang,
>
>Allow me to ask for some attention, as I'm trying to say that given
> that Topaz is not having support, amdgpu_sriov_vf(adev) may return false
> and ignore the vi.c code path. Instead of it, it enters the code path and
> reaches the BUG_ON that states this is not supported.
>
>Thanks for coming back!
>
>José.
>

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

Re: [PATCH 28/37] drm/amdkfd: Add support for displaying VRAM usage

2017-12-19 Thread Oded Gabbay 
On Sat, Dec 16, 2017 at 10:36 PM, Felix Kühling
 wrote:
> Am 13.12.2017 um 08:23 schrieb Oded Gabbay:
>> On Tue, Dec 12, 2017 at 1:11 PM, Russell, Kent  wrote:
>>> That's alright. I admit that it was a bit self-serving in that I was asked 
>>> to get something somewhere to get the information out, and it was the 
>>> simplest solution. I can see if I can come up with a more acceptable option 
>>> in a future patch set, but for now I think Felix is right in that we can 
>>> just drop this one for now, it's definitely not worth holding up the rest 
>>> of the patches over.
>>>
>>>  Kent
>> Sure, np. I'll drop this for now.
>
> FWIW, there is precedent for this type of information in sysfs. See
> /sys/devices/virtual/drm/ttm/memory_accounting/kernel/used_memory.
>
> Regards,
>   Felix

I understand but I don't think that's applicable in our case. Who
works directly vs. ttm ? I'm not familiar with it enough but it seems
more like a debug feature.
I think it is better to follow amdgpu programming model.

Oded

>
>>
>> Oded
>>
>>> -Original Message-
>>> From: Kuehling, Felix
>>> Sent: Monday, December 11, 2017 2:52 PM
>>> To: Koenig, Christian; Oded Gabbay
>>> Cc: Russell, Kent; amd-gfx list
>>> Subject: Re: [PATCH 28/37] drm/amdkfd: Add support for displaying VRAM usage
>>>
>>> On 2017-12-11 12:28 PM, Christian König wrote:
 Am 11.12.2017 um 17:40 schrieb Oded Gabbay:
> On Mon, Dec 11, 2017 at 5:32 PM, Oded Gabbay 
> wrote:
>> On Sat, Dec 9, 2017 at 6:09 AM, Felix Kuehling
>>  wrote:
>>> From: Kent Russell 
>>>
>>> Add a sysfs file in topology (node/x/memory_banks/X/used_memory)
>>> that reports the current VRAM usage for that node. Only works for
>>> GPU nodes at this time.
>>>
>> As with patch 22 (perf counters), I would not expect this
>> information to be included in the topology. It doesn't describe the
>> properties of the device, but a current state.
>> Oded
> For example, in amdgpu, the VRAM usage is reported in the INFO IOCTL
> (AMDGPU_INFO_VRAM_USAGE). See function  amdgpu_info_ioctl()
 Yep, completely agree.

 That stuff is runtime properties and not static attribute nor
 configuration or setup.

 So either debugfs or IOCTL are the two best options as far as I can see.
>>> Right. I admit, this feature was a bit of a hack to quickly enable the HIP 
>>> team without having to change a bunch of interfaces (ioctls, Thunk, and 
>>> Runtime).
>>>
>>> This patch isn't critical for enabling dGPU support. I'll drop it for now 
>>> and we can reimplement it properly later.
>>>
>>> Regards,
>>>   Felix
>>>
 Christian.

> Thanks,
>
> Oded
>
>
>>> Signed-off-by: Kent Russell 
>>> Signed-off-by: Felix Kuehling 
>>> ---
>>>   drivers/gpu/drm/amd/amdkfd/kfd_topology.c | 49
>>> +++
>>>   drivers/gpu/drm/amd/amdkfd/kfd_topology.h |  4 ++-
>>>   2 files changed, 46 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_topology.c
>>> b/drivers/gpu/drm/amd/amdkfd/kfd_topology.c
>>> index 7f0d41e..7f04038 100644
>>> --- a/drivers/gpu/drm/amd/amdkfd/kfd_topology.c
>>> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_topology.c
>>> @@ -186,6 +186,8 @@ struct kfd_topology_device
>>> *kfd_create_topology_device(
>>>  sysfs_show_gen_prop(buffer, "%s %llu\n", name,
>>> value)
>>>   #define sysfs_show_32bit_val(buffer, value) \
>>>  sysfs_show_gen_prop(buffer, "%u\n", value)
>>> +#define sysfs_show_64bit_val(buffer, value) \
>>> +   sysfs_show_gen_prop(buffer, "%llu\n", value)
>>>   #define sysfs_show_str_val(buffer, value) \
>>>  sysfs_show_gen_prop(buffer, "%s\n", value)
>>>
>>> @@ -268,11 +270,23 @@ static ssize_t mem_show(struct kobject *kobj,
>>> struct attribute *attr,
>>>   {
>>>  ssize_t ret;
>>>  struct kfd_mem_properties *mem;
>>> +   uint64_t used_mem;
>>>
>>>  /* Making sure that the buffer is an empty string */
>>>  buffer[0] = 0;
>>>
>>> -   mem = container_of(attr, struct kfd_mem_properties, attr);
>>> +   if (strcmp(attr->name, "used_memory") == 0) {
>>> +   mem = container_of(attr, struct kfd_mem_properties,
>>> attr_used);
>>> +   if (mem->gpu) {
>>> +   used_mem =
>>> +mem->gpu->kfd2kgd->get_vram_usage(
>>> +
>>> mem->gpu->kgd);
>>> +   return sysfs_show_64bit_val(buffer,
>>> +used_mem);
>>> +   }
>>> +   /* TODO: Report APU/CPU-allocated memory; For now
>>> return 0 */
>>> +   return 0;

Re: [PATCH 22/37] drm/amdkfd: Add perf counters to topology

2017-12-19 Thread Oded Gabbay 
On Sat, Dec 16, 2017 at 10:48 PM, Felix Kühling
 wrote:
> Am 12.12.2017 um 09:15 schrieb Oded Gabbay:
>> On Mon, Dec 11, 2017 at 9:54 PM, Felix Kuehling  
>> wrote:
>>> On 2017-12-11 10:23 AM, Oded Gabbay wrote:
 On Sat, Dec 9, 2017 at 6:09 AM, Felix Kuehling  
 wrote:
> From: Amber Lin 
>
> For hardware blocks whose performance counters are accessed via MMIO
> registers, KFD provides the support for those privileged blocks. IOMMU is
> one of those privileged blocks. Most performance counter properties
> required by Thunk are available at 
> /sys/bus/event_source/devices/amd_iommu.
>  This patch adds properties to topology in KFD sysfs for information not
> available in /sys/bus/event_source/devices/amd_iommu. They are shown at
> /sys/devices/virtual/kfd/kfd/topology/nodes/0/perf/iommu/ formatted as
> /sys/devices/virtual/kfd/kfd/topology/nodes/0/perf//, 
> i.e.
> /sys/devices/virtual/kfd/kfd/topology/nodes/0/perf/iommu/max_concurrent.
> For dGPUs, who don't have IOMMU, nothing appears under
> /sys/devices/virtual/kfd/kfd/topology/nodes/0/perf.
 I don't feel comfortable with this patch. It seems to me you didn't
 have anywhere to put these counters so you just stuck them in a place
 the thunk already reads because it was "convenient" for you to do it.
 But, as you point out in a comment later, these counters have nothing
 to do with topology.
 So this just feels wrong and I would like to:

 a. get additional opinions on it. Christian ? Alex ? What do you think
 ? How the GPU's GFX counters are exposed ?
 b. Ask why not use IOCTL to get the counters ?
>>> I see the performance counter information similar to other information
>>> provided in the topology, such as memory, caches, CUs, etc. That's why
>>> it makes sense for me to report it in the topology.
>>>
>>> If this is controversial, I can drop the patch for now. It's not
>>> critically needed for enabling dGPU support.
>>>
>>> Regards,
>>>   Felix
>> Felix,
>> Is the perf counter information part of the snapshot that the thunk
>> takes before opening the device, or is it constantly being sampled ?
>> If its a oneshot thing, than I think that's somehow acceptable.
>
> It's currently read in hsaKmtOpen. But I think that could be changed to
> be done as part of the snapshot. Either way, it's a one-shot thing.
>
> Regards,
>   Felix
>
ok, so I think we can accept this as it is.

Oded

>>
>> Oded
>>
 btw, I tried to search for other drivers that do this (expose perf
 counters in sysfs) and didn't find any (it wasn't an exhaustive search
 so I may have missed).

 Thanks,
 Oded




> Signed-off-by: Amber Lin 
> Signed-off-by: Kent Russell 
> Signed-off-by: Felix Kuehling 
> ---
>  drivers/gpu/drm/amd/amdkfd/kfd_topology.c | 116 
> +-
>  drivers/gpu/drm/amd/amdkfd/kfd_topology.h |  13 
>  2 files changed, 127 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_topology.c 
> b/drivers/gpu/drm/amd/amdkfd/kfd_topology.c
> index 7fe7ee0..52d20f5 100644
> --- a/drivers/gpu/drm/amd/amdkfd/kfd_topology.c
> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_topology.c
> @@ -104,6 +104,7 @@ static void kfd_release_topology_device(struct 
> kfd_topology_device *dev)
> struct kfd_mem_properties *mem;
> struct kfd_cache_properties *cache;
> struct kfd_iolink_properties *iolink;
> +   struct kfd_perf_properties *perf;
>
> list_del(>list);
>
> @@ -128,6 +129,13 @@ static void kfd_release_topology_device(struct 
> kfd_topology_device *dev)
> kfree(iolink);
> }
>
> +   while (dev->perf_props.next != >perf_props) {
> +   perf = container_of(dev->perf_props.next,
> +   struct kfd_perf_properties, list);
> +   list_del(>list);
> +   kfree(perf);
> +   }
> +
> kfree(dev);
>  }
>
> @@ -162,6 +170,7 @@ struct kfd_topology_device 
> *kfd_create_topology_device(
> INIT_LIST_HEAD(>mem_props);
> INIT_LIST_HEAD(>cache_props);
> INIT_LIST_HEAD(>io_link_props);
> +   INIT_LIST_HEAD(>perf_props);
>
> list_add_tail(>list, device_list);
>
> @@ -328,6 +337,39 @@ static struct kobj_type cache_type = {
> .sysfs_ops = _ops,
>  };
>
> +/** Sysfs of Performance Counters **/
> +
> +struct kfd_perf_attr {
> +   struct kobj_attribute attr;
> +   uint32_t data;
> +};
> +
> +static ssize_t perf_show(struct kobject *kobj, struct

Re: Depth 30 enablement for ati-ddx + exa.

2017-12-19 Thread Michel Dänzer 
On 2017-12-18 11:36 PM, Mario Kleiner wrote:
> 
> 2/3 is actually Fredrik Hoeglunds work, which he sent out many
> years ago to the mailing list. I've tested it without problems
> on HD 5770 for the evergreen exa path, and on some HD 4000 series
> (rv630 iirc) for the r600 exa path, and it seems to work nicely.
> 
> It also has a r-b by me as in "looks good to me", but i'm
> not familiar enough with exa to really judge if it is complete or
> if something for some more unusual case might be missing.
> 
> I guess it also might need a signed off by Fredrik?

Yes, that would be good.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 3/3] Support exa screen color depth 30 on Linux 3.16 and later.

2017-12-19 Thread Michel Dänzer 
On 2017-12-18 11:36 PM, Mario Kleiner wrote:
> Linux 3.16's radeon-kms introduced 10 bpc fb support.
> Currently, as of X-Server 1.19, this works with exa accel,
> but not yet when using glamor acceleration.
> 
> Signed-off-by: Mario Kleiner 
> ---
>  man/radeon.man   |  3 ++-
>  src/radeon_kms.c | 17 +
>  2 files changed, 19 insertions(+), 1 deletion(-)
> 
> diff --git a/man/radeon.man b/man/radeon.man
> index f4441c4..d888ac0 100644
> --- a/man/radeon.man
> +++ b/man/radeon.man
> @@ -18,7 +18,8 @@ following features:
>  .PD 0
>  .TP 2
>  \(bu
> -Full support for 8-, 15-, 16- and 24-bit pixel depths;
> +Full support for 8-, 15-, 16- and 24-bit pixel depths, and for 30-bit depth 
> on Linux 3.16
> +and later with exa acceleration;

"EXA" (acronyms should be spelled with capital letters)


> @@ -1763,6 +1764,22 @@ Bool RADEONPreInit_KMS(ScrnInfoPtr pScrn, int flags)
>  
>  if (!RADEONPreInitAccel_KMS(pScrn))  goto fail;
>  
> +/* Depth 30 only supported since Linux 3.16 / kms driver minor version 
> 39 */
> +if ((pScrn->depth == 30) && (info->dri2.pKernelDRMVersion->version_minor 
> < 39)) {
> + xf86DrvMsg(pScrn->scrnIndex, X_ERROR,
> +"Given depth (%d) is not supported. Kernel too old. Needs 
> Linux 3.16+\n",
> +pScrn->depth);
> + goto fail;
> +}
> +
> +/* Depth 30 not yet supported under glamor. */
> +if ((pScrn->depth == 30) && info->use_glamor) {

There's no need for the nested parentheses in the tests.


> + xf86DrvMsg(pScrn->scrnIndex, X_ERROR,
> +"Given depth (%d) is not supported under glamor accel. 
> Select exa.\n",
> +pScrn->depth);
> + goto fail;
> +}

I'd check for glamor first, so that users with GCN cards don't upgrade
their kernel just to find out that it doesn't work with glamor anyway.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 1/3] Fix xf86HandleColormaps() crash at color depth 30.

2017-12-19 Thread Michel Dänzer 
On 2017-12-18 11:36 PM, Mario Kleiner wrote:
> The size of the X-Server pScreenPriv->PreAllocIndices
> array allocated within xf86HandleColormaps() is given
> by the given maxColors argument, but the range of
> indices by which the PreAllocIndices array is indexed
> in routines like CMapReinstallMap() seems to be up to
> 1023 on a 10 bpc / depth 30 screen, leading to an
> out-of-bounds access and server crash.
> 
> Raising maxColors to 1024 fixes the crash at server
> startup with X-Screen color depth 30.
> 
> Signed-off-by: Mario Kleiner 
> ---
>  src/drmmode_display.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/src/drmmode_display.c b/src/drmmode_display.c
> index 7ad3235..67db86e 100644
> --- a/src/drmmode_display.c
> +++ b/src/drmmode_display.c
> @@ -2730,8 +2730,9 @@ Bool drmmode_setup_colormap(ScreenPtr pScreen, 
> ScrnInfoPtr pScrn)
>  "Initializing kms color map\n");
>   if (!miCreateDefColormap(pScreen))
>   return FALSE;
> +
>   /* all radeons support 10 bit CLUTs */
> - if (!xf86HandleColormaps(pScreen, 256, 10,
> + if (!xf86HandleColormaps(pScreen, 1024, 10,
>NULL, NULL,
>CMAP_PALETTED_TRUECOLOR
>  #if 0 /* This option messes up text mode! (e...@suse.de) */
> 

The hardware CLUT isn't actually used at depth 30, so a better solution
would be to skip the xf86HandleColormaps call (and probably also set
xf86CrtcFuncsRec::gamma_set = NULL) for pScrn->depth == 30.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: Topaz mistakenly reported as vf

2017-12-19 Thread José Pekkarinen 
On Tuesday, 19 December 2017 09:19:02 EET Yu, Xiangliang wrote:
> Topaz doesn't support SRIOV.
> 

Hi Xiangliang,

Allow me to ask for some attention, as I'm trying to say that given 
that 
Topaz is not having support, amdgpu_sriov_vf(adev) may return false and ignore 
the vi.c code path. Instead of it, it enters the code path and reaches the 
BUG_ON that states this is not supported.

Thanks for coming back!

José.


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

Re: Topaz mistakenly reported as vf

2017-12-19 Thread José Pekkarinen 
On Sunday, 17 December 2017 21:20:49 EET José Pekkarinen wrote:
>   Hi,
> 
>   I hit an issue that seems to be a topaz discrete vga reporting it's a
> virtual function when my laptop is running on the battery. I received the
> following bactrace:
> 
> Dec 17 11:17:28 bee kernel: [   31.976810] kernel BUG at
> drivers/gpu/drm/amd/ amdgpu/mxgpu_vi.c:310!
> Dec 17 11:17:28 bee kernel: [   31.976815] invalid opcode:  [#1] SMP
> Dec 17 11:17:28 bee kernel: [   31.976831] Modules linked in: vfio_pci
> vfio_virqfd udl loop bfq arc4 iwlmvm mac80211 kvmgt vfio_mdev amdgpu(+) mdev
> vfio_iommu_type1 vfio i915 uvcvideo x86_pkg_temp_thermal videobuf2_vmalloc
> videobuf2_memo
> ps videobuf2_v4l2 intel_powerclamp videobuf2_core coretemp videodev
> kvm_intel kvm i2c_algo_bit rtsx_pci_sdmmc drm_kms_helper joydev mmc_core
> media mousedev rtsx_pci_ms btusb btrtl btbcm memstick ttm drm wmi_bmof
> hci_uart btintel bluetoot
> h iwlwifi snd_hda_intel snd_hda_codec cfg80211 irqbypass crc32c_intel
> ghash_clmulni_intel intel_cstate snd_hwdep intel_uncore snd_hda_core psmouse
> intel_rapl_perf rtsx_pci snd_pcm efi_pstore evdev ideapad_laptop ac
> input_leds serio_raw e
> fivars sparse_keymap intel_lpss_acpi battery thermal ecdh_generic wmi fan
> syscopyarea snd_timer sysfillrect snd rfkill intel_lpss
> Dec 17 11:17:28 bee kernel: [   31.977023]  video sysimgblt tpm_crb
> soundcore button mfd_core i2c_hid i2c_i801 fb_sys_fops backlight acpi_pad
> efivarfs unix dm_zero dm_thin_pool dm_persistent_data dm_bio_prison
> dm_service_time dm_round_ro
> bin dm_queue_length dm_multipath dm_log_userspace cn dm_flakey dm_delay xts
> aesni_intel crypto_simd cryptd glue_helper aes_x86_64 cbc sha256_generic
> scsi_transport_iscsi r8169 mii fuse xfs nfs lockd grace sunrpc fscache ext4
> mbcache jbd2
>  multipath linear raid10 raid1 raid0 dm_raid raid456 md_mod
> async_raid6_recov async_memcpy async_pq async_xor xor async_tx raid6_pq
> libcrc32c dm_snapshot dm_bufio dm_crypt dm_mirror dm_region_hash dm_log
> dm_mod dax hid_generic usbhid xhc
> i_pci xhci_hcd ohci_hcd uhci_hcd usb_storage ehci_pci ehci_hcd usbcore
> usb_common scsi_transport_fc sr_mod cdrom sg sd_mod ata_piix
> Dec 17 11:17:28 bee kernel: [   31.977223]  ahci libahci sata_sx4
> pata_oldpiix Dec 17 11:17:28 bee kernel: [   31.977239] CPU: 0 PID: 3698
> Comm: udevd Not tainted 4.14.5 #10
> Dec 17 11:17:28 bee kernel: [   31.977255] Hardware name: LENOVO 80UV/Lenovo
> ideapad 510S-14IKB, BIOS 2SCN21WW(V2.01) 12/20/2016
> Dec 17 11:17:28 bee kernel: [   31.977278] task: 880358b54280
> task.stack: c900014dc000
> Dec 17 11:17:28 bee kernel: [   31.977323] RIP:
> 0010:xgpu_vi_init_golden_registers+0x56/0xa0 [amdgpu]
> Dec 17 11:17:28 bee kernel: [   31.977341] RSP: 0018:c900014dfa08
> EFLAGS: 00010293
> Dec 17 11:17:28 bee kernel: [   31.977356] RAX: 000a RBX:
> 88034004 RCX: 
> Dec 17 11:17:28 bee kernel: [   31.977375] RDX: 880358b54280 RSI:
> 0100 RDI: 88034004
> Dec 17 11:17:28 bee kernel: [   31.977394] RBP: c900014dfa10 R08:
> 88033c6dd198 R09: 
> Dec 17 11:17:28 bee kernel: [   31.977413] R10: 880352c0aaa0 R11:
> 0008 R12: 880340040458
> Dec 17 11:17:28 bee kernel: [   31.977432] R13:  R14:
>  R15: 88034004
> Dec 17 11:17:28 bee kernel: [   31.977452] FS:  7fbfdd8c0780()
> GS:88046ec0() knlGS:
> Dec 17 11:17:28 bee kernel: [   31.977474] CS:  0010 DS:  ES:  CR0:
> 80050033
> Dec 17 11:17:28 bee kernel: [   31.977490] CR2: 55c3b48c1408 CR3:
> 000358307003 CR4: 003606f0
> Dec 17 11:17:28 bee kernel: [   31.977527] Call Trace:
> Dec 17 11:17:28 bee kernel: [   31.977555]  vi_common_hw_init+0x77/0xe0
> [amdgpu]
> Dec 17 11:17:28 bee kernel: [   31.977584]  amdgpu_device_init+0xc4b/0x14b0
> [amdgpu]
> Dec 17 11:17:28 bee kernel: [   31.977601]  ? kmem_cache_alloc_trace
> +0x208/0x250
> Dec 17 11:17:28 bee kernel: [   31.977629]  ? amdgpu_driver_load_kms+0x2a/
> 0x1b0 [amdgpu]
> Dec 17 11:17:28 bee kernel: [   31.977658] 
> amdgpu_driver_load_kms+0x4f/0x1b0 [amdgpu]
> Dec 17 11:17:28 bee kernel: [   31.977682]  drm_dev_register+0x146/0x1d0
> [drm] Dec 17 11:17:28 bee kernel: [   31.977710] 
> amdgpu_pci_probe+0x118/0x140 [amdgpu]
> Dec 17 11:17:28 bee kernel: [   31.977725]  pci_device_probe+0xcf/0x150
> Dec 17 11:17:28 bee kernel: [   31.977739]  driver_probe_device+0x29c/0x450
> Dec 17 11:17:28 bee kernel: [   31.977753]  __driver_attach+0xdf/0xf0
> Dec 17 11:17:28 bee kernel: [   31.978775]  ?
> driver_probe_device+0x450/0x450 Dec 17 11:17:28 bee kernel: [   31.979815] 
> bus_for_each_dev+0x60/0xa0 Dec 17 11:17:28 bee kernel: [   31.980882] 
> driver_attach+0x1e/0x20 Dec 17 11:17:28 bee kernel: [   31.981931] 
> bus_add_driver+0x170/0x260 Dec 17 11:17:28 bee kernel: [   31.982977] 
> driver_register+0x60/0xe0 Dec 17 11:17:28 bee kernel: [   31.984033]

Re: Topaz mistakenly reported as vf

2017-12-19 Thread José Pekkarinen 
On Tuesday, 19 December 2017 09:44:00 EET Yu, Xiangliang wrote:
> We can add ASIC check in vi_detect_hw_virtualization function to avoid to
> entry error path. I'll submit patch later.
> 
> Thanks!

Awesome, thanks!

Also, I noticed the following patch in case you can consider it for 
upstream.

Best regards.

José.From dc691db50dbfb213aaee2b76574a5e8de2d7bca0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Jos=C3=A9=20Pekkarinen?= 
Date: Tue, 19 Dec 2017 09:39:50 +0200
Subject: [PATCH] Release the mutex hold before backtracing for not supported
 mxgpu.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Signed-off-by: José Pekkarinen 
---
 drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c b/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
index c25a831f94ec..cac1d8b003e6 100644
--- a/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
+++ b/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
@@ -307,6 +307,7 @@ void xgpu_vi_init_golden_registers(struct amdgpu_device *adev)
 		 xgpu_tonga_golden_common_all));
 		break;
 	default:
+		mutex_unlock(>grbm_idx_mutex);
 		BUG_ON("Doesn't support chip type.\n");
 		break;
 	}
-- 
2.13.6

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

[PATCH 4/4] drm/amd/pp: implement force_dpm_level on rv

2017-12-19 Thread Rex Zhu 
user can change engine/mclk/soc/vcn clocks on Rv

v3: add smu version check
v2: fix no return statement

Signed-off-by: Rex Zhu 
---
 drivers/gpu/drm/amd/powerplay/hwmgr/rv_hwmgr.c | 123 +
 drivers/gpu/drm/amd/powerplay/hwmgr/rv_hwmgr.h |  15 +++
 2 files changed, 138 insertions(+)

diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/rv_hwmgr.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/rv_hwmgr.c
index ae11a85..569073e 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/rv_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/rv_hwmgr.c
@@ -484,6 +484,129 @@ static int rv_hwmgr_backend_fini(struct pp_hwmgr *hwmgr)
 static int rv_dpm_force_dpm_level(struct pp_hwmgr *hwmgr,
enum amd_dpm_forced_level level)
 {
+   if (hwmgr->smu_version < 0x1E3700) {
+   pr_info("smu firmware version too old, can not set dpm 
level\n");
+   return 0;
+   }
+
+   switch (level) {
+   case AMD_DPM_FORCED_LEVEL_HIGH:
+   case AMD_DPM_FORCED_LEVEL_PROFILE_PEAK:
+   smum_send_msg_to_smc_with_parameter(hwmgr,
+   PPSMC_MSG_SetHardMinGfxClk,
+   RAVEN_UMD_PSTATE_PEAK_GFXCLK);
+   smum_send_msg_to_smc_with_parameter(hwmgr,
+   PPSMC_MSG_SetHardMinFclkByFreq,
+   RAVEN_UMD_PSTATE_PEAK_FCLK);
+   smum_send_msg_to_smc_with_parameter(hwmgr,
+   
PPSMC_MSG_SetHardMinSocclkByFreq,
+   RAVEN_UMD_PSTATE_PEAK_SOCCLK);
+   smum_send_msg_to_smc_with_parameter(hwmgr,
+   PPSMC_MSG_SetHardMinVcn,
+   RAVEN_UMD_PSTATE_VCE);
+
+   smum_send_msg_to_smc_with_parameter(hwmgr,
+   PPSMC_MSG_SetSoftMaxGfxClk,
+   RAVEN_UMD_PSTATE_PEAK_GFXCLK);
+   smum_send_msg_to_smc_with_parameter(hwmgr,
+   PPSMC_MSG_SetSoftMaxFclkByFreq,
+   RAVEN_UMD_PSTATE_PEAK_FCLK);
+   smum_send_msg_to_smc_with_parameter(hwmgr,
+   
PPSMC_MSG_SetSoftMaxSocclkByFreq,
+   RAVEN_UMD_PSTATE_PEAK_SOCCLK);
+   smum_send_msg_to_smc_with_parameter(hwmgr,
+   PPSMC_MSG_SetSoftMaxVcn,
+   RAVEN_UMD_PSTATE_VCE);
+   break;
+   case AMD_DPM_FORCED_LEVEL_PROFILE_MIN_SCLK:
+   smum_send_msg_to_smc_with_parameter(hwmgr,
+   PPSMC_MSG_SetHardMinGfxClk,
+   RAVEN_UMD_PSTATE_MIN_GFXCLK);
+   smum_send_msg_to_smc_with_parameter(hwmgr,
+   PPSMC_MSG_SetSoftMaxGfxClk,
+   RAVEN_UMD_PSTATE_MIN_GFXCLK);
+   break;
+   case AMD_DPM_FORCED_LEVEL_PROFILE_MIN_MCLK:
+   smum_send_msg_to_smc_with_parameter(hwmgr,
+   PPSMC_MSG_SetHardMinFclkByFreq,
+   RAVEN_UMD_PSTATE_MIN_FCLK);
+   smum_send_msg_to_smc_with_parameter(hwmgr,
+   PPSMC_MSG_SetSoftMaxFclkByFreq,
+   RAVEN_UMD_PSTATE_MIN_FCLK);
+   break;
+   case AMD_DPM_FORCED_LEVEL_PROFILE_STANDARD:
+   smum_send_msg_to_smc_with_parameter(hwmgr,
+   PPSMC_MSG_SetHardMinGfxClk,
+   RAVEN_UMD_PSTATE_GFXCLK);
+   smum_send_msg_to_smc_with_parameter(hwmgr,
+   PPSMC_MSG_SetHardMinFclkByFreq,
+   RAVEN_UMD_PSTATE_FCLK);
+   smum_send_msg_to_smc_with_parameter(hwmgr,
+   
PPSMC_MSG_SetHardMinSocclkByFreq,
+   RAVEN_UMD_PSTATE_SOCCLK);
+   smum_send_msg_to_smc_with_parameter(hwmgr,
+   PPSMC_MSG_SetHardMinVcn,
+   RAVEN_UMD_PSTATE_VCE);
+
+   smum_send_msg_to_smc_with_parameter(hwmgr,
+   PPSMC_MSG_SetSoftMaxGfxClk,
+   RAVEN_UMD_PSTATE_GFXCLK);
+   smum_send_msg_to_smc_with_parameter(hwmgr,
+

[PATCH 3/4] drm/amd/pp: get Rv smu_version and notify amdgpu

2017-12-19 Thread Rex Zhu 
Signed-off-by: Rex Zhu 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c  | 3 +++
 drivers/gpu/drm/amd/powerplay/smumgr/rv_smumgr.c | 8 
 2 files changed, 11 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c
index 85d2149..13607e2 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c
@@ -801,6 +801,9 @@ static int amdgpu_cgs_get_firmware_info(struct cgs_device 
*cgs_device,
else
strcpy(fw_name, 
"amdgpu/vega10_smc.bin");
break;
+   case CHIP_RAVEN:
+   adev->pm.fw_version = info->version;
+   return 0;
default:
DRM_ERROR("SMC firmware not supported\n");
return -EINVAL;
diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/rv_smumgr.c 
b/drivers/gpu/drm/amd/powerplay/smumgr/rv_smumgr.c
index b98ade6..2d662b4 100644
--- a/drivers/gpu/drm/amd/powerplay/smumgr/rv_smumgr.c
+++ b/drivers/gpu/drm/amd/powerplay/smumgr/rv_smumgr.c
@@ -305,6 +305,14 @@ static int rv_smu_fini(struct pp_hwmgr *hwmgr)
 
 static int rv_start_smu(struct pp_hwmgr *hwmgr)
 {
+   struct cgs_firmware_info info = {0};
+
+   smum_send_msg_to_smc(hwmgr, PPSMC_MSG_GetSmuVersion);
+   rv_read_arg_from_smc(hwmgr, >smu_version);
+   info.version = hwmgr->smu_version >> 8;
+
+   cgs_get_firmware_info(hwmgr->device, CGS_UCODE_ID_SMU, );
+
if (rv_verify_smc_interface(hwmgr))
return -EINVAL;
if (rv_smc_enable_sdma(hwmgr))
-- 
1.9.1

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

[PATCH 2/4] drm/amd/pp: update smu_version value for CI/VI

2017-12-19 Thread Rex Zhu 
Change-Id: Ia55a0bc2cde45cb995d92ff054e57b07ed548f08
---
 drivers/gpu/drm/amd/powerplay/smumgr/ci_smumgr.c  | 1 +
 drivers/gpu/drm/amd/powerplay/smumgr/iceland_smumgr.c | 2 +-
 drivers/gpu/drm/amd/powerplay/smumgr/smu7_smumgr.c| 2 +-
 3 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/ci_smumgr.c 
b/drivers/gpu/drm/amd/powerplay/smumgr/ci_smumgr.c
index c6c741a..0b4a556 100644
--- a/drivers/gpu/drm/amd/powerplay/smumgr/ci_smumgr.c
+++ b/drivers/gpu/drm/amd/powerplay/smumgr/ci_smumgr.c
@@ -2316,6 +2316,7 @@ static int ci_load_smc_ucode(struct pp_hwmgr *hwmgr)
cgs_get_firmware_info(hwmgr->device, CGS_UCODE_ID_SMU, );
 
hwmgr->is_kicker = info.is_kicker;
+   hwmgr->smu_version = info.version;
byte_count = info.image_size;
src = (uint8_t *)info.kptr;
start_addr = info.ucode_start_address;
diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/iceland_smumgr.c 
b/drivers/gpu/drm/amd/powerplay/smumgr/iceland_smumgr.c
index d75bb99..1253126 100644
--- a/drivers/gpu/drm/amd/powerplay/smumgr/iceland_smumgr.c
+++ b/drivers/gpu/drm/amd/powerplay/smumgr/iceland_smumgr.c
@@ -204,7 +204,7 @@ static int iceland_smu_upload_firmware_image(struct 
pp_hwmgr *hwmgr)
pr_err("[ powerplay ] SMC address is beyond the SMC RAM 
area\n");
return -EINVAL;
}
-
+   hwmgr->smu_version = info.version;
/* wait for smc boot up */
PHM_WAIT_INDIRECT_FIELD_UNEQUAL(hwmgr, SMC_IND,
 RCU_UC_EVENTS, boot_seq_done, 0);
diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/smu7_smumgr.c 
b/drivers/gpu/drm/amd/powerplay/smumgr/smu7_smumgr.c
index 7f5359a..cb95e88 100644
--- a/drivers/gpu/drm/amd/powerplay/smumgr/smu7_smumgr.c
+++ b/drivers/gpu/drm/amd/powerplay/smumgr/smu7_smumgr.c
@@ -535,7 +535,7 @@ int smu7_upload_smu_firmware_image(struct pp_hwmgr *hwmgr)
smu7_convert_fw_type_to_cgs(UCODE_ID_SMU_SK), );
 
hwmgr->is_kicker = info.is_kicker;
-
+   hwmgr->smu_version = info.version;
result = smu7_upload_smc_firmware_data(hwmgr, info.image_size, 
(uint32_t *)info.kptr, SMU7_SMC_SIZE);
 
return result;
-- 
1.9.1

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

[PATCH 1/4] drm/amd/pp: move smu_version out vega to hwmgr

2017-12-19 Thread Rex Zhu 
Change-Id: Ie8c32663aa0d61a1dfdd8e019509cb551f137aa0
Signed-off-by: Rex Zhu 
---
 drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c | 8 
 drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.h | 1 -
 drivers/gpu/drm/amd/powerplay/inc/hwmgr.h  | 1 +
 3 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
index f0295fa..2d55dab 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
@@ -426,9 +426,9 @@ static void vega10_init_dpm_defaults(struct pp_hwmgr *hwmgr)
data->smu_features[GNLD_VR0HOT].supported = true;
 
smum_send_msg_to_smc(hwmgr, PPSMC_MSG_GetSmuVersion);
-   vega10_read_arg_from_smc(hwmgr, &(data->smu_version));
+   vega10_read_arg_from_smc(hwmgr, &(hwmgr->smu_version));
/* ACG firmware has major version 5 */
-   if ((data->smu_version & 0xff00) == 0x500)
+   if ((hwmgr->smu_version & 0xff00) == 0x500)
data->smu_features[GNLD_ACG].supported = true;
 
if (data->registry_data.didt_support)
@@ -2879,8 +2879,8 @@ static int vega10_enable_dpm_tasks(struct pp_hwmgr *hwmgr)
"DPM is already running right , skipping 
re-enablement!",
return 0);
 
-   if ((data->smu_version == 0x001c2c00) ||
-   (data->smu_version == 0x001c2d00)) {
+   if ((hwmgr->smu_version == 0x001c2c00) ||
+   (hwmgr->smu_version == 0x001c2d00)) {
tmp_result = smum_send_msg_to_smc_with_parameter(hwmgr,
PPSMC_MSG_UpdatePkgPwrPidAlpha, 1);
PP_ASSERT_WITH_CODE(!tmp_result,
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.h 
b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.h
index 8f7358c..e8507ff 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.h
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.h
@@ -387,7 +387,6 @@ struct vega10_hwmgr {
struct vega10_smc_state_table  smc_state_table;
 
uint32_t   config_telemetry;
-   uint32_t   smu_version;
uint32_t   acg_loop_state;
uint32_t   mem_channels;
 };
diff --git a/drivers/gpu/drm/amd/powerplay/inc/hwmgr.h 
b/drivers/gpu/drm/amd/powerplay/inc/hwmgr.h
index 39eedbc..565fe08 100644
--- a/drivers/gpu/drm/amd/powerplay/inc/hwmgr.h
+++ b/drivers/gpu/drm/amd/powerplay/inc/hwmgr.h
@@ -692,6 +692,7 @@ enum PP_TABLE_VERSION {
 struct pp_hwmgr {
uint32_t chip_family;
uint32_t chip_id;
+   uint32_t smu_version;
 
uint32_t pp_table_version;
void *device;
-- 
1.9.1

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

RE: Topaz mistakenly reported as vf

2017-12-19 Thread Yu, Xiangliang 
>   Also, I noticed the following patch in case you can consider it for
> upstream.

Please send it to amd-gfx mailist for code review.

> 
>   Best regards.
> 
>   José.
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

RE: Topaz mistakenly reported as vf

2017-12-19 Thread Yu, Xiangliang 
We can add ASIC check in vi_detect_hw_virtualization function to avoid to entry 
error path.
I'll submit patch later.

Thanks!

> -Original Message-
> From: José Pekkarinen [mailto:jose.pekkari...@canonical.com]
> Sent: Tuesday, December 19, 2017 3:27 PM
> To: Yu, Xiangliang 
> Cc: amd-gfx@lists.freedesktop.org; Deucher, Alexander
> ; Koenig, Christian
> 
> Subject: Re: Topaz mistakenly reported as vf
> 
> On Tuesday, 19 December 2017 09:19:02 EET Yu, Xiangliang wrote:
> > Topaz doesn't support SRIOV.
> >
> 
>   Hi Xiangliang,
> 
>   Allow me to ask for some attention, as I'm trying to say that given
> that Topaz is not having support, amdgpu_sriov_vf(adev) may return false
> and ignore the vi.c code path. Instead of it, it enters the code path and
> reaches the BUG_ON that states this is not supported.
> 
>   Thanks for coming back!
> 
>   José.
> 

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