Re: [PATCH v11 2/2] cpufreq: qcom-hw: Add support for QCOM cpufreq HW driver

2018-12-05 Thread Viresh Kumar
On 05-12-18, 09:00, Stephen Boyd wrote: > Here's a patch to squash in to fix those tiny problems. I left it as > devm_ioremap_resource() because that has all the nice features of > resource requesting inside and it didn't seem too bad to devm_iounmap() > on the exit path. > >

Re: [PATCH v2] cpufreq: nforce2: Remove meaningless return

2018-12-05 Thread Viresh Kumar
f MODULE_ > -delete some blank lines > --- > drivers/cpufreq/cpufreq-nforce2.c | 3 --- > 1 file changed, 3 deletions(-) Acked-by: Viresh Kumar -- viresh

Re: [PATCH v11 2/2] cpufreq: qcom-hw: Add support for QCOM cpufreq HW driver

2018-12-04 Thread Viresh Kumar
On 05-12-18, 09:07, Taniya Das wrote: > Hello Stephen, Viresh > > Thanks for the code and suggestions. > > Having a NR_DOMAINS '2' makes the driver not scalable for re-use. Sure, I didn't like it either and that wasn't really what I was suggesting in the first place. I didn't wanted to write

Re: [PATCH v11 2/2] cpufreq: qcom-hw: Add support for QCOM cpufreq HW driver

2018-12-04 Thread Viresh Kumar
On 04-12-18, 14:57, Taniya Das wrote: > Hello Viresh, > > On 12/4/2018 10:42 AM, Viresh Kumar wrote: > > Hi Taniya, > > > > Sorry that I haven't been reviewing it much from last few iterations as I > > was > > letting others get this into a better shape. T

Re: [PATCH] opp: Add API for getting voltage from supplies

2018-12-04 Thread Viresh Kumar
On 04-12-18, 14:59, Nick Fan wrote: > Add API to get voltage for multiple supplies from opp table And who needs to use this new API ? It would be better to add the user in the same series to make sure this really gets used. > Signed-off-by: Nick Fan > --- > drivers/opp/core.c | 28

Re: [PATCH v5 8/8] soc: qcom: rpmhpd: Mark mx as a parent for cx

2018-12-03 Thread Viresh Kumar
Viresh [1] which adds support to propogate performance states across the > power domain hierarchy which is still being reviewed. > > [1] https://lkml.org/lkml/2018/11/26/333 > > drivers/soc/qcom/rpmhpd.c | 11 +++++++ > 1 file changed, 11 insertions(+) Acked-by: Viresh Kumar -- viresh

Re: [PATCH v5 7/8] arm64: dts: sdm845: Add rpmh powercontroller node

2018-12-03 Thread Viresh Kumar
On 04-12-18, 10:51, Rajendra Nayak wrote: > Add the DT node for the rpmhpd powercontroller. > > Signed-off-by: Rajendra Nayak > --- > arch/arm64/boot/dts/qcom/sdm845.dtsi | 51 > 1 file changed, 51 insertions(+) Acked-by: Viresh Kumar -- viresh

Re: [PATCH v11 2/2] cpufreq: qcom-hw: Add support for QCOM cpufreq HW driver

2018-12-03 Thread Viresh Kumar
Hi Taniya, Sorry that I haven't been reviewing it much from last few iterations as I was letting others get this into a better shape. Thanks for your efforts.. On 02-12-18, 09:25, Taniya Das wrote: > +++ b/drivers/cpufreq/qcom-cpufreq-hw.c > +struct cpufreq_qcom { > + struct

Re: [PATCH RESEND] sched/cpufreq: Add the SPDX tags

2018-12-03 Thread Viresh Kumar
/cpufreq_schedutil.c | 5 + > 2 files changed, 2 insertions(+), 8 deletions(-) Acked-by: Viresh Kumar -- viresh

Re: [PATCH V2 5/5] PM / Domains: Propagate performance state updates

2018-12-03 Thread Viresh Kumar
On 30-11-18, 10:44, Ulf Hansson wrote: > On Mon, 26 Nov 2018 at 09:10, Viresh Kumar wrote: > > +static int _genpd_reeval_performance_state(struct generic_pm_domain *genpd, > > + unsigned int state, int depth); > > + > > I don'

Re: [PATCH V2 3/5] PM / Domains: Save OPP table pointer in genpd

2018-12-02 Thread Viresh Kumar
On 30-11-18, 09:53, Ulf Hansson wrote: > On Mon, 26 Nov 2018 at 09:10, Viresh Kumar wrote: > > > > We will need these going forward in hotpath, i.e. from within > > dev_pm_genpd_set_performance_state(). > > Well, as for patch2, please try to be a bit more descriptive o

Re: [PATCH V2 2/5] OPP: Add dev_pm_opp_xlate_performance_state() helper

2018-12-02 Thread Viresh Kumar
On 30-11-18, 09:45, Ulf Hansson wrote: > On Mon, 26 Nov 2018 at 09:10, Viresh Kumar wrote: > > > > Introduce a new helper dev_pm_opp_xlate_performance_state() which will > > be used to translate from pstate of a device to another one. > > I don't get this,

Re: [PATCH] cpufreq: ia64: Remove unused header files

2018-12-02 Thread Viresh Kumar
On 03-12-18, 10:12, Viresh Kumar wrote: > On 30-11-18, 09:16, Yangtao Li wrote: > > seq_file.h does not need to be included,so remove it.Moreover deleted a > > line of meaningless return and move the module declaration to the end. > > In a function whose return type is void,

Re: [PATCH] cpufreq: ia64: Remove unused header files

