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=-5.2 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=unavailable 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 26700C76192 for ; Wed, 17 Jul 2019 17:19:10 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id F335921841 for ; Wed, 17 Jul 2019 17:19:09 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="GXI0yq4S" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org F335921841 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=jn/rlScOq8O6/z0PDe6V4kfb9CBQmttkCtQc1GqSExo=; b=GXI0yq4SykuWEp s0gcIwjxZceehoW+ab4qtvg0ge3tGSn06k3I/RpW42/z8DvPQZDFl9wRGRCPSnz0Dg3p6wID2GcAg 3J9nNtWIOR33cgHSbw4VuELam7HrSOigVXYxH9CzA0uToHyV96UpEVVjZQvT30JjRaqlnJ8oh5fUw XIFS6yqPWGsbkytABgOEYLWTVxdMvzX0yt589gCvR7Iu87Au1Lec7hMLwNg7cEbaBEUZHx4jI5AhU sdTDmvkoMqUpW8p7q43HOVutvkHCrrwRy6SQBCnzitkSExID0tfFsMSv4cJTkZ/dSslmjcJog+qHe lNNfdII8gzXxJjQxywuw==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92 #3 (Red Hat Linux)) id 1hnna8-0004Ps-L9; Wed, 17 Jul 2019 17:19:08 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.92 #3 (Red Hat Linux)) id 1hnna5-0004PU-8l for linux-arm-kernel@lists.infradead.org; Wed, 17 Jul 2019 17:19:06 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id ACFB728; Wed, 17 Jul 2019 10:19:01 -0700 (PDT) Received: from e107155-lin (e107155-lin.cambridge.arm.com [10.1.196.42]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id C30D73F71F; Wed, 17 Jul 2019 10:18:58 -0700 (PDT) Date: Wed, 17 Jul 2019 18:18:56 +0100 From: Sudeep Holla To: Lina Iyer Subject: Re: [PATCH 17/18] arm64: dts: Convert to the hierarchical CPU topology layout for MSM8916 Message-ID: <20190717171856.GF18370@e107155-lin> References: <20190513192300.653-1-ulf.hansson@linaro.org> <20190513192300.653-18-ulf.hansson@linaro.org> <20190716144730.GA7250@e107155-lin> <20190716203631.GC25567@codeaurora.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20190716203631.GC25567@codeaurora.org> User-Agent: Mutt/1.9.4 (2018-02-28) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190717_101905_404653_EF6BEBFB X-CRM114-Status: GOOD ( 20.54 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , Ulf Hansson , Geert Uytterhoeven , Tony Lindgren , Viresh Kumar , Bjorn Andersson , David Brown , Lina Iyer , Lorenzo Pieralisi , Kevin Hilman , Daniel Lezcano , Andy Gross , "Raju P . L . S . S . S . N" , Souvik Chakravarty , linux-pm@vger.kernel.org, linux-arm-msm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Stephen Boyd , "Rafael J . Wysocki" , linux-kernel@vger.kernel.org, Amit Kucheria , Niklas Cassel Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, Jul 16, 2019 at 02:36:31PM -0600, Lina Iyer wrote: > On Tue, Jul 16 2019 at 08:47 -0600, Sudeep Holla wrote: > > On Mon, May 13, 2019 at 09:22:59PM +0200, Ulf Hansson wrote: > > > From: Lina Iyer > > > > > > In the hierarchical layout, we are creating power domains around each CPU > > > and describes the idle states for them inside the power domain provider > > > node. Note that, the CPU's idle states still needs to be compatible with > > > "arm,idle-state". > > > > > > Furthermore, represent the CPU cluster as a separate master power domain, > > > powering the CPU's power domains. The cluster node, contains the idle > > > states for the cluster and each idle state needs to be compatible with the > > > "domain-idle-state". > > > > > > If the running platform is using a PSCI FW that supports the OS initiated > > > CPU suspend mode, which likely should be the case unless the PSCI FW is > > > very old, this change triggers the PSCI driver to enable it. > > > > > > Cc: Andy Gross > > > Cc: David Brown > > > Signed-off-by: Lina Iyer > > > Co-developed-by: Ulf Hansson > > > Signed-off-by: Ulf Hansson > > > --- > > > > [...] > > > > > @@ -166,12 +170,57 @@ > > > min-residency-us = <2000>; > > > local-timer-stop; > > > }; > > > + > > > + CLUSTER_RET: cluster-retention { > > > + compatible = "domain-idle-state"; > > > + arm,psci-suspend-param = <0x1000010>; > > > + entry-latency-us = <500>; > > > + exit-latency-us = <500>; > > > + min-residency-us = <2000>; > > > + }; > > > + > > > + CLUSTER_PWRDN: cluster-gdhs { > > > + compatible = "domain-idle-state"; > > > + arm,psci-suspend-param = <0x1000030>; > > > + entry-latency-us = <2000>; > > > + exit-latency-us = <2000>; > > > + min-residency-us = <6000>; > > > + }; > > > }; > > > }; > > > > I was trying to understand the composition of composite state parameters > > in this series and that made me look at these DT examples. > > > This was meant to depict a hierarchical state format for OSI. > Hmm, I am more confused. We have 2 formats: original and extended. 1. Original: 31:26 Reserved. Must be zero. 25:24 PowerLevel 23:17 Reserved. Must be zero. 16 StateType 15:0 StateID 2. Extended 31 Reserved. Must be zero. 30 StateType 29:28 Reserved. Must be zero. 27:0 StateID I was trying to match them to that. I think I commented on other patches. I think simple OR logic breaks with extended format easily if StateIDs are not carefully crafted which is not mandated and hence the trouble. The same holds to original format but with PowerLevel, it slightly relaxing things a bit but still it needs to be crafted when firmware decides these parameters. E.g.: what is done with HiKey platform is completely wrong. It's helpful if we want to avoid save/restore for retention states. CPU_PM_CPU_IDLE_ENTER_RETENTION vs CPU_PM_CPU_IDLE_ENTER > > What format does the above platform use ? I tried matching them to > > both original as well as extended format and I fail to understand. > > Assuming original format: > > State power_state PowerLevel StateType StateID > > SPC 0x40000002 0(core) 0(Retention) 0x2 (Res0 b[29]=1?) > > CLUSTER_RET 0x1000010 1(clusters) 0(Retention) 0x10 > > CLUSTER_PWRDN 0x1000030 1(clusters) 0(Retention?) 0x30 > > Now extended format: > > State power_state StateType StateID > > SPC 0x40000002 0(Retention) 0x40000002 (Res0 b[29]=1?) > > CLUSTER_RET 0x1000010 0(Retention) 0x1000010 > The composite state would comprise of CPU state and Cluster state. > So for the last CPU entering idle - > (CLUSTER_RET | SPC) > 0x41000012 > > CLUSTER_PWRDN 0x1000030 0(Retention?) 0x1000030 > > > (CLUSTER_PWRDN | SPC) > 0x41000032 > > Hope this helps. > I just follow OR logic. I have made wrong reference to bit 29 above(I can't read simple 32 bit number anymore :(), it should bit 30 and if this platform follow extended state, then it makes some sense. But I expect CLUSTER_PWRDN also to have bit 30 set. I tried to match to both formats and failed to understand which it follows, so thought of asking. -- Regards, Sudeep _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel