Hi Guys,
This patchset add APIs in OPP layer to allow OPPs transitioning from
within OPP layer. Currently all OPP users need to replicate the same
code to switch between OPPs. While the same can be handled easily by
OPP-core.
The first 7 patches update the OPP core to introduce the new APIs and
the next Nine patches update cpufreq-dt for the same.
11 out of 17 are already Reviewed by Stephen, only few are left :)
I hope this is the last version of the series :)
Testing:
- Tested on exynos 5250-arndale (dual-cortex-A15)
- Tested for both Old-V1 bindings and New V2 bindings
- Tested with regulator names as: 'cpu-supply' and 'cpu0-supply'
- Tested with Unsupported supply ranges as well, to check the
opp-disable logic
V2->V3:
- Very minor updates.
- find_supply_name() doesn't return an error value now, and so its
callers don't check for it.
- And so we don't need to initialize name to NULL
Viresh Kumar (16):
PM / OPP: get/put regulators from OPP core
PM / OPP: Disable OPPs that aren't supported by the regulator
PM / OPP: Introduce dev_pm_opp_get_max_volt_latency()
PM / OPP: Introduce dev_pm_opp_get_max_transition_latency()
PM / OPP: Parse clock-latency and voltage-tolerance for v1 bindings
PM / OPP: Manage device clk
PM / OPP: Add dev_pm_opp_set_rate()
cpufreq: dt: Convert few pr_debug/err() calls to dev_dbg/err()
cpufreq: dt: Rename 'need_update' to 'opp_v1'
cpufreq: dt: OPP layers handles clock-latency for V1 bindings as well
cpufreq: dt: Pass regulator name to the OPP core
cpufreq: dt: Unsupported OPPs are already disabled
cpufreq: dt: Reuse dev_pm_opp_get_max_transition_latency()
cpufreq: dt: Use dev_pm_opp_set_rate() to switch frequency
cpufreq: dt: No need to fetch voltage-tolerance
cpufreq: dt: No need to allocate resources anymore
drivers/base/power/opp/core.c | 420 ++++++++++++++++++++++++++++++++++++++++++
drivers/base/power/opp/opp.h | 13 ++
drivers/cpufreq/cpufreq-dt.c | 300 +++++++++++-------------------
include/linux/pm_opp.h | 27 +++
4 files changed, 565 insertions(+), 195 deletions(-)
--
2.7.1.370.gb2aa7f8
The rate_limit_us for the schedutil governor is getting set to 500 ms by
default for the ARM64 hikey board. And its way too much, even for the
default value. Lets set the default transition_delay_ns to something
more realistic (10 ms), while the userspace always have a chance to set
something it wants.
Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org>
---
drivers/cpufreq/cpufreq-dt.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/cpufreq/cpufreq-dt.c b/drivers/cpufreq/cpufreq-dt.c
index c943787d761e..70eac3fd89ac 100644
--- a/drivers/cpufreq/cpufreq-dt.c
+++ b/drivers/cpufreq/cpufreq-dt.c
@@ -275,6 +275,9 @@ static int cpufreq_init(struct cpufreq_policy *policy)
policy->cpuinfo.transition_latency = transition_latency;
+ /* Set the default transition delay to 10ms */
+ policy->transition_delay_us = 10 * USEC_PER_MSEC;
+
return 0;
out_free_cpufreq_table:
--
2.7.4
Hi,
The first patch fixes a potential regression we may observe on the UP
systems and the others are doing minor optimizations in the scheduler
core.
They are all tested on ARM 32 (exynos) and 64 (hikey) bit platforms.
--
viresh
Viresh Kumar (6):
sched: fair: Call cpufreq update util handlers less frequently on UP
sched: Reuse put_prev_task()
sched: fair: Pass rq to weighted_cpuload()
sched: fair: Avoid checking cfs_rq->nr_running twice
sched: fair: Drop always true parameter of update_cfs_rq_load_avg()
sched: cpufreq: Optimize cpufreq_update_this_cpu() a bit
kernel/sched/core.c | 2 +-
kernel/sched/fair.c | 107 ++++++++++++++++++++++++++-------------------------
kernel/sched/sched.h | 2 +-
3 files changed, 56 insertions(+), 55 deletions(-)
--
2.13.0.70.g6367777092d9
Hi,
Here is the 7th version of the series and it looks very different from
whatever is sent until now. Almost a rewrite.
Here is a brief summary of the problem I am trying to solve.
Some platforms have the capability to configure the performance state of
their power domains. The process of configuring the performance state is
pretty much platform dependent and we may need to work with a wide range
of configurables. For some platforms, like Qcom, it can be a positive
integer value alone, while in other cases it can be voltage levels, etc.
The power-domain framework until now was only designed for the idle
state management of the device and this needs to change in order to
reuse the power-domain framework for active state management of the
devices.
Solution:
Kevin suggested in V6 that we should wait for a while before introducing
any new binding (power-domain-opp) to the OPP table for this stuff and
translate the device requirements into a performance index from within
the power domain driver as it already knows which devices it supports.
If we do that, then there is also no need to represent the performance
states of the power domains in the DT. Keep that as well in the driver
for now.
This simplified things a lot and we can make things work with just two
patches. The first one updates the genpd framework to supply new APIs
and the second patch uses them from the OPP core. Its quite straight
forward and simple.
The ideal way is still to get the relation between device and domain
states via the DT instead of platform code, but that can be done
incrementally later once we have some users for it. It would be much
simpler to get these two patches merged. The code never got any real
reviews in the last 6 versions as we were stuck with bindings :)
This is tested currently by hacking the kernel a bit with virtual
power-domains for the dual A15 exynos platform.
Driver code:
------------
Here is some sample power-domain driver code that I have. It only
supports a single device for now, CPU.
int pd_get_performance(struct device *dev, unsigned long rate)
{
struct device *cpu_dev = get_cpu_device(0);
if (cpu_dev != dev)
return -EINVAL;
if (rate <= 500000000)
return 1;
else if (rate <= 700000000)
return 2;
else if (rate <= 900000000)
return 3;
else if (rate <= 1200000000)
return 4;
else if (rate <= 1600000000)
return 5;
else
return 6;
}
static int pd_set_performance(struct generic_pm_domain *domain, unsigned int state)
{
/* Set performance of the domain in platform dependent way */
return 0;
}
static const struct of_device_id pm_domain_of_match[] __initconst = {
{ .compatible = "foo,genpd", },
{ },
};
static int __init genpd_test_init(void)
{
struct device *dev = get_cpu_device(0);
struct device_node *np;
const struct of_device_id *match;
int n;
int ret;
for_each_matching_node_and_match(np, pm_domain_of_match, &match) {
pd.name = kstrdup_const(strrchr(np->full_name, '/') + 1,
GFP_KERNEL);
if (!pd.name) {
of_node_put(np);
return -ENOMEM;
}
pd.get_performance_state = pd_get_performance;
pd.set_performance_state = pd_set_performance;
pm_genpd_init(&pd, NULL, false);
of_genpd_add_provider_simple(np, &pd);
}
ret = dev_pm_domain_attach(dev, false);
return ret;
}
Pushed here as well:
https://git.linaro.org/people/viresh.kumar/linux.git/log/?h=opp/genpd-perfo…
Rebased on: pm/linux-next + some OPP cleanups (https://marc.info/?l=linux-kernel&m=149499607030364&w=2)
V6->V7:
- Almost a rewrite, only two patches against 9 in earlier version.
- No bindings updated now and domain's performance state aren't passed
via DT for now (until we know how users are going to use it).
- We also skipped the QoS framework completely and new APIs are provided
directly by genpd.
V5->V6:
- Use freq/voltage in OPP table as it is for power domain and don't
create "domain-performance-level" property
- Create new "power-domain-opp" property for the devices.
- Take care of domain providers that provide multiple domains and extend
"operating-points-v2" property to contain a list of phandles
- Update code according to those bindings.
V4->V5:
- Only 3 patches were resent and 2 of them are Acked from Ulf.
V3->V4:
- Use OPP table for genpd devices as well.
- Add struct device to genpd, in order to reuse OPP infrastructure.
- Based over: https://marc.info/?l=linux-kernel&m=148972988002317&w=2
- Fixed examples in DT document to have voltage in target,min,max order.
V2->V3:
- Based over latest pm/linux-next
- Bindings and code are merged together
- Lots of updates in bindings
- the performance-states node is present within the power-domain now,
instead of its phandle.
- performance-level property is replaced by "reg".
- domain-performance-state property of the consumers contain an
integer value now instead of phandle.
- Lots of updates to the code as well
- Patch "PM / QOS: Add default case to the switch" is merged with
other patches and the code is changed a bit as well.
- Don't pass 'type' to dev_pm_qos_add_notifier(), rather handle all
notifiers with a single list. A new patch is added for that.
- The OPP framework patch can be applied now and has proper SoB from
me.
- Dropped "PM / domain: Save/restore performance state at runtime
suspend/resume".
- Drop all WARN().
- Tested-by Rajendra nayak.
V1->V2:
- Based over latest pm/linux-next
- It is mostly a resend of what is sent earlier as this series hasn't
got any reviews so far and Rafael suggested that its better I resend
it.
- Only the 4/6 patch got an update, which was shared earlier as reply to
V1 as well. It has got several fixes for taking care of power domain
hierarchy, etc.
--
viresh
Viresh Kumar (2):
PM / Domains: Add support to select performance-state of domains
PM / OPP: Support updating performance state of device's power domains
drivers/base/power/domain.c | 172 ++++++++++++++++++++++++++++++++++++++++++
drivers/base/power/opp/core.c | 48 +++++++++++-
drivers/base/power/opp/opp.h | 2 +
include/linux/pm_domain.h | 19 +++++
4 files changed, 240 insertions(+), 1 deletion(-)
--
2.13.0.303.g4ebf3021692d
Those patches aim to complete stm32 timer features support.
The last missing part is to be able to chain to timer blocks
which mean that one of timerX's trigger could be used as clock for timerY.
Since this operating is neither event or buffer triggered mode I would
like to introduce a hardware triggered mode in IIO core.
Benjamin Gaignard (2):
iio: add hardware triggered operating mode
iio: make stm32 trigger driver use INDIO_HARDWARE_TRIGGERED mode
.../ABI/testing/sysfs-bus-iio-timer-stm32 | 15 ++++++
drivers/iio/industrialio-core.c | 4 +-
drivers/iio/trigger/stm32-timer-trigger.c | 61 ++++++++++++++++++++++
include/linux/iio/iio.h | 6 +++
4 files changed, 84 insertions(+), 2 deletions(-)
--
1.9.1