Frank/Rob.
On 08-01-21, 14:11, Viresh Kumar wrote:
> diff --git a/drivers/of/unittest-data/Makefile
> b/drivers/of/unittest-data/Makefile
> index 009f4045c8e4..f17bce85f65f 100644
> --- a/drivers/of/unittest-data/Makefile
> +++ b/drivers/of/unittest-data/Makefile
&g
On 12-01-21, 12:34, Frank Rowand wrote:
> On 1/11/21 11:08 PM, Viresh Kumar wrote:
> > On 11-01-21, 18:44, Frank Rowand wrote:
> >> On 1/7/21 12:25 AM, Viresh Kumar wrote:
> >>> We will start building overlays for platforms soon in the kernel and
> >>>
On 11-01-21, 15:45, 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 11-01-21, 15:45, Nicola Mazzucato wrote:
> diff --git a/drivers/cpufreq/scmi-cpufreq.c b/drivers/cpufreq/scmi-cpufreq.c
> +static int scmi_init_cpudata(void)
> +{
> + int cpu;
> + unsigned int ncpus = num_possible_cpus();
> +
> + cpudata_table = kzalloc(sizeof(*cpudata_table) *
On 12-01-21, 02:02, Masahiro Yamada wrote:
> On Tue, Jan 12, 2021 at 1:13 AM Rob Herring wrote:
> > On Mon, Jan 11, 2021 at 9:40 AM Masahiro Yamada
> > wrote:
> We do not need the dtbo-y syntax.
+1
And we are left with much simpler diff with what we agreed on. Does
this look okay now ?
---
On 11-01-21, 20:22, Bill Mills wrote:
> On 1/11/21 5:06 PM, Frank Rowand wrote:
> > NACK to this specific patch, in its current form.
> >
> > There are restrictions on applying an overlay at runtime that do not apply
> > to applying an overlay to an FDT that will be loaded by the kernel during
>
the overlaid blobs based on platform specific
configurations.
Signed-off-by: Viresh Kumar
---
scripts/dtc/Makefile | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/scripts/dtc/Makefile b/scripts/dtc/Makefile
index 4852bf44e913..5f19386a49eb 100644
--- a/scripts/dtc/Makefile
+++ b
This was copied from external DTC repository long back and isn't used
anymore. Over that the dtc tool can be used to generate the dts source
back from the dtb. Remove the unused fdtdump.c file.
Signed-off-by: Viresh Kumar
---
scripts/dtc/fdtdump.c | 163
We will start building overlays for platforms soon in the kernel and
would need fdtoverlay tool going forward. Lets start fetching it.
Signed-off-by: Viresh Kumar
---
scripts/dtc/update-dtc-source.sh | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/scripts/dtc/update
We will start building overlays for platforms soon in the kernel and
would need fdtoverlay tool going forward. Lets start fetching and
building it.
While at it, also remove fdtdump.c file, which isn't used by the kernel.
V4:
- Don't fetch and build fdtdump.c
- Remove fdtdump.c
Viresh Kumar (3
On 11-01-21, 18:44, Frank Rowand wrote:
> On 1/7/21 12:25 AM, Viresh Kumar wrote:
> > We will start building overlays for platforms soon in the kernel and
> > would need these tools going forward. Lets start building them.
> >
> > The fdtoverlay program applies (or m
On 11-01-21, 18:55, Frank Rowand wrote:
> Hi Viresh,
>
> I may have an email hiccup,
No you don't, I just sent the 2nd patch alone.
> but I don't see a "[PATCH V3 1/2]" email, I
> only see this "V3 2/2" email.
>
> Please start each new version of a patch series as a stand alone email
> instead
On 11-01-21, 16:13, Frank Rowand wrote:
> Hi Viresh,
>
> On 1/6/21 11:15 PM, Viresh Kumar wrote:
> > We will start building overlays for platforms soon in the kernel and
> > would need these tools going forward. Lets start fetching them.
> >
> > Note that a cop
On 11-01-21, 11:28, Linus Torvalds wrote:
> On Sun, Jan 10, 2021 at 10:02 PM 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
On 07-01-21, 14:28, Masahiro Yamada wrote:
> Viresh's patch is not enough.
>
> We will need to change .gitignore
> and scripts/Makefile.dtbinst as well.
>
> In my understanding, the build rule is completely the same
> between .dtb and .dtbo
> As Rob mentioned, I am not sure if we really
On 08-01-21, 23:55, Arnd Bergmann wrote:
> * spear -- added in 2010, no notable changes since 2015
I started an email chain with the ST folks to see if there are any
concerns with this getting removed and it was confirmed by Mattias
(Cc'd) from Schneider Electric (one of SPEAr's customers) that
in #endif part ]
Signed-off-by: Viresh Kumar
---
fs/Makefile | 2 +-
include/linux/dcookies.h | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/fs/Makefile b/fs/Makefile
index 999d1a23f036..0e85d1ae20da 100644
--- a/fs/Makefile
+++ b/fs/Makefile
@@ -64,7 +64,7 @@ obj
On 08-01-21, 15:53, Ionela Voinescu wrote:
> On Friday 08 Jan 2021 at 16:46:50 (+0530), Viresh Kumar wrote:
> > Hi,
> >
> > Here is the V4 with the general improvements for topology stuff. This
> > cleans up the code and makes it work with cpufreq modules.
> >
&g
writing
to amu_fie_cpus in case we don't have to, but that optimization itself
is creating more confusion than the real work. Lets just do that if all
the CPUs support AMUs. It is much cleaner that way.
Reviewed-by: Ionela Voinescu
Signed-off-by: Viresh Kumar
---
arch/arm64/kernel/topology.c | 20
there to unregister the notifier instead, but that seemed
too much instead of this simple check.
While at it, convert the print message to pr_debug instead of pr_info.
Signed-off-by: Viresh Kumar
---
arch/arm64/kernel/topology.c | 92 +++-
1 file changed, 48 insertions(+), 44
calling it for the third time.
Reviewed-by: Ionela Voinescu
Signed-off-by: Viresh Kumar
---
arch/arm64/kernel/topology.c | 27 ++-
1 file changed, 14 insertions(+), 13 deletions(-)
diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c
index ebadc73449f9
Hi,
Here is the V4 with the general improvements for topology stuff. This
cleans up the code and makes it work with cpufreq modules.
V4:
- Added Rby from Ionela.
- In 3/3, Print cpus instead of amu_fie_cpus and make it pr_debug
instead.
Viresh Kumar (3):
arm64: topology: Avoid
On 08-01-21, 09:44, Ionela Voinescu wrote:
> Now that I think of it again (after spending 30 minutes trying to come
> up with a more clear solution) I realised this is not actually a
> problem :).
>
> The only location that checks the invariance status is schedutil, but
> what a cpufreq governor
-overlay.dtb file.
The intermediate-overlay.dtb file along with all other overlays is them
applied to testcases.dtb to generate the master.dtb file.
Signed-off-by: Viresh Kumar
---
Depends on:
https://lore.kernel.org/lkml/be5cb12a68d9ac2c35ad9dd50d6b168f7cad6837.1609996381.git.viresh.ku...@linaro.org
Section 3.11 was incorrectly called 3.9, fix it.
Signed-off-by: Viresh Kumar
---
Documentation/kbuild/makefiles.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/kbuild/makefiles.rst
b/Documentation/kbuild/makefiles.rst
index d36768cf1250..9f6a11881951
On 07-01-21, 14:28, Masahiro Yamada wrote:
> On Wed, Jan 6, 2021 at 12:21 AM Rob Herring wrote:
> >
> > On Tue, Jan 5, 2021 at 4:24 AM Viresh Kumar wrote:
> > >
> > > Hello,
> > >
> > > Here is an attempt to make some changes in the ker
-off-by: Viresh Kumar
---
V3:
- Updated log
- Remove libfdt_dir
scripts/dtc/Makefile | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/scripts/dtc/Makefile b/scripts/dtc/Makefile
index 4852bf44e913..472ab8cd590c 100644
--- a/scripts/dtc/Makefile
+++ b/scripts/dtc/Makefile
We will start building overlays for platforms soon in the kernel and
would need these tools going forward. Lets start building them.
Signed-off-by: Viresh Kumar
---
scripts/dtc/Makefile | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/scripts/dtc/Makefile b/scripts/dtc
We will start building overlays for platforms soon in the kernel and
would need these tools going forward. Lets start fetching them.
Note that a copy of fdtdump.c was already copied back in the year 2012,
but was never updated or built for some reason.
Signed-off-by: Viresh Kumar
---
V2
We will start building overlays for platforms soon in the kernel and
would need these tools going forward. Lets fetch and build these.
Note that a copy of fdtdump.c was already copied back in the year 2012,
but it was never updated or built for some reason.
Signed-off-by: Viresh Kumar
Allow the overlays to have .dtbo extension instead of just .dtb. This
allows them to be identified easily by tools as well as humans.
Allow the dtbo outform in dtc.c for the same.
Signed-off-by: Viresh Kumar
---
Hello,
This was earlier posted for the Linux Kernel and here is the thread
where
Update dtc compiler to accept dtbo as an outform.
Signed-off-by: Viresh Kumar
---
I feel that this needs to go directly to
https://git.kernel.org/pub/scm/utils/dtc/dtc.git
Right ? I will send it separately if the idea is accepted here.
---
scripts/dtc/dtc.c | 2 ++
1 file changed, 2
Add support for building DT overlays (%.dtbo). The overlay's source file
will have the usual extension, i.e. .dts, though the blob will have
.dtbo extension to distinguish it from normal blobs.
Signed-off-by: Viresh Kumar
---
Makefile | 4 ++--
scripts/Makefile.lib | 12
?
Thanks.
--
Viresh
Viresh Kumar (2):
kbuild: Add support to build overlays (%.dtbo)
scripts: dtc: Handle outform dtbo
Makefile | 4 ++--
scripts/Makefile.lib | 12
scripts/dtc/dtc.c| 2 ++
3 files changed, 16 insertions(+), 2 deletions(-)
--
2.25.0.rc1.19
On 05-01-21, 12:22, Claudiu Beznea wrote:
> Microchip SAMA7G5 devices supports runtime changes of CPU frequency.
> This is doable by changing CPUPLL frequency along with MCK0 frequency.
> Along with this CPU's regulator must be changed to accommodate new
> frequencies.
>
> Signed-off-by: Claudiu
; caller and hence eliminating the need for the cpufreq_cpu_get and
> cpufreq_cpu_put. Thanks to Viresh Kumar for suggesting the fix.
>
> Addresses-Coverity: ("Dereference null return")
> Fixes: b43a7ffbf33b ("cpufreq: Notify all policy->cpus in
> cpufreq_no
sing the policy to transition_frequency_fidvid from the
> caller and hence eliminating the need for the cpufreq_cpu_get and
> cpufreq_cpu_put. Thanks to Viresh Kumar for suggesting the fix.
>
> Addresses-Coverity: ("Dereference null return")
> Fixes: b43a7ffbf33b ("cpufreq: Notify all
On 04-01-21, 13:02, Colin King wrote:
> From: Colin Ian King
>
> Currently there is an unlikely case where cpufreq_cpu_get returns a
> null policy and this will cause a null pointer dereference later on.
> Fix this by adding a null check and adding an error return.
>
> Addresses-Coverity:
On 03-01-21, 03:57, Yangtao Li wrote:
> Use devm_pm_opp_* API to simplify code.
>
> Signed-off-by: Yangtao Li
> ---
> drivers/devfreq/devfreq.c | 66 +--
> include/linux/devfreq.h | 23 --
> 2 files changed, 1 insertion(+), 88 deletions(-)
On 01-01-21, 16:54, Yangtao Li wrote:
> Hi,
>
> This patchset add devm_pm_opp_set_clkname, devm_pm_opp_put_clkname,
> devm_pm_opp_set_regulators, devm_pm_opp_put_regulators,
> devm_pm_opp_set_supported_hw, devm_pm_opp_of_add_table and
> devm_pm_opp_register_notifier.
Please also mention next
On 01-01-21, 16:54, Yangtao Li wrote:
> There is no need to manually release devm related resources.
>
> Signed-off-by: Yangtao Li
> ---
> drivers/gpu/drm/lima/lima_devfreq.c | 5 -
> 1 file changed, 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/lima/lima_devfreq.c
>
On 01-01-21, 16:54, Yangtao Li wrote:
> +/**
> + * devm_pm_opp_put_clkname() - Releases resources blocked for clk.
> + * @dev: Device for which we do this operation.
> + * @opp_table: OPP table returned from devm_pm_opp_set_clkname().
> + */
> +void devm_pm_opp_put_clkname(struct device *dev,
On 03-01-21, 03:54, Yangtao Li wrote:
> Use devm_pm_opp_* API to simplify code, and remove opp_table
> from tegra_devfreq.
Patches starting this one didn't appear in the same thread and it is a
nightmare to apply these now. Please send everything properly next
time.
--
viresh
Dropped lots of people from cc list
On 04-01-21, 12:49, Viresh Kumar wrote:
> On 01-01-21, 16:54, Yangtao Li wrote:
> > Use devm_pm_opp_* API to simplify code, and we don't need
> > to make opp_table glabal.
> >
> > Let's remove opp_table from geni_se later.
> &g
On 01-01-21, 16:54, Yangtao Li wrote:
> Hi,
>
> This patchset add devm_pm_opp_set_clkname, devm_pm_opp_put_clkname,
> devm_pm_opp_set_regulators, devm_pm_opp_put_regulators,
> devm_pm_opp_set_supported_hw, devm_pm_opp_of_add_table and
> devm_pm_opp_register_notifier.
You can't put so many names
On 01-01-21, 16:54, Yangtao Li wrote:
> Use devm_pm_opp_* API to simplify code, and we don't need
> to make opp_table glabal.
>
> Let's remove opp_table from geni_se later.
>
> Signed-off-by: Yangtao Li
> ---
> drivers/tty/serial/qcom_geni_serial.c | 23 +--
> 1 file
On 01-01-21, 16:54, Yangtao Li wrote:
> Add devres wrapper for dev_pm_opp_register_notifier() to simplify driver
> code.
>
> Signed-off-by: Yangtao Li
> ---
> drivers/opp/core.c | 38 ++
> include/linux/pm_opp.h | 6 ++
> 2 files changed, 44
On 01-01-21, 16:54, Yangtao Li wrote:
> We should use dev_pm_opp_put_clkname() to free opp table each time
> dev_pm_opp_of_add_table() got error.
>
> Signed-off-by: Yangtao Li
> ---
> drivers/tty/serial/qcom_geni_serial.c | 10 ++
> 1 file changed, 6 insertions(+), 4 deletions(-)
>
>
On 28-12-20, 17:03, Dmitry Osipenko wrote:
> 28.12.2020 09:22, Viresh Kumar пишет:
> > On 24-12-20, 16:00, Dmitry Osipenko wrote:
> >> In a device driver I want to set PD to the lowest performance state by
> >> removing the performance vote when dev_pm_opp_set_r
.c:1027:22: warning: dereference of noderef expression
drivers/mailbox/arm_mhuv2.c:1048:17: warning: dereference of noderef expression
Reported-by: kernel test robot
Signed-off-by: Viresh Kumar
---
drivers/mailbox/arm_mhuv2.c | 22 +++---
1 file changed, 11 insertions(+), 11
On 24-12-20, 16:00, Dmitry Osipenko wrote:
> In a device driver I want to set PD to the lowest performance state by
> removing the performance vote when dev_pm_opp_set_rate(dev, 0) is
> invoked by the driver.
>
> The OPP core already does this, but if OPP levels don't start from 0 in
> a
On 27-12-20, 18:22, Christophe JAILLET wrote:
> Le 22/12/2020 à 05:35, Viresh Kumar a écrit :
> > On 19-12-20, 11:17, Christophe JAILLET wrote:
> > > If 'cpufreq_register_driver()' fails, we must release the resources
> > > allocated in 'brcm_avs_prepare_init()' as
Fix the clock reference counting by calling the missing clk_put() in the
error path.
Cc: v5.10 # v5.10
Fixes: dd461cd9183f ("opp: Allow dev_pm_opp_get_opp_table() to return
-EPROBE_DEFER")
Signed-off-by: Viresh Kumar
---
drivers/opp/core.c | 5 -
1 file changed, 4 insert
0x14c/0x1f0
> [<89928aaa>] driver_register+0x64/0x120
>
> Fixes: dd461cd9183f ("opp: Allow dev_pm_opp_get_opp_table() to return
> -EPROBE_DEFER")
> Signed-off-by: Quanyang Wang
> ---
> drivers/opp/core.c | 6 --
> 1 file changed, 4 insertions(+),
On 23-12-20, 23:37, Dmitry Osipenko wrote:
> 23.12.2020 08:57, Viresh Kumar пишет:
> > What's wrong with getting the regulator in the driver as well ? Apart from
> > the
> > OPP core ?
>
> The voltage syncing should be done for each consumer regulator
> individually
On 23-12-20, 23:37, Dmitry Osipenko wrote:
> 23.12.2020 07:19, Viresh Kumar пишет:
> > On 22-12-20, 22:15, Dmitry Osipenko wrote:
> >> 22.12.2020 09:42, Viresh Kumar пишет:
> >>> On 17-12-20, 21:06, Dmitry Osipenko wrote:
> >>>> Add a ceil version of th
On 23-12-20, 23:36, Dmitry Osipenko wrote:
> 23.12.2020 07:34, Viresh Kumar пишет:
> > On 22-12-20, 22:19, Dmitry Osipenko wrote:
> >> 22.12.2020 12:12, Viresh Kumar пишет:
> >>> rate will be 0 for both the OPPs here if rate_not_available is true and
> &
On 23-12-20, 23:38, Dmitry Osipenko wrote:
> Well, there is no "same structure", the opp_table->set_opp_data is NULL
> there.
Right, I saw that yesterday. What I meant was that we need to start allocating
the structure for this case now.
--
viresh
On 17-12-20, 21:06, Dmitry Osipenko wrote:
> Support set_opp() customization without requiring to use regulators. This
> is needed by drivers which want to use dev_pm_opp_set_rate() for changing
> rates of a multiple clocks and don't need to touch regulator.
>
> One example is NVIDIA Tegra30/114
On 22-12-20, 22:39, Dmitry Osipenko wrote:
> 22.12.2020 22:21, Dmitry Osipenko пишет:
> >>> + if (IS_ERR(opp)) {
> >>> + dev_err(>dev, "failed to find OPP for level %u: %pe\n",
> >>> + level, opp);
> >>> + return PTR_ERR(opp);
> >>> + }
> >>> +
> >>> + err =
On 22-12-20, 22:19, Dmitry Osipenko wrote:
> 22.12.2020 12:12, Viresh Kumar пишет:
> > On 17-12-20, 21:06, Dmitry Osipenko wrote:
> >> Fix adding OPP entries in a wrong (opposite) order if OPP rate is
> >> unavailable. The OPP comparison is erroneously skipped if OPP
On 22-12-20, 22:17, Dmitry Osipenko wrote:
> 22.12.2020 11:59, Viresh Kumar пишет:
> > On 17-12-20, 21:06, Dmitry Osipenko wrote:
> >> A required OPP may not be available, and thus, all OPPs which are using
> >> this required OPP should be unavailable too.
> >>
On 22-12-20, 22:15, Dmitry Osipenko wrote:
> 22.12.2020 09:42, Viresh Kumar пишет:
> > On 17-12-20, 21:06, Dmitry Osipenko wrote:
> >> Add a ceil version of the dev_pm_opp_find_level(). It's handy to have if
> >> levels don't start from 0 in OPP table and zero usually
On 18-12-20, 16:51, Dmitry Osipenko wrote:
> Alright, although I haven't pretended that v2 patches should be merged
> right away since they are fundamentally different from v1, and thus, all
> patches need to be reviewed first.
I agree. I have done some basic review for the stuff.
> If the
On 17-12-20, 21:06, Dmitry Osipenko wrote:
> Fix adding OPP entries in a wrong (opposite) order if OPP rate is
> unavailable. The OPP comparison is erroneously skipped if OPP rate is
> missing, thus OPPs are left unsorted.
>
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/opp/core.c | 23
On 17-12-20, 21:06, Dmitry Osipenko wrote:
> diff --git a/arch/arm/boot/dts/tegra30-peripherals-opp.dtsi
> b/arch/arm/boot/dts/tegra30-peripherals-opp.dtsi
> index cbe84d25e726..983db1a06682 100644
> --- a/arch/arm/boot/dts/tegra30-peripherals-opp.dtsi
> +++
On 17-12-20, 21:06, Dmitry Osipenko wrote:
> Support set_opp() customization without requiring to use regulators. This
> is needed by drivers which want to use dev_pm_opp_set_rate() for changing
> rates of a multiple clocks and don't need to touch regulator.
>
> One example is NVIDIA Tegra30/114
On 17-12-20, 21:06, Dmitry Osipenko wrote:
> A required OPP may not be available, and thus, all OPPs which are using
> this required OPP should be unavailable too.
>
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/opp/core.c | 11 ++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
On 17-12-20, 21:06, Dmitry Osipenko wrote:
> Add resource-managed versions of OPP API functions. This removes a need
> from drivers to store and manage OPP table pointers.
>
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/opp/core.c | 173 +
>
On Mon, 9 Nov 2020 at 16:51, Frank Lee wrote:
> On Mon, Nov 9, 2020 at 1:53 PM Viresh Kumar wrote:
> > > devm_pm_opp_set_supported_hw()
> > > devm_pm_opp_set_regulators() [if we won't use GENPD]
> > > devm_pm_opp_set_clkname()
> > > devm_pm_opp_of_add_
On 17-12-20, 21:06, Dmitry Osipenko wrote:
> Add a ceil version of the dev_pm_opp_find_level(). It's handy to have if
> levels don't start from 0 in OPP table and zero usually means a minimal
> level.
>
> Signed-off-by: Dmitry Osipenko
Why doesn't the exact version work for you here ?
--
On 17-12-20, 21:05, Dmitry Osipenko wrote:
> Extend OPP API with dev_pm_opp_sync_regulators() function, which syncs
> voltage state of regulators.
>
> Signed-off-by: Dmitry Osipenko
We shouldn't be doing this, details in patch 28.
--
viresh
On 17-12-20, 21:06, Dmitry Osipenko wrote:
> Add dev_pm_opp_set_voltage() which allows OPP table users to set voltage
> in accordance to a given OPP. In particular this is needed for driving
> voltage of a generic power domain which uses OPPs and doesn't have a
> clock.
>
> Signed-off-by: Dmitry
On 17-12-20, 21:06, Dmitry Osipenko wrote:
> +++ b/drivers/soc/tegra/core-power-domain.c
> @@ -0,0 +1,125 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * NVIDIA Tegra SoC Core Power Domain Driver
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
>
On 17-12-20, 21:06, Dmitry Osipenko wrote:
> diff --git a/arch/arm/boot/dts/tegra20-peripherals-opp.dtsi
> b/arch/arm/boot/dts/tegra20-peripherals-opp.dtsi
> index b84afecea154..7e015cdfbc55 100644
> --- a/arch/arm/boot/dts/tegra20-peripherals-opp.dtsi
> +++
On 19-12-20, 11:17, Christophe JAILLET wrote:
> If 'cpufreq_register_driver()' fails, we must release the resources
> allocated in 'brcm_avs_prepare_init()' as already done in the remove
> function.
>
> To do that, introduce a new function 'brcm_avs_prepare_uninit()' in order
> to avoid code
On 18-12-20, 11:01, Catalin Marinas wrote:
> On Fri, Dec 18, 2020 at 09:56:02AM +0530, Viresh Kumar wrote:
> > On 17-12-20, 10:55, Catalin Marinas wrote:
> > > Hi Viresh,
> > >
> > > On Thu, Dec 17, 2020 at 01:27:32PM +0530, Viresh Kumar wrote:
> >
On 26-11-20, 19:45, AngeloGioacchino Del Regno wrote:
> On new SoCs (SDM845 onwards) the Operating State Manager (OSM) is
> being programmed in the bootloader and write-protected by the
> hypervisor, leaving to the OS read-only access to some of its
> registers (in order to read the Lookup Tables
On 17-12-20, 21:05, Dmitry Osipenko wrote:
> Introduce core voltage scaling for NVIDIA Tegra20/30 SoCs, which reduces
> power consumption and heating of the Tegra chips. Tegra SoC has multiple
> hardware units which belong to a core power domain of the SoC and share
> the core voltage. The voltage
On 17-12-20, 10:55, Catalin Marinas wrote:
> Hi Viresh,
>
> On Thu, Dec 17, 2020 at 01:27:32PM +0530, Viresh Kumar wrote:
> > On 15-12-20, 11:04, Viresh Kumar wrote:
> > > Every time I have stumbled upon this routine, I get confused with the
> > > way 'have_
On 16-12-20, 19:37, Ionela Voinescu wrote:
> I did not yet test this, but reading this comment made me wonder..
>
> arch_scale_freq_invariant() (or topology_scale_freq_invariant()) is also
> called from schedutil when obtaining the next frequency.
>
> So if we had a system that only partly
On 15-12-20, 11:04, 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 an
On 07-12-20, 11:46, Viresh Kumar wrote:
> 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 wrot
On 16-12-20, 00:03, Ionela Voinescu wrote:
> Hi,
>
> On Tuesday 15 Dec 2020 at 11:04:16 (+0530), Viresh Kumar wrote:
> > The AMU counters won't get used today if the cpufreq driver is built as
> > a module as the amu core requires everything to be ready by late init.
>
that the AMUs have higher priority than
CPPC counters if available, though the CPPC driver doesn't need to have
any special handling for that.
This also exports sched_setattr_nocheck() as the CPPC driver can be
built as a module.
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/cppc_cpufreq.c | 140
counters for example.
Signed-off-by: Viresh Kumar
---
arch/arm64/include/asm/topology.h | 8 +--
arch/arm64/kernel/topology.c | 89 ++-
drivers/base/arch_topology.c | 56 +--
include/linux/arch_topology.h | 13 -
4 files changed, 104
://lore.kernel.org/lkml/5ffc7b9ed03c6301ac2f710f609282959491b526.1608010334.git.viresh.ku...@linaro.org/
Viresh Kumar (2):
topology: Allow multiple entities to provide sched_freq_tick()
callback
cpufreq: cppc: Add support for frequency invariance
arch/arm64/include/asm/topology.h | 8
there to unregister the notifier instead, but that seemed
too much instead of this simple check.
Signed-off-by: Viresh Kumar
---
V3:
- This is a new patch.
Ionela,
I don't have a way to test the AMU stuff, will it be possible for you to
give it a try ?
arch/arm64/kernel/topology.c | 88
calling it for the third time.
Signed-off-by: Viresh Kumar
---
V3:
- Skipped the enable/disable dance.
- No need to call topology_scale_freq_invariant() multiple times.
arch/arm64/kernel/topology.c | 27 ++-
1 file changed, 14 insertions(+), 13 deletions(-)
diff --git a/arch
writing
to amu_fie_cpus in case we don't have to, but that optimization itself
is creating more confusion than the real work. Lets just do that if all
the CPUs support AMUs. It is much cleaner that way.
Reviewed-by: Ionela Voinescu
Signed-off-by: Viresh Kumar
---
V3:
- Added Reviewed by tag.
arch
On 14-12-20, 14:00, Ionela Voinescu wrote:
> I think there could be a potential problem here (it would be unlikely
> but why not fix it :) ). It was in the code before your changes.
>
> When we enable amu_fie_key here, topology_scale_freq_tick() could be
> called for AMU CPUs, which will compute
he
> > hardware.
>
> In this second revision there are three patches (one preparatory patch for
> schedutil that hasn't changed since the v1, the introduction of the new
> callback and schedutil changes in patch [2/3] and the intel_pstate changes
> in patch [3/3] that are the same as before.
>
> Please see patch changelogs for details.
Acked-by: Viresh Kumar
--
viresh
On 08-12-20, 14:32, Viresh Kumar 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
On 09-12-20, 16:32, Rafael J. Wysocki wrote:
> So I have misunderstood your example.
>
> In the non-invariant case (which is or shortly will be relevant for
> everybody interested) cpuinfo.max_freq goes into the calculation
> instead of the current frequency and the mapping between util and freq
On 10-12-20, 10:38, Ionela Voinescu wrote:
> Basically, that's functions purpose is only to make sure that invariance
> at the level of the policy is consistent: either all CPUs in a policy
> support counters and counters will be used for the scale factor, or
> either none or only some support
On 10-12-20, 11:17, Viresh Kumar wrote:
> 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")
> Si
writing
to amu_fie_cpus in case we don't have to, but that optimization itself
is creating more confusion than the real work. Lets just do that if all
the CPUs support AMUs. It is much cleaner that way.
Signed-off-by: Viresh Kumar
---
V2:
- Skip the have_policy check altogether
- Updated subject and log
.
Signed-off-by: Viresh Kumar
---
V2:
- The enable/disable dance is actually required, just made a bunch of
other optimizations to make it look better.
arch/arm64/kernel/topology.c | 22 ++
1 file changed, 14 insertions(+), 8 deletions(-)
diff --git a/arch/arm64/kernel/topology.c
;
> + return spear_pinctrl_probe(pdev, _machdata);
> }
>
> static struct platform_driver spear300_pinctrl_driver = {
Acked-by: Viresh Kumar
--
viresh
On 10-12-20, 11:29, Ionela Voinescu wrote:
> On Thursday 10 Dec 2020 at 16:25:06 (+0530), Viresh Kumar wrote:
> > - But right after that we call static_branch_disable() if we aren't
> > invariant (call to topology_scale_freq_invariant()), and this will
> > happen if amu_
401 - 500 of 16408 matches
Mail list logo
