On 06/05/2018 02:20 PM, Christian König wrote:
Hi Jerry,
Am 05.06.2018 um 03:50 schrieb Zhang, Jerry (Junwei):
[SNIP]
Can you check if the problem also vanishes when you disable the following
optimization in amdgpu_vm_update_ptes?
/* We don't need to update PTEs for huge page
Reviewed-by: Hawking Zhang
Regards,
Hawking
-Original Message-
From: amd-gfx On Behalf Of Huang Rui
Sent: 2018年6月5日 11:02
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander ; Kuehling, Felix
; Huang, Ray ; Koenig, Christian
; Zhang, Hawking
Subject: [PATCH v2] drm/amdgpu: fix CG
Am 05.06.2018 um 05:01 schrieb Huang Rui:
After defer the execution of clockgating enabling, at that time, gfx already
enter into "off" state. Howerver, clockgating enabling will use MMIO to access
the gfx registers, then get the gfx hung.
So here we should move the gfx powergating and gfxoff en
Hi Jerry,
Am 05.06.2018 um 03:50 schrieb Zhang, Jerry (Junwei):
[SNIP]
Can you check if the problem also vanishes when you disable the
following
optimization in amdgpu_vm_update_ptes?
/* We don't need to update PTEs for huge pages */
if (entry->huge)
Am 04.06.2018 um 21:35 schrieb Lyude Paul:
So, unfortunately I recently made the discovery that in the upstream
kernel, the only reason that amdgpu is not currently suffering from
issues with runtime PM putting the GPU into suspend while it's driving
displays is due to the fact that on most prime
Raven support gfx off feature instand of gfx powergate,
so use smu10_gfx_off_control as the powergate_gfx backend function.
Signed-off-by: Rex Zhu
---
drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_h
On 06/04/2018 07:01 PM, Christian König wrote:
I've figured out what's going wrong here.
Your analysis of the problem is correct, but the proposed fix just doesn't
handle everything.
The issue is that I assumed in the replace operation that the existing lose end
of the mapping can stay as they
This is a ip function for set smu pg state.
Although the cg/pg were still not supported on legacy asics, we should not
add other ip block's pg code in it.
Signed-off-by: Rex Zhu
---
drivers/gpu/drm/amd/powerplay/amd_powerplay.c | 25 +
1 file changed, 1 insertion(+), 24 d
gfx ip block can call set_powergating_by_smu to set gfx pg state if
necessary.
Signed-off-by: Rex Zhu
---
drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 10 --
drivers/gpu/drm/amd/amdgpu/mmhub_v1_0.c | 4 ++--
drivers/gpu/drm/amd/powerplay/amd_powerplay.c | 17 +
In order to keep consistent with powergate_uvd/vce.
Signed-off-by: Rex Zhu
---
drivers/gpu/drm/amd/amdgpu/amdgpu_dpm.h | 4 ++--
drivers/gpu/drm/amd/amdgpu/mmhub_v1_0.c | 4 ++--
drivers/gpu/drm/amd/include/kgd_pp_interface.h| 2 +-
drivers/gpu/drm/amd/powerplay/amd_power
Some HW ip blocks need call SMU to enter/leave power gate state.
So export common set_powergating_by_smu interface.
1. keep consistent with set_clockgating_by_smu
2. scales easily to powergate other ip(gfx) if necessary
Signed-off-by: Rex Zhu
---
drivers/gpu/drm/amd/amdgpu/amdgpu_dpm.h|
keep consistent with powergate_uvd/vce/mmhub
Signed-off-by: Rex Zhu
---
drivers/gpu/drm/amd/powerplay/amd_powerplay.c | 4 ++--
drivers/gpu/drm/amd/powerplay/hwmgr/smu7_clockpowergating.c | 2 +-
drivers/gpu/drm/amd/powerplay/hwmgr/smu7_clockpowergating.h | 2 +-
drivers/gpu/drm/am
After defer the execution of clockgating enabling, at that time, gfx already
enter into "off" state. Howerver, clockgating enabling will use MMIO to access
the gfx registers, then get the gfx hung.
So here we should move the gfx powergating and gfxoff enabling behavior at the
end of initialization
On 06/04/2018 05:51 PM, Christian König wrote:
Am 04.06.2018 um 10:19 schrieb Zhang, Jerry (Junwei):
On 06/04/2018 03:48 PM, Christian König wrote:
Am 04.06.2018 um 09:02 schrieb Zhang, Jerry (Junwei):
On 06/04/2018 02:43 PM, Christian König wrote:
Actually that is not correct. According to t
So, unfortunately I recently made the discovery that in the upstream
kernel, the only reason that amdgpu is not currently suffering from
issues with runtime PM putting the GPU into suspend while it's driving
displays is due to the fact that on most prime systems, we have sound
devices associated wi
Am 04.06.2018 um 20:39 schrieb Andrey Grodzovsky:
Dying process might be blocked from receiving any more signals
so avoid using it.
Also retire enity->fini_status and just check the SW queue,
if it's not empty do the fallback cleanup.
Also handle entity->last_scheduled == NULL use case which
ha
With this we can now terminate jobs enqueue into SW queue the moment
the task is being killed instead of waiting for last user of
drm file to release it.
Also stop checking for kref_read(&ctx->refcount) == 1 when
calling drm_sched_entity_do_release since other task
might still hold a reference to
Dying process might be blocked from receiving any more signals
so avoid using it.
Also retire enity->fini_status and just check the SW queue,
if it's not empty do the fallback cleanup.
Also handle entity->last_scheduled == NULL use case which
happens when HW ring is already hangged whem a new en
Ok that explains it. I was already wondering what the heck I was missing :)
The second patch already looked fine to me as well.
Just send it out once more to get an rb,
Christian.
Am 04.06.2018 um 20:03 schrieb Andrey Grodzovsky:
I reread the documentation for wait_event_timeout, my bad, all
I reread the documentation for wait_event_timeout, my bad, all this time
i assumed it returns
amount of jiffies he spent in waiting while actually it returns "the
remaining jiffies (at least 1)
if the @condition evaluated
* to %true before the @timeout elapsed."
Will fix that, please take a
Am 04.06.2018 um 17:03 schrieb Andrey Grodzovsky:
Dying process might be blocked from receiving any more signals
so avoid using it.
Also retire enity->fini_status and just check the SW queue,
if it's not empty do the fallback cleanup.
Also handle entity->last_scheduled == NULL use case which
ha
With this we can now terminate jobs enqueue into SW queue the moment
the task is being killed instead of waiting for last user of
drm file to release it.
Also stop checking for kref_read(&ctx->refcount) == 1 when
calling drm_sched_entity_do_release since other task
might still hold a reference to
Dying process might be blocked from receiving any more signals
so avoid using it.
Also retire enity->fini_status and just check the SW queue,
if it's not empty do the fallback cleanup.
Also handle entity->last_scheduled == NULL use case which
happens when HW ring is already hangged whem a new en
On 2018-06-04 12:59 PM, Christian König wrote:
> We need to put the lose ends on the invalid list because it is possible
> that we need to split up huge pages for them.
>
> Signed-off-by: Christian König
Does this need to go to stable?
--
Earthling Michel Dänzer |
I've figured out what's going wrong here.
Your analysis of the problem is correct, but the proposed fix just
doesn't handle everything.
The issue is that I assumed in the replace operation that the existing
lose end of the mapping can stay as they are, but that assumption is
actually not cor
We need to put the lose ends on the invalid list because it is possible
that we need to split up huge pages for them.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgp
driver need to know the real power source to do some power
related configuration when initialize.
Signed-off-by: Rex Zhu
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/
driver need to update uvd/vce smc table before enable
uvd/vce dpm.
Signed-off-by: Rex Zhu
---
drivers/gpu/drm/amd/powerplay/smumgr/ci_smumgr.c | 84
1 file changed, 84 insertions(+)
diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/ci_smumgr.c
b/drivers/gpu/drm/amd/pow
if vbios not set the max clock voltage limit table for DC mode,
Set the table as sama as the table for AC mode.
Signed-off-by: Rex Zhu
---
drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
b
Am 04.06.2018 um 10:19 schrieb Zhang, Jerry (Junwei):
On 06/04/2018 03:48 PM, Christian König wrote:
Am 04.06.2018 um 09:02 schrieb Zhang, Jerry (Junwei):
On 06/04/2018 02:43 PM, Christian König wrote:
Actually that is not correct. According to the documentation the
PRT flag should
work for h
On 2018-06-01 08:03 PM, Alex Deucher wrote:
> Document the hwmon and power control interfaces exposed
> by the amdgpu driver.
>
> Signed-off-by: Alex Deucher
> ---
> Documentation/gpu/amdgpu.rst | 52
> ++
> drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c | 45 +
Adding dri-devel.
On 2018-06-01 08:03 PM, Alex Deucher wrote:
> Use chapter rather than section to align with the rst markup.
>
> Signed-off-by: Alex Deucher
> ---
> Documentation/gpu/amdgpu.rst | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/gpu/amdgpu
1. move ac_power to struct pm from dpm, so can be shared with powerplay
2. remove power_source in powerplay, use adev->pm.ac_power instand.
3. update ac_power before dispatch power task.
Signed-off-by: Rex Zhu
---
drivers/gpu/drm/amd/amdgpu/amdgpu_dpm.h| 2 +-
drivers/gpu/drm/amd/am
On 06/04/2018 03:48 PM, Christian König wrote:
Am 04.06.2018 um 09:02 schrieb Zhang, Jerry (Junwei):
On 06/04/2018 02:43 PM, Christian König wrote:
Actually that is not correct. According to the documentation the PRT flag should
work for huge pages as well.
Mmm, I checked the doc earlier, did
Am 04.06.2018 um 09:52 schrieb Huang Rui:
On Sat, Jun 02, 2018 at 03:01:57AM +0800, Kuehling, Felix wrote:
On 2018-06-01 06:09 AM, Christian König wrote:
Am 01.06.2018 um 11:29 schrieb Huang Rui:
On Fri, Jun 01, 2018 at 05:13:49PM +0800, Christian König wrote:
Am 01.06.2018 um 08:41 schrieb H
Am 04.06.2018 um 09:02 schrieb Zhang, Jerry (Junwei):
On 06/04/2018 02:43 PM, Christian König wrote:
Actually that is not correct. According to the documentation the PRT
flag should
work for huge pages as well.
Mmm, I checked the doc earlier, didn't find the PRT flag for PDE.
The PDE indeed
On Sat, Jun 02, 2018 at 03:01:57AM +0800, Kuehling, Felix wrote:
> On 2018-06-01 06:09 AM, Christian König wrote:
> > Am 01.06.2018 um 11:29 schrieb Huang Rui:
> >> On Fri, Jun 01, 2018 at 05:13:49PM +0800, Christian König wrote:
> >>> Am 01.06.2018 um 08:41 schrieb Huang Rui:
> After defer th
On Fri, Jun 01, 2018 at 10:37:33PM +0800, Alex Deucher wrote:
> On Thu, May 31, 2018 at 11:07 PM, Huang Rui wrote:
> > On Thu, May 24, 2018 at 02:46:34PM -0500, Alex Deucher wrote:
> >> This reverts commit 13b40935cf64f59b93cf1c716a2033488e5a228c.
> >>
> >> This was a workaround for a bug in the H
On 06/04/2018 02:43 PM, Christian König wrote:
Actually that is not correct. According to the documentation the PRT flag should
work for huge pages as well.
Mmm, I checked the doc earlier, didn't find the PRT flag for PDE.
In CTS PRT test, the reserved PRT mapping introduces huge page mapping,
39 matches
Mail list logo
