From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-10.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,NICE_REPLY_A, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 22402C432BE for ; Thu, 12 Aug 2021 16:54:59 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 2148160ED5 for ; Thu, 12 Aug 2021 16:54:58 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 2148160ED5 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=daenzer.net Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 42D9A6E435; Thu, 12 Aug 2021 16:54:55 +0000 (UTC) Received: from netline-mail3.netline.ch (mail.netline.ch [148.251.143.180]) by gabe.freedesktop.org (Postfix) with ESMTP id EE9AE6E434; Thu, 12 Aug 2021 16:54:52 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by netline-mail3.netline.ch (Postfix) with ESMTP id AD7C120201B; Thu, 12 Aug 2021 18:54:51 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at netline-mail3.netline.ch Received: from netline-mail3.netline.ch ([127.0.0.1]) by localhost (netline-mail3.netline.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id CkgQfxZhxIDW; Thu, 12 Aug 2021 18:54:51 +0200 (CEST) Received: from thor (24.99.2.85.dynamic.wline.res.cust.swisscom.ch [85.2.99.24]) by netline-mail3.netline.ch (Postfix) with ESMTPA id 5235720201A; Thu, 12 Aug 2021 18:54:51 +0200 (CEST) Received: from [::1] by thor with esmtp (Exim 4.94.2) (envelope-from ) id 1mEDyk-0005vC-Ag; Thu, 12 Aug 2021 18:54:50 +0200 To: "Lazar, Lijo" , "Koenig, Christian" , "Quan, Evan" , "Deucher, Alexander" Cc: "Liu, Leo" , "Zhu, James" , "amd-gfx@lists.freedesktop.org" , "dri-devel@lists.freedesktop.org" References: <20210811165211.6811-1-michel@daenzer.net> <20210811165211.6811-2-michel@daenzer.net> <194e8a33-1705-d19c-add1-38941b6d9b5c@amd.com> From: =?UTF-8?Q?Michel_D=c3=a4nzer?= Subject: Re: [PATCH 2/2] drm/amdgpu: Use mod_delayed_work in JPEG/UVD/VCE/VCN ring_end_use hooks Message-ID: Date: Thu, 12 Aug 2021 18:54:50 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: <194e8a33-1705-d19c-add1-38941b6d9b5c@amd.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-CA Content-Transfer-Encoding: 8bit X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On 2021-08-12 1:33 p.m., Lazar, Lijo wrote: > On 8/12/2021 1:41 PM, Michel Dänzer wrote: >> On 2021-08-12 7:55 a.m., Koenig, Christian wrote: >>> Hi James, >>> >>> Evan seems to have understood how this all works together. >>> >>> See while any begin/end use critical section is active the work should not be active. >>> >>> When you handle only one ring you can just call cancel in begin use and schedule in end use. But when you have more than one ring you need a lock or counter to prevent concurrent work items to be started. >>> >>> Michelle's idea to use mod_delayed_work is a bad one because it assumes that the delayed work is still running. >> >> It merely assumes that the work may already have been scheduled before. >> >> Admittedly, I missed the cancel_delayed_work_sync calls for patch 2. While I think it can still have some effect when there's a single work item for multiple rings, as described by James, it's probably negligible, since presumably the time intervals between ring_begin_use and ring_end_use are normally much shorter than a second. >> >> So, while patch 2 is at worst a no-op (since mod_delayed_work is the same as schedule_delayed_work if the work hasn't been scheduled yet), I'm fine with dropping it. >> >> >>> Something similar applies to the first patch I think, >> >> There are no cancel work calls in that case, so the commit log is accurate TTBOMK. > > Curious - > > For patch 1, does it make a difference if any delayed work scheduled is cancelled in the else part before proceeding? > > } else if (!enable && adev->gfx.gfx_off_state) { > cancel_delayed_work(); I tried the patch below. While this does seem to fix the problem as well, I see a potential issue: 1. amdgpu_gfx_off_ctrl locks adev->gfx.gfx_off_mutex 2. amdgpu_device_delay_enable_gfx_off runs, blocks in mutex_lock 3. amdgpu_gfx_off_ctrl calls cancel_delayed_work_sync I'm afraid this would deadlock? (CONFIG_PROVE_LOCKING doesn't complain though) Maybe it's possible to fix it with cancel_delayed_work_sync somehow, but I'm not sure how offhand. (With cancel_delayed_work instead, I'm worried amdgpu_device_delay_enable_gfx_off might still enable GFXOFF in the HW immediately after amdgpu_gfx_off_ctrl unlocks the mutex. Then again, that might happen with mod_delayed_work as well...) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c index a0be0772c8b3..3e4585ffb9af 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c @@ -570,8 +570,11 @@ void amdgpu_gfx_off_ctrl(struct amdgpu_device *adev, bool enable) if (enable && !adev->gfx.gfx_off_state && !adev->gfx.gfx_off_req_count) { schedule_delayed_work(&adev->gfx.gfx_off_delay_work, GFX_OFF_DELAY_ENABLE); - } else if (!enable && adev->gfx.gfx_off_state) { - if (!amdgpu_dpm_set_powergating_by_smu(adev, AMD_IP_BLOCK_TYPE_GFX, false)) { + } else if (!enable) { + cancel_delayed_work_sync(&adev->gfx.gfx_off_delay_work); + + if (adev->gfx.gfx_off_state && + !amdgpu_dpm_set_powergating_by_smu(adev, AMD_IP_BLOCK_TYPE_GFX, false)) { adev->gfx.gfx_off_state = false; if (adev->gfx.funcs->init_spm_golden) { -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer