Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp5083665ybl; Tue, 4 Feb 2020 07:24:12 -0800 (PST) X-Google-Smtp-Source: APXvYqyw2FvjNS3hhRfqABfQ1bVX3h4oRWR0eLDuNxZo8qxWmlDPY46Szg1UmFBVc8VyuVYlXWlK X-Received: by 2002:aca:3f8b:: with SMTP id m133mr3681668oia.51.1580829852438; Tue, 04 Feb 2020 07:24:12 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1580829852; cv=none; d=google.com; s=arc-20160816; b=gatH+9f8DZk2BXEWGheGnJV+lFc9cOTfU0KXMh/IHNEDRRjptfA6K4h8v1cVnofMDd R0omjyff6b+J+hDlgqPwsgqvrLvtf1HSGe/9f6mrT2Sg06LOe5abVi1R1q7eBHzq1ncD BV3Sbyt7oZ4ALwEggrf7wEuSCTviKf2WJfMZTKncQn1gwzs7+ZCN4WZrSK4hYCBnOHQf 8Gk4JsltuyUGqk8YHkd4Xiyv/UtlQGnpTc9aSriw21kVg0KKs7dekChN2eCn+BCez0iZ 7sZB1b4SyCpAJBm4AYsbeXwjmtXGQ/AmVmZh01KaOBLYpkvJj3enGLEv8Pgy4DP7USZ3 rD9Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=xzz0vxCcuJDUthhrc8/23+u0NYwKl8lPOsndvBQe8nQ=; b=TLZTxJNlca89JjtwsxxUHGEgKH06yLczK4psRuvoJp5oIubpGhlsbX2ps9ISCQJqnT 4FMa751laoYlAF/+fwOfy3mRnjUZ5byKmjxheRrOx/LpU24EQiAYjkxZVOsj0o9ooTUV fVDgtiafH2spJs1sTknZ/8gMF8wrb5srt/8G44sodvPGdOfeJoROxbSBzYwoTzyStSL7 k937KTntgeFK1BwF8ZajiGXw3kslTiirjC0ghBVB+w2zMnVMRxnCvEtp4p824TlMPYDi rrC48J0humrpklTjTJgi8xGPv3Mu73PhnUbhmC5OQc+U++EqjGoEFUjSD4/QMK8aB6mR wP/w== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v25si11886503ote.90.2020.02.04.07.23.58; Tue, 04 Feb 2020 07:24:12 -0800 (PST) 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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727392AbgBDPVp (ORCPT + 99 others); Tue, 4 Feb 2020 10:21:45 -0500 Received: from foss.arm.com ([217.140.110.172]:38078 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727369AbgBDPVn (ORCPT ); Tue, 4 Feb 2020 10:21:43 -0500 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 EDA41101E; Tue, 4 Feb 2020 07:21:42 -0800 (PST) Received: from bogus (e103737-lin.cambridge.arm.com [10.1.197.49]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id BC71A3F52E; Tue, 4 Feb 2020 07:21:40 -0800 (PST) Date: Tue, 4 Feb 2020 15:21:32 +0000 From: Sudeep Holla To: Maulik Shah Cc: swboyd@chromium.org, agross@kernel.org, david.brown@linaro.org, Lorenzo.Pieralisi@arm.com, linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, bjorn.andersson@linaro.org, evgreen@chromium.org, dianders@chromium.org, rnayak@codeaurora.org, ilina@codeaurora.org, lsrao@codeaurora.org, ulf.hansson@linaro.org, rjw@rjwysocki.net, Sudeep Holla Subject: Re: [PATCH v3 5/7] drivers: firmware: psci: Add hierarchical domain idle states converter Message-ID: <20200204152132.GA44858@bogus> References: <1580736940-6985-1-git-send-email-mkshah@codeaurora.org> <1580736940-6985-6-git-send-email-mkshah@codeaurora.org> <20200203170832.GA38466@bogus> <0d7f7ade-3a1e-5428-d851-f1a886f58712@codeaurora.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0d7f7ade-3a1e-5428-d851-f1a886f58712@codeaurora.org> User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Feb 04, 2020 at 10:22:42AM +0530, Maulik Shah wrote: > > On 2/3/2020 10:38 PM, Sudeep Holla wrote: > > On Mon, Feb 03, 2020 at 07:05:38PM +0530, Maulik Shah wrote: > > > From: Ulf Hansson > > > > > > If the hierarchical CPU topology is used, but the OS initiated mode isn't > > > supported, we need to rely solely on the regular cpuidle framework to > > > manage the idle state selection, rather than using genpd and its > > > governor. > > > > > > For this reason, introduce a new PSCI DT helper function, > > > psci_dt_pm_domains_parse_states(), which parses and converts the > > > hierarchically described domain idle states from DT, into regular flattened > > > cpuidle states. The converted states are added to the existing cpuidle > > > driver's array of idle states, which make them available for cpuidle. > > > > > And what's the main motivation for this if OSI is not supported in the > > firmware ? > > Hi Sudeep, > > Main motivation is to do last-man activities before the CPU cluster can > enter a deep idle state. > Details on those last-man activities will help the discussion. Basically I am wondering what they are and why they need to done in OSPM ? > > > Signed-off-by: Ulf Hansson > > > [applied to new path, resolved conflicts] > > > Signed-off-by: Maulik Shah > > > --- > > > drivers/cpuidle/cpuidle-psci-domain.c | 137 +++++++++++++++++++++++++++++----- > > > drivers/cpuidle/cpuidle-psci.c | 41 +++++----- > > > drivers/cpuidle/cpuidle-psci.h | 11 +++ > > > 3 files changed, 153 insertions(+), 36 deletions(-) > > > > > > diff --git a/drivers/cpuidle/cpuidle-psci-domain.c b/drivers/cpuidle/cpuidle-psci-domain.c > > > index 423f03b..3c417f7 100644 > > > --- a/drivers/cpuidle/cpuidle-psci-domain.c > > > +++ b/drivers/cpuidle/cpuidle-psci-domain.c > > > @@ -26,13 +26,17 @@ struct psci_pd_provider { > > > }; > > > > > > static LIST_HEAD(psci_pd_providers); > > > -static bool osi_mode_enabled __initdata; > > > +static bool osi_mode_enabled; > > > > > > static int psci_pd_power_off(struct generic_pm_domain *pd) > > > { > > > struct genpd_power_state *state = &pd->states[pd->state_idx]; > > > u32 *pd_state; > > > > > > + /* If we have failed to enable OSI mode, then abort power off. */ > > > + if ((psci_has_osi_support()) && !osi_mode_enabled) > > > + return -EBUSY; > > > + > > Why is this needed ? IIUC we don't create genpd domains if OSI is not > > enabled. > > we do create genpd domains, for cpu domains, we just abort power off here > since idle states are converted into regular flattened mode. > OK, IIRC the OSI patches from Ulf didn't add the genpd or rather removed them in case of any failure to enable OSI. Has that been changed ? If so, why ? > however genpd poweroff will be used by parent domain (rsc in this case) > which is kept in hireachy in DTSI with cluster domain to do last man > activities. > I am bit confused here. Either we do OSI or PC and what you are describing sounds like a mix-n-match to me and I am totally against it. -- Regards, Sudeep