* [PATCH] drm/amd/amdgpu: disable GFXOFF around debugfs access to MMIO
@ 2020-02-19 15:04 Tom St Denis
2020-02-19 15:07 ` Alex Deucher
0 siblings, 1 reply; 18+ messages in thread
From: Tom St Denis @ 2020-02-19 15:04 UTC (permalink / raw)
To: amd-gfx; +Cc: Tom St Denis
Signed-off-by: Tom St Denis <tom.stdenis@amd.com>
---
drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
index 7379910790c9..66f763300c96 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
@@ -169,6 +169,7 @@ static int amdgpu_debugfs_process_reg_op(bool read, struct file *f,
if (pm_pg_lock)
mutex_lock(&adev->pm.mutex);
+ amdgpu_gfx_off_ctrl(adev, false);
while (size) {
uint32_t value;
@@ -192,6 +193,8 @@ static int amdgpu_debugfs_process_reg_op(bool read, struct file *f,
}
end:
+ amdgpu_gfx_off_ctrl(adev, true);
+
if (use_bank) {
amdgpu_gfx_select_se_sh(adev, 0xffffffff, 0xffffffff, 0xffffffff);
mutex_unlock(&adev->grbm_idx_mutex);
--
2.24.1
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
^ permalink raw reply related [flat|nested] 18+ messages in thread
* Re: [PATCH] drm/amd/amdgpu: disable GFXOFF around debugfs access to MMIO
2020-02-19 15:04 [PATCH] drm/amd/amdgpu: disable GFXOFF around debugfs access to MMIO Tom St Denis
@ 2020-02-19 15:07 ` Alex Deucher
2020-02-19 15:09 ` Tom St Denis
0 siblings, 1 reply; 18+ messages in thread
From: Alex Deucher @ 2020-02-19 15:07 UTC (permalink / raw)
To: Tom St Denis; +Cc: amd-gfx list
On Wed, Feb 19, 2020 at 10:04 AM Tom St Denis <tom.stdenis@amd.com> wrote:
>
> Signed-off-by: Tom St Denis <tom.stdenis@amd.com>
Please add a patch description. With that fixed:
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
> index 7379910790c9..66f763300c96 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
> @@ -169,6 +169,7 @@ static int amdgpu_debugfs_process_reg_op(bool read, struct file *f,
> if (pm_pg_lock)
> mutex_lock(&adev->pm.mutex);
>
> + amdgpu_gfx_off_ctrl(adev, false);
> while (size) {
> uint32_t value;
>
> @@ -192,6 +193,8 @@ static int amdgpu_debugfs_process_reg_op(bool read, struct file *f,
> }
>
> end:
> + amdgpu_gfx_off_ctrl(adev, true);
> +
> if (use_bank) {
> amdgpu_gfx_select_se_sh(adev, 0xffffffff, 0xffffffff, 0xffffffff);
> mutex_unlock(&adev->grbm_idx_mutex);
> --
> 2.24.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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] drm/amd/amdgpu: disable GFXOFF around debugfs access to MMIO
2020-02-19 15:07 ` Alex Deucher
@ 2020-02-19 15:09 ` Tom St Denis
2020-02-21 14:34 ` Huang Rui
0 siblings, 1 reply; 18+ messages in thread
From: Tom St Denis @ 2020-02-19 15:09 UTC (permalink / raw)
To: Alex Deucher; +Cc: amd-gfx list
I got some messages after a while:
[ 741.788564] Failed to send Message 8.
[ 746.671509] Failed to send Message 8.
[ 748.749673] Failed to send Message 2b.
[ 759.245414] Failed to send Message 7.
[ 763.216902] Failed to send Message 2a.
Are there any additional locks that should be held? Because some
commands like --top or --waves can do a lot of distinct read operations
(causing a lot of enable/disable calls).
I'm going to sit on this a bit since I don't think the patch is ready
for pushing out.
Tom
On 2020-02-19 10:07 a.m., Alex Deucher wrote:
> On Wed, Feb 19, 2020 at 10:04 AM Tom St Denis <tom.stdenis@amd.com> wrote:
>> Signed-off-by: Tom St Denis <tom.stdenis@amd.com>
> Please add a patch description. With that fixed:
> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
>
>> ---
>> drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
>> index 7379910790c9..66f763300c96 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
>> @@ -169,6 +169,7 @@ static int amdgpu_debugfs_process_reg_op(bool read, struct file *f,
>> if (pm_pg_lock)
>> mutex_lock(&adev->pm.mutex);
>>
>> + amdgpu_gfx_off_ctrl(adev, false);
>> while (size) {
>> uint32_t value;
>>
>> @@ -192,6 +193,8 @@ static int amdgpu_debugfs_process_reg_op(bool read, struct file *f,
>> }
>>
>> end:
>> + amdgpu_gfx_off_ctrl(adev, true);
>> +
>> if (use_bank) {
>> amdgpu_gfx_select_se_sh(adev, 0xffffffff, 0xffffffff, 0xffffffff);
>> mutex_unlock(&adev->grbm_idx_mutex);
>> --
>> 2.24.1
>>
>> _______________________________________________
>> amd-gfx mailing list
>> amd-gfx@lists.freedesktop.org
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=02%7C01%7Ctom.stdenis%40amd.com%7Cf3c4cd3120fa476bbca808d7b54d8076%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637177216782684720&sdata=m5eyco1nGc5XD%2Ford7Q3goA48G5NhR%2BqdSYQjnfd7%2Fg%3D&reserved=0
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] drm/amd/amdgpu: disable GFXOFF around debugfs access to MMIO
2020-02-19 15:09 ` Tom St Denis
@ 2020-02-21 14:34 ` Huang Rui
2020-02-21 14:35 ` Tom St Denis
2020-02-21 15:18 ` 回复: " Liu, Monk
0 siblings, 2 replies; 18+ messages in thread
From: Huang Rui @ 2020-02-21 14:34 UTC (permalink / raw)
To: Tom St Denis; +Cc: Alex Deucher, amd-gfx list
On Wed, Feb 19, 2020 at 10:09:46AM -0500, Tom St Denis wrote:
> I got some messages after a while:
>
> [ 741.788564] Failed to send Message 8.
> [ 746.671509] Failed to send Message 8.
> [ 748.749673] Failed to send Message 2b.
> [ 759.245414] Failed to send Message 7.
> [ 763.216902] Failed to send Message 2a.
>
> Are there any additional locks that should be held? Because some commands
> like --top or --waves can do a lot of distinct read operations (causing a
> lot of enable/disable calls).
>
> I'm going to sit on this a bit since I don't think the patch is ready for
> pushing out.
>
How about use RREG32_KIQ and WREG32_KIQ?
Thanks,
Ray
>
> Tom
>
> On 2020-02-19 10:07 a.m., Alex Deucher wrote:
> > On Wed, Feb 19, 2020 at 10:04 AM Tom St Denis <tom.stdenis@amd.com> wrote:
> > > Signed-off-by: Tom St Denis <tom.stdenis@amd.com>
> > Please add a patch description. With that fixed:
> > Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
> >
> > > ---
> > > drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 3 +++
> > > 1 file changed, 3 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
> > > index 7379910790c9..66f763300c96 100644
> > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
> > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
> > > @@ -169,6 +169,7 @@ static int amdgpu_debugfs_process_reg_op(bool read, struct file *f,
> > > if (pm_pg_lock)
> > > mutex_lock(&adev->pm.mutex);
> > >
> > > + amdgpu_gfx_off_ctrl(adev, false);
> > > while (size) {
> > > uint32_t value;
> > >
> > > @@ -192,6 +193,8 @@ static int amdgpu_debugfs_process_reg_op(bool read, struct file *f,
> > > }
> > >
> > > end:
> > > + amdgpu_gfx_off_ctrl(adev, true);
> > > +
> > > if (use_bank) {
> > > amdgpu_gfx_select_se_sh(adev, 0xffffffff, 0xffffffff, 0xffffffff);
> > > mutex_unlock(&adev->grbm_idx_mutex);
> > > --
> > > 2.24.1
> > >
> > > _______________________________________________
> > > amd-gfx mailing list
> > > amd-gfx@lists.freedesktop.org
> > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=02%7C01%7Cray.huang%40amd.com%7C7db7d3365c8842d46cde08d7b54dc560%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637177217984125436&sdata=NBNxMQ%2Fuq7YswVzlrvZWbSmcf4JUt4eL5L62%2F7iLL28%3D&reserved=0
> _______________________________________________
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=02%7C01%7Cray.huang%40amd.com%7C7db7d3365c8842d46cde08d7b54dc560%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637177217984125436&sdata=NBNxMQ%2Fuq7YswVzlrvZWbSmcf4JUt4eL5L62%2F7iLL28%3D&reserved=0
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] drm/amd/amdgpu: disable GFXOFF around debugfs access to MMIO
2020-02-21 14:34 ` Huang Rui
@ 2020-02-21 14:35 ` Tom St Denis
2020-02-21 14:44 ` Huang Rui
2020-02-21 15:18 ` 回复: " Liu, Monk
1 sibling, 1 reply; 18+ messages in thread
From: Tom St Denis @ 2020-02-21 14:35 UTC (permalink / raw)
To: Huang Rui; +Cc: Alex Deucher, amd-gfx list
On 2020-02-21 9:34 a.m., Huang Rui wrote:
> On Wed, Feb 19, 2020 at 10:09:46AM -0500, Tom St Denis wrote:
>> I got some messages after a while:
>>
>> [ 741.788564] Failed to send Message 8.
>> [ 746.671509] Failed to send Message 8.
>> [ 748.749673] Failed to send Message 2b.
>> [ 759.245414] Failed to send Message 7.
>> [ 763.216902] Failed to send Message 2a.
>>
>> Are there any additional locks that should be held? Because some commands
>> like --top or --waves can do a lot of distinct read operations (causing a
>> lot of enable/disable calls).
>>
>> I'm going to sit on this a bit since I don't think the patch is ready for
>> pushing out.
>>
> How about use RREG32_KIQ and WREG32_KIQ?
For all register accesses (in the debugfs read/write method)? Can we use
those on all ASICs?
Tom
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] drm/amd/amdgpu: disable GFXOFF around debugfs access to MMIO
2020-02-21 14:35 ` Tom St Denis
@ 2020-02-21 14:44 ` Huang Rui
0 siblings, 0 replies; 18+ messages in thread
From: Huang Rui @ 2020-02-21 14:44 UTC (permalink / raw)
To: StDenis, Tom; +Cc: Alex Deucher, amd-gfx list
On Fri, Feb 21, 2020 at 10:35:33PM +0800, StDenis, Tom wrote:
>
> On 2020-02-21 9:34 a.m., Huang Rui wrote:
> > On Wed, Feb 19, 2020 at 10:09:46AM -0500, Tom St Denis wrote:
> >> I got some messages after a while:
> >>
> >> [ 741.788564] Failed to send Message 8.
> >> [ 746.671509] Failed to send Message 8.
> >> [ 748.749673] Failed to send Message 2b.
> >> [ 759.245414] Failed to send Message 7.
> >> [ 763.216902] Failed to send Message 2a.
> >>
> >> Are there any additional locks that should be held? Because some commands
> >> like --top or --waves can do a lot of distinct read operations (causing a
> >> lot of enable/disable calls).
> >>
> >> I'm going to sit on this a bit since I don't think the patch is ready for
> >> pushing out.
> >>
> > How about use RREG32_KIQ and WREG32_KIQ?
>
>
> For all register accesses (in the debugfs read/write method)? Can we use
> those on all ASICs?
It can be used for all register access, but using KIQ is not as fast as MMIO.
So we can check if GFXOFF enabled, then go with KIQ path. Because KIQ can
wake up the GFX to "on" state at runtime.
Thanks,
Ray
>
>
> Tom
>
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
^ permalink raw reply [flat|nested] 18+ messages in thread
* 回复: [PATCH] drm/amd/amdgpu: disable GFXOFF around debugfs access to MMIO
2020-02-21 14:34 ` Huang Rui
2020-02-21 14:35 ` Tom St Denis
@ 2020-02-21 15:18 ` Liu, Monk
2020-02-21 15:23 ` Huang Rui
1 sibling, 1 reply; 18+ messages in thread
From: Liu, Monk @ 2020-02-21 15:18 UTC (permalink / raw)
To: Huang, Ray, StDenis, Tom; +Cc: Alex Deucher, amd-gfx list
Better not use KIQ, because when you use debugfs to read register you usually hit a hang, and by that case KIQ probably already die
-----邮件原件-----
发件人: amd-gfx <amd-gfx-bounces@lists.freedesktop.org> 代表 Huang Rui
发送时间: 2020年2月21日 22:34
收件人: StDenis, Tom <Tom.StDenis@amd.com>
抄送: Alex Deucher <alexdeucher@gmail.com>; amd-gfx list <amd-gfx@lists.freedesktop.org>
主题: Re: [PATCH] drm/amd/amdgpu: disable GFXOFF around debugfs access to MMIO
On Wed, Feb 19, 2020 at 10:09:46AM -0500, Tom St Denis wrote:
> I got some messages after a while:
>
> [ 741.788564] Failed to send Message 8.
> [ 746.671509] Failed to send Message 8.
> [ 748.749673] Failed to send Message 2b.
> [ 759.245414] Failed to send Message 7.
> [ 763.216902] Failed to send Message 2a.
>
> Are there any additional locks that should be held? Because some
> commands like --top or --waves can do a lot of distinct read
> operations (causing a lot of enable/disable calls).
>
> I'm going to sit on this a bit since I don't think the patch is ready
> for pushing out.
>
How about use RREG32_KIQ and WREG32_KIQ?
Thanks,
Ray
>
> Tom
>
> On 2020-02-19 10:07 a.m., Alex Deucher wrote:
> > On Wed, Feb 19, 2020 at 10:04 AM Tom St Denis <tom.stdenis@amd.com> wrote:
> > > Signed-off-by: Tom St Denis <tom.stdenis@amd.com>
> > Please add a patch description. With that fixed:
> > Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
> >
> > > ---
> > > drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 3 +++
> > > 1 file changed, 3 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
> > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
> > > index 7379910790c9..66f763300c96 100644
> > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
> > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
> > > @@ -169,6 +169,7 @@ static int amdgpu_debugfs_process_reg_op(bool read, struct file *f,
> > > if (pm_pg_lock)
> > > mutex_lock(&adev->pm.mutex);
> > >
> > > + amdgpu_gfx_off_ctrl(adev, false);
> > > while (size) {
> > > uint32_t value;
> > >
> > > @@ -192,6 +193,8 @@ static int amdgpu_debugfs_process_reg_op(bool read, struct file *f,
> > > }
> > >
> > > end:
> > > + amdgpu_gfx_off_ctrl(adev, true);
> > > +
> > > if (use_bank) {
> > > amdgpu_gfx_select_se_sh(adev, 0xffffffff, 0xffffffff, 0xffffffff);
> > > mutex_unlock(&adev->grbm_idx_mutex);
> > > --
> > > 2.24.1
> > >
> > > _______________________________________________
> > > amd-gfx mailing list
> > > amd-gfx@lists.freedesktop.org
> > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > > lists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=02%7
> > > C01%7Cmonk.liu%40amd.com%7Cba45efb26c0240ed036f08d7b6db20aa%7C3dd8
> > > 961fe4884e608e11a82d994e183d%7C0%7C0%7C637178924605524378&sdat
> > > a=%2FyHkvYU5T%2F4iFxRexsg%2BIdm7sDzyXbjzNpHUGCO7h4k%3D&reserve
> > > d=0
> _______________________________________________
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist
> s.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=02%7C01%7Cmo
> nk.liu%40amd.com%7Cba45efb26c0240ed036f08d7b6db20aa%7C3dd8961fe4884e60
> 8e11a82d994e183d%7C0%7C0%7C637178924605524378&sdata=%2FyHkvYU5T%2F
> 4iFxRexsg%2BIdm7sDzyXbjzNpHUGCO7h4k%3D&reserved=0
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=02%7C01%7Cmonk.liu%40amd.com%7Cba45efb26c0240ed036f08d7b6db20aa%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637178924605524378&sdata=%2FyHkvYU5T%2F4iFxRexsg%2BIdm7sDzyXbjzNpHUGCO7h4k%3D&reserved=0
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: 回复: [PATCH] drm/amd/amdgpu: disable GFXOFF around debugfs access to MMIO
2020-02-21 15:18 ` 回复: " Liu, Monk
@ 2020-02-21 15:23 ` Huang Rui
2020-02-21 15:27 ` Christian König
2020-02-22 2:19 ` 回复: " Liu, Monk
0 siblings, 2 replies; 18+ messages in thread
From: Huang Rui @ 2020-02-21 15:23 UTC (permalink / raw)
To: Liu, Monk; +Cc: StDenis, Tom, Alex Deucher, amd-gfx list
On Fri, Feb 21, 2020 at 11:18:07PM +0800, Liu, Monk wrote:
> Better not use KIQ, because when you use debugfs to read register you usually hit a hang, and by that case KIQ probably already die
If CP is busy, the gfx should be in "on" state at that time, we needn't use KIQ.
Thanks,
Ray
>
> -----邮件原件-----
> 发件人: amd-gfx <amd-gfx-bounces@lists.freedesktop.org> 代表 Huang Rui
> 发送时间: 2020年2月21日 22:34
> 收件人: StDenis, Tom <Tom.StDenis@amd.com>
> 抄送: Alex Deucher <alexdeucher@gmail.com>; amd-gfx list <amd-gfx@lists.freedesktop.org>
> 主题: Re: [PATCH] drm/amd/amdgpu: disable GFXOFF around debugfs access to MMIO
>
> On Wed, Feb 19, 2020 at 10:09:46AM -0500, Tom St Denis wrote:
> > I got some messages after a while:
> >
> > [ 741.788564] Failed to send Message 8.
> > [ 746.671509] Failed to send Message 8.
> > [ 748.749673] Failed to send Message 2b.
> > [ 759.245414] Failed to send Message 7.
> > [ 763.216902] Failed to send Message 2a.
> >
> > Are there any additional locks that should be held? Because some
> > commands like --top or --waves can do a lot of distinct read
> > operations (causing a lot of enable/disable calls).
> >
> > I'm going to sit on this a bit since I don't think the patch is ready
> > for pushing out.
> >
>
> How about use RREG32_KIQ and WREG32_KIQ?
>
> Thanks,
> Ray
>
> >
> > Tom
> >
> > On 2020-02-19 10:07 a.m., Alex Deucher wrote:
> > > On Wed, Feb 19, 2020 at 10:04 AM Tom St Denis <tom.stdenis@amd.com> wrote:
> > > > Signed-off-by: Tom St Denis <tom.stdenis@amd.com>
> > > Please add a patch description. With that fixed:
> > > Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
> > >
> > > > ---
> > > > drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 3 +++
> > > > 1 file changed, 3 insertions(+)
> > > >
> > > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
> > > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
> > > > index 7379910790c9..66f763300c96 100644
> > > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
> > > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
> > > > @@ -169,6 +169,7 @@ static int amdgpu_debugfs_process_reg_op(bool read, struct file *f,
> > > > if (pm_pg_lock)
> > > > mutex_lock(&adev->pm.mutex);
> > > >
> > > > + amdgpu_gfx_off_ctrl(adev, false);
> > > > while (size) {
> > > > uint32_t value;
> > > >
> > > > @@ -192,6 +193,8 @@ static int amdgpu_debugfs_process_reg_op(bool read, struct file *f,
> > > > }
> > > >
> > > > end:
> > > > + amdgpu_gfx_off_ctrl(adev, true);
> > > > +
> > > > if (use_bank) {
> > > > amdgpu_gfx_select_se_sh(adev, 0xffffffff, 0xffffffff, 0xffffffff);
> > > > mutex_unlock(&adev->grbm_idx_mutex);
> > > > --
> > > > 2.24.1
> > > >
> > > > _______________________________________________
> > > > amd-gfx mailing list
> > > > amd-gfx@lists.freedesktop.org
> > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > > > lists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=02%7
> > > > C01%7Cmonk.liu%40amd.com%7Cba45efb26c0240ed036f08d7b6db20aa%7C3dd8
> > > > 961fe4884e608e11a82d994e183d%7C0%7C0%7C637178924605524378&sdat
> > > > a=%2FyHkvYU5T%2F4iFxRexsg%2BIdm7sDzyXbjzNpHUGCO7h4k%3D&reserve
> > > > d=0
> > _______________________________________________
> > amd-gfx mailing list
> > amd-gfx@lists.freedesktop.org
> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist
> > s.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=02%7C01%7Cmo
> > nk.liu%40amd.com%7Cba45efb26c0240ed036f08d7b6db20aa%7C3dd8961fe4884e60
> > 8e11a82d994e183d%7C0%7C0%7C637178924605524378&sdata=%2FyHkvYU5T%2F
> > 4iFxRexsg%2BIdm7sDzyXbjzNpHUGCO7h4k%3D&reserved=0
> _______________________________________________
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=02%7C01%7Cmonk.liu%40amd.com%7Cba45efb26c0240ed036f08d7b6db20aa%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637178924605524378&sdata=%2FyHkvYU5T%2F4iFxRexsg%2BIdm7sDzyXbjzNpHUGCO7h4k%3D&reserved=0
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: 回复: [PATCH] drm/amd/amdgpu: disable GFXOFF around debugfs access to MMIO
2020-02-21 15:23 ` Huang Rui
@ 2020-02-21 15:27 ` Christian König
2020-02-21 15:39 ` Deucher, Alexander
2020-02-21 15:49 ` Huang Rui
2020-02-22 2:19 ` 回复: " Liu, Monk
1 sibling, 2 replies; 18+ messages in thread
From: Christian König @ 2020-02-21 15:27 UTC (permalink / raw)
To: Huang Rui, Liu, Monk; +Cc: StDenis, Tom, Alex Deucher, amd-gfx list
Am 21.02.20 um 16:23 schrieb Huang Rui:
> On Fri, Feb 21, 2020 at 11:18:07PM +0800, Liu, Monk wrote:
>> Better not use KIQ, because when you use debugfs to read register you usually hit a hang, and by that case KIQ probably already die
> If CP is busy, the gfx should be in "on" state at that time, we needn't use KIQ.
Yeah, but how do you detect that? Do we have a way to wake up the CP
without asking power management to do so?
Cause the register debug interface is meant to be used when the ASIC is
completed locked up. Sending messages to the SMU is not really going to
work in that situation.
Regards,
Christian.
>
> Thanks,
> Ray
>
>> -----邮件原件-----
>> 发件人: amd-gfx <amd-gfx-bounces@lists.freedesktop.org> 代表 Huang Rui
>> 发送时间: 2020年2月21日 22:34
>> 收件人: StDenis, Tom <Tom.StDenis@amd.com>
>> 抄送: Alex Deucher <alexdeucher@gmail.com>; amd-gfx list <amd-gfx@lists.freedesktop.org>
>> 主题: Re: [PATCH] drm/amd/amdgpu: disable GFXOFF around debugfs access to MMIO
>>
>> On Wed, Feb 19, 2020 at 10:09:46AM -0500, Tom St Denis wrote:
>>> I got some messages after a while:
>>>
>>> [ 741.788564] Failed to send Message 8.
>>> [ 746.671509] Failed to send Message 8.
>>> [ 748.749673] Failed to send Message 2b.
>>> [ 759.245414] Failed to send Message 7.
>>> [ 763.216902] Failed to send Message 2a.
>>>
>>> Are there any additional locks that should be held? Because some
>>> commands like --top or --waves can do a lot of distinct read
>>> operations (causing a lot of enable/disable calls).
>>>
>>> I'm going to sit on this a bit since I don't think the patch is ready
>>> for pushing out.
>>>
>> How about use RREG32_KIQ and WREG32_KIQ?
>>
>> Thanks,
>> Ray
>>
>>> Tom
>>>
>>> On 2020-02-19 10:07 a.m., Alex Deucher wrote:
>>>> On Wed, Feb 19, 2020 at 10:04 AM Tom St Denis <tom.stdenis@amd.com> wrote:
>>>>> Signed-off-by: Tom St Denis <tom.stdenis@amd.com>
>>>> Please add a patch description. With that fixed:
>>>> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
>>>>
>>>>> ---
>>>>> drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 3 +++
>>>>> 1 file changed, 3 insertions(+)
>>>>>
>>>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
>>>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
>>>>> index 7379910790c9..66f763300c96 100644
>>>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
>>>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
>>>>> @@ -169,6 +169,7 @@ static int amdgpu_debugfs_process_reg_op(bool read, struct file *f,
>>>>> if (pm_pg_lock)
>>>>> mutex_lock(&adev->pm.mutex);
>>>>>
>>>>> + amdgpu_gfx_off_ctrl(adev, false);
>>>>> while (size) {
>>>>> uint32_t value;
>>>>>
>>>>> @@ -192,6 +193,8 @@ static int amdgpu_debugfs_process_reg_op(bool read, struct file *f,
>>>>> }
>>>>>
>>>>> end:
>>>>> + amdgpu_gfx_off_ctrl(adev, true);
>>>>> +
>>>>> if (use_bank) {
>>>>> amdgpu_gfx_select_se_sh(adev, 0xffffffff, 0xffffffff, 0xffffffff);
>>>>> mutex_unlock(&adev->grbm_idx_mutex);
>>>>> --
>>>>> 2.24.1
>>>>>
>>>>> _______________________________________________
>>>>> amd-gfx mailing list
>>>>> amd-gfx@lists.freedesktop.org
>>>>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2F
>>>>> lists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=02%7
>>>>> C01%7Cmonk.liu%40amd.com%7Cba45efb26c0240ed036f08d7b6db20aa%7C3dd8
>>>>> 961fe4884e608e11a82d994e183d%7C0%7C0%7C637178924605524378&sdat
>>>>> a=%2FyHkvYU5T%2F4iFxRexsg%2BIdm7sDzyXbjzNpHUGCO7h4k%3D&reserve
>>>>> d=0
>>> _______________________________________________
>>> amd-gfx mailing list
>>> amd-gfx@lists.freedesktop.org
>>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist
>>> s.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=02%7C01%7Cmo
>>> nk.liu%40amd.com%7Cba45efb26c0240ed036f08d7b6db20aa%7C3dd8961fe4884e60
>>> 8e11a82d994e183d%7C0%7C0%7C637178924605524378&sdata=%2FyHkvYU5T%2F
>>> 4iFxRexsg%2BIdm7sDzyXbjzNpHUGCO7h4k%3D&reserved=0
>> _______________________________________________
>> amd-gfx mailing list
>> amd-gfx@lists.freedesktop.org
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=02%7C01%7Cmonk.liu%40amd.com%7Cba45efb26c0240ed036f08d7b6db20aa%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637178924605524378&sdata=%2FyHkvYU5T%2F4iFxRexsg%2BIdm7sDzyXbjzNpHUGCO7h4k%3D&reserved=0
> _______________________________________________
> 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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: 回复: [PATCH] drm/amd/amdgpu: disable GFXOFF around debugfs access to MMIO
2020-02-21 15:27 ` Christian König
@ 2020-02-21 15:39 ` Deucher, Alexander
2020-02-21 15:43 ` Christian König
2020-02-22 2:21 ` 回复: " Liu, Monk
2020-02-21 15:49 ` Huang Rui
1 sibling, 2 replies; 18+ messages in thread
From: Deucher, Alexander @ 2020-02-21 15:39 UTC (permalink / raw)
To: Christian König, Huang, Ray, Liu, Monk
Cc: StDenis, Tom, Alex Deucher, amd-gfx list
[-- Attachment #1.1: Type: text/plain, Size: 6297 bytes --]
[AMD Public Use]
If we are trying to debug a reproducible hang, probably best to just to disable gfxoff before messing with it to remove that as a factor. Otherwise, the method included in this patch is the proper way to disable/enable GFXOFF dynamically.
Alex
________________________________
From: amd-gfx <amd-gfx-bounces@lists.freedesktop.org> on behalf of Christian König <ckoenig.leichtzumerken@gmail.com>
Sent: Friday, February 21, 2020 10:27 AM
To: Huang, Ray <Ray.Huang@amd.com>; Liu, Monk <Monk.Liu@amd.com>
Cc: StDenis, Tom <Tom.StDenis@amd.com>; Alex Deucher <alexdeucher@gmail.com>; amd-gfx list <amd-gfx@lists.freedesktop.org>
Subject: Re: 回复: [PATCH] drm/amd/amdgpu: disable GFXOFF around debugfs access to MMIO
Am 21.02.20 um 16:23 schrieb Huang Rui:
> On Fri, Feb 21, 2020 at 11:18:07PM +0800, Liu, Monk wrote:
>> Better not use KIQ, because when you use debugfs to read register you usually hit a hang, and by that case KIQ probably already die
> If CP is busy, the gfx should be in "on" state at that time, we needn't use KIQ.
Yeah, but how do you detect that? Do we have a way to wake up the CP
without asking power management to do so?
Cause the register debug interface is meant to be used when the ASIC is
completed locked up. Sending messages to the SMU is not really going to
work in that situation.
Regards,
Christian.
>
> Thanks,
> Ray
>
>> -----邮件原件-----
>> 发件人: amd-gfx <amd-gfx-bounces@lists.freedesktop.org> 代表 Huang Rui
>> 发送时间: 2020年2月21日 22:34
>> 收件人: StDenis, Tom <Tom.StDenis@amd.com>
>> 抄送: Alex Deucher <alexdeucher@gmail.com>; amd-gfx list <amd-gfx@lists.freedesktop.org>
>> 主题: Re: [PATCH] drm/amd/amdgpu: disable GFXOFF around debugfs access to MMIO
>>
>> On Wed, Feb 19, 2020 at 10:09:46AM -0500, Tom St Denis wrote:
>>> I got some messages after a while:
>>>
>>> [ 741.788564] Failed to send Message 8.
>>> [ 746.671509] Failed to send Message 8.
>>> [ 748.749673] Failed to send Message 2b.
>>> [ 759.245414] Failed to send Message 7.
>>> [ 763.216902] Failed to send Message 2a.
>>>
>>> Are there any additional locks that should be held? Because some
>>> commands like --top or --waves can do a lot of distinct read
>>> operations (causing a lot of enable/disable calls).
>>>
>>> I'm going to sit on this a bit since I don't think the patch is ready
>>> for pushing out.
>>>
>> How about use RREG32_KIQ and WREG32_KIQ?
>>
>> Thanks,
>> Ray
>>
>>> Tom
>>>
>>> On 2020-02-19 10:07 a.m., Alex Deucher wrote:
>>>> On Wed, Feb 19, 2020 at 10:04 AM Tom St Denis <tom.stdenis@amd.com> wrote:
>>>>> Signed-off-by: Tom St Denis <tom.stdenis@amd.com>
>>>> Please add a patch description. With that fixed:
>>>> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
>>>>
>>>>> ---
>>>>> drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 3 +++
>>>>> 1 file changed, 3 insertions(+)
>>>>>
>>>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
>>>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
>>>>> index 7379910790c9..66f763300c96 100644
>>>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
>>>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
>>>>> @@ -169,6 +169,7 @@ static int amdgpu_debugfs_process_reg_op(bool read, struct file *f,
>>>>> if (pm_pg_lock)
>>>>> mutex_lock(&adev->pm.mutex);
>>>>>
>>>>> + amdgpu_gfx_off_ctrl(adev, false);
>>>>> while (size) {
>>>>> uint32_t value;
>>>>>
>>>>> @@ -192,6 +193,8 @@ static int amdgpu_debugfs_process_reg_op(bool read, struct file *f,
>>>>> }
>>>>>
>>>>> end:
>>>>> + amdgpu_gfx_off_ctrl(adev, true);
>>>>> +
>>>>> if (use_bank) {
>>>>> amdgpu_gfx_select_se_sh(adev, 0xffffffff, 0xffffffff, 0xffffffff);
>>>>> mutex_unlock(&adev->grbm_idx_mutex);
>>>>> --
>>>>> 2.24.1
>>>>>
>>>>> _______________________________________________
>>>>> amd-gfx mailing list
>>>>> amd-gfx@lists.freedesktop.org
>>>>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2F
>>>>> lists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=02%7
>>>>> C01%7Cmonk.liu%40amd.com%7Cba45efb26c0240ed036f08d7b6db20aa%7C3dd8
>>>>> 961fe4884e608e11a82d994e183d%7C0%7C0%7C637178924605524378&sdat
>>>>> a=%2FyHkvYU5T%2F4iFxRexsg%2BIdm7sDzyXbjzNpHUGCO7h4k%3D&reserve
>>>>> d=0
>>> _______________________________________________
>>> amd-gfx mailing list
>>> amd-gfx@lists.freedesktop.org
>>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist
>>> s.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=02%7C01%7Cmo
>>> nk.liu%40amd.com%7Cba45efb26c0240ed036f08d7b6db20aa%7C3dd8961fe4884e60
>>> 8e11a82d994e183d%7C0%7C0%7C637178924605524378&sdata=%2FyHkvYU5T%2F
>>> 4iFxRexsg%2BIdm7sDzyXbjzNpHUGCO7h4k%3D&reserved=0
>> _______________________________________________
>> amd-gfx mailing list
>> amd-gfx@lists.freedesktop.org
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=02%7C01%7Calexander.deucher%40amd.com%7Cf3762304925b4019bfed08d7b6e287e4%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637178957179179431&sdata=bY7V%2BKOF3gYu4ITGCKgAiRvXUvxPcwsz2zsEJDns3jI%3D&reserved=0
> _______________________________________________
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=02%7C01%7Calexander.deucher%40amd.com%7Cf3762304925b4019bfed08d7b6e287e4%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637178957179179431&sdata=bY7V%2BKOF3gYu4ITGCKgAiRvXUvxPcwsz2zsEJDns3jI%3D&reserved=0
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=02%7C01%7Calexander.deucher%40amd.com%7Cf3762304925b4019bfed08d7b6e287e4%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637178957179179431&sdata=bY7V%2BKOF3gYu4ITGCKgAiRvXUvxPcwsz2zsEJDns3jI%3D&reserved=0
[-- Attachment #1.2: Type: text/html, Size: 11127 bytes --]
[-- Attachment #2: Type: text/plain, Size: 154 bytes --]
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: 回复: [PATCH] drm/amd/amdgpu: disable GFXOFF around debugfs access to MMIO
2020-02-21 15:39 ` Deucher, Alexander
@ 2020-02-21 15:43 ` Christian König
2020-02-21 15:56 ` Deucher, Alexander
2020-02-22 2:21 ` 回复: " Liu, Monk
1 sibling, 1 reply; 18+ messages in thread
From: Christian König @ 2020-02-21 15:43 UTC (permalink / raw)
To: Deucher, Alexander, Huang, Ray, Liu, Monk
Cc: StDenis, Tom, Alex Deucher, amd-gfx list
[-- Attachment #1.1: Type: text/plain, Size: 6729 bytes --]
Do we have a way to disable GFXOFF on the fly?
If not maybe it would be a good idea to add a separate debugfs file to
do this.
Christian.
Am 21.02.20 um 16:39 schrieb Deucher, Alexander:
>
> [AMD Public Use]
>
>
> If we are trying to debug a reproducible hang, probably best to just
> to disable gfxoff before messing with it to remove that as a factor.
> Otherwise, the method included in this patch is the proper way to
> disable/enable GFXOFF dynamically.
>
> Alex
>
> ------------------------------------------------------------------------
> *From:* amd-gfx <amd-gfx-bounces@lists.freedesktop.org> on behalf of
> Christian König <ckoenig.leichtzumerken@gmail.com>
> *Sent:* Friday, February 21, 2020 10:27 AM
> *To:* Huang, Ray <Ray.Huang@amd.com>; Liu, Monk <Monk.Liu@amd.com>
> *Cc:* StDenis, Tom <Tom.StDenis@amd.com>; Alex Deucher
> <alexdeucher@gmail.com>; amd-gfx list <amd-gfx@lists.freedesktop.org>
> *Subject:* Re: 回复: [PATCH] drm/amd/amdgpu: disable GFXOFF around
> debugfs access to MMIO
> Am 21.02.20 um 16:23 schrieb Huang Rui:
> > On Fri, Feb 21, 2020 at 11:18:07PM +0800, Liu, Monk wrote:
> >> Better not use KIQ, because when you use debugfs to read register
> you usually hit a hang, and by that case KIQ probably already die
> > If CP is busy, the gfx should be in "on" state at that time, we
> needn't use KIQ.
>
> Yeah, but how do you detect that? Do we have a way to wake up the CP
> without asking power management to do so?
>
> Cause the register debug interface is meant to be used when the ASIC is
> completed locked up. Sending messages to the SMU is not really going to
> work in that situation.
>
> Regards,
> Christian.
>
> >
> > Thanks,
> > Ray
> >
> >> -----邮件原件-----
> >> 发件人: amd-gfx <amd-gfx-bounces@lists.freedesktop.org> 代表 Huang Rui
> >> 发送时间: 2020年2月21日 22:34
> >> 收件人: StDenis, Tom <Tom.StDenis@amd.com>
> >> 抄送: Alex Deucher <alexdeucher@gmail.com>; amd-gfx list
> <amd-gfx@lists.freedesktop.org>
> >> 主题: Re: [PATCH] drm/amd/amdgpu: disable GFXOFF around debugfs
> access to MMIO
> >>
> >> On Wed, Feb 19, 2020 at 10:09:46AM -0500, Tom St Denis wrote:
> >>> I got some messages after a while:
> >>>
> >>> [ 741.788564] Failed to send Message 8.
> >>> [ 746.671509] Failed to send Message 8.
> >>> [ 748.749673] Failed to send Message 2b.
> >>> [ 759.245414] Failed to send Message 7.
> >>> [ 763.216902] Failed to send Message 2a.
> >>>
> >>> Are there any additional locks that should be held? Because some
> >>> commands like --top or --waves can do a lot of distinct read
> >>> operations (causing a lot of enable/disable calls).
> >>>
> >>> I'm going to sit on this a bit since I don't think the patch is ready
> >>> for pushing out.
> >>>
> >> How about use RREG32_KIQ and WREG32_KIQ?
> >>
> >> Thanks,
> >> Ray
> >>
> >>> Tom
> >>>
> >>> On 2020-02-19 10:07 a.m., Alex Deucher wrote:
> >>>> On Wed, Feb 19, 2020 at 10:04 AM Tom St Denis
> <tom.stdenis@amd.com> wrote:
> >>>>> Signed-off-by: Tom St Denis <tom.stdenis@amd.com>
> >>>> Please add a patch description. With that fixed:
> >>>> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
> >>>>
> >>>>> ---
> >>>>> drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 3 +++
> >>>>> 1 file changed, 3 insertions(+)
> >>>>>
> >>>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
> >>>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
> >>>>> index 7379910790c9..66f763300c96 100644
> >>>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
> >>>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
> >>>>> @@ -169,6 +169,7 @@ static int
> amdgpu_debugfs_process_reg_op(bool read, struct file *f,
> >>>>> if (pm_pg_lock)
> >>>>> mutex_lock(&adev->pm.mutex);
> >>>>>
> >>>>> + amdgpu_gfx_off_ctrl(adev, false);
> >>>>> while (size) {
> >>>>> uint32_t value;
> >>>>>
> >>>>> @@ -192,6 +193,8 @@ static int
> amdgpu_debugfs_process_reg_op(bool read, struct file *f,
> >>>>> }
> >>>>>
> >>>>> end:
> >>>>> + amdgpu_gfx_off_ctrl(adev, true);
> >>>>> +
> >>>>> if (use_bank) {
> >>>>> amdgpu_gfx_select_se_sh(adev, 0xffffffff, 0xffffffff, 0xffffffff);
> >>>>> mutex_unlock(&adev->grbm_idx_mutex);
> >>>>> --
> >>>>> 2.24.1
> >>>>>
> >>>>> _______________________________________________
> >>>>> amd-gfx mailing list
> >>>>> amd-gfx@lists.freedesktop.org
> >>>>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> >>>>> lists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=02%7
> >>>>> C01%7Cmonk.liu%40amd.com%7Cba45efb26c0240ed036f08d7b6db20aa%7C3dd8
> >>>>> 961fe4884e608e11a82d994e183d%7C0%7C0%7C637178924605524378&sdat
> >>>>> a=%2FyHkvYU5T%2F4iFxRexsg%2BIdm7sDzyXbjzNpHUGCO7h4k%3D&reserve
> >>>>> d=0
> >>> _______________________________________________
> >>> amd-gfx mailing list
> >>> amd-gfx@lists.freedesktop.org
> >>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist
> >>> s.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=02%7C01%7Cmo
> >>> nk.liu%40amd.com%7Cba45efb26c0240ed036f08d7b6db20aa%7C3dd8961fe4884e60
> >>> 8e11a82d994e183d%7C0%7C0%7C637178924605524378&sdata=%2FyHkvYU5T%2F
> >>> 4iFxRexsg%2BIdm7sDzyXbjzNpHUGCO7h4k%3D&reserved=0
> >> _______________________________________________
> >> amd-gfx mailing list
> >> amd-gfx@lists.freedesktop.org
> >>
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=02%7C01%7Calexander.deucher%40amd.com%7Cf3762304925b4019bfed08d7b6e287e4%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637178957179179431&sdata=bY7V%2BKOF3gYu4ITGCKgAiRvXUvxPcwsz2zsEJDns3jI%3D&reserved=0
> > _______________________________________________
> > amd-gfx mailing list
> > amd-gfx@lists.freedesktop.org
> >
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=02%7C01%7Calexander.deucher%40amd.com%7Cf3762304925b4019bfed08d7b6e287e4%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637178957179179431&sdata=bY7V%2BKOF3gYu4ITGCKgAiRvXUvxPcwsz2zsEJDns3jI%3D&reserved=0
>
> _______________________________________________
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=02%7C01%7Calexander.deucher%40amd.com%7Cf3762304925b4019bfed08d7b6e287e4%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637178957179179431&sdata=bY7V%2BKOF3gYu4ITGCKgAiRvXUvxPcwsz2zsEJDns3jI%3D&reserved=0
[-- Attachment #1.2: Type: text/html, Size: 15533 bytes --]
[-- Attachment #2: Type: text/plain, Size: 154 bytes --]
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: 回复: [PATCH] drm/amd/amdgpu: disable GFXOFF around debugfs access to MMIO
2020-02-21 15:27 ` Christian König
2020-02-21 15:39 ` Deucher, Alexander
@ 2020-02-21 15:49 ` Huang Rui
1 sibling, 0 replies; 18+ messages in thread
From: Huang Rui @ 2020-02-21 15:49 UTC (permalink / raw)
To: Koenig, Christian; +Cc: StDenis, Tom, Alex Deucher, amd-gfx list, Liu, Monk
On Fri, Feb 21, 2020 at 11:27:10PM +0800, Christian König wrote:
> Am 21.02.20 um 16:23 schrieb Huang Rui:
> > On Fri, Feb 21, 2020 at 11:18:07PM +0800, Liu, Monk wrote:
> >> Better not use KIQ, because when you use debugfs to read register you usually hit a hang, and by that case KIQ probably already die
> > If CP is busy, the gfx should be in "on" state at that time, we needn't use KIQ.
>
> Yeah, but how do you detect that?
I remember there is a bit in SMU or PWR register which is not exposed yet.
And need double confirm with SMU or RLC guys.
> Do we have a way to wake up the CP without asking power management to do
> so?
Use doorbell interrupt. RLC will detect the doorbell interrupt to tell SMU
to wake up gfx at runtime. So I suggest KIQ here.
>
> Cause the register debug interface is meant to be used when the ASIC is
> completed locked up. Sending messages to the SMU is not really going to
> work in that situation.
>
Agree, actually, we tried this kind of messages a long time before, and
will get failure sometimes that the same like Tom here.
Thanks,
Ray
> Regards,
> Christian.
>
> >
> > Thanks,
> > Ray
> >
> >> -----邮件原件-----
> >> 发件人: amd-gfx <amd-gfx-bounces@lists.freedesktop.org> 代表 Huang Rui
> >> 发送时间: 2020年2月21日 22:34
> >> 收件人: StDenis, Tom <Tom.StDenis@amd.com>
> >> 抄送: Alex Deucher <alexdeucher@gmail.com>; amd-gfx list <amd-gfx@lists.freedesktop.org>
> >> 主题: Re: [PATCH] drm/amd/amdgpu: disable GFXOFF around debugfs access to MMIO
> >>
> >> On Wed, Feb 19, 2020 at 10:09:46AM -0500, Tom St Denis wrote:
> >>> I got some messages after a while:
> >>>
> >>> [ 741.788564] Failed to send Message 8.
> >>> [ 746.671509] Failed to send Message 8.
> >>> [ 748.749673] Failed to send Message 2b.
> >>> [ 759.245414] Failed to send Message 7.
> >>> [ 763.216902] Failed to send Message 2a.
> >>>
> >>> Are there any additional locks that should be held? Because some
> >>> commands like --top or --waves can do a lot of distinct read
> >>> operations (causing a lot of enable/disable calls).
> >>>
> >>> I'm going to sit on this a bit since I don't think the patch is ready
> >>> for pushing out.
> >>>
> >> How about use RREG32_KIQ and WREG32_KIQ?
> >>
> >> Thanks,
> >> Ray
> >>
> >>> Tom
> >>>
> >>> On 2020-02-19 10:07 a.m., Alex Deucher wrote:
> >>>> On Wed, Feb 19, 2020 at 10:04 AM Tom St Denis <tom.stdenis@amd.com> wrote:
> >>>>> Signed-off-by: Tom St Denis <tom.stdenis@amd.com>
> >>>> Please add a patch description. With that fixed:
> >>>> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
> >>>>
> >>>>> ---
> >>>>> drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 3 +++
> >>>>> 1 file changed, 3 insertions(+)
> >>>>>
> >>>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
> >>>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
> >>>>> index 7379910790c9..66f763300c96 100644
> >>>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
> >>>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
> >>>>> @@ -169,6 +169,7 @@ static int amdgpu_debugfs_process_reg_op(bool read, struct file *f,
> >>>>> if (pm_pg_lock)
> >>>>> mutex_lock(&adev->pm.mutex);
> >>>>>
> >>>>> + amdgpu_gfx_off_ctrl(adev, false);
> >>>>> while (size) {
> >>>>> uint32_t value;
> >>>>>
> >>>>> @@ -192,6 +193,8 @@ static int amdgpu_debugfs_process_reg_op(bool read, struct file *f,
> >>>>> }
> >>>>>
> >>>>> end:
> >>>>> + amdgpu_gfx_off_ctrl(adev, true);
> >>>>> +
> >>>>> if (use_bank) {
> >>>>> amdgpu_gfx_select_se_sh(adev, 0xffffffff, 0xffffffff, 0xffffffff);
> >>>>> mutex_unlock(&adev->grbm_idx_mutex);
> >>>>> --
> >>>>> 2.24.1
> >>>>>
> >>>>> _______________________________________________
> >>>>> amd-gfx mailing list
> >>>>> amd-gfx@lists.freedesktop.org
> >>>>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> >>>>> lists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=02%7
> >>>>> C01%7Cmonk.liu%40amd.com%7Cba45efb26c0240ed036f08d7b6db20aa%7C3dd8
> >>>>> 961fe4884e608e11a82d994e183d%7C0%7C0%7C637178924605524378&sdat
> >>>>> a=%2FyHkvYU5T%2F4iFxRexsg%2BIdm7sDzyXbjzNpHUGCO7h4k%3D&reserve
> >>>>> d=0
> >>> _______________________________________________
> >>> amd-gfx mailing list
> >>> amd-gfx@lists.freedesktop.org
> >>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist
> >>> s.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=02%7C01%7Cmo
> >>> nk.liu%40amd.com%7Cba45efb26c0240ed036f08d7b6db20aa%7C3dd8961fe4884e60
> >>> 8e11a82d994e183d%7C0%7C0%7C637178924605524378&sdata=%2FyHkvYU5T%2F
> >>> 4iFxRexsg%2BIdm7sDzyXbjzNpHUGCO7h4k%3D&reserved=0
> >> _______________________________________________
> >> amd-gfx mailing list
> >> amd-gfx@lists.freedesktop.org
> >> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=02%7C01%7Cray.huang%40amd.com%7Cefe423577bde46fc9e2508d7b6e28702%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637178956359228789&sdata=rShU5sl749BuNxVR8uFLtIf8kR%2BUWBrt%2FO9H%2F0SRVTo%3D&reserved=0
> > _______________________________________________
> > amd-gfx mailing list
> > amd-gfx@lists.freedesktop.org
> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=02%7C01%7Cray.huang%40amd.com%7Cefe423577bde46fc9e2508d7b6e28702%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637178956359238785&sdata=XkJ5uT1g41lku%2FYxMsMTGaHzajGsCAVvcMUYHvTx%2FV0%3D&reserved=0
>
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: 回复: [PATCH] drm/amd/amdgpu: disable GFXOFF around debugfs access to MMIO
2020-02-21 15:43 ` Christian König
@ 2020-02-21 15:56 ` Deucher, Alexander
2020-02-21 16:04 ` Christian König
0 siblings, 1 reply; 18+ messages in thread
From: Deucher, Alexander @ 2020-02-21 15:56 UTC (permalink / raw)
To: Christian König, Huang, Ray, Liu, Monk
Cc: StDenis, Tom, Alex Deucher, amd-gfx list
[-- Attachment #1.1: Type: text/plain, Size: 8873 bytes --]
[AMD Public Use]
Not at the moment. But we could add a debugfs file which just wraps amdgpu_gfx_off_ctrl(). That said, maybe we just add a delay here or a use a timer to delay turning gfxoff back on again so that we aren't turning it on and off so rapidly.
Alex
________________________________
From: Christian König <ckoenig.leichtzumerken@gmail.com>
Sent: Friday, February 21, 2020 10:43 AM
To: Deucher, Alexander <Alexander.Deucher@amd.com>; Huang, Ray <Ray.Huang@amd.com>; Liu, Monk <Monk.Liu@amd.com>
Cc: StDenis, Tom <Tom.StDenis@amd.com>; Alex Deucher <alexdeucher@gmail.com>; amd-gfx list <amd-gfx@lists.freedesktop.org>
Subject: Re: 回复: [PATCH] drm/amd/amdgpu: disable GFXOFF around debugfs access to MMIO
Do we have a way to disable GFXOFF on the fly?
If not maybe it would be a good idea to add a separate debugfs file to do this.
Christian.
Am 21.02.20 um 16:39 schrieb Deucher, Alexander:
[AMD Public Use]
If we are trying to debug a reproducible hang, probably best to just to disable gfxoff before messing with it to remove that as a factor. Otherwise, the method included in this patch is the proper way to disable/enable GFXOFF dynamically.
Alex
________________________________
From: amd-gfx <amd-gfx-bounces@lists.freedesktop.org><mailto:amd-gfx-bounces@lists.freedesktop.org> on behalf of Christian König <ckoenig.leichtzumerken@gmail.com><mailto:ckoenig.leichtzumerken@gmail.com>
Sent: Friday, February 21, 2020 10:27 AM
To: Huang, Ray <Ray.Huang@amd.com><mailto:Ray.Huang@amd.com>; Liu, Monk <Monk.Liu@amd.com><mailto:Monk.Liu@amd.com>
Cc: StDenis, Tom <Tom.StDenis@amd.com><mailto:Tom.StDenis@amd.com>; Alex Deucher <alexdeucher@gmail.com><mailto:alexdeucher@gmail.com>; amd-gfx list <amd-gfx@lists.freedesktop.org><mailto:amd-gfx@lists.freedesktop.org>
Subject: Re: 回复: [PATCH] drm/amd/amdgpu: disable GFXOFF around debugfs access to MMIO
Am 21.02.20 um 16:23 schrieb Huang Rui:
> On Fri, Feb 21, 2020 at 11:18:07PM +0800, Liu, Monk wrote:
>> Better not use KIQ, because when you use debugfs to read register you usually hit a hang, and by that case KIQ probably already die
> If CP is busy, the gfx should be in "on" state at that time, we needn't use KIQ.
Yeah, but how do you detect that? Do we have a way to wake up the CP
without asking power management to do so?
Cause the register debug interface is meant to be used when the ASIC is
completed locked up. Sending messages to the SMU is not really going to
work in that situation.
Regards,
Christian.
>
> Thanks,
> Ray
>
>> -----邮件原件-----
>> 发件人: amd-gfx <amd-gfx-bounces@lists.freedesktop.org><mailto:amd-gfx-bounces@lists.freedesktop.org> 代表 Huang Rui
>> 发送时间: 2020年2月21日 22:34
>> 收件人: StDenis, Tom <Tom.StDenis@amd.com><mailto:Tom.StDenis@amd.com>
>> 抄送: Alex Deucher <alexdeucher@gmail.com><mailto:alexdeucher@gmail.com>; amd-gfx list <amd-gfx@lists.freedesktop.org><mailto:amd-gfx@lists.freedesktop.org>
>> 主题: Re: [PATCH] drm/amd/amdgpu: disable GFXOFF around debugfs access to MMIO
>>
>> On Wed, Feb 19, 2020 at 10:09:46AM -0500, Tom St Denis wrote:
>>> I got some messages after a while:
>>>
>>> [ 741.788564] Failed to send Message 8.
>>> [ 746.671509] Failed to send Message 8.
>>> [ 748.749673] Failed to send Message 2b.
>>> [ 759.245414] Failed to send Message 7.
>>> [ 763.216902] Failed to send Message 2a.
>>>
>>> Are there any additional locks that should be held? Because some
>>> commands like --top or --waves can do a lot of distinct read
>>> operations (causing a lot of enable/disable calls).
>>>
>>> I'm going to sit on this a bit since I don't think the patch is ready
>>> for pushing out.
>>>
>> How about use RREG32_KIQ and WREG32_KIQ?
>>
>> Thanks,
>> Ray
>>
>>> Tom
>>>
>>> On 2020-02-19 10:07 a.m., Alex Deucher wrote:
>>>> On Wed, Feb 19, 2020 at 10:04 AM Tom St Denis <tom.stdenis@amd.com><mailto:tom.stdenis@amd.com> wrote:
>>>>> Signed-off-by: Tom St Denis <tom.stdenis@amd.com><mailto:tom.stdenis@amd.com>
>>>> Please add a patch description. With that fixed:
>>>> Reviewed-by: Alex Deucher <alexander.deucher@amd.com><mailto:alexander.deucher@amd.com>
>>>>
>>>>> ---
>>>>> drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 3 +++
>>>>> 1 file changed, 3 insertions(+)
>>>>>
>>>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
>>>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
>>>>> index 7379910790c9..66f763300c96 100644
>>>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
>>>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
>>>>> @@ -169,6 +169,7 @@ static int amdgpu_debugfs_process_reg_op(bool read, struct file *f,
>>>>> if (pm_pg_lock)
>>>>> mutex_lock(&adev->pm.mutex);
>>>>>
>>>>> + amdgpu_gfx_off_ctrl(adev, false);
>>>>> while (size) {
>>>>> uint32_t value;
>>>>>
>>>>> @@ -192,6 +193,8 @@ static int amdgpu_debugfs_process_reg_op(bool read, struct file *f,
>>>>> }
>>>>>
>>>>> end:
>>>>> + amdgpu_gfx_off_ctrl(adev, true);
>>>>> +
>>>>> if (use_bank) {
>>>>> amdgpu_gfx_select_se_sh(adev, 0xffffffff, 0xffffffff, 0xffffffff);
>>>>> mutex_unlock(&adev->grbm_idx_mutex);
>>>>> --
>>>>> 2.24.1
>>>>>
>>>>> _______________________________________________
>>>>> amd-gfx mailing list
>>>>> amd-gfx@lists.freedesktop.org<mailto:amd-gfx@lists.freedesktop.org>
>>>>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2F
>>>>> lists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=02%7
>>>>> C01%7Cmonk.liu%40amd.com%7Cba45efb26c0240ed036f08d7b6db20aa%7C3dd8
>>>>> 961fe4884e608e11a82d994e183d%7C0%7C0%7C637178924605524378&sdat
>>>>> a=%2FyHkvYU5T%2F4iFxRexsg%2BIdm7sDzyXbjzNpHUGCO7h4k%3D&reserve
>>>>> d=0
>>> _______________________________________________
>>> amd-gfx mailing list
>>> amd-gfx@lists.freedesktop.org<mailto:amd-gfx@lists.freedesktop.org>
>>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist
>>> s.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=02%7C01%7Cmo
>>> nk.liu%40amd.com%7Cba45efb26c0240ed036f08d7b6db20aa%7C3dd8961fe4884e60
>>> 8e11a82d994e183d%7C0%7C0%7C637178924605524378&sdata=%2FyHkvYU5T%2F
>>> 4iFxRexsg%2BIdm7sDzyXbjzNpHUGCO7h4k%3D&reserved=0
>> _______________________________________________
>> amd-gfx mailing list
>> amd-gfx@lists.freedesktop.org<mailto:amd-gfx@lists.freedesktop.org>
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=02%7C01%7Calexander.deucher%40amd.com%7Cf3762304925b4019bfed08d7b6e287e4%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637178957179179431&sdata=bY7V%2BKOF3gYu4ITGCKgAiRvXUvxPcwsz2zsEJDns3jI%3D&reserved=0<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=02%7C01%7CAlexander.Deucher%40amd.com%7C50c08a2474b346c44c0608d7b6e4d3ff%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637178966243976347&sdata=yQgD1Ywji%2BimCVr06LD0oSnf4ZHGmoN3s8a5NybPx4E%3D&reserved=0>
> _______________________________________________
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org<mailto:amd-gfx@lists.freedesktop.org>
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=02%7C01%7Calexander.deucher%40amd.com%7Cf3762304925b4019bfed08d7b6e287e4%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637178957179179431&sdata=bY7V%2BKOF3gYu4ITGCKgAiRvXUvxPcwsz2zsEJDns3jI%3D&reserved=0<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=02%7C01%7CAlexander.Deucher%40amd.com%7C50c08a2474b346c44c0608d7b6e4d3ff%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637178966243986301&sdata=5vafv2zCFbpgaSpgcQzLaEAC3wnqkIvGbrvKH3M11s4%3D&reserved=0>
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org<mailto:amd-gfx@lists.freedesktop.org>
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=02%7C01%7Calexander.deucher%40amd.com%7Cf3762304925b4019bfed08d7b6e287e4%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637178957179179431&sdata=bY7V%2BKOF3gYu4ITGCKgAiRvXUvxPcwsz2zsEJDns3jI%3D&reserved=0<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=02%7C01%7CAlexander.Deucher%40amd.com%7C50c08a2474b346c44c0608d7b6e4d3ff%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637178966243986301&sdata=5vafv2zCFbpgaSpgcQzLaEAC3wnqkIvGbrvKH3M11s4%3D&reserved=0>
[-- Attachment #1.2: Type: text/html, Size: 15495 bytes --]
[-- Attachment #2: Type: text/plain, Size: 154 bytes --]
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: 回复: [PATCH] drm/amd/amdgpu: disable GFXOFF around debugfs access to MMIO
2020-02-21 15:56 ` Deucher, Alexander
@ 2020-02-21 16:04 ` Christian König
2020-02-21 16:06 ` Tom St Denis
0 siblings, 1 reply; 18+ messages in thread
From: Christian König @ 2020-02-21 16:04 UTC (permalink / raw)
To: Deucher, Alexander, Huang, Ray, Liu, Monk
Cc: StDenis, Tom, Alex Deucher, amd-gfx list
[-- Attachment #1.1: Type: text/plain, Size: 9836 bytes --]
Ok how about this:
We add a debugfs file which when read returns the GFXOFF status and when
written with a number disabled GFXOFF for N seconds with 0 meaning forever.
Umr gets a new commandline option to write to that file before reading
registers.
This way the user can still disable it if it causes any problems. Does
that sounds like a plan?
Regards,
Christian.
Am 21.02.20 um 16:56 schrieb Deucher, Alexander:
>
> [AMD Public Use]
>
>
> Not at the moment. But we could add a debugfs file which just wraps
> amdgpu_gfx_off_ctrl(). That said, maybe we just add a delay here or a
> use a timer to delay turning gfxoff back on again so that we aren't
> turning it on and off so rapidly.
>
> Alex
>
> ------------------------------------------------------------------------
> *From:* Christian König <ckoenig.leichtzumerken@gmail.com>
> *Sent:* Friday, February 21, 2020 10:43 AM
> *To:* Deucher, Alexander <Alexander.Deucher@amd.com>; Huang, Ray
> <Ray.Huang@amd.com>; Liu, Monk <Monk.Liu@amd.com>
> *Cc:* StDenis, Tom <Tom.StDenis@amd.com>; Alex Deucher
> <alexdeucher@gmail.com>; amd-gfx list <amd-gfx@lists.freedesktop.org>
> *Subject:* Re: 回复: [PATCH] drm/amd/amdgpu: disable GFXOFF around
> debugfs access to MMIO
> Do we have a way to disable GFXOFF on the fly?
>
> If not maybe it would be a good idea to add a separate debugfs file to
> do this.
>
> Christian.
>
> Am 21.02.20 um 16:39 schrieb Deucher, Alexander:
>>
>> [AMD Public Use]
>>
>>
>> If we are trying to debug a reproducible hang, probably best to just
>> to disable gfxoff before messing with it to remove that as a factor.
>> Otherwise, the method included in this patch is the proper way to
>> disable/enable GFXOFF dynamically.
>>
>> Alex
>>
>> ------------------------------------------------------------------------
>> *From:* amd-gfx <amd-gfx-bounces@lists.freedesktop.org>
>> <mailto:amd-gfx-bounces@lists.freedesktop.org> on behalf of Christian
>> König <ckoenig.leichtzumerken@gmail.com>
>> <mailto:ckoenig.leichtzumerken@gmail.com>
>> *Sent:* Friday, February 21, 2020 10:27 AM
>> *To:* Huang, Ray <Ray.Huang@amd.com> <mailto:Ray.Huang@amd.com>; Liu,
>> Monk <Monk.Liu@amd.com> <mailto:Monk.Liu@amd.com>
>> *Cc:* StDenis, Tom <Tom.StDenis@amd.com>
>> <mailto:Tom.StDenis@amd.com>; Alex Deucher <alexdeucher@gmail.com>
>> <mailto:alexdeucher@gmail.com>; amd-gfx list
>> <amd-gfx@lists.freedesktop.org> <mailto:amd-gfx@lists.freedesktop.org>
>> *Subject:* Re: 回复: [PATCH] drm/amd/amdgpu: disable GFXOFF around
>> debugfs access to MMIO
>> Am 21.02.20 um 16:23 schrieb Huang Rui:
>> > On Fri, Feb 21, 2020 at 11:18:07PM +0800, Liu, Monk wrote:
>> >> Better not use KIQ, because when you use debugfs to read register
>> you usually hit a hang, and by that case KIQ probably already die
>> > If CP is busy, the gfx should be in "on" state at that time, we
>> needn't use KIQ.
>>
>> Yeah, but how do you detect that? Do we have a way to wake up the CP
>> without asking power management to do so?
>>
>> Cause the register debug interface is meant to be used when the ASIC is
>> completed locked up. Sending messages to the SMU is not really going to
>> work in that situation.
>>
>> Regards,
>> Christian.
>>
>> >
>> > Thanks,
>> > Ray
>> >
>> >> -----邮件原件-----
>> >> 发件人: amd-gfx <amd-gfx-bounces@lists.freedesktop.org>
>> <mailto:amd-gfx-bounces@lists.freedesktop.org> 代表 Huang Rui
>> >> 发送时间: 2020年2月21日 22:34
>> >> 收件人: StDenis, Tom <Tom.StDenis@amd.com>
>> <mailto:Tom.StDenis@amd.com>
>> >> 抄送: Alex Deucher <alexdeucher@gmail.com>
>> <mailto:alexdeucher@gmail.com>; amd-gfx list
>> <amd-gfx@lists.freedesktop.org> <mailto:amd-gfx@lists.freedesktop.org>
>> >> 主题: Re: [PATCH] drm/amd/amdgpu: disable GFXOFF around debugfs
>> access to MMIO
>> >>
>> >> On Wed, Feb 19, 2020 at 10:09:46AM -0500, Tom St Denis wrote:
>> >>> I got some messages after a while:
>> >>>
>> >>> [ 741.788564] Failed to send Message 8.
>> >>> [ 746.671509] Failed to send Message 8.
>> >>> [ 748.749673] Failed to send Message 2b.
>> >>> [ 759.245414] Failed to send Message 7.
>> >>> [ 763.216902] Failed to send Message 2a.
>> >>>
>> >>> Are there any additional locks that should be held? Because some
>> >>> commands like --top or --waves can do a lot of distinct read
>> >>> operations (causing a lot of enable/disable calls).
>> >>>
>> >>> I'm going to sit on this a bit since I don't think the patch is ready
>> >>> for pushing out.
>> >>>
>> >> How about use RREG32_KIQ and WREG32_KIQ?
>> >>
>> >> Thanks,
>> >> Ray
>> >>
>> >>> Tom
>> >>>
>> >>> On 2020-02-19 10:07 a.m., Alex Deucher wrote:
>> >>>> On Wed, Feb 19, 2020 at 10:04 AM Tom St Denis
>> <tom.stdenis@amd.com> <mailto:tom.stdenis@amd.com> wrote:
>> >>>>> Signed-off-by: Tom St Denis <tom.stdenis@amd.com>
>> <mailto:tom.stdenis@amd.com>
>> >>>> Please add a patch description. With that fixed:
>> >>>> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
>> <mailto:alexander.deucher@amd.com>
>> >>>>
>> >>>>> ---
>> >>>>> drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 3 +++
>> >>>>> 1 file changed, 3 insertions(+)
>> >>>>>
>> >>>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
>> >>>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
>> >>>>> index 7379910790c9..66f763300c96 100644
>> >>>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
>> >>>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
>> >>>>> @@ -169,6 +169,7 @@ static int
>> amdgpu_debugfs_process_reg_op(bool read, struct file *f,
>> >>>>> if (pm_pg_lock)
>> >>>>> mutex_lock(&adev->pm.mutex);
>> >>>>>
>> >>>>> + amdgpu_gfx_off_ctrl(adev, false);
>> >>>>> while (size) {
>> >>>>> uint32_t value;
>> >>>>>
>> >>>>> @@ -192,6 +193,8 @@ static int
>> amdgpu_debugfs_process_reg_op(bool read, struct file *f,
>> >>>>> }
>> >>>>>
>> >>>>> end:
>> >>>>> + amdgpu_gfx_off_ctrl(adev, true);
>> >>>>> +
>> >>>>> if (use_bank) {
>> >>>>> amdgpu_gfx_select_se_sh(adev, 0xffffffff, 0xffffffff, 0xffffffff);
>> >>>>> mutex_unlock(&adev->grbm_idx_mutex);
>> >>>>> --
>> >>>>> 2.24.1
>> >>>>>
>> >>>>> _______________________________________________
>> >>>>> amd-gfx mailing list
>> >>>>> amd-gfx@lists.freedesktop.org
>> <mailto:amd-gfx@lists.freedesktop.org>
>> >>>>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2F
>> >>>>> lists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=02%7
>> >>>>> C01%7Cmonk.liu%40amd.com%7Cba45efb26c0240ed036f08d7b6db20aa%7C3dd8
>> >>>>> 961fe4884e608e11a82d994e183d%7C0%7C0%7C637178924605524378&sdat
>> >>>>> a=%2FyHkvYU5T%2F4iFxRexsg%2BIdm7sDzyXbjzNpHUGCO7h4k%3D&reserve
>> >>>>> d=0
>> >>> _______________________________________________
>> >>> amd-gfx mailing list
>> >>> amd-gfx@lists.freedesktop.org <mailto:amd-gfx@lists.freedesktop.org>
>> >>>
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist
>> >>>
>> s.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=02%7C01%7Cmo
>> >>>
>> nk.liu%40amd.com%7Cba45efb26c0240ed036f08d7b6db20aa%7C3dd8961fe4884e60
>> >>>
>> 8e11a82d994e183d%7C0%7C0%7C637178924605524378&sdata=%2FyHkvYU5T%2F
>> >>> 4iFxRexsg%2BIdm7sDzyXbjzNpHUGCO7h4k%3D&reserved=0
>> >> _______________________________________________
>> >> amd-gfx mailing list
>> >> amd-gfx@lists.freedesktop.org <mailto:amd-gfx@lists.freedesktop.org>
>> >>
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=02%7C01%7Calexander.deucher%40amd.com%7Cf3762304925b4019bfed08d7b6e287e4%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637178957179179431&sdata=bY7V%2BKOF3gYu4ITGCKgAiRvXUvxPcwsz2zsEJDns3jI%3D&reserved=0
>> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=02%7C01%7CAlexander.Deucher%40amd.com%7C50c08a2474b346c44c0608d7b6e4d3ff%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637178966243976347&sdata=yQgD1Ywji%2BimCVr06LD0oSnf4ZHGmoN3s8a5NybPx4E%3D&reserved=0>
>> > _______________________________________________
>> > amd-gfx mailing list
>> > amd-gfx@lists.freedesktop.org <mailto:amd-gfx@lists.freedesktop.org>
>> >
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=02%7C01%7Calexander.deucher%40amd.com%7Cf3762304925b4019bfed08d7b6e287e4%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637178957179179431&sdata=bY7V%2BKOF3gYu4ITGCKgAiRvXUvxPcwsz2zsEJDns3jI%3D&reserved=0
>> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=02%7C01%7CAlexander.Deucher%40amd.com%7C50c08a2474b346c44c0608d7b6e4d3ff%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637178966243986301&sdata=5vafv2zCFbpgaSpgcQzLaEAC3wnqkIvGbrvKH3M11s4%3D&reserved=0>
>>
>> _______________________________________________
>> amd-gfx mailing list
>> amd-gfx@lists.freedesktop.org <mailto:amd-gfx@lists.freedesktop.org>
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=02%7C01%7Calexander.deucher%40amd.com%7Cf3762304925b4019bfed08d7b6e287e4%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637178957179179431&sdata=bY7V%2BKOF3gYu4ITGCKgAiRvXUvxPcwsz2zsEJDns3jI%3D&reserved=0
>> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=02%7C01%7CAlexander.Deucher%40amd.com%7C50c08a2474b346c44c0608d7b6e4d3ff%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637178966243986301&sdata=5vafv2zCFbpgaSpgcQzLaEAC3wnqkIvGbrvKH3M11s4%3D&reserved=0>
>
[-- Attachment #1.2: Type: text/html, Size: 23159 bytes --]
[-- Attachment #2: Type: text/plain, Size: 154 bytes --]
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: 回复: [PATCH] drm/amd/amdgpu: disable GFXOFF around debugfs access to MMIO
2020-02-21 16:04 ` Christian König
@ 2020-02-21 16:06 ` Tom St Denis
2020-02-21 16:10 ` Christian König
0 siblings, 1 reply; 18+ messages in thread
From: Tom St Denis @ 2020-02-21 16:06 UTC (permalink / raw)
To: christian.koenig, Deucher, Alexander, Huang, Ray, Liu, Monk
Cc: Alex Deucher, amd-gfx list
Probably simpler just to do on/off and let userspace determine timing
but other than that ya sounds good.
For things like umr's --top which runs indefinitely having a timer
wouldn't work. Similarly, --waves can take a long time depending on
activity and the asic.
Tom
On 2020-02-21 11:04 a.m., Christian König wrote:
> Ok how about this:
>
> We add a debugfs file which when read returns the GFXOFF status and
> when written with a number disabled GFXOFF for N seconds with 0
> meaning forever.
>
> Umr gets a new commandline option to write to that file before reading
> registers.
>
> This way the user can still disable it if it causes any problems. Does
> that sounds like a plan?
>
> Regards,
> Christian.
>
> Am 21.02.20 um 16:56 schrieb Deucher, Alexander:
>>
>> [AMD Public Use]
>>
>>
>> Not at the moment. But we could add a debugfs file which just wraps
>> amdgpu_gfx_off_ctrl(). That said, maybe we just add a delay here or a
>> use a timer to delay turning gfxoff back on again so that we aren't
>> turning it on and off so rapidly.
>>
>> Alex
>>
>> ------------------------------------------------------------------------
>> *From:* Christian König <ckoenig.leichtzumerken@gmail.com>
>> *Sent:* Friday, February 21, 2020 10:43 AM
>> *To:* Deucher, Alexander <Alexander.Deucher@amd.com>; Huang, Ray
>> <Ray.Huang@amd.com>; Liu, Monk <Monk.Liu@amd.com>
>> *Cc:* StDenis, Tom <Tom.StDenis@amd.com>; Alex Deucher
>> <alexdeucher@gmail.com>; amd-gfx list <amd-gfx@lists.freedesktop.org>
>> *Subject:* Re: 回复: [PATCH] drm/amd/amdgpu: disable GFXOFF around
>> debugfs access to MMIO
>> Do we have a way to disable GFXOFF on the fly?
>>
>> If not maybe it would be a good idea to add a separate debugfs file
>> to do this.
>>
>> Christian.
>>
>> Am 21.02.20 um 16:39 schrieb Deucher, Alexander:
>>>
>>> [AMD Public Use]
>>>
>>>
>>> If we are trying to debug a reproducible hang, probably best to just
>>> to disable gfxoff before messing with it to remove that as a
>>> factor. Otherwise, the method included in this patch is the proper
>>> way to disable/enable GFXOFF dynamically.
>>>
>>> Alex
>>>
>>> ------------------------------------------------------------------------
>>> *From:* amd-gfx <amd-gfx-bounces@lists.freedesktop.org>
>>> <mailto:amd-gfx-bounces@lists.freedesktop.org> on behalf of
>>> Christian König <ckoenig.leichtzumerken@gmail.com>
>>> <mailto:ckoenig.leichtzumerken@gmail.com>
>>> *Sent:* Friday, February 21, 2020 10:27 AM
>>> *To:* Huang, Ray <Ray.Huang@amd.com> <mailto:Ray.Huang@amd.com>;
>>> Liu, Monk <Monk.Liu@amd.com> <mailto:Monk.Liu@amd.com>
>>> *Cc:* StDenis, Tom <Tom.StDenis@amd.com>
>>> <mailto:Tom.StDenis@amd.com>; Alex Deucher <alexdeucher@gmail.com>
>>> <mailto:alexdeucher@gmail.com>; amd-gfx list
>>> <amd-gfx@lists.freedesktop.org> <mailto:amd-gfx@lists.freedesktop.org>
>>> *Subject:* Re: 回复: [PATCH] drm/amd/amdgpu: disable GFXOFF around
>>> debugfs access to MMIO
>>> Am 21.02.20 um 16:23 schrieb Huang Rui:
>>> > On Fri, Feb 21, 2020 at 11:18:07PM +0800, Liu, Monk wrote:
>>> >> Better not use KIQ, because when you use debugfs to read register
>>> you usually hit a hang, and by that case KIQ probably already die
>>> > If CP is busy, the gfx should be in "on" state at that time, we
>>> needn't use KIQ.
>>>
>>> Yeah, but how do you detect that? Do we have a way to wake up the CP
>>> without asking power management to do so?
>>>
>>> Cause the register debug interface is meant to be used when the ASIC is
>>> completed locked up. Sending messages to the SMU is not really going to
>>> work in that situation.
>>>
>>> Regards,
>>> Christian.
>>>
>>> >
>>> > Thanks,
>>> > Ray
>>> >
>>> >> -----邮件原件-----
>>> >> 发件人: amd-gfx <amd-gfx-bounces@lists.freedesktop.org>
>>> <mailto:amd-gfx-bounces@lists.freedesktop.org> 代表 Huang Rui
>>> >> 发送时间: 2020年2月21日 22:34
>>> >> 收件人: StDenis, Tom <Tom.StDenis@amd.com>
>>> <mailto:Tom.StDenis@amd.com>
>>> >> 抄送: Alex Deucher <alexdeucher@gmail.com>
>>> <mailto:alexdeucher@gmail.com>; amd-gfx list
>>> <amd-gfx@lists.freedesktop.org> <mailto:amd-gfx@lists.freedesktop.org>
>>> >> 主题: Re: [PATCH] drm/amd/amdgpu: disable GFXOFF around debugfs
>>> access to MMIO
>>> >>
>>> >> On Wed, Feb 19, 2020 at 10:09:46AM -0500, Tom St Denis wrote:
>>> >>> I got some messages after a while:
>>> >>>
>>> >>> [ 741.788564] Failed to send Message 8.
>>> >>> [ 746.671509] Failed to send Message 8.
>>> >>> [ 748.749673] Failed to send Message 2b.
>>> >>> [ 759.245414] Failed to send Message 7.
>>> >>> [ 763.216902] Failed to send Message 2a.
>>> >>>
>>> >>> Are there any additional locks that should be held? Because some
>>> >>> commands like --top or --waves can do a lot of distinct read
>>> >>> operations (causing a lot of enable/disable calls).
>>> >>>
>>> >>> I'm going to sit on this a bit since I don't think the patch is
>>> ready
>>> >>> for pushing out.
>>> >>>
>>> >> How about use RREG32_KIQ and WREG32_KIQ?
>>> >>
>>> >> Thanks,
>>> >> Ray
>>> >>
>>> >>> Tom
>>> >>>
>>> >>> On 2020-02-19 10:07 a.m., Alex Deucher wrote:
>>> >>>> On Wed, Feb 19, 2020 at 10:04 AM Tom St Denis
>>> <tom.stdenis@amd.com> <mailto:tom.stdenis@amd.com> wrote:
>>> >>>>> Signed-off-by: Tom St Denis <tom.stdenis@amd.com>
>>> <mailto:tom.stdenis@amd.com>
>>> >>>> Please add a patch description. With that fixed:
>>> >>>> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
>>> <mailto:alexander.deucher@amd.com>
>>> >>>>
>>> >>>>> ---
>>> >>>>> drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 3 +++
>>> >>>>> 1 file changed, 3 insertions(+)
>>> >>>>>
>>> >>>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
>>> >>>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
>>> >>>>> index 7379910790c9..66f763300c96 100644
>>> >>>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
>>> >>>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
>>> >>>>> @@ -169,6 +169,7 @@ static int
>>> amdgpu_debugfs_process_reg_op(bool read, struct file *f,
>>> >>>>> if (pm_pg_lock)
>>> >>>>> mutex_lock(&adev->pm.mutex);
>>> >>>>>
>>> >>>>> + amdgpu_gfx_off_ctrl(adev, false);
>>> >>>>> while (size) {
>>> >>>>> uint32_t value;
>>> >>>>>
>>> >>>>> @@ -192,6 +193,8 @@ static int
>>> amdgpu_debugfs_process_reg_op(bool read, struct file *f,
>>> >>>>> }
>>> >>>>>
>>> >>>>> end:
>>> >>>>> + amdgpu_gfx_off_ctrl(adev, true);
>>> >>>>> +
>>> >>>>> if (use_bank) {
>>> >>>>> amdgpu_gfx_select_se_sh(adev, 0xffffffff, 0xffffffff, 0xffffffff);
>>> >>>>> mutex_unlock(&adev->grbm_idx_mutex);
>>> >>>>> --
>>> >>>>> 2.24.1
>>> >>>>>
>>> >>>>> _______________________________________________
>>> >>>>> amd-gfx mailing list
>>> >>>>> amd-gfx@lists.freedesktop.org
>>> <mailto:amd-gfx@lists.freedesktop.org>
>>> >>>>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2F
>>> >>>>> lists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=02%7
>>> >>>>> C01%7Cmonk.liu%40amd.com%7Cba45efb26c0240ed036f08d7b6db20aa%7C3dd8
>>> >>>>> 961fe4884e608e11a82d994e183d%7C0%7C0%7C637178924605524378&sdat
>>> >>>>> a=%2FyHkvYU5T%2F4iFxRexsg%2BIdm7sDzyXbjzNpHUGCO7h4k%3D&reserve
>>> >>>>> d=0
>>> >>> _______________________________________________
>>> >>> amd-gfx mailing list
>>> >>> amd-gfx@lists.freedesktop.org <mailto:amd-gfx@lists.freedesktop.org>
>>> >>>
>>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist
>>> >>>
>>> s.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=02%7C01%7Cmo
>>> >>>
>>> nk.liu%40amd.com%7Cba45efb26c0240ed036f08d7b6db20aa%7C3dd8961fe4884e60
>>> >>>
>>> 8e11a82d994e183d%7C0%7C0%7C637178924605524378&sdata=%2FyHkvYU5T%2F
>>> >>> 4iFxRexsg%2BIdm7sDzyXbjzNpHUGCO7h4k%3D&reserved=0
>>> >> _______________________________________________
>>> >> amd-gfx mailing list
>>> >> amd-gfx@lists.freedesktop.org <mailto:amd-gfx@lists.freedesktop.org>
>>> >>
>>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=02%7C01%7Calexander.deucher%40amd.com%7Cf3762304925b4019bfed08d7b6e287e4%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637178957179179431&sdata=bY7V%2BKOF3gYu4ITGCKgAiRvXUvxPcwsz2zsEJDns3jI%3D&reserved=0
>>> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=02%7C01%7CTom.StDenis%40amd.com%7Ce7c6277c26884e509ce508d7b6e7aea5%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637178978798816096&sdata=Nj%2BxemPqrL4VhXJDcktQBWu77KxtwyYLPUvHEPquvHw%3D&reserved=0>
>>> > _______________________________________________
>>> > amd-gfx mailing list
>>> > amd-gfx@lists.freedesktop.org <mailto:amd-gfx@lists.freedesktop.org>
>>> >
>>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=02%7C01%7Calexander.deucher%40amd.com%7Cf3762304925b4019bfed08d7b6e287e4%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637178957179179431&sdata=bY7V%2BKOF3gYu4ITGCKgAiRvXUvxPcwsz2zsEJDns3jI%3D&reserved=0
>>> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=02%7C01%7CTom.StDenis%40amd.com%7Ce7c6277c26884e509ce508d7b6e7aea5%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637178978798826087&sdata=VQEOX1p4mWqWeamWP9OF4dpQeh8wAdJE%2B4SOThFAhSY%3D&reserved=0>
>>>
>>> _______________________________________________
>>> amd-gfx mailing list
>>> amd-gfx@lists.freedesktop.org <mailto:amd-gfx@lists.freedesktop.org>
>>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=02%7C01%7Calexander.deucher%40amd.com%7Cf3762304925b4019bfed08d7b6e287e4%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637178957179179431&sdata=bY7V%2BKOF3gYu4ITGCKgAiRvXUvxPcwsz2zsEJDns3jI%3D&reserved=0
>>> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=02%7C01%7CTom.StDenis%40amd.com%7Ce7c6277c26884e509ce508d7b6e7aea5%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637178978798836083&sdata=HOIBW4ctr61UCWxr%2FEpBYzP6kTMxx5J9ItOXBMmZUN4%3D&reserved=0>
>>
>
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: 回复: [PATCH] drm/amd/amdgpu: disable GFXOFF around debugfs access to MMIO
2020-02-21 16:06 ` Tom St Denis
@ 2020-02-21 16:10 ` Christian König
0 siblings, 0 replies; 18+ messages in thread
From: Christian König @ 2020-02-21 16:10 UTC (permalink / raw)
To: Tom St Denis, Deucher, Alexander, Huang, Ray, Liu, Monk
Cc: Alex Deucher, amd-gfx list
> Probably simpler just to do on/off and let userspace determine timing
> but other than that ya sounds good.
Works for me as long as we only expose it through debugfs for root.
Otherwise there is always the risk of userspace forgetting to turn it on
again.
Christian.
Am 21.02.20 um 17:06 schrieb Tom St Denis:
> Probably simpler just to do on/off and let userspace determine timing
> but other than that ya sounds good.
>
>
> For things like umr's --top which runs indefinitely having a timer
> wouldn't work. Similarly, --waves can take a long time depending on
> activity and the asic.
>
>
> Tom
>
>
>
> On 2020-02-21 11:04 a.m., Christian König wrote:
>> Ok how about this:
>>
>> We add a debugfs file which when read returns the GFXOFF status and
>> when written with a number disabled GFXOFF for N seconds with 0
>> meaning forever.
>>
>> Umr gets a new commandline option to write to that file before
>> reading registers.
>>
>> This way the user can still disable it if it causes any problems.
>> Does that sounds like a plan?
>>
>> Regards,
>> Christian.
>>
>> Am 21.02.20 um 16:56 schrieb Deucher, Alexander:
>>>
>>> [AMD Public Use]
>>>
>>>
>>> Not at the moment. But we could add a debugfs file which just wraps
>>> amdgpu_gfx_off_ctrl(). That said, maybe we just add a delay here or
>>> a use a timer to delay turning gfxoff back on again so that we
>>> aren't turning it on and off so rapidly.
>>>
>>> Alex
>>>
>>> ------------------------------------------------------------------------
>>>
>>> *From:* Christian König <ckoenig.leichtzumerken@gmail.com>
>>> *Sent:* Friday, February 21, 2020 10:43 AM
>>> *To:* Deucher, Alexander <Alexander.Deucher@amd.com>; Huang, Ray
>>> <Ray.Huang@amd.com>; Liu, Monk <Monk.Liu@amd.com>
>>> *Cc:* StDenis, Tom <Tom.StDenis@amd.com>; Alex Deucher
>>> <alexdeucher@gmail.com>; amd-gfx list <amd-gfx@lists.freedesktop.org>
>>> *Subject:* Re: 回复: [PATCH] drm/amd/amdgpu: disable GFXOFF around
>>> debugfs access to MMIO
>>> Do we have a way to disable GFXOFF on the fly?
>>>
>>> If not maybe it would be a good idea to add a separate debugfs file
>>> to do this.
>>>
>>> Christian.
>>>
>>> Am 21.02.20 um 16:39 schrieb Deucher, Alexander:
>>>>
>>>> [AMD Public Use]
>>>>
>>>>
>>>> If we are trying to debug a reproducible hang, probably best to
>>>> just to disable gfxoff before messing with it to remove that as a
>>>> factor. Otherwise, the method included in this patch is the proper
>>>> way to disable/enable GFXOFF dynamically.
>>>>
>>>> Alex
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>> *From:* amd-gfx <amd-gfx-bounces@lists.freedesktop.org>
>>>> <mailto:amd-gfx-bounces@lists.freedesktop.org> on behalf of
>>>> Christian König <ckoenig.leichtzumerken@gmail.com>
>>>> <mailto:ckoenig.leichtzumerken@gmail.com>
>>>> *Sent:* Friday, February 21, 2020 10:27 AM
>>>> *To:* Huang, Ray <Ray.Huang@amd.com> <mailto:Ray.Huang@amd.com>;
>>>> Liu, Monk <Monk.Liu@amd.com> <mailto:Monk.Liu@amd.com>
>>>> *Cc:* StDenis, Tom <Tom.StDenis@amd.com>
>>>> <mailto:Tom.StDenis@amd.com>; Alex Deucher <alexdeucher@gmail.com>
>>>> <mailto:alexdeucher@gmail.com>; amd-gfx list
>>>> <amd-gfx@lists.freedesktop.org> <mailto:amd-gfx@lists.freedesktop.org>
>>>> *Subject:* Re: 回复: [PATCH] drm/amd/amdgpu: disable GFXOFF around
>>>> debugfs access to MMIO
>>>> Am 21.02.20 um 16:23 schrieb Huang Rui:
>>>> > On Fri, Feb 21, 2020 at 11:18:07PM +0800, Liu, Monk wrote:
>>>> >> Better not use KIQ, because when you use debugfs to read
>>>> register you usually hit a hang, and by that case KIQ probably
>>>> already die
>>>> > If CP is busy, the gfx should be in "on" state at that time, we
>>>> needn't use KIQ.
>>>>
>>>> Yeah, but how do you detect that? Do we have a way to wake up the CP
>>>> without asking power management to do so?
>>>>
>>>> Cause the register debug interface is meant to be used when the
>>>> ASIC is
>>>> completed locked up. Sending messages to the SMU is not really
>>>> going to
>>>> work in that situation.
>>>>
>>>> Regards,
>>>> Christian.
>>>>
>>>> >
>>>> > Thanks,
>>>> > Ray
>>>> >
>>>> >> -----邮件原件-----
>>>> >> 发件人: amd-gfx <amd-gfx-bounces@lists.freedesktop.org>
>>>> <mailto:amd-gfx-bounces@lists.freedesktop.org> 代表 Huang Rui
>>>> >> 发送时间: 2020年2月21日 22:34
>>>> >> 收件人: StDenis, Tom <Tom.StDenis@amd.com>
>>>> <mailto:Tom.StDenis@amd.com>
>>>> >> 抄送: Alex Deucher <alexdeucher@gmail.com>
>>>> <mailto:alexdeucher@gmail.com>; amd-gfx list
>>>> <amd-gfx@lists.freedesktop.org> <mailto:amd-gfx@lists.freedesktop.org>
>>>> >> 主题: Re: [PATCH] drm/amd/amdgpu: disable GFXOFF around debugfs
>>>> access to MMIO
>>>> >>
>>>> >> On Wed, Feb 19, 2020 at 10:09:46AM -0500, Tom St Denis wrote:
>>>> >>> I got some messages after a while:
>>>> >>>
>>>> >>> [ 741.788564] Failed to send Message 8.
>>>> >>> [ 746.671509] Failed to send Message 8.
>>>> >>> [ 748.749673] Failed to send Message 2b.
>>>> >>> [ 759.245414] Failed to send Message 7.
>>>> >>> [ 763.216902] Failed to send Message 2a.
>>>> >>>
>>>> >>> Are there any additional locks that should be held? Because some
>>>> >>> commands like --top or --waves can do a lot of distinct read
>>>> >>> operations (causing a lot of enable/disable calls).
>>>> >>>
>>>> >>> I'm going to sit on this a bit since I don't think the patch is
>>>> ready
>>>> >>> for pushing out.
>>>> >>>
>>>> >> How about use RREG32_KIQ and WREG32_KIQ?
>>>> >>
>>>> >> Thanks,
>>>> >> Ray
>>>> >>
>>>> >>> Tom
>>>> >>>
>>>> >>> On 2020-02-19 10:07 a.m., Alex Deucher wrote:
>>>> >>>> On Wed, Feb 19, 2020 at 10:04 AM Tom St Denis
>>>> <tom.stdenis@amd.com> <mailto:tom.stdenis@amd.com> wrote:
>>>> >>>>> Signed-off-by: Tom St Denis <tom.stdenis@amd.com>
>>>> <mailto:tom.stdenis@amd.com>
>>>> >>>> Please add a patch description. With that fixed:
>>>> >>>> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
>>>> <mailto:alexander.deucher@amd.com>
>>>> >>>>
>>>> >>>>> ---
>>>> >>>>> drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 3 +++
>>>> >>>>> 1 file changed, 3 insertions(+)
>>>> >>>>>
>>>> >>>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
>>>> >>>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
>>>> >>>>> index 7379910790c9..66f763300c96 100644
>>>> >>>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
>>>> >>>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
>>>> >>>>> @@ -169,6 +169,7 @@ static int
>>>> amdgpu_debugfs_process_reg_op(bool read, struct file *f,
>>>> >>>>> if (pm_pg_lock)
>>>> >>>>> mutex_lock(&adev->pm.mutex);
>>>> >>>>>
>>>> >>>>> + amdgpu_gfx_off_ctrl(adev, false);
>>>> >>>>> while (size) {
>>>> >>>>> uint32_t value;
>>>> >>>>>
>>>> >>>>> @@ -192,6 +193,8 @@ static int
>>>> amdgpu_debugfs_process_reg_op(bool read, struct file *f,
>>>> >>>>> }
>>>> >>>>>
>>>> >>>>> end:
>>>> >>>>> + amdgpu_gfx_off_ctrl(adev, true);
>>>> >>>>> +
>>>> >>>>> if (use_bank) {
>>>> >>>>> amdgpu_gfx_select_se_sh(adev, 0xffffffff, 0xffffffff,
>>>> 0xffffffff);
>>>> >>>>> mutex_unlock(&adev->grbm_idx_mutex);
>>>> >>>>> --
>>>> >>>>> 2.24.1
>>>> >>>>>
>>>> >>>>> _______________________________________________
>>>> >>>>> amd-gfx mailing list
>>>> >>>>> amd-gfx@lists.freedesktop.org
>>>> <mailto:amd-gfx@lists.freedesktop.org>
>>>> >>>>>
>>>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2F
>>>> >>>>>
>>>> lists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=02%7
>>>> >>>>>
>>>> C01%7Cmonk.liu%40amd.com%7Cba45efb26c0240ed036f08d7b6db20aa%7C3dd8
>>>> >>>>>
>>>> 961fe4884e608e11a82d994e183d%7C0%7C0%7C637178924605524378&sdat
>>>> >>>>>
>>>> a=%2FyHkvYU5T%2F4iFxRexsg%2BIdm7sDzyXbjzNpHUGCO7h4k%3D&reserve
>>>> >>>>> d=0
>>>> >>> _______________________________________________
>>>> >>> amd-gfx mailing list
>>>> >>> amd-gfx@lists.freedesktop.org
>>>> <mailto:amd-gfx@lists.freedesktop.org>
>>>> >>>
>>>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist
>>>> >>>
>>>> s.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=02%7C01%7Cmo
>>>> >>>
>>>> nk.liu%40amd.com%7Cba45efb26c0240ed036f08d7b6db20aa%7C3dd8961fe4884e60
>>>> >>>
>>>> 8e11a82d994e183d%7C0%7C0%7C637178924605524378&sdata=%2FyHkvYU5T%2F
>>>> >>> 4iFxRexsg%2BIdm7sDzyXbjzNpHUGCO7h4k%3D&reserved=0
>>>> >> _______________________________________________
>>>> >> amd-gfx mailing list
>>>> >> amd-gfx@lists.freedesktop.org
>>>> <mailto:amd-gfx@lists.freedesktop.org>
>>>> >>
>>>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=02%7C01%7Calexander.deucher%40amd.com%7Cf3762304925b4019bfed08d7b6e287e4%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637178957179179431&sdata=bY7V%2BKOF3gYu4ITGCKgAiRvXUvxPcwsz2zsEJDns3jI%3D&reserved=0
>>>> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=02%7C01%7CTom.StDenis%40amd.com%7Ce7c6277c26884e509ce508d7b6e7aea5%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637178978798816096&sdata=Nj%2BxemPqrL4VhXJDcktQBWu77KxtwyYLPUvHEPquvHw%3D&reserved=0>
>>>>
>>>> > _______________________________________________
>>>> > amd-gfx mailing list
>>>> > amd-gfx@lists.freedesktop.org <mailto:amd-gfx@lists.freedesktop.org>
>>>> >
>>>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=02%7C01%7Calexander.deucher%40amd.com%7Cf3762304925b4019bfed08d7b6e287e4%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637178957179179431&sdata=bY7V%2BKOF3gYu4ITGCKgAiRvXUvxPcwsz2zsEJDns3jI%3D&reserved=0
>>>> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=02%7C01%7CTom.StDenis%40amd.com%7Ce7c6277c26884e509ce508d7b6e7aea5%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637178978798826087&sdata=VQEOX1p4mWqWeamWP9OF4dpQeh8wAdJE%2B4SOThFAhSY%3D&reserved=0>
>>>>
>>>>
>>>> _______________________________________________
>>>> amd-gfx mailing list
>>>> amd-gfx@lists.freedesktop.org <mailto:amd-gfx@lists.freedesktop.org>
>>>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=02%7C01%7Calexander.deucher%40amd.com%7Cf3762304925b4019bfed08d7b6e287e4%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637178957179179431&sdata=bY7V%2BKOF3gYu4ITGCKgAiRvXUvxPcwsz2zsEJDns3jI%3D&reserved=0
>>>> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=02%7C01%7CTom.StDenis%40amd.com%7Ce7c6277c26884e509ce508d7b6e7aea5%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637178978798836083&sdata=HOIBW4ctr61UCWxr%2FEpBYzP6kTMxx5J9ItOXBMmZUN4%3D&reserved=0>
>>>>
>>>
>>
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
^ permalink raw reply [flat|nested] 18+ messages in thread
* 回复: 回复: [PATCH] drm/amd/amdgpu: disable GFXOFF around debugfs access to MMIO
2020-02-21 15:23 ` Huang Rui
2020-02-21 15:27 ` Christian König
@ 2020-02-22 2:19 ` Liu, Monk
1 sibling, 0 replies; 18+ messages in thread
From: Liu, Monk @ 2020-02-22 2:19 UTC (permalink / raw)
To: Huang, Ray; +Cc: StDenis, Tom, Alex Deucher, amd-gfx list
>>>RREG32_KIQ and WREG32_KIQ
If you are using RREG32_KIQ it is always go through KIQ no matter GFX is "on" state or not
-----邮件原件-----
发件人: Huang, Ray <Ray.Huang@amd.com>
发送时间: 2020年2月21日 23:23
收件人: Liu, Monk <Monk.Liu@amd.com>
抄送: StDenis, Tom <Tom.StDenis@amd.com>; Alex Deucher <alexdeucher@gmail.com>; amd-gfx list <amd-gfx@lists.freedesktop.org>
主题: Re: 回复: [PATCH] drm/amd/amdgpu: disable GFXOFF around debugfs access to MMIO
On Fri, Feb 21, 2020 at 11:18:07PM +0800, Liu, Monk wrote:
> Better not use KIQ, because when you use debugfs to read register you
> usually hit a hang, and by that case KIQ probably already die
If CP is busy, the gfx should be in "on" state at that time, we needn't use KIQ.
Thanks,
Ray
>
> -----邮件原件-----
> 发件人: amd-gfx <amd-gfx-bounces@lists.freedesktop.org> 代表 Huang Rui
> 发送时间: 2020年2月21日 22:34
> 收件人: StDenis, Tom <Tom.StDenis@amd.com>
> 抄送: Alex Deucher <alexdeucher@gmail.com>; amd-gfx list
> <amd-gfx@lists.freedesktop.org>
> 主题: Re: [PATCH] drm/amd/amdgpu: disable GFXOFF around debugfs access
> to MMIO
>
> On Wed, Feb 19, 2020 at 10:09:46AM -0500, Tom St Denis wrote:
> > I got some messages after a while:
> >
> > [ 741.788564] Failed to send Message 8.
> > [ 746.671509] Failed to send Message 8.
> > [ 748.749673] Failed to send Message 2b.
> > [ 759.245414] Failed to send Message 7.
> > [ 763.216902] Failed to send Message 2a.
> >
> > Are there any additional locks that should be held? Because some
> > commands like --top or --waves can do a lot of distinct read
> > operations (causing a lot of enable/disable calls).
> >
> > I'm going to sit on this a bit since I don't think the patch is
> > ready for pushing out.
> >
>
> How about use RREG32_KIQ and WREG32_KIQ?
>
> Thanks,
> Ray
>
> >
> > Tom
> >
> > On 2020-02-19 10:07 a.m., Alex Deucher wrote:
> > > On Wed, Feb 19, 2020 at 10:04 AM Tom St Denis <tom.stdenis@amd.com> wrote:
> > > > Signed-off-by: Tom St Denis <tom.stdenis@amd.com>
> > > Please add a patch description. With that fixed:
> > > Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
> > >
> > > > ---
> > > > drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 3 +++
> > > > 1 file changed, 3 insertions(+)
> > > >
> > > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
> > > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
> > > > index 7379910790c9..66f763300c96 100644
> > > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
> > > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
> > > > @@ -169,6 +169,7 @@ static int amdgpu_debugfs_process_reg_op(bool read, struct file *f,
> > > > if (pm_pg_lock)
> > > > mutex_lock(&adev->pm.mutex);
> > > >
> > > > + amdgpu_gfx_off_ctrl(adev, false);
> > > > while (size) {
> > > > uint32_t value;
> > > >
> > > > @@ -192,6 +193,8 @@ static int amdgpu_debugfs_process_reg_op(bool read, struct file *f,
> > > > }
> > > >
> > > > end:
> > > > + amdgpu_gfx_off_ctrl(adev, true);
> > > > +
> > > > if (use_bank) {
> > > > amdgpu_gfx_select_se_sh(adev, 0xffffffff, 0xffffffff, 0xffffffff);
> > > > mutex_unlock(&adev->grbm_idx_mutex);
> > > > --
> > > > 2.24.1
> > > >
> > > > _______________________________________________
> > > > amd-gfx mailing list
> > > > amd-gfx@lists.freedesktop.org
> > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%
> > > > 2F
> > > > lists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=02
> > > > %7
> > > > C01%7Cmonk.liu%40amd.com%7Cba45efb26c0240ed036f08d7b6db20aa%7C3d
> > > > d8
> > > > 961fe4884e608e11a82d994e183d%7C0%7C0%7C637178924605524378&sd
> > > > at
> > > > a=%2FyHkvYU5T%2F4iFxRexsg%2BIdm7sDzyXbjzNpHUGCO7h4k%3D&reser
> > > > ve
> > > > d=0
> > _______________________________________________
> > amd-gfx mailing list
> > amd-gfx@lists.freedesktop.org
> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fli
> > st
> > s.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=02%7C01%7C
> > mo
> > nk.liu%40amd.com%7Cba45efb26c0240ed036f08d7b6db20aa%7C3dd8961fe4884e
> > 60
> > 8e11a82d994e183d%7C0%7C0%7C637178924605524378&sdata=%2FyHkvYU5T%
> > 2F
> > 4iFxRexsg%2BIdm7sDzyXbjzNpHUGCO7h4k%3D&reserved=0
> _______________________________________________
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist
> s.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=02%7C01%7Cmo
> nk.liu%40amd.com%7Cba45efb26c0240ed036f08d7b6db20aa%7C3dd8961fe4884e60
> 8e11a82d994e183d%7C0%7C0%7C637178924605524378&sdata=%2FyHkvYU5T%2F
> 4iFxRexsg%2BIdm7sDzyXbjzNpHUGCO7h4k%3D&reserved=0
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
^ permalink raw reply [flat|nested] 18+ messages in thread
* 回复: 回复: [PATCH] drm/amd/amdgpu: disable GFXOFF around debugfs access to MMIO
2020-02-21 15:39 ` Deucher, Alexander
2020-02-21 15:43 ` Christian König
@ 2020-02-22 2:21 ` Liu, Monk
1 sibling, 0 replies; 18+ messages in thread
From: Liu, Monk @ 2020-02-22 2:21 UTC (permalink / raw)
To: Deucher, Alexander, Christian König, Huang, Ray
Cc: StDenis, Tom, Alex Deucher, amd-gfx list
[-- Attachment #1.1: Type: text/plain, Size: 7811 bytes --]
>>> If we are trying to debug a reproducible hang, probably best to just to disable gfxoff before messing with it to remove that as a factor.
Agree
>> Otherwise, the method included in this patch is the proper way to disable/enable GFXOFF dynamically.
Sounds not doable, because we cannot disable GFXOFF every time we use debugfs (and restore GFXOFF as well after that debugfs interface done …)
thanks
发件人: Deucher, Alexander <Alexander.Deucher@amd.com>
发送时间: 2020年2月21日 23:40
收件人: Christian König <ckoenig.leichtzumerken@gmail.com>; Huang, Ray <Ray.Huang@amd.com>; Liu, Monk <Monk.Liu@amd.com>
抄送: StDenis, Tom <Tom.StDenis@amd.com>; Alex Deucher <alexdeucher@gmail.com>; amd-gfx list <amd-gfx@lists.freedesktop.org>
主题: Re: 回复: [PATCH] drm/amd/amdgpu: disable GFXOFF around debugfs access to MMIO
[AMD Public Use]
If we are trying to debug a reproducible hang, probably best to just to disable gfxoff before messing with it to remove that as a factor. Otherwise, the method included in this patch is the proper way to disable/enable GFXOFF dynamically.
Alex
________________________________
From: amd-gfx <amd-gfx-bounces@lists.freedesktop.org<mailto:amd-gfx-bounces@lists.freedesktop.org>> on behalf of Christian König <ckoenig.leichtzumerken@gmail.com<mailto:ckoenig.leichtzumerken@gmail.com>>
Sent: Friday, February 21, 2020 10:27 AM
To: Huang, Ray <Ray.Huang@amd.com<mailto:Ray.Huang@amd.com>>; Liu, Monk <Monk.Liu@amd.com<mailto:Monk.Liu@amd.com>>
Cc: StDenis, Tom <Tom.StDenis@amd.com<mailto:Tom.StDenis@amd.com>>; Alex Deucher <alexdeucher@gmail.com<mailto:alexdeucher@gmail.com>>; amd-gfx list <amd-gfx@lists.freedesktop.org<mailto:amd-gfx@lists.freedesktop.org>>
Subject: Re: 回复: [PATCH] drm/amd/amdgpu: disable GFXOFF around debugfs access to MMIO
Am 21.02.20 um 16:23 schrieb Huang Rui:
> On Fri, Feb 21, 2020 at 11:18:07PM +0800, Liu, Monk wrote:
>> Better not use KIQ, because when you use debugfs to read register you usually hit a hang, and by that case KIQ probably already die
> If CP is busy, the gfx should be in "on" state at that time, we needn't use KIQ.
Yeah, but how do you detect that? Do we have a way to wake up the CP
without asking power management to do so?
Cause the register debug interface is meant to be used when the ASIC is
completed locked up. Sending messages to the SMU is not really going to
work in that situation.
Regards,
Christian.
>
> Thanks,
> Ray
>
>> -----邮件原件-----
>> 发件人: amd-gfx <amd-gfx-bounces@lists.freedesktop.org<mailto:amd-gfx-bounces@lists.freedesktop.org>> 代表 Huang Rui
>> 发送时间: 2020年2月21日 22:34
>> 收件人: StDenis, Tom <Tom.StDenis@amd.com<mailto:Tom.StDenis@amd.com>>
>> 抄送: Alex Deucher <alexdeucher@gmail.com<mailto:alexdeucher@gmail.com>>; amd-gfx list <amd-gfx@lists.freedesktop.org<mailto:amd-gfx@lists.freedesktop.org>>
>> 主题: Re: [PATCH] drm/amd/amdgpu: disable GFXOFF around debugfs access to MMIO
>>
>> On Wed, Feb 19, 2020 at 10:09:46AM -0500, Tom St Denis wrote:
>>> I got some messages after a while:
>>>
>>> [ 741.788564] Failed to send Message 8.
>>> [ 746.671509] Failed to send Message 8.
>>> [ 748.749673] Failed to send Message 2b.
>>> [ 759.245414] Failed to send Message 7.
>>> [ 763.216902] Failed to send Message 2a.
>>>
>>> Are there any additional locks that should be held? Because some
>>> commands like --top or --waves can do a lot of distinct read
>>> operations (causing a lot of enable/disable calls).
>>>
>>> I'm going to sit on this a bit since I don't think the patch is ready
>>> for pushing out.
>>>
>> How about use RREG32_KIQ and WREG32_KIQ?
>>
>> Thanks,
>> Ray
>>
>>> Tom
>>>
>>> On 2020-02-19 10:07 a.m., Alex Deucher wrote:
>>>> On Wed, Feb 19, 2020 at 10:04 AM Tom St Denis <tom.stdenis@amd.com<mailto:tom.stdenis@amd.com>> wrote:
>>>>> Signed-off-by: Tom St Denis <tom.stdenis@amd.com<mailto:tom.stdenis@amd.com>>
>>>> Please add a patch description. With that fixed:
>>>> Reviewed-by: Alex Deucher <alexander.deucher@amd.com<mailto:alexander.deucher@amd.com>>
>>>>
>>>>> ---
>>>>> drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 3 +++
>>>>> 1 file changed, 3 insertions(+)
>>>>>
>>>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
>>>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
>>>>> index 7379910790c9..66f763300c96 100644
>>>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
>>>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
>>>>> @@ -169,6 +169,7 @@ static int amdgpu_debugfs_process_reg_op(bool read, struct file *f,
>>>>> if (pm_pg_lock)
>>>>> mutex_lock(&adev->pm.mutex);
>>>>>
>>>>> + amdgpu_gfx_off_ctrl(adev, false);
>>>>> while (size) {
>>>>> uint32_t value;
>>>>>
>>>>> @@ -192,6 +193,8 @@ static int amdgpu_debugfs_process_reg_op(bool read, struct file *f,
>>>>> }
>>>>>
>>>>> end:
>>>>> + amdgpu_gfx_off_ctrl(adev, true);
>>>>> +
>>>>> if (use_bank) {
>>>>> amdgpu_gfx_select_se_sh(adev, 0xffffffff, 0xffffffff, 0xffffffff);
>>>>> mutex_unlock(&adev->grbm_idx_mutex);
>>>>> --
>>>>> 2.24.1
>>>>>
>>>>> _______________________________________________
>>>>> amd-gfx mailing list
>>>>> amd-gfx@lists.freedesktop.org<mailto:amd-gfx@lists.freedesktop.org>
>>>>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2F
>>>>> lists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=02%7
>>>>> C01%7Cmonk.liu%40amd.com%7Cba45efb26c0240ed036f08d7b6db20aa%7C3dd8
>>>>> 961fe4884e608e11a82d994e183d%7C0%7C0%7C637178924605524378&sdat
>>>>> a=%2FyHkvYU5T%2F4iFxRexsg%2BIdm7sDzyXbjzNpHUGCO7h4k%3D&reserve
>>>>> d=0
>>> _______________________________________________
>>> amd-gfx mailing list
>>> amd-gfx@lists.freedesktop.org<mailto:amd-gfx@lists.freedesktop.org>
>>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist
>>> s.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=02%7C01%7Cmo
>>> nk.liu%40amd.com%7Cba45efb26c0240ed036f08d7b6db20aa%7C3dd8961fe4884e60
>>> 8e11a82d994e183d%7C0%7C0%7C637178924605524378&sdata=%2FyHkvYU5T%2F
>>> 4iFxRexsg%2BIdm7sDzyXbjzNpHUGCO7h4k%3D&reserved=0
>> _______________________________________________
>> amd-gfx mailing list
>> amd-gfx@lists.freedesktop.org<mailto:amd-gfx@lists.freedesktop.org>
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=02%7C01%7Calexander.deucher%40amd.com%7Cf3762304925b4019bfed08d7b6e287e4%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637178957179179431&sdata=bY7V%2BKOF3gYu4ITGCKgAiRvXUvxPcwsz2zsEJDns3jI%3D&reserved=0
> _______________________________________________
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org<mailto:amd-gfx@lists.freedesktop.org>
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=02%7C01%7Calexander.deucher%40amd.com%7Cf3762304925b4019bfed08d7b6e287e4%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637178957179179431&sdata=bY7V%2BKOF3gYu4ITGCKgAiRvXUvxPcwsz2zsEJDns3jI%3D&reserved=0
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org<mailto:amd-gfx@lists.freedesktop.org>
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=02%7C01%7Calexander.deucher%40amd.com%7Cf3762304925b4019bfed08d7b6e287e4%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637178957179179431&sdata=bY7V%2BKOF3gYu4ITGCKgAiRvXUvxPcwsz2zsEJDns3jI%3D&reserved=0
[-- Attachment #1.2: Type: text/html, Size: 17864 bytes --]
[-- Attachment #2: Type: text/plain, Size: 154 bytes --]
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2020-02-22 2:21 UTC | newest]
Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-02-19 15:04 [PATCH] drm/amd/amdgpu: disable GFXOFF around debugfs access to MMIO Tom St Denis
2020-02-19 15:07 ` Alex Deucher
2020-02-19 15:09 ` Tom St Denis
2020-02-21 14:34 ` Huang Rui
2020-02-21 14:35 ` Tom St Denis
2020-02-21 14:44 ` Huang Rui
2020-02-21 15:18 ` 回复: " Liu, Monk
2020-02-21 15:23 ` Huang Rui
2020-02-21 15:27 ` Christian König
2020-02-21 15:39 ` Deucher, Alexander
2020-02-21 15:43 ` Christian König
2020-02-21 15:56 ` Deucher, Alexander
2020-02-21 16:04 ` Christian König
2020-02-21 16:06 ` Tom St Denis
2020-02-21 16:10 ` Christian König
2020-02-22 2:21 ` 回复: " Liu, Monk
2020-02-21 15:49 ` Huang Rui
2020-02-22 2:19 ` 回复: " Liu, Monk
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.