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 AADB9C88CB6 for ; Mon, 12 Jun 2023 15:38:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238617AbjFLPij (ORCPT ); Mon, 12 Jun 2023 11:38:39 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33646 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237359AbjFLPii (ORCPT ); Mon, 12 Jun 2023 11:38:38 -0400 Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3D49A10CC for ; Mon, 12 Jun 2023 08:38:35 -0700 (PDT) Received: by mail-lj1-x236.google.com with SMTP id 38308e7fff4ca-2b1b2ca09b9so53316341fa.1 for ; Mon, 12 Jun 2023 08:38:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1686584313; x=1689176313; 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=6j+4xQEH1M/R/NQt831AU88wINq39ctKhdxH/376xe8=; b=ZmYcILAuFJRWyFReOLXxXy2Gd7G6ysWJ/yBu6etw7IwytgQPZPqxjDFfvipbfw+GDy S3ZAbO83vbSZqdNeyj8b0ilsycbAjw5UzMCaH5RUruPNO99Tc4dTtd8ZkW3RkiseuqnO HmvxSZd2HyPJW/OGaXCIPagATwdi58gOees4HyLySflAFBV2D7oVRUon9zDHzIMnpgma 0TI35pyFvCcD/JIJFye5cTBYyY1VdkhIbf5y2cYvkoi6RDA3Kgtvf0S2+s55PmbDr9jY C36u/NJmUhshqu1ecDnhDa9U9mI5n0NYvtalnjAY2h3EttEZfBRfjXc+bdkYlafP4KQz kG2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686584313; x=1689176313; 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=6j+4xQEH1M/R/NQt831AU88wINq39ctKhdxH/376xe8=; b=VsXHjF+t4/J61ywoqGwZ1o/v7Xskf6rNRDEOMYQqO7XGEjDK5rlF8/VgGUj8acrHvf /aEyW3NXiT70n05n5Voo2PKEO2SaL6xQlGKHjoxwX4MtCdbaK+zcbET4RnarEghWL9V0 fpa9e+rKA3Ng4NqTYKVe5ehIZblRmMugOr5i3ahfDVREUYwF2VF7zRIq34CtHopBmz4t wqCzW8lOavKsbSdRB5cAEUoP/XqesiPOi5+nyRgDEcoFaLVmNZxPK/4H3jV8x7N2cVye 6UVL7tWHB7OdOPe1SdbLigxdfb9ee3JQql37eeerKK7w0CW4JQcZ6ZPVE1OBNNCFoYeJ gV2A== X-Gm-Message-State: AC+VfDxBrZnSkHE8gq1cxlNyPbjjvsCJv67ItA9i2t5qNidoSSp80UJC TsL1jxEC/RusaT1FSxFa1LEhmw== X-Google-Smtp-Source: ACHHUZ4Teau1vBIt9NE9tpRSAXxSnYawNGGHP0WPg9NHLirIprLF6ye3xlV7W9UxE9+b939q64+g7Q== X-Received: by 2002:a05:651c:86:b0:2b2:104d:8f89 with SMTP id 6-20020a05651c008600b002b2104d8f89mr3097381ljq.0.1686584313327; Mon, 12 Jun 2023 08:38:33 -0700 (PDT) Received: from ?IPV6:2001:14ba:a0db:1f00::8a5? (dzdqv0yyyyyyyyyyybcwt-3.rev.dnainternet.fi. [2001:14ba:a0db:1f00::8a5]) by smtp.gmail.com with ESMTPSA id i5-20020a2e8085000000b002ad994b0b51sm1812951ljg.16.2023.06.12.08.38.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Jun 2023 08:38:32 -0700 (PDT) Message-ID: Date: Mon, 12 Jun 2023 18:38:32 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Subject: Re: [PATCH 15/18] ARM: dts: qcom: apq8064: provide voltage scaling tables Content-Language: en-GB To: Stephan Gerhold Cc: Rob Herring , Krzysztof Kozlowski , Conor Dooley , Andy Gross , Bjorn Andersson , Konrad Dybcio , Ilia Lin , Viresh Kumar , Nishanth Menon , Stephen Boyd , Michael Turquette , "Rafael J. Wysocki" , linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org, linux-pm@vger.kernel.org, linux-clk@vger.kernel.org, Christian Marangi References: <20230612053922.3284394-1-dmitry.baryshkov@linaro.org> <20230612053922.3284394-16-dmitry.baryshkov@linaro.org> <8c1085fd-8a73-d192-6624-d4f35728e68a@linaro.org> From: Dmitry Baryshkov In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On 12/06/2023 16:59, Stephan Gerhold wrote: > On Mon, Jun 12, 2023 at 04:33:09PM +0300, Dmitry Baryshkov wrote: >> On 12/06/2023 12:01, Stephan Gerhold wrote: >>> On Mon, Jun 12, 2023 at 08:39:19AM +0300, Dmitry Baryshkov wrote: >>>> APQ8064 has 4 speed bins, each of them having from 4 to 6 categorization >>>> kinds. Provide tables necessary to handle voltage scaling on this SoC. >>>> >>>> Signed-off-by: Dmitry Baryshkov >>>> --- >>>> arch/arm/boot/dts/qcom-apq8064.dtsi | 1017 +++++++++++++++++++++++++++ >>>> 1 file changed, 1017 insertions(+) >>>> >>>> diff --git a/arch/arm/boot/dts/qcom-apq8064.dtsi b/arch/arm/boot/dts/qcom-apq8064.dtsi >>>> index 4ef13f3d702b..f35853b59544 100644 >>>> --- a/arch/arm/boot/dts/qcom-apq8064.dtsi >>>> +++ b/arch/arm/boot/dts/qcom-apq8064.dtsi >>>> @@ -49,6 +49,9 @@ CPU0: cpu@0 { >>>> clocks = <&kraitcc KRAIT_CPU_0>; >>>> clock-names = "cpu"; >>>> clock-latency = <100000>; >>>> + vdd-mem-supply = <&pm8921_l24>; >>>> + vdd-dig-supply = <&pm8921_s3>; >>>> + vdd-core-supply = <&saw0_vreg>; >>>> interconnects = <&kraitcc MASTER_KRAIT_L2 &kraitcc SLAVE_KRAIT_L2>; >>>> operating-points-v2 = <&cpu_opp_table>; >>>> #cooling-cells = <2>; >>>> @@ -66,6 +69,9 @@ CPU1: cpu@1 { >>>> clocks = <&kraitcc KRAIT_CPU_1>; >>>> clock-names = "cpu"; >>>> clock-latency = <100000>; >>>> + vdd-mem-supply = <&pm8921_l24>; >>>> + vdd-dig-supply = <&pm8921_s3>; >>>> + vdd-core-supply = <&saw1_vreg>; >>>> interconnects = <&kraitcc MASTER_KRAIT_L2 &kraitcc SLAVE_KRAIT_L2>; >>>> operating-points-v2 = <&cpu_opp_table>; >>>> #cooling-cells = <2>; >>>> @@ -83,6 +89,9 @@ CPU2: cpu@2 { >>>> clocks = <&kraitcc KRAIT_CPU_2>; >>>> clock-names = "cpu"; >>>> clock-latency = <100000>; >>>> + vdd-mem-supply = <&pm8921_l24>; >>>> + vdd-dig-supply = <&pm8921_s3>; >>>> + vdd-core-supply = <&saw2_vreg>; >>>> interconnects = <&kraitcc MASTER_KRAIT_L2 &kraitcc SLAVE_KRAIT_L2>; >>>> operating-points-v2 = <&cpu_opp_table>; >>>> #cooling-cells = <2>; >>>> @@ -100,6 +109,9 @@ CPU3: cpu@3 { >>>> clocks = <&kraitcc KRAIT_CPU_3>; >>>> clock-names = "cpu"; >>>> clock-latency = <100000>; >>>> + vdd-mem-supply = <&pm8921_l24>; >>>> + vdd-dig-supply = <&pm8921_s3>; >>>> + vdd-core-supply = <&saw3_vreg>; >>>> interconnects = <&kraitcc MASTER_KRAIT_L2 &kraitcc SLAVE_KRAIT_L2>; >>>> operating-points-v2 = <&cpu_opp_table>; >>>> #cooling-cells = <2>; >>>> @@ -132,6 +144,81 @@ cpu_opp_table: opp-table-cpu { >>>> opp-384000000 { >>>> opp-hz = /bits/ 64 <384000000>; >>>> opp-peak-kBps = <384000>; >>>> + opp-microvolt-speed0-pvs0 = <1050000 1050000 1150000>, >>>> + <950000 950000 1150000>, >>>> + <950000 950000 975000>; >>> [skipped the OPP voltage vs bw ordering] >> >>> >>> The alternative that I've already argued for on IRC in #linux-msm a >>> couple of days ago would be to give the L2 cache (here: "interconnect") >>> an own OPP table where it can describe its voltage requirements, >>> independent from the CPU. That way the icc_set_bw() would be guaranteed >>> to apply the correct voltage before adjusting the L2 cache clock. It >>> looks like the "l2_level" voltages for vdd_dig and vdd_mem are not >>> speedbin/PVS-specific [2] so this would also significantly reduce the DT >>> size, since you wouldn't need to repeat the same vdd_dig/vdd_mem >>> voltages for all of them. >> >> Yes. I fact our discussion triggered me to do this patchset. >> >> So, another option would be to have something like the following snippet. Do >> you know if we are allowed to squish additional data into the L2 cache DT >> node? >> > > I suspect no one has tried this before, so only the DT maintainers could > answer this. I would say that it just follows the existing design of > clocks/-supply/OPPs on the CPU nodes. vdd-mem-supply isn't a property of > the CPU, it's a property of the L2 cache so it actually fits better there. > > I think the more controversial questions might be: > > - Is a L2 cache really an "interconnect"? I suppose one could argue it > connects multiple CPU cores to a cluster (similar how a CCI connects > multiple clusters to a system). Yes. This was my reasoning for CBF clock as well as for this L2 clock. The separate L2 cache device is also an interconnect from my POV. It connects all CPU cores and we have to vote on its frequency. > - What would bind to the l2-cache node? A separate driver? Does that > work if it sits below the /cpus node? In the worst case we'd have to populate that manually. E.g. from the qcom-cpufreq-nvmem.c -- With best wishes Dmitry