On 10-12-20, 11:09, Ionela Voinescu wrote:
> On Thursday 10 Dec 2020 at 15:12:25 (+0530), Viresh Kumar wrote:
> > Avoid the static_branch_enable() and static_branch_disable() dance by
> > redoing the code in a different way. We will be fully invariant here
> > only if amu_fie
My intent was to keep the logical working of the code as is (in all
the patches I have sent today), let me see if I broke that assumption
somewhere unintentionally.
On 10-12-20, 10:38, Ionela Voinescu wrote:
> I'm first of all replying to discuss the need of this policy analysis
> that
On 10-12-20, 12:48, Viresh Kumar wrote:
> Every time I have stumbled upon this routine, I get confused with the
> way 'have_policy' is used and I have to dig in to understand why is it
> so.
>
> Here is an attempt to make it easier to understand, and hopefully it is
&
of the routine if we enabled the static
branch, followed by a disable.
Also make the first call to topology_scale_freq_invariant() just when we
need it, instead of at the top of the routine. This makes it further
clear on why we need it, i.e. just around enabling AMUs use here.
Signed-off-by: Viresh
if cpufreq policy wasn't available for any CPU.
Signed-off-by: Viresh Kumar
---
Ionela, I think it would be even better to do this over this patch
- /*
-* If none of the CPUs have cpufreq support, we only enable
-* the use of the AMU feature for FIE if all CPUs support AMU
The previous call to update_freq_counters_refs() has already updated the
per-cpu variables, don't overwrite them with the same value again.
Fixes: 4b9cf23c179a ("arm64: wrap and generalise counter read functions")
Signed-off-by: Viresh Kumar
---
arch/arm64/kernel/topology.c | 6 +---
On 17-11-20, 15:32, Viresh Kumar wrote:
> Hi Jassi,
>
> Here is the updated version based on your suggestions.
>
> I feel bad that I haven't implemented the single-word protocol as a
> special case of multi-word one in the earlier attempt. Perhaps I was too
> consumed by
On 08-12-20, 17:42, Nicola Mazzucato wrote:
> Hi All,
>
> In this V5 posting I have addressed suggestions on opp/of and scmi-cpufreq
> driver.
>
> This is to support systems where exposed cpu performance controls are more
> fine-grained that the platform's ability to scale cpus independently.
>
On 08-12-20, 11:20, Sudeep Holla wrote:
> It is because of per-CPU vs per domain drama here. Imagine a system with
> 4 CPUs which the firmware puts in individual domains while they all are
> in the same perf domain and hence OPP is marked shared in DT.
>
> Since this probe gets called for all the
On 08-12-20, 18:01, Rafael J. Wysocki wrote:
> On Tue, Dec 8, 2020 at 9:52 AM Viresh Kumar wrote:
> >
> > On 07-12-20, 17:29, Rafael J. Wysocki wrote:
> > > From: Rafael J. Wysocki
> > >
> > > When avoiding reduction of the frequency after the target
On 08-12-20, 15:50, Peter Zijlstra wrote:
> On Tue, Dec 08, 2020 at 09:46:54AM +0530, Viresh Kumar wrote:
> > Viresh Kumar (3):
> > sched/core: Move schedutil_cpu_util() to core.c
> > sched/core: Rename schedutil_cpu_util() and allow rest of the kernel
> >
On 08-12-20, 10:58, Nicola Mazzucato wrote:
>
>
> On 12/8/20 7:26 AM, Viresh Kumar wrote:
> > On 08-12-20, 07:22, Nicola Mazzucato wrote:
> >> On 12/8/20 5:50 AM, Viresh Kumar wrote:
> >>> On 02-12-20, 17:23, Nicola Mazzucato wrote:
> >>>>
On 07-12-20, 17:35, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> First off, some cpufreq drivers (eg. intel_pstate) can pass hints
> beyond the current target frequency to the hardware and there are no
> provisions for doing that in the cpufreq framework. In particular,
> today the
On 07-12-20, 17:29, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> When avoiding reduction of the frequency after the target CPU has
> been busy since the previous frequency update, adjust the utilization
> instead of adjusting the frequency, because doing so is more prudent
> (it is
l;
> unsigned long max;
>
> @@ -276,16 +277,15 @@ unsigned long schedutil_cpu_util(int cpu
> return min(max, util);
> }
>
> -static unsigned long sugov_get_util(struct sugov_cpu *sg_cpu)
> +static void sugov_get_util(struct sugov_cpu *sg_cpu)
Maybe name it sugov_update_util() ?
Otherwise,
Acked-by: Viresh Kumar
--
viresh
Please use --thread=shallow while creating the patches, I use the following
options normally, so they appear as a thread.
git format-patch -C -M --thread=shallow
--
viresh
On 08-12-20, 07:22, Nicola Mazzucato wrote:
> On 12/8/20 5:50 AM, Viresh Kumar wrote:
> > On 02-12-20, 17:23, Nicola Mazzucato wrote:
> >>nr_opp = dev_pm_opp_get_opp_count(cpu_dev);
> >>if (nr_opp <= 0) {
> >> - dev_dbg(cpu_dev, &qu
On 02-12-20, 17:23, Nicola Mazzucato wrote:
> By design, SCMI performance domains define the granularity of
> performance controls, they do not describe any underlying hardware
> dependencies (although they may match in many cases).
>
> It is therefore possible to have some platforms where
On 07-12-20, 12:43, Viresh Kumar wrote:
> On 24-11-20, 10:43, Lukasz Luba wrote:
> > Hi all,
> >
> > The Energy Model (EM) supports power values expressed in an abstract scale
> > via new API. The SCMI performance protocol provides the information about
> > power
Subject should rather be:
dt-bindings: opp: Allow empty OPP tables
On 02-12-20, 17:23, Nicola Mazzucato wrote:
> Currently the optional property opp-shared is used within an opp table
> to tell that a set of devices share their clock/voltage lines (and the
> opp points).
> It is therefore
-by: Viresh Kumar
---
include/linux/sched.h| 5 +
kernel/sched/core.c | 10 --
kernel/sched/cpufreq_schedutil.c | 2 +-
kernel/sched/fair.c | 6 +++---
kernel/sched/sched.h | 10 +-
5 files changed, 22 insertions(+), 11
,0x5c,0x5b,0x5c,0x5c,0x51,0x5b}}
dynamic_power=4672
As can be seen, the idle time based load is 100% for all the CPUs as it
took only the last window into account, but in reality the CPUs aren't
that loaded as shown by the utilization numbers.
Reviewed-by: Lukasz Luba
Signed-off-by: Viresh Kumar
There is nothing schedutil specific in schedutil_cpu_util(), move it to
core.c and define it only for CONFIG_SMP.
Acked-by: Rafael J. Wysocki
Signed-off-by: Viresh Kumar
---
kernel/sched/core.c | 108 +++
kernel/sched/cpufreq_schedutil.c | 106
and !SMP implementations in the cpufreq_cooling driver.
- Improved commit log with testing related information.
--
Viresh
Viresh Kumar (3):
sched/core: Move schedutil_cpu_util() to core.c
sched/core: Rename schedutil_cpu_util() and allow rest of the kernel
to use it
thermal: cpufreq_cooli
On 03-12-20, 12:54, Dietmar Eggemann wrote:
> On 24/11/2020 07:26, Viresh Kumar wrote:
> > Several parts of the kernel are already using the effective CPU
> > utilization (as seen by the scheduler) to get the current load on the
> > CPU, do the same here instead of depen
Hi Valentin,
On 01-12-20, 17:25, Valentin Schneider wrote:
> PELT time-scaling can make the util signals behave strangely from an
> external PoV. For instance, on a big.LITTLE system, the rq util of a LITTLE
> CPU may suddenly drop if it was stuck on a too-low OPP for some time and
> eventually
On 30-11-20, 19:37, Rafael J. Wysocki wrote:
> Index: linux-pm/include/linux/cpufreq.h
> ===
> --- linux-pm.orig/include/linux/cpufreq.h
> +++ linux-pm/include/linux/cpufreq.h
> @@ -320,6 +320,15 @@ struct cpufreq_driver {
>
_protocol.h| 1 +
> 3 files changed, 12 insertions(+), 1 deletion(-)
Acked-by: Viresh Kumar
--
viresh
On 03-12-20, 23:55, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> Wtihout CONFIG_COMMON_CLK, the scmi driver fails to link:
>
> arm-linux-gnueabi-ld: drivers/cpufreq/scmi-cpufreq.o: in function
> `scmi_cpufreq_probe':
> scmi-cpufreq.c:(.text+0x20c): undefined reference to
>
On 03-12-20, 23:53, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> A driver should not 'select' drivers from another subsystem.
> If NVMEM is disabled, this one results in a warning:
>
> WARNING: unmet direct dependencies detected for NVMEM_IMX_OCOTP
> Depends on [n]: NVMEM [=n] && (ARCH_MXC
On 19-11-20, 11:35, Viresh Kumar wrote:
> On 18-11-20, 08:53, Rob Clark wrote:
> > On Tue, Nov 17, 2020 at 9:28 PM Viresh Kumar
> > wrote:
> > >
> > > On 17-11-20, 09:02, Rob Clark wrote:
> > > > With that on top of the previous patch,
> &
On 24-11-20, 09:10, Quentin Perret wrote:
> Hey Viresh,
>
> On Tuesday 24 Nov 2020 at 11:56:15 (+0530), Viresh Kumar wrote:
> > There is nothing schedutil specific in schedutil_cpu_util(), rename it
> > to effective_cpu_util(). Also create and expose another wrapper
> >
On 20-10-20, 16:31, Viresh Kumar wrote:
> From: Arnd Bergmann
>
> The dcookies stuff is used only with OPROFILE and there is no need to
> build it if CONFIG_OPROFILE isn't enabled. Build it depending on
> CONFIG_OPROFILE instead of CONFIG_PROFILING.
>
> Signed-off-by: Arnd
th SMP and !SMP implementations in the cpufreq_cooling driver.
- Improved commit log with testing related information.
--
Viresh
Viresh Kumar (3):
sched/core: Move schedutil_cpu_util() to core.c
sched/core: Rename schedutil_cpu_util() and allow rest of the kernel
to use it
t
,0x5c,0x5b,0x5c,0x5c,0x51,0x5b}}
dynamic_power=4672
As can be seen, the idle time based load is 100% for all the CPUs as it
took only the last window into account, but in reality the CPUs aren't
that loaded as shown by the utilization numbers.
Reviewed-by: Lukasz Luba
Signed-off-by: Viresh Kumar
There is nothing schedutil specific in schedutil_cpu_util(), rename it
to effective_cpu_util(). Also create and expose another wrapper
sched_cpu_util() which can be used by other parts of the kernel, like
thermal core (that will be done in a later commit).
Signed-off-by: Viresh Kumar
There is nothing schedutil specific in schedutil_cpu_util(), move it to
core.c and define it only for CONFIG_SMP.
Signed-off-by: Viresh Kumar
---
kernel/sched/core.c | 108 +++
kernel/sched/cpufreq_schedutil.c | 106 --
kernel
On 23-11-20, 15:32, Lukasz Luba wrote:
> LGTM. It has potential. We will see how far we can improve IPA with this
> model.
>
> Reviewed-by: Lukasz Luba
Thanks Lukasz for your review :)
--
viresh
On 20-11-20, 14:51, Lukasz Luba wrote:
> On 11/19/20 7:38 AM, Viresh Kumar wrote:
> > Scenario 1: The CPUs were mostly idle in the previous polling window of
> > the IPA governor as the tasks were sleeping and here are the details
> > from traces (load is
On 19-11-20, 13:30, Rafael J. Wysocki wrote:
> On Thu, Nov 19, 2020 at 8:38 AM Viresh Kumar wrote:
> >
> > There is nothing schedutil specific in schedutil_cpu_util(), move it to
> > core.c and rename it to sched_cpu_util(), so it can be used from other
> >
On 20-11-20, 13:06, Jassi Brar wrote:
> On Tue, Nov 17, 2020 at 4:02 AM Viresh Kumar wrote:
>
> > +
> > +/**
> > + * struct mhuv2 - MHUv2 mailbox controller data
> > + *
> > + * @mbox: Mailbox controller belonging to the MHU frame.
> > + * @send/
On 23-11-20, 03:27, Dmitry Osipenko wrote:
> This series brings initial support for memory interconnect to Tegra20,
> Tegra30 and Tegra124 SoCs.
>
> For the starter only display controllers and devfreq devices are getting
> interconnect API support, others could be supported later on. The display
On 20-11-20, 09:13, Quentin Perret wrote:
> On Friday 20 Nov 2020 at 09:56:53 (+0100), Peter Zijlstra wrote:
> > On Fri, Nov 20, 2020 at 08:55:27AM +0100, Peter Zijlstra wrote:
> > > - In saturated scenarios task movement will cause some transient dips,
> > >suppose we have a CPU saturated
/2.
V2->V3:
- Put the scheduler helpers within ifdef CONFIG_SMP.
- Keep both SMP and !SMP implementations in the cpufreq_cooling driver.
- Improved commit log with testing related information.
--
Viresh
Viresh Kumar (2):
sched/core: Rename and move schedutil_cpu_util() to core.c
ther
the idle time based load is 100% for all the CPUs as it
took only the last window into account, but in reality the CPUs aren't
that loaded as shown by the utilization numbers.
Signed-off-by: Viresh Kumar
---
drivers/thermal/cpufreq_cooling.c | 68 ---
1 file changed,
There is nothing schedutil specific in schedutil_cpu_util(), move it to
core.c and rename it to sched_cpu_util(), so it can be used from other
parts of the kernel as well.
The cpufreq_cooling stuff will make use of this in a later commit.
Signed-off-by: Viresh Kumar
---
include/linux/sched.h
On 02-11-20, 12:01, Nicola Mazzucato wrote:
> Second proposal:
>
> Another option could be for each driver to store internally the performance
> dependencies and let the driver directly provide the correct cpumask for
> any consumer.
>From the discussion that happened in this thread, looks like
On 18-11-20, 13:00, Rafael J. Wysocki wrote:
> On Wed, Nov 18, 2020 at 5:42 AM Viresh Kumar wrote:
> >
> > On 17-11-20, 14:06, Rafael J. Wysocki wrote:
> > > Is this really a cpufreq thing, though, or is it arch stuff? I think
> > > the latter, because it is not
There is a lot of stuff here which can be done outside of the
opp_table->lock, do that. This helps avoiding a circular dependency
lockdeps around debugfs.
Reported-by: Rob Clark
Signed-off-by: Viresh Kumar
---
drivers/opp/core.c | 94 +++---
1 f
On 18-11-20, 08:53, Rob Clark wrote:
> On Tue, Nov 17, 2020 at 9:28 PM Viresh Kumar wrote:
> >
> > On 17-11-20, 09:02, Rob Clark wrote:
> > > With that on top of the previous patch,
> >
> > Don't you still have this ? Which fixed the lockdep in the remove p
gt; drivers/cpufreq/cpufreq.c | 72
> +++---
> 1 file changed, 36 insertions(+), 36 deletions(-)
Acked-by: Viresh Kumar
--
viresh
On 17-11-20, 09:02, Rob Clark wrote:
> With that on top of the previous patch,
Don't you still have this ? Which fixed the lockdep in the remove path.
https://lore.kernel.org/lkml/20201022080644.2ck4okrxygmkuatn@vireshk-i7/
To make it clear you need these patches to fix the OPP stuff:
//From
On 17-11-20, 14:06, Rafael J. Wysocki wrote:
> Is this really a cpufreq thing, though, or is it arch stuff? I think
> the latter, because it is not necessary for anything in cpufreq.
>
> Yes, acpi-cpufreq happens to know this information, because it uses
> processor_perflib, but the latter may
On 17-11-20, 17:17, Dmitry Osipenko wrote:
> 17.11.2020 13:07, Viresh Kumar пишет:
> > On 16-11-20, 00:29, Dmitry Osipenko wrote:
> >> This patch moves ACTMON driver away from generating OPP table by itself,
> >> transitioning it to use the table which comes from de
local_clock() has better precision and accuracy as compared to jiffies,
lets use it for time management in cpufreq stats.
Signed-off-by: Viresh Kumar
---
V2:
- Doesn't change the units to msec and use local_clock() instead of
ktime.
drivers/cpufreq/cpufreq_stats.c | 16
1
On 17-11-20, 10:47, Lukasz Luba wrote:
> Fair enough. What if we come back with experiments results in future?
> Currently we are trying to conduct experiments with Nicola on modified Juno
> firmware and kernel)
Sure. If we think it improves things, why not. I just wanted to make
sure we
On 17-11-20, 10:47, Nicola Mazzucato wrote:
> Freq-invariance has been mentioned. I suppose the fix will depend on which
> strategy we prefer to solve this.
I am not sure how FIE will use this information, as I thought the
problem is about knowing the current frequency on a CPU instead of
which
On 16-11-20, 11:33, Lukasz Luba wrote:
> On 11/9/20 6:57 AM, Viresh Kumar wrote:
> > On 06-11-20, 11:14, Lukasz Luba wrote:
> > > I also had similar doubts, because if we make frequency requests
> > > independently for each CPU, why not having N cooling devs, which
>
On 16-11-20, 00:29, Dmitry Osipenko wrote:
> This patch moves ACTMON driver away from generating OPP table by itself,
> transitioning it to use the table which comes from device-tree. This
> change breaks compatibility with older device-trees in order to bring
> support for the interconnect
This patch adds device tree binding for ARM Message Handling Unit (MHU)
controller version 2.
Based on earlier work by Morten Borup Petersen.
Reviewed-by: Rob Herring
Co-developed-by: Tushar Khandelwal
Signed-off-by: Tushar Khandelwal
Signed-off-by: Viresh Kumar
---
.../bindings/mailbox/arm
rks with 1 or more windows.
- Moved register names to small case.
Rob, I have kept your Reviewed-by tag as is, please let me know if you
would like to revoke it.
--
Viresh
Viresh Kumar (2):
dt-bindings: mailbox : arm,mhuv2: Add bindings
mailbox: arm_mhuv2: Add driver
.../bindings/mailbox/
through struct arm_mhuv2_mbox_msg.
Based on the initial work done by Morten Borup Petersen from ARM.
Co-developed-by: Tushar Khandelwal
Signed-off-by: Tushar Khandelwal
Tested-by: Usama Arif
Signed-off-by: Viresh Kumar
---
MAINTAINERS |9 +
drivers/mailbox
On Fri, 6 Nov 2020 at 12:46, Viresh Kumar wrote:
>
> On 05-11-20, 11:24, Rob Clark wrote:
> > On Tue, Nov 3, 2020 at 7:04 PM Viresh Kumar wrote:
> > >
> > > On 03-11-20, 08:50, Rob Clark wrote:
> > > > sorry, it didn't apply cleanly (which I guess
off-by: Sudeep Holla
> ---
> .../bindings/dvfs/performance-domain.yaml | 76 +++
> 1 file changed, 76 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/dvfs/performance-domain.yaml
Acked-by: Viresh Kumar
--
viresh
On 16-11-20, 15:55, Jon Hunter wrote:
> Hi Rafael,
>
> On 04/11/2020 09:33, Viresh Kumar wrote:
> > On 03-11-20, 11:55, Jon Hunter wrote:
> >> Commit b89c01c96051 ("cpufreq: tegra186: Fix initial frequency")
> >> implemented the CPUFREQ 'get' callb
rn false;
>
> sg_policy->next_freq = next_freq;
> sg_policy->last_freq_update_time = time;
>
Acked-by: Viresh Kumar
--
viresh
On 23-10-20, 12:37, Peter Zijlstra wrote:
> Actual numbers that show the goodness would be nice ;-) Because clearly
> we're doing this make it better.
Hi Peter,
I tried the patchset with hackbench, sysbench and schbench. None of them showed
any regression or significant improvements. schbench
On 11-11-20, 09:13, Thomas Renninger wrote:
> Am Mittwoch, 11. November 2020, 06:13:50 CET schrieb Viresh Kumar:
> > On 10-11-20, 13:53, Thomas Renninger wrote:
> > > Am Dienstag, 10. November 2020, 12:07:37 CET schrieb Viresh Kumar:
> > > > The cpufreq and th
On 11-11-20, 10:32, Dmitry Osipenko wrote:
> 11.11.2020 09:18, Viresh Kumar пишет:
> > On 11-11-20, 09:14, Dmitry Osipenko wrote:
> >> The dev_pm_opp_of_add_table() will produce a error message which doesn't
> >> give a clue about what's wrong, i.e. that devi
On 11-11-20, 09:14, Dmitry Osipenko wrote:
> 11.11.2020 08:53, Viresh Kumar пишет:
> >> +static int tegra_emc_opp_table_init(struct tegra_emc *emc)
> >> +{
> >> + struct opp_table *reg_opp_table = NULL, *clk_opp_table, *hw_opp_table;
> >> + u32 hw_ver
On 27-10-20, 17:23, Viresh Kumar wrote:
> This adds driver for the ARM MHUv2 (Message Handling Unit) mailbox
> controller.
>
> This is based on the accepted DT bindings of the controller and supports
> combination of all transport protocols, i.e. single-word, multi-word
On 03-11-20, 16:11, Pali Rohár wrote:
> Some of cpufreq drivers are tristate, can be compiled as modules, but do
> not have defined modalias for automatic loading. This patch series add
> for all those cpufreq drivers missing MODULE_DEVICE_TABLE macro, based
> on OF definitions, or MODULE_ALIAS
On 11-11-20, 11:15, Viresh Kumar wrote:
> On 11-11-20, 04:14, Dmitry Osipenko wrote:
> > The dev_pm_opp_get_opp_table() shouldn't be used by drivers, use
> > dev_pm_opp_set_clkname() instead.
> >
> > Suggested-by: Viresh Kumar
> > Signed-off-by: Dmitry Osipenko
On 11-11-20, 04:14, Dmitry Osipenko wrote:
> +static int tegra_emc_opp_table_init(struct tegra_emc *emc)
> +{
> + struct opp_table *reg_opp_table = NULL, *clk_opp_table, *hw_opp_table;
> + u32 hw_version = BIT(tegra_sku_info.soc_speedo_id);
> + const char *rname = "core";
> + int
On 11-11-20, 04:14, Dmitry Osipenko wrote:
> The dev_pm_opp_get_opp_table() shouldn't be used by drivers, use
> dev_pm_opp_set_clkname() instead.
>
> Suggested-by: Viresh Kumar
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/memory/tegra/tegra20-emc.c | 30 ++
On 10-11-20, 13:59, Rafael J. Wysocki wrote:
> Well, this may confuse user space using the stats today.
>
> But whoever uses cpupower may be confused.
Yes, it will confuse them for once and they will probably learn of the
change, not sure how many of them would be there though who look at
these
On 10-11-20, 11:36, Lukasz Luba wrote:
> I am not sure if these ktime_get() are not too heavy in the code path
> visited by the scheduler.
Ahh Right. I missed that.
> How about local_clock()?
> It's used in ./drivers/cpuidle/cpuidle.c to do similar accounting.
Will have a look.
--
viresh
On 10-11-20, 13:53, Thomas Renninger wrote:
> Am Dienstag, 10. November 2020, 12:07:37 CET schrieb Viresh Kumar:
> > The cpufreq and thermal core, both provide sysfs statistics to help
> > userspace learn about the behavior of frequencies and cooling states.
> >
>
but it is independent of the unit of the time and didn't
require an update.
Signed-off-by: Viresh Kumar
---
Documentation/cpu-freq/cpufreq-stats.rst | 5 +--
drivers/cpufreq/cpufreq_stats.c | 47 +---
2 files changed, 28 insertions(+), 24 deletions(-)
diff --git
The sysfs stats for cooling devices shows the time_in_state in msec,
remove the unwanted usertime comment.
Signed-off-by: Viresh Kumar
---
Documentation/driver-api/thermal/sysfs-api.rst | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/Documentation/driver-api/thermal/sysfs
On 10-11-20, 07:57, Marek Szyprowski wrote:
> Hi Viresh,
>
> On 10.11.2020 07:00, Viresh Kumar wrote:
> > On 09-11-20, 13:42, Marek Szyprowski wrote:
> >> This patch landed in linux next-20201109 as commit e8f7703f8fe5
> >> ("cpufreq: dt: Don't (ab)use de
On 09-11-20, 13:42, Marek Szyprowski wrote:
> This patch landed in linux next-20201109 as commit e8f7703f8fe5
> ("cpufreq: dt: Don't (ab)use dev_pm_opp_get_opp_table() to create OPP
> table"). Sadly it causes regression on some Samsung Exynos based boards:
>
> 8<--- cut here ---
> Unable to
req_fast_s
>
> target_pstate = DIV_ROUND_UP(target_freq, cpu->pstate.scaling);
>
> - target_pstate = intel_cpufreq_update_pstate(cpu, target_pstate, true);
> + target_pstate = intel_cpufreq_update_pstate(policy, target_pstate,
> true);
>
> return target_pstate * cpu->pstate.scaling;
> }
Acked-by: Viresh Kumar
--
viresh
gov structure at all ? I mean there is only
one user of that field now, do we really need a flag for it ? We can just do the
string comparison here with powersave and performance to set strict_target.
Whatever you feel is better though.
Acked-by: Viresh Kumar
--
viresh
t; /* For governors which change frequency dynamically by themselves */
> #define CPUFREQ_GOV_FLAG_DYN_SWITCH BIT(0)
>
> +/* For governors wanting the target frequency to be set exactly */
> +#define CPUFREQ_GOV_FLAG_STRICT_TARGET BIT(1)
> +
>
> /* Pass a target to the cpufreq driver */
> unsigned int cpufreq_driver_fast_switch(struct cpufreq_policy *policy,
Acked-by: Viresh Kumar
--
viresh
gt; +#define CPUFREQ_GOV_FLAG_DYN_SWITCH BIT(0)
Maybe just drop the FLAG_ part as we don't use it for other cpufreq related
flags as well. That will also give us space to write DYN as DYNAMIC (it may be
better as we use the full name in CPUFREQ_NO_AUTO_DYNAMIC_SWITCHING).
Acked-by: Viresh Kumar
--
viresh
On 09-11-20, 15:18, Rafael J. Wysocki wrote:
> On Tue, Nov 3, 2020 at 4:14 PM Pali Rohár wrote:
> >
> > Some of cpufreq drivers are tristate, can be compiled as modules, but do
> > not have defined modalias for automatic loading. This patch series add
> > for all those cpufreq drivers missing
turn domains with a single CPU, this change
> does not affect the functionality, but clarifies the intention.
>
> Signed-off-by: Ionela Voinescu
> Cc: Rafael J. Wysocki
> Cc: Len Brown
> Cc: Viresh Kumar
> ---
> drivers/acpi/cppc_acpi.c | 2 +-
> drivers/acpi/pr
On 05-11-20, 12:55, Ionela Voinescu wrote:
> Use the existing sysfs attribute "freqdomain_cpus" to expose
> information to userspace about CPUs in the same frequency domain.
>
> Signed-off-by: Ionela Voinescu
> Cc: Rafael J. Wysocki
> Cc: Viresh Kumar
> ---
>
types (HW_ALL/HW, NONE) were silently supported.
>
> Clarify support for coordination types while describing in comments the
> intended behavior.
>
> Signed-off-by: Ionela Voinescu
> Cc: Rafael J. Wysocki
> Cc: Viresh Kumar
> ---
> drivers/cpufreq/cppc_cpufreq
prints in cppc_set_perf() would no longer create confusion
> when referring to a CPU that is hotplugged out.
>
> Signed-off-by: Ionela Voinescu
> Cc: Rafael J. Wysocki
> Cc: Viresh Kumar
> ---
> drivers/cpufreq/cppc_cpufreq.c | 5 +++--
> 1 file changed, 3 insertions(+),
lities often.
>
> Signed-off-by: Ionela Voinescu
> Cc: Rafael J. Wysocki
> Cc: Viresh Kumar
> ---
> drivers/cpufreq/cppc_cpufreq.c | 40 +++---
> 1 file changed, 23 insertions(+), 17 deletions(-)
Acked-by: Viresh Kumar
--
viresh
m" and "cpunum" with "cpu"
> - make cpu variables unsigned int
>
> Where pertinent, also move the initialisation of cpu_data variable to
> its declaration and make consistent use of the local "cpu" variable.
>
> Signed-off-by: Ionela Voinesc
from long pointers to structures to
>short ret and i (index) variables, to improve readability
>
> Signed-off-by: Ionela Voinescu
> Cc: Rafael J. Wysocki
> Cc: Viresh Kumar
> ---
> drivers/cpufreq/cppc_cpufreq.c | 32
> 1 file changed
On 06-11-20, 11:14, Lukasz Luba wrote:
> I also had similar doubts, because if we make frequency requests
> independently for each CPU, why not having N cooling devs, which
> will set independently QoS max freq for them...
>
> What convinced me:
> EAS and FIE would know the 'real' frequency of
On 09-11-20, 08:44, Dmitry Osipenko wrote:
> 09.11.2020 08:35, Viresh Kumar пишет:
> > On 09-11-20, 08:19, Dmitry Osipenko wrote:
> >> Thanks, I made it in a different way by simply adding helpers to the
> >> pm_opp.h which use devm_add_action_or_reset(). This does
On 09-11-20, 08:19, Dmitry Osipenko wrote:
> Thanks, I made it in a different way by simply adding helpers to the
> pm_opp.h which use devm_add_action_or_reset(). This doesn't require to
> add new kernel symbols.
I will prefer to add it in core.c itself, and yes
devm_add_action_or_reset() looks
On 09-11-20, 08:10, Dmitry Osipenko wrote:
> 09.11.2020 07:47, Dmitry Osipenko пишет:
> > 09.11.2020 07:43, Viresh Kumar пишет:
> >> On 08-11-20, 15:19, Dmitry Osipenko wrote:
> >>> I took a detailed look at the GENPD and tried to implement it. Here is
> >>
On 09-11-20, 08:08, Dmitry Osipenko wrote:
> 09.11.2020 08:00, Viresh Kumar пишет:
> > On 06-11-20, 21:41, Frank Lee wrote:
> >> On Fri, Nov 6, 2020 at 9:18 PM Dmitry Osipenko wrote:
> >>>
> >>> 06.11.2020 09:15, Viresh Kumar пишет:
> >>>
On 06-11-20, 21:41, Frank Lee wrote:
> On Fri, Nov 6, 2020 at 9:18 PM Dmitry Osipenko wrote:
> >
> > 06.11.2020 09:15, Viresh Kumar пишет:
> > > Setting regulators for count as 0 doesn't sound good to me.
> > >
> > > But, I understand that you
501 - 600 of 16408 matches
Mail list logo