2018-12-02 Thread Viresh Kumar
unsigned intresume; > @@ -348,9 +342,11 @@ acpi_cpufreq_exit (void) > pr_debug("acpi_cpufreq_exit\n"); > > cpufreq_unregister_driver(_cpufreq_driver); > - return; > } > > +MODULE_AUTHOR("Venkatesh Pallipadi"); > +MODULE_DESCRIPTION("ACPI Processor P-States Driver"); > +MODULE_LICENSE("GPL"); > > late_initcall(acpi_cpufreq_init); > module_exit(acpi_cpufreq_exit); Acked-by: Viresh Kumar -- viresh

Re: [PATCH V2 5/5] PM / Domains: Propagate performance state updates

2018-11-30 Thread Viresh Kumar
On 30-11-18, 11:18, Ulf Hansson wrote: > On Fri, 30 Nov 2018 at 10:59, Viresh Kumar wrote: > > Sure, but the ordering of locks is always subdomain first and then master. > > Considering the case of Qcom, we have two domains Cx (sub-domain) and Mx > > (master). > > >

Re: [PATCH V2 5/5] PM / Domains: Propagate performance state updates

2018-11-30 Thread Viresh Kumar
On 30-11-18, 10:44, Ulf Hansson wrote: > On Mon, 26 Nov 2018 at 09:10, Viresh Kumar wrote: > > > > This commit updates genpd core to start propagating performance state > > updates to master domains that have their set_performance_state() > > callback set. >

Re: [PATCH V2 3/5] PM / Domains: Save OPP table pointer in genpd

2018-11-30 Thread Viresh Kumar
On 30-11-18, 09:53, Ulf Hansson wrote: > > diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c > > index 8e554e6a82a2..0d928359b880 100644 > > --- a/drivers/base/power/domain.c > > +++ b/drivers/base/power/domain.c > > @@ -1907,12 +1907,21 @@ int

Re: [RFC][PATCH 2/2] sched: Enqueue tasks on a cpu with only SCHED_IDLE tasks

2018-11-27 Thread Viresh Kumar
Hi Quentin, On 26-11-18, 12:37, Quentin Perret wrote: > On Monday 26 Nov 2018 at 16:50:24 (+0530), Viresh Kumar wrote: > > The scheduler tries to schedule a newly wakeup task on an idle CPU to > > make sure the new task gets chance to run as soon as possible, for > >

Re: [PATCH V4 2/2] base/drivers/arch_topology: Default dmips-mhz if they are not set in DT

2018-11-27 Thread Viresh Kumar
On 27-11-18, 09:09, Quentin Perret wrote: > On Tuesday 27 Nov 2018 at 09:27:35 (+0530), Viresh Kumar wrote: > > On 26-11-18, 13:20, Daniel Lezcano wrote: > > > diff --git a/Documentation/devicetree/bindings/arm/cpu-capacity.txt > > > b/Documentation/devicetree/bi

Re: [PATCH] OPP: remove some duplicated includes

2018-11-26 Thread Viresh Kumar
On 26-11-18, 08:18, Yangtao Li wrote: > Some header files are included twice.It's unnecessary, > so just remove them. > > Signed-off-by: Yangtao Li > --- > drivers/opp/core.c | 2 -- > drivers/opp/cpu.c | 1 - > drivers/opp/debugfs.c | 2 -- > drivers/opp/of.c

Re: [PATCH V4 2/2] base/drivers/arch_topology: Default dmips-mhz if they are not set in DT

2018-11-26 Thread Viresh Kumar
On 26-11-18, 13:20, Daniel Lezcano wrote: > diff --git a/Documentation/devicetree/bindings/arm/cpu-capacity.txt > b/Documentation/devicetree/bindings/arm/cpu-capacity.txt > index 84262cd..f53a3c9 100644 > --- a/Documentation/devicetree/bindings/arm/cpu-capacity.txt > +++

[RFC][PATCH 2/2] sched: Enqueue tasks on a cpu with only SCHED_IDLE tasks

2018-11-26 Thread Viresh Kumar
state) and enqueuing the new task on a CPU which only has SCHED_IDLE tasks. Signed-off-by: Viresh Kumar --- kernel/sched/core.c | 23 kernel/sched/fair.c | 50 +++- kernel/sched/sched.h | 3 +++ 3 files changed, 62 insertions(+), 14

[RFC][PATCH 1/2] sched: Start tracking SCHED_IDLE tasks count in cfs_rq

2018-11-26 Thread Viresh Kumar
Start tracking how many tasks with SCHED_IDLE policy are present in each cfs_rq. This will be used by later commits. Signed-off-by: Viresh Kumar --- kernel/sched/fair.c | 14 -- kernel/sched/sched.h | 2 ++ 2 files changed, 14 insertions(+), 2 deletions(-) diff --git a/kernel

[RFC][PATCH 0/2] sched: Power optimizations with SCHED_IDLE

2018-11-26 Thread Viresh Kumar
. -- viresh Viresh Kumar (2): sched: Start tracking SCHED_IDLE tasks count in cfs_rq sched: Enqueue tasks on a cpu with only SCHED_IDLE tasks kernel/sched/core.c | 23 kernel/sched/fair.c | 64 +--- kernel/sched/sched.h | 5 3 files

Re: [PATCH V3 2/2] base/drivers/arch_topology: Default dmips-mhz if they are not set in DT

2018-11-26 Thread Viresh Kumar
On 26-11-18, 11:08, Daniel Lezcano wrote: > On 26/11/2018 10:52, Quentin Perret wrote: > > Maybe you want to test 'if (!raw_capacity || cap_parsing_failed)' at the > > top of topology_parse_cpu_capacity() ? > > I prefer to update the documentation, it makes more sense than adding > more

Re: [PATCH V3 2/2] base/drivers/arch_topology: Default dmips-mhz if they are not set in DT

2018-11-26 Thread Viresh Kumar
s 1593600 and 2150400. > > Cc: Chris Redpath > Cc: Quentin Perret > Cc: Viresh Kumar > Cc: Amit Kucheria > Cc: Nicolas Dechesne > Cc: Niklas Cassel > Signed-off-by: Daniel Lezcano > --- > drivers/base/arch_topology.c | 13 - > 1 file changed, 12 insertions(+), 1 deletion(-) Reviewed-by: Viresh Kumar -- viresh

[PATCH V2 3/5] PM / Domains: Save OPP table pointer in genpd

2018-11-26 Thread Viresh Kumar
We will need these going forward in hotpath, i.e. from within dev_pm_genpd_set_performance_state(). Lets fetch and save them while the OPP tables are added. Signed-off-by: Viresh Kumar --- drivers/base/power/domain.c | 23 +-- include/linux/pm_domain.h | 2 ++ 2 files

[PATCH V2 4/5] PM / Domains: Factorize dev_pm_genpd_set_performance_state()

2018-11-26 Thread Viresh Kumar
Separate out _genpd_set_performance_state() and _genpd_reeval_performance_state() from dev_pm_genpd_set_performance_state() to handle performance state update related stuff. This will be used by a later commit. Signed-off-by: Viresh Kumar --- drivers/base/power/domain.c | 105

[PATCH V2 0/5] PM / Domains: Allow performance state propagation

2018-11-26 Thread Viresh Kumar
to handle 1:1 pstate mapping between genpd and its master and also to fix a problem while finding the dst_table. - Handle pstate=0 case properly. -- viresh Viresh Kumar (5): OPP: Improve _find_table_of_opp_np() OPP: Add dev_pm_opp_xlate_performance_state() helper PM / Domains: Save OPP

[PATCH V2 2/5] OPP: Add dev_pm_opp_xlate_performance_state() helper

2018-11-26 Thread Viresh Kumar
Introduce a new helper dev_pm_opp_xlate_performance_state() which will be used to translate from pstate of a device to another one. Initially this will be used by genpd to find pstate of a master domain using its sub-domain's pstate. Signed-off-by: Viresh Kumar --- drivers/opp/core.c | 59

[PATCH V2 1/5] OPP: Improve _find_table_of_opp_np()

2018-11-26 Thread Viresh Kumar
Make _find_table_of_opp_np() more efficient by using of_get_parent() to find the parent OPP table node. Signed-off-by: Viresh Kumar --- drivers/opp/of.c | 14 ++ 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/drivers/opp/of.c b/drivers/opp/of.c index 840f85181a37

[PATCH V2 5/5] PM / Domains: Propagate performance state updates

2018-11-26 Thread Viresh Kumar
while powering-on a genpd as well, as we ignore performance state requirements from sub-domains which are powered-off. For this reason _genpd_power_on() also received the additional parameter, depth, which is used for hierarchical locking within genpd. Signed-off-by: Viresh Kumar --- drivers/base

Re: [PATCH 2/2] cpufreq: imx6q: save one condition block for normal case of nvmem read

2018-11-25 Thread Viresh Kumar
return ret; > if (ret) { > + if (ret == -EPROBE_DEFER) > + return ret; > + > dev_err(cpu_dev, "failed to read ocotp: %d\n", > ret); > return ret; Acked-by: Viresh Kumar -- viresh

Re: [PATCH 1/2] cpufreq: imx6q: remove unused code

2018-11-25 Thread Viresh Kumar
ex], 0); > - if (ret) { > + if (ret) > dev_warn(cpu_dev, "failed to scale vddpu down: > %d\n", ret); > - ret = 0; > - } > } > } > Acked-by: Viresh Kumar -- viresh

Re: [PATCH V2 2/2] base/drivers/arch_topology: Default dmips-mhz if they are not set in DT

2018-11-25 Thread Viresh Kumar
On 23-11-18, 11:32, Daniel Lezcano wrote: > On 23/11/2018 11:04, Viresh Kumar wrote: > > On 22-11-18, 13:36, Daniel Lezcano wrote: > >> In the case of asymmetric SoC with the same micro-architecture, we > >> have a group of CPUs with smaller OPPs than the ot

Re: [PATCH V2 2/2] base/drivers/arch_topology: Default dmips-mhz if they are not set in DT

2018-11-23 Thread Viresh Kumar
On 22-11-18, 13:36, Daniel Lezcano wrote: > In the case of asymmetric SoC with the same micro-architecture, we > have a group of CPUs with smaller OPPs than the other group. One > example is the 96boards dragonboard 820c. There is no dmips/MHz > difference between both groups, so no need to

Re: [PATCH 1/4] OPP: Add dev_pm_opp_xlate_performance_state() helper

2018-11-23 Thread Viresh Kumar
On 23-11-18, 14:41, Viresh Kumar wrote: > On 22-11-18, 11:38, Viresh Kumar wrote: > > So there are few complexities in the case where an OPP table points to > > itself in > > the required-opp field. I looked at solving it up in the opp core but that > > gets > >

Re: [PATCH 1/4] OPP: Add dev_pm_opp_xlate_performance_state() helper

2018-11-23 Thread Viresh Kumar
On 22-11-18, 11:38, Viresh Kumar wrote: > So there are few complexities in the case where an OPP table points to itself > in > the required-opp field. I looked at solving it up in the opp core but that > gets > more and more messy. > > Now there is actually a assumptio

