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 X-Spam-Level: X-Spam-Status: No, score=-7.0 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9CCB9C04AB1 for ; Thu, 9 May 2019 17:49:38 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 6481D2084E for ; Thu, 9 May 2019 17:49:38 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="IC1oQNAg" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726880AbfEIRth (ORCPT ); Thu, 9 May 2019 13:49:37 -0400 Received: from mail-vs1-f65.google.com ([209.85.217.65]:40866 "EHLO mail-vs1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726683AbfEIRtg (ORCPT ); Thu, 9 May 2019 13:49:36 -0400 Received: by mail-vs1-f65.google.com with SMTP id c24so1964754vsp.7 for ; Thu, 09 May 2019 10:49:35 -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=EH7jEXZyZKvAtUeW6cCFcLL4FqSd/A3iJEXYx8OljIU=; b=IC1oQNAgZo3s3zKgaeYt0VrxPg0DP7D9ABi+Y0c/SX6/j+DU3inX+z0u3eMq4e/XgD s1HPa+Hqh91Idp8CDkOOeHEZqhCgOBisL+LpQdYBpELhBVaXQtQ4nXmXEh08UxjOvESZ Z0TTApcW4S41vxjPV+EMwqg8y+k40csfLr2tlONgvTZImLLTzldbHGOYXDGLgKUdHyoO dGD9PpkLS0o3aq3iXCq7eK5QFjXhREv81rTip4/m4zEfl6AdRIJhS5elKSQiz+yWWX1U JszBEROnzPL0rgKTu0GIfWsSfuMFkYI3F7qCZQzHJbq8qwQoUVQ4PRc/RwI7bpMxRg77 oh2w== 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=EH7jEXZyZKvAtUeW6cCFcLL4FqSd/A3iJEXYx8OljIU=; b=GVV83unpKRTHaJzs2VNVGYT2VTC/7YKHryECTXT4Ev33CDxQ0lPt08nbXDw/obi6Jf vRD8+N6BnJImFSQamQkl+rCr9FTz2GrSflOLRjrdGrefKwCjlcBeLjRZ2yYnwtg9bzWf eqEbhTXDKGIVqJxxdDYwIyUB2IK0ljE+2hOLUHD+w8cHxh533qVlUXvJEG1AQN3iqCLz 1Eg/o9m+CaOmLl0tSvQXR9FfE1xvFWlmqlwGfJkAWvhZQghkpiBK2iM4mbfcIygQ7ukR K9Kq8bJsMRjG2YeaWPbyC+0Z0exgGOMrS2OkbBxvMw+tHgr8XX6W2HTkJ0zA+16VPX5t 1Vqg== X-Gm-Message-State: APjAAAXQ0dL9ChHklgIoc1Scft8GYTp6rdf9iO+/r+UEz+40b0RAusxK 50f4UYe+HkWZA4zW+TXIu+re3OghepDpvAK0NMNafA== X-Google-Smtp-Source: APXvYqzk8uFHBlgCSkOhIBS0yK9rrT6iZ4LP/5820HUukPinkRV2mrldiC+qqlUOq9IXMLlrVSZEtFfD7KiLoS332ic= X-Received: by 2002:a67:ad03:: with SMTP id t3mr2771101vsl.159.1557424174870; Thu, 09 May 2019 10:49:34 -0700 (PDT) MIME-Version: 1.0 References: <20190506193115.20909-1-niklas.cassel@linaro.org> <20190508145600.GA26843@centauri> In-Reply-To: <20190508145600.GA26843@centauri> From: Amit Kucheria Date: Thu, 9 May 2019 23:19:23 +0530 Message-ID: Subject: Re: [PATCH] arm64: dts: qcom: qcs404: Add PSCI cpuidle support To: Niklas Cassel , Lorenzo Pieralisi , Sudeep Holla Cc: Andy Gross , David Brown , Rob Herring , Mark Rutland , Jorge Ramirez-Ortiz , Lina Iyer , Ulf Hansson , Bjorn Andersson , linux-arm-msm , DTML , Linux Kernel Mailing List 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 (Adding Lorenzo and Sudeep) On Wed, May 8, 2019 at 8:26 PM Niklas Cassel wrote: > > On Wed, May 08, 2019 at 02:48:19AM +0530, Amit Kucheria wrote: > > On Tue, May 7, 2019 at 1:01 AM Niklas Cassel wrote: > > > > > > Add device bindings for CPUs to suspend using PSCI as the enable-method. > > > > > > Signed-off-by: Niklas Cassel > > > --- > > > arch/arm64/boot/dts/qcom/qcs404.dtsi | 15 +++++++++++++++ > > > 1 file changed, 15 insertions(+) > > > > > > diff --git a/arch/arm64/boot/dts/qcom/qcs404.dtsi b/arch/arm64/boot/dts/qcom/qcs404.dtsi > > > index ffedf9640af7..f9db9f3ee10c 100644 > > > --- a/arch/arm64/boot/dts/qcom/qcs404.dtsi > > > +++ b/arch/arm64/boot/dts/qcom/qcs404.dtsi > > > @@ -31,6 +31,7 @@ > > > reg = <0x100>; > > > enable-method = "psci"; > > > next-level-cache = <&L2_0>; > > > + cpu-idle-states = <&CPU_PC>; > > > }; > > > > > > CPU1: cpu@101 { > > > @@ -39,6 +40,7 @@ > > > reg = <0x101>; > > > enable-method = "psci"; > > > next-level-cache = <&L2_0>; > > > + cpu-idle-states = <&CPU_PC>; > > > }; > > > > > > CPU2: cpu@102 { > > > @@ -47,6 +49,7 @@ > > > reg = <0x102>; > > > enable-method = "psci"; > > > next-level-cache = <&L2_0>; > > > + cpu-idle-states = <&CPU_PC>; > > > }; > > > > > > CPU3: cpu@103 { > > > @@ -55,12 +58,24 @@ > > > reg = <0x103>; > > > enable-method = "psci"; > > > next-level-cache = <&L2_0>; > > > + cpu-idle-states = <&CPU_PC>; > > > }; > > > > > > L2_0: l2-cache { > > > compatible = "cache"; > > > cache-level = <2>; > > > }; > > > + > > > + idle-states { > > > > entry-method="psci" property goes here. I have a patch fixing it for 410c ;-) > > > > I don't think the psci_cpuidle_ops will even get called without this. > > Hello Amit, > > I added debug prints in psci_cpu_suspend_enter() and arm_cpuidle_suspend() > when verifying this patch, and psci_cpu_suspend_enter() is indeed called, > with the correct psci suspend parameter. > > The output from: > grep "" /sys/bus/cpu/devices/cpu0/cpuidle/state?/* > also looks sane. > > However, if 'entry-method="psci"' is required according to the DT binding, > perhaps you can send a 2/2 series that fixes both this patch and msm8916 ? Last time I discussed this with Lorenzo and Sudeep (on IRC), I pointed out that entry-method="psci" isn't checked for in code anywhere. Let's get their view on this for posterity. What does entry-method="psci" in the idle-states node achieve that enable-method="psci" in the cpu node doesn't achieve? (Note: enable- vs. entry-). The enable-method property is the one that sets up the psci_cpuidle_ops callbacks through the CPUIDLE_METHOD_OF_DECLARE macro. IOW, if we deprecated the entry-method property, everything would still work, wouldn't it? Do we expect to support PSCI platforms that might have a different entry-method for idle states? Should I whip up a patch removing entry-method? Since we don't check for it today, it won't break the old DTs either. Regards, Amit > > Did you see any changes in consumption with this patch? I was trying > > to measure that before sending this out. > > I don't know of any way to measure the power consumption on this board, > so no, I haven't been able to verify that the firmware actually does > the right thing here. > > > Kind regards, > Niklas > > > > > > + CPU_PC: pc { > > > + compatible = "arm,idle-state"; > > > + arm,psci-suspend-param = <0x40000003>; > > > + entry-latency-us = <125>; > > > + exit-latency-us = <180>; > > > + min-residency-us = <595>; > > > + local-timer-stop; > > > + }; > > > + }; > > > }; > > > > > > firmware { > > > -- > > > 2.21.0 > > >