Received: by 2002:a05:7412:419a:b0:f3:1519:9f41 with SMTP id i26csp972445rdh; Fri, 24 Nov 2023 02:22:09 -0800 (PST) X-Google-Smtp-Source: AGHT+IErq0S2fClX18obhbCI9Obgbc8hdnkuCDu3bI7CP62DQt/oa5AiP+ZbjXqFYgLAuFQPwO87 X-Received: by 2002:a05:6808:3209:b0:3b8:4ada:7d7b with SMTP id cb9-20020a056808320900b003b84ada7d7bmr2805668oib.28.1700821329004; Fri, 24 Nov 2023 02:22:09 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1700821328; cv=none; d=google.com; s=arc-20160816; b=qvV8pIc1nzArcGjMwccA0J0J8xgiLJ3RCsQkkSTcsS4CN4w7gh3rlqD8zyQmfP13+J KUFEWfcnBqMRwlqE98wpwJIkkT8P9aSH1H1VFO2ftVl5t/feOpiMcGKvyhQ5BI6BLgVT 5ENsfXS01diNVPFFbhm/chzLAxIcMJnsknK6eikPqmUeCIOqqMdoebaL+ndUp0/RKPbG 5qV0c6OOvWzMAt/JX/DDkgcQCUFmwXjiTMGEXzcCyVNpB1syTE2c74DWxAG9/H2IgkB2 dhO8vhqEgH9OUySwxe2vwOboI4yyDJ+/8CmZWtZSj13W7GSURpQfIlyAYxr1gpxRAish LlgQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :organization:references:in-reply-to:message-id:subject:cc:to:from :date:dkim-signature; bh=K55h7W0no3jydBW3XPAhO6AAvqMaLYXkqM6cPcCsnP0=; fh=VwElTOQhLpOBk13wcoNaxveX044TUxFJngCoF/6yyZk=; b=uwsRbXVwu0VAkV4FXIqC8Az/Lm47QT6FpuwmetCHJLF6paCTnlcD/1459TGpSAE3Ce RqRuww66yW1w4HxOJHvuWkGT4Wady48sU3y63rFK2Sc76sg35L/OZVL8d14dCtZLGH8D F13tyi0mVtYbhdmt1ZfuoI3Y/zw6OJtPehAc5H83HrXDQxNtBkvgdhl29LHMhDqu1fLQ RcoN/iSO+73FJBQXHd0R5wT8kRLwelsH8aH/eII1EF/4I1vEk05eWgcWfh4Gp/WNzw5z pcNu/HUKS3ir/K9Qx2YkVmxlRQrFyi7gh/A0Dn/SnELzdHGElyLvyNX9Mw2WIUIJUpmX 0bpg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@collabora.com header.s=mail header.b=E8m+CKdV; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:4 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=collabora.com Return-Path: Received: from howler.vger.email (howler.vger.email. [2620:137:e000::3:4]) by mx.google.com with ESMTPS id x20-20020a63f714000000b005c14fc66cc4si3295747pgh.380.2023.11.24.02.22.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 24 Nov 2023 02:22:08 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:4 as permitted sender) client-ip=2620:137:e000::3:4; Authentication-Results: mx.google.com; dkim=pass header.i=@collabora.com header.s=mail header.b=E8m+CKdV; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:4 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=collabora.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by howler.vger.email (Postfix) with ESMTP id D824B80AF809; Fri, 24 Nov 2023 02:22:05 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at howler.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345526AbjKXKVt (ORCPT + 99 others); Fri, 24 Nov 2023 05:21:49 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59790 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345481AbjKXKVr (ORCPT ); Fri, 24 Nov 2023 05:21:47 -0500 Received: from madras.collabora.co.uk (madras.collabora.co.uk [IPv6:2a00:1098:0:82:1000:25:2eeb:e5ab]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 49F58BC for ; Fri, 24 Nov 2023 02:21:53 -0800 (PST) Received: from localhost (cola.collaboradmins.com [195.201.22.229]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: bbrezillon) by madras.collabora.co.uk (Postfix) with ESMTPSA id 3A34B66073A8; Fri, 24 Nov 2023 10:21:51 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1700821311; bh=0UstT5q4XGqLhugf7BzP/6tcf1OIPQXVhYROpLfPmeg=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=E8m+CKdVsUsF1G5OGRdCsKrrZW+LRi+CVh6lbl/tdwkzCZtajmPyZJuB8N+ZEOjwc jKrNzEFNediRAs+okyNZfM8vfSJfSzaYWtc0dbDWAUG8C24mDncKKUqM0vhg/eegTA RpvVx+URcsvGso2fab608xlkfGa4o2EpUA1dm+HMysDditQ4CygQOshoNHelFJtWLd IOiiTR1RYJvfdJCBxv7QB19SWwK+35dV7P1vYkr1nLzNdcr4lXAteYh/sumOKQ+rqU QtZU7WUDfyIR0E9XJMdp/3YIkp7JdgMEQzzFljpGSx1Ti6+BdmQiTMb4JxYXnzvaZf w6g8swatrZHyA== Date: Fri, 24 Nov 2023 11:21:47 +0100 From: Boris Brezillon To: AngeloGioacchino Del Regno Cc: steven.price@arm.com, robh@kernel.org, maarten.lankhorst@linux.intel.com, mripard@kernel.org, tzimmermann@suse.de, airlied@gmail.com, daniel@ffwll.ch, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, krzysztof.kozlowski@linaro.org, kernel@collabora.com Subject: Re: [PATCH] drm/panfrost: Ignore core_mask for poweroff and sync interrupts Message-ID: <20231124112147.19b6b6b7@collabora.com> In-Reply-To: References: <20231123095320.41433-1-angelogioacchino.delregno@collabora.com> <20231123113530.46191ded@collabora.com> <1740797f-f3ae-4868-924a-08d6d731e506@collabora.com> <20231123135933.34d643f7@collabora.com> <5019af46-f5ae-4db5-979e-802b61025ba4@collabora.com> <20231123145103.23b6eac9@collabora.com> <43cc8641-6a60-41d9-b8f2-32227235702a@collabora.com> <20231123164019.629c91f9@collabora.com> <5e60f1d1-8e3a-42ca-af56-126faa67ea86@collabora.com> Organization: Collabora X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on howler.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (howler.vger.email [0.0.0.0]); Fri, 24 Nov 2023 02:22:06 -0800 (PST) On Fri, 24 Nov 2023 11:12:57 +0100 AngeloGioacchino Del Regno wrote: > Il 24/11/23 10:17, AngeloGioacchino Del Regno ha scritto: > > Il 23/11/23 16:40, Boris Brezillon ha scritto: =20 > >> On Thu, 23 Nov 2023 16:14:12 +0100 > >> AngeloGioacchino Del Regno > >> wrote: > >> =20 > >>> Il 23/11/23 14:51, Boris Brezillon ha scritto: =20 > >>>> On Thu, 23 Nov 2023 14:24:57 +0100 > >>>> AngeloGioacchino Del Regno > >>>> wrote: =20 > >>>>>>> > >>>>>>> So, while I agree that it'd be slightly more readable as a diff i= f those > >>>>>>> were two different commits I do have reasons against splitting...= .. =20 > >>>>>> > >>>>>> If we just need a quick fix to avoid PWRTRANS interrupts from kick= ing > >>>>>> in when we power-off the cores, I think we'd be better off dropping > >>>>>> GPU_IRQ_POWER_CHANGED[_ALL] from the value we write to GPU_INT_MASK > >>>>>> at [re]initialization time, and then have a separate series that f= ixes > >>>>>> the problem more generically. =20 > >>>>> > >>>>> But that didn't work: > >>>>> https://lore.kernel.org/all/d95259b8-10cf-4ded-866c-47cbd2a44f84@li= naro.org/ =20 > >>>> > >>>> I meant, your 'ignore-core_mask' fix + the > >>>> 'drop GPU_IRQ_POWER_CHANGED[_ALL] in GPU_INT_MASK' one. > >>>> > >>>> So, > >>>> > >>>> https://lore.kernel.org/all/4c73f67e-174c-497e-85a5-cb053ce657cb@col= labora.com/ > >>>> + > >>>> https://lore.kernel.org/all/d95259b8-10cf-4ded-866c-47cbd2a44f84@lin= aro.org/ =20 > >>>>> > >>>>> > >>>>> ...while this "full" solution worked: > >>>>> https://lore.kernel.org/all/39e9514b-087c-42eb-8d0e-f75dc620e954@li= naro.org/ > >>>>> > >>>>> https://lore.kernel.org/all/5b24cc73-23aa-4837-abb9-b6d138b46426@li= naro.org/ > >>>>> > >>>>> > >>>>> ...so this *is* a "quick fix" already... :-) =20 > >>>> > >>>> It's a half-baked solution for the missing irq-synchronization-on-su= spend > >>>> issue IMHO. I understand why you want it all in one patch that can s= erve > >>>> as a fix for 123b431f8a5c ("drm/panfrost: Really power off GPU cores= in > >>>> panfrost_gpu_power_off()"), which is why I'm suggesting to go for an > >>>> even simpler diff (see below), and then fully address the > >>>> irq-synhronization-on-suspend issue in a follow-up patchset. =20 > >>>> --->8--- =20 > >>>> diff --git a/drivers/gpu/drm/panfrost/panfrost_gpu.c=20 > >>>> b/drivers/gpu/drm/panfrost/panfrost_gpu.c > >>>> index 09f5e1563ebd..6e2d7650cc2b 100644 > >>>> --- a/drivers/gpu/drm/panfrost/panfrost_gpu.c > >>>> +++ b/drivers/gpu/drm/panfrost/panfrost_gpu.c > >>>> @@ -78,7 +78,10 @@ int panfrost_gpu_soft_reset(struct panfrost_devic= e *pfdev) > >>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 } > >>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 gpu_write(pfd= ev, GPU_INT_CLEAR, GPU_IRQ_MASK_ALL); > >>>> -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 gpu_write(pfdev, GPU_INT_MASK,= GPU_IRQ_MASK_ALL); =20 > >> > >> We probably want a comment here: > >> > >> =C2=A0=C2=A0=C2=A0=C2=A0/* Only enable the interrupts we care about. */ > >> =20 > >>>> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 gpu_write(pfdev, GPU_INT_MASK, > >>>> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 GPU_IRQ_MASK_ERROR | > >>>> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 GPU_IRQ_PERFCNT_SAMPLE_COMPLETED | > >>>> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 GPU_IRQ_CLEAN_CACHES_COMPLETED); =20 > >>> > >>> ...but if we do that, the next patch(es) will contain a partial rever= t of this > >>> commit, putting back this to gpu_write(pfdev, GPU_INT_MASK, GPU_IRQ_M= ASK_ALL)... =20 > >> > >> Why should we revert it? We're not processing the PWRTRANS interrupts > >> in the interrupt handler, those should never have been enabled in the > >> first place. The only reason we'd want to revert that change is if we > >> decide to do have interrupt-based waits in the poweron/off > >> implementation, which, as far as I'm aware, is not something we intend > >> to do any time soon. > >> =20 > >=20 > > You're right, yes. Okay, I'll push the new code soon. > >=20 > > Cheers! > > =20 >=20 > Update: I was running some (rather fast) tests here because I ... felt li= ke playing > with it, basically :-) >=20 > So, I had an issue with MediaTek platforms being unable to cut power to t= he GPU or > disable clocks aggressively... and after trying "this and that" I couldn'= t get it > working (in runtime suspend). >=20 > Long story short - after implementing `panfrost_{job,mmu,gpu}_suspend_irq= ()` (only > gpu irq, as you said, is a half solution), I can not only turn off clocks= , but even > turn off GPU power supplies entirely, bringing the power consumption of t= he GPU > itself during *runtime* suspend to ... zero. Very nice! >=20 > The result of this test makes me truly happy, even though complete powerc= ut during > runtime suspend may not be feasible for other reasons (takes ~200000ns on= AVG, > MIN ~160000ns, but the MAX is ~475000ns - and beware that I haven't run t= hat for > long, I'd suspect to get up to 1-1.5ms as max time, so that's a big no). Do you know what's taking so long? I'm disabling clks + the main power domain in panthor (I leave the regulators enabled), but I didn't get to measure the time it takes to enter/exit suspend. I might have to do what you did in panfrost and have different paths for system and RPM suspend. >=20 > This means that I will take a day or two and I'll push both the "simple" = fix for > the Really-power-off and also some more commits to add the full irq sync. Thanks for working on that, and sorry if I've been picky in my previous reviews. Looking forward to review these new patches. Regards, Boris