[PATCH] OPP: Fix parsing of multiple phandles in "operating-points-v2" property

2018-11-22 Thread Viresh Kumar
d_opp_table_v{1|2}()") Signed-off-by: Viresh Kumar --- drivers/opp/of.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/opp/of.c b/drivers/opp/of.c index 5a4b47958073..38a08805a30c 100644 --- a/drivers/opp/of.c +++ b/drivers/opp/of.c @@ -

Re: [PATCH 4/4] base/drivers/topology: Default dmpis-mhz if they are not set in DT

2018-11-22 Thread Viresh Kumar
On 22-11-18, 11:29, Daniel Lezcano wrote: > Oh ... actually raw_capacity is not needed at all! It is required as another routine writes some values to it I believe :) -- viresh

Re: [PATCH 1/4] OPP: Add dev_pm_opp_xlate_performance_state() helper

2018-11-21 Thread Viresh Kumar
On 21-11-18, 11:48, Rajendra Nayak wrote: > > > On 11/21/2018 11:36 AM, Viresh Kumar wrote: > > On 21-11-18, 10:47, Viresh Kumar wrote: > > > On 21-11-18, 10:34, Rajendra Nayak wrote: > > > > > > > > > > > > On 11/5/2018 12

Re: [PATCH v10 2/2] cpufreq: qcom-hw: Add support for QCOM cpufreq HW driver

2018-11-21 Thread Viresh Kumar
On 21-11-18, 14:06, Matthias Kaehlcke wrote: > On Wed, Nov 21, 2018 at 04:12:47PM +0530, Taniya Das wrote: > > + .boost_enabled = true, > > I have no real expertise with cpufreq boost, but after reading a bit > through cpufreq code this seems wrong. Boost is enabled statically, > however the

Re: [PATCH 4/4] base/drivers/topology: Default dmpis-mhz if they are not set in DT

2018-11-21 Thread Viresh Kumar
On 21-11-18, 23:12, Daniel Lezcano wrote: > On 30/10/2018 09:58, Viresh Kumar wrote: > > s/dmpis/dmips/ in $subject > > > > On 29-10-18, 17:23, Daniel Lezcano wrote: > >> In the case of assymetric SoC with the same micro-architecture, we > > > >

Re: [PATCH 4/4] PM / Domains: Propagate performance state updates

2018-11-20 Thread Viresh Kumar
On 21-11-18, 11:12, Rajendra Nayak wrote: > And the reason for that seems to be that we update the genpd status to > GPD_STATE_ACTIVE > *after* we try to set the performance state, so we always hit this check > which bails out > thinking the genpd is not ON. Thanks for looking at it. Here is

Re: [PATCH 1/4] OPP: Add dev_pm_opp_xlate_performance_state() helper

2018-11-20 Thread Viresh Kumar
On 21-11-18, 10:47, Viresh Kumar wrote: > On 21-11-18, 10:34, Rajendra Nayak wrote: > > > > > > On 11/5/2018 12:06 PM, Viresh Kumar wrote: > > > Introduce a new helper dev_pm_opp_xlate_performance_state() which will > > > be used to translate

Re: [PATCH V5 1/2] thermal: imx: fix for dependency on cpu-freq

2018-11-20 Thread Viresh Kumar
2 files changed, 36 insertions(+), 13 deletions(-) Acked-by: Viresh Kumar -- viresh

Re: [PATCH V5 2/2] thermal: imx: save one condition block for normal case of nvmem initialization

2018-11-20 Thread Viresh Kumar
if (ret == -EPROBE_DEFER) > + return ret; > + > dev_err(>dev, "failed to init from nvmem: %d\n", > ret); > return ret; Acked-by: Viresh Kumar -- viresh

Re: [PATCH 4/4] PM / Domains: Propagate performance state updates

2018-11-20 Thread Viresh Kumar
On 21-11-18, 11:01, Rajendra Nayak wrote: > I would think this is analogous to a driver calling clk_set_rate() first and > then a clk_enable(), which is certainly valid. > So my question is, if calling a dev_pm_genpd_set_performance_state() > and then runtime enabling the device would work (and

Re: [PATCH V4] thermal: imx: fix for dependency on cpu-freq

2018-11-20 Thread Viresh Kumar
On 21-11-18, 05:28, Anson Huang wrote: > Since there is similar case of DEFER PROBE for the case of > imx_init_from_nvmem_cells > check, should I create another patch of same fix for it in V5 patch set? Send that as a separate patch please. Thanks. -- viresh

Re: [PATCH V4] thermal: imx: fix for dependency on cpu-freq

2018-11-20 Thread Viresh Kumar
On 21-11-18, 05:08, Anson Huang wrote: > +static void imx_thermal_unregister_legacy_cooling(struct imx_thermal_data > *data) > +{ > + cpufreq_cooling_unregister(data->cdev); > + cpufreq_cpu_put(data->policy); > +} > +#else > +static inline int imx_thermal_register_legacy_cooling(struct >

Re: [PATCH V4] thermal: imx: fix for dependency on cpu-freq

2018-11-20 Thread Viresh Kumar
On 21-11-18, 05:08, Anson Huang wrote: > The thermal driver is a standalone driver for monitoring SoC temperature > by enabling thermal sensor, so it can be enabled even when CONFIG_CPU_FREQ > is NOT set. So remove the dependency with CPU_THERMAL. > > Introduce dummy function of legacy cooling

Re: [PATCH 1/4] OPP: Add dev_pm_opp_xlate_performance_state() helper

2018-11-20 Thread Viresh Kumar
On 21-11-18, 10:34, Rajendra Nayak wrote: > > > On 11/5/2018 12:06 PM, Viresh Kumar wrote: > > Introduce a new helper dev_pm_opp_xlate_performance_state() which will > > be used to translate from pstate of a device to another one. > > > > Initially this wil

Re: [PATCH 4/4] PM / Domains: Propagate performance state updates

2018-11-20 Thread Viresh Kumar
On 21-11-18, 10:33, Rajendra Nayak wrote: > Hi Viresh, > > On 11/5/2018 12:06 PM, Viresh Kumar wrote: > > This commit updates genpd core to start propagating performance state > > updates to master domains that have their set_performance_state() > > callback set. > &

Re: [PATCH V3] thermal: imx: fix for dependency on cpu-freq

2018-11-20 Thread Viresh Kumar
On Wed, Nov 21, 2018 at 8:11 AM Anson Huang wrote: > @@ -830,8 +851,7 @@ static int imx_thermal_probe(struct platform_device *pdev) > clk_disable: > clk_disable_unprepare(data->thermal_clk); > cpufreq_put: While at it, rename this label as well to something like legacy_cleanup. > -

Re: [PATCH] thermal: imx: fix for dependency on cpu-freq

2018-11-20 Thread Viresh Kumar
While I am aligned with the fact that we need to carry this code for backward compatibility, there are few things I would suggest to improve. On Wed, Oct 24, 2018 at 12:10 PM Anson Huang wrote: > static int imx_thermal_probe(struct platform_device *pdev) > { > @@ -743,6 +745,7 @@ static int

Re: [RCF PATCH,v2,2/2] pwm: imx: Configure output to GPIO in disabled state

2018-11-20 Thread Viresh Kumar
On 20-11-18, 09:35, Linus Walleij wrote: > The whole issue with splash screens and different hardware > turned over to Linux in running state is a bit imperfect I would > say, I think Viresh was working on boot constraints to get > handover of different systems components into some kind > of shape

Re: [PATCH v9 15/15] OPTIONAL: cpufreq: dt: Register an Energy Model

2018-11-19 Thread Viresh Kumar
On 19-11-18, 14:18, Quentin Perret wrote: > static int cpufreq_init(struct cpufreq_policy *policy) > { > + struct em_data_callback em_cb = EM_DATA_CB(of_est_power); > struct cpufreq_frequency_table *freq_table; > struct opp_table *opp_table = NULL; > struct private_data

Re: [PATCH v9 02/15] sched/cpufreq: Prepare schedutil for Energy Aware Scheduling

2018-11-19 Thread Viresh Kumar
On 19-11-18, 14:18, Quentin Perret wrote: > @@ -223,20 +222,33 @@ static unsigned long sugov_get_util(struct sugov_cpu > *sg_cpu) > - if ((util + cpu_util_dl(rq)) >= max) > - return max; > + if (type == FREQUENCY_UTIL) { > + /* > + * For frequency

Re: [PATCH 1/7] drivers/cpufreq: change CONFIG_6xx to CONFIG_PPC_BOOK3S_32

2018-11-18 Thread Viresh Kumar
static int dfs_set_cpu_speed(int low_speed) > } > > /* set frequency */ > -#ifdef CONFIG_6xx > +#ifdef CONFIG_PPC_BOOK3S_32 > low_choose_7447a_dfs(low_speed); > #endif > udelay(100); Acked-by: Viresh Kumar -- viresh

Re: [PATCH] boot_constraint: Add constraints for earlycon on dragonboard 410c

2018-11-16 Thread Viresh Kumar
Hi, On 16-11-18, 16:16, Sai Prakash Ranjan wrote: > iface clock is shared with other drivers, which may reconfigure > this before the serial driver comes up. This may lead to > crashes like the one below where GCC_BLSP1_AHB_CLK is same across > multiple drivers like bam dma. > > <0>[

[PATCH 10/10] ARM64: dts: uniphier: Add all CPUs in cooling maps

2018-11-16 Thread Viresh Kumar
to include all devices affected by individual trip points. Signed-off-by: Viresh Kumar --- arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi | 11 --- 1 file changed, 4 insertions(+), 7 deletions(-) diff --git a/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi b/arch/arm64/boot/dts/socionext

[PATCH 09/10] ARM64: dts: rockchip: Add all CPUs in cooling maps

2018-11-16 Thread Viresh Kumar
to include all devices affected by individual trip points. Signed-off-by: Viresh Kumar --- arch/arm64/boot/dts/rockchip/rk3328.dtsi | 5 - arch/arm64/boot/dts/rockchip/rk3368.dtsi | 15 --- arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts | 8 ++-- arch/arm64

[PATCH 00/10] ARM64: dts: Fix incomplete cooling-maps

2018-11-16 Thread Viresh Kumar
ling maps to include all devices affected by individual trip points. Individual maintainers can take the patches through their tree. -- viresh Viresh Kumar (10): ARM64: dts: amlogic: Add all CPUs in cooling maps ARM64: dts: exynos: Add all CPUs in cooling maps ARM64: dts: fsl: Add all CPUs in

[PATCH 04/10] arm64: dts: hi3660: Add missing cooling device properties for CPUs

2018-11-16 Thread Viresh Kumar
s are brought online in a different order. For example, this will happen because the operating system looks for such properties in the CPU node it is trying to bring up, so that it can register a cooling device. Add such missing properties. Signed-off-by: Viresh Kumar --- arch/arm64/boot/dts/hisilicon/hi366

[PATCH 06/10] ARM64: dts: mediatek: Add all CPUs in cooling maps

2018-11-16 Thread Viresh Kumar
to include all devices affected by individual trip points. Signed-off-by: Viresh Kumar --- arch/arm64/boot/dts/mediatek/mt7622.dtsi | 9 ++--- arch/arm64/boot/dts/mediatek/mt8173.dtsi | 6 -- 2 files changed, 10 insertions(+), 5 deletions(-) diff --git a/arch/arm64/boot/dts/mediatek/mt7622.dtsi

[PATCH 05/10] ARM64: dts: hisilicon: Add all CPUs in cooling maps

2018-11-16 Thread Viresh Kumar
to include all devices affected by individual trip points. Signed-off-by: Viresh Kumar --- arch/arm64/boot/dts/hisilicon/hi3660.dtsi | 10 -- arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 9 - 2 files changed, 16 insertions(+), 3 deletions(-) diff --git a/arch/arm64/boot/dts/hisilicon

[PATCH 07/10] ARM64: dts: msm8916: Add all CPUs in cooling maps

2018-11-16 Thread Viresh Kumar
to include all devices affected by individual trip points. Signed-off-by: Viresh Kumar --- arch/arm64/boot/dts/qcom/msm8916.dtsi | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi b/arch/arm64/boot/dts/qcom/msm8916.dtsi index

[PATCH 01/10] ARM64: dts: amlogic: Add all CPUs in cooling maps

2018-11-16 Thread Viresh Kumar
to include all devices affected by individual trip points. Signed-off-by: Viresh Kumar --- .../dts/amlogic/meson-gxm-khadas-vim2.dts | 22 --- 1 file changed, 9 insertions(+), 13 deletions(-) diff --git a/arch/arm64/boot/dts/amlogic/meson-gxm-khadas-vim2.dts b/arch/arm64/boot/dts

[PATCH 02/10] ARM64: dts: exynos: Add all CPUs in cooling maps

2018-11-16 Thread Viresh Kumar
to include all devices affected by individual trip points. Signed-off-by: Viresh Kumar --- .../arm64/boot/dts/exynos/exynos5433-tmu.dtsi | 36 --- 1 file changed, 24 insertions(+), 12 deletions(-) diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tmu.dtsi b/arch/arm64/boot/dts/exynos

[PATCH 03/10] ARM64: dts: fsl: Add all CPUs in cooling maps

2018-11-16 Thread Viresh Kumar
to include all devices affected by individual trip points. Signed-off-by: Viresh Kumar --- .../arm64/boot/dts/freescale/fsl-ls1043a.dtsi | 6 ++-- .../arm64/boot/dts/freescale/fsl-ls1046a.dtsi | 6 ++-- .../arm64/boot/dts/freescale/fsl-ls1088a.dtsi | 17 ++- .../arm64/boot/dts/freescale/fsl

[PATCH 3/6] ARM: dts: mt7623: Add all CPUs in cooling maps

2018-11-16 Thread Viresh Kumar
to include all devices affected by individual trip points. Signed-off-by: Viresh Kumar --- arch/arm/boot/dts/mt7623.dtsi | 15 --- 1 file changed, 12 insertions(+), 3 deletions(-) diff --git a/arch/arm/boot/dts/mt7623.dtsi b/arch/arm/boot/dts/mt7623.dtsi index d01bdee6f2f3..7cae886f79c9

[PATCH 5/6] ARM: dts: sunxi: Add all CPUs in cooling maps

2018-11-16 Thread Viresh Kumar
to include all devices affected by individual trip points. Signed-off-by: Viresh Kumar --- arch/arm/boot/dts/sun6i-a31.dtsi | 11 +++ arch/arm/boot/dts/sun7i-a20.dtsi | 5 +++-- arch/arm/boot/dts/sun8i-a33.dtsi | 16 +++- 3 files changed, 21 insertions(+), 11 deletions(-) diff

[PATCH 6/6] ARM: dts: uniphier: Add all CPUs in cooling maps

2018-11-16 Thread Viresh Kumar
to include all devices affected by individual trip points. Signed-off-by: Viresh Kumar --- arch/arm/boot/dts/uniphier-pxs2.dtsi | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/arch/arm/boot/dts/uniphier-pxs2.dtsi b/arch/arm/boot/dts/uniphier-pxs2.dtsi index 8d20e9548e39

[PATCH 1/6] ARM: dts: exynos: Add all CPUs in cooling maps

2018-11-16 Thread Viresh Kumar
to include all devices affected by individual trip points. Signed-off-by: Viresh Kumar --- arch/arm/boot/dts/exynos3250-artik5.dtsi | 6 +- arch/arm/boot/dts/exynos3250-monk.dts | 6 +- arch/arm/boot/dts/exynos3250-rinato.dts | 6 +- arch/arm/boot/dts/exynos4210-trats.dts

[PATCH 2/6] ARM: dts: ls1021a: Add all CPUs in cooling maps

2018-11-16 Thread Viresh Kumar
to include all devices affected by individual trip points. Signed-off-by: Viresh Kumar --- arch/arm/boot/dts/ls1021a.dtsi | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/boot/dts/ls1021a.dtsi b/arch/arm/boot/dts/ls1021a.dtsi index bdd6e66a79ad..2a411eb1ebb0 100644 --- a/arch/arm/boot/dts

[PATCH 0/6] ARM: dts: Fix incomplete cooling-maps

2018-11-16 Thread Viresh Kumar
include all devices affected by individual trip points. -- viresh Viresh Kumar (6): ARM: dts: exynos: Add all CPUs in cooling maps ARM: dts: ls1021a: Add all CPUs in cooling maps ARM: dts: mt7623: Add all CPUs in cooling maps ARM: dts: rockchip: Add all CPUs in cooling maps ARM: dts:

[PATCH 4/6] ARM: dts: rockchip: Add all CPUs in cooling maps

2018-11-16 Thread Viresh Kumar
to include all devices affected by individual trip points. Signed-off-by: Viresh Kumar --- arch/arm/boot/dts/rk322x.dtsi | 10 +++-- arch/arm/boot/dts/rk3288-veyron-mickey.dts | 24 +- arch/arm/boot/dts/rk3288.dtsi | 15 +++--- 3 files changed

Re: Crash in msm serial on dragonboard with ftrace bootargs

2018-11-15 Thread Viresh Kumar
On Thu, Nov 15, 2018 at 4:23 PM Srinivas Kandagatla wrote: > Yes, this is not the solution, but it proves that the hand-off between > booloaders and kernel is the issue. > > In general there is wider issue with resources hand-off between > bootloader and kernel. > > There has been some proposal

Re: [PATCH v4] cpufreq: ti-cpufreq: Only register platform_device when supported

2018-11-13 Thread Viresh Kumar
platform_device_register_simple("ti-cpufreq", -1, NULL, 0); > + const struct of_device_id *match; > + > + /* Check to ensure we are on a compatible platform */ > + match = ti_cpufreq_match_node(); > + if (match) > + platform_device_register_data(NULL, "ti-cpufreq", -1, match, > + sizeof(*match)); > + > return 0; > } > module_init(ti_cpufreq_init); Acked-by: Viresh Kumar -- viresh

Re: [PATCH 0/2] opp: ti-opp-supply: Fixes

2018-11-12 Thread Viresh Kumar
On 07-11-18, 10:04, Keerthy wrote: > The series brings in couple of fixes to the ti-opp-supply driver. > One of them updates u_volt_min dynamically and avoids hang due > to lesser static u_volt_min and the other fixes the supply in > _get_optimal_vdd_voltage. Applied both patches after manually

[tip:sched/core] sched/core: Clean up the #ifdef block in add_nr_running()

2018-11-12 Thread tip-bot for Viresh Kumar
Commit-ID: 3e184501083c38fa091f640acb13af17a21fd228 Gitweb: https://git.kernel.org/tip/3e184501083c38fa091f640acb13af17a21fd228 Author: Viresh Kumar AuthorDate: Tue, 6 Nov 2018 11:12:57 +0530 Committer: Ingo Molnar CommitDate: Mon, 12 Nov 2018 11:18:06 +0100 sched/core: Clean up

[tip:sched/core] sched/core: Create task_has_idle_policy() helper

2018-11-11 Thread tip-bot for Viresh Kumar
Commit-ID: 1da1843f9f0334e2428308945d396ffecc2acfe1 Gitweb: https://git.kernel.org/tip/1da1843f9f0334e2428308945d396ffecc2acfe1 Author: Viresh Kumar AuthorDate: Mon, 5 Nov 2018 16:51:55 +0530 Committer: Ingo Molnar CommitDate: Mon, 12 Nov 2018 06:17:52 +0100 sched/core: Create

Re: [PATCH 1/2] opp: ti-opp-supply: Dynamically update u_volt_min

2018-11-07 Thread Viresh Kumar
On 07-11-18, 10:04, Keerthy wrote: > The voltage range (min, max) provided in the device tree is from > the data manual and is pretty big, catering to a wide range of devices. > On a i2c read/write failure the regulator_set_voltage_triplet function > falls back to set voltage between min and max.

Re: [PATCH 0/2] opp: ti-opp-supply: Fixes

2018-11-07 Thread Viresh Kumar
On 07-11-18, 10:04, Keerthy wrote: > The series brings in couple of fixes to the ti-opp-supply driver. > One of them updates u_volt_min dynamically and avoids hang due > to lesser static u_volt_min and the other fixes the supply in > _get_optimal_vdd_voltage. > > Keerthy (2): > power: opp:

Re: [PATCH 2/9] arm64: defconfig: Drop ARM_BIG_LITTLE_CPUFREQ

2018-11-07 Thread Viresh Kumar
defconfig > > @@ -107,7 +107,6 @@ CONFIG_CPU_FREQ_GOV_SCHEDUTIL=y > > CONFIG_CPUFREQ_DT=y > > CONFIG_ACPI_CPPC_CPUFREQ=m > > CONFIG_ARM_ARMADA_37XX_CPUFREQ=y > > -CONFIG_ARM_BIG_LITTLE_CPUFREQ=y > > CONFIG_ARM_SCPI_CPUFREQ=y > > CONFIG_ARM_TEGRA186_CPUFREQ=y > > CONFIG_ARM_SCPI_PROTOCOL=y Acked-by: Viresh Kumar -- viresh

Re: [PATCH] cpufreq: s3c24xx: Change to use DEFINE_SHOW_ATTRIBUTE macro

2018-11-07 Thread Viresh Kumar
NULL, _io); > + NULL, _fops); > > dbgfs_file_info = debugfs_create_file("info", S_IRUGO, dbgfs_root, > - NULL, _info); > + NULL, _fops); > > dbgfs_file_board = debugfs_create_file("board", S_IRUGO, dbgfs_root, > -NULL, _board); > +NULL, _fops); > > return 0; > } Acked-by: Viresh Kumar -- viresh

