* Re: [RFD] Add debugfs for cpuidle ?
From: Rafael J. Wysocki @ 2018-05-24 9:39 UTC (permalink / raw)
To: Daniel Lezcano; +Cc: Linux Kernel Mailing List, Linux PM mailing list
In-Reply-To: <bcdbf067-4213-18ed-6d30-dc0dd2376c02@linaro.org>
On Thursday, May 24, 2018 10:47:54 AM CEST Daniel Lezcano wrote:
> On 24/05/2018 10:28, Rafael J. Wysocki wrote:
> > On Thursday, May 24, 2018 10:14:31 AM CEST Daniel Lezcano wrote:
> >>
> >> Hi all,
> >
> > Hi,
> >
> >> would it be interesting to add debugfs metrics for cpuidle in order
> >> to read some statistics from there and investigate the behavior ?
> >
> > What exactly would you like to see in there?
>
> It could be interesting to have statistics on a per cpu and global basis
> for:
>
> - prediction accuracy:
>
> /sys/kernel/debug/cpuidle/prediction/[good|over|under]
> /sys/kernel/debug/cpuidle/cpu*/state*/prediction/[good|over|under]
>
> - exit latency
>
> In addition, it is often the case the idle states values are dropped
> randomly, it is interesting to see the average exit latency for the
> states. That could give also an indication the cluster idle state success.
>
> /sys/kernel/debug/cpuidle/state*/latency/[min|max|avg|stddev]
> /sys/kernel/debug/cpuidle/cpu*/state*/prediction/[min|max|avg|stddev]
>
> And perhaps more information like the tick stopped stat ?
Fair enough, but that must be minimum overhead.
^ permalink raw reply
* Re: [PATCH] cpufreq: Rename cpufreq_can_do_remote_dvfs()
From: Rafael J. Wysocki @ 2018-05-24 9:38 UTC (permalink / raw)
To: Viresh Kumar
Cc: Ingo Molnar, Peter Zijlstra, linux-pm, Vincent Guittot,
Rafael J. Wysocki, linux-kernel
In-Reply-To: <17700bd99bc34e4e189b94b417591f328005ffbf.1526983276.git.viresh.kumar@linaro.org>
On Tuesday, May 22, 2018 12:01:30 PM CEST Viresh Kumar wrote:
> This routine checks if the CPU running this code belongs to the policy
> of the target CPU or if not, can it do remote DVFS for it remotely. But
> the current name of it implies as if it is only about doing remote
> updates.
>
> Rename it to make it more relevant.
>
> Reported-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> ---
> drivers/cpufreq/cpufreq_governor.c | 2 +-
> include/linux/cpufreq.h | 2 +-
> kernel/sched/cpufreq_schedutil.c | 2 +-
> 3 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/cpufreq/cpufreq_governor.c b/drivers/cpufreq/cpufreq_governor.c
> index ca38229b045a..871bf9cf55cf 100644
> --- a/drivers/cpufreq/cpufreq_governor.c
> +++ b/drivers/cpufreq/cpufreq_governor.c
> @@ -278,7 +278,7 @@ static void dbs_update_util_handler(struct update_util_data *data, u64 time,
> struct policy_dbs_info *policy_dbs = cdbs->policy_dbs;
> u64 delta_ns, lst;
>
> - if (!cpufreq_can_do_remote_dvfs(policy_dbs->policy))
> + if (!cpufreq_this_cpu_can_update(policy_dbs->policy))
> return;
>
> /*
> diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
> index 87f48dd932eb..882a9b9e34bc 100644
> --- a/include/linux/cpufreq.h
> +++ b/include/linux/cpufreq.h
> @@ -571,7 +571,7 @@ struct governor_attr {
> size_t count);
> };
>
> -static inline bool cpufreq_can_do_remote_dvfs(struct cpufreq_policy *policy)
> +static inline bool cpufreq_this_cpu_can_update(struct cpufreq_policy *policy)
> {
> /*
> * Allow remote callbacks if:
> diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c
> index 2442decbfec7..2145655dbd9e 100644
> --- a/kernel/sched/cpufreq_schedutil.c
> +++ b/kernel/sched/cpufreq_schedutil.c
> @@ -89,7 +89,7 @@ static bool sugov_should_update_freq(struct sugov_policy *sg_policy, u64 time)
> * schedule the kthread.
> */
> if (sg_policy->policy->fast_switch_enabled &&
> - !cpufreq_can_do_remote_dvfs(sg_policy->policy))
> + !cpufreq_this_cpu_can_update(sg_policy->policy))
> return false;
>
> if (sg_policy->work_in_progress)
>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH v11 1/2] cpufreq: Add Kryo CPU scaling driver
From: Sudeep Holla @ 2018-05-24 9:37 UTC (permalink / raw)
To: Viresh Kumar
Cc: Ilia Lin, vireshk, nm, sboyd, robh, mark.rutland, rjw, linux-pm,
devicetree, linux-kernel, Sudeep Holla
In-Reply-To: <20180524043443.adivshl2un53n6hm@vireshk-i7>
On Thu, May 24, 2018 at 10:04:43AM +0530, Viresh Kumar wrote:
> On 23-05-18, 14:25, Sudeep Holla wrote:
> > On 23/05/18 13:38, Ilia Lin wrote:
> > > +config ARM_QCOM_CPUFREQ_KRYO
> > > + bool "Qualcomm Kryo based CPUFreq"
> > > + depends on QCOM_QFPROM
> > > + depends on QCOM_SMEM
> > > + select PM_OPP
> > > + help
> > > + This adds the CPUFreq driver for Qualcomm Kryo SoC based boards.
> > > +
> > > + If in doubt, say N.
> > > +
> >
> > Sorry but just noticed now, any reason why this can't be module. I can't
> > imagine any.
>
> Actually I asked him to do that as cpufreq-dt itself can be compiled
> in as module and this driver wasn't doing much and isn't big enough
> (size wise) as well.
>
Initially I guessed that to be the reason, but not prevents this to be a
module. But you are right, the gain is not much as this driver is quite
small on it's own.
--
Regards,
Sudeep
^ permalink raw reply
* Re: [PATCH v1] cpufreq: tegra20: Fix imbalanced clock enable count
From: Rafael J. Wysocki @ 2018-05-24 9:36 UTC (permalink / raw)
To: Dmitry Osipenko
Cc: Viresh Kumar, Thierry Reding, Jonathan Hunter, linux-tegra,
linux-pm, linux-kernel
In-Reply-To: <db300fa3-ae83-059f-eae0-0808c3cb33fb@gmail.com>
On Wednesday, May 23, 2018 11:30:39 AM CEST Dmitry Osipenko wrote:
> On 23.05.2018 08:58, Viresh Kumar wrote:
> > On 23-05-18, 00:14, Dmitry Osipenko wrote:
> >> Tegra20-cpufreq driver missed enabling the CPU clocks. This results in a
> >> clock-enable refcount disbalance on PLL_P <-> PLL_X reparent, causing
> >> PLL_X to get disabled while it shouldn't. Fix this by enabling the clocks
> >> on the driver probe.
> >>
> >> Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
> >> ---
> >>
> >> CPUFreq maintainers,
> >>
> >> Please take into account that this patch is made on top of my recent
> >> series of patches [0] "Clean up Tegra20 cpufreq driver" that was fully
> >> reviewed, but seems not applied yet. Let me know if you prefer to re-spin
> >> the [0], including this patch into the series.
> >>
> >> [0] https://patchwork.ozlabs.org/project/linux-tegra/list/?series=45321
> >
> > This is already picked by Rafael and is sitting in pm/bleeding-edge
> > branch. Should get merged into linux-next in a day or two.
>
> Neat, thank you for letting me know.
It actually is there in my linux-next branch, but linux-next proper is not
taking new material this week AFAICS.
You'll see this in linux-next on Monday, most probably.
^ permalink raw reply
* Re: [PATCH 8/9] PM / Domains: Add support for multi PM domains per device to genpd
From: Jon Hunter @ 2018-05-24 9:36 UTC (permalink / raw)
To: Ulf Hansson
Cc: Rajendra Nayak, Geert Uytterhoeven, Linux PM, Greg Kroah-Hartman,
Kevin Hilman, Rafael J . Wysocki, Linux Kernel Mailing List,
Todor Tomov, Viresh Kumar, linux-tegra, Vincent Guittot,
Linux ARM
In-Reply-To: <CAPDyKFo8e5FMrxF2ggxVZ+HQjw4s1Wtx-tMf5ka67knJpZMQcA@mail.gmail.com>
On 24/05/18 08:04, Ulf Hansson wrote:
...
>> Any reason why we could not add a 'boolean' argument to the API to indicate
>> whether the new device should be linked? I think that I prefer the API
>> handles it, but I can see there could be instances where drivers may wish to
>> handle it themselves.
>
> Coming back to this question. Both Tegra XUSB and Qcom Camera use
> case, would benefit from doing the linking themselves, as it needs
> different PM domains to be powered on depending on the current use
> case - as to avoid wasting power.
>
> However, I can understand that you prefer some simplicity over
> optimizations, as you told us. Then, does it mean that you are
> insisting on extending the APIs with a boolean for linking, or are you
> fine with the driver to call device_link_add()?
I am fine with the driver calling device_link_add(), but I just wonder
if we will find a several drivers doing this and then we will end up
doing this later anyway.
The current API is called ...
* genpd_dev_pm_attach_by_id() - Attach a device to one of its PM domain.
* @dev: Device to attach.
* @index: The index of the PM domain.
This naming and description is a bit misleading, because really it is
not attaching the device that is passed, but creating a new device to
attach a PM domain to. So we should consider renaming and changing the
description and indicate that users need to link the device.
Finally, how is a PM domain attached via calling
genpd_dev_pm_attach_by_id() detached?
Cheers
Jon
--
nvpublic
^ permalink raw reply
* Re: [PATCH] tools/power/x86/intel_pstate_tracer: Add optional setting of trace buffer memory allocation
From: Rafael J. Wysocki @ 2018-05-24 9:34 UTC (permalink / raw)
To: Doug Smythies; +Cc: srinivas.pandruvada, dsmythies, linux-kernel, linux-pm
In-Reply-To: <23851272.hyr4RImLsD@aspire.rjw.lan>
On Sunday, May 13, 2018 10:43:02 AM CEST Rafael J. Wysocki wrote:
> On Friday, May 4, 2018 3:46:22 PM CEST Doug Smythies wrote:
> > Allow the user to override the default trace buffer memory allocation
> > by adding a command line option to override the default.
> >
> > The patch also:
> >
> > Adds a SIGINT (i.e. CTRL C exit) handler,
> > so that things can be cleaned up before exit.
> >
> > Moves the postion of some other cleanup from after to
> > before the potential "No valid data to plot" exit.
> >
> > Replaces all quit() calls with sys.exit, because
> > quit() is not supposed to be used in scripts.
> >
> > Signed-off-by: Doug Smythies <dsmythies@telus.net>
>
> Srinivas, any comments here?
No concerns, so applied. Thanks!
^ permalink raw reply
* Re: [PATCH v2] PM / AVS: rockchip-io: add io selectors and supplies for PX30
From: Rafael J. Wysocki @ 2018-05-24 9:31 UTC (permalink / raw)
To: Heiko Stuebner, David Wu
Cc: khilman, rafael.j.wysocki, nm, robh+dt, mark.rutland, huangtao,
linux-rockchip, linux-pm, linux-arm-kernel, linux-kernel
In-Reply-To: <1899248.qiidGlqZWz@phil>
On Tuesday, May 15, 2018 1:51:26 PM CEST Heiko Stuebner wrote:
> Hi David,
>
> Am Dienstag, 15. Mai 2018, 13:48:19 CEST schrieb David Wu:
> > This adds the necessary data for handling io voltage domains on PX30.
> > As interesting tidbit, the PX30 contains two separate iodomain areas.
> > One in the regular General Register Files (GRF) and one in PMUGRF in the
> > pmu power domain.
> >
> > Signed-off-by: David Wu <david.wu@rock-chips.com>
>
> thanks for the fast respin, looks great now.
>
> Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Applied, thanks!
^ permalink raw reply
* Re: OMAP serial runtime PM and autosuspend (was: Re: [PATCH 4/7] dt-bindings: gnss: add u-blox binding))
From: Johan Hovold @ 2018-05-24 9:17 UTC (permalink / raw)
To: Tony Lindgren
Cc: Johan Hovold, Sebastian Reichel, H. Nikolaus Schaller,
Andreas Kemnade, Mark Rutland, Arnd Bergmann, Pavel Machek,
linux-kernel@vger.kernel.org,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Greg Kroah-Hartman, Rob Herring, linux-serial, linux-omap,
linux-pm
In-Reply-To: <20180521154832.GY98604@atomide.com>
On Mon, May 21, 2018 at 08:48:32AM -0700, Tony Lindgren wrote:
> * Johan Hovold <johan@kernel.org> [180521 13:50]:
> > On Thu, May 17, 2018 at 10:10:38AM -0700, Tony Lindgren wrote:
> > > * Johan Hovold <johan@kernel.org> [180517 10:12]:
> > > Well in that case we should just stick with -1 value for the
> > > autosuspend. And just do pm_runtime_put_sync_suspend() after
> > > probe and on close.
> >
> > That won't work either as a negative autosuspend delay prevents runtime
> > suspend completely (by grabbing an extra RPM reference).
>
> Well so negative autosuspend delay is working as documented then :)
Yes, indeed. All too well. ;)
> > > > I fail to see how we can implement this using the current toolbox. What
> > > > you're after here is really a mechanism for selecting between two
> > > > different runtime PM schemes at runtime:
> > > >
> > > > 1. normal serial RPM, where the controller is active while the
> > > > port is open (this should be the safe default)
> > >
> > > Agreed. And that is the case already.
> >
> > Yes, but it's not really the case today as since omap-serial (and
> > 8250-omap) sets a negative autosuspend at probe and hence does not
> > runtime-suspend when the port is closed. So that's the long-standing bug
> > which needs fixing.
>
> Yes the bug for closed ports needs to be fixed for sure.
I did some forensic on this and it seems this problem has "always" been
there. Specifically, closed ports have never been runtime suspended
unless a non-negative autosuspend delay has been set by user space since
fcdca75728ac ("ARM: OMAP2+: UART: Add runtime pm support for omap-serial
driver") which was merged seven years ago.
So while it would certainly be nice to save some more power by default,
this would really be a new feature rather than a bug or regression fix
(which reduces the urgency for this issue somewhat too).
> > > > 2. aggressive serial RPM, where the controller is allowed to
> > > > suspend while the port is open even though this may result in
> > > > lost characters when waking up on incoming data
> > >
> > > In this case it seems that the only thing needed is to just
> > > configure the autosuspend delay for the parent port. The use of
> > > -1 has been around since the start of runtime PM AFAIK, so maybe
> > > we should just document it. I guess we could also introduce
> > > pm_runtime_block_autoidle_unless_configured() :)
> >
> > The implications of a negative autosuspend delay are already documented
> > (in Documentation/power/runtime_pm.txt); it's just the omap drivers that
> > gets it wrong when trying to do things which aren't currently supported
> > (and never have been).
> >
> > So I still think we need a new mechanism for this.
>
> Well if you have some better mechanism in mind let's try it out. Short of
> sprinkling pm_runtime_force_suspend/resume calls all over, I'm out of ideas
> right now.
Yeah, that would be too much of a hack and likely wouldn't work either
(and we really should do away with those _force calls altogether).
I've been thinking a bit too much about this already, but it may be
possible to use the pm QoS framework for this. A resume latency can be
set through sysfs where "n/a" is defined to mean "no latency accepted"
(i.e. controller remains always-on while port is open) and "0" means
"any latency accepted" (i.e. omap aggressive serial RPM is allowed).
Now, implementing this may get a little tricky as we want to be able to
change this setting on the fly (consider consoles) and we need to figure
out the interaction with serdev (user space should probably not be
allowed to request a resume latency for ports used by serdev).
I'd be happy to dig into this some more, but not in my spare time I'm
afraid.
> > > > For normal ttys, we need a user-space interface for selecting between
> > > > the two, and for serdev we may want a way to select the RPM scheme from
> > > > within the kernel.
> > > >
> > > > Note that with my serdev controller runtime PM patch, serdev core could
> > > > always opt for aggressive PM (as by default serdev core holds an RPM
> > > > reference for the controller while the port is open).
> > >
> > > So if your serdev controller was to set the parent autosuspend
> > > delay on open() and set it back on close() this should work?
> >
> > Is it really the job of a serdev driver to set the autosuspend delay of
> > a parent controller? Isn't this somethings which depends on the
> > characteristics of the controller (possibly configurable by user space)
> > such as the cost of runtime suspending and resuming?
>
> Only in some cases will the serdev driver know it's safe to configure
> the parent controller. Configuring the parent controller from userspace
> works just fine as we've seen for years now.
Yes, user space may override the default settings provided by the serial
driver, but a serdev driver, in contrast, knows nothing about the
underlying serial hardware.
> > The patch I posted works with what we have today; if a parent serial
> > controller driver uses aggressive runtime PM by default or after having
> > been configured through sysfs to do so.
>
> Yeah let's stick with configuring the parent controller from userspace
> for now at least.
Yep, status quo works for the time being (since this isn't a
regression).
> > What I'm getting at here is that the delay should be set by the serial
> > driver implementing aggressive runtime PM. Then all we need is a
> > mechanism to determine whether an extra RPM reference should be taken at
> > tty open or not (configurable by user space, defaulting to yes).
>
> OK yeah some additional on/off switch seems to be missing here.
As mentioned above, PM QoS resume latency may possibly be used, and
otherwise me may able to define a new (generic) QoS flag for this.
> > Specifically, the serial drivers themselves would always use
> > autosuspend and not have to deal with supporting the two RPM schemes
> > (normal vs aggressive runtime PM).
>
> OK. So if I understand your idea right, we could have autosuspend timeout
> set to 3000ms in the 8250_omap.c but still default to RPM blocked?
> Then user can enable aggressive PM via /sys as desired, right?
Not RPM blocked; the ports must always be able to suspend when the port
is closed. But user space should be able to enable the aggressive
(active) runtime PM via sysfs independently of the autosuspend delay,
yes.
Thanks,
Johan
^ permalink raw reply
* Re: [PATCH v7 00/26] PM / Domains: Support hierarchical CPU arrangement (PSCI/ARM)
From: Ulf Hansson @ 2018-05-24 9:16 UTC (permalink / raw)
To: Sudeep Holla, Lorenzo Pieralisi, Mark Rutland, Lina Iyer
Cc: Ulf Hansson, Linux PM, Linux ARM, linux-arm-msm,
Linux Kernel Mailing List
In-Reply-To: <1523531671-27491-1-git-send-email-ulf.hansson@linaro.org>
Sudeep, Lorenzo, Mark
On 12 April 2018 at 13:14, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> Changes in v7:
> - Addressed comments concerning the PSCI changes from Mark Rutland, which moves
> the psci firmware driver to a new firmware subdir and change to force PSCI PC
> mode during boot to cope with kexec'ed booted kernels.
Are you guys happy in general with the PSCI specific parts from this
series? It would be nice if you could provide me with acks or
reviewed-by tags for the rest of them in such case.
I intend to re-post a new version very soon.
[...]
Kind regards
Uffe
^ permalink raw reply
* Re: [PATCH v3 18/27] xen: Adapt assembly for PIE support
From: Juergen Gross @ 2018-05-24 9:11 UTC (permalink / raw)
To: Thomas Garnier, Herbert Xu, David S . Miller, Thomas Gleixner,
Ingo Molnar, H . Peter Anvin, Peter Zijlstra, Josh Poimboeuf,
Greg Kroah-Hartman, Philippe Ombredanne, Kate Stewart,
Arnaldo Carvalho de Melo, Yonghong Song, Andrey Ryabinin,
Kees Cook, Tom Lendacky, Kirill A . Shutemov, Andy Lutomirski,
Dominik Brodowski, Borislav Petkov, Borislav Petkov,
Rafael J . Wysocki
Cc: linux-arch, kvm, linux-pm, x86, linux-doc, linux-kernel,
virtualization, linux-sparse, linux-crypto, kernel-hardening,
xen-devel
In-Reply-To: <20180523195421.180248-19-thgarnie@google.com>
On 23/05/18 21:54, Thomas Garnier wrote:
> Change the assembly code to use the new _ASM_MOVABS macro which get a
> symbol reference while being PIE compatible. Adapt the relocation tool
> to ignore 32-bit Xen code.
>
> Position Independent Executable (PIE) support will allow to extended the
> KASLR randomization range below the -2G memory limit.
>
> Signed-off-by: Thomas Garnier <thgarnie@google.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Juergen
^ permalink raw reply
* RE: [PATCH 2/2] soc: imx: add SCU power domains driver
From: A.s. Dong @ 2018-05-24 9:03 UTC (permalink / raw)
To: Ulf Hansson
Cc: Dong Aisheng, Kevin Hilman, Linux PM, Rafael J. Wysocki,
dl-linux-imx, Sascha Hauer, Fabio Estevam, Shawn Guo, Linux ARM
In-Reply-To: <CAPDyKFrZHB2ti75zQav_SSXndorV38TcXMCoRBvDzdE5SS-WhA@mail.gmail.com>
Hi Ulf,
> -----Original Message-----
> From: Ulf Hansson [mailto:ulf.hansson@linaro.org]
> Sent: Thursday, May 24, 2018 5:00 PM
> To: A.s. Dong <aisheng.dong@nxp.com>
> Cc: Linux ARM <linux-arm-kernel@lists.infradead.org>; Dong Aisheng
> <dongas86@gmail.com>; Sascha Hauer <kernel@pengutronix.de>; Shawn
> Guo <shawnguo@kernel.org>; Fabio Estevam <fabio.estevam@nxp.com>;
> dl-linux-imx <linux-imx@nxp.com>; Rafael J. Wysocki <rjw@rjwysocki.net>;
> Kevin Hilman <khilman@kernel.org>; Linux PM <linux-pm@vger.kernel.org>
> Subject: Re: [PATCH 2/2] soc: imx: add SCU power domains driver
>
> On 24 May 2018 at 10:37, A.s. Dong <aisheng.dong@nxp.com> wrote:
> > Hi Ulf,
> >
> > Thanks for the review.
> >
> >> -----Original Message-----
> >> From: Ulf Hansson [mailto:ulf.hansson@linaro.org]
> >> Sent: Wednesday, May 9, 2018 3:16 AM
> >> To: A.s. Dong <aisheng.dong@nxp.com>
> >> Cc: Linux ARM <linux-arm-kernel@lists.infradead.org>; Dong Aisheng
> >> <dongas86@gmail.com>; Sascha Hauer <kernel@pengutronix.de>; Shawn
> Guo
> >> <shawnguo@kernel.org>; Fabio Estevam <fabio.estevam@nxp.com>;
> >> dl-linux-imx <linux-imx@nxp.com>; Rafael J. Wysocki
> >> <rjw@rjwysocki.net>; Kevin Hilman <khilman@kernel.org>; Linux PM
> >> <linux-pm@vger.kernel.org>
> >> Subject: Re: [PATCH 2/2] soc: imx: add SCU power domains driver
> >>
> >> [...]
> >>
> >> > +
> >> > +static int __init imx_sc_init_pm_domains(void) {
> >> > + struct generic_pm_domain *pd;
> >> > + struct device_node *np;
> >> > + sc_err_t sci_err;
> >> > +
> >> > + if (!of_machine_is_compatible("fsl,imx8qxp"))
> >> > + return 0;
> >> > +
> >> > + sci_err = sc_ipc_get_handle(&pm_ipc_handle);
> >> > + if (sci_err != SC_ERR_NONE) {
> >> > + pr_err("imx_sc_pd: can't get sc ipc handle\n");
> >> > + return -ENODEV;
> >> > + }
> >> > +
> >> > + for_each_matching_node(np, imx_sc_pm_domain_of_match) {
> >> > + pd = imx_sc_pm_add_one_domain(np, NULL);
> >> > + if (!IS_ERR(pd))
> >> > + imx_sc_pm_add_subdomains(np, pd);
> >> > + }
> >>
> >> Perhaps using of_genpd_add_subdomain() may help here and possibly
> >> could avoid some open coding!?
> >>
> >
> > Thanks for the suggestion. I thought of it a lot and the result is
> > that I'm not sure If it's quite suitable for i.MX cases. Currently
> > seems there's only one user, Samsung, in kernel using that API which
> > takes two struct of_phandle_args as arguments, parent and child. It looks
> needs special handling in code before using it, e.g.
> > register both parent and child domain first, which is somehow not like
> > i.MX flow of registration. It looks like to me not see much benefits
> > to enforce a big change to switch to it. Or am I missed anything?
>
> It's up to you. The idea was to make the code easier and a bit future proof.
> Perhaps that isn't suitable here.
>
> In any case, if you have a device node and all power-domain providers are
> listed below it, one can call for_each_child_of_node() and search for
> provider nodes hierarchically. I thought that is kind of nice.
>
> Something along the lines of what I done in psci_dt_set_genpd_topology(),
> from a patch I posted a while ago:
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpat
> chwork.kernel.org%2Fpatch%2F10338399%2F&data=02%7C01%7Caisheng.do
> ng%40nxp.com%7C0ce43cb8f66740a0f95908d5c154c330%7C686ea1d3bc2b4c
> 6fa92cd99c5c301635%7C0%7C1%7C636627492163349262&sdata=sk9U7c5VQ
> WKJN1UMOMUIXZh0nnpiWGX7ildx2Zzo4dc%3D&reserved=0
>
Thanks for the info. Will have a look at it.
> [...]
>
> If you decide to sticking to the existing way, anyway feel free to add:
>
> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
>
Thanks
Regards
Dong Aisheng
> Kind regards
> Uffe
^ permalink raw reply
* Re: [PATCH v12 0/2] Kryo CPU scaling driver
From: Viresh Kumar @ 2018-05-24 9:02 UTC (permalink / raw)
To: Ilia Lin
Cc: vireshk, nm, sboyd, robh, mark.rutland, rjw, linux-pm, devicetree,
linux-kernel
In-Reply-To: <1527152242-31281-1-git-send-email-ilialin@codeaurora.org>
On 24-05-18, 11:57, Ilia Lin wrote:
> [v12]
> * Addressed comments from Sudeep and Viresh about the single init
>
> [v11]
> * Addressed comment from Russel about device_node reference
> * Addressed comment from Sudeep about the late_initcall
> * Transformed init into probe to take care of deferals
>
> [v10]
> * Split the series into domains
> * Addressed comments from Viresh and Sudeep about logical CPU numbering.
>
> The qcom-cpufreq-kryo driver is aimed to support different SOC versions.
> The driver reads eFuse information and chooses the required OPP subset
> by passing the OPP supported-hw parameter.
>
> The series depends on the series from Viresh:
> https://patchwork.kernel.org/patch/10418139/
>
> The previous spin was here:
> https://patchwork.kernel.org/patch/10421143/
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
--
viresh
^ permalink raw reply
* Re: [PATCH 2/2] soc: imx: add SCU power domains driver
From: Ulf Hansson @ 2018-05-24 9:00 UTC (permalink / raw)
To: A.s. Dong
Cc: Dong Aisheng, Kevin Hilman, Linux PM, Rafael J. Wysocki,
dl-linux-imx, Sascha Hauer, Fabio Estevam, Shawn Guo, Linux ARM
In-Reply-To: <AM0PR04MB42114331A1E75B3B90B07E56806A0@AM0PR04MB4211.eurprd04.prod.outlook.com>
On 24 May 2018 at 10:37, A.s. Dong <aisheng.dong@nxp.com> wrote:
> Hi Ulf,
>
> Thanks for the review.
>
>> -----Original Message-----
>> From: Ulf Hansson [mailto:ulf.hansson@linaro.org]
>> Sent: Wednesday, May 9, 2018 3:16 AM
>> To: A.s. Dong <aisheng.dong@nxp.com>
>> Cc: Linux ARM <linux-arm-kernel@lists.infradead.org>; Dong Aisheng
>> <dongas86@gmail.com>; Sascha Hauer <kernel@pengutronix.de>; Shawn
>> Guo <shawnguo@kernel.org>; Fabio Estevam <fabio.estevam@nxp.com>;
>> dl-linux-imx <linux-imx@nxp.com>; Rafael J. Wysocki <rjw@rjwysocki.net>;
>> Kevin Hilman <khilman@kernel.org>; Linux PM <linux-pm@vger.kernel.org>
>> Subject: Re: [PATCH 2/2] soc: imx: add SCU power domains driver
>>
>> [...]
>>
>> > +
>> > +static int __init imx_sc_init_pm_domains(void) {
>> > + struct generic_pm_domain *pd;
>> > + struct device_node *np;
>> > + sc_err_t sci_err;
>> > +
>> > + if (!of_machine_is_compatible("fsl,imx8qxp"))
>> > + return 0;
>> > +
>> > + sci_err = sc_ipc_get_handle(&pm_ipc_handle);
>> > + if (sci_err != SC_ERR_NONE) {
>> > + pr_err("imx_sc_pd: can't get sc ipc handle\n");
>> > + return -ENODEV;
>> > + }
>> > +
>> > + for_each_matching_node(np, imx_sc_pm_domain_of_match) {
>> > + pd = imx_sc_pm_add_one_domain(np, NULL);
>> > + if (!IS_ERR(pd))
>> > + imx_sc_pm_add_subdomains(np, pd);
>> > + }
>>
>> Perhaps using of_genpd_add_subdomain() may help here and possibly could
>> avoid some open coding!?
>>
>
> Thanks for the suggestion. I thought of it a lot and the result is that I'm not sure
> If it's quite suitable for i.MX cases. Currently seems there's only one user, Samsung,
> in kernel using that API which takes two struct of_phandle_args as arguments,
> parent and child. It looks needs special handling in code before using it, e.g.
> register both parent and child domain first, which is somehow not like i.MX flow
> of registration. It looks like to me not see much benefits to enforce a big
> change to switch to it. Or am I missed anything?
It's up to you. The idea was to make the code easier and a bit future
proof. Perhaps that isn't suitable here.
In any case, if you have a device node and all power-domain providers
are listed below it, one can call for_each_child_of_node() and search
for provider nodes hierarchically. I thought that is kind of nice.
Something along the lines of what I done in
psci_dt_set_genpd_topology(), from a patch I posted a while ago:
https://patchwork.kernel.org/patch/10338399/
[...]
If you decide to sticking to the existing way, anyway feel free to add:
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Kind regards
Uffe
^ permalink raw reply
* [PATCH v12 2/2] dt-bindings: cpufreq: Document operating-points-v2-kryo-cpu
From: Ilia Lin @ 2018-05-24 8:57 UTC (permalink / raw)
To: vireshk, nm, sboyd, robh, mark.rutland, rjw
Cc: linux-pm, devicetree, linux-kernel, ilialin
In-Reply-To: <1527152242-31281-1-git-send-email-ilialin@codeaurora.org>
The qcom-cpufreq-kryo driver reads the msm-id and efuse value from the SoC
to provide the OPP framework with required information.
This is used to determine the voltage and frequency value for each OPP of
operating-points-v2 table when it is parsed by the OPP framework.
This change adds documentation for the DT bindings.
The "operating-points-v2-kryo-cpu" DT extends the "operating-points-v2"
with following parameters:
- nvmem-cells (NVMEM area containig the speedbin information)
- opp-supported-hw: A single 32 bit bitmap value,
representing compatible HW:
0: MSM8996 V3, speedbin 0
1: MSM8996 V3, speedbin 1
2: MSM8996 V3, speedbin 2
3: unused
4: MSM8996 SG, speedbin 0
5: MSM8996 SG, speedbin 1
6: MSM8996 SG, speedbin 2
7-31: unused
Signed-off-by: Ilia Lin <ilialin@codeaurora.org>
Reviewed-by: Rob Herring <robh@kernel.org>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
---
.../devicetree/bindings/opp/kryo-cpufreq.txt | 680 +++++++++++++++++++++
1 file changed, 680 insertions(+)
create mode 100644 Documentation/devicetree/bindings/opp/kryo-cpufreq.txt
diff --git a/Documentation/devicetree/bindings/opp/kryo-cpufreq.txt b/Documentation/devicetree/bindings/opp/kryo-cpufreq.txt
new file mode 100644
index 0000000..c2127b9
--- /dev/null
+++ b/Documentation/devicetree/bindings/opp/kryo-cpufreq.txt
@@ -0,0 +1,680 @@
+Qualcomm Technologies, Inc. KRYO CPUFreq and OPP bindings
+===================================
+
+In Certain Qualcomm Technologies, Inc. SoCs like apq8096 and msm8996
+that have KRYO processors, the CPU ferequencies subset and voltage value
+of each OPP varies based on the silicon variant in use.
+Qualcomm Technologies, Inc. Process Voltage Scaling Tables
+defines the voltage and frequency value based on the msm-id in SMEM
+and speedbin blown in the efuse combination.
+The qcom-cpufreq-kryo driver reads the msm-id and efuse value from the SoC
+to provide the OPP framework with required information (existing HW bitmap).
+This is used to determine the voltage and frequency value for each OPP of
+operating-points-v2 table when it is parsed by the OPP framework.
+
+Required properties:
+--------------------
+In 'cpus' nodes:
+- operating-points-v2: Phandle to the operating-points-v2 table to use.
+
+In 'operating-points-v2' table:
+- compatible: Should be
+ - 'operating-points-v2-kryo-cpu' for apq8096 and msm8996.
+- nvmem-cells: A phandle pointing to a nvmem-cells node representing the
+ efuse registers that has information about the
+ speedbin that is used to select the right frequency/voltage
+ value pair.
+ Please refer the for nvmem-cells
+ bindings Documentation/devicetree/bindings/nvmem/nvmem.txt
+ and also examples below.
+
+In every OPP node:
+- opp-supported-hw: A single 32 bit bitmap value, representing compatible HW.
+ Bitmap:
+ 0: MSM8996 V3, speedbin 0
+ 1: MSM8996 V3, speedbin 1
+ 2: MSM8996 V3, speedbin 2
+ 3: unused
+ 4: MSM8996 SG, speedbin 0
+ 5: MSM8996 SG, speedbin 1
+ 6: MSM8996 SG, speedbin 2
+ 7-31: unused
+
+Example 1:
+---------
+
+ cpus {
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ CPU0: cpu@0 {
+ device_type = "cpu";
+ compatible = "qcom,kryo";
+ reg = <0x0 0x0>;
+ enable-method = "psci";
+ clocks = <&kryocc 0>;
+ cpu-supply = <&pm8994_s11_saw>;
+ operating-points-v2 = <&cluster0_opp>;
+ #cooling-cells = <2>;
+ next-level-cache = <&L2_0>;
+ L2_0: l2-cache {
+ compatible = "cache";
+ cache-level = <2>;
+ };
+ };
+
+ CPU1: cpu@1 {
+ device_type = "cpu";
+ compatible = "qcom,kryo";
+ reg = <0x0 0x1>;
+ enable-method = "psci";
+ clocks = <&kryocc 0>;
+ cpu-supply = <&pm8994_s11_saw>;
+ operating-points-v2 = <&cluster0_opp>;
+ #cooling-cells = <2>;
+ next-level-cache = <&L2_0>;
+ };
+
+ CPU2: cpu@100 {
+ device_type = "cpu";
+ compatible = "qcom,kryo";
+ reg = <0x0 0x100>;
+ enable-method = "psci";
+ clocks = <&kryocc 1>;
+ cpu-supply = <&pm8994_s11_saw>;
+ operating-points-v2 = <&cluster1_opp>;
+ #cooling-cells = <2>;
+ next-level-cache = <&L2_1>;
+ L2_1: l2-cache {
+ compatible = "cache";
+ cache-level = <2>;
+ };
+ };
+
+ CPU3: cpu@101 {
+ device_type = "cpu";
+ compatible = "qcom,kryo";
+ reg = <0x0 0x101>;
+ enable-method = "psci";
+ clocks = <&kryocc 1>;
+ cpu-supply = <&pm8994_s11_saw>;
+ operating-points-v2 = <&cluster1_opp>;
+ #cooling-cells = <2>;
+ next-level-cache = <&L2_1>;
+ };
+
+ cpu-map {
+ cluster0 {
+ core0 {
+ cpu = <&CPU0>;
+ };
+
+ core1 {
+ cpu = <&CPU1>;
+ };
+ };
+
+ cluster1 {
+ core0 {
+ cpu = <&CPU2>;
+ };
+
+ core1 {
+ cpu = <&CPU3>;
+ };
+ };
+ };
+ };
+
+ cluster0_opp: opp_table0 {
+ compatible = "operating-points-v2-kryo-cpu";
+ nvmem-cells = <&speedbin_efuse>;
+ opp-shared;
+
+ opp-307200000 {
+ opp-hz = /bits/ 64 <307200000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x77>;
+ clock-latency-ns = <200000>;
+ };
+ opp-384000000 {
+ opp-hz = /bits/ 64 <384000000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-422400000 {
+ opp-hz = /bits/ 64 <422400000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-460800000 {
+ opp-hz = /bits/ 64 <460800000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-480000000 {
+ opp-hz = /bits/ 64 <480000000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-537600000 {
+ opp-hz = /bits/ 64 <537600000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-556800000 {
+ opp-hz = /bits/ 64 <556800000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-614400000 {
+ opp-hz = /bits/ 64 <614400000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-652800000 {
+ opp-hz = /bits/ 64 <652800000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-691200000 {
+ opp-hz = /bits/ 64 <691200000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-729600000 {
+ opp-hz = /bits/ 64 <729600000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-768000000 {
+ opp-hz = /bits/ 64 <768000000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-844800000 {
+ opp-hz = /bits/ 64 <844800000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x77>;
+ clock-latency-ns = <200000>;
+ };
+ opp-902400000 {
+ opp-hz = /bits/ 64 <902400000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-960000000 {
+ opp-hz = /bits/ 64 <960000000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-979200000 {
+ opp-hz = /bits/ 64 <979200000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1036800000 {
+ opp-hz = /bits/ 64 <1036800000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1056000000 {
+ opp-hz = /bits/ 64 <1056000000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1113600000 {
+ opp-hz = /bits/ 64 <1113600000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1132800000 {
+ opp-hz = /bits/ 64 <1132800000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1190400000 {
+ opp-hz = /bits/ 64 <1190400000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1209600000 {
+ opp-hz = /bits/ 64 <1209600000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1228800000 {
+ opp-hz = /bits/ 64 <1228800000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1286400000 {
+ opp-hz = /bits/ 64 <1286400000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1324800000 {
+ opp-hz = /bits/ 64 <1324800000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x5>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1363200000 {
+ opp-hz = /bits/ 64 <1363200000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x72>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1401600000 {
+ opp-hz = /bits/ 64 <1401600000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x5>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1440000000 {
+ opp-hz = /bits/ 64 <1440000000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1478400000 {
+ opp-hz = /bits/ 64 <1478400000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x1>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1497600000 {
+ opp-hz = /bits/ 64 <1497600000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x4>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1516800000 {
+ opp-hz = /bits/ 64 <1516800000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1593600000 {
+ opp-hz = /bits/ 64 <1593600000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x71>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1996800000 {
+ opp-hz = /bits/ 64 <1996800000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x20>;
+ clock-latency-ns = <200000>;
+ };
+ opp-2188800000 {
+ opp-hz = /bits/ 64 <2188800000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x10>;
+ clock-latency-ns = <200000>;
+ };
+ };
+
+ cluster1_opp: opp_table1 {
+ compatible = "operating-points-v2-kryo-cpu";
+ nvmem-cells = <&speedbin_efuse>;
+ opp-shared;
+
+ opp-307200000 {
+ opp-hz = /bits/ 64 <307200000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x77>;
+ clock-latency-ns = <200000>;
+ };
+ opp-384000000 {
+ opp-hz = /bits/ 64 <384000000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-403200000 {
+ opp-hz = /bits/ 64 <403200000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-460800000 {
+ opp-hz = /bits/ 64 <460800000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-480000000 {
+ opp-hz = /bits/ 64 <480000000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-537600000 {
+ opp-hz = /bits/ 64 <537600000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-556800000 {
+ opp-hz = /bits/ 64 <556800000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-614400000 {
+ opp-hz = /bits/ 64 <614400000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-652800000 {
+ opp-hz = /bits/ 64 <652800000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-691200000 {
+ opp-hz = /bits/ 64 <691200000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-729600000 {
+ opp-hz = /bits/ 64 <729600000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-748800000 {
+ opp-hz = /bits/ 64 <748800000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-806400000 {
+ opp-hz = /bits/ 64 <806400000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-825600000 {
+ opp-hz = /bits/ 64 <825600000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-883200000 {
+ opp-hz = /bits/ 64 <883200000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-902400000 {
+ opp-hz = /bits/ 64 <902400000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-940800000 {
+ opp-hz = /bits/ 64 <940800000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-979200000 {
+ opp-hz = /bits/ 64 <979200000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1036800000 {
+ opp-hz = /bits/ 64 <1036800000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1056000000 {
+ opp-hz = /bits/ 64 <1056000000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1113600000 {
+ opp-hz = /bits/ 64 <1113600000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1132800000 {
+ opp-hz = /bits/ 64 <1132800000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1190400000 {
+ opp-hz = /bits/ 64 <1190400000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1209600000 {
+ opp-hz = /bits/ 64 <1209600000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1248000000 {
+ opp-hz = /bits/ 64 <1248000000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1286400000 {
+ opp-hz = /bits/ 64 <1286400000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1324800000 {
+ opp-hz = /bits/ 64 <1324800000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1363200000 {
+ opp-hz = /bits/ 64 <1363200000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1401600000 {
+ opp-hz = /bits/ 64 <1401600000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1440000000 {
+ opp-hz = /bits/ 64 <1440000000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1478400000 {
+ opp-hz = /bits/ 64 <1478400000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1516800000 {
+ opp-hz = /bits/ 64 <1516800000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1555200000 {
+ opp-hz = /bits/ 64 <1555200000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1593600000 {
+ opp-hz = /bits/ 64 <1593600000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1632000000 {
+ opp-hz = /bits/ 64 <1632000000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1670400000 {
+ opp-hz = /bits/ 64 <1670400000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1708800000 {
+ opp-hz = /bits/ 64 <1708800000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1747200000 {
+ opp-hz = /bits/ 64 <1747200000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1785600000 {
+ opp-hz = /bits/ 64 <1785600000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1804800000 {
+ opp-hz = /bits/ 64 <1804800000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x6>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1824000000 {
+ opp-hz = /bits/ 64 <1824000000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x71>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1900800000 {
+ opp-hz = /bits/ 64 <1900800000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x74>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1920000000 {
+ opp-hz = /bits/ 64 <1920000000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x1>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1977600000 {
+ opp-hz = /bits/ 64 <1977600000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x30>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1996800000 {
+ opp-hz = /bits/ 64 <1996800000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x1>;
+ clock-latency-ns = <200000>;
+ };
+ opp-2054400000 {
+ opp-hz = /bits/ 64 <2054400000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x30>;
+ clock-latency-ns = <200000>;
+ };
+ opp-2073600000 {
+ opp-hz = /bits/ 64 <2073600000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x1>;
+ clock-latency-ns = <200000>;
+ };
+ opp-2150400000 {
+ opp-hz = /bits/ 64 <2150400000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x31>;
+ clock-latency-ns = <200000>;
+ };
+ opp-2246400000 {
+ opp-hz = /bits/ 64 <2246400000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x10>;
+ clock-latency-ns = <200000>;
+ };
+ opp-2342400000 {
+ opp-hz = /bits/ 64 <2342400000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x10>;
+ clock-latency-ns = <200000>;
+ };
+ };
+
+....
+
+reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+....
+ smem_mem: smem-mem@86000000 {
+ reg = <0x0 0x86000000 0x0 0x200000>;
+ no-map;
+ };
+....
+};
+
+smem {
+ compatible = "qcom,smem";
+ memory-region = <&smem_mem>;
+ hwlocks = <&tcsr_mutex 3>;
+};
+
+soc {
+....
+ qfprom: qfprom@74000 {
+ compatible = "qcom,qfprom";
+ reg = <0x00074000 0x8ff>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ....
+ speedbin_efuse: speedbin@133 {
+ reg = <0x133 0x1>;
+ bits = <5 3>;
+ };
+ };
+};
--
1.9.1
^ permalink raw reply related
* [PATCH v12 1/2] cpufreq: Add Kryo CPU scaling driver
From: Ilia Lin @ 2018-05-24 8:57 UTC (permalink / raw)
To: vireshk, nm, sboyd, robh, mark.rutland, rjw
Cc: linux-pm, devicetree, linux-kernel, ilialin
In-Reply-To: <1527152242-31281-1-git-send-email-ilialin@codeaurora.org>
In Certain QCOM SoCs like apq8096 and msm8996 that have KRYO processors,
the CPU frequency subset and voltage value of each OPP varies
based on the silicon variant in use. Qualcomm Process Voltage Scaling Tables
defines the voltage and frequency value based on the msm-id in SMEM
and speedbin blown in the efuse combination.
The qcom-cpufreq-kryo driver reads the msm-id and efuse value from the SoC
to provide the OPP framework with required information.
This is used to determine the voltage and frequency value for each OPP of
operating-points-v2 table when it is parsed by the OPP framework.
Signed-off-by: Ilia Lin <ilialin@codeaurora.org>
---
drivers/cpufreq/Kconfig.arm | 10 ++
drivers/cpufreq/Makefile | 1 +
drivers/cpufreq/cpufreq-dt-platdev.c | 3 +
drivers/cpufreq/qcom-cpufreq-kryo.c | 194 +++++++++++++++++++++++++++++++++++
4 files changed, 208 insertions(+)
create mode 100644 drivers/cpufreq/qcom-cpufreq-kryo.c
diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index de55c7d..0bfd40e 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -124,6 +124,16 @@ config ARM_OMAP2PLUS_CPUFREQ
depends on ARCH_OMAP2PLUS
default ARCH_OMAP2PLUS
+config ARM_QCOM_CPUFREQ_KRYO
+ bool "Qualcomm Kryo based CPUFreq"
+ depends on QCOM_QFPROM
+ depends on QCOM_SMEM
+ select PM_OPP
+ help
+ This adds the CPUFreq driver for Qualcomm Kryo SoC based boards.
+
+ If in doubt, say N.
+
config ARM_S3C_CPUFREQ
bool
help
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index 8d24ade..fb4a2ec 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -65,6 +65,7 @@ obj-$(CONFIG_MACH_MVEBU_V7) += mvebu-cpufreq.o
obj-$(CONFIG_ARM_OMAP2PLUS_CPUFREQ) += omap-cpufreq.o
obj-$(CONFIG_ARM_PXA2xx_CPUFREQ) += pxa2xx-cpufreq.o
obj-$(CONFIG_PXA3xx) += pxa3xx-cpufreq.o
+obj-$(CONFIG_ARM_QCOM_CPUFREQ_KRYO) += qcom-cpufreq-kryo.o
obj-$(CONFIG_ARM_S3C2410_CPUFREQ) += s3c2410-cpufreq.o
obj-$(CONFIG_ARM_S3C2412_CPUFREQ) += s3c2412-cpufreq.o
obj-$(CONFIG_ARM_S3C2416_CPUFREQ) += s3c2416-cpufreq.o
diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c b/drivers/cpufreq/cpufreq-dt-platdev.c
index 3b585e4..77d6ab8 100644
--- a/drivers/cpufreq/cpufreq-dt-platdev.c
+++ b/drivers/cpufreq/cpufreq-dt-platdev.c
@@ -118,6 +118,9 @@
{ .compatible = "nvidia,tegra124", },
+ { .compatible = "qcom,apq8096", },
+ { .compatible = "qcom,msm8996", },
+
{ .compatible = "st,stih407", },
{ .compatible = "st,stih410", },
diff --git a/drivers/cpufreq/qcom-cpufreq-kryo.c b/drivers/cpufreq/qcom-cpufreq-kryo.c
new file mode 100644
index 0000000..9fe379c
--- /dev/null
+++ b/drivers/cpufreq/qcom-cpufreq-kryo.c
@@ -0,0 +1,194 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2018, The Linux Foundation. All rights reserved.
+ */
+
+/*
+ * In Certain QCOM SoCs like apq8096 and msm8996 that have KRYO processors,
+ * the CPU frequency subset and voltage value of each OPP varies
+ * based on the silicon variant in use. Qualcomm Process Voltage Scaling Tables
+ * defines the voltage and frequency value based on the msm-id in SMEM
+ * and speedbin blown in the efuse combination.
+ * The qcom-cpufreq-kryo driver reads the msm-id and efuse value from the SoC
+ * to provide the OPP framework with required information.
+ * This is used to determine the voltage and frequency value for each OPP of
+ * operating-points-v2 table when it is parsed by the OPP framework.
+ */
+
+#include <linux/cpu.h>
+#include <linux/err.h>
+#include <linux/init.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/nvmem-consumer.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/pm_opp.h>
+#include <linux/slab.h>
+#include <linux/soc/qcom/smem.h>
+
+#define MSM_ID_SMEM 137
+
+enum _msm_id {
+ MSM8996V3 = 0xF6ul,
+ APQ8096V3 = 0x123ul,
+ MSM8996SG = 0x131ul,
+ APQ8096SG = 0x138ul,
+};
+
+enum _msm8996_version {
+ MSM8996_V3,
+ MSM8996_SG,
+ NUM_OF_MSM8996_VERSIONS,
+};
+
+static enum _msm8996_version __init qcom_cpufreq_kryo_get_msm_id(void)
+{
+ size_t len;
+ u32 *msm_id;
+ enum _msm8996_version version;
+
+ msm_id = qcom_smem_get(QCOM_SMEM_HOST_ANY, MSM_ID_SMEM, &len);
+ /* The first 4 bytes are format, next to them is the actual msm-id */
+ msm_id++;
+
+ switch ((enum _msm_id)*msm_id) {
+ case MSM8996V3:
+ case APQ8096V3:
+ version = MSM8996_V3;
+ break;
+ case MSM8996SG:
+ case APQ8096SG:
+ version = MSM8996_SG;
+ break;
+ default:
+ version = NUM_OF_MSM8996_VERSIONS;
+ }
+
+ return version;
+}
+
+static int qcom_cpufreq_kryo_probe(struct platform_device *pdev)
+{
+ struct opp_table *opp_tables[NR_CPUS] = {0};
+ struct platform_device *cpufreq_dt_pdev;
+ enum _msm8996_version msm8996_version;
+ struct nvmem_cell *speedbin_nvmem;
+ struct device_node *np;
+ struct device *cpu_dev;
+ unsigned cpu;
+ u8 *speedbin;
+ u32 versions;
+ size_t len;
+ int ret;
+
+ cpu_dev = get_cpu_device(0);
+ if (NULL == cpu_dev)
+ return -ENODEV;
+
+ msm8996_version = qcom_cpufreq_kryo_get_msm_id();
+ if (NUM_OF_MSM8996_VERSIONS == msm8996_version) {
+ dev_err(cpu_dev, "Not Snapdragon 820/821!");
+ return -ENODEV;
+ }
+
+ np = dev_pm_opp_of_get_opp_desc_node(cpu_dev);
+ if (IS_ERR(np))
+ return PTR_ERR(np);
+
+ if (!of_device_is_compatible(np, "operating-points-v2-kryo-cpu")) {
+ of_node_put(np);
+ return -ENOENT;
+ }
+
+ speedbin_nvmem = of_nvmem_cell_get(np, NULL);
+ of_node_put(np);
+ if (IS_ERR(speedbin_nvmem)) {
+ dev_err(cpu_dev, "Could not get nvmem cell: %ld\n",
+ PTR_ERR(speedbin_nvmem));
+ return PTR_ERR(speedbin_nvmem);
+ }
+
+ speedbin = nvmem_cell_read(speedbin_nvmem, &len);
+ nvmem_cell_put(speedbin_nvmem);
+
+ switch (msm8996_version) {
+ case MSM8996_V3:
+ versions = 1 << (unsigned int)(*speedbin);
+ break;
+ case MSM8996_SG:
+ versions = 1 << ((unsigned int)(*speedbin) + 4);
+ break;
+ default:
+ BUG();
+ break;
+ }
+
+ for_each_possible_cpu(cpu) {
+ cpu_dev = get_cpu_device(cpu);
+ if (NULL == cpu_dev) {
+ ret = -ENODEV;
+ goto free_opp;
+ }
+
+ opp_tables[cpu] = dev_pm_opp_set_supported_hw(cpu_dev,
+ &versions, 1);
+ if (IS_ERR(opp_tables[cpu])) {
+ ret = PTR_ERR(opp_tables[cpu]);
+ dev_err(cpu_dev, "Failed to set supported hardware\n");
+ goto free_opp;
+ }
+ }
+
+ cpufreq_dt_pdev = platform_device_register_simple("cpufreq-dt", -1,
+ NULL, 0);
+ if (!IS_ERR(cpufreq_dt_pdev))
+ return 0;
+
+ ret = PTR_ERR(cpufreq_dt_pdev);
+ dev_err(cpu_dev, "Failed to register platform device\n");
+
+free_opp:
+ for_each_possible_cpu(cpu) {
+ if (IS_ERR_OR_NULL(opp_tables[cpu]))
+ break;
+ dev_pm_opp_put_supported_hw(opp_tables[cpu]);
+ }
+
+ return ret;
+}
+
+static struct platform_driver qcom_cpufreq_kryo_driver = {
+ .probe = qcom_cpufreq_kryo_probe,
+ .driver = {
+ .name = "qcom-cpufreq-kryo",
+ },
+};
+
+/*
+ * Since the driver depends on smem and nvmem drivers, which may
+ * return EPROBE_DEFER, all the real activity is done in the probe,
+ * which may be defered as well. The init here is only registering
+ * the driver and the platform device.
+ */
+static int __init qcom_cpufreq_kryo_init(void)
+{
+ int ret;
+
+ ret = platform_driver_register(&qcom_cpufreq_kryo_driver);
+ if (unlikely(ret < 0))
+ return ret;
+
+ ret = PTR_ERR_OR_ZERO(platform_device_register_simple(
+ "qcom-cpufreq-kryo", -1, NULL, 0));
+ if (unlikely(ret < 0)) {
+ platform_driver_unregister(&qcom_cpufreq_kryo_driver);
+ return ret;
+ }
+
+ return 0;
+}
+module_init(qcom_cpufreq_kryo_init);
+
+MODULE_DESCRIPTION("Qualcomm Technologies, Inc. Kryo CPUfreq driver");
+MODULE_LICENSE("GPL v2");
--
1.9.1
^ permalink raw reply related
* [PATCH v12 0/2] Kryo CPU scaling driver
From: Ilia Lin @ 2018-05-24 8:57 UTC (permalink / raw)
To: vireshk, nm, sboyd, robh, mark.rutland, rjw
Cc: linux-pm, devicetree, linux-kernel, ilialin
[v12]
* Addressed comments from Sudeep and Viresh about the single init
[v11]
* Addressed comment from Russel about device_node reference
* Addressed comment from Sudeep about the late_initcall
* Transformed init into probe to take care of deferals
[v10]
* Split the series into domains
* Addressed comments from Viresh and Sudeep about logical CPU numbering.
The qcom-cpufreq-kryo driver is aimed to support different SOC versions.
The driver reads eFuse information and chooses the required OPP subset
by passing the OPP supported-hw parameter.
The series depends on the series from Viresh:
https://patchwork.kernel.org/patch/10418139/
The previous spin was here:
https://patchwork.kernel.org/patch/10421143/
Ilia Lin (2):
cpufreq: Add Kryo CPU scaling driver
dt-bindings: cpufreq: Document operating-points-v2-kryo-cpu
.../devicetree/bindings/opp/kryo-cpufreq.txt | 680 +++++++++++++++++++++
drivers/cpufreq/Kconfig.arm | 10 +
drivers/cpufreq/Makefile | 1 +
drivers/cpufreq/cpufreq-dt-platdev.c | 3 +
drivers/cpufreq/qcom-cpufreq-kryo.c | 194 ++++++
5 files changed, 888 insertions(+)
create mode 100644 Documentation/devicetree/bindings/opp/kryo-cpufreq.txt
create mode 100644 drivers/cpufreq/qcom-cpufreq-kryo.c
--
1.9.1
^ permalink raw reply
* Re: [RFD] Add debugfs for cpuidle ?
From: Daniel Lezcano @ 2018-05-24 8:47 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: Linux Kernel Mailing List, Linux PM mailing list
In-Reply-To: <2682482.uFPN0cxrGI@aspire.rjw.lan>
On 24/05/2018 10:28, Rafael J. Wysocki wrote:
> On Thursday, May 24, 2018 10:14:31 AM CEST Daniel Lezcano wrote:
>>
>> Hi all,
>
> Hi,
>
>> would it be interesting to add debugfs metrics for cpuidle in order
>> to read some statistics from there and investigate the behavior ?
>
> What exactly would you like to see in there?
It could be interesting to have statistics on a per cpu and global basis
for:
- prediction accuracy:
/sys/kernel/debug/cpuidle/prediction/[good|over|under]
/sys/kernel/debug/cpuidle/cpu*/state*/prediction/[good|over|under]
- exit latency
In addition, it is often the case the idle states values are dropped
randomly, it is interesting to see the average exit latency for the
states. That could give also an indication the cluster idle state success.
/sys/kernel/debug/cpuidle/state*/latency/[min|max|avg|stddev]
/sys/kernel/debug/cpuidle/cpu*/state*/prediction/[min|max|avg|stddev]
And perhaps more information like the tick stopped stat ?
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
^ permalink raw reply
* RE: [PATCH 2/2] soc: imx: add SCU power domains driver
From: A.s. Dong @ 2018-05-24 8:37 UTC (permalink / raw)
To: Ulf Hansson
Cc: Dong Aisheng, Kevin Hilman, Linux PM, Rafael J. Wysocki,
dl-linux-imx, Sascha Hauer, Fabio Estevam, Shawn Guo, Linux ARM
In-Reply-To: <CAPDyKFowdpxwNMmDjdD3qcqnAcQZA9-MYWnTcZL-oSbwg8WYMg@mail.gmail.com>
Hi Ulf,
Thanks for the review.
> -----Original Message-----
> From: Ulf Hansson [mailto:ulf.hansson@linaro.org]
> Sent: Wednesday, May 9, 2018 3:16 AM
> To: A.s. Dong <aisheng.dong@nxp.com>
> Cc: Linux ARM <linux-arm-kernel@lists.infradead.org>; Dong Aisheng
> <dongas86@gmail.com>; Sascha Hauer <kernel@pengutronix.de>; Shawn
> Guo <shawnguo@kernel.org>; Fabio Estevam <fabio.estevam@nxp.com>;
> dl-linux-imx <linux-imx@nxp.com>; Rafael J. Wysocki <rjw@rjwysocki.net>;
> Kevin Hilman <khilman@kernel.org>; Linux PM <linux-pm@vger.kernel.org>
> Subject: Re: [PATCH 2/2] soc: imx: add SCU power domains driver
>
> [...]
>
> > +
> > +static int __init imx_sc_init_pm_domains(void) {
> > + struct generic_pm_domain *pd;
> > + struct device_node *np;
> > + sc_err_t sci_err;
> > +
> > + if (!of_machine_is_compatible("fsl,imx8qxp"))
> > + return 0;
> > +
> > + sci_err = sc_ipc_get_handle(&pm_ipc_handle);
> > + if (sci_err != SC_ERR_NONE) {
> > + pr_err("imx_sc_pd: can't get sc ipc handle\n");
> > + return -ENODEV;
> > + }
> > +
> > + for_each_matching_node(np, imx_sc_pm_domain_of_match) {
> > + pd = imx_sc_pm_add_one_domain(np, NULL);
> > + if (!IS_ERR(pd))
> > + imx_sc_pm_add_subdomains(np, pd);
> > + }
>
> Perhaps using of_genpd_add_subdomain() may help here and possibly could
> avoid some open coding!?
>
Thanks for the suggestion. I thought of it a lot and the result is that I'm not sure
If it's quite suitable for i.MX cases. Currently seems there's only one user, Samsung,
in kernel using that API which takes two struct of_phandle_args as arguments,
parent and child. It looks needs special handling in code before using it, e.g.
register both parent and child domain first, which is somehow not like i.MX flow
of registration. It looks like to me not see much benefits to enforce a big
change to switch to it. Or am I missed anything?
If you have better idea please let me know.
> > +
> > + return 0;
> > +}
> > +early_initcall(imx_sc_init_pm_domains);
>
> Otherwise this looks good to me!
>
Thanks
Regards
Dong Aisheng
> Kind regards
> Uffe
^ permalink raw reply
* Re: [PATCH v4 2/3] power: supply: add cros-ec USBPD charger driver.
From: Sebastian Reichel @ 2018-05-24 8:34 UTC (permalink / raw)
To: Enric Balletbo i Serra, Lee Jones
Cc: Gwendal Grignou, Sameer Nanda, linux-pm, Guenter Roeck,
linux-kernel, Benson Leung, miguel.ojeda.sandonis, kernel
In-Reply-To: <20180502154418.2153-3-enric.balletbo@collabora.com>
[-- Attachment #1: Type: text/plain, Size: 781 bytes --]
Hi,
On Wed, May 02, 2018 at 05:44:17PM +0200, Enric Balletbo i Serra wrote:
> From: Sameer Nanda <snanda@chromium.org>
>
> This driver gets various bits of information about what is connected to
> USB PD ports from the EC and converts that into power_supply properties.
>
> Signed-off-by: Sameer Nanda <snanda@chromium.org>
> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
> Acked-by: Lee Jones <lee.jones@linaro.org>
I suppose Lee's Ack was mainly for the no longer relevant MFD part
of this patch.
> ---
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
I would be fine with merging this for 4.18, but it has a dependency
on patch 1 for MFD. Lee, can you provide a immutable branch for
patch 1?
-- Sebastian
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [PATCH] PM / runtime: Drop usage count for suppliers at device link removal
From: Ulf Hansson @ 2018-05-24 8:33 UTC (permalink / raw)
To: Rafael J . Wysocki, Greg Kroah-Hartman, linux-pm
Cc: Ulf Hansson, Viresh Kumar, Vincent Guittot, Todor Tomov,
Rajendra Nayak, Jon Hunter, linux-kernel, linux-arm-kernel
In the case consumer device is runtime resumed, while the link to the
supplier is removed, the earlier call to pm_runtime_get_sync() made from
rpm_get_suppliers() does not get properly balanced with a corresponding
call to pm_runtime_put(). This leads to that suppliers remains to be
runtime resumed forever, while they don't need to.
Let's fix the behaviour by calling rpm_put_suppliers() when dropping a
device link. Not that, since rpm_put_suppliers() checks the
link->rpm_active flag, we can correctly avoid to call pm_runtime_put() in
cases when we shouldn't.
Reported-by: Todor Tomov <todor.tomov@linaro.org>
Fixes: 21d5c57b3726 ("PM / runtime: Use device links")
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
---
Rafael, I am not sure if this is safe from locking point of view. The device
link write lock has been taken when pm_runtime_drop_link() is called, hence I
assume calling rpm_put_suppliers() should be fine!? If not, can you please
advise how to change?
Kind regards
Uffe
---
drivers/base/power/runtime.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/base/power/runtime.c b/drivers/base/power/runtime.c
index 8bef3cb..beb85c3 100644
--- a/drivers/base/power/runtime.c
+++ b/drivers/base/power/runtime.c
@@ -1607,6 +1607,8 @@ void pm_runtime_new_link(struct device *dev)
void pm_runtime_drop_link(struct device *dev)
{
+ rpm_put_suppliers(dev);
+
spin_lock_irq(&dev->power.lock);
WARN_ON(dev->power.links_count == 0);
dev->power.links_count--;
--
2.7.4
^ permalink raw reply related
* Re: [RFD] Add debugfs for cpuidle ?
From: Rafael J. Wysocki @ 2018-05-24 8:28 UTC (permalink / raw)
To: Daniel Lezcano; +Cc: Linux Kernel Mailing List, Linux PM mailing list
In-Reply-To: <516d8599-8038-7b47-a3f5-640bf13856c2@linaro.org>
On Thursday, May 24, 2018 10:14:31 AM CEST Daniel Lezcano wrote:
>
> Hi all,
Hi,
> would it be interesting to add debugfs metrics for cpuidle in order to
> read some statistics from there and investigate the behavior ?
What exactly would you like to see in there?
^ permalink raw reply
* [RFD] Add debugfs for cpuidle ?
From: Daniel Lezcano @ 2018-05-24 8:14 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: Linux Kernel Mailing List, Linux PM mailing list
Hi all,
would it be interesting to add debugfs metrics for cpuidle in order to
read some statistics from there and investigate the behavior ?
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
^ permalink raw reply
* Re: [PATCH v1 2/2] cpufreq: tegra20: Use PLL_C as intermediate clock source
From: Rafael J. Wysocki @ 2018-05-24 8:01 UTC (permalink / raw)
To: Dmitry Osipenko
Cc: Viresh Kumar, Rafael J. Wysocki, Thierry Reding, Jonathan Hunter,
Peter De Schrijver, linux-tegra, Linux PM,
Linux Kernel Mailing List
In-Reply-To: <56552c53-8868-af50-232e-b12e3c247ecd@gmail.com>
On Thu, May 24, 2018 at 7:37 AM, Dmitry Osipenko <digetx@gmail.com> wrote:
> On 24.05.2018 07:30, Viresh Kumar wrote:
>> On 23-05-18, 19:00, Dmitry Osipenko wrote:
>>> PLL_C is running at 600MHz which is significantly higher than the 216MHz
>>> of the PLL_P and it is known that PLL_C is always-ON because AHB BUS is
>>> running on that PLL. Let's use PLL_C as intermediate clock source, making
>>> CPU snappier a tad during of the frequency transition.
>>>
>>> Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
>>> ---
>>> drivers/cpufreq/tegra20-cpufreq.c | 25 +++++++++++++++++++++----
>>> 1 file changed, 21 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/cpufreq/tegra20-cpufreq.c b/drivers/cpufreq/tegra20-cpufreq.c
>>> index 3ad6bded6efc..4bf5ba7da40b 100644
>>> --- a/drivers/cpufreq/tegra20-cpufreq.c
>>> +++ b/drivers/cpufreq/tegra20-cpufreq.c
>>> @@ -25,12 +25,13 @@
>>> #include <linux/types.h>
>>>
>>> #define PLL_P_FREQ 216000
>>> +#define PLL_C_FREQ 600000
>>>
>>> static struct cpufreq_frequency_table freq_table[] = {
>>> { .frequency = 216000 },
>>> { .frequency = 312000 },
>>> { .frequency = 456000 },
>>> - { .frequency = 608000 },
>>> + { .frequency = 600000 },
>>> { .frequency = 760000 },
>>> { .frequency = 816000 },
>>> { .frequency = 912000 },
>>> @@ -44,6 +45,7 @@ struct tegra20_cpufreq {
>>> struct clk *cpu_clk;
>>> struct clk *pll_x_clk;
>>> struct clk *pll_p_clk;
>>> + struct clk *pll_c_clk;
>>> bool pll_x_prepared;
>>> };
>>>
>>> @@ -58,7 +60,10 @@ static unsigned int tegra_get_intermediate(struct cpufreq_policy *policy,
>>> if (index == 0 || policy->cur == PLL_P_FREQ)
>>> return 0;
>>>
>>> - return PLL_P_FREQ;
>>> + if (index == 3 || policy->cur == PLL_C_FREQ)
>>> + return 0;
>>
>> So we can choose between two different intermediate frequencies ? And
>> I didn't like the way magic number 3 is used here. Its prone to errors
>> and we better use a macro or something else here.
>>
>> Like instead of doing index == 3, what about freq_table[index].freq ==
>> PLL_C_FREQ ? Same for the previous patch as well.
>
> The frequency is determined by the parent clock of CCLK (CPU clock), we can
> choose between different parents for the CCLK. PLL_C as PLL_P and PLL_X are
> among the available parents for the CCLK to choose from and there some others.
>
> I don't mind to use freq_table[index].freq, though I'd like to keep compiled
> assembly minimal where possible. Hence the freq_table should be made constant to
> tell compiler that it doesn't need to emit data fetches for the table values and
> could embed the constants into the code where appropriate.
>
> Could we constify the "struct cpufreq_frequency_table" within the cpufreq core?
> Seems nothing prevents this (I already tried to constify - there are no
> obstacles), unless some cpufreq driver would try to modify
> policy->freq_table->... within the cpufreq callback implementation.
Some drivers generate frequency tables out of external data
unavailable at compile time, like ACPI tables.
But if you know it for the fact that the core doesn't modify the
frequency table, you could pass a constant table from the driver to
it, can't you?
^ permalink raw reply
* Re: [PATCH] cpufreq: reinitialize new policy min/max when writing scaling_(max|min)_freq
From: Rafael J. Wysocki @ 2018-05-24 7:45 UTC (permalink / raw)
To: Kevin Wangtao
Cc: Rafael J. Wysocki, Viresh Kumar, Linux PM,
Linux Kernel Mailing List, gengyanping, sunzhaosheng
In-Reply-To: <1527144234-96396-1-git-send-email-kevin.wangtao@hisilicon.com>
On Thu, May 24, 2018 at 8:43 AM, Kevin Wangtao
<kevin.wangtao@hisilicon.com> wrote:
> consider such situation, current user_policy.min is 1000000,
> current user_policy.max is 1200000, in cpufreq_set_policy,
> other driver may update policy.min to 1200000, policy.max to
> 1300000. After that, If we input "echo 1300000 > scaling_min_freq",
> then user_policy.min will be 1300000, and user_policy.max is
> still 1200000, because the input value is checked with policy.max
> not user_policy.max. if we get all related cpus offline and
> online again, it will cause cpufreq_init_policy fail because
> user_policy.min is higher than user_policy.max.
How do you reproduce this, exactly?
> The solution is when user space tries to write scaling_(max|min)_freq,
> the min/max of new_policy should be reinitialized with min/max
> of user_policy, like what cpufreq_update_policy does.
>
> Signed-off-by: Kevin Wangtao <kevin.wangtao@hisilicon.com>
> ---
> drivers/cpufreq/cpufreq.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index b79c532..8b33e08 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -697,6 +697,8 @@ static ssize_t store_##file_name \
> struct cpufreq_policy new_policy; \
> \
> memcpy(&new_policy, policy, sizeof(*policy)); \
> + new_policy->min = policy->user_policy.min; \
> + new_policy->max = policy->user_policy.max; \
It looks like you haven't even tried to build this, have you?
> \
> ret = sscanf(buf, "%u", &new_policy.object); \
> if (ret != 1) \
> --
> 2.8.1
>
^ permalink raw reply
* [PATCH V2] thermal: qcom-spmi-temp-alarm: add support for GEN2 PMIC peripherals
From: Kiran Gunda @ 2018-05-24 7:19 UTC (permalink / raw)
To: rui.zhang, sboyd, Eduardo Valentin, linux-pm, linux-kernel
Cc: linux-arm-msm, linux-arm-msm-owner, bjorn.andersson,
David Collins, Kiran Gunda
From: David Collins <collinsd@codeaurora.org>
Add support for the TEMP_ALARM GEN2 PMIC peripheral subtype. The
GEN2 subtype defines an over temperature state with hysteresis
instead of stage in the status register. There are two GEN2
states corresponding to stages 1 and 2.
Signed-off-by: David Collins <collinsd@codeaurora.org>
Signed-off-by: Kiran Gunda <kgunda@codeaurora.org>
Reviewed-by: Stephen Boyd <sboyd@codeaurora.org>
---
drivers/thermal/qcom-spmi-temp-alarm.c | 92 ++++++++++++++++++++++++++--------
1 file changed, 71 insertions(+), 21 deletions(-)
Changes from [V1]:
Rebased on top of 4.17-rc6
diff --git a/drivers/thermal/qcom-spmi-temp-alarm.c b/drivers/thermal/qcom-spmi-temp-alarm.c
index 95f987d..ad4f3a8 100644
--- a/drivers/thermal/qcom-spmi-temp-alarm.c
+++ b/drivers/thermal/qcom-spmi-temp-alarm.c
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2011-2015, The Linux Foundation. All rights reserved.
+ * Copyright (c) 2011-2015, 2017, The Linux Foundation. All rights reserved.
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 and
@@ -11,6 +11,7 @@
* GNU General Public License for more details.
*/
+#include <linux/bitops.h>
#include <linux/delay.h>
#include <linux/err.h>
#include <linux/iio/consumer.h>
@@ -29,13 +30,17 @@
#define QPNP_TM_REG_ALARM_CTRL 0x46
#define QPNP_TM_TYPE 0x09
-#define QPNP_TM_SUBTYPE 0x08
+#define QPNP_TM_SUBTYPE_GEN1 0x08
+#define QPNP_TM_SUBTYPE_GEN2 0x09
-#define STATUS_STAGE_MASK 0x03
+#define STATUS_GEN1_STAGE_MASK GENMASK(1, 0)
+#define STATUS_GEN2_STATE_MASK GENMASK(6, 4)
+#define STATUS_GEN2_STATE_SHIFT 4
-#define SHUTDOWN_CTRL1_THRESHOLD_MASK 0x03
+#define SHUTDOWN_CTRL1_OVERRIDE_MASK GENMASK(7, 6)
+#define SHUTDOWN_CTRL1_THRESHOLD_MASK GENMASK(1, 0)
-#define ALARM_CTRL_FORCE_ENABLE 0x80
+#define ALARM_CTRL_FORCE_ENABLE BIT(7)
/*
* Trip point values based on threshold control
@@ -58,6 +63,7 @@
struct qpnp_tm_chip {
struct regmap *map;
struct thermal_zone_device *tz_dev;
+ unsigned int subtype;
long temp;
unsigned int thresh;
unsigned int stage;
@@ -66,6 +72,9 @@ struct qpnp_tm_chip {
struct iio_channel *adc;
};
+/* This array maps from GEN2 alarm state to GEN1 alarm stage */
+static const unsigned int alarm_state_map[8] = {0, 1, 1, 2, 2, 3, 3, 3};
+
static int qpnp_tm_read(struct qpnp_tm_chip *chip, u16 addr, u8 *data)
{
unsigned int val;
@@ -84,30 +93,59 @@ static int qpnp_tm_write(struct qpnp_tm_chip *chip, u16 addr, u8 data)
return regmap_write(chip->map, chip->base + addr, data);
}
+/**
+ * qpnp_tm_get_temp_stage() - return over-temperature stage
+ * @chip: Pointer to the qpnp_tm chip
+ *
+ * Return: stage (GEN1) or state (GEN2) on success, or errno on failure.
+ */
+static int qpnp_tm_get_temp_stage(struct qpnp_tm_chip *chip)
+{
+ int ret;
+ u8 reg = 0;
+
+ ret = qpnp_tm_read(chip, QPNP_TM_REG_STATUS, ®);
+ if (ret < 0)
+ return ret;
+
+ if (chip->subtype == QPNP_TM_SUBTYPE_GEN1)
+ ret = reg & STATUS_GEN1_STAGE_MASK;
+ else
+ ret = (reg & STATUS_GEN2_STATE_MASK) >> STATUS_GEN2_STATE_SHIFT;
+
+ return ret;
+}
+
/*
* This function updates the internal temp value based on the
* current thermal stage and threshold as well as the previous stage
*/
static int qpnp_tm_update_temp_no_adc(struct qpnp_tm_chip *chip)
{
- unsigned int stage;
+ unsigned int stage, stage_new, stage_old;
int ret;
- u8 reg = 0;
- ret = qpnp_tm_read(chip, QPNP_TM_REG_STATUS, ®);
+ ret = qpnp_tm_get_temp_stage(chip);
if (ret < 0)
return ret;
+ stage = ret;
- stage = reg & STATUS_STAGE_MASK;
+ if (chip->subtype == QPNP_TM_SUBTYPE_GEN1) {
+ stage_new = stage;
+ stage_old = chip->stage;
+ } else {
+ stage_new = alarm_state_map[stage];
+ stage_old = alarm_state_map[chip->stage];
+ }
- if (stage > chip->stage) {
+ if (stage_new > stage_old) {
/* increasing stage, use lower bound */
- chip->temp = (stage - 1) * TEMP_STAGE_STEP +
+ chip->temp = (stage_new - 1) * TEMP_STAGE_STEP +
chip->thresh * TEMP_THRESH_STEP +
TEMP_STAGE_HYSTERESIS + TEMP_THRESH_MIN;
- } else if (stage < chip->stage) {
+ } else if (stage_new < stage_old) {
/* decreasing stage, use upper bound */
- chip->temp = stage * TEMP_STAGE_STEP +
+ chip->temp = stage_new * TEMP_STAGE_STEP +
chip->thresh * TEMP_THRESH_STEP -
TEMP_STAGE_HYSTERESIS + TEMP_THRESH_MIN;
}
@@ -162,28 +200,37 @@ static irqreturn_t qpnp_tm_isr(int irq, void *data)
*/
static int qpnp_tm_init(struct qpnp_tm_chip *chip)
{
+ unsigned int stage;
int ret;
- u8 reg;
+ u8 reg = 0;
- chip->thresh = THRESH_MIN;
+ ret = qpnp_tm_read(chip, QPNP_TM_REG_SHUTDOWN_CTRL1, ®);
+ if (ret < 0)
+ return ret;
+
+ chip->thresh = reg & SHUTDOWN_CTRL1_THRESHOLD_MASK;
chip->temp = DEFAULT_TEMP;
- ret = qpnp_tm_read(chip, QPNP_TM_REG_STATUS, ®);
+ ret = qpnp_tm_get_temp_stage(chip);
if (ret < 0)
return ret;
+ chip->stage = ret;
- chip->stage = reg & STATUS_STAGE_MASK;
+ stage = chip->subtype == QPNP_TM_SUBTYPE_GEN1
+ ? chip->stage : alarm_state_map[chip->stage];
- if (chip->stage)
+ if (stage)
chip->temp = chip->thresh * TEMP_THRESH_STEP +
- (chip->stage - 1) * TEMP_STAGE_STEP +
+ (stage - 1) * TEMP_STAGE_STEP +
TEMP_THRESH_MIN;
/*
* Set threshold and disable software override of stage 2 and 3
* shutdowns.
*/
- reg = chip->thresh & SHUTDOWN_CTRL1_THRESHOLD_MASK;
+ chip->thresh = THRESH_MIN;
+ reg &= ~(SHUTDOWN_CTRL1_OVERRIDE_MASK | SHUTDOWN_CTRL1_THRESHOLD_MASK);
+ reg |= chip->thresh & SHUTDOWN_CTRL1_THRESHOLD_MASK;
ret = qpnp_tm_write(chip, QPNP_TM_REG_SHUTDOWN_CTRL1, reg);
if (ret < 0)
return ret;
@@ -246,12 +293,15 @@ static int qpnp_tm_probe(struct platform_device *pdev)
return ret;
}
- if (type != QPNP_TM_TYPE || subtype != QPNP_TM_SUBTYPE) {
+ if (type != QPNP_TM_TYPE || (subtype != QPNP_TM_SUBTYPE_GEN1
+ && subtype != QPNP_TM_SUBTYPE_GEN2)) {
dev_err(&pdev->dev, "invalid type 0x%02x or subtype 0x%02x\n",
type, subtype);
return -ENODEV;
}
+ chip->subtype = subtype;
+
ret = qpnp_tm_init(chip);
if (ret < 0) {
dev_err(&pdev->dev, "init failed\n");
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox