Re: Latest drm-next-4.9-wip is causing gfx kernel thread to be pegged 100% running piglit

2016-09-18 Thread Shawn Starr
On Sunday, September 18, 2016 8:06:51 PM EDT Shawn Starr wrote:
> Looks like something broke in drm-next-4.9-wip, unsure which change did.
> 
> When running: piglit tests/gpu summary/amdgpu
> 

It's spinning in:

   82.37%82.37%  [kernel]  [k] 
amdgpu_sync_peek_fence

This is on a CIK (Bonaire) chip.

Thanks,
Shawn   

> 
> Also triggers:
> [ 1848.505498] [drm:amdgpu_cs_ioctl [amdgpu]] *ERROR* ttm_eu_reserve_buffers
> failed.
> 
> Will test 4.8-rc6 vanilla to see if something broke there.
> 
> Thanks,
> Shawn
> ___
> 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


Latest drm-next-4.9-wip is causing gfx kernel thread to be pegged 100% running piglit

2016-09-18 Thread Shawn Starr
Looks like something broke in drm-next-4.9-wip, unsure which change did.

When running: piglit tests/gpu summary/amdgpu 


Also triggers:
[ 1848.505498] [drm:amdgpu_cs_ioctl [amdgpu]] *ERROR* ttm_eu_reserve_buffers 
failed.

Will test 4.8-rc6 vanilla to see if something broke there.

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


Re: [PATCH 4/6] drm/radeon: Provide page_flip_target hook

2016-09-18 Thread Mario Kleiner

Hi Michel,

all your patches, both the already merged kernel bits in radeon/amdgpu 
and also all the userspace bits in libdrm/ati-ddx/amdgpu-ddx are all


Reviewed-and-tested-by: Mario Kleiner 

I successfully tested with old/current userspace and the new userspace 
patches from your own libdrm/ati-ddx/amdgpu-ddx repos, under radeon-kms 
with HD-5770 and amdgpu-kms with R9 380, under DRI2 and DRI3/Present 
with the new userspace and at least DRI3/Present with the old/current 
userspace (can't quite remember if i also tested with DRI2 on 
old/current userspace, but probably). Hardware measured timing tests all 
work fine.


So all is good, except for pre-DCE4 without pflip irqs, but for that see 
the patchset i just sent out, which should make those old asics work 
well as well.


-mario

On 08/16/2016 03:49 AM, Michel Dänzer wrote:

On 16/08/16 09:35 AM, Mario Kleiner wrote:

Hi Michel,

sorry for the super-late reply, i was just catching up with all the
mails and discussions, starting in June, leading to this patch set.

Looks all pretty good.

I'll look at this radeon patch and 2/6 for amdgpu later this week when i
have a fresh brain and enough "obsessive compulsive time", to make sure
all the magic wrt. "virtually extended vblank" and the fudging logic is
fine.


Excellent!



I'll then also run it through my timing tests. I assume the
ati/amdgpu-ddx patches and libdrm patches in your freedesktop home are
all i need for testing?


Yes, although it would also be nice to test with unmodified userspace
and make sure there are no regressions with that.



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


Re: [pull] radeon and amdgpu drm-next-4.9

2016-09-18 Thread Lukas Wunner
On Fri, Sep 16, 2016 at 06:07:36PM -0400, Alex Deucher wrote:
> On Fri, Sep 16, 2016 at 5:38 PM, Lukas Wunner  wrote:
> > On Fri, Sep 16, 2016 at 04:42:43PM -0400, Alex Deucher wrote:
> >>   drm/amdgpu: skip suspend/resume on DRM_SWITCH_POWER_DYNAMIC_OFF
> >>   drm/radeon: skip suspend/resume on DRM_SWITCH_POWER_DYNAMIC_OFF
> >
> > Those two are unnecessary, it can't happen that the ->suspend hook
> > is executed with the device runtime suspended.
> >
> > Since commit d14d2a8453d6 ("drm: Remove dev_pm_ops from drm_class"),
> > DRM devices are afforded direct_complete, i.e. if the GPU is runtime
> > suspended upon system sleep, it is left in this state.  The only
> > callbacks that are executed are the ->prepare and the ->complete hook.
> > All the callbacks in-between, like ->suspend, are skipped.
> >
> > Even if direct_complete is not afforded for some reason, the PM core
> > will automatically runtime resume the device before executing ->suspend.
> >
> > That ->suspend is skipped in the DRM_SWITCH_POWER_OFF case was done
> > because the device is suspended behind the PM core's back if runpm=0
> > is set.  (And it doesn't work properly because the PCI core will
> > invalidate the saved_state during ->resume_noirq.  That could be
> > solved by returning 1 from the ->prepare hook in the DRM_SWITCH_POWER_OFF
> > case, but that's a different story.)
> >
> > (Sorry for not raising this earlier, I'm not subscribed to amd-gfx.)
> 
> Thanks for the heads up.  They shouldn't hurt anything and it matches
> what other drivers do.  If you feel strongly about it, I can revert
> them later.

Well, superfluous code shouldn't be included just because it doesn't hurt
or because others didn't know better either, or removed because of
someone else's feelings. ;-)

You can find the runtime resume before execution of the driver ->suspend
callback in drivers/pci/pci-driver.c:pci_pm_suspend():

const struct dev_pm_ops *pm = dev->driver ? dev->driver->pm : NULL;
...
pm_runtime_resume(dev);
...
if (pm->suspend) {
...
error = pm->suspend(dev);

The device is prevented from auto-suspending because of a runtime PM ref
acquired beforehand in drivers/base/power/main.c:device_prepare().

Best regards,

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


[PATCH 3/3] drm/amdgpu: set gfx clock gating for tonga/polaris.

2016-09-18 Thread Rex Zhu
Change-Id: I65d9858b8ca0789c5d82db2f8893b7c10fc6f471
Signed-off-by: Rex Zhu 
---
 drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 77 +++
 1 file changed, 77 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c 
b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
index 1902442..9970893 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
@@ -5818,6 +5818,76 @@ static int gfx_v8_0_update_gfx_clock_gating(struct 
amdgpu_device *adev,
return 0;
 }
 
+static int gfx_v8_0_tonga_update_gfx_clock_gating(struct amdgpu_device *adev,
+ enum amd_clockgating_state state)
+{
+   uint32_t msg_id, pp_state;
+   void *pp_handle = adev->powerplay.pp_handle;
+
+   if (state == AMD_CG_STATE_UNGATE)
+   pp_state = 0;
+   else
+   pp_state = PP_STATE_CG | PP_STATE_LS;
+
+   msg_id = PP_CG_MSG_ID(PP_GROUP_GFX,
+   PP_BLOCK_GFX_CG,
+   PP_STATE_SUPPORT_CG | PP_STATE_SUPPORT_LS,
+   pp_state);
+   amd_set_clockgating_by_smu(pp_handle, msg_id);
+
+   msg_id = PP_CG_MSG_ID(PP_GROUP_GFX,
+   PP_BLOCK_GFX_MG,
+   PP_STATE_SUPPORT_CG | PP_STATE_SUPPORT_LS,
+   pp_state);
+   amd_set_clockgating_by_smu(pp_handle, msg_id);
+
+   return 0;
+}
+
+static int gfx_v8_0_polaris_update_gfx_clock_gating(struct amdgpu_device *adev,
+ enum amd_clockgating_state state)
+{
+   uint32_t msg_id, pp_state;
+   void *pp_handle = adev->powerplay.pp_handle;
+
+   if (state == AMD_CG_STATE_UNGATE)
+   pp_state = 0;
+   else
+   pp_state = PP_STATE_CG | PP_STATE_LS;
+
+   msg_id = PP_CG_MSG_ID(PP_GROUP_GFX,
+   PP_BLOCK_GFX_CG,
+   PP_STATE_SUPPORT_CG | PP_STATE_SUPPORT_LS,
+   pp_state);
+   amd_set_clockgating_by_smu(pp_handle, msg_id);
+
+   msg_id = PP_CG_MSG_ID(PP_GROUP_GFX,
+   PP_BLOCK_GFX_3D,
+   PP_STATE_SUPPORT_CG | PP_STATE_SUPPORT_LS,
+   pp_state);
+   amd_set_clockgating_by_smu(pp_handle, msg_id);
+
+   msg_id = PP_CG_MSG_ID(PP_GROUP_GFX,
+   PP_BLOCK_GFX_MG,
+   PP_STATE_SUPPORT_CG | PP_STATE_SUPPORT_LS,
+   pp_state);
+   amd_set_clockgating_by_smu(pp_handle, msg_id);
+
+   msg_id = PP_CG_MSG_ID(PP_GROUP_GFX,
+   PP_BLOCK_GFX_RLC,
+   PP_STATE_SUPPORT_CG | PP_STATE_SUPPORT_LS,
+   pp_state);
+   amd_set_clockgating_by_smu(pp_handle, msg_id);
+
+   msg_id = PP_CG_MSG_ID(PP_GROUP_GFX,
+   PP_BLOCK_GFX_CP,
+   PP_STATE_SUPPORT_CG | PP_STATE_SUPPORT_LS,
+   pp_state);
+   amd_set_clockgating_by_smu(pp_handle, msg_id);
+
+   return 0;
+}
+
 static int gfx_v8_0_set_clockgating_state(void *handle,
  enum amd_clockgating_state state)
 {
@@ -5830,6 +5900,13 @@ static int gfx_v8_0_set_clockgating_state(void *handle,
gfx_v8_0_update_gfx_clock_gating(adev,
 state == AMD_CG_STATE_GATE ? 
true : false);
break;
+   case CHIP_TONGA:
+   gfx_v8_0_tonga_update_gfx_clock_gating(adev, state);
+   break;
+   case CHIP_POLARIS10:
+   case CHIP_POLARIS11:
+   gfx_v8_0_polaris_update_gfx_clock_gating(adev, state);
+   break;
default:
break;
}
-- 
1.9.1

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


[PATCH 2/3] drm/amdgpu: set system clock gating for tonga/polaris.

2016-09-18 Thread Rex Zhu
Change-Id: Ie66afaea8b30c4b7b6d491c7aa63775e4a5cd6e1
Signed-off-by: Rex Zhu 
---
 drivers/gpu/drm/amd/amdgpu/vi.c | 61 +
 1 file changed, 61 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/vi.c b/drivers/gpu/drm/amd/amdgpu/vi.c
index 370bf2f..6561c54 100644
--- a/drivers/gpu/drm/amd/amdgpu/vi.c
+++ b/drivers/gpu/drm/amd/amdgpu/vi.c
@@ -2131,6 +2131,63 @@ static void 
vi_update_rom_medium_grain_clock_gating(struct amdgpu_device *adev,
WREG32_SMC(ixCGTT_ROM_CLK_CTRL0, data);
 }
 
+static int vi_common_set_clockgating_state_by_smu(void *handle,
+  enum amd_clockgating_state state)
+{
+   uint32_t msg_id, pp_state;
+   struct amdgpu_device *adev = (struct amdgpu_device *)handle;
+   void *pp_handle = adev->powerplay.pp_handle;
+
+   if (state == AMD_CG_STATE_UNGATE)
+   pp_state = 0;
+   else
+   pp_state = PP_STATE_CG | PP_STATE_LS;
+
+   msg_id = PP_CG_MSG_ID(PP_GROUP_SYS,
+  PP_BLOCK_SYS_MC,
+  PP_STATE_SUPPORT_CG | PP_STATE_SUPPORT_LS,
+  pp_state);
+   amd_set_clockgating_by_smu(pp_handle, msg_id);
+
+   msg_id = PP_CG_MSG_ID(PP_GROUP_SYS,
+  PP_BLOCK_SYS_SDMA,
+  PP_STATE_SUPPORT_CG | PP_STATE_SUPPORT_LS,
+  pp_state);
+   amd_set_clockgating_by_smu(pp_handle, msg_id);
+
+   msg_id = PP_CG_MSG_ID(PP_GROUP_SYS,
+  PP_BLOCK_SYS_HDP,
+  PP_STATE_SUPPORT_CG | PP_STATE_SUPPORT_LS,
+  pp_state);
+   amd_set_clockgating_by_smu(pp_handle, msg_id);
+
+   msg_id = PP_CG_MSG_ID(PP_GROUP_SYS,
+  PP_BLOCK_SYS_BIF,
+  PP_STATE_SUPPORT_LS,
+  pp_state);
+   amd_set_clockgating_by_smu(pp_handle, msg_id);
+
+   msg_id = PP_CG_MSG_ID(PP_GROUP_SYS,
+  PP_BLOCK_SYS_BIF,
+  PP_STATE_SUPPORT_CG,
+  pp_state);
+   amd_set_clockgating_by_smu(pp_handle, msg_id);
+
+   msg_id = PP_CG_MSG_ID(PP_GROUP_SYS,
+  PP_BLOCK_SYS_DRM,
+  PP_STATE_SUPPORT_LS,
+  pp_state);
+   amd_set_clockgating_by_smu(pp_handle, msg_id);
+
+   msg_id = PP_CG_MSG_ID(PP_GROUP_SYS,
+  PP_BLOCK_SYS_ROM,
+  PP_STATE_SUPPORT_CG,
+  pp_state);
+   amd_set_clockgating_by_smu(pp_handle, msg_id);
+
+   return 0;
+}
+
 static int vi_common_set_clockgating_state(void *handle,
   enum amd_clockgating_state state)
 {
@@ -2156,6 +2213,10 @@ static int vi_common_set_clockgating_state(void *handle,
vi_update_hdp_light_sleep(adev,
state == AMD_CG_STATE_GATE ? true : false);
break;
+   case CHIP_TONGA:
+   case CHIP_POLARIS10:
+   case CHIP_POLARIS11:
+   vi_common_set_clockgating_state_by_smu(adev, state);
default:
break;
}
-- 
1.9.1

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


Re: [PATCH 3/5] drm/amdgpu:fix RB cost calculator

2016-09-18 Thread Christian König

Alex fixed this up in a rather complete series for all engines/rings.

Christian.

Am 18.09.2016 um 05:47 schrieb Liu, Monk:

Is that applied to all ring ?

Cuz seems only GFX ring each lot of dw per submit ...

BR Monk

-Original Message-
From: Christian König [mailto:deathsim...@vodafone.de]
Sent: Thursday, September 15, 2016 3:24 PM
To: Andy Furniss ; Liu, Monk ; 
amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH 3/5] drm/amdgpu:fix RB cost calculator

256dw for the header are probably not enough.

Since we now uses NOPs for the CE/DE sync we only need 256dw for that alone. I 
suggest to raise that to 512.

Christian.

Am 15.09.2016 um 00:24 schrieb Andy Furniss:

This has just gone into drm-next-4.9-wip and caused lots of logging
noise.

Seems to work OK though.

Sep 14 23:18:38 ph4 kernel: [drm:gfx_v8_0_ring_emit_fence_gfx
[amdgpu]] *ERROR* amdgpu: writing more dwords to the ring than expected!
Sep 14 23:18:38 ph4 last message repeated 11 times Sep 14 23:18:38 ph4
kernel: [drm:gfx_v8_ring_emit_sb [amdgpu]] *ERROR*
amdgpu: writing more dwords to the ring than expected!
Sep 14 23:18:38 ph4 kernel: [drm:gfx_v8_ring_emit_sb [amdgpu]] *ERROR*
amdgpu: writing more dwords to the ring than expected!
Sep 14 23:18:38 ph4 kernel: [drm:amdgpu_ring_insert_nop [amdgpu]]
*ERROR* amdgpu: writing more dwords to the ring than expected!
Sep 14 23:18:38 ph4 last message repeated 10 times Sep 14 23:18:38 ph4
kernel: [drm:gfx_v8_0_ring_emit_ib_gfx [amdgpu]]
*ERROR* amdgpu: writing more dwords to the ring than expected!
Sep 14 23:18:38 ph4 kernel: [drm:gfx_v8_0_ring_emit_ib_gfx [amdgpu]]
*ERROR* amdgpu: writing more dwords to the ring than expected!
Sep 14 23:18:38 ph4 kernel: [drm:gfx_v8_0_ring_emit_hdp_invalidate
[amdgpu]] *ERROR* amdgpu: writing more dwords to the ring than expected!
Sep 14 23:18:38 ph4 last message repeated 4 times Sep 14 23:18:38 ph4
kernel: [drm:gfx_v8_0_ring_emit_fence_gfx [amdgpu]] *ERROR* amdgpu:
writing more dwords to the ring than expected!
Sep 14 23:18:38 ph4 last message repeated 11 times Sep 14 23:18:38 ph4
kernel: [drm:gfx_v8_ring_emit_sb [amdgpu]] *ERROR*
amdgpu: writing more dwords to the ring than expected!
Sep 14 23:18:38 ph4 kernel: [drm:gfx_v8_ring_emit_sb [amdgpu]] *ERROR*
amdgpu: writing more dwords to the ring than expected!
Sep 14 23:18:38 ph4 kernel: [drm:amdgpu_ring_insert_nop [amdgpu]]
*ERROR* amdgpu: writing more dwords to the ring than expected!
Sep 14 23:18:38 ph4 last message repeated 10 times

Monk Liu wrote:

Change-Id: Ie3e4587ed49c487c562f45a99f236a76727ace1e
Signed-off-by: Monk Liu 
---
   drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c | 2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
index 029ee79..6ad45fa 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
@@ -151,7 +151,7 @@ int amdgpu_ib_schedule(struct amdgpu_ring *ring,
unsigned num_ibs,
   return -EINVAL;
   }

-r = amdgpu_ring_alloc(ring, 256 * num_ibs);
+r = amdgpu_ring_alloc(ring, 256 + (num_ibs << 4));
   if (r) {
   dev_err(adev->dev, "scheduling IB failed (%d).\n", r);
   return r;


___
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