[PATCH] sched: Fix the ifdef block in add_nr_running()

2018-11-05 Thread Viresh Kumar
There is no point in keeping the conditional statement of the if block outside of the ifdef block, while all of its body is contained within the ifdef block. Move the conditional statement as well under the ifdef block. Signed-off-by: Viresh Kumar --- kernel/sched/sched.h | 4 ++-- 1 file

[PATCH] sched: Create task_has_idle_policy() helper

2018-11-05 Thread Viresh Kumar
We already have task_has_rt_policy() and task_has_dl_policy() helpers, create task_has_idle_policy() as well and update sched core to start using it. While at it, use task_has_dl_policy() at one more place. Signed-off-by: Viresh Kumar --- kernel/sched/core.c | 4 ++-- kernel/sched/debug.c

[PATCH 2/4] PM / Domains: Save OPP table pointer in genpd

2018-11-04 Thread Viresh Kumar
We will need these going forward in hotpath, i.e. from within dev_pm_genpd_set_performance_state(). Lets fetch and save them while the OPP tables are added. Signed-off-by: Viresh Kumar --- drivers/base/power/domain.c | 23 +-- include/linux/pm_domain.h | 2 ++ 2 files

[PATCH 0/4] PM / Domains: Allow performance state propagation

2018-11-04 Thread Viresh Kumar
o run some tests and tell me if some stuff is still missing as per Qcom requirements ? Based on opp/linux-next branch (which is 4.20-rc1 + multiple-power-domain-support-in-opp-core). -- viresh Viresh Kumar (4): OPP: Add dev_pm_opp_xlate_performance_state() helper PM / Domains: Save OPP tab

