Message ID | 20230717-topic-branch_aon_cleanup-v1-15-27784d27a4f4@linaro.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:c923:0:b0:3e4:2afc:c1 with SMTP id j3csp1181719vqt; Mon, 17 Jul 2023 08:28:57 -0700 (PDT) X-Google-Smtp-Source: APBJJlG1g0vvTPkqo0zO9rb7LNVRJbWnEQsk4AyBDsZG8RwCqnSDQZ2C+PKzAfx19UAFNLLKV1On X-Received: by 2002:a2e:3606:0:b0:2b6:eb5a:d377 with SMTP id d6-20020a2e3606000000b002b6eb5ad377mr8859762lja.5.1689607736976; Mon, 17 Jul 2023 08:28:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1689607736; cv=none; d=google.com; s=arc-20160816; b=lGqk3SGuCiSljK3yrfNckvZxUVzDflbHmW4RrCnfTu8fkEhfnPedIb1S2bsy4GWovq ngzDabqckuT4b3D75e8USSvmGTsm61jt7vwSnA50iAY7bFUtTLbuR5vSsRZp4XcYrfLS 7INNH/n9/oMvQ/jgv7p1N6Luyb8LaN+W2dDuCJElYTWRmrloWja9OFxo7xFn+s58LvuU 98XUWcIKPN6B8p3ALp8ZWH6Y0hCq2vZ7iIPjgQGOhbhFXx4f/wmwGvba/x1kKOf4vkYu qggf0uzuhiKp0xJCKaZmk1OiiU/b4ghVOquKQ8zExN1AEGUJYW7raP6dB0OS5ipdia8Z +xPQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:in-reply-to:references:message-id :content-transfer-encoding:mime-version:subject:date:from :dkim-signature; bh=6ucP2HxOwgP4Yjc3Q8ZZBgQ8j1uIc3OmiWC7cbRp7SQ=; fh=E58dWdTK3D0DoIKuSZYoE/gJoipBIXlqiTk01lLVuRg=; b=xSUkz1hjs1RpaXb6rkviVS0m615zoIC1xxvrtXkfuwTeu0RmGSkq0z4BUoUjV5Z5fV PhGbw8e43VYeKaGw5HqCRCY8J2RinsSmBefFJcHxyp/QkActIzqjW6alIjp++XJACaPz 7RacFInUGYs5Gom2u8rSyLSe8Wv02wr+7qPBoNjuFczB45Y0WGkFvxbbi829h0SmIW3L Av7IWR/JQu5HgJvos/lQ+OgL83WWj1a1fiRmFjgItnWATZcyC1EgwnJvU5J/a5pBr5rM 2MPUGfZ9kqFyEphRl1Ww+9QyVodc7nm14ZBOfOKnaHveumjz26sHtq7rF1iAXzZv7QxL Zgdg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=aAsyFds6; 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=NONE sp=NONE dis=NONE) header.from=linaro.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id c26-20020a170906529a00b0098296d092ffsi13709972ejm.330.2023.07.17.08.28.32; Mon, 17 Jul 2023 08:28:56 -0700 (PDT) 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=@linaro.org header.s=google header.b=aAsyFds6; 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=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231486AbjGQPUr (ORCPT <rfc822;hadasmailinglist@gmail.com> + 99 others); Mon, 17 Jul 2023 11:20:47 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51638 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229779AbjGQPUe (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 17 Jul 2023 11:20:34 -0400 Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 35F1226BE for <linux-kernel@vger.kernel.org>; Mon, 17 Jul 2023 08:19:55 -0700 (PDT) Received: by mail-lf1-x134.google.com with SMTP id 2adb3069b0e04-4fa48b5dc2eso7448291e87.1 for <linux-kernel@vger.kernel.org>; Mon, 17 Jul 2023 08:19:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1689607172; x=1692199172; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :mime-version:subject:date:from:from:to:cc:subject:date:message-id :reply-to; bh=6ucP2HxOwgP4Yjc3Q8ZZBgQ8j1uIc3OmiWC7cbRp7SQ=; b=aAsyFds6D3PMJEXo1mRw7yaSFEFyCwzpw8bc7QERWt12x+GbYXficzoCDkDyBo7h4Z 62Z6Rxu+5TMH3EeAAlv60yIOJkKs1lSTWu6iBieEmkUsquuIa11nMNQdHG1kcNXk6Jml vJ3dObu5l1Rzkk8/4WSFhvQI/+4XhyexGyeCk2bUjkLEU5rjBwlHMcklMQfaStrCnlHC 0xORplVjcyGhMZq87BeArmLClMW1oKgWZH6VyMbA1rowzdSZMO1VTIDvtjbCAqA2QdlV Wng487nS0xowQ1eGL8UF+0LXKbfRkU6VVCeJzJxiPeyy1m56qprgDRFCfjNPyi5WNzZ/ iDAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689607172; x=1692199172; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :mime-version:subject:date:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=6ucP2HxOwgP4Yjc3Q8ZZBgQ8j1uIc3OmiWC7cbRp7SQ=; b=KxO1qoWZgpgPHMfyWtEoHoRXZAVMtfk+dYjnxQjupbQLnAv0Hr/oDx4nyf3m3eFM5u 5h1ifpaGJJM8KC3GrF98ni2u13LzqpB9XFGzvoGtAWxkvLfKVA2zD2mDm2FNLzg0rd4K nrCWwtXHNliGavsD8RPyWx81UHOt3EpGG7w96Bwn9mtKJrrS4RgTQmOFmFnCKa4cFQFs J+ZihYUuc0bnuhQUhYAEeuXAP+SxfOJv+cdNUJYXXEFanrIPUCRivMnSFucq0ls2OvG3 rcrRP/qeGKLxBAUZGhRDE7DLgpvhxmCDx6NvW+23wk+5S5VoGx2sRo4WVyFcoG3Lxg52 KqHQ== X-Gm-Message-State: ABy/qLZE5c98+HMGuNR7cvodOTIUCPW1bRzqPQlrlyE4QV+YR5NA8MaD TQ516Ir8V7yCzjx+GciGkpTXJw== X-Received: by 2002:a05:6512:3121:b0:4f8:6533:3341 with SMTP id p1-20020a056512312100b004f865333341mr8483185lfd.20.1689607172501; Mon, 17 Jul 2023 08:19:32 -0700 (PDT) Received: from [192.168.1.101] (abyj181.neoplus.adsl.tpnet.pl. [83.9.29.181]) by smtp.gmail.com with ESMTPSA id z7-20020ac24187000000b004f26d63f823sm2873949lfh.237.2023.07.17.08.19.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 17 Jul 2023 08:19:32 -0700 (PDT) From: Konrad Dybcio <konrad.dybcio@linaro.org> Date: Mon, 17 Jul 2023 17:19:22 +0200 Subject: [PATCH 15/15] arm64: dts: qcom: sm6115: Add VDD_CX to GPU_CCC MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20230717-topic-branch_aon_cleanup-v1-15-27784d27a4f4@linaro.org> References: <20230717-topic-branch_aon_cleanup-v1-0-27784d27a4f4@linaro.org> In-Reply-To: <20230717-topic-branch_aon_cleanup-v1-0-27784d27a4f4@linaro.org> To: Bjorn Andersson <andersson@kernel.org>, Andy Gross <agross@kernel.org>, Michael Turquette <mturquette@baylibre.com>, Stephen Boyd <sboyd@kernel.org>, Rob Herring <robh+dt@kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Conor Dooley <conor+dt@kernel.org> Cc: Marijn Suijten <marijn.suijten@somainline.org>, linux-arm-msm@vger.kernel.org, linux-clk@vger.kernel.org, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, Konrad Dybcio <konrad.dybcio@linaro.org> X-Mailer: b4 0.12.2 X-Developer-Signature: v=1; a=ed25519-sha256; t=1689607149; l=782; i=konrad.dybcio@linaro.org; s=20230215; h=from:subject:message-id; bh=KUdFQ1vDlHA4ohS8EU78+JEQV/TntyZtIcOU/vB61S4=; b=PXU+1NIif1o8q606ns3V3Z9OE4O7LZWnqOhTWMcpM/+BblfkOHNE3GpDoGEyTgvH3VTTUBZrq TubYMkT6OmRDcWp5p4Sj2bY+QorleRofBFq1lfUNCd7lsYo875iG8b+ X-Developer-Key: i=konrad.dybcio@linaro.org; a=ed25519; pk=iclgkYvtl2w05SSXO5EjjSYlhFKsJ+5OSZBjOkQuEms= X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, 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 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: INBOX X-GMAIL-THRID: 1771682122626790815 X-GMAIL-MSGID: 1771682122626790815 |
Series |
Unregister critical branch clocks + some RPM
|
|
Commit Message
Konrad Dybcio
July 17, 2023, 3:19 p.m. UTC
The GPU_CC block is powered by VDD_CX. Describe that.
Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
---
arch/arm64/boot/dts/qcom/sm6115.dtsi | 2 ++
1 file changed, 2 insertions(+)
Comments
On Mon, Jul 17, 2023 at 05:19:22PM +0200, Konrad Dybcio wrote: > The GPU_CC block is powered by VDD_CX. Describe that. > > Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> > --- > arch/arm64/boot/dts/qcom/sm6115.dtsi | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/arch/arm64/boot/dts/qcom/sm6115.dtsi b/arch/arm64/boot/dts/qcom/sm6115.dtsi > index 29b5b388cd94..bfaaa1801a4d 100644 > --- a/arch/arm64/boot/dts/qcom/sm6115.dtsi > +++ b/arch/arm64/boot/dts/qcom/sm6115.dtsi > @@ -1430,6 +1430,8 @@ gpucc: clock-controller@5990000 { > clocks = <&rpmcc RPM_SMD_XO_CLK_SRC>, > <&gcc GCC_GPU_GPLL0_CLK_SRC>, > <&gcc GCC_GPU_GPLL0_DIV_CLK_SRC>; > + power-domains = <&rpmpd SM6115_VDDCX>; > + required-opps = <&rpmpd_opp_low_svs>; Where is this required-opp coming from? The clocks in gpucc seem to have different voltage requirements depending on the rates, but we usually handle that in the OPP tables of the consumer. Thanks, Stephan
On 17.07.2023 18:28, Stephan Gerhold wrote: > On Mon, Jul 17, 2023 at 05:19:22PM +0200, Konrad Dybcio wrote: >> The GPU_CC block is powered by VDD_CX. Describe that. >> >> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> >> --- >> arch/arm64/boot/dts/qcom/sm6115.dtsi | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/arch/arm64/boot/dts/qcom/sm6115.dtsi b/arch/arm64/boot/dts/qcom/sm6115.dtsi >> index 29b5b388cd94..bfaaa1801a4d 100644 >> --- a/arch/arm64/boot/dts/qcom/sm6115.dtsi >> +++ b/arch/arm64/boot/dts/qcom/sm6115.dtsi >> @@ -1430,6 +1430,8 @@ gpucc: clock-controller@5990000 { >> clocks = <&rpmcc RPM_SMD_XO_CLK_SRC>, >> <&gcc GCC_GPU_GPLL0_CLK_SRC>, >> <&gcc GCC_GPU_GPLL0_DIV_CLK_SRC>; >> + power-domains = <&rpmpd SM6115_VDDCX>; >> + required-opps = <&rpmpd_opp_low_svs>; > > Where is this required-opp coming from? The clocks in gpucc seem to have > different voltage requirements depending on the rates, but we usually > handle that in the OPP tables of the consumer. The only lower levels defined for this SoC are VDD_MIN and VDD_RET, but quite obviously the GPU won't work then Konrad > > Thanks, > Stephan
On Mon, Jul 17, 2023 at 06:50:18PM +0200, Konrad Dybcio wrote: > On 17.07.2023 18:28, Stephan Gerhold wrote: > > On Mon, Jul 17, 2023 at 05:19:22PM +0200, Konrad Dybcio wrote: > >> The GPU_CC block is powered by VDD_CX. Describe that. > >> > >> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> > >> --- > >> arch/arm64/boot/dts/qcom/sm6115.dtsi | 2 ++ > >> 1 file changed, 2 insertions(+) > >> > >> diff --git a/arch/arm64/boot/dts/qcom/sm6115.dtsi b/arch/arm64/boot/dts/qcom/sm6115.dtsi > >> index 29b5b388cd94..bfaaa1801a4d 100644 > >> --- a/arch/arm64/boot/dts/qcom/sm6115.dtsi > >> +++ b/arch/arm64/boot/dts/qcom/sm6115.dtsi > >> @@ -1430,6 +1430,8 @@ gpucc: clock-controller@5990000 { > >> clocks = <&rpmcc RPM_SMD_XO_CLK_SRC>, > >> <&gcc GCC_GPU_GPLL0_CLK_SRC>, > >> <&gcc GCC_GPU_GPLL0_DIV_CLK_SRC>; > >> + power-domains = <&rpmpd SM6115_VDDCX>; > >> + required-opps = <&rpmpd_opp_low_svs>; > > > > Where is this required-opp coming from? The clocks in gpucc seem to have > > different voltage requirements depending on the rates, but we usually > > handle that in the OPP tables of the consumer. > The only lower levels defined for this SoC are VDD_MIN and VDD_RET, > but quite obviously the GPU won't work then > The levels needed for the GPU clocks to run should be in the GPU OPP table though, just like e.g. sdhc2_opp_table for the SDCC clocks. I still don't really understand why this is specified here. :) Stephan
On 17.07.2023 18:56, Stephan Gerhold wrote: > On Mon, Jul 17, 2023 at 06:50:18PM +0200, Konrad Dybcio wrote: >> On 17.07.2023 18:28, Stephan Gerhold wrote: >>> On Mon, Jul 17, 2023 at 05:19:22PM +0200, Konrad Dybcio wrote: >>>> The GPU_CC block is powered by VDD_CX. Describe that. >>>> >>>> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> >>>> --- >>>> arch/arm64/boot/dts/qcom/sm6115.dtsi | 2 ++ >>>> 1 file changed, 2 insertions(+) >>>> >>>> diff --git a/arch/arm64/boot/dts/qcom/sm6115.dtsi b/arch/arm64/boot/dts/qcom/sm6115.dtsi >>>> index 29b5b388cd94..bfaaa1801a4d 100644 >>>> --- a/arch/arm64/boot/dts/qcom/sm6115.dtsi >>>> +++ b/arch/arm64/boot/dts/qcom/sm6115.dtsi >>>> @@ -1430,6 +1430,8 @@ gpucc: clock-controller@5990000 { >>>> clocks = <&rpmcc RPM_SMD_XO_CLK_SRC>, >>>> <&gcc GCC_GPU_GPLL0_CLK_SRC>, >>>> <&gcc GCC_GPU_GPLL0_DIV_CLK_SRC>; >>>> + power-domains = <&rpmpd SM6115_VDDCX>; >>>> + required-opps = <&rpmpd_opp_low_svs>; >>> >>> Where is this required-opp coming from? The clocks in gpucc seem to have >>> different voltage requirements depending on the rates, but we usually >>> handle that in the OPP tables of the consumer. >> The only lower levels defined for this SoC are VDD_MIN and VDD_RET, >> but quite obviously the GPU won't work then >> > > The levels needed for the GPU clocks to run should be in the GPU OPP > table though, just like e.g. sdhc2_opp_table for the SDCC clocks. > > I still don't really understand why this is specified here. :) The GPU_CC block needs this rail to be at a certain power level for register access. This describes that requirement. Konrad
On Mon, Jul 17, 2023 at 07:11:33PM +0200, Konrad Dybcio wrote: > On 17.07.2023 18:56, Stephan Gerhold wrote: > > On Mon, Jul 17, 2023 at 06:50:18PM +0200, Konrad Dybcio wrote: > >> On 17.07.2023 18:28, Stephan Gerhold wrote: > >>> On Mon, Jul 17, 2023 at 05:19:22PM +0200, Konrad Dybcio wrote: > >>>> The GPU_CC block is powered by VDD_CX. Describe that. > >>>> > >>>> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> > >>>> --- > >>>> arch/arm64/boot/dts/qcom/sm6115.dtsi | 2 ++ > >>>> 1 file changed, 2 insertions(+) > >>>> > >>>> diff --git a/arch/arm64/boot/dts/qcom/sm6115.dtsi b/arch/arm64/boot/dts/qcom/sm6115.dtsi > >>>> index 29b5b388cd94..bfaaa1801a4d 100644 > >>>> --- a/arch/arm64/boot/dts/qcom/sm6115.dtsi > >>>> +++ b/arch/arm64/boot/dts/qcom/sm6115.dtsi > >>>> @@ -1430,6 +1430,8 @@ gpucc: clock-controller@5990000 { > >>>> clocks = <&rpmcc RPM_SMD_XO_CLK_SRC>, > >>>> <&gcc GCC_GPU_GPLL0_CLK_SRC>, > >>>> <&gcc GCC_GPU_GPLL0_DIV_CLK_SRC>; > >>>> + power-domains = <&rpmpd SM6115_VDDCX>; > >>>> + required-opps = <&rpmpd_opp_low_svs>; > >>> > >>> Where is this required-opp coming from? The clocks in gpucc seem to have > >>> different voltage requirements depending on the rates, but we usually > >>> handle that in the OPP tables of the consumer. > >> The only lower levels defined for this SoC are VDD_MIN and VDD_RET, > >> but quite obviously the GPU won't work then > >> > > > > The levels needed for the GPU clocks to run should be in the GPU OPP > > table though, just like e.g. sdhc2_opp_table for the SDCC clocks. > > > > I still don't really understand why this is specified here. :) > The GPU_CC block needs this rail to be at a certain power level for > register access. This describes that requirement. > Can you show where this is defined downstream? On a quick look I didn't see something like that anywhere. Or is this from some secret documentation? Thanks, Stephan
On 17.07.2023 19:23, Stephan Gerhold wrote: > On Mon, Jul 17, 2023 at 07:11:33PM +0200, Konrad Dybcio wrote: >> On 17.07.2023 18:56, Stephan Gerhold wrote: >>> On Mon, Jul 17, 2023 at 06:50:18PM +0200, Konrad Dybcio wrote: >>>> On 17.07.2023 18:28, Stephan Gerhold wrote: >>>>> On Mon, Jul 17, 2023 at 05:19:22PM +0200, Konrad Dybcio wrote: >>>>>> The GPU_CC block is powered by VDD_CX. Describe that. >>>>>> >>>>>> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> >>>>>> --- >>>>>> arch/arm64/boot/dts/qcom/sm6115.dtsi | 2 ++ >>>>>> 1 file changed, 2 insertions(+) >>>>>> >>>>>> diff --git a/arch/arm64/boot/dts/qcom/sm6115.dtsi b/arch/arm64/boot/dts/qcom/sm6115.dtsi >>>>>> index 29b5b388cd94..bfaaa1801a4d 100644 >>>>>> --- a/arch/arm64/boot/dts/qcom/sm6115.dtsi >>>>>> +++ b/arch/arm64/boot/dts/qcom/sm6115.dtsi >>>>>> @@ -1430,6 +1430,8 @@ gpucc: clock-controller@5990000 { >>>>>> clocks = <&rpmcc RPM_SMD_XO_CLK_SRC>, >>>>>> <&gcc GCC_GPU_GPLL0_CLK_SRC>, >>>>>> <&gcc GCC_GPU_GPLL0_DIV_CLK_SRC>; >>>>>> + power-domains = <&rpmpd SM6115_VDDCX>; >>>>>> + required-opps = <&rpmpd_opp_low_svs>; >>>>> >>>>> Where is this required-opp coming from? The clocks in gpucc seem to have >>>>> different voltage requirements depending on the rates, but we usually >>>>> handle that in the OPP tables of the consumer. >>>> The only lower levels defined for this SoC are VDD_MIN and VDD_RET, >>>> but quite obviously the GPU won't work then >>>> >>> >>> The levels needed for the GPU clocks to run should be in the GPU OPP >>> table though, just like e.g. sdhc2_opp_table for the SDCC clocks. >>> >>> I still don't really understand why this is specified here. :) >> The GPU_CC block needs this rail to be at a certain power level for >> register access. This describes that requirement. >> > > Can you show where this is defined downstream? On a quick look I didn't > see something like that anywhere. Or is this from some secret > documentation? As far as downstream goes, you can notice that no branch's or RCG's vdd tables ever define a level lower than the one I mentioned. Konrad
On Mon, Jul 17, 2023 at 07:11:33PM +0200, Konrad Dybcio wrote: > On 17.07.2023 18:56, Stephan Gerhold wrote: > > On Mon, Jul 17, 2023 at 06:50:18PM +0200, Konrad Dybcio wrote: > >> On 17.07.2023 18:28, Stephan Gerhold wrote: > >>> On Mon, Jul 17, 2023 at 05:19:22PM +0200, Konrad Dybcio wrote: > >>>> The GPU_CC block is powered by VDD_CX. Describe that. > >>>> > >>>> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> > >>>> --- > >>>> arch/arm64/boot/dts/qcom/sm6115.dtsi | 2 ++ > >>>> 1 file changed, 2 insertions(+) > >>>> > >>>> diff --git a/arch/arm64/boot/dts/qcom/sm6115.dtsi b/arch/arm64/boot/dts/qcom/sm6115.dtsi > >>>> index 29b5b388cd94..bfaaa1801a4d 100644 > >>>> --- a/arch/arm64/boot/dts/qcom/sm6115.dtsi > >>>> +++ b/arch/arm64/boot/dts/qcom/sm6115.dtsi > >>>> @@ -1430,6 +1430,8 @@ gpucc: clock-controller@5990000 { > >>>> clocks = <&rpmcc RPM_SMD_XO_CLK_SRC>, > >>>> <&gcc GCC_GPU_GPLL0_CLK_SRC>, > >>>> <&gcc GCC_GPU_GPLL0_DIV_CLK_SRC>; > >>>> + power-domains = <&rpmpd SM6115_VDDCX>; > >>>> + required-opps = <&rpmpd_opp_low_svs>; > >>> > >>> Where is this required-opp coming from? The clocks in gpucc seem to have > >>> different voltage requirements depending on the rates, but we usually > >>> handle that in the OPP tables of the consumer. > >> The only lower levels defined for this SoC are VDD_MIN and VDD_RET, > >> but quite obviously the GPU won't work then > >> > > > > The levels needed for the GPU clocks to run should be in the GPU OPP > > table though, just like e.g. sdhc2_opp_table for the SDCC clocks. > > > > I still don't really understand why this is specified here. :) > The GPU_CC block needs this rail to be at a certain power level for > register access. This describes that requirement. > And that is not the lowest level reported by command db? Please describe this part in the commit message as well. Thanks, Bjorn
On Mon, Jul 17, 2023 at 09:18:21PM +0200, Konrad Dybcio wrote: > On 17.07.2023 19:23, Stephan Gerhold wrote: > > On Mon, Jul 17, 2023 at 07:11:33PM +0200, Konrad Dybcio wrote: > >> On 17.07.2023 18:56, Stephan Gerhold wrote: > >>> On Mon, Jul 17, 2023 at 06:50:18PM +0200, Konrad Dybcio wrote: > >>>> On 17.07.2023 18:28, Stephan Gerhold wrote: > >>>>> On Mon, Jul 17, 2023 at 05:19:22PM +0200, Konrad Dybcio wrote: > >>>>>> The GPU_CC block is powered by VDD_CX. Describe that. > >>>>>> > >>>>>> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> > >>>>>> --- > >>>>>> arch/arm64/boot/dts/qcom/sm6115.dtsi | 2 ++ > >>>>>> 1 file changed, 2 insertions(+) > >>>>>> > >>>>>> diff --git a/arch/arm64/boot/dts/qcom/sm6115.dtsi b/arch/arm64/boot/dts/qcom/sm6115.dtsi > >>>>>> index 29b5b388cd94..bfaaa1801a4d 100644 > >>>>>> --- a/arch/arm64/boot/dts/qcom/sm6115.dtsi > >>>>>> +++ b/arch/arm64/boot/dts/qcom/sm6115.dtsi > >>>>>> @@ -1430,6 +1430,8 @@ gpucc: clock-controller@5990000 { > >>>>>> clocks = <&rpmcc RPM_SMD_XO_CLK_SRC>, > >>>>>> <&gcc GCC_GPU_GPLL0_CLK_SRC>, > >>>>>> <&gcc GCC_GPU_GPLL0_DIV_CLK_SRC>; > >>>>>> + power-domains = <&rpmpd SM6115_VDDCX>; > >>>>>> + required-opps = <&rpmpd_opp_low_svs>; > >>>>> > >>>>> Where is this required-opp coming from? The clocks in gpucc seem to have > >>>>> different voltage requirements depending on the rates, but we usually > >>>>> handle that in the OPP tables of the consumer. > >>>> The only lower levels defined for this SoC are VDD_MIN and VDD_RET, > >>>> but quite obviously the GPU won't work then > >>>> > >>> > >>> The levels needed for the GPU clocks to run should be in the GPU OPP > >>> table though, just like e.g. sdhc2_opp_table for the SDCC clocks. > >>> > >>> I still don't really understand why this is specified here. :) > >> The GPU_CC block needs this rail to be at a certain power level for > >> register access. This describes that requirement. > >> > > > > Can you show where this is defined downstream? On a quick look I didn't > > see something like that anywhere. Or is this from some secret > > documentation? > As far as downstream goes, you can notice that no branch's or RCG's > vdd tables ever define a level lower than the one I mentioned. > As far as I can tell the vdd tables are only used when the clock is actually enabled though, not for writing to registers while they are disabled. Stephan
On 18.07.2023 06:25, Bjorn Andersson wrote: > On Mon, Jul 17, 2023 at 07:11:33PM +0200, Konrad Dybcio wrote: >> On 17.07.2023 18:56, Stephan Gerhold wrote: >>> On Mon, Jul 17, 2023 at 06:50:18PM +0200, Konrad Dybcio wrote: >>>> On 17.07.2023 18:28, Stephan Gerhold wrote: >>>>> On Mon, Jul 17, 2023 at 05:19:22PM +0200, Konrad Dybcio wrote: >>>>>> The GPU_CC block is powered by VDD_CX. Describe that. >>>>>> >>>>>> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> >>>>>> --- >>>>>> arch/arm64/boot/dts/qcom/sm6115.dtsi | 2 ++ >>>>>> 1 file changed, 2 insertions(+) >>>>>> >>>>>> diff --git a/arch/arm64/boot/dts/qcom/sm6115.dtsi b/arch/arm64/boot/dts/qcom/sm6115.dtsi >>>>>> index 29b5b388cd94..bfaaa1801a4d 100644 >>>>>> --- a/arch/arm64/boot/dts/qcom/sm6115.dtsi >>>>>> +++ b/arch/arm64/boot/dts/qcom/sm6115.dtsi >>>>>> @@ -1430,6 +1430,8 @@ gpucc: clock-controller@5990000 { >>>>>> clocks = <&rpmcc RPM_SMD_XO_CLK_SRC>, >>>>>> <&gcc GCC_GPU_GPLL0_CLK_SRC>, >>>>>> <&gcc GCC_GPU_GPLL0_DIV_CLK_SRC>; >>>>>> + power-domains = <&rpmpd SM6115_VDDCX>; >>>>>> + required-opps = <&rpmpd_opp_low_svs>; >>>>> >>>>> Where is this required-opp coming from? The clocks in gpucc seem to have >>>>> different voltage requirements depending on the rates, but we usually >>>>> handle that in the OPP tables of the consumer. >>>> The only lower levels defined for this SoC are VDD_MIN and VDD_RET, >>>> but quite obviously the GPU won't work then >>>> >>> >>> The levels needed for the GPU clocks to run should be in the GPU OPP >>> table though, just like e.g. sdhc2_opp_table for the SDCC clocks. >>> >>> I still don't really understand why this is specified here. :) >> The GPU_CC block needs this rail to be at a certain power level for >> register access. This describes that requirement. >> > > And that is not the lowest level reported by command db? > Please describe this part in the commit message as well. command-what? ;) RPM exports VDD_NONE (off), VDD_MIN (the lowest state before collapse) and then low_svs is usually the lowest "actually on" state for all consumers. Konrad
On 18.07.2023 13:56, Stephan Gerhold wrote: > On Mon, Jul 17, 2023 at 09:18:21PM +0200, Konrad Dybcio wrote: >> On 17.07.2023 19:23, Stephan Gerhold wrote: >>> On Mon, Jul 17, 2023 at 07:11:33PM +0200, Konrad Dybcio wrote: >>>> On 17.07.2023 18:56, Stephan Gerhold wrote: >>>>> On Mon, Jul 17, 2023 at 06:50:18PM +0200, Konrad Dybcio wrote: >>>>>> On 17.07.2023 18:28, Stephan Gerhold wrote: >>>>>>> On Mon, Jul 17, 2023 at 05:19:22PM +0200, Konrad Dybcio wrote: >>>>>>>> The GPU_CC block is powered by VDD_CX. Describe that. >>>>>>>> >>>>>>>> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> >>>>>>>> --- >>>>>>>> arch/arm64/boot/dts/qcom/sm6115.dtsi | 2 ++ >>>>>>>> 1 file changed, 2 insertions(+) >>>>>>>> >>>>>>>> diff --git a/arch/arm64/boot/dts/qcom/sm6115.dtsi b/arch/arm64/boot/dts/qcom/sm6115.dtsi >>>>>>>> index 29b5b388cd94..bfaaa1801a4d 100644 >>>>>>>> --- a/arch/arm64/boot/dts/qcom/sm6115.dtsi >>>>>>>> +++ b/arch/arm64/boot/dts/qcom/sm6115.dtsi >>>>>>>> @@ -1430,6 +1430,8 @@ gpucc: clock-controller@5990000 { >>>>>>>> clocks = <&rpmcc RPM_SMD_XO_CLK_SRC>, >>>>>>>> <&gcc GCC_GPU_GPLL0_CLK_SRC>, >>>>>>>> <&gcc GCC_GPU_GPLL0_DIV_CLK_SRC>; >>>>>>>> + power-domains = <&rpmpd SM6115_VDDCX>; >>>>>>>> + required-opps = <&rpmpd_opp_low_svs>; >>>>>>> >>>>>>> Where is this required-opp coming from? The clocks in gpucc seem to have >>>>>>> different voltage requirements depending on the rates, but we usually >>>>>>> handle that in the OPP tables of the consumer. >>>>>> The only lower levels defined for this SoC are VDD_MIN and VDD_RET, >>>>>> but quite obviously the GPU won't work then >>>>>> >>>>> >>>>> The levels needed for the GPU clocks to run should be in the GPU OPP >>>>> table though, just like e.g. sdhc2_opp_table for the SDCC clocks. >>>>> >>>>> I still don't really understand why this is specified here. :) >>>> The GPU_CC block needs this rail to be at a certain power level for >>>> register access. This describes that requirement. >>>> >>> >>> Can you show where this is defined downstream? On a quick look I didn't >>> see something like that anywhere. Or is this from some secret >>> documentation? >> As far as downstream goes, you can notice that no branch's or RCG's >> vdd tables ever define a level lower than the one I mentioned. >> > > As far as I can tell the vdd tables are only used when the clock is > actually enabled though, not for writing to registers while they are > disabled. Maybe, but you can also notice that even XO rates require at least SVS_LOW to function. Konrad
On Tue, 18 Jul 2023 at 15:48, Konrad Dybcio <konrad.dybcio@linaro.org> wrote: > > On 18.07.2023 13:56, Stephan Gerhold wrote: > > On Mon, Jul 17, 2023 at 09:18:21PM +0200, Konrad Dybcio wrote: > >> On 17.07.2023 19:23, Stephan Gerhold wrote: > >>> On Mon, Jul 17, 2023 at 07:11:33PM +0200, Konrad Dybcio wrote: > >>>> On 17.07.2023 18:56, Stephan Gerhold wrote: > >>>>> On Mon, Jul 17, 2023 at 06:50:18PM +0200, Konrad Dybcio wrote: > >>>>>> On 17.07.2023 18:28, Stephan Gerhold wrote: > >>>>>>> On Mon, Jul 17, 2023 at 05:19:22PM +0200, Konrad Dybcio wrote: > >>>>>>>> The GPU_CC block is powered by VDD_CX. Describe that. > >>>>>>>> > >>>>>>>> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> > >>>>>>>> --- > >>>>>>>> arch/arm64/boot/dts/qcom/sm6115.dtsi | 2 ++ > >>>>>>>> 1 file changed, 2 insertions(+) > >>>>>>>> > >>>>>>>> diff --git a/arch/arm64/boot/dts/qcom/sm6115.dtsi b/arch/arm64/boot/dts/qcom/sm6115.dtsi > >>>>>>>> index 29b5b388cd94..bfaaa1801a4d 100644 > >>>>>>>> --- a/arch/arm64/boot/dts/qcom/sm6115.dtsi > >>>>>>>> +++ b/arch/arm64/boot/dts/qcom/sm6115.dtsi > >>>>>>>> @@ -1430,6 +1430,8 @@ gpucc: clock-controller@5990000 { > >>>>>>>> clocks = <&rpmcc RPM_SMD_XO_CLK_SRC>, > >>>>>>>> <&gcc GCC_GPU_GPLL0_CLK_SRC>, > >>>>>>>> <&gcc GCC_GPU_GPLL0_DIV_CLK_SRC>; > >>>>>>>> + power-domains = <&rpmpd SM6115_VDDCX>; > >>>>>>>> + required-opps = <&rpmpd_opp_low_svs>; > >>>>>>> > >>>>>>> Where is this required-opp coming from? The clocks in gpucc seem to have > >>>>>>> different voltage requirements depending on the rates, but we usually > >>>>>>> handle that in the OPP tables of the consumer. > >>>>>> The only lower levels defined for this SoC are VDD_MIN and VDD_RET, > >>>>>> but quite obviously the GPU won't work then > >>>>>> > >>>>> > >>>>> The levels needed for the GPU clocks to run should be in the GPU OPP > >>>>> table though, just like e.g. sdhc2_opp_table for the SDCC clocks. > >>>>> > >>>>> I still don't really understand why this is specified here. :) > >>>> The GPU_CC block needs this rail to be at a certain power level for > >>>> register access. This describes that requirement. > >>>> > >>> > >>> Can you show where this is defined downstream? On a quick look I didn't > >>> see something like that anywhere. Or is this from some secret > >>> documentation? > >> As far as downstream goes, you can notice that no branch's or RCG's > >> vdd tables ever define a level lower than the one I mentioned. > >> > > > > As far as I can tell the vdd tables are only used when the clock is > > actually enabled though, not for writing to registers while they are > > disabled. > Maybe, but you can also notice that even XO rates require at least > SVS_LOW to function. But the vdd tables are related to clock rates, which, in the upstream design, should be voted by the consumers, not by the clock driver.
On 18.07.2023 15:08, Dmitry Baryshkov wrote: > On Tue, 18 Jul 2023 at 15:48, Konrad Dybcio <konrad.dybcio@linaro.org> wrote: >> >> On 18.07.2023 13:56, Stephan Gerhold wrote: >>> On Mon, Jul 17, 2023 at 09:18:21PM +0200, Konrad Dybcio wrote: >>>> On 17.07.2023 19:23, Stephan Gerhold wrote: >>>>> On Mon, Jul 17, 2023 at 07:11:33PM +0200, Konrad Dybcio wrote: >>>>>> On 17.07.2023 18:56, Stephan Gerhold wrote: >>>>>>> On Mon, Jul 17, 2023 at 06:50:18PM +0200, Konrad Dybcio wrote: >>>>>>>> On 17.07.2023 18:28, Stephan Gerhold wrote: >>>>>>>>> On Mon, Jul 17, 2023 at 05:19:22PM +0200, Konrad Dybcio wrote: >>>>>>>>>> The GPU_CC block is powered by VDD_CX. Describe that. >>>>>>>>>> >>>>>>>>>> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> >>>>>>>>>> --- >>>>>>>>>> arch/arm64/boot/dts/qcom/sm6115.dtsi | 2 ++ >>>>>>>>>> 1 file changed, 2 insertions(+) >>>>>>>>>> >>>>>>>>>> diff --git a/arch/arm64/boot/dts/qcom/sm6115.dtsi b/arch/arm64/boot/dts/qcom/sm6115.dtsi >>>>>>>>>> index 29b5b388cd94..bfaaa1801a4d 100644 >>>>>>>>>> --- a/arch/arm64/boot/dts/qcom/sm6115.dtsi >>>>>>>>>> +++ b/arch/arm64/boot/dts/qcom/sm6115.dtsi >>>>>>>>>> @@ -1430,6 +1430,8 @@ gpucc: clock-controller@5990000 { >>>>>>>>>> clocks = <&rpmcc RPM_SMD_XO_CLK_SRC>, >>>>>>>>>> <&gcc GCC_GPU_GPLL0_CLK_SRC>, >>>>>>>>>> <&gcc GCC_GPU_GPLL0_DIV_CLK_SRC>; >>>>>>>>>> + power-domains = <&rpmpd SM6115_VDDCX>; >>>>>>>>>> + required-opps = <&rpmpd_opp_low_svs>; >>>>>>>>> >>>>>>>>> Where is this required-opp coming from? The clocks in gpucc seem to have >>>>>>>>> different voltage requirements depending on the rates, but we usually >>>>>>>>> handle that in the OPP tables of the consumer. >>>>>>>> The only lower levels defined for this SoC are VDD_MIN and VDD_RET, >>>>>>>> but quite obviously the GPU won't work then >>>>>>>> >>>>>>> >>>>>>> The levels needed for the GPU clocks to run should be in the GPU OPP >>>>>>> table though, just like e.g. sdhc2_opp_table for the SDCC clocks. >>>>>>> >>>>>>> I still don't really understand why this is specified here. :) >>>>>> The GPU_CC block needs this rail to be at a certain power level for >>>>>> register access. This describes that requirement. >>>>>> >>>>> >>>>> Can you show where this is defined downstream? On a quick look I didn't >>>>> see something like that anywhere. Or is this from some secret >>>>> documentation? >>>> As far as downstream goes, you can notice that no branch's or RCG's >>>> vdd tables ever define a level lower than the one I mentioned. >>>> >>> >>> As far as I can tell the vdd tables are only used when the clock is >>> actually enabled though, not for writing to registers while they are >>> disabled. >> Maybe, but you can also notice that even XO rates require at least >> SVS_LOW to function. > > But the vdd tables are related to clock rates, which, in the upstream > design, should be voted by the consumers, not by the clock driver. Not all of the clocks are associated with OPP tables upstream, and it would be nice if the clock controller block had power flowing to it in case one wanted to access a different clock. Konrad
On Tue, Jul 18, 2023 at 02:21:31PM +0200, Konrad Dybcio wrote: > On 18.07.2023 06:25, Bjorn Andersson wrote: > > On Mon, Jul 17, 2023 at 07:11:33PM +0200, Konrad Dybcio wrote: > >> On 17.07.2023 18:56, Stephan Gerhold wrote: > >>> On Mon, Jul 17, 2023 at 06:50:18PM +0200, Konrad Dybcio wrote: > >>>> On 17.07.2023 18:28, Stephan Gerhold wrote: > >>>>> On Mon, Jul 17, 2023 at 05:19:22PM +0200, Konrad Dybcio wrote: > >>>>>> The GPU_CC block is powered by VDD_CX. Describe that. > >>>>>> > >>>>>> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> > >>>>>> --- > >>>>>> arch/arm64/boot/dts/qcom/sm6115.dtsi | 2 ++ > >>>>>> 1 file changed, 2 insertions(+) > >>>>>> > >>>>>> diff --git a/arch/arm64/boot/dts/qcom/sm6115.dtsi b/arch/arm64/boot/dts/qcom/sm6115.dtsi > >>>>>> index 29b5b388cd94..bfaaa1801a4d 100644 > >>>>>> --- a/arch/arm64/boot/dts/qcom/sm6115.dtsi > >>>>>> +++ b/arch/arm64/boot/dts/qcom/sm6115.dtsi > >>>>>> @@ -1430,6 +1430,8 @@ gpucc: clock-controller@5990000 { > >>>>>> clocks = <&rpmcc RPM_SMD_XO_CLK_SRC>, > >>>>>> <&gcc GCC_GPU_GPLL0_CLK_SRC>, > >>>>>> <&gcc GCC_GPU_GPLL0_DIV_CLK_SRC>; > >>>>>> + power-domains = <&rpmpd SM6115_VDDCX>; > >>>>>> + required-opps = <&rpmpd_opp_low_svs>; > >>>>> > >>>>> Where is this required-opp coming from? The clocks in gpucc seem to have > >>>>> different voltage requirements depending on the rates, but we usually > >>>>> handle that in the OPP tables of the consumer. > >>>> The only lower levels defined for this SoC are VDD_MIN and VDD_RET, > >>>> but quite obviously the GPU won't work then > >>>> > >>> > >>> The levels needed for the GPU clocks to run should be in the GPU OPP > >>> table though, just like e.g. sdhc2_opp_table for the SDCC clocks. > >>> > >>> I still don't really understand why this is specified here. :) > >> The GPU_CC block needs this rail to be at a certain power level for > >> register access. This describes that requirement. > >> > > > > And that is not the lowest level reported by command db? > > Please describe this part in the commit message as well. > command-what? ;) > Apparently doesn't matter that I read that line multiple times, my brain really wanted a 'h' in there. > RPM exports VDD_NONE (off), VDD_MIN (the lowest state before collapse) > and then low_svs is usually the lowest "actually on" state for all > consumers. > In rpmhpd I changed it such that the minimal enabled state would be !disabled (so that the automatic enablement during probe would be sufficient to access registers), but talking to Ulf this is provider-specific. So unless you can figure out a acceptable lowest non-disabled state this is what has to be done... PS. My ask for mentioning this in the commit message still stands. Regards, Bjorn
diff --git a/arch/arm64/boot/dts/qcom/sm6115.dtsi b/arch/arm64/boot/dts/qcom/sm6115.dtsi index 29b5b388cd94..bfaaa1801a4d 100644 --- a/arch/arm64/boot/dts/qcom/sm6115.dtsi +++ b/arch/arm64/boot/dts/qcom/sm6115.dtsi @@ -1430,6 +1430,8 @@ gpucc: clock-controller@5990000 { clocks = <&rpmcc RPM_SMD_XO_CLK_SRC>, <&gcc GCC_GPU_GPLL0_CLK_SRC>, <&gcc GCC_GPU_GPLL0_DIV_CLK_SRC>; + power-domains = <&rpmpd SM6115_VDDCX>; + required-opps = <&rpmpd_opp_low_svs>; #clock-cells = <1>; #reset-cells = <1>; #power-domain-cells = <1>;