回复: [PATCH] drm/amd/amdgpu: disable GFXOFF around debugfs access to MMIO

Fri Feb 21 15:49:51 UTC 2020

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 at lists.freedesktop.org> 代表 Huang Rui
> >> 发送时间: 2020年2月21日 22:34
> >> 收件人: StDenis, Tom <Tom.StDenis at amd.com>
> >> 抄送: Alex Deucher <alexdeucher at gmail.com>; amd-gfx list <amd-gfx at 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 at amd.com> wrote:
> >>>>> Signed-off-by: Tom St Denis <tom.stdenis at amd.com>
> >>>> Please add a patch description.  With that fixed:
> >>>> Reviewed-by: Alex Deucher <alexander.deucher at 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 at 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 at 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 at 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 at 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
> 