[PATCH 1/4] OPP: Add dev_pm_opp_xlate_performance_state() helper

2018-11-04 Thread Viresh Kumar
Introduce a new helper dev_pm_opp_xlate_performance_state() which will be used to translate from pstate of a device to another one. Initially this will be used by genpd to find pstate of a master domain using its sub-domain's pstate. Signed-off-by: Viresh Kumar --- drivers/opp/core.c | 49

[PATCH 4/4] PM / Domains: Propagate performance state updates

2018-11-04 Thread Viresh Kumar
while powering-on a genpd as well, as we ignore performance state requirements from sub-domains which are powered-off. For this reason _genpd_power_on() also received the additional parameter, depth, which is used for hierarchical locking within genpd. Signed-off-by: Viresh Kumar --- drivers/base

[PATCH 3/4] PM / Domains: Factorize dev_pm_genpd_set_performance_state()

2018-11-04 Thread Viresh Kumar
Separate out _genpd_set_performance_state() and _genpd_reeval_performance_state() from dev_pm_genpd_set_performance_state() to handle performance state update related stuff. This will be used by a later commit. Signed-off-by: Viresh Kumar --- drivers/base/power/domain.c | 104

Re: [PATCH] cpufreq: imx6q: add return value check for voltage scale

2018-11-04 Thread Viresh Kumar
regulator_set_voltage_tol(arm_reg, volt_old, 0); > + ret1 = regulator_set_voltage_tol(arm_reg, volt_old, 0); > + if (ret1) > + dev_warn(cpu_dev, > + "failed to restore vddarm voltage: %d\n", > ret1); > return ret; > } > Acked-by: Viresh Kumar -- viresh

