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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8B7CFEB64DD for ; Tue, 18 Jul 2023 13:36:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232529AbjGRNg6 (ORCPT ); Tue, 18 Jul 2023 09:36:58 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39848 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232831AbjGRNgu (ORCPT ); Tue, 18 Jul 2023 09:36:50 -0400 Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E4E64170F for ; Tue, 18 Jul 2023 06:36:39 -0700 (PDT) Received: by mail-lf1-x130.google.com with SMTP id 2adb3069b0e04-4fbf09a9139so9151741e87.2 for ; Tue, 18 Jul 2023 06:36:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1689687398; x=1692279398; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=hp7UgnldNcHA7FZx3WIx9aOagNjv/KtuNEbWyENtJnA=; b=oGFGd0FP042iyZd37c7nyenPiJFz/AO4vwIGmPPiBLZ1+VUXrw/l4TlTmHUn9dn36i JsHuBXdt+NLWsVYWFCmcRuv50+1m9NNcVdmrGuly+uR1T8kb3wo5MBbvAi+l6c6ayI2E F8oBKCAjQwz4H/Nzs4tqRQNMvlTVxzFmFOxtYzVYVrraof3khRBj91sFyvyj8iDXTR/U PdDi2rrciwUTgm/fipsXPOEyelj5fijEswO55KMYmIVC2yQzOk7J6dL+R/aSP4mdCngI 69rEkwQoBWmbi7KZuDule39Lnnz+uKmwME3zcxwK21INsGeG9AJvuWvjYZuN/hrKqNcd YAVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689687398; x=1692279398; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=hp7UgnldNcHA7FZx3WIx9aOagNjv/KtuNEbWyENtJnA=; b=DD5i+C39NpKh8t8RNkLpttOax4sYrZMI2WYiiE9lOn8B0TKZCV7mG4OupGh/0mNzaO 0AprLRaL5bUL8VokrxTTUUzUGhnEpF4/75fwvnXj78xfyqfPOeD1iQWPXZQSeE+NN5C7 NxRnGScDkBRGOQbgaa6j/7ddSKPiEwE9Rf98OzVtaRbNyxxZC5xGeyb2GvyWIi4JVSca ilmiwCAyuSHL0DK9Nyhda/HAKAn00DOnBfBLMH2xsFJMumhaSsIQE4WgckEwqlryeZCJ 61ZA3NkPxhbE0V16OWtJ/wlzD99j/jg3o5ISb9srv5TLk+7/eFbUOK4PZ57TO4ke17y7 AiRQ== X-Gm-Message-State: ABy/qLb6MOWp0pnjQXSJMImVwa1QvkzhMpfISGoPQrrVfH+iQ/lQgsy3 pCwXZAoq4Up7wPQLkEojj9va4lnt58EENqBbtNqANQ== X-Google-Smtp-Source: APBJJlEgu9uSDaqhIXSpJjdBCEk3Mz4dqmv970bnu18XX0t6LiabJ0R4/28cYLVkOSADKddST27Gtw== X-Received: by 2002:a05:6512:5c1:b0:4f8:83f:babe with SMTP id o1-20020a05651205c100b004f8083fbabemr9554309lfo.62.1689687397885; Tue, 18 Jul 2023 06:36:37 -0700 (PDT) Received: from [192.168.1.101] (abyj181.neoplus.adsl.tpnet.pl. [83.9.29.181]) by smtp.gmail.com with ESMTPSA id p11-20020ac246cb000000b004faa82946d8sm444846lfo.178.2023.07.18.06.36.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 18 Jul 2023 06:36:37 -0700 (PDT) Message-ID: <8c342c2b-db37-1360-c716-0e4cdf3809a7@linaro.org> Date: Tue, 18 Jul 2023 15:36:35 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: [PATCH 15/15] arm64: dts: qcom: sm6115: Add VDD_CX to GPU_CCC Content-Language: en-US To: Dmitry Baryshkov Cc: Stephan Gerhold , Bjorn Andersson , Andy Gross , Michael Turquette , Stephen Boyd , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Marijn Suijten , linux-arm-msm@vger.kernel.org, linux-clk@vger.kernel.org, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org References: <20230717-topic-branch_aon_cleanup-v1-0-27784d27a4f4@linaro.org> <20230717-topic-branch_aon_cleanup-v1-15-27784d27a4f4@linaro.org> <8c5dc146-c305-bef9-0d97-76a91345ed1a@linaro.org> <9b28a17a-fe9c-3ff0-fa1d-320e75e174d0@linaro.org> From: Konrad Dybcio In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On 18.07.2023 15:08, Dmitry Baryshkov wrote: > On Tue, 18 Jul 2023 at 15:48, Konrad Dybcio 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 >>>>>>>>>> --- >>>>>>>>>> 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