[v4,12/19] arm64: dts: mediatek: mt8192-asurada: Couple VGPU and VSRAM_OTHER regulators
Message ID | 20230301095523.428461-13-angelogioacchino.delregno@collabora.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:5915:0:0:0:0:0 with SMTP id v21csp3539945wrd; Wed, 1 Mar 2023 01:57:57 -0800 (PST) X-Google-Smtp-Source: AK7set8BB2HDG1fU6j/rkT/axXDXJdKGssUKpBCRhQL27cDBBez6fpS7coVqadsZ49ITd69Xcky6 X-Received: by 2002:a17:903:41c1:b0:19c:d550:8cd4 with SMTP id u1-20020a17090341c100b0019cd5508cd4mr7222579ple.7.1677664677433; Wed, 01 Mar 2023 01:57:57 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1677664677; cv=none; d=google.com; s=arc-20160816; b=Ji8/DX9LpyFgYXjoQC0cDEcfZkZC/6iKxCD+0ZG3VQKNYQFYfPUyRbTdgUHFnUoRpH lJRuM9cHVbf1JVaBJmlG3/za913JGPzF7spbTSO9KgZ0e21mpvPWzyKBwVDg94sHMsJo 4+NbeBPofV5z4ZfpqF7kRz5jgtOQzb3bs0Edp+9jNvtnvzsKakyXcYvfQ04oIFxxaBZD pGfQRTX6QnAU7VQxkzz4yJaTuktErn6VS95XITBcXQaMAIADX0NfctgXwP1Nz8BAaFRc l6Dh1MjL+xPhA8yr2hes2N9SqxoSkvquPqKd2/UH1dPyaDbKhbyKjF/JoCXpwHWEuD3D 1t3w== 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 :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=IPeLzAnu40OEFmsm2TUZHRD4OK6i1lIc44dZlRVz8I4=; b=A5sxZo+Q6fADmSjgPm/mo1gGh7MCbHbAkinndoIlGfX9eUnHXy0dx+90exnQ/xtACq 4lavOZi9T1X4sijhCPFnux70fIHzV95Aq8/dzYKr3Sk/8H2lnkBOJAwr5Eun0q5aePCP voUEG6fbtxR/5m82UUJBP1+Aetv/1dIkVulfNFBtrAv2Jn+T1T7S/6UK/hrIG27XvhLh EFm+oz68c7RbFAKAiohBluY3myXc8UcGcFpQ9AWnIFCEDjLw7zqsNAV0VaFkI5qhUs+z tIVRD9rmS66YkIIyhhv0zhs/y52zO6lFbEDA/dUdcX0p3TZutkLpodvQlimGVJ3/Wnfv 3NXw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@collabora.com header.s=mail header.b=LNy8CnbO; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 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 (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id kk16-20020a170903071000b0019cb7dade21si11220222plb.219.2023.03.01.01.57.43; Wed, 01 Mar 2023 01:57:57 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@collabora.com header.s=mail header.b=LNy8CnbO; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=collabora.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229945AbjCAJ4R (ORCPT <rfc822;dipsyhu@gmail.com> + 99 others); Wed, 1 Mar 2023 04:56:17 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40972 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229896AbjCAJzj (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 1 Mar 2023 04:55:39 -0500 Received: from madras.collabora.co.uk (madras.collabora.co.uk [46.235.227.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9ADCC34F62; Wed, 1 Mar 2023 01:55:38 -0800 (PST) Received: from IcarusMOD.eternityproject.eu (2-237-20-237.ip236.fastwebnet.it [2.237.20.237]) (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: kholk11) by madras.collabora.co.uk (Postfix) with ESMTPSA id D050D660211B; Wed, 1 Mar 2023 09:55:36 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1677664537; bh=co4SeDmQzj4uU8aYQJsjemsonD8P7POUOi2D/TyJicQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=LNy8CnbOZxIoaSG9lOwDELZPZvwSOFF6ZoXE3St0Hjhbs1dq9GP2Vr9Ux4rfjgDDA c98a5Ml4ioX3aLdmuVF37c/VCxRt+/7GDBFM/Dj21pdh6dxvtdl+kKPCbKpCuLg1R8 3FQO3RGxwc3Zffx7q+wNLT8y7ajTGd6hHOXWGxCmDd2sYyxjkJ9GiNlt8jgdnJpbXM 2MDpGwx2YrkdLz6w8ibZ1vkQ2Ttg4Nv5B+h0PkTIbdaMXMSLdNwhcrB1niGm5IRuo4 5IbCQ8+tDH8EusEPQclRv9ytqM1Wt98Rnf/H0jlDjomO7qpGUyU3NQCGFYD7G+6Mzy zBPcCtltPv/SA== From: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> To: matthias.bgg@gmail.com Cc: robh+dt@kernel.org, krzysztof.kozlowski+dt@linaro.org, angelogioacchino.delregno@collabora.com, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, wenst@chromium.org Subject: [PATCH v4 12/19] arm64: dts: mediatek: mt8192-asurada: Couple VGPU and VSRAM_OTHER regulators Date: Wed, 1 Mar 2023 10:55:16 +0100 Message-Id: <20230301095523.428461-13-angelogioacchino.delregno@collabora.com> X-Mailer: git-send-email 2.39.2 In-Reply-To: <20230301095523.428461-1-angelogioacchino.delregno@collabora.com> References: <20230301095523.428461-1-angelogioacchino.delregno@collabora.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1759158916968198940?= X-GMAIL-MSGID: =?utf-8?q?1759158916968198940?= |
Series |
Enable GPU with DVFS support on MediaTek SoCs
|
|
Commit Message
AngeloGioacchino Del Regno
March 1, 2023, 9:55 a.m. UTC
Add coupling for these regulators, as VSRAM_OTHER is used to power the
GPU SRAM, and they have a strict voltage output relation to satisfy in
order to ensure GPU stable operation.
While at it, also add voltage constraint overrides for the GPU SRAM
regulator "mt6359_vsram_others" so that we stay in a safe range of
0.75-0.80V.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
---
arch/arm64/boot/dts/mediatek/mt8192-asurada.dtsi | 9 +++++++++
1 file changed, 9 insertions(+)
Comments
On Wed, Mar 1, 2023 at 5:55 PM AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> wrote: > > Add coupling for these regulators, as VSRAM_OTHER is used to power the > GPU SRAM, and they have a strict voltage output relation to satisfy in > order to ensure GPU stable operation. > While at it, also add voltage constraint overrides for the GPU SRAM > regulator "mt6359_vsram_others" so that we stay in a safe range of > 0.75-0.80V. > > Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> > --- > arch/arm64/boot/dts/mediatek/mt8192-asurada.dtsi | 9 +++++++++ > 1 file changed, 9 insertions(+) > > diff --git a/arch/arm64/boot/dts/mediatek/mt8192-asurada.dtsi b/arch/arm64/boot/dts/mediatek/mt8192-asurada.dtsi > index 8570b78c04a4..f858eca219d7 100644 > --- a/arch/arm64/boot/dts/mediatek/mt8192-asurada.dtsi > +++ b/arch/arm64/boot/dts/mediatek/mt8192-asurada.dtsi > @@ -447,6 +447,13 @@ &mt6359_vrf12_ldo_reg { > regulator-always-on; > }; > > +&mt6359_vsram_others_ldo_reg { > + regulator-min-microvolt = <750000>; > + regulator-max-microvolt = <800000>; > + regulator-coupled-with = <&mt6315_7_vbuck1>; > + regulator-coupled-max-spread = <10000>; Looking again at the downstream OPP table, it seems there's no voltage difference requirement. It only needs V_SRAM >= V_GPU. Same applies to MT8195. Looks like only MT8183 and MT8186 need V_SRAM - V_GPU >= 10000. Would setting max-spread to 0 work? I ask because with both regulator's maximum voltage set to 0.8V, there's no way we can reach the highest OPP. ChenYu > +}; > + > &mt6359_vufs_ldo_reg { > regulator-always-on; > }; > @@ -1411,6 +1418,8 @@ mt6315_7_vbuck1: vbuck1 { > regulator-max-microvolt = <800000>; > regulator-enable-ramp-delay = <256>; > regulator-allowed-modes = <0 1 2>; > + regulator-coupled-with = <&mt6359_vsram_others_ldo_reg>; > + regulator-coupled-max-spread = <10000>; > }; > }; > }; > -- > 2.39.2 >
Il 02/03/23 11:03, Chen-Yu Tsai ha scritto: > On Wed, Mar 1, 2023 at 5:55 PM AngeloGioacchino Del Regno > <angelogioacchino.delregno@collabora.com> wrote: >> >> Add coupling for these regulators, as VSRAM_OTHER is used to power the >> GPU SRAM, and they have a strict voltage output relation to satisfy in >> order to ensure GPU stable operation. >> While at it, also add voltage constraint overrides for the GPU SRAM >> regulator "mt6359_vsram_others" so that we stay in a safe range of >> 0.75-0.80V. >> >> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> >> --- >> arch/arm64/boot/dts/mediatek/mt8192-asurada.dtsi | 9 +++++++++ >> 1 file changed, 9 insertions(+) >> >> diff --git a/arch/arm64/boot/dts/mediatek/mt8192-asurada.dtsi b/arch/arm64/boot/dts/mediatek/mt8192-asurada.dtsi >> index 8570b78c04a4..f858eca219d7 100644 >> --- a/arch/arm64/boot/dts/mediatek/mt8192-asurada.dtsi >> +++ b/arch/arm64/boot/dts/mediatek/mt8192-asurada.dtsi >> @@ -447,6 +447,13 @@ &mt6359_vrf12_ldo_reg { >> regulator-always-on; >> }; >> >> +&mt6359_vsram_others_ldo_reg { >> + regulator-min-microvolt = <750000>; >> + regulator-max-microvolt = <800000>; >> + regulator-coupled-with = <&mt6315_7_vbuck1>; >> + regulator-coupled-max-spread = <10000>; > > Looking again at the downstream OPP table, it seems there's no voltage > difference requirement. It only needs V_SRAM >= V_GPU. Same applies to > MT8195. Looks like only MT8183 and MT8186 need V_SRAM - V_GPU >= 10000. On MT8195 we don't need any regulator coupling. There, the GPU-SRAM voltage is fixed at .. I don't remember, 0.7V? - anyway - MT8195 doesn't need to scale the vsram. > > Would setting max-spread to 0 work? I ask because with both regulator's > maximum voltage set to 0.8V, there's no way we can reach the highest > OPP. > No that doesn't work. I can raise the Vgpu max voltage to 0.88V to solve the issue right here and right now, or we can leave it like that and revisit it later. I would at this point go for setting mt6315_7_vbuck1's max-microvolt to 880000, as this is the maximum recommended voltage for the GPU as per the MT8192 datasheet, it would also make sense as we would be still describing the hardware in a correct manner. What do you think? Angelo > ChenYu > > >> +}; >> + >> &mt6359_vufs_ldo_reg { >> regulator-always-on; >> }; >> @@ -1411,6 +1418,8 @@ mt6315_7_vbuck1: vbuck1 { >> regulator-max-microvolt = <800000>; >> regulator-enable-ramp-delay = <256>; >> regulator-allowed-modes = <0 1 2>; >> + regulator-coupled-with = <&mt6359_vsram_others_ldo_reg>; >> + regulator-coupled-max-spread = <10000>; >> }; >> }; >> }; >> -- >> 2.39.2 >>
On Thu, Mar 2, 2023 at 6:17 PM AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> wrote: > > Il 02/03/23 11:03, Chen-Yu Tsai ha scritto: > > On Wed, Mar 1, 2023 at 5:55 PM AngeloGioacchino Del Regno > > <angelogioacchino.delregno@collabora.com> wrote: > >> > >> Add coupling for these regulators, as VSRAM_OTHER is used to power the > >> GPU SRAM, and they have a strict voltage output relation to satisfy in > >> order to ensure GPU stable operation. > >> While at it, also add voltage constraint overrides for the GPU SRAM > >> regulator "mt6359_vsram_others" so that we stay in a safe range of > >> 0.75-0.80V. > >> > >> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> > >> --- > >> arch/arm64/boot/dts/mediatek/mt8192-asurada.dtsi | 9 +++++++++ > >> 1 file changed, 9 insertions(+) > >> > >> diff --git a/arch/arm64/boot/dts/mediatek/mt8192-asurada.dtsi b/arch/arm64/boot/dts/mediatek/mt8192-asurada.dtsi > >> index 8570b78c04a4..f858eca219d7 100644 > >> --- a/arch/arm64/boot/dts/mediatek/mt8192-asurada.dtsi > >> +++ b/arch/arm64/boot/dts/mediatek/mt8192-asurada.dtsi > >> @@ -447,6 +447,13 @@ &mt6359_vrf12_ldo_reg { > >> regulator-always-on; > >> }; > >> > >> +&mt6359_vsram_others_ldo_reg { > >> + regulator-min-microvolt = <750000>; > >> + regulator-max-microvolt = <800000>; > >> + regulator-coupled-with = <&mt6315_7_vbuck1>; > >> + regulator-coupled-max-spread = <10000>; > > > > Looking again at the downstream OPP table, it seems there's no voltage > > difference requirement. It only needs V_SRAM >= V_GPU. Same applies to > > MT8195. Looks like only MT8183 and MT8186 need V_SRAM - V_GPU >= 10000. > > On MT8195 we don't need any regulator coupling. There, the GPU-SRAM voltage > is fixed at .. I don't remember, 0.7V? - anyway - MT8195 doesn't need to > scale the vsram. Looks like it's fixed at 0.75V. I guess we're Ok on MT8195. > > > > Would setting max-spread to 0 work? I ask because with both regulator's > > maximum voltage set to 0.8V, there's no way we can reach the highest > > OPP. > > > > No that doesn't work. I can raise the Vgpu max voltage to 0.88V to solve the > issue right here and right now, or we can leave it like that and revisit it > later. > > I would at this point go for setting mt6315_7_vbuck1's max-microvolt to > 880000, as this is the maximum recommended voltage for the GPU as per the > MT8192 datasheet, it would also make sense as we would be still describing > the hardware in a correct manner. > > What do you think? If it's just to accommodate the coupler stuff, I say just set the maximum at the lowest possible setting that satisfies the coupler constraint and granularity of the regulator. The regulator does 6250 uV steps, so I guess we could set the maximum at 812500 uV, with a comment stating the nominal voltage of 800000 uV and that the extra 12500 uV is to workaround coupler limitations. Does that sound OK? ChenYu
On Fri, Mar 3, 2023 at 12:09 PM Chen-Yu Tsai <wenst@chromium.org> wrote: > > On Thu, Mar 2, 2023 at 6:17 PM AngeloGioacchino Del Regno > <angelogioacchino.delregno@collabora.com> wrote: > > > > Il 02/03/23 11:03, Chen-Yu Tsai ha scritto: > > > On Wed, Mar 1, 2023 at 5:55 PM AngeloGioacchino Del Regno > > > <angelogioacchino.delregno@collabora.com> wrote: > > >> > > >> Add coupling for these regulators, as VSRAM_OTHER is used to power the > > >> GPU SRAM, and they have a strict voltage output relation to satisfy in > > >> order to ensure GPU stable operation. > > >> While at it, also add voltage constraint overrides for the GPU SRAM > > >> regulator "mt6359_vsram_others" so that we stay in a safe range of > > >> 0.75-0.80V. > > >> > > >> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> > > >> --- > > >> arch/arm64/boot/dts/mediatek/mt8192-asurada.dtsi | 9 +++++++++ > > >> 1 file changed, 9 insertions(+) > > >> > > >> diff --git a/arch/arm64/boot/dts/mediatek/mt8192-asurada.dtsi b/arch/arm64/boot/dts/mediatek/mt8192-asurada.dtsi > > >> index 8570b78c04a4..f858eca219d7 100644 > > >> --- a/arch/arm64/boot/dts/mediatek/mt8192-asurada.dtsi > > >> +++ b/arch/arm64/boot/dts/mediatek/mt8192-asurada.dtsi > > >> @@ -447,6 +447,13 @@ &mt6359_vrf12_ldo_reg { > > >> regulator-always-on; > > >> }; > > >> > > >> +&mt6359_vsram_others_ldo_reg { > > >> + regulator-min-microvolt = <750000>; > > >> + regulator-max-microvolt = <800000>; > > >> + regulator-coupled-with = <&mt6315_7_vbuck1>; > > >> + regulator-coupled-max-spread = <10000>; > > > > > > Looking again at the downstream OPP table, it seems there's no voltage > > > difference requirement. It only needs V_SRAM >= V_GPU. Same applies to > > > MT8195. Looks like only MT8183 and MT8186 need V_SRAM - V_GPU >= 10000. > > > > On MT8195 we don't need any regulator coupling. There, the GPU-SRAM voltage > > is fixed at .. I don't remember, 0.7V? - anyway - MT8195 doesn't need to > > scale the vsram. > > Looks like it's fixed at 0.75V. I guess we're Ok on MT8195. > > > > > > > Would setting max-spread to 0 work? I ask because with both regulator's > > > maximum voltage set to 0.8V, there's no way we can reach the highest > > > OPP. > > > > > > > No that doesn't work. I can raise the Vgpu max voltage to 0.88V to solve the > > issue right here and right now, or we can leave it like that and revisit it > > later. > > > > I would at this point go for setting mt6315_7_vbuck1's max-microvolt to > > 880000, as this is the maximum recommended voltage for the GPU as per the > > MT8192 datasheet, it would also make sense as we would be still describing > > the hardware in a correct manner. > > > > What do you think? > > If it's just to accommodate the coupler stuff, I say just set the maximum > at the lowest possible setting that satisfies the coupler constraint and > granularity of the regulator. The regulator does 6250 uV steps, so I guess > we could set the maximum at 812500 uV, with a comment stating the nominal > voltage of 800000 uV and that the extra 12500 uV is to workaround coupler > limitations. > > Does that sound OK? Even without changing anything, the coupler seems to work OK: vsram_others 1 1 0 normal 800mV 0mA 750mV 800mV 10006000.syscon:power-controller-domain 1 0mA 0mV 0mV Vgpu 2 2 0 normal 800mV 0mA 606mV 800mV 13000000.gpu-mali 1 0mA 800mV 800mV 10006000.syscon:power-controller-domain 1 0mA 0mV 0mV Am I missing something? ChenYu
Il 07/03/23 10:24, Chen-Yu Tsai ha scritto: > On Fri, Mar 3, 2023 at 12:09 PM Chen-Yu Tsai <wenst@chromium.org> wrote: >> >> On Thu, Mar 2, 2023 at 6:17 PM AngeloGioacchino Del Regno >> <angelogioacchino.delregno@collabora.com> wrote: >>> >>> Il 02/03/23 11:03, Chen-Yu Tsai ha scritto: >>>> On Wed, Mar 1, 2023 at 5:55 PM AngeloGioacchino Del Regno >>>> <angelogioacchino.delregno@collabora.com> wrote: >>>>> >>>>> Add coupling for these regulators, as VSRAM_OTHER is used to power the >>>>> GPU SRAM, and they have a strict voltage output relation to satisfy in >>>>> order to ensure GPU stable operation. >>>>> While at it, also add voltage constraint overrides for the GPU SRAM >>>>> regulator "mt6359_vsram_others" so that we stay in a safe range of >>>>> 0.75-0.80V. >>>>> >>>>> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> >>>>> --- >>>>> arch/arm64/boot/dts/mediatek/mt8192-asurada.dtsi | 9 +++++++++ >>>>> 1 file changed, 9 insertions(+) >>>>> >>>>> diff --git a/arch/arm64/boot/dts/mediatek/mt8192-asurada.dtsi b/arch/arm64/boot/dts/mediatek/mt8192-asurada.dtsi >>>>> index 8570b78c04a4..f858eca219d7 100644 >>>>> --- a/arch/arm64/boot/dts/mediatek/mt8192-asurada.dtsi >>>>> +++ b/arch/arm64/boot/dts/mediatek/mt8192-asurada.dtsi >>>>> @@ -447,6 +447,13 @@ &mt6359_vrf12_ldo_reg { >>>>> regulator-always-on; >>>>> }; >>>>> >>>>> +&mt6359_vsram_others_ldo_reg { >>>>> + regulator-min-microvolt = <750000>; >>>>> + regulator-max-microvolt = <800000>; >>>>> + regulator-coupled-with = <&mt6315_7_vbuck1>; >>>>> + regulator-coupled-max-spread = <10000>; >>>> >>>> Looking again at the downstream OPP table, it seems there's no voltage >>>> difference requirement. It only needs V_SRAM >= V_GPU. Same applies to >>>> MT8195. Looks like only MT8183 and MT8186 need V_SRAM - V_GPU >= 10000. >>> >>> On MT8195 we don't need any regulator coupling. There, the GPU-SRAM voltage >>> is fixed at .. I don't remember, 0.7V? - anyway - MT8195 doesn't need to >>> scale the vsram. >> >> Looks like it's fixed at 0.75V. I guess we're Ok on MT8195. >> >>>> >>>> Would setting max-spread to 0 work? I ask because with both regulator's >>>> maximum voltage set to 0.8V, there's no way we can reach the highest >>>> OPP. >>>> >>> >>> No that doesn't work. I can raise the Vgpu max voltage to 0.88V to solve the >>> issue right here and right now, or we can leave it like that and revisit it >>> later. >>> >>> I would at this point go for setting mt6315_7_vbuck1's max-microvolt to >>> 880000, as this is the maximum recommended voltage for the GPU as per the >>> MT8192 datasheet, it would also make sense as we would be still describing >>> the hardware in a correct manner. >>> >>> What do you think? >> >> If it's just to accommodate the coupler stuff, I say just set the maximum >> at the lowest possible setting that satisfies the coupler constraint and >> granularity of the regulator. The regulator does 6250 uV steps, so I guess >> we could set the maximum at 812500 uV, with a comment stating the nominal >> voltage of 800000 uV and that the extra 12500 uV is to workaround coupler >> limitations. >> >> Does that sound OK? > > Even without changing anything, the coupler seems to work OK: > > vsram_others 1 1 0 normal 800mV > 0mA 750mV 800mV > 10006000.syscon:power-controller-domain 1 > 0mA 0mV 0mV > Vgpu 2 2 0 normal 800mV > 0mA 606mV 800mV > 13000000.gpu-mali 1 > 0mA 800mV 800mV > 10006000.syscon:power-controller-domain 1 > 0mA 0mV 0mV > > Am I missing something? > I don't think you are... I may be getting confused by all of the changesets that I'm pushing at once. Hence, is this commit fine as it is? Regards, Angelo
On Tue, Mar 7, 2023 at 5:30 PM AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> wrote: > > Il 07/03/23 10:24, Chen-Yu Tsai ha scritto: > > On Fri, Mar 3, 2023 at 12:09 PM Chen-Yu Tsai <wenst@chromium.org> wrote: > >> > >> On Thu, Mar 2, 2023 at 6:17 PM AngeloGioacchino Del Regno > >> <angelogioacchino.delregno@collabora.com> wrote: > >>> > >>> Il 02/03/23 11:03, Chen-Yu Tsai ha scritto: > >>>> On Wed, Mar 1, 2023 at 5:55 PM AngeloGioacchino Del Regno > >>>> <angelogioacchino.delregno@collabora.com> wrote: > >>>>> > >>>>> Add coupling for these regulators, as VSRAM_OTHER is used to power the > >>>>> GPU SRAM, and they have a strict voltage output relation to satisfy in > >>>>> order to ensure GPU stable operation. > >>>>> While at it, also add voltage constraint overrides for the GPU SRAM > >>>>> regulator "mt6359_vsram_others" so that we stay in a safe range of > >>>>> 0.75-0.80V. > >>>>> > >>>>> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> > >>>>> --- > >>>>> arch/arm64/boot/dts/mediatek/mt8192-asurada.dtsi | 9 +++++++++ > >>>>> 1 file changed, 9 insertions(+) > >>>>> > >>>>> diff --git a/arch/arm64/boot/dts/mediatek/mt8192-asurada.dtsi b/arch/arm64/boot/dts/mediatek/mt8192-asurada.dtsi > >>>>> index 8570b78c04a4..f858eca219d7 100644 > >>>>> --- a/arch/arm64/boot/dts/mediatek/mt8192-asurada.dtsi > >>>>> +++ b/arch/arm64/boot/dts/mediatek/mt8192-asurada.dtsi > >>>>> @@ -447,6 +447,13 @@ &mt6359_vrf12_ldo_reg { > >>>>> regulator-always-on; > >>>>> }; > >>>>> > >>>>> +&mt6359_vsram_others_ldo_reg { > >>>>> + regulator-min-microvolt = <750000>; > >>>>> + regulator-max-microvolt = <800000>; > >>>>> + regulator-coupled-with = <&mt6315_7_vbuck1>; > >>>>> + regulator-coupled-max-spread = <10000>; > >>>> > >>>> Looking again at the downstream OPP table, it seems there's no voltage > >>>> difference requirement. It only needs V_SRAM >= V_GPU. Same applies to > >>>> MT8195. Looks like only MT8183 and MT8186 need V_SRAM - V_GPU >= 10000. > >>> > >>> On MT8195 we don't need any regulator coupling. There, the GPU-SRAM voltage > >>> is fixed at .. I don't remember, 0.7V? - anyway - MT8195 doesn't need to > >>> scale the vsram. > >> > >> Looks like it's fixed at 0.75V. I guess we're Ok on MT8195. > >> > >>>> > >>>> Would setting max-spread to 0 work? I ask because with both regulator's > >>>> maximum voltage set to 0.8V, there's no way we can reach the highest > >>>> OPP. > >>>> > >>> > >>> No that doesn't work. I can raise the Vgpu max voltage to 0.88V to solve the > >>> issue right here and right now, or we can leave it like that and revisit it > >>> later. > >>> > >>> I would at this point go for setting mt6315_7_vbuck1's max-microvolt to > >>> 880000, as this is the maximum recommended voltage for the GPU as per the > >>> MT8192 datasheet, it would also make sense as we would be still describing > >>> the hardware in a correct manner. > >>> > >>> What do you think? > >> > >> If it's just to accommodate the coupler stuff, I say just set the maximum > >> at the lowest possible setting that satisfies the coupler constraint and > >> granularity of the regulator. The regulator does 6250 uV steps, so I guess > >> we could set the maximum at 812500 uV, with a comment stating the nominal > >> voltage of 800000 uV and that the extra 12500 uV is to workaround coupler > >> limitations. > >> > >> Does that sound OK? > > > > Even without changing anything, the coupler seems to work OK: > > > > vsram_others 1 1 0 normal 800mV > > 0mA 750mV 800mV > > 10006000.syscon:power-controller-domain 1 > > 0mA 0mV 0mV > > Vgpu 2 2 0 normal 800mV > > 0mA 606mV 800mV > > 13000000.gpu-mali 1 > > 0mA 800mV 800mV > > 10006000.syscon:power-controller-domain 1 > > 0mA 0mV 0mV > > > > Am I missing something? > > > > I don't think you are... I may be getting confused by all of the changesets > that I'm pushing at once. > > Hence, is this commit fine as it is? It works for some reason. Maybe it's a bug in the coupler. Either way I think it works, even though the numbers might be a bit off. We can revisit it later. Reviewed-by: Chen-Yu Tsai <wenst@chromium.org>
Il 07/03/23 10:44, Chen-Yu Tsai ha scritto: > On Tue, Mar 7, 2023 at 5:30 PM AngeloGioacchino Del Regno > <angelogioacchino.delregno@collabora.com> wrote: >> >> Il 07/03/23 10:24, Chen-Yu Tsai ha scritto: >>> On Fri, Mar 3, 2023 at 12:09 PM Chen-Yu Tsai <wenst@chromium.org> wrote: >>>> >>>> On Thu, Mar 2, 2023 at 6:17 PM AngeloGioacchino Del Regno >>>> <angelogioacchino.delregno@collabora.com> wrote: >>>>> >>>>> Il 02/03/23 11:03, Chen-Yu Tsai ha scritto: >>>>>> On Wed, Mar 1, 2023 at 5:55 PM AngeloGioacchino Del Regno >>>>>> <angelogioacchino.delregno@collabora.com> wrote: >>>>>>> >>>>>>> Add coupling for these regulators, as VSRAM_OTHER is used to power the >>>>>>> GPU SRAM, and they have a strict voltage output relation to satisfy in >>>>>>> order to ensure GPU stable operation. >>>>>>> While at it, also add voltage constraint overrides for the GPU SRAM >>>>>>> regulator "mt6359_vsram_others" so that we stay in a safe range of >>>>>>> 0.75-0.80V. >>>>>>> >>>>>>> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> >>>>>>> --- >>>>>>> arch/arm64/boot/dts/mediatek/mt8192-asurada.dtsi | 9 +++++++++ >>>>>>> 1 file changed, 9 insertions(+) >>>>>>> >>>>>>> diff --git a/arch/arm64/boot/dts/mediatek/mt8192-asurada.dtsi b/arch/arm64/boot/dts/mediatek/mt8192-asurada.dtsi >>>>>>> index 8570b78c04a4..f858eca219d7 100644 >>>>>>> --- a/arch/arm64/boot/dts/mediatek/mt8192-asurada.dtsi >>>>>>> +++ b/arch/arm64/boot/dts/mediatek/mt8192-asurada.dtsi >>>>>>> @@ -447,6 +447,13 @@ &mt6359_vrf12_ldo_reg { >>>>>>> regulator-always-on; >>>>>>> }; >>>>>>> >>>>>>> +&mt6359_vsram_others_ldo_reg { >>>>>>> + regulator-min-microvolt = <750000>; >>>>>>> + regulator-max-microvolt = <800000>; >>>>>>> + regulator-coupled-with = <&mt6315_7_vbuck1>; >>>>>>> + regulator-coupled-max-spread = <10000>; >>>>>> >>>>>> Looking again at the downstream OPP table, it seems there's no voltage >>>>>> difference requirement. It only needs V_SRAM >= V_GPU. Same applies to >>>>>> MT8195. Looks like only MT8183 and MT8186 need V_SRAM - V_GPU >= 10000. >>>>> >>>>> On MT8195 we don't need any regulator coupling. There, the GPU-SRAM voltage >>>>> is fixed at .. I don't remember, 0.7V? - anyway - MT8195 doesn't need to >>>>> scale the vsram. >>>> >>>> Looks like it's fixed at 0.75V. I guess we're Ok on MT8195. >>>> >>>>>> >>>>>> Would setting max-spread to 0 work? I ask because with both regulator's >>>>>> maximum voltage set to 0.8V, there's no way we can reach the highest >>>>>> OPP. >>>>>> >>>>> >>>>> No that doesn't work. I can raise the Vgpu max voltage to 0.88V to solve the >>>>> issue right here and right now, or we can leave it like that and revisit it >>>>> later. >>>>> >>>>> I would at this point go for setting mt6315_7_vbuck1's max-microvolt to >>>>> 880000, as this is the maximum recommended voltage for the GPU as per the >>>>> MT8192 datasheet, it would also make sense as we would be still describing >>>>> the hardware in a correct manner. >>>>> >>>>> What do you think? >>>> >>>> If it's just to accommodate the coupler stuff, I say just set the maximum >>>> at the lowest possible setting that satisfies the coupler constraint and >>>> granularity of the regulator. The regulator does 6250 uV steps, so I guess >>>> we could set the maximum at 812500 uV, with a comment stating the nominal >>>> voltage of 800000 uV and that the extra 12500 uV is to workaround coupler >>>> limitations. >>>> >>>> Does that sound OK? >>> >>> Even without changing anything, the coupler seems to work OK: >>> >>> vsram_others 1 1 0 normal 800mV >>> 0mA 750mV 800mV >>> 10006000.syscon:power-controller-domain 1 >>> 0mA 0mV 0mV >>> Vgpu 2 2 0 normal 800mV >>> 0mA 606mV 800mV >>> 13000000.gpu-mali 1 >>> 0mA 800mV 800mV >>> 10006000.syscon:power-controller-domain 1 >>> 0mA 0mV 0mV >>> >>> Am I missing something? >>> >> >> I don't think you are... I may be getting confused by all of the changesets >> that I'm pushing at once. >> >> Hence, is this commit fine as it is? > > It works for some reason. Maybe it's a bug in the coupler. Either way I > think it works, even though the numbers might be a bit off. We can revisit > it later. > > Reviewed-by: Chen-Yu Tsai <wenst@chromium.org> Thanks! Angelo
diff --git a/arch/arm64/boot/dts/mediatek/mt8192-asurada.dtsi b/arch/arm64/boot/dts/mediatek/mt8192-asurada.dtsi index 8570b78c04a4..f858eca219d7 100644 --- a/arch/arm64/boot/dts/mediatek/mt8192-asurada.dtsi +++ b/arch/arm64/boot/dts/mediatek/mt8192-asurada.dtsi @@ -447,6 +447,13 @@ &mt6359_vrf12_ldo_reg { regulator-always-on; }; +&mt6359_vsram_others_ldo_reg { + regulator-min-microvolt = <750000>; + regulator-max-microvolt = <800000>; + regulator-coupled-with = <&mt6315_7_vbuck1>; + regulator-coupled-max-spread = <10000>; +}; + &mt6359_vufs_ldo_reg { regulator-always-on; }; @@ -1411,6 +1418,8 @@ mt6315_7_vbuck1: vbuck1 { regulator-max-microvolt = <800000>; regulator-enable-ramp-delay = <256>; regulator-allowed-modes = <0 1 2>; + regulator-coupled-with = <&mt6359_vsram_others_ldo_reg>; + regulator-coupled-max-spread = <10000>; }; }; };