Re: [PATCH] drm/amd/pp: Clean register first to avoid read original value

2018-03-30 Thread Eric Huang 

Please confirm this with SMU team about your assumption.


Regards,

Eric


On 03/30/2018 08:28 PM, Zhu, Rex wrote:


when PPSMC_MSG_PmStatusLogSample sent, firmware will clean the temp 
sampling date, and add the sample task to dpm loop.


but firmware not  clean the registers.  if firmware not update the 
registers, we will read out the original value.



Best Regards

Rex





*From:* amd-gfx  on behalf of 
Eric Huang 

*Sent:* Friday, March 30, 2018 11:22 PM
*To:* amd-gfx@lists.freedesktop.org
*Subject:* Re: [PATCH] drm/amd/pp: Clean register first to avoid read 
original value


On 03/30/2018 10:36 AM, Eric Huang wrote:
> It is not necessary to do that. The register will reset to 0 after
> reading.
The register is not reset after reading. Actually after
PPSMC_MSG_PmStatusLogSample sent, the register will be updated. So it is
still not necessary to do that.

Eric
>
> Eric
>
>
> On 03/30/2018 03:33 AM, Rex Zhu wrote:
>> Signed-off-by: Rex Zhu 
>> ---
>> drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c | 13 +
>>   1 file changed, 13 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
>> b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
>> index aaa9f5b..38cf3a1 100644
>> --- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
>> +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
>> @@ -3368,6 +3368,19 @@ static int smu7_get_gpu_power(struct pp_hwmgr
>> *hwmgr,
>>   "Failed to start pm status log!",
>>   return -1);
>>   + cgs_write_ind_register(hwmgr->device,
>> +    CGS_IND_REG__SMC,
>> +    ixSMU_PM_STATUS_40, 0);
>> +    cgs_write_ind_register(hwmgr->device,
>> +    CGS_IND_REG__SMC,
>> +    ixSMU_PM_STATUS_49, 0);
>> +    cgs_write_ind_register(hwmgr->device,
>> +    CGS_IND_REG__SMC,
>> +    ixSMU_PM_STATUS_94, 0);
>> +    cgs_write_ind_register(hwmgr->device,
>> +    CGS_IND_REG__SMC,
>> +    ixSMU_PM_STATUS_95, 0);
>> +
>>   /* Sampling period from 50ms to 4sec */
>>   msleep_interruptible(200);
>

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


lists.freedesktop.org
Subscribing to amd-gfx: Subscribe to amd-gfx by filling out the 
following form. Use of all freedesktop.org lists is subject to our 
Code of Conduct.






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

Re: [PATCH] drm/amd/pp: Clean register first to avoid read original value

2018-03-30 Thread Zhu, Rex 
when PPSMC_MSG_PmStatusLogSample sent, firmware will clean the temp sampling 
date, and add the sample task to dpm loop.

but firmware not  clean the registers.  if firmware not update the registers, 
we will read out the original value.


Best Regards

Rex




From: amd-gfx  on behalf of Eric Huang 

Sent: Friday, March 30, 2018 11:22 PM
To: amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/amd/pp: Clean register first to avoid read original 
value


On 03/30/2018 10:36 AM, Eric Huang wrote:
> It is not necessary to do that. The register will reset to 0 after
> reading.
The register is not reset after reading. Actually after
PPSMC_MSG_PmStatusLogSample sent, the register will be updated. So it is
still not necessary to do that.

Eric
>
> Eric
>
>
> On 03/30/2018 03:33 AM, Rex Zhu wrote:
>> Signed-off-by: Rex Zhu 
>> ---
>>   drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c | 13 +
>>   1 file changed, 13 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
>> b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
>> index aaa9f5b..38cf3a1 100644
>> --- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
>> +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
>> @@ -3368,6 +3368,19 @@ static int smu7_get_gpu_power(struct pp_hwmgr
>> *hwmgr,
>>   "Failed to start pm status log!",
>>   return -1);
>>   +cgs_write_ind_register(hwmgr->device,
>> +CGS_IND_REG__SMC,
>> +ixSMU_PM_STATUS_40, 0);
>> +cgs_write_ind_register(hwmgr->device,
>> +CGS_IND_REG__SMC,
>> +ixSMU_PM_STATUS_49, 0);
>> +cgs_write_ind_register(hwmgr->device,
>> +CGS_IND_REG__SMC,
>> +ixSMU_PM_STATUS_94, 0);
>> +cgs_write_ind_register(hwmgr->device,
>> +CGS_IND_REG__SMC,
>> +ixSMU_PM_STATUS_95, 0);
>> +
>>   /* Sampling period from 50ms to 4sec */
>>   msleep_interruptible(200);
>

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
amd-gfx Info Page - 
freedesktop.org
lists.freedesktop.org
Subscribing to amd-gfx: Subscribe to amd-gfx by filling out the following form. 
Use of all freedesktop.org lists is subject to our Code of Conduct.



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

[PATCH 1/2] drm/amdgpu: Fix memory leaks at amdgpu_init() error path

2018-03-30 Thread Takashi Iwai 
amdgpu driver checks vgacon_text_force() after some initializations
but without cleaning up.  This will result in leaks.

Move the check of vgacon_text_force() to the beginning of
amdgpu_init() for fixing it and also for optimization.

Signed-off-by: Takashi Iwai 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 50afcf65181a..e55792d3cd12 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -905,6 +905,11 @@ static int __init amdgpu_init(void)
 {
int r;
 
+   if (vgacon_text_force()) {
+   DRM_ERROR("VGACON disables amdgpu kernel modesetting.\n");
+   return -EINVAL;
+   }
+
r = amdgpu_sync_init();
if (r)
goto error_sync;
@@ -913,10 +918,6 @@ static int __init amdgpu_init(void)
if (r)
goto error_fence;
 
-   if (vgacon_text_force()) {
-   DRM_ERROR("VGACON disables amdgpu kernel modesetting.\n");
-   return -EINVAL;
-   }
DRM_INFO("amdgpu kernel modesetting enabled.\n");
driver = _driver;
pdriver = _kms_pci_driver;
-- 
2.16.2

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

[PATCH 2/2] drm/amdgpu: Add modeset module option

2018-03-30 Thread Takashi Iwai 
amdgpu driver lacks of modeset module option other drm drivers provide
for enforcing or disabling the driver load.  Interestingly, the
amdgpu_mode variable declaration is already found in the header file,
but the actual implementation seems to have been forgotten.

This patch adds the missing piece.

Signed-off-by: Takashi Iwai 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index e55792d3cd12..029d95ecd26b 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -78,6 +78,7 @@
 #define KMS_DRIVER_MINOR   23
 #define KMS_DRIVER_PATCHLEVEL  0
 
+int amdgpu_modeset = -1;
 int amdgpu_vram_limit = 0;
 int amdgpu_vis_vram_limit = 0;
 int amdgpu_gart_size = -1; /* auto */
@@ -130,6 +131,9 @@ int amdgpu_lbpw = -1;
 int amdgpu_compute_multipipe = -1;
 int amdgpu_gpu_recovery = -1; /* auto */
 
+MODULE_PARM_DESC(modeset, "Disable/Enable modesetting");
+module_param_named(modeset, amdgpu_modeset, int, 0400);
+
 MODULE_PARM_DESC(vramlimit, "Restrict VRAM for testing, in megabytes");
 module_param_named(vramlimit, amdgpu_vram_limit, int, 0600);
 
@@ -905,10 +909,12 @@ static int __init amdgpu_init(void)
 {
int r;
 
-   if (vgacon_text_force()) {
+   if (vgacon_text_force() && amdgpu_modeset == -1) {
DRM_ERROR("VGACON disables amdgpu kernel modesetting.\n");
return -EINVAL;
}
+   if (amdgpu_modeset == 0)
+   return -EINVAL;
 
r = amdgpu_sync_init();
if (r)
-- 
2.16.2

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

Re: [PATCH 2/8] PCI: Add pci_find_common_upstream_dev()

2018-03-30 Thread Logan Gunthorpe 


On 29/03/18 07:58 PM, Jerome Glisse wrote:
> On Thu, Mar 29, 2018 at 10:25:52AM -0600, Logan Gunthorpe wrote:
>>
>>
>> On 29/03/18 10:10 AM, Christian König wrote:
>>> Why not? I mean the dma_map_resource() function is for P2P while other 
>>> dma_map_* functions are only for system memory.
>>
>> Oh, hmm, I wasn't aware dma_map_resource was exclusively for mapping
>> P2P. Though it's a bit odd seeing we've been working under the
>> assumption that PCI P2P is different as it has to translate the PCI bus
>> address. Where as P2P for devices on other buses is a big unknown.
> 
> dma_map_resource() is the right API (thought its current implementation
> is fill with x86 assumptions). So i would argue that arch can decide to
> implement it or simply return dma error address which trigger fallback
> path into the caller (at least for GPU drivers). SG variant can be added
> on top.
> 
> dma_map_resource() is the right API because it has all the necessary
> informations. It use the CPU physical address as the common address
> "language" with CPU physical address of PCIE bar to map to another
> device you can find the corresponding bus address from the IOMMU code
> (NOP on x86). So dma_map_resource() knows both the source device which
> export its PCIE bar and the destination devices.

Well, as it is today, it doesn't look very sane to me. The default is to
just return the physical address if the architecture doesn't support it.
So if someone tries this on an arch that hasn't added itself to return
an error they're very likely going to just end up DMAing to an invalid
address and loosing the data or causing a machine check.

Furthermore, the API does not have all the information it needs to do
sane things. A phys_addr_t doesn't really tell you anything about the
memory behind it or what needs to be done with it. For example, on some
arm64 implementations if the physical address points to a PCI BAR and
that BAR is behind a switch with the DMA device then the address must be
converted to the PCI BUS address. On the other hand, if it's a physical
address of a device in an SOC it might need to  be handled in a
completely different way. And right now all the implementations I can
find seem to just assume that phys_addr_t points to regular memory and
can be treated as such.

This is one of the reasons that, based on feedback, our work went from
being general P2P with any device to being restricted to only P2P with
PCI devices. The dream that we can just grab the physical address of any
device and use it in a DMA request is simply not realistic.

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

[PATCH] drm/amdgpu/si: implement get/set pcie_lanes asic callback

2018-03-30 Thread Alex Deucher 
Required for dpm setup on some asics. Fixes a NULL dereference
on asics that require it.

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=102553
Signed-off-by: Alex Deucher 
Cc: sta...@vger.kernel.org
---
 drivers/gpu/drm/amd/amdgpu/si.c | 67 +
 1 file changed, 67 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/si.c b/drivers/gpu/drm/amd/amdgpu/si.c
index 775cacfe9917..c364ef94cc36 100644
--- a/drivers/gpu/drm/amd/amdgpu/si.c
+++ b/drivers/gpu/drm/amd/amdgpu/si.c
@@ -1258,6 +1258,71 @@ static bool si_need_full_reset(struct amdgpu_device 
*adev)
return true;
 }
 
+static int si_get_pcie_lanes(struct amdgpu_device *adev)
+{
+   u32 link_width_cntl;
+
+   if (adev->flags & AMD_IS_APU)
+   return 0;
+
+   link_width_cntl = RREG32_PCIE_PORT(PCIE_LC_LINK_WIDTH_CNTL);
+
+   switch ((link_width_cntl & LC_LINK_WIDTH_RD_MASK) >> 
LC_LINK_WIDTH_RD_SHIFT) {
+   case LC_LINK_WIDTH_X1:
+   return 1;
+   case LC_LINK_WIDTH_X2:
+   return 2;
+   case LC_LINK_WIDTH_X4:
+   return 4;
+   case LC_LINK_WIDTH_X8:
+   return 8;
+   case LC_LINK_WIDTH_X0:
+   case LC_LINK_WIDTH_X16:
+   default:
+   return 16;
+   }
+}
+
+static void si_set_pcie_lanes(struct amdgpu_device *adev, int lanes)
+{
+   u32 link_width_cntl, mask;
+
+   if (adev->flags & AMD_IS_APU)
+   return;
+
+   switch (lanes) {
+   case 0:
+   mask = LC_LINK_WIDTH_X0;
+   break;
+   case 1:
+   mask = LC_LINK_WIDTH_X1;
+   break;
+   case 2:
+   mask = LC_LINK_WIDTH_X2;
+   break;
+   case 4:
+   mask = LC_LINK_WIDTH_X4;
+   break;
+   case 8:
+   mask = LC_LINK_WIDTH_X8;
+   break;
+   case 16:
+   mask = LC_LINK_WIDTH_X16;
+   break;
+   default:
+   DRM_ERROR("invalid pcie lane request: %d\n", lanes);
+   return;
+   }
+
+   link_width_cntl = RREG32_PCIE_PORT(PCIE_LC_LINK_WIDTH_CNTL);
+   link_width_cntl &= ~LC_LINK_WIDTH_MASK;
+   link_width_cntl |= mask << LC_LINK_WIDTH_SHIFT;
+   link_width_cntl |= (LC_RECONFIG_NOW |
+   LC_RECONFIG_ARC_MISSING_ESCAPE);
+
+   WREG32_PCIE_PORT(PCIE_LC_LINK_WIDTH_CNTL, link_width_cntl);
+}
+
 static const struct amdgpu_asic_funcs si_asic_funcs =
 {
.read_disabled_bios = _read_disabled_bios,
@@ -1268,6 +1333,8 @@ static const struct amdgpu_asic_funcs si_asic_funcs =
.get_xclk = _get_xclk,
.set_uvd_clocks = _set_uvd_clocks,
.set_vce_clocks = NULL,
+   .get_pcie_lanes = _get_pcie_lanes,
+   .set_pcie_lanes = _set_pcie_lanes,
.get_config_memsize = _get_config_memsize,
.flush_hdp = _flush_hdp,
.invalidate_hdp = _invalidate_hdp,
-- 
2.13.6

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

[PATCH] drm/amd/display: fix spelling mistake: "Usupported" -> "Unsupported"

2018-03-30 Thread Colin King 
From: Colin Ian King 

Trivial fix to spelling mistake in DRM_ERROR error message text

Signed-off-by: Colin Ian King 
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index e42a28e3adc5..1df1c91b6ae5 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -1521,7 +1521,7 @@ static int amdgpu_dm_initialize_drm_device(struct 
amdgpu_device *adev)
break;
 #endif
default:
-   DRM_ERROR("Usupported ASIC type: 0x%X\n", adev->asic_type);
+   DRM_ERROR("Unsupported ASIC type: 0x%X\n", adev->asic_type);
goto fail;
}
 
@@ -1715,7 +1715,7 @@ static int dm_early_init(void *handle)
break;
 #endif
default:
-   DRM_ERROR("Usupported ASIC type: 0x%X\n", adev->asic_type);
+   DRM_ERROR("Unsupported ASIC type: 0x%X\n", adev->asic_type);
return -EINVAL;
}
 
-- 
2.15.1

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

Re: [PATCH 2/8] PCI: Add pci_find_common_upstream_dev()

2018-03-30 Thread Jerome Glisse 
On Thu, Mar 29, 2018 at 11:33:34PM -0700, Christoph Hellwig wrote:
> On Thu, Mar 29, 2018 at 09:58:54PM -0400, Jerome Glisse wrote:
> > dma_map_resource() is the right API (thought its current implementation
> > is fill with x86 assumptions). So i would argue that arch can decide to
> > implement it or simply return dma error address which trigger fallback
> > path into the caller (at least for GPU drivers). SG variant can be added
> > on top.
> 
> It isn't in general.  It doesn't integrate with scatterlists (see my
> comment to page one), and it doesn't integrate with all the subsystems
> that also need a kernel virtual address.

IIRC SG variant was proposed at the time dma_map_resource() was added,
dunno why they did not make it (again from memory i think it was because
it grows the scatterlist struct size). My point is more than people that
need SG variant should work on adding it. People who do not, should not
be stop by the lack of it. There is something there upstream, it does
not make sense to not use it. The dma-buf infrastructure is useful to
many drivers.

If you do not want to share the underlying logic of dma_map_resource()
fine (ie not sharing code inside drivers/iommu/*). I thought it would
be a good thing to share code ...

Cheers,
Jérôme
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH] drm/amdgpu/powerplay: whitespace cleanup

2018-03-30 Thread Alex Deucher 
Fix confusing indentation.

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/amd/powerplay/hwmgr/ppatomfwctrl.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/ppatomfwctrl.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/ppatomfwctrl.c
index 8aea88aed1d3..0adaf36b6d68 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/ppatomfwctrl.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/ppatomfwctrl.c
@@ -38,11 +38,11 @@ static const union atom_voltage_object_v4 
*pp_atomfwctrl_lookup_voltage_type_v4(
 
while (offset < size) {
const union atom_voltage_object_v4 *voltage_object =
-   (const union atom_voltage_object_v4 *)(start + 
offset);
+   (const union atom_voltage_object_v4 *)(start + offset);
 
-   if (voltage_type == 
voltage_object->gpio_voltage_obj.header.voltage_type &&
-   voltage_mode == 
voltage_object->gpio_voltage_obj.header.voltage_mode)
-   return voltage_object;
+   if (voltage_type == 
voltage_object->gpio_voltage_obj.header.voltage_type &&
+   voltage_mode == 
voltage_object->gpio_voltage_obj.header.voltage_mode)
+   return voltage_object;
 
offset += 
le16_to_cpu(voltage_object->gpio_voltage_obj.header.object_size);
 
-- 
2.13.6

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

Re: [PATCH] drm/amd/pp: Clean register first to avoid read original value

2018-03-30 Thread Eric Huang 


On 03/30/2018 10:36 AM, Eric Huang wrote:
It is not necessary to do that. The register will reset to 0 after 
reading.
The register is not reset after reading. Actually after 
PPSMC_MSG_PmStatusLogSample sent, the register will be updated. So it is 
still not necessary to do that.


Eric


Eric


On 03/30/2018 03:33 AM, Rex Zhu wrote:

Signed-off-by: Rex Zhu 
---
  drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c | 13 +
  1 file changed, 13 insertions(+)

diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c

index aaa9f5b..38cf3a1 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
@@ -3368,6 +3368,19 @@ static int smu7_get_gpu_power(struct pp_hwmgr 
*hwmgr,

  "Failed to start pm status log!",
  return -1);
  +    cgs_write_ind_register(hwmgr->device,
+    CGS_IND_REG__SMC,
+    ixSMU_PM_STATUS_40, 0);
+    cgs_write_ind_register(hwmgr->device,
+    CGS_IND_REG__SMC,
+    ixSMU_PM_STATUS_49, 0);
+    cgs_write_ind_register(hwmgr->device,
+    CGS_IND_REG__SMC,
+    ixSMU_PM_STATUS_94, 0);
+    cgs_write_ind_register(hwmgr->device,
+    CGS_IND_REG__SMC,
+    ixSMU_PM_STATUS_95, 0);
+
  /* Sampling period from 50ms to 4sec */
  msleep_interruptible(200);




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

Re: [PATCH] drm/amd/powerply: fix power reading on Fiji

2018-03-30 Thread Eric Huang 
I reproduced the issue reported by customer. When running a HSA test, 
repeating to read power via AGT and rocm-smi (driver). We set power 
limit of 175w to a Fiji. The results from AGT are all below 175w and the 
results from driver have a lot of value over 175, some are almost double 
of 175. So your test cases are not enough, you should run some OCL and 
HSA tests.


I have tested 100ms and 150ms, the results still have some wrong. 200ms 
is good. It seems more sampling more accurate.


The theoretical period is quoted from smu team and tools team. AGT is 
using more than 1sec of period. I don't know how long one cycle of dpm 
task is, but is sampling based on dpm task cycle? we should ask smu team 
to confirm.


Regards,
Eric


On 03/30/2018 03:52 AM, Zhu, Rex wrote:


>> Power value is wrong reported by customer.

Hi Eric,

What is the wrong value customer reported?

In my end, there is no big difference between 20ms and 200ms or 2s. I 
tested on Fiji/Tonga when gpu idle or running fullscreen glxgears.


why need 50 ms?

How long does the SMU core take to complete one cycle of dpm tasks? I 
tested, it is less than 1 ms.



So when we delay 20 ms, The output is the average value of more than 
20 sampling.


Best Regards

Rex

*From:*amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] *On 
Behalf Of *Deucher, Alexander

*Sent:* Friday, March 30, 2018 4:00 AM
*To:* Huang, JinHuiEric; amd-gfx@lists.freedesktop.org
*Subject:* Re: [PATCH] drm/amd/powerply: fix power reading on Fiji

Fiji and tonga I presume.  The current code seems to work fine on 
tonga at least.


Alex



*From:*Huang, JinHuiEric
*Sent:* Thursday, March 29, 2018 3:58:42 PM
*To:* Deucher, Alexander; amd-gfx@lists.freedesktop.org 


*Subject:* Re: [PATCH] drm/amd/powerply: fix power reading on Fiji

Right. This is only for Fiji. We should use PPSMC_MSG_GetCurrPkgPwr on 
poaris.


Thanks,

Eric

On 2018-03-29 03:54 PM, Deucher, Alexander wrote:

Thanks. Patch is:

Acked-by: Alex Deucher 


Care to make a patch to use PPSMC_MSG_GetCurrPkgPwr on polaris
boards so we don't have to worry about the delay on them?

Alex



*From:*Huang, JinHuiEric
*Sent:* Thursday, March 29, 2018 3:40:22 PM
*To:* Deucher, Alexander; amd-gfx@lists.freedesktop.org

*Subject:* Re: [PATCH] drm/amd/powerply: fix power reading on Fiji

This reading method is shared with AGT tool only on Fiji, because
SMU FW doesn't support PPSMC_MSG_GetCurrPkgPwr message on Fiji.
But since polaris10, PPSMC_MSG_GetCurrPkgPwr has been supported.
We also use PPSMC_MSG_GetCurrPkgPwr on vega which SMU FW control
sampling period. Driver will not care about it.

Eric

On 2018-03-29 03:31 PM, Deucher, Alexander wrote:

Do you know what the sampling period is on vega?  We should
try and be consistent.  How about making this selectable via
hwmon:

power[1-*]_average_interval   Power use averaging
interval.  A poll

  notification is sent to this file if the

  hardware changes the averaging interval.

  Unit: milliseconds

  RW

power[1-*]_average_interval_max   Maximum power use averaging
interval

  Unit: milliseconds

  RO

power[1-*]_average_interval_min   Minimum power use averaging
interval

  Unit: milliseconds

  RO

Then the user can select the interval they want.

Alex



*From:*amd-gfx 
 on behalf of
Eric Huang 

*Sent:* Thursday, March 29, 2018 3:21:52 PM
*To:* amd-gfx@lists.freedesktop.org

*Cc:* Huang, JinHuiEric
*Subject:* [PATCH] drm/amd/powerply: fix power reading on Fiji

Power value is wrong reported by customer. It is a regression by

commit a7c7bc4c0c47eaac77b8fa92f0672032df7f4254
Author: Rex Zhu  
Date:   Mon Mar 27 15:32:59 2017 +0800

    drm/amd/powerplay: reduce sample period time

    for power readings.

    Signed-off-by: Rex Zhu 

    Reviewed-by: Alex Deucher

Re: [PATCH 00/24] drm_framebuffer boilerplate removal

2018-03-30 Thread Alex Deucher 
On Fri, Mar 30, 2018 at 11:00 AM, Daniel Stone  wrote:
> Hi Alex,
>
> On 30 March 2018 at 15:47, Alex Deucher  wrote:
>> On Fri, Mar 30, 2018 at 10:11 AM, Daniel Stone  wrote:
>>> I intend to remove create_handle when all drivers are converted over
>>> to placing BOs directly inside drm_framebuffer. For most drivers
>>> there's a relatively easy conversion to using the helpers for
>>> basically all framebuffer handling and fbdev emulation as well, though
>>> that's a bit further than I was willing to go without hardware to test
>>> on ...
>>
>> Series is:
>> Acked-by: Alex Deucher 
>
> Thanks a lot for the review! Are you taking the radeon/amdgpu patches
> through your tree? They don't have any dependencies on core code.

Sure.  I'll grab them now.

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

Re: [PATCH 00/24] drm_framebuffer boilerplate removal

2018-03-30 Thread Daniel Stone 
Hi Alex,

On 30 March 2018 at 15:47, Alex Deucher  wrote:
> On Fri, Mar 30, 2018 at 10:11 AM, Daniel Stone  wrote:
>> I intend to remove create_handle when all drivers are converted over
>> to placing BOs directly inside drm_framebuffer. For most drivers
>> there's a relatively easy conversion to using the helpers for
>> basically all framebuffer handling and fbdev emulation as well, though
>> that's a bit further than I was willing to go without hardware to test
>> on ...
>
> Series is:
> Acked-by: Alex Deucher 

Thanks a lot for the review! Are you taking the radeon/amdgpu patches
through your tree? They don't have any dependencies on core code.

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

Re: [PATCH 00/24] drm_framebuffer boilerplate removal

2018-03-30 Thread Alex Deucher 
On Fri, Mar 30, 2018 at 10:11 AM, Daniel Stone  wrote:
> Hi,
> I've been working on a getfb2[0] ioctl, which amongst other things
> supports multi-planar framebuffers as well as modifiers. getfb
> currently calls the framebuffer's handle_create hook, which doesn't
> support multiple planes.
>
> Thanks to Noralf's recent work, drivers can just store GEM objects
> directly in drm_framebuffer. I use this directly in getfb2: we need
> direct access to the GEM objects and not a vfunc in order to not hand
> out duplicate GEM names for the same object.
>
> This series converts all drivers except for nouveau, which was a
> little too non-trivial for my comfort, to storing GEM objects directly
> in drm_framebuffer. For those drivers whose driver_framebuffer struct
> was nothing but drm_framebuffer + BO, it deletes the driver-specific
> struct. It also makes use of Noralf's generic framebuffer helpers for
> create_handle and destroy where possible.
>
> I don't have the hardware for most of these drivers, so have had to
> settle for just staring really hard at the diff.
>
> I intend to remove create_handle when all drivers are converted over
> to placing BOs directly inside drm_framebuffer. For most drivers
> there's a relatively easy conversion to using the helpers for
> basically all framebuffer handling and fbdev emulation as well, though
> that's a bit further than I was willing to go without hardware to test
> on ...

Series is:
Acked-by: Alex Deucher 

>
> Cheers,
> Daniel
>
> [0]: https://lists.freedesktop.org/archives/dri-devel/2018-March/170512.html
> ___
> 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/amd/pp: Clean register first to avoid read original value

2018-03-30 Thread Eric Huang 

It is not necessary to do that. The register will reset to 0 after reading.

Eric


On 03/30/2018 03:33 AM, Rex Zhu wrote:

Signed-off-by: Rex Zhu 
---
  drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c | 13 +
  1 file changed, 13 insertions(+)

diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
index aaa9f5b..38cf3a1 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
@@ -3368,6 +3368,19 @@ static int smu7_get_gpu_power(struct pp_hwmgr *hwmgr,
"Failed to start pm status log!",
return -1);
  
+	cgs_write_ind_register(hwmgr->device,

+   CGS_IND_REG__SMC,
+   ixSMU_PM_STATUS_40, 0);
+   cgs_write_ind_register(hwmgr->device,
+   CGS_IND_REG__SMC,
+   ixSMU_PM_STATUS_49, 0);
+   cgs_write_ind_register(hwmgr->device,
+   CGS_IND_REG__SMC,
+   ixSMU_PM_STATUS_94, 0);
+   cgs_write_ind_register(hwmgr->device,
+   CGS_IND_REG__SMC,
+   ixSMU_PM_STATUS_95, 0);
+
/* Sampling period from 50ms to 4sec */
msleep_interruptible(200);
  


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

[PATCH 24/24] drm/amdgpu: Move GEM BO to drm_framebuffer

2018-03-30 Thread Daniel Stone 
Since drm_framebuffer can now store GEM objects directly, place them
there rather than in our own subclass. As this makes the framebuffer
create_handle and destroy functions the same as the GEM framebuffer
helper, we can reuse those.

Signed-off-by: Daniel Stone 
Cc: Alex Deucher 
Cc: Christian König 
Cc: David (ChunMing) Zhou 
Cc: amd-gfx@lists.freedesktop.org
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c|  6 ++--
 drivers/gpu/drm/amd/amdgpu/amdgpu_display.c   | 36 +--
 drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c| 10 +++
 drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h  |  1 -
 drivers/gpu/drm/amd/amdgpu/dce_v10_0.c| 17 ---
 drivers/gpu/drm/amd/amdgpu/dce_v11_0.c| 17 ---
 drivers/gpu/drm/amd/amdgpu/dce_v6_0.c | 17 ---
 drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 17 ---
 drivers/gpu/drm/amd/amdgpu/dce_virtual.c  |  4 +--
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 11 +++
 10 files changed, 40 insertions(+), 96 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 34af664b9f93..fbc0676c6bcc 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -2539,7 +2539,7 @@ int amdgpu_device_suspend(struct drm_device *dev, bool 
suspend, bool fbcon)
/* unpin the front buffers and cursors */
list_for_each_entry(crtc, >mode_config.crtc_list, head) {
struct amdgpu_crtc *amdgpu_crtc = to_amdgpu_crtc(crtc);
-   struct amdgpu_framebuffer *rfb = 
to_amdgpu_framebuffer(crtc->primary->fb);
+   struct drm_framebuffer *fb = crtc->primary->fb;
struct amdgpu_bo *robj;
 
if (amdgpu_crtc->cursor_bo) {
@@ -2551,10 +2551,10 @@ int amdgpu_device_suspend(struct drm_device *dev, bool 
suspend, bool fbcon)
}
}
 
-   if (rfb == NULL || rfb->obj == NULL) {
+   if (fb == NULL || fb->obj[0] == NULL) {
continue;
}
-   robj = gem_to_amdgpu_bo(rfb->obj);
+   robj = gem_to_amdgpu_bo(fb->obj[0]);
/* don't unpin kernel fb objects */
if (!amdgpu_fbdev_robj_is_fb(adev, robj)) {
r = amdgpu_bo_reserve(robj, true);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
index 93f700ab1bfb..b83ae998fe27 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
@@ -35,6 +35,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 static void amdgpu_display_flip_callback(struct dma_fence *f,
@@ -151,8 +152,6 @@ int amdgpu_display_crtc_page_flip_target(struct drm_crtc 
*crtc,
struct drm_device *dev = crtc->dev;
struct amdgpu_device *adev = dev->dev_private;
struct amdgpu_crtc *amdgpu_crtc = to_amdgpu_crtc(crtc);
-   struct amdgpu_framebuffer *old_amdgpu_fb;
-   struct amdgpu_framebuffer *new_amdgpu_fb;
struct drm_gem_object *obj;
struct amdgpu_flip_work *work;
struct amdgpu_bo *new_abo;
@@ -174,15 +173,13 @@ int amdgpu_display_crtc_page_flip_target(struct drm_crtc 
*crtc,
work->async = (page_flip_flags & DRM_MODE_PAGE_FLIP_ASYNC) != 0;
 
/* schedule unpin of the old buffer */
-   old_amdgpu_fb = to_amdgpu_framebuffer(crtc->primary->fb);
-   obj = old_amdgpu_fb->obj;
+   obj = crtc->primary->fb->obj[0];
 
/* take a reference to the old object */
work->old_abo = gem_to_amdgpu_bo(obj);
amdgpu_bo_ref(work->old_abo);
 
-   new_amdgpu_fb = to_amdgpu_framebuffer(fb);
-   obj = new_amdgpu_fb->obj;
+   obj = fb->obj[0];
new_abo = gem_to_amdgpu_bo(obj);
 
/* pin the new buffer */
@@ -482,28 +479,9 @@ bool amdgpu_display_ddc_probe(struct amdgpu_connector 
*amdgpu_connector,
return true;
 }
 
-static void amdgpu_display_user_framebuffer_destroy(struct drm_framebuffer *fb)
-{
-   struct amdgpu_framebuffer *amdgpu_fb = to_amdgpu_framebuffer(fb);
-
-   drm_gem_object_put_unlocked(amdgpu_fb->obj);
-   drm_framebuffer_cleanup(fb);
-   kfree(amdgpu_fb);
-}
-
-static int amdgpu_display_user_framebuffer_create_handle(
-   struct drm_framebuffer *fb,
-   struct drm_file *file_priv,
-   unsigned int *handle)
-{
-   struct amdgpu_framebuffer *amdgpu_fb = to_amdgpu_framebuffer(fb);
-
-   return drm_gem_handle_create(file_priv, amdgpu_fb->obj, handle);
-}
-
 static const struct drm_framebuffer_funcs amdgpu_fb_funcs = {
-   .destroy = amdgpu_display_user_framebuffer_destroy,
-   .create_handle =

[PATCH 22/24] drm/radeon: Move GEM BO to drm_framebuffer

2018-03-30 Thread Daniel Stone 
Since drm_framebuffer can now store GEM objects directly, place them
there rather than in our own subclass. As this makes the framebuffer
create_handle and destroy functions the same as the GEM framebuffer
helper, we can reuse those.

Signed-off-by: Daniel Stone 
Cc: Alex Deucher 
Cc: Christian König 
Cc: David (ChunMing) Zhou 
Cc: amd-gfx@lists.freedesktop.org
---
 drivers/gpu/drm/radeon/atombios_crtc.c  | 10 +-
 drivers/gpu/drm/radeon/radeon_device.c  |  4 ++--
 drivers/gpu/drm/radeon/radeon_display.c | 31 +++--
 drivers/gpu/drm/radeon/radeon_fb.c  |  8 
 drivers/gpu/drm/radeon/radeon_legacy_crtc.c | 11 --
 drivers/gpu/drm/radeon/radeon_mode.h|  1 -
 6 files changed, 22 insertions(+), 43 deletions(-)

diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c 
b/drivers/gpu/drm/radeon/atombios_crtc.c
index 02baaaf20e9d..028a811c1462 100644
--- a/drivers/gpu/drm/radeon/atombios_crtc.c
+++ b/drivers/gpu/drm/radeon/atombios_crtc.c
@@ -1176,7 +1176,7 @@ static int dce4_crtc_do_set_base(struct drm_crtc *crtc,
/* If atomic, assume fb object is pinned & idle & fenced and
 * just update base pointers
 */
-   obj = radeon_fb->obj;
+   obj = radeon_fb->base.obj[0];
rbo = gem_to_radeon_bo(obj);
r = radeon_bo_reserve(rbo, false);
if (unlikely(r != 0))
@@ -1442,7 +1442,7 @@ static int dce4_crtc_do_set_base(struct drm_crtc *crtc,
 
if (!atomic && fb && fb != crtc->primary->fb) {
radeon_fb = to_radeon_framebuffer(fb);
-   rbo = gem_to_radeon_bo(radeon_fb->obj);
+   rbo = gem_to_radeon_bo(radeon_fb->base.obj[0]);
r = radeon_bo_reserve(rbo, false);
if (unlikely(r != 0))
return r;
@@ -1490,7 +1490,7 @@ static int avivo_crtc_do_set_base(struct drm_crtc *crtc,
target_fb = crtc->primary->fb;
}
 
-   obj = radeon_fb->obj;
+   obj = radeon_fb->base.obj[0];
rbo = gem_to_radeon_bo(obj);
r = radeon_bo_reserve(rbo, false);
if (unlikely(r != 0))
@@ -1642,7 +1642,7 @@ static int avivo_crtc_do_set_base(struct drm_crtc *crtc,
 
if (!atomic && fb && fb != crtc->primary->fb) {
radeon_fb = to_radeon_framebuffer(fb);
-   rbo = gem_to_radeon_bo(radeon_fb->obj);
+   rbo = gem_to_radeon_bo(radeon_fb->base.obj[0]);
r = radeon_bo_reserve(rbo, false);
if (unlikely(r != 0))
return r;
@@ -2153,7 +2153,7 @@ static void atombios_crtc_disable(struct drm_crtc *crtc)
struct radeon_bo *rbo;
 
radeon_fb = to_radeon_framebuffer(crtc->primary->fb);
-   rbo = gem_to_radeon_bo(radeon_fb->obj);
+   rbo = gem_to_radeon_bo(radeon_fb->base.obj[0]);
r = radeon_bo_reserve(rbo, false);
if (unlikely(r))
DRM_ERROR("failed to reserve rbo before unpin\n");
diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
b/drivers/gpu/drm/radeon/radeon_device.c
index e415d2c097a7..30c5bc20a60b 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -1599,10 +1599,10 @@ int radeon_suspend_kms(struct drm_device *dev, bool 
suspend,
}
}
 
-   if (rfb == NULL || rfb->obj == NULL) {
+   if (rfb == NULL || rfb->base.obj[0] == NULL) {
continue;
}
-   robj = gem_to_radeon_bo(rfb->obj);
+   robj = gem_to_radeon_bo(rfb->base.obj[0]);
/* don't unpin kernel fb objects */
if (!radeon_fbdev_robj_is_fb(rdev, robj)) {
r = radeon_bo_reserve(robj, false);
diff --git a/drivers/gpu/drm/radeon/radeon_display.c 
b/drivers/gpu/drm/radeon/radeon_display.c
index 26129b2b082d..dc300128283d 100644
--- a/drivers/gpu/drm/radeon/radeon_display.c
+++ b/drivers/gpu/drm/radeon/radeon_display.c
@@ -32,6 +32,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -502,14 +503,14 @@ static int radeon_crtc_page_flip_target(struct drm_crtc 
*crtc,
 
/* schedule unpin of the old buffer */
old_radeon_fb = to_radeon_framebuffer(crtc->primary->fb);
-   obj = old_radeon_fb->obj;
+   obj = old_radeon_fb->base.obj[0];
 
/* take a reference to the old object */
drm_gem_object_get(obj);
work->old_rbo = gem_to_radeon_bo(obj);
 
new_radeon_fb = to_radeon_framebuffer(fb);
-   obj = new_radeon_fb->obj;
+   obj = new_radeon_fb->base.obj[0];
new_rbo = gem_to_radeon_bo(obj);
 
/* pin the new buffer */
@@ -1285,27 +1286,9 @@ void radeon_compute_pll_legacy(struct radeon_pll *pll,
 
 }
 
-static void

[PATCH 23/24] drm/radeon: radeon_framebuffer -> drm_framebuffer

2018-03-30 Thread Daniel Stone 
Since drm_framebuffer can now store GEM objects directly, place them
there rather than in our own subclass. As this makes the framebuffer
create_handle and destroy functions the same as the GEM framebuffer
helper, we can reuse those.

Signed-off-by: Daniel Stone 
Cc: Alex Deucher 
Cc: Christian König 
Cc: David (ChunMing) Zhou 
Cc: amd-gfx@lists.freedesktop.org
---
 drivers/gpu/drm/radeon/atombios_crtc.c  | 32 -
 drivers/gpu/drm/radeon/radeon_device.c  |  6 +++---
 drivers/gpu/drm/radeon/radeon_display.c | 30 ---
 drivers/gpu/drm/radeon/radeon_fb.c  | 20 +-
 drivers/gpu/drm/radeon/radeon_legacy_crtc.c | 11 +++---
 drivers/gpu/drm/radeon/radeon_mode.h|  7 +--
 6 files changed, 39 insertions(+), 67 deletions(-)

diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c 
b/drivers/gpu/drm/radeon/atombios_crtc.c
index 028a811c1462..efbd5816082d 100644
--- a/drivers/gpu/drm/radeon/atombios_crtc.c
+++ b/drivers/gpu/drm/radeon/atombios_crtc.c
@@ -1145,7 +1145,6 @@ static int dce4_crtc_do_set_base(struct drm_crtc *crtc,
struct radeon_crtc *radeon_crtc = to_radeon_crtc(crtc);
struct drm_device *dev = crtc->dev;
struct radeon_device *rdev = dev->dev_private;
-   struct radeon_framebuffer *radeon_fb;
struct drm_framebuffer *target_fb;
struct drm_gem_object *obj;
struct radeon_bo *rbo;
@@ -1164,19 +1163,15 @@ static int dce4_crtc_do_set_base(struct drm_crtc *crtc,
return 0;
}
 
-   if (atomic) {
-   radeon_fb = to_radeon_framebuffer(fb);
+   if (atomic)
target_fb = fb;
-   }
-   else {
-   radeon_fb = to_radeon_framebuffer(crtc->primary->fb);
+   else
target_fb = crtc->primary->fb;
-   }
 
/* If atomic, assume fb object is pinned & idle & fenced and
 * just update base pointers
 */
-   obj = radeon_fb->base.obj[0];
+   obj = target_fb->obj[0];
rbo = gem_to_radeon_bo(obj);
r = radeon_bo_reserve(rbo, false);
if (unlikely(r != 0))
@@ -1441,8 +1436,7 @@ static int dce4_crtc_do_set_base(struct drm_crtc *crtc,
WREG32(EVERGREEN_MASTER_UPDATE_MODE + radeon_crtc->crtc_offset, 0);
 
if (!atomic && fb && fb != crtc->primary->fb) {
-   radeon_fb = to_radeon_framebuffer(fb);
-   rbo = gem_to_radeon_bo(radeon_fb->base.obj[0]);
+   rbo = gem_to_radeon_bo(fb->obj[0]);
r = radeon_bo_reserve(rbo, false);
if (unlikely(r != 0))
return r;
@@ -1463,7 +1457,6 @@ static int avivo_crtc_do_set_base(struct drm_crtc *crtc,
struct radeon_crtc *radeon_crtc = to_radeon_crtc(crtc);
struct drm_device *dev = crtc->dev;
struct radeon_device *rdev = dev->dev_private;
-   struct radeon_framebuffer *radeon_fb;
struct drm_gem_object *obj;
struct radeon_bo *rbo;
struct drm_framebuffer *target_fb;
@@ -1481,16 +1474,12 @@ static int avivo_crtc_do_set_base(struct drm_crtc *crtc,
return 0;
}
 
-   if (atomic) {
-   radeon_fb = to_radeon_framebuffer(fb);
+   if (atomic)
target_fb = fb;
-   }
-   else {
-   radeon_fb = to_radeon_framebuffer(crtc->primary->fb);
+   else
target_fb = crtc->primary->fb;
-   }
 
-   obj = radeon_fb->base.obj[0];
+   obj = target_fb->obj[0];
rbo = gem_to_radeon_bo(obj);
r = radeon_bo_reserve(rbo, false);
if (unlikely(r != 0))
@@ -1641,8 +1630,7 @@ static int avivo_crtc_do_set_base(struct drm_crtc *crtc,
WREG32(AVIVO_D1MODE_MASTER_UPDATE_MODE + radeon_crtc->crtc_offset, 3);
 
if (!atomic && fb && fb != crtc->primary->fb) {
-   radeon_fb = to_radeon_framebuffer(fb);
-   rbo = gem_to_radeon_bo(radeon_fb->base.obj[0]);
+   rbo = gem_to_radeon_bo(fb->obj[0]);
r = radeon_bo_reserve(rbo, false);
if (unlikely(r != 0))
return r;
@@ -2149,11 +2137,9 @@ static void atombios_crtc_disable(struct drm_crtc *crtc)
atombios_crtc_dpms(crtc, DRM_MODE_DPMS_OFF);
if (crtc->primary->fb) {
int r;
-   struct radeon_framebuffer *radeon_fb;
struct radeon_bo *rbo;
 
-   radeon_fb = to_radeon_framebuffer(crtc->primary->fb);
-   rbo = gem_to_radeon_bo(radeon_fb->base.obj[0]);
+   rbo = gem_to_radeon_bo(crtc->primary->fb->obj[0]);
r = radeon_bo_reserve(rbo, false);
if (unlikely(r))
DRM_ERROR("failed to reserve rbo before unpin\n");
diff --git a/drivers/gpu/drm/radeon/radeon_device.c

[PATCH 00/24] drm_framebuffer boilerplate removal

2018-03-30 Thread Daniel Stone 
Hi,
I've been working on a getfb2[0] ioctl, which amongst other things
supports multi-planar framebuffers as well as modifiers. getfb
currently calls the framebuffer's handle_create hook, which doesn't
support multiple planes.

Thanks to Noralf's recent work, drivers can just store GEM objects
directly in drm_framebuffer. I use this directly in getfb2: we need
direct access to the GEM objects and not a vfunc in order to not hand
out duplicate GEM names for the same object.

This series converts all drivers except for nouveau, which was a
little too non-trivial for my comfort, to storing GEM objects directly
in drm_framebuffer. For those drivers whose driver_framebuffer struct
was nothing but drm_framebuffer + BO, it deletes the driver-specific
struct. It also makes use of Noralf's generic framebuffer helpers for
create_handle and destroy where possible.

I don't have the hardware for most of these drivers, so have had to
settle for just staring really hard at the diff.

I intend to remove create_handle when all drivers are converted over
to placing BOs directly inside drm_framebuffer. For most drivers
there's a relatively easy conversion to using the helpers for
basically all framebuffer handling and fbdev emulation as well, though
that's a bit further than I was willing to go without hardware to test
on ...

Cheers,
Daniel

[0]: https://lists.freedesktop.org/archives/dri-devel/2018-March/170512.html
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH libdrm] headers: sync up amdgpu_drm.h with drm-next

2018-03-30 Thread Alex Deucher 
Chunming submitted it:
https://cgit.freedesktop.org/mesa/drm/commit/include/drm/amdgpu_drm.h?id=2fa58c77fb9e563219f8ec647b9ddf52f3390ed2

Alex

On Thu, Mar 29, 2018 at 10:04 PM, Yu, Qiang  wrote:
> Hi, Can anyone submit it?
>
> Thanks,
> Qiang
>
> 
> From: Zhou, David(ChunMing)
> Sent: Thursday, March 29, 2018 11:07:09 AM
> To: Yu, Qiang; amd-gfx@lists.freedesktop.org
> Cc: Zhu, Rex
> Subject: Re: [PATCH libdrm] headers: sync up amdgpu_drm.h with drm-next
>
> Acked-by: Chunming Zhou 
>
>
> On 2018年03月29日 09:10, Yu, Qiang wrote:
>> Hi guys,
>>
>> Ping.
>>
>> Regards,
>> Qiang
>>
>> 
>> From: amd-gfx  on behalf of Qiang Yu 
>> 
>> Sent: Tuesday, March 20, 2018 2:08:09 PM
>> To: amd-gfx@lists.freedesktop.org
>> Cc: Zhu, Rex
>> Subject: [PATCH libdrm] headers: sync up amdgpu_drm.h with drm-next
>>
>> From: Rex Zhu 
>>
>> Add sensor_info type
>> AMDGPU_INFO_SENSOR_STABLE_PSTATE_GFX_MCLK
>> AMDGPU_INFO_SENSOR_STABLE_PSTATE_GFX_SCLK
>>
>> Reviewed-by: Evan Quan 
>> Signed-off-by: Rex Zhu 
>> ---
>>   include/drm/amdgpu_drm.h | 4 
>>   1 file changed, 4 insertions(+)
>>
>> diff --git a/include/drm/amdgpu_drm.h b/include/drm/amdgpu_drm.h
>> index f9d81bf..c519776 100644
>> --- a/include/drm/amdgpu_drm.h
>> +++ b/include/drm/amdgpu_drm.h
>> @@ -723,6 +723,10 @@ struct drm_amdgpu_cs_chunk_data {
>>  #define AMDGPU_INFO_SENSOR_VDDNB0x6
>>  /* Subquery id: Query graphics voltage */
>>  #define AMDGPU_INFO_SENSOR_VDDGFX   0x7
>> +   /* Subquery id: Query GPU stable pstate shader clock */
>> +   #define AMDGPU_INFO_SENSOR_STABLE_PSTATE_GFX_SCLK   0x8
>> +   /* Subquery id: Query GPU stable pstate memory clock */
>> +   #define AMDGPU_INFO_SENSOR_STABLE_PSTATE_GFX_MCLK   0x9
>>   /* Number of VRAM page faults on CPU access. */
>>   #define AMDGPU_INFO_NUM_VRAM_CPU_PAGE_FAULTS   0x1E
>>   #define AMDGPU_INFO_VRAM_LOST_COUNTER  0x1F
>> --
>> 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
>
> ___
> 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 -next] drm/amdkfd: Make function kfd_dev_is_large_bar() static

2018-03-30 Thread Wei Yongjun 
Fixes the following sparse warning:

drivers/gpu/drm/amd/amdkfd/kfd_chardev.c:1150:6: warning:
 symbol 'kfd_dev_is_large_bar' was not declared. Should it be static?

Signed-off-by: Wei Yongjun 
---
 drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
index cd679cf..fb5d997 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
@@ -1147,7 +1147,7 @@ static int kfd_ioctl_acquire_vm(struct file *filep, 
struct kfd_process *p,
return ret;
 }
 
-bool kfd_dev_is_large_bar(struct kfd_dev *dev)
+static bool kfd_dev_is_large_bar(struct kfd_dev *dev)
 {
struct kfd_local_mem_info mem_info;

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

[PATCH -next] drm/amdkfd: Fix the error return code in kfd_ioctl_unmap_memory_from_gpu()

2018-03-30 Thread Wei Yongjun 
Passing NULL pointer to PTR_ERR will result in return value of 0
indicating success which is clearly not what it is intended here.
This patch returns -EINVAL instead.

Fixes: 5ec7e02854b3 ("drm/amdkfd: Add ioctls for GPUVM memory management")
Signed-off-by: Wei Yongjun 
---
 drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
index cd679cf..c32a341 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
@@ -1421,7 +1421,7 @@ static int kfd_ioctl_unmap_memory_from_gpu(struct file 
*filep,
 
pdd = kfd_get_process_device_data(dev, p);
if (!pdd) {
-   err = PTR_ERR(pdd);
+   err = -EINVAL;
goto bind_process_to_device_failed;
}

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

Re: [PATCH 2/8] PCI: Add pci_find_common_upstream_dev()

2018-03-30 Thread Jerome Glisse 
On Thu, Mar 29, 2018 at 10:25:52AM -0600, Logan Gunthorpe wrote:
> 
> 
> On 29/03/18 10:10 AM, Christian König wrote:
> > Why not? I mean the dma_map_resource() function is for P2P while other 
> > dma_map_* functions are only for system memory.
> 
> Oh, hmm, I wasn't aware dma_map_resource was exclusively for mapping
> P2P. Though it's a bit odd seeing we've been working under the
> assumption that PCI P2P is different as it has to translate the PCI bus
> address. Where as P2P for devices on other buses is a big unknown.

dma_map_resource() is the right API (thought its current implementation
is fill with x86 assumptions). So i would argue that arch can decide to
implement it or simply return dma error address which trigger fallback
path into the caller (at least for GPU drivers). SG variant can be added
on top.

dma_map_resource() is the right API because it has all the necessary
informations. It use the CPU physical address as the common address
"language" with CPU physical address of PCIE bar to map to another
device you can find the corresponding bus address from the IOMMU code
(NOP on x86). So dma_map_resource() knows both the source device which
export its PCIE bar and the destination devices.


So i don't think Christian need to base his patchset on yours. This
is orthogonal. Christian is using existing upstream API, if it is
broken on some arch it is up to those arch to fix it, or return error
if it is not fixable. In fact i would assume that you would need to
base your patchset on top of dma_map_resource() too ...

Moreover i doubt Christian want to have struct page for this. For
nouveau there will be HMM struct page and this would conflict.

AFAICT you need struct page because the API you are trying to expose
to user space rely on "regular" filesystem/RDMA umem API which all
assume struct page. GPU drivers do not have this requirement and it
should not be impose on them.


So from my point of view Christian patchset is good as it is. Modulo
better commit message.


Bottom line i think we need common PCIE helper for P2P and the current
dma_map_resource() is the right kind from POV. What you are doing with
struct page is specific to your sub-system and should not be impose on
others.

Cheers,
Jérôme
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 2/8] PCI: Add pci_find_common_upstream_dev()

2018-03-30 Thread Christoph Hellwig 
On Thu, Mar 29, 2018 at 09:58:54PM -0400, Jerome Glisse wrote:
> dma_map_resource() is the right API (thought its current implementation
> is fill with x86 assumptions). So i would argue that arch can decide to
> implement it or simply return dma error address which trigger fallback
> path into the caller (at least for GPU drivers). SG variant can be added
> on top.

It isn't in general.  It doesn't integrate with scatterlists (see my
comment to page one), and it doesn't integrate with all the subsystems
that also need a kernel virtual address.
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] drm/amdgpu/sdma4:fix sdma engine hang

2018-03-30 Thread Deucher, Alexander 
The spec claims it does and we use it for HDP flush...

Acked-by: Alex Deucher 


From: amd-gfx  on behalf of Emily Deng 

Sent: Friday, March 30, 2018 4:24:08 AM
To: amd-gfx@lists.freedesktop.org
Cc: Deng, Emily
Subject: [PATCH] drm/amdgpu/sdma4:fix sdma engine hang

The sdma doesn't support register write and wait in one command.
Use this will make sdma engine hang.

Signed-off-by: Emily Deng 
---
 drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c | 9 +
 1 file changed, 1 insertion(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c 
b/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c
index 9ac28b2..84d148d 100644
--- a/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c
@@ -1178,13 +1178,6 @@ static void sdma_v4_0_ring_emit_reg_wait(struct 
amdgpu_ring *ring, uint32_t reg,
 sdma_v4_0_wait_reg_mem(ring, 0, 0, reg, 0, val, mask, 10);
 }

-static void sdma_v4_0_ring_emit_reg_write_reg_wait(struct amdgpu_ring *ring,
-  uint32_t reg0, uint32_t reg1,
-  uint32_t ref, uint32_t mask)
-{
-   sdma_v4_0_wait_reg_mem(ring, 0, 1, reg0, reg1, ref, mask, 10);
-}
-
 static int sdma_v4_0_early_init(void *handle)
 {
 struct amdgpu_device *adev = (struct amdgpu_device *)handle;
@@ -1626,7 +1619,7 @@ static const struct amdgpu_ring_funcs 
sdma_v4_0_ring_funcs = {
 .pad_ib = sdma_v4_0_ring_pad_ib,
 .emit_wreg = sdma_v4_0_ring_emit_wreg,
 .emit_reg_wait = sdma_v4_0_ring_emit_reg_wait,
-   .emit_reg_write_reg_wait = sdma_v4_0_ring_emit_reg_write_reg_wait,
+   .emit_reg_write_reg_wait = amdgpu_ring_emit_reg_write_reg_wait_helper,
 };

 static void sdma_v4_0_set_ring_funcs(struct amdgpu_device *adev)
--
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] drm/amd/pp: Clean register first to avoid read original value

2018-03-30 Thread Deucher, Alexander 
Reviewed-by: Alex Deucher 


From: amd-gfx  on behalf of Rex Zhu 

Sent: Friday, March 30, 2018 3:33:26 AM
To: amd-gfx@lists.freedesktop.org
Cc: Zhu, Rex
Subject: [PATCH] drm/amd/pp: Clean register first to avoid read original value

Signed-off-by: Rex Zhu 
---
 drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
index aaa9f5b..38cf3a1 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
@@ -3368,6 +3368,19 @@ static int smu7_get_gpu_power(struct pp_hwmgr *hwmgr,
 "Failed to start pm status log!",
 return -1);

+   cgs_write_ind_register(hwmgr->device,
+   CGS_IND_REG__SMC,
+   ixSMU_PM_STATUS_40, 0);
+   cgs_write_ind_register(hwmgr->device,
+   CGS_IND_REG__SMC,
+   ixSMU_PM_STATUS_49, 0);
+   cgs_write_ind_register(hwmgr->device,
+   CGS_IND_REG__SMC,
+   ixSMU_PM_STATUS_94, 0);
+   cgs_write_ind_register(hwmgr->device,
+   CGS_IND_REG__SMC,
+   ixSMU_PM_STATUS_95, 0);
+
 /* Sampling period from 50ms to 4sec */
 msleep_interruptible(200);

--
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

[PATCH] drm/amdgpu/sdma4:fix sdma engine hang

2018-03-30 Thread Emily Deng 
The sdma doesn't support register write and wait in one command.
Use this will make sdma engine hang.

Signed-off-by: Emily Deng 
---
 drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c | 9 +
 1 file changed, 1 insertion(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c 
b/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c
index 9ac28b2..84d148d 100644
--- a/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c
@@ -1178,13 +1178,6 @@ static void sdma_v4_0_ring_emit_reg_wait(struct 
amdgpu_ring *ring, uint32_t reg,
sdma_v4_0_wait_reg_mem(ring, 0, 0, reg, 0, val, mask, 10);
 }
 
-static void sdma_v4_0_ring_emit_reg_write_reg_wait(struct amdgpu_ring *ring,
-  uint32_t reg0, uint32_t reg1,
-  uint32_t ref, uint32_t mask)
-{
-   sdma_v4_0_wait_reg_mem(ring, 0, 1, reg0, reg1, ref, mask, 10);
-}
-
 static int sdma_v4_0_early_init(void *handle)
 {
struct amdgpu_device *adev = (struct amdgpu_device *)handle;
@@ -1626,7 +1619,7 @@ static const struct amdgpu_ring_funcs 
sdma_v4_0_ring_funcs = {
.pad_ib = sdma_v4_0_ring_pad_ib,
.emit_wreg = sdma_v4_0_ring_emit_wreg,
.emit_reg_wait = sdma_v4_0_ring_emit_reg_wait,
-   .emit_reg_write_reg_wait = sdma_v4_0_ring_emit_reg_write_reg_wait,
+   .emit_reg_write_reg_wait = amdgpu_ring_emit_reg_write_reg_wait_helper,
 };
 
 static void sdma_v4_0_set_ring_funcs(struct amdgpu_device *adev)
-- 
2.7.4

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

RE: [PATCH] drm/amd/powerply: fix power reading on Fiji

2018-03-30 Thread Zhu, Rex 
>> Power value is wrong reported by customer.

Hi Eric,

What is the wrong value customer reported?

In my end, there is no big difference between 20ms and 200ms or 2s. I tested on 
Fiji/Tonga when gpu idle or running fullscreen glxgears.

why need 50 ms?

How long does the SMU core take to complete one cycle of dpm tasks? I tested, 
it is less than 1 ms.

So when we delay 20 ms, The output is the average value of more than 20 
sampling.

Best Regards
Rex


From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of 
Deucher, Alexander
Sent: Friday, March 30, 2018 4:00 AM
To: Huang, JinHuiEric; amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/amd/powerply: fix power reading on Fiji


Fiji and tonga I presume.  The current code seems to work fine on tonga at 
least.



Alex


From: Huang, JinHuiEric
Sent: Thursday, March 29, 2018 3:58:42 PM
To: Deucher, Alexander; 
amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/amd/powerply: fix power reading on Fiji


Right. This is only for Fiji. We should use PPSMC_MSG_GetCurrPkgPwr on poaris.



Thanks,

Eric

On 2018-03-29 03:54 PM, Deucher, Alexander wrote:

Thanks. Patch is:

Acked-by: Alex Deucher 


Care to make a patch to use PPSMC_MSG_GetCurrPkgPwr on polaris boards so we 
don't have to worry about the delay on them?



Alex


From: Huang, JinHuiEric
Sent: Thursday, March 29, 2018 3:40:22 PM
To: Deucher, Alexander; 
amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/amd/powerply: fix power reading on Fiji


This reading method is shared with AGT tool only on Fiji, because SMU FW 
doesn't support PPSMC_MSG_GetCurrPkgPwr message on Fiji. But since polaris10, 
PPSMC_MSG_GetCurrPkgPwr has been supported. We also use PPSMC_MSG_GetCurrPkgPwr 
on vega which SMU FW control sampling period. Driver will not care about it.



Eric

On 2018-03-29 03:31 PM, Deucher, Alexander wrote:

Do you know what the sampling period is on vega?  We should try and be 
consistent.  How about making this selectable via hwmon:

power[1-*]_average_interval   Power use averaging interval.  A poll

  notification is sent to this file if the

  hardware changes the averaging interval.

  Unit: milliseconds

  RW



power[1-*]_average_interval_max   Maximum power use averaging interval

  Unit: milliseconds

  RO



power[1-*]_average_interval_min   Minimum power use averaging interval

  Unit: milliseconds

  RO



Then the user can select the interval they want.



Alex


From: amd-gfx 

 on behalf of Eric Huang 

Sent: Thursday, March 29, 2018 3:21:52 PM
To: amd-gfx@lists.freedesktop.org
Cc: Huang, JinHuiEric
Subject: [PATCH] drm/amd/powerply: fix power reading on Fiji

Power value is wrong reported by customer. It is a regression by

commit a7c7bc4c0c47eaac77b8fa92f0672032df7f4254
Author: Rex Zhu 
Date:   Mon Mar 27 15:32:59 2017 +0800

drm/amd/powerplay: reduce sample period time

for power readings.

Signed-off-by: Rex Zhu 
Reviewed-by: Alex Deucher 

Signed-off-by: Alex Deucher 


The theoretical sampling period is from 50ms to 4sec, original 2sec
is long but correct, and 20ms is too short. change it to more
reasonable 200ms.

Signed-off-by: Eric Huang 

---
 drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
index a03b7fe..7631d80 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
@@ -3377,7 +3377,8 @@ static int smu7_get_gpu_power(struct pp_hwmgr *hwmgr,
 "Failed to start pm status log!",
 return -1);

-   msleep_interruptible(20);
+   /* Sampling period from 50ms to 4sec */
+   msleep_interruptible(200);

 PP_ASSERT_WITH_CODE(!smum_send_msg_to_smc(hwmgr,
 PPSMC_MSG_PmStatusLogSample),
--
2.7.4

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org

[PATCH] drm/amd/pp: Clean register first to avoid read original value

2018-03-30 Thread Rex Zhu 
Signed-off-by: Rex Zhu 
---
 drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
index aaa9f5b..38cf3a1 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
@@ -3368,6 +3368,19 @@ static int smu7_get_gpu_power(struct pp_hwmgr *hwmgr,
"Failed to start pm status log!",
return -1);
 
+   cgs_write_ind_register(hwmgr->device,
+   CGS_IND_REG__SMC,
+   ixSMU_PM_STATUS_40, 0);
+   cgs_write_ind_register(hwmgr->device,
+   CGS_IND_REG__SMC,
+   ixSMU_PM_STATUS_49, 0);
+   cgs_write_ind_register(hwmgr->device,
+   CGS_IND_REG__SMC,
+   ixSMU_PM_STATUS_94, 0);
+   cgs_write_ind_register(hwmgr->device,
+   CGS_IND_REG__SMC,
+   ixSMU_PM_STATUS_95, 0);
+
/* Sampling period from 50ms to 4sec */
msleep_interruptible(200);
 
-- 
1.9.1

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