[PATCH V4 09/10] OPP: Rename and relocate of_genpd_opp_to_performance_state()

2018-11-02 Thread Viresh Kumar
his commit renames of_genpd_opp_to_performance_state() as of_get_required_opp_performance_state() and moves it to the OPP core, as it is all about OPP stuff now. Reviewed-by: Ulf Hansson Signed-off-by: Viresh Kumar --- V3->V4: - Return 0 from of_get_required_opp_performance_state() on

Re: [PATCH 1/4] base/drivers/arch_topology: Remove useless check

2018-10-30 Thread Viresh Kumar
On 30-10-18, 14:35, Daniel Lezcano wrote: > I'm wondering if having a statically per_cpu variable, even if it is not > free at the end, isn't worth regarding the twisted code we end up with > an allocation. Maybe yeah. -- viresh

Re: [PATCH 4/4] base/drivers/topology: Default dmpis-mhz if they are not set in DT

2018-10-30 Thread Viresh Kumar
> > That reflects the capacity for the max frequencies 1593600 and 2150400. > > Cc: Chris Redpath > Cc: Quentin Perret > Cc: Viresh Kumar > Cc: Amit Kucheria > Cc: Nicolas Dechesne > Cc: Niklas Cassel > Signed-off-by: Daniel Lezcano > --- > drivers/bas

Re: [PATCH 4/4] base/drivers/topology: Default dmpis-mhz if they are not set in DT

2018-10-30 Thread Viresh Kumar
On 30-10-18, 09:39, Daniel Lezcano wrote: > SCHED_CAPACITY_SCALE is the default value in this file. > > eg. > > DEFINE_PER_CPU(unsigned long, cpu_scale) = SCHED_CAPACITY_SCALE > ... > pr_err("cpu_capacity: partial information: fallback to 1024 for all > CPUs\n"); > ... > > So I prefer to use

Re: [PATCH 1/4] base/drivers/arch_topology: Remove useless check

2018-10-30 Thread Viresh Kumar
On 30-10-18, 08:55, Daniel Lezcano wrote: > The workqueue is called from init_cpu_capacity_callback(). This one is > called in the notifier callback. IOW the notification callback > unregisters itself. But if it is not registered, it won't unregister, > hence it won't call the workqueue and

Re: [PATCH 4/4] base/drivers/topology: Default dmpis-mhz if they are not set in DT

2018-10-30 Thread Viresh Kumar
in the DT (correct results) > > correct results are: > cat /sys/devices/system/cpu/cpu*/cpu_capacity >758 >758 > 1024 > 1024 > > ... respectively for CPU0, CPU1, CPU2 and CPU3. > > That reflects the capacity for the max frequencies 1593600 and 2150400. >

  1   2   3   4   5   6   7   8   9   10   >