Stephan and Dmitry,
Here is an attempt to solve the problem you guys faced, I have tested it
locally and works with my expectations. Please see if they solve your
problems.
Dmitry: I sent another message for you in patch 3's comments section.
--
viresh
Viresh Kumar (3):
dt-bindings: opp
one is just a flag. But yeah,
that is out of this series's scope, but maybe you should name
topology_scale_freq_invariant() to topology_is_freq_invariant() or something
else on those lines ? Anyway:
Acked-by: Viresh Kumar
--
viresh
nline_mask without getting a warning.
>
> Signed-off-by: Valentin Schneider
> Signed-off-by: Ionela Voinescu
> Acked-by: Catalin Marinas
> Cc: Catalin Marinas
> Cc: Will Deacon
> Cc: Sudeep Holla
> Cc: Rafael J. Wysocki
> Cc: Viresh Kumar
> ---
> a
he scheduler.
>
> Signed-off-by: Ionela Voinescu
> Cc: Rafael J. Wysocki
> Cc: Viresh Kumar
> ---
> drivers/cpufreq/cpufreq.c | 20
> include/linux/cpufreq.h | 5 +
> 2 files changed, 25 insertions(+)
>
> diff --git a/drivers/cpufreq/cp
etter position to decide if it has better methods to obtain
> more accurate information regarding the current frequency and use that
> information instead (for example, the use of counters).
>
> Also, the implementation to arch_set_freq_scale() will now have to handle
> e
On 24-08-20, 22:02, Ionela Voinescu wrote:
> The current frequency passed to arch_set_freq_scale() could end up
> being 0, signaling an error in setting a new frequency. Also, if the
> maximum frequency in 0, this will result in a division by 0 error.
>
> Therefore, validate these input values
On 24-08-20, 15:59, Jon Hunter wrote:
> Commit 6cc3d0e9a097 ("cpufreq: tegra186: add
> CPUFREQ_NEED_INITIAL_FREQ_CHECK flag") fixed CPUFREQ support for
> Tegra186 but as a consequence the following warnings are now seen on
> boot ...
>
> cpufreq: cpufreq_online: CPU0: Running at unlisted freq: 0
On 24-08-20, 17:08, Stephan Gerhold wrote:
> On Mon, Aug 24, 2020 at 04:36:57PM +0200, Ulf Hansson wrote:
> > That said, perhaps should rely on the consumer to deploy runtime PM
> > support, but let the OPP core to set up the device links for the genpd
> > virtual devices!?
> >
>
> Yes, that
On 24-08-20, 18:10, Greg KH wrote:
> On Mon, Aug 24, 2020 at 02:52:23PM +0530, Viresh Kumar wrote:
> > From: Rajendra Nayak
> >
> > commit a4501bac0e553bed117b7e1b166d49731caf7260 upstream.
> >
> > dev_pm_opp_set_rate() can now be called with freq = 0 in ord
On 24-08-20, 18:10, Greg KH wrote:
> On Mon, Aug 24, 2020 at 03:00:03PM +0530, Viresh Kumar wrote:
> > From: Stephen Boyd
> >
> > commit 8979ef70850eb469e1094279259d1ef393ffe85f upstream.
> >
> > We get the opp_table pointer at the top of the function and
On 24-08-20, 13:30, Stephan Gerhold wrote:
> You're right. Not sure why I removed it.
>
> I suspect I had it in _set_required_opp() at some point, but I moved
> code around several times until I was happy with the result.
>
> We should just add it back.
> Should I send a v2 with it fixed or
On 21-08-20, 18:31, Stephan Gerhold wrote:
> This patch does not apply anymore after the cleanup you pushed to
> opp/linux-next. I would be happy to send a v2 with that fixed.
>
> On my other OPP patch set you mentioned that you might apply these
> directly with some of your own changes - would
On 30-07-20, 10:01, Stephan Gerhold wrote:
> dev_pm_opp_attach_genpd() allows attaching an arbitrary number of
> power domains to an OPP table. In that case, the genpd core will
> create a virtual device for each of the power domains.
>
> At the moment, the OPP core only calls
>
On 30-07-20, 10:01, Stephan Gerhold wrote:
> Move call to dev_pm_genpd_set_performance_state() to a separate
> function so we can avoid duplicating the code for the single and
> multiple genpd case.
>
> Signed-off-by: Stephan Gerhold
> ---
> drivers/opp/core.c | 40
On 24-07-20, 11:38, Vincent Guittot wrote:
> Yeah it's exactly the same behavior as x86 and re using the same
> mechanism seems the best solution
>
> The main problem is that AMU currently assumes that it will be the
> only to support such tick based mechanism whereas others like cppc can
>
+Vincent/Saravana/Sibi
On 21-08-20, 16:00, Ansuel Smith wrote:
> This adds Krait Cache scaling support using the cpufreq notifier.
> I have some doubt about where this should be actually placed (clk or cpufreq)?
> Also the original idea was to create a dedicated cpufreq driver (like it's
> done
On 13-08-20, 15:07, Hector Yuan wrote:
> From: "Hector.Yuan"
>
> Add MT6779 cpufreq HW support.
>
> Signed-off-by: Hector.Yuan
> ---
> arch/arm64/configs/defconfig |1 +
> drivers/cpufreq/Kconfig.arm | 11 ++
> drivers/cpufreq/Makefile |1 +
>
anage empty OPP tables with clk handle")
Reviewed-by: Rajendra Nayak
Signed-off-by: Stephen Boyd
[ Viresh: Split the patch into two ]
Signed-off-by: Viresh Kumar
[ Viresh: Update the code for v5.7-stable ]
Signed-off-by: Viresh Kumar
---
drivers/opp/core.c | 2 +-
1 file changed, 1 inser
q = 0 to drop
performance votes")
Reported-by: Sajida Bhanu
Reviewed-by: Sibi Sankar
Reported-by: Matthias Kaehlcke
Tested-by: Matthias Kaehlcke
Reviewed-by: Stephen Boyd
Signed-off-by: Rajendra Nayak
[ Viresh: Don't skip clk_set_rate() and massaged changelog ]
Signed-off-by: Viresh Kumar
On 12-08-20, 11:10, Ulf Hansson wrote:
> On Mon, 27 Jul 2020 at 11:31, Stephan Gerhold wrote:
> > I wasn't sure if the changes in drivers/base/power/domain.c
> > should be made in a separate commit, but they need to be made together
> > with the other changes.
>
> I would suggest to move the
pm_opp_get_opp_table() for
EPROBE_DEFER in domain.c, fix NULL return value and reorder
code a bit in core.c, and update exynos-asv.c ]
Signed-off-by: Viresh Kumar
---
Stephan, I have made some changes to the code. Please try it again and
lemme know if it works fine.
drivers/base/powe
end up saving a few lines of code,
the resources are no longer looked up multiple times and everything
should be much more robust.
Signed-off-by: Stephan Gerhold
[ Viresh: Use list_head structure for maintaining the list and minor
changes ]
Signed-off-by: Viresh Kumar
---
drivers/cpuf
On 20-08-20, 13:37, Sudeep Holla wrote:
> On Thu, Aug 20, 2020 at 11:09:45AM +0530, Viresh Kumar wrote:
> > On 12-08-20, 01:13, Sumit Gupta wrote:
> > > Commit eaecca9e7710 ("arm64: Fix __cpu_logical_map undefined issue")
> > > fixes the issue with build
gt; Suggested-by: Amit Kucheria
> Signed-off-by: Yue Hu
> ---
> drivers/thermal/thermal_sysfs.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
Acked-by: Viresh Kumar
--
viresh
dev_pm_opp_of_remove_table() doesn't report any errors when it fails to
find the OPP table with error -ENODEV (i.e. OPP table not present for
the device). And we can call dev_pm_opp_of_remove_table()
unconditionally here.
Signed-off-by: Viresh Kumar
---
drivers/mmc/host/sdhci-msm.c | 11
dev_pm_opp_of_remove_table() doesn't report any errors when it fails to
find the OPP table with error -ENODEV (i.e. OPP table not present for
the device). And we can call dev_pm_opp_of_remove_table()
unconditionally here.
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/imx6q-cpufreq.c | 10
dev_pm_opp_of_remove_table() doesn't report any errors when it fails to
find the OPP table with error -ENODEV (i.e. OPP table not present for
the device). And we can call dev_pm_opp_of_remove_table()
unconditionally here.
Signed-off-by: Viresh Kumar
---
drivers/spi/spi-geni-qcom.c | 10
of these changes are related to qcom stuff, it
would be great if you can give them a try. I wasn't able to test them
due to lack of hardware.
Viresh Kumar (8):
cpufreq: imx6q: Unconditionally call dev_pm_opp_of_remove_table()
drm/lima: Unconditionally call dev_pm_opp_of_remove_table()
drm/msm
On 22-07-20, 10:54, Viresh Kumar wrote:
> On 21-07-20, 01:43, Stephen Boyd wrote:
> > It seems that dev_pm_opp_set_rate() calls _find_opp_table() and finds
> > something that isn't an error pointer but then dev_pm_opp_of_add_table()
> > returns an error value because the
dev_pm_opp_of_remove_table() doesn't report any errors when it fails to
find the OPP table with error -ENODEV (i.e. OPP table not present for
the device). And we can call dev_pm_opp_of_remove_table()
unconditionally here.
Signed-off-by: Viresh Kumar
---
drivers/spi/spi-qcom-qspi.c | 11
has_opp_table isn't used anymore, remove it.
Signed-off-by: Viresh Kumar
---
include/linux/qcom-geni-se.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/include/linux/qcom-geni-se.h b/include/linux/qcom-geni-se.h
index 8f385fbe5a0e..02d1417c8ecf 100644
--- a/include/linux/qcom-geni-se.h
dev_pm_opp_of_remove_table() doesn't report any errors when it fails to
find the OPP table with error -ENODEV (i.e. OPP table not present for
the device). And we can call dev_pm_opp_of_remove_table()
unconditionally here.
Signed-off-by: Viresh Kumar
---
drivers/gpu/drm/lima/lima_devfreq.c | 6
dev_pm_opp_of_remove_table() doesn't report any errors when it fails to
find the OPP table with error -ENODEV (i.e. OPP table not present for
the device). And we can call dev_pm_opp_of_remove_table()
unconditionally here.
Signed-off-by: Viresh Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
dev_pm_opp_of_remove_table() doesn't report any errors when it fails to
find the OPP table with error -ENODEV (i.e. OPP table not present for
the device). And we can call dev_pm_opp_of_remove_table()
unconditionally here.
Signed-off-by: Viresh Kumar
---
drivers/tty/serial/qcom_geni_serial.c
Expand the scope of the regulator_enabled flag and use it to track
status of all the resources. This will be used for other stuff in the
next patch.
Signed-off-by: Viresh Kumar
---
drivers/opp/core.c | 19 +--
drivers/opp/opp.h | 4 ++--
2 files changed, 11 insertions(+), 12
The OPP core needs to track if the resources of devices are
enabled/configured or not, as it disables the resources when target_freq
is set to 0.
Handle that with the new enabled flag and remove otherwise complex
conditional statements.
Signed-off-by: Viresh Kumar
---
drivers/opp/core.c | 29
Remove the unnecessary wrapper and merge
_dev_pm_opp_find_and_remove_table() with dev_pm_opp_remove_table().
Signed-off-by: Viresh Kumar
---
drivers/opp/core.c | 21 -
drivers/opp/cpu.c | 2 +-
drivers/opp/of.c | 2 +-
drivers/opp/opp.h | 1 -
4 files changed, 10
Hi,
Here is another version of the cleanups I sent earlier.
Rajendra: Please see if these work fine now.
V3:
- Dropped v2 1/4 as it is already merged.
- New patch 4/4 added.
- Reordered the first two patches here (Stephen)
- disable regulator only if present
Viresh Kumar (4):
opp: Rename
Create separate routine _opp_set_rate_zero() to handle !target_freq
case.
Signed-off-by: Viresh Kumar
---
drivers/opp/core.c | 52 ++
1 file changed, 29 insertions(+), 23 deletions(-)
diff --git a/drivers/opp/core.c b/drivers/opp/core.c
index
On 15-08-20, 00:55, Stephen Boyd wrote:
> Quoting Viresh Kumar (2020-08-12 21:29:00)
> > diff --git a/drivers/opp/core.c b/drivers/opp/core.c
> > index e8882e7fd8a5..5f5da257f58a 100644
> > --- a/drivers/opp/core.c
> > +++ b/drivers/opp/core.c
> >
On 12-08-20, 01:13, Sumit Gupta wrote:
> Commit eaecca9e7710 ("arm64: Fix __cpu_logical_map undefined issue")
> fixes the issue with building tegra194 cpufreq driver as module. But
> the fix might cause problem while supporting physical cpu hotplug[1].
>
> This patch fixes the original problem by
On 20-08-20, 08:01, Stephen Rothwell wrote:
> Hi all,
>
> In commit
>
> ceac7fc18ac7 ("opp: Enable resources again if they were disabled earlier")
>
> Fixes tag
>
> Fixes: cd7ea582 ("opp: Make dev_pm_opp_set_rate() handle freq = 0 to drop
> performance votes")
>
> has these problem(s):
>
3,7 @@
> 0 7 0x04>;
> };
>
> - L2: l2-cache {
> + L2: cache-controller {
> compatible = "arm,pl310-cache";
> reg = <0xed00 0x1000>;
> cache-unified;
Acked-by: Viresh Kumar
--
viresh
On 13-08-20, 11:34, Wang Qing wrote:
> Use kobj_to_dev() instead of container_of()
>
> Signed-off-by: Wang Qing
> ---
> drivers/greybus/interface.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
Acked-by: Viresh Kumar
--
viresh
On 15-08-20, 01:03, Stephen Boyd wrote:
> Quoting Viresh Kumar (2020-08-12 21:28:59)
> > The OPP core needs to track if the resources of devices are enabled or
> > configured or not, as it disables the resources when target_freq is set
> > to 0.
> >
> > Han
On 11-08-20, 14:09, Stephen Boyd wrote:
> This is a goto maze! Any chance we can clean this up?
I have sent a short series in reply to this series, please have a
look. It should look better now.
--
viresh
Reviewed-by: Sibi Sankar
Reported-by: Matthias Kaehlcke
Tested-by: Matthias Kaehlcke
Signed-off-by: Rajendra Nayak
[ Viresh: Don't skip clk_set_rate() and massaged changelog ]
Signed-off-by: Viresh Kumar
---
Hi Rajendra,
I wasn't able to test this stuff, please give it a try. I have
simpl
the resources are getting enabled again. This shouldn't have any
side effects anyway.
Signed-off-by: Viresh Kumar
---
drivers/opp/core.c | 37 ++---
drivers/opp/opp.h | 2 ++
2 files changed, 20 insertions(+), 19 deletions(-)
diff --git a/drivers/opp/core.c b
The common "enabled" flag can be used here instead of
"regulator_enabled" now.
Signed-off-by: Viresh Kumar
---
drivers/opp/core.c | 13 +++--
drivers/opp/opp.h | 2 --
2 files changed, 3 insertions(+), 12 deletions(-)
diff --git a/drivers/opp/core.c b/driv
Create separate routine _opp_set_rate_zero() to handle !target_freq
case.
Signed-off-by: Viresh Kumar
---
drivers/opp/core.c | 52 +---
1 file changed, 29 insertions(+), 23 deletions(-)
diff --git a/drivers/opp/core.c b/drivers/opp/core.c
index
On 12-08-20, 12:53, Stephan Gerhold wrote:
> On Wed, Aug 12, 2020 at 11:10:38AM +0200, Ulf Hansson wrote:
> > > I wasn't sure if the changes in drivers/base/power/domain.c
> > > should be made in a separate commit, but they need to be made together
> > > with the other changes.
> >
> > I would
On 11-08-20, 14:28, Stephen Boyd wrote:
> @@ -905,7 +907,7 @@ int dev_pm_opp_set_rate(struct device *dev, unsigned long
> target_freq)
>
> ret = _set_opp_bw(opp_table, NULL, dev, true);
> if (ret)
> - return ret;
> + goto
ut it lets us kill off the header file
> usage.
>
> Signed-off-by: Arnd Bergmann
> [krzk: Rebase and fix -Wold-style-definition]
> Signed-off-by: Krzysztof Kozlowski
Acked-by: Viresh Kumar
--
viresh
ers/cpufreq/s3c2412-cpufreq.c| 23
> include/linux/soc/samsung/s3c-cpufreq-core.h | 1 +
> 2 files changed, 1 insertion(+), 23 deletions(-)
Acked-by: Viresh Kumar
--
viresh
+-
> include/linux/soc/samsung/s3c-pm.h | 10 ++
> 24 files changed, 41 insertions(+), 42 deletions(-)
> rename arch/arm/plat-samsung/include/plat/cpu-freq.h =>
> include/linux/soc/samsung/s3c-cpu-freq.h (97%)
> rename arch/arm/plat-samsung/include/plat/cpu-freq-core.h =>
> include/linux/soc/samsung/s3c-cpufreq-core.h (98%)
Acked-by: Viresh Kumar
--
viresh
ix build by copying also S3C2410_LOCKTIME]
> Signed-off-by: Krzysztof Kozlowski
>
> ---
Acked-by: Viresh Kumar
--
viresh
On 05-08-20, 12:04, Lukasz Luba wrote:
> I know that Viresh is going to develop patches and improve these
> cpufreq stats framework. Maybe he also had this 'aggregation' in mind.
> I will leave it him.
I am only going to look at cpufreq's view of stats independently from
the firmware.
--
viresh
On 04-08-20, 11:29, Lukasz Luba wrote:
> On 8/4/20 6:35 AM, Viresh Kumar wrote:
> > IIUC, the only concern right now is to capture stats with fast switch ?
> > Maybe we
> > can do something else in that case and brainstorm a bit..
>
> Correct, the fast switch is
On 03-08-20, 16:24, Ionela Voinescu wrote:
> Right, cpufreq_register_driver() should check that at least one of them
> is present
> (although currently cpufreq_register_driver() will return
> -EINVAL if .fast_switch() alone is present - something to be fixed).
I think it is fine as there is no
On 30-07-20, 12:29, Dietmar Eggemann wrote:
> On 30/07/2020 06:24, Viresh Kumar wrote:
> > On 22-07-20, 10:37, Ionela Voinescu wrote:
> >> +++ b/drivers/base/arch_topology.c
> >> @@ -27,6 +27,7 @@ __weak bool arch_freq_counters_available(struct cpumask
> >>
On 03-08-20, 14:58, Ionela Voinescu wrote:
> Hi Viresh,
>
> On Thursday 30 Jul 2020 at 09:43:34 (+0530), Viresh Kumar wrote:
> > On 22-07-20, 10:37, Ionela Voinescu wrote:
> > > While the move of the invariance setter calls (arch_set_freq_scale())
> > > fro
On 03-08-20, 22:31, Dongdong Yang wrote:
> From: Dongdong Yang
>
> This patch provides USF(User Sensitive Feedback factor) auxiliary
> cpufreq governor to support high level layer sysfs inodes setting
> for utils adjustment purpose from the identified scenario on portable
> equipment. Because
On 30-07-20, 10:36, Lukasz Luba wrote:
> On 7/30/20 10:10 AM, Sudeep Holla wrote:
> > On Thu, Jul 30, 2020 at 02:23:33PM +0530, Viresh Kumar wrote:
> > > On 29-07-20, 16:12, Lukasz Luba wrote:
> > > > The existing CPUFreq framework does not tracks the statistics
On 31-07-20, 13:14, Jon Hunter wrote:
> I have been doing some more testing on Tegra, I noticed that when
> reading the current CPU frequency via the sysfs scaling_cur_freq entry,
> this always returns the cached value (at least for Tegra). Looking at
> the implementation of scaling_cur_freq I see
On 04-08-20, 10:37, Xin Hao wrote:
> Hi everyone:
>
> I want to know why my patch didn't merge into upstream ?
I have sent a pull request earlier today to Rafael and this will get
merged in the next pull request Rafael will send to Linus.
--
viresh
On 30-07-20, 08:27, Rob Clark wrote:
> Hmm, I've already sent my pull request to Dave, dropping the patch
> would require force-push and sending a new PR. Which I can do if Dave
> prefers. OTOH I guess it isn't the end of the world if the patch is
> merged via two different trees.
I don't think
On 29-07-20, 16:12, Lukasz Luba wrote:
> The existing CPUFreq framework does not tracks the statistics when the
> 'fast switch' is used or when firmware changes the frequency independently
> due to e.g. thermal reasons. However, the firmware might track the frequency
> changes and expose this to
On 30-07-20, 12:02, Amit Kucheria wrote:
> Looking at this more closely, I found another call site for
> cpufreq_frequency_table_target() in cpufreq.c that needs the index to
> be unsigned int.
>
> But then cpufreq_frequency_table_target() returns -EINVAL, so we
It returns -EINVAL only in the
On 17-07-20, 11:46, Vincent Guittot wrote:
> On Thu, 16 Jul 2020 at 16:24, Lukasz Luba wrote:
> > On 7/16/20 12:56 PM, Peter Zijlstra wrote:
> > > Currently cpufreq_cooling appears to estimate the CPU energy usage by
> > > calculating the percentage of idle time using the per-cpu cpustat stuff,
>
On 30-07-20, 11:29, Amit Kucheria wrote:
> On Thu, Jul 30, 2020 at 9:38 AM Viresh Kumar wrote:
> >
> > It is not possible for cached_resolved_idx to be invalid here as the
> > cpufreq core always sets index to a positive value.
> >
> > Change its type to unsi
On 22-07-20, 11:00, Viresh Kumar wrote:
> On 21-07-20, 07:28, Rob Clark wrote:
> > With your ack, I can add the patch the dev_pm_opp_set_bw patch to my
> > tree and merge it via msm-next -> drm-next -> linus
>
> I wanted to send it via my tree, but its okay. Pick t
e default for arm && arm64 for now.
>
> Signed-off-by: Valentin Schneider
> Signed-off-by: Ionela Voinescu
> Cc: Catalin Marinas
> Cc: Will Deacon
> Cc: Russell King
> Cc: Rafael J. Wysocki
> Cc: Viresh Kumar
> ---
> drivers/cpufreq/Kconfig | 2 +-
> 1 file
On 22-07-20, 10:37, Ionela Voinescu wrote:
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index 3497c1cd6818..1d0b046fe8e9 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -61,6 +61,9 @@ static struct cpufreq_driver *cpufreq_driver;
> static
On 22-07-20, 10:37, Ionela Voinescu wrote:
> +++ b/drivers/base/arch_topology.c
> @@ -27,6 +27,7 @@ __weak bool arch_freq_counters_available(struct cpumask
> *cpus)
> }
> DEFINE_PER_CPU(unsigned long, freq_scale) = SCHED_CAPACITY_SCALE;
>
> +#ifndef CONFIG_BL_SWITCHER
> void
On 22-07-20, 10:37, Ionela Voinescu wrote:
> While the move of the invariance setter calls (arch_set_freq_scale())
> from cpufreq drivers to cpufreq core maintained the previous
> functionality for existing drivers that use target_index() and
> fast_switch() for frequency switching, it also gives
It is not possible for cached_resolved_idx to be invalid here as the
cpufreq core always sets index to a positive value.
Change its type to unsigned int and fix qcom usage a bit.
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/qcom-cpufreq-hw.c | 5 +
include/linux/cpufreq.h | 2
On 27-07-20, 15:48, Rafael J. Wysocki wrote:
> On Wed, Jul 22, 2020 at 11:38 AM Ionela Voinescu
> wrote:
> > diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> > index 036f4cc42ede..bac4101546db 100644
> > --- a/drivers/cpufreq/cpufreq.c
> > +++ b/drivers/cpufreq/cpufreq.c
> >
On 28-07-20, 17:37, Alex Elder wrote:
> On 7/27/20 1:32 PM, Gustavo A. R. Silva wrote:
> > Replace the existing /* fall through */ comments and its variants with
> > the new pseudo-keyword macro fallthrough[1].
> >
> > [1]
> >
On 28-07-20, 09:59, Linus Walleij wrote:
> On Mon, Jul 27, 2020 at 12:44 PM Arnd Bergmann wrote:
> > On Mon, Jul 27, 2020 at 10:18 AM Anson Huang wrote:
> > drivers/pinctrl/spear/pinctrl-plgpio.c:static
> > SIMPLE_DEV_PM_OPS(plgpio_dev_pm_ops, plgpio_suspend, plgpio_resume);
>
> This one is
On 27-07-20, 17:38, Rajendra Nayak wrote:
>
> On 7/27/2020 11:23 AM, Rajendra Nayak wrote:
> >
> >
> > On 7/24/2020 7:39 PM, Stanimir Varbanov wrote:
> > > Hi,
> > >
> > > On 7/23/20 9:06 PM, Stanimir Varbanov wrote:
> > > > Hi Rajendra,
> > > >
> > > > After applying 2,3 and 4/5 patches on
On 17-07-20, 11:43, Quentin Perret wrote:
> On Friday 17 Jul 2020 at 11:33:05 (+0100), Quentin Perret wrote:
> > On Friday 17 Jul 2020 at 11:14:38 (+0100), Quentin Perret wrote:
> > > On Tuesday 14 Jul 2020 at 12:06:53 (+0530), Viresh Kumar wrote:
> > > > /**
>
On 22-07-20, 09:43, Pavel Machek wrote:
> OTOH the changelog is extremely confusing, because code would not work
> on the table presented there as an example.
Yeah, maybe I should have updated it too, just missed it completely :(
--
viresh
On 21-07-20, 13:43, Pavel Machek wrote:
> On Mon 2020-07-20 17:37:50, Greg Kroah-Hartman wrote:
> > From: Finley Xiao
> >
> > commit 371a3bc79c11b707d7a1b7a2c938dc3cc042fffb upstream.
> >
> > The function cpu_power_to_freq is used to find a frequency and set the
> > cooling device to consume at
On 21-07-20, 07:28, Rob Clark wrote:
> With your ack, I can add the patch the dev_pm_opp_set_bw patch to my
> tree and merge it via msm-next -> drm-next -> linus
I wanted to send it via my tree, but its okay. Pick this patch from
linux-next and add my Ack, I will drop it after that.
a8351c12c6c7
On 21-07-20, 01:43, Stephen Boyd wrote:
> It seems that dev_pm_opp_set_rate() calls _find_opp_table() and finds
> something that isn't an error pointer but then dev_pm_opp_of_add_table()
> returns an error value because there isn't an operating-points property
> in DT. We're getting saved because
On 21-07-20, 01:15, Stephen Boyd wrote:
> Quoting Andrew-sh.Cheng (2020-07-20 01:55:26)
> > From: "Andrew-sh.Cheng"
> >
> > Modify dev_pm_opp_get_freq() to return freqeuncy
> > even this opp item is not available.
> > So that we can get the information of disable opp items.
> >
> >
On 20-07-20, 08:03, Rob Clark wrote:
> On Mon, Jul 20, 2020 at 3:01 AM Viresh Kumar wrote:
> >
> > On 15-07-20, 08:36, Rob Clark wrote:
> > > I can take the first two into msm-next, the 3rd will need to wait
> > > until dev_pm_opp_set_bw() lands
> >
> &g
indings/arm/freescale/fsl,scu.txt
>
>
> .../bindings/cpufreq/cpufreq-dt.txt | 3 +-
> .../bindings/cpufreq/cpufreq-mediatek.txt | 4 +-
> .../cpufreq/nvidia,tegra20-cpufreq.txt| 2 +-
Acked-by: Viresh Kumar
--
viresh
On 15-07-20, 08:36, Rob Clark wrote:
> I can take the first two into msm-next, the 3rd will need to wait
> until dev_pm_opp_set_bw() lands
You can base that on a8351c12c6c7 in linux-next, I will make sure not to rebase
it anymore.
--
viresh
On 20-07-20, 16:55, Andrew-sh.Cheng wrote:
> From: "Andrew-sh.Cheng"
>
> Modify dev_pm_opp_get_freq() to return freqeuncy
> even this opp item is not available.
> So that we can get the information of disable opp items.
>
> Signed-off-by: Andrew-sh.Cheng
> ---
> drivers/opp/core.c | 2 +-
> 1
On 16-07-20, 14:37, Thierry Reding wrote:
> On Wed, Jul 15, 2020 at 07:01:24PM +0530, Sumit Gupta wrote:
> > On Tegra194, data on valid operating points for the CPUs needs to be
> > queried from BPMP. In T194, there is no node representing CPU complex.
> > So, add compatible string to the 'cpus'
On 15-07-20, 20:57, Sumit Gupta wrote:
> Sorry, missed to remove this. Will wait if any other comments before
> re-spin.
I don't have any further comments, maybe just send a new version of
this patch alone and name it v6.1.
--
viresh
On 15-07-20, 23:54, Walter Lozano wrote:
> Currently, when using _of_add_opp_table_v2 parsed_static_opps is
> increased and this value is used on _opp_remove_all_static to
> check if there are static opps entries that need to be freed.
> Unfortunately this does not happens when using
On 13-07-20, 19:36, Sumit Gupta wrote:
> Add support for CPU frequency scaling on Tegra194. The frequency
> of each core can be adjusted by writing a clock divisor value to
> a MSR on the core. The range of valid divisors is queried from
> the BPMP.
>
> Signed-off-by: Mikko Perttunen
>
W=0 nor W=1 level warnings in drivers/cpufreq.
>
> Hurrah!
>
> Changelog
>
> v1 => v2:
> - Collect *-bys
> - Use __maybe_unused instead of removing device IDs
> - Use __always_unused instead of using unused variables
> - Include architecture header instead o
On 15-07-20, 09:26, Lee Jones wrote:
> Kerneldoc format for attribute descriptions should be '@.*: '.
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/cpufreq/sti-cpufreq.c:49: warning: cannot understand function
> prototype: 'struct sti_cpufreq_ddata '
>
> Cc: Patrice Chotard
vious prototype for
> ‘powernv_cpufreq_work_fn’ [-Wmissing-prototypes]
>
> Cc: Michael Ellerman
> Cc: Benjamin Herrenschmidt
> Cc: Paul Mackerras
> Cc: linuxppc-...@lists.ozlabs.org
> Signed-off-by: Lee Jones
> Acked-by: Viresh Kumar
> ---
> drivers/cpufreq/po
On 15-07-20, 08:31, Lee Jones wrote:
> I'm not sure what you mean. Kerneldoc headers are designed to be
> extracted and converted into mediums which are easy to read/browse.
> For example, see the online documentation for 'debug_object_init':
>
>
>
On 14-07-20, 15:05, Rafael J. Wysocki wrote:
> On Tue, Jul 14, 2020 at 8:37 AM Viresh Kumar wrote:
> > static u32 get_load(struct cpufreq_cooling_device *cpufreq_cdev, int cpu,
> > int cpu_idx)
> > {
> > - u32 load;
> > - u64 now,
On 15-07-20, 07:47, Lee Jones wrote:
> On Wed, 15 Jul 2020, Viresh Kumar wrote:
>
> > On 14-07-20, 15:50, Lee Jones wrote:
> > > -/**
> > > +/*
> > > * cpufreq_remove_dev - remove a CPU device
> >
> > Because cpuf
901 - 1000 of 16408 matches
Mail list logo
