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