Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp389627yba; Wed, 15 May 2019 03:15:51 -0700 (PDT) X-Google-Smtp-Source: APXvYqxZd0qBDMQepPPwYu7RwBrWbFETm66d3rKCpB6YFth8W5pV6UwSV+L22h9IVJzUG24GgqPh X-Received: by 2002:a65:57ce:: with SMTP id q14mr29430233pgr.109.1557915351907; Wed, 15 May 2019 03:15:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1557915351; cv=none; d=google.com; s=arc-20160816; b=GgIvsBeHa5++xFEidWfuxgfEGKeKVlhpV1UojnN7yA7RamvPsOeVcCuSmzUJk9oxKJ pLNlhoHTowGROfQ5c/WbYsLmXnhymEtuoWvhiwfBQXkXZ4oo2nxh8WYnN41087tBOs0W Zte+Vxz1jYcpYVCipqZoJ3VmTC6kKjXOq22HK5mGp4A4bVYsDrX+IQlFhAX2VzkBQSIL f1WVnvS2trZ4KRBbBT4yvH5jHvSd3nxraPzpxPgLfQ3TilsM8FgE/uG/pf8en4dP4Smp wcPI9gGSd9VW7uaPZyApMhW+aJFZp2lK9fpDO5xsH9w4LE1f9d3nu4YnsVsz7PzK2Tcb Ue1g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=q5vzb9qbv69BzC3TBeJnpXxGBryRXdu9w9fPfes2sXY=; b=YX4+UGlSPyB56QnuxDyspzDyO5kpRdCYte3yWfybEMlsne9aFDSLFWRhb68BgUJ9f5 w9pmBfo1+yBBIi5v50SIX+wFoAEq2bwZgxhmuWKtoS1tCBrdHNxxx1QI+8B0Z3vF3AAp 3FREpzkCfUpCmVWuh2LeJ9EVRYLucnMJ8s7Q+7edhPUReMggvziRWbzLgajaM2WO8a2q Tnd8/7segaRm4T5jiHoBemRDUr5Qxgrzd9kWWaCVuDZj+foW4VhE6RvSh6OKfAKoH8xA eNTk/0BbxhE3HnJs8O8t7YD0pZxj8MtiodPMYfJC7aMNj8Nh9OF+IJrQRPCLUtpSCJFR dycA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b="bLY7sL/G"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v4si1388161plp.404.2019.05.15.03.15.36; Wed, 15 May 2019 03:15:51 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b="bLY7sL/G"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 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 S1726412AbfEOKNc (ORCPT + 99 others); Wed, 15 May 2019 06:13:32 -0400 Received: from mail-qt1-f196.google.com ([209.85.160.196]:35775 "EHLO mail-qt1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726281AbfEOKNc (ORCPT ); Wed, 15 May 2019 06:13:32 -0400 Received: by mail-qt1-f196.google.com with SMTP id a39so711860qtk.2 for ; Wed, 15 May 2019 03:13:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=q5vzb9qbv69BzC3TBeJnpXxGBryRXdu9w9fPfes2sXY=; b=bLY7sL/G7Yf8SOp3HqCiZL/Kxke2jlyjmhfdkXZ4DfcbDpQUZHQifT9d1Oju1FPBS1 Ao0qSpfnJn6I8FO2jf0bAeMaODXJM/0x1q07MfRLBZQNVfB8nCoGWEWkc+S1GqGtDz0/ 9IVRpcLcC2qsGz8hm6MAWrHIShgSy/hOo2J4L6njeSF8PECmqnZATpyreRDrinDXpZEM VyaodUXP0ixgqtokO43Dj33+VD8/bq/nbt9LW1grUE3MS5DvJhkPVUlOhAcf/dI2mEkv h437g/Nz4hMvkLA4KLeNv3vuyGFSPBmO/HSuM1ElFU2Ncsx4PKs34PWYv6YY/FKawKcy IKvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=q5vzb9qbv69BzC3TBeJnpXxGBryRXdu9w9fPfes2sXY=; b=pHXQ9SLdXI1mz19TwnLitMGfwk+3rNjVN4toq70tgZLydwpoqLL17eOn+20N1EJ1/A F42CTGF4zH8Vp6lt5KN+Gu03f3BP18TTxV2DvmvkkGwZJOV8TQO0uVoozFSpTMoaaHTp VOw2NNsuh8RnKAXZqN5elOUdOBzy0VbCYRgTVRRx+79YQ150bwvPpZQJAvP3AXEOYGmI ANUIoBMdRkGC64HLPjV1jJBW19qqTRjLcal1zs5O0IvSrhLjWv83l3gHIFeFnjhrnRmb uaor/1xE90bmmSQELvEg4cy7r+pgJDgbNJ+HDHrvw151VM/f+cKW9+8Fn3oYxGX1eniJ J78Q== X-Gm-Message-State: APjAAAXF4F6wNMA5fDEYAduHnqyDXnygcWFIGq6O8ZlRv035nZ6LpAf+ m54SnbiIHd7Eq5yqX1kcEoYVQtl5aiD6Hxfv357iKg== X-Received: by 2002:ac8:3884:: with SMTP id f4mr35537714qtc.300.1557915210650; Wed, 15 May 2019 03:13:30 -0700 (PDT) MIME-Version: 1.0 References: <2a0626da4d8d5a1018c351b24b63e5e0d7a45a10.1557486950.git.amit.kucheria@linaro.org> <20190514161220.GC1824@centauri.ideon.se> In-Reply-To: <20190514161220.GC1824@centauri.ideon.se> From: Amit Kucheria Date: Wed, 15 May 2019 15:43:19 +0530 Message-ID: Subject: Re: [PATCHv1 4/8] arm64: dts: qcom: msm8916: Use more generic idle state names To: Niklas Cassel Cc: Linux Kernel Mailing List , linux-arm-msm , Bjorn Andersson , Andy Gross , David Brown , Li Yang , Shawn Guo , DTML Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, May 14, 2019 at 9:42 PM Niklas Cassel wrote: > > On Fri, May 10, 2019 at 04:59:42PM +0530, Amit Kucheria wrote: > > Instead of using Qualcomm-specific terminology, use generic node names > > for the idle states that are easier to understand. Move the description > > into the "idle-state-name" property. > > > > Signed-off-by: Amit Kucheria > > --- > > arch/arm64/boot/dts/qcom/msm8916.dtsi | 11 ++++++----- > > 1 file changed, 6 insertions(+), 5 deletions(-) > > > > diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi b/arch/arm64/boot/dts/qcom/msm8916.dtsi > > index ded1052e5693..400b609bb3fd 100644 > > --- a/arch/arm64/boot/dts/qcom/msm8916.dtsi > > +++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi > > @@ -110,7 +110,7 @@ > > reg = <0x0>; > > next-level-cache = <&L2_0>; > > enable-method = "psci"; > > - cpu-idle-states = <&CPU_SPC>; > > + cpu-idle-states = <&CPU_SLEEP_0>; > > clocks = <&apcs>; > > operating-points-v2 = <&cpu_opp_table>; > > #cooling-cells = <2>; > > @@ -122,7 +122,7 @@ > > reg = <0x1>; > > next-level-cache = <&L2_0>; > > enable-method = "psci"; > > - cpu-idle-states = <&CPU_SPC>; > > + cpu-idle-states = <&CPU_SLEEP_0>; > > clocks = <&apcs>; > > operating-points-v2 = <&cpu_opp_table>; > > #cooling-cells = <2>; > > @@ -134,7 +134,7 @@ > > reg = <0x2>; > > next-level-cache = <&L2_0>; > > enable-method = "psci"; > > - cpu-idle-states = <&CPU_SPC>; > > + cpu-idle-states = <&CPU_SLEEP_0>; > > clocks = <&apcs>; > > operating-points-v2 = <&cpu_opp_table>; > > #cooling-cells = <2>; > > @@ -146,7 +146,7 @@ > > reg = <0x3>; > > next-level-cache = <&L2_0>; > > enable-method = "psci"; > > - cpu-idle-states = <&CPU_SPC>; > > + cpu-idle-states = <&CPU_SLEEP_0>; > > clocks = <&apcs>; > > operating-points-v2 = <&cpu_opp_table>; > > #cooling-cells = <2>; > > @@ -160,8 +160,9 @@ > > idle-states { > > entry-method="psci"; > > Please add a space before and after "=". > > > > > - CPU_SPC: spc { > > + CPU_SLEEP_0: cpu-sleep-0 { > > While I like your idea of using power state names from > Server Base System Architecture document (SBSA) where applicable, > does each qcom power state have a matching state in SBSA? > > These are the qcom power states: > https://source.codeaurora.org/quic/la/kernel/msm-4.4/tree/Documentation/devicetree/bindings/arm/msm/lpm-levels.txt?h=msm-4.4#n53 > > Note that qcom defines: > "wfi", "retention", "gdhs", "pc", "fpc" > while SBSA simply defines "idle_standby" (aka wfi), "idle_retention", "sleep". > > Unless you know the equivalent name for each qcom power state > (perhaps several qcom power states are really the same SBSA state?), > I think that you should omit the renaming from this patch series. That is what SLEEP_0, SLEEP_1, SLEEP_2 could be used for. IOW, all these qcom definitions are nicely represented in the state-name and we could simply stick to SLEEP_0, SLEEP_1 for the node names. There is wide variability in the the names of the qcom idle states across SoC families downstream, so I'd argue against using those for the node names. Just for cpu states (non-wfi) I see the use of the following names downstream across families. The C seems to come from x86 world[1]: - C4, standalone power collapse (spc) - C4, power collapse (fpc) - C2D, retention - C3, power collapse (pc) - C4, rail power collapse (rail-pc) [1] https://www.hardwaresecrets.com/everything-you-need-to-know-about-the-cpu-c-states-power-saving-modes/ > > compatible = "arm,idle-state"; > > + idle-state-name = "standalone-power-collapse"; > > arm,psci-suspend-param = <0x40000002>; > > entry-latency-us = <130>; > > exit-latency-us = <150>; > > -- > > 2.17.1 > >