Re: 回复: [PATCH] drm/amd/amdgpu: disable GFXOFF around debugfs access to MMIO
Christian König
ckoenig.leichtzumerken at gmail.com
Fri Feb 21 16:04:05 UTC 2020
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 at gmail.com>
> *Sent:* Friday, February 21, 2020 10:43 AM
> *To:* Deucher, Alexander <Alexander.Deucher at amd.com>; Huang, Ray
> <Ray.Huang at amd.com>; Liu, Monk <Monk.Liu at amd.com>
> *Cc:* StDenis, Tom <Tom.StDenis at amd.com>; Alex Deucher
> <alexdeucher at gmail.com>; amd-gfx list <amd-gfx at 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 at lists.freedesktop.org>
>> <mailto:amd-gfx-bounces at lists.freedesktop.org> on behalf of Christian
>> König <ckoenig.leichtzumerken at gmail.com>
>> <mailto:ckoenig.leichtzumerken at gmail.com>
>> *Sent:* Friday, February 21, 2020 10:27 AM
>> *To:* Huang, Ray <Ray.Huang at amd.com> <mailto:Ray.Huang at amd.com>; Liu,
>> Monk <Monk.Liu at amd.com> <mailto:Monk.Liu at amd.com>
>> *Cc:* StDenis, Tom <Tom.StDenis at amd.com>
>> <mailto:Tom.StDenis at amd.com>; Alex Deucher <alexdeucher at gmail.com>
>> <mailto:alexdeucher at gmail.com>; amd-gfx list
>> <amd-gfx at lists.freedesktop.org> <mailto:amd-gfx at 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 at lists.freedesktop.org>
>> <mailto:amd-gfx-bounces at lists.freedesktop.org> 代表 Huang Rui
>> >> 发送时间: 2020年2月21日 22:34
>> >> 收件人: StDenis, Tom <Tom.StDenis at amd.com>
>> <mailto:Tom.StDenis at amd.com>
>> >> 抄送: Alex Deucher <alexdeucher at gmail.com>
>> <mailto:alexdeucher at gmail.com>; amd-gfx list
>> <amd-gfx at lists.freedesktop.org> <mailto: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> <mailto:tom.stdenis at amd.com> wrote:
>> >>>>> Signed-off-by: Tom St Denis <tom.stdenis at amd.com>
>> <mailto:tom.stdenis at amd.com>
>> >>>> Please add a patch description. With that fixed:
>> >>>> Reviewed-by: Alex Deucher <alexander.deucher at amd.com>
>> <mailto: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
>> <mailto: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 <mailto: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 <mailto: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%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 at lists.freedesktop.org <mailto: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%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 at lists.freedesktop.org <mailto: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%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>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/amd-gfx/attachments/20200221/79c8bd9a/attachment-0001.htm>
More information about the amd-gfx
mailing list