On 20-01-21, 17:50, Dmitry Osipenko wrote:
> If OPP API was meant to be thread-safe, then the
> dev_pm_opp_unregister_set_opp_helper() should unset the
> opp_table->set_opp_data under the lock since it races with
> dev_pm_opp_set_regulators().
Right, I will fix that.
> Secondly, functions like
On 20-01-21, 13:38, Viresh Kumar wrote:
> On 19-01-21, 12:05, Viresh Kumar wrote:
> > Until now the ->set_opp() helper (i.e. special implementation for
> > setting the OPPs for platforms) was implemented only to take care of
> > multiple regulators case, but goi
dev_pm_opp_set_bw() is getting removed and dev_pm_opp_set_opp() should
be used instead. Migrate to the new API.
Signed-off-by: Viresh Kumar
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
dev_pm_opp_set_bw() is getting removed and dev_pm_opp_set_opp() should
be used instead. Migrate to the new API.
Signed-off-by: Viresh Kumar
---
drivers/devfreq/tegra30-devfreq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/devfreq/tegra30-devfreq.c
b/drivers
dev_pm_opp_set_bw() is getting removed and dev_pm_opp_set_opp() should
be used instead. Migrate to the new API.
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/qcom-cpufreq-hw.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/cpufreq/qcom-cpufreq-hw.c
b/drivers
Drop the unnecessary parameters and follow the pattern from
_generic_set_opp_regulator().
While at it, also remove the local variable old_freq.
Signed-off-by: Viresh Kumar
---
drivers/opp/core.c | 22 +-
1 file changed, 9 insertions(+), 13 deletions(-)
diff --git a/drivers
checks as well.
Signed-off-by: Viresh Kumar
---
drivers/opp/core.c | 83 +-
drivers/opp/opp.h | 2 ++
2 files changed, 55 insertions(+), 30 deletions(-)
diff --git a/drivers/opp/core.c b/drivers/opp/core.c
index cb5b67ccf5cf..4ee598344e6a 100644
This routine has nothing to do with frequency, it just disables all the
resources previously enabled. Rename it to match its purpose.
Signed-off-by: Viresh Kumar
---
drivers/opp/core.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/opp/core.c b/drivers/opp
On 20-01-21, 18:41, Dmitry Osipenko wrote:
> 19.01.2021 20:35, Dmitry Osipenko пишет:
> > 18.01.2021 14:46, Viresh Kumar пишет:
> >> On 18-01-21, 03:55, Dmitry Osipenko wrote:
> >>> Hi,
> >>>
> >>> This series fixes problems and adds features
On 21-01-21, 17:34, David Gibson wrote:
> No, this is the wrong way around. The expected operation here is that
> you apply overlay (1) to the base tree, giving you, say, output1.dtb.
> output1.dtb is (effectively) a base tree itself, to which you can then
> apply overlay-(2).
Thanks for the
On 20-01-21, 23:55, Frank Rowand wrote:
> yes, but using the modified versions ("/plugin/;" removed) of
> testcases.dtb and overlay_base.dtb.
Okay, that would work fine I guess. I will try to implement this in
the new version.
> I apologize in advance if I get confused in these threads or cause
On 20-01-21, 23:45, Frank Rowand wrote:
> I have only the most surface knowledge of fdtoverlay, mostly from
> "fdtoverlay --help", but you can apply multiple overlays with a
> single invocation of fdtoverlay. My _assumption_ was that the
> overlays would be applied in order, and after any given
Hi Frank,
On 20-01-21, 23:34, Frank Rowand wrote:
> It should be possible to apply this same concept to copying overlay_base.dts
> to overlay_base_base.dts, removing the "/plugin/;" from overlay_base_base.dts
> and using an additional rule to use fdtoverlay to apply overlay.dtb on top
> of
On 20-01-21, 23:14, Frank Rowand wrote:
> It is a convenient FDT to use because it provides the frame that the overlays
> require to be applied. It is fortunate that fdtoverlay does not reject the
> use
> of an FDT with overlay metadata as the base blob.
> This is probably a good idea instead
On 20-01-21, 23:00, Frank Rowand wrote:
> unittest.c first unflattens overlay_base.dtb during early boot. Then later
> it does some phandle resolution using the overlay metadata from overlay_base.
> Then it removes the overlay metadata from the in kernel devicetree data
> structure. It is a
On 20-01-21, 14:16, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> The tango platform is getting removed, so the driver is no
> longer needed.
>
> Cc: Marc Gonzalez
> Cc: Mans Rullgard
> Signed-off-by: Arnd Bergmann
> ---
> drivers/cpufreq/Kconfig.arm | 5 -
>
On 21-01-21, 11:49, David Gibson wrote:
> If you're using overlays, you probably need the -@ flag, for both the
> base file and the overlays, which AFAICT is not already the case.
I think the idea was to do that in the platform specific Makefiles,
unless I have misunderstood that from earlier
On 21-01-21, 11:44, David Gibson wrote:
> On Wed, Jan 20, 2021 at 12:36:45PM +0530, Viresh Kumar wrote:
> > 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 d
On 20-01-21, 09:43, Rob Herring wrote:
> On Wed, Jan 20, 2021 at 1:07 AM Viresh Kumar wrote:
> >
> > Hi Frank/Rob,
> >
> > I have picked all the related patches together into a single patchset,
> > so they can be properly reviewed/tested.
> >
&g
+---
> 1 file changed, 18 insertions(+), 15 deletions(-)
Reviewed-by: Viresh Kumar
--
viresh
On 20-01-21, 20:04, Masahiro Yamada wrote:
> The DTC rule takes one source input, and one output file.
>
> It cannot generate .dtb and .dtbo at the same time.
>
> That is why a grouped target does not fit here.
Okay, thanks for taking time to explain this. Will fix this in the
next version.
--
On 20-01-21, 17:58, Masahiro Yamada wrote:
> > +%.dtb %.dtbo: include/config/kernel.release scripts_dtc
> > $(Q)$(MAKE) $(build)=$(dtstree) $(dtstree)/$@
>
>
> No, this is wrong because it does not work
> as grouped targets.
>
> You need to separate them.
>
>
>
> %.dtb:
On 19-01-21, 12:05, Viresh Kumar wrote:
> Until now the ->set_opp() helper (i.e. special implementation for
> setting the OPPs for platforms) was implemented only to take care of
> multiple regulators case, but going forward we would need that for other
> use cases as well.
tps://krzk.eu/#/builders/21/builds/2862/steps/15/logs/serial0
>
> I did not do a bisect but the last commit touching these parts was:
>
> commit 302c014726dbd9fcde852985528c139d2214a1f2
> Author: Viresh Kumar
> Date: Tue Jan 19 11:58:58 2021 +0530
> opp: Prepare for
On 19-01-21, 20:16, Dmitry Osipenko wrote:
> 19.01.2021 09:35, Viresh Kumar пишет:
> > + mutex_lock(_table->lock);
> > + opp_table->set_opp_data = data;
> > + if (opp_table->sod_supplies) {
> > + data->old_opp.supplies = opp_ta
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
---
.gitignore | 3 +--
Makefile | 4
in the static_test.dtb.
Signed-off-by: Viresh Kumar
---
drivers/of/unittest-data/Makefile | 50 +++
1 file changed, 50 insertions(+)
diff --git a/drivers/of/unittest-data/Makefile
b/drivers/of/unittest-data/Makefile
index 009f4045c8e4..ece7dfd5cafa 100644
--- a/drivers/of/unittest
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 | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/scripts/dtc/update-dtc
(Frank).
--
Viresh
[1]
https://github.com/dgibson/dtc/commit/163f0469bf2ed8b2fe5aa15bc796b93c70243ddc
[2] https://lore.kernel.org/lkml/74f8aa8f-ffab-3b0f-186f-31fb7395e...@gmail.com/
Viresh Kumar (5):
scripts: dtc: Fetch fdtoverlay.c from external DTC project
scripts: dtc: Build fdtoverlay tool
On 20-01-21, 10:36, Viresh Kumar wrote:
> On 19-01-21, 09:44, Frank Rowand wrote:
> > No. overlay_base.dts is intentionally compiled into a base FDT, not
> > an overlay. Unittest intentionally unflattens this FDT in early boot,
> > in association with unflattening the system
+David.
On 19-01-21, 11:12, Frank Rowand wrote:
> On 1/12/21 2:28 AM, Viresh Kumar wrote:
> > We will start building overlays for platforms soon in the kernel and
> > would need fdtoverlay tool going forward. Lets start fetching and
> > building it.
> >
> > W
On 19-01-21, 09:44, Frank Rowand wrote:
> No. overlay_base.dts is intentionally compiled into a base FDT, not
> an overlay. Unittest intentionally unflattens this FDT in early boot,
> in association with unflattening the system FDT. One key intent
> behind this is to use the same memory
On 20-01-21, 04:50, Dmitry Osipenko wrote:
> Make set_performance_state() callback optional in order to remove the
> need from power domain drivers to implement a dummy callback. If callback
> isn't implemented by a GENPD driver, then the performance state is passed
> to the parent domain.
>
>
On 19-01-21, 18:01, Dmitry Osipenko wrote:
> The regular devm_opp_* helpers won't be usable for CPUFreq drivers because
> OPP is applied to the CPU device and not the device of the CPUFreq driver.
Ahh, I missed that.
> But maybe we could support such cases by the helpers?
>
> I CC'd Yangtao
On 19-01-21, 12:02, Ulf Hansson wrote:
> As a matter of fact this was quite recently discussed [1], which also
> pointed out some issues when using the "required-opps" in combination,
> but perhaps that got resolved? Viresh?
Perhaps we never did anything there ..
--
viresh
On 19-01-21, 10:52, Ulf Hansson wrote:
> That would work if the topology is built from top to bottom, but I
> don't think we can rely on that.
>
> For example, when a domain A is added as a child to domain B, domain B
> doesn't have a parent yet (and the "can-handle-pstates" don't get set
> for
On 08-01-21, 16:46, 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.
>
> V4:
> - Added Rby from Ionela.
> - In 3/3, Print cpus instead of amu_fie_cpus and make
On 18-01-21, 20:21, frowand.l...@gmail.com wrote:
> From: Frank Rowand
>
> These changes apply on top of the patches in:
>
> [PATCH] of: unittest: Statically apply overlays using fdtoverlay
> Message-Id:
> <1e42183ccafa1afba33b3e79a4e3efd3329fd133.1610095159.git.viresh.ku...@linaro.org>
>
On 18-01-21, 21:48, Dmitry Osipenko wrote:
> 18.01.2021 14:44, Viresh Kumar пишет:
> > On 18-01-21, 03:55, Dmitry Osipenko wrote:
> >> diff --git a/include/linux/pm_opp.h b/include/linux/pm_opp.h
> >> index eefd0b15890c..c98fd2add563 100644
> >> --- a/inclu
art
from dev_pm_opp_set_regulators() and the opp helper part from
dev_pm_opp_register_set_opp_helper().
Signed-off-by: Viresh Kumar
---
Dmitry,
I haven't tested this patch, can you please help with that ?
drivers/opp/core.c | 81 --
drivers/opp/op
On 18-01-21, 21:35, Dmitry Osipenko wrote:
> 18.01.2021 11:20, Viresh Kumar пишет:
> >> +int dev_pm_opp_sync_regulators(struct device *dev)
> >> +{
> >> + struct opp_table *opp_table;
> >> + struct regulator *reg;
> >> + int i, ret = 0;
(retval < 0) {
> dev_err(>dev,
> "failed to send ARPC request %d: %d\n",
> rpc->req->type, retval);
> - if (retval > 0)
> - retval = -EIO;
> return retval;
> }
Reviewed-by: Viresh Kumar
--
viresh
On 18-01-21, 13:46, Ulf Hansson wrote:
> You seem to be worried about latency/overhead while doing the
> propagation upwards in the hierarchy. That seems like a reasonable
> concern to me, especially as the genpd lock is taken at each level.
I am not sure how many levels of domains we have
On 18-01-21, 03:55, 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.
>
> Tested-by: Peter Geis
> Tested-by: Nicolas Chauvet
> Tested-by: Matt Merhar
>
On 18-01-21, 03:55, Dmitry Osipenko wrote:
> Add resource-managed version of dev_pm_opp_attach_genpd().
>
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/opp/core.c | 35 +++
> include/linux/pm_opp.h | 8
> 2 files changed, 43 insertions(+)
>
>
On 18-01-21, 03:55, Dmitry Osipenko wrote:
> diff --git a/include/linux/pm_opp.h b/include/linux/pm_opp.h
> index eefd0b15890c..c98fd2add563 100644
> --- a/include/linux/pm_opp.h
> +++ b/include/linux/pm_opp.h
> @@ -13,6 +13,7 @@
>
> #include
> #include
> +#include
> #include
>
>
On 18-01-21, 03:55, Dmitry Osipenko wrote:
> Hi,
>
> This series fixes problems and adds features to OPP API that are required
> for implementation of a power domain driver for NVIDIA Tegra SoCs.
>
> It is a continuation of [1], where Viresh Kumar asked to factor OPP
> pa
On 18-01-21, 03:55, Dmitry Osipenko wrote:
> Print OPP level in debug message of _opp_add_static_v2(). This helps to
> chase GENPD bugs.
>
> Tested-by: Peter Geis
> Tested-by: Nicolas Chauvet
> Tested-by: Matt Merhar
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/opp/of.c | 5 +++--
> 1
On 18-01-21, 03:55, Dmitry Osipenko wrote:
> NVIDIA Tegra SoCs have a power domains topology such that child domains
> only clamp a power rail, while parent domain controls shared performance
> state of the multiple child domains. In this case child's domain doesn't
> need to have OPP table. Hence
On 18-01-21, 03:55, Dmitry Osipenko wrote:
> Add resource-managed version of dev_pm_opp_register_set_opp_helper().
>
> Tested-by: Peter Geis
> Tested-by: Nicolas Chauvet
> Tested-by: Matt Merhar
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/opp/core.c | 34
On 18-01-21, 16:30, Viresh Kumar wrote:
> On 18-01-21, 03:55, Dmitry Osipenko wrote:
> > Extend OPP API with dev_pm_opp_sync_regulators() function, which syncs
> > voltage state of regulators.
> >
> > Tested-by: Peter Geis
> > Tested-by: Nicolas Chauvet
>
On 18-01-21, 11:59, Ulf Hansson wrote:
> Good point! I certainly overlooked that when reviewing. We need to
> reevaluate the new state when propagating to the parent(s).
>
> To me, it looks like when doing the propagation we must check if the
> parent has the ->set_performance_state() callback
On 18-01-21, 03:55, Dmitry Osipenko wrote:
> Add dev_pm_opp_get_required_pstate() which allows OPP users to retrieve
> required performance state of a given OPP.
>
> Tested-by: Peter Geis
> Tested-by: Nicolas Chauvet
> Tested-by: Matt Merhar
> Signed-off-by: Dmitry Osipenko
> ---
>
On 18-01-21, 03:55, Dmitry Osipenko wrote:
> Extend OPP API with dev_pm_opp_sync_regulators() function, which syncs
> voltage state of regulators.
>
> Tested-by: Peter Geis
> Tested-by: Nicolas Chauvet
> Tested-by: Matt Merhar
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/opp/core.c |
On 18-01-21, 03:55, Dmitry Osipenko wrote:
> diff --git a/drivers/opp/core.c b/drivers/opp/core.c
> index 99d18befc209..341484d58e6c 100644
> --- a/drivers/opp/core.c
> +++ b/drivers/opp/core.c
> @@ -2731,3 +2731,58 @@ int dev_pm_opp_sync_regulators(struct device *dev)
> return ret;
> }
>
On 18-01-21, 03:55, Dmitry Osipenko wrote:
> Extend OPP API with dev_pm_opp_sync_regulators() function, which syncs
> voltage state of regulators.
>
> Tested-by: Peter Geis
> Tested-by: Nicolas Chauvet
> Tested-by: Matt Merhar
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/opp/core.c |
On 18-01-21, 03:55, Dmitry Osipenko wrote:
> The debug message always prints rate=0 instead of a proper value, fix it.
>
> Tested-by: Peter Geis
> Tested-by: Nicolas Chauvet
> Tested-by: Matt Merhar
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/opp/of.c | 4 ++--
> 1 file changed, 2
On 18-01-21, 03:55, Dmitry Osipenko wrote:
> A required OPP may not be available, and thus, all OPPs which are using
> this required OPP should be unavailable too.
>
> Tested-by: Peter Geis
> Tested-by: Nicolas Chauvet
> Tested-by: Matt Merhar
> Signed-off-by: Dmitry Osipenko
> ---
>
On 18-01-21, 03:55, Dmitry Osipenko wrote:
> Fix adding OPP entries in a wrong (opposite) order if OPP rate is
> unavailable. The OPP comparison was erroneously skipped, thus OPPs
> were left unsorted.
>
> Tested-by: Peter Geis
> Tested-by: Nicolas Chauvet
> Tested-by: Matt Merhar
>
On 18-01-21, 15:21, Hsin-Yi Wang wrote:
> Do you still have plans to push this? I've tested on mt8183 cci with:
I was never able to get Saravana to test this, if you are interested
in this stuff then I can rebase this and resend and we can see if it
works.
--
viresh
rn ret == -ENOENT ? -EPROBE_DEFER : ret;
> }
> EXPORT_SYMBOL_GPL(of_genpd_add_subdomain);
>
Reviewed-by: Viresh Kumar
--
viresh
> children\n");
> + seq_puts(s, "domain status children
> performance\n");
> seq_puts(s, " /device
> runtime status\n");
> - seq_puts(s,
> "--\n");
> + seq_puts(s,
> "--\n");
>
> ret = mutex_lock_interruptible(_list_lock);
> if (ret)
Reviewed-by: Viresh Kumar
--
viresh
; return 0;
> @@ -399,9 +401,6 @@ int dev_pm_genpd_set_performance_state(struct device
> *dev, unsigned int state)
> if (!genpd)
> return -ENODEV;
>
> - if (unlikely(!genpd->set_performance_state))
> - return -EINVAL;
> -
> if (WAR
On 14-01-21, 09:51, Linus Torvalds wrote:
> On Thu, Jan 14, 2021 at 3:34 AM Viresh Kumar wrote:
> >
> > This is build/boot tested by kernel test robot (Intel) and Linaro's
> > Tuxmake[2] for a lot of architectures and no failures were reported.
>
> Can you make
On 17-01-21, 15:26, 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-01-21, 02:18, Dmitry Osipenko wrote:
> Switch cpufreq-tegra20 driver to use resource-managed API.
> This removes the need to get opp_table pointer using
> dev_pm_opp_get_opp_table() in order to release OPP table that
> was requested by dev_pm_opp_set_supported_hw(), making the code
> a bit
On 18-01-21, 16:31, Stephen Rothwell wrote:
> Hi all,
>
> After merging the oprofile-removal tree, today's linux-next build
> (powerpc allyesconfig) failed like this:
>
> make[4]: *** No rule to make target
> 'arch/powerpc/platforms/cell/spu_notify.o', needed by
>
On 14-01-21, 17:05, Viresh Kumar wrote:
> The "oprofile" user-space tools don't use the kernel OPROFILE support
> any more, and haven't in a long time. User-space has been converted to
> the perf interfaces.
>
> This commits stops building oprofile for powerpc an
On 13-01-21, 16:18, Ionela Voinescu wrote:
> On Tuesday 15 Dec 2020 at 16:46:35 (+0530), Viresh Kumar wrote:
> > +void topology_scale_freq_tick(void)
> > +{
> > + struct scale_freq_tick_data *sftd = *this_cpu_ptr(_data);
> > +
> > + if (sftd)
On 30-12-20, 10:12, Viresh Kumar wrote:
> This patch fixes a bunch of sparse warnings in the newly added arm_mhuv2
> driver.
>
> drivers/mailbox/arm_mhuv2.c:506:24: warning: incorrect type in argument 1
> (different address spaces)
> drivers/mailbox/arm_mhuv2.c:506:24:e
+David,
On 14-01-21, 09:01, Rob Herring wrote:
> On Wed, Jan 13, 2021 at 11:03 PM Viresh Kumar wrote:
> >
> > On 11-01-21, 09:46, Rob Herring wrote:
> > > On Fri, Jan 8, 2021 at 2:41 AM Viresh Kumar
> > > wrote:
> > > >
> > > > Now
+LKML (Not sure why the cover-letter didn't go to LKML but everything else).
On 14-01-21, 17:04, Viresh Kumar wrote:
> Hello,
>
> The "oprofile" user-space tools don't use the kernel OPROFILE support
> any more, and haven't in a long time. User-space has been converted to
1] earlier.
This is build/boot tested by kernel test robot (Intel) and Linaro's
Tuxmake[2] for a lot of architectures and no failures were reported.
--
Viresh
[1]
https://lore.kernel.org/lkml/CAHk-=whw9t3ztv8ia2sjwyqs1vojus14p_qhj3v5-9pcbmg...@mail.gmail.com/
[2] https://lwn.net/Articles/841624/
Vi
On 14-01-21, 17:05, Viresh Kumar wrote:
> The "oprofile" user-space tools don't use the kernel OPROFILE support
> any more, and haven't in a long time. User-space has been converted to
> the perf interfaces.
>
> This commits stops building oprofile for powerpc an
On 14-01-21, 17:51, Vineet Gupta wrote:
> On 1/14/21 3:35 AM, Viresh Kumar wrote:
> > The "oprofile" user-space tools don't use the kernel OPROFILE support
> > any more, and haven't in a long time. User-space has been converted to
> > the perf interfaces.
&g
uggested-by: Christoph Hellwig
Suggested-by: Linus Torvalds
Signed-off-by: Viresh Kumar
---
arch/powerpc/Kconfig | 1 -
arch/powerpc/Makefile | 2 -
arch/powerpc/configs/44x/akebono_defconfig| 1 -
arch/powerpc/configs/44x/currituck_de
Signed-off-by: Viresh Kumar
---
arch/x86/Kconfig | 1 -
arch/x86/Makefile | 3 -
arch/x86/include/asm/nmi.h | 1 -
arch/x86/kernel/cpu/perfctr-watchdog.c | 11 +-
arch/x86/oprofile/Makefile | 12 -
arch/x86/oprofile/b
Signed-off-by: Viresh Kumar
---
arch/mips/Kconfig | 3 +-
arch/mips/Makefile| 1 -
arch/mips/configs/fuloong2e_defconfig | 1 -
arch/mips/configs/ip32_defconfig | 1 -
arch/mips/configs/lemote2f_defconfig |
Signed-off-by: Viresh Kumar
---
arch/sh/Kconfig | 1 -
arch/sh/Makefile | 1 -
arch/sh/configs/espt_defconfig | 1 -
arch/sh/configs/migor_defconfig | 1 -
arch/sh/configs/r7780mp_defconfig| 1 -
arch/sh/configs/r7785rp
The "oprofile" user-space tools don't use the kernel OPROFILE support
any more, and haven't in a long time. User-space has been converted to
the perf interfaces.
Remove kernel's old oprofile support.
Suggested-by: Christoph Hellwig
Suggested-by: Linus Torvalds
Signed-off-by: Vi
Signed-off-by: Viresh Kumar
---
Documentation/kbuild/makefiles.rst | 1 -
arch/sparc/Kconfig | 1 -
arch/sparc/Makefile | 1 -
arch/sparc/configs/sparc64_defconfig | 1 -
arch/sparc/oprofile/Makefile | 10
arch/sparc/oprofile/init.c
Signed-off-by: Viresh Kumar
---
arch/xtensa/Kconfig | 1 -
arch/xtensa/Makefile| 1 -
arch/xtensa/configs/audio_kc705_defconfig | 1 -
arch/xtensa/configs/generic_kc705_defconfig | 1 -
arch/xtensa/configs/smp_lx200_defconfig | 1 -
arch/xten
The dcookies stuff was only used by the kernel's old oprofile code. Now
that oprofile's support is removed from the kernel, there is no need for
dcookies as well. Remove it.
Suggested-by: Christoph Hellwig
Suggested-by: Linus Torvalds
Signed-off-by: Viresh Kumar
---
fs/Makefile
Signed-off-by: Viresh Kumar
---
arch/s390/Kconfig | 1 -
arch/s390/Makefile| 3 ---
arch/s390/configs/debug_defconfig | 1 -
arch/s390/configs/defconfig | 1 -
arch/s390/oprofile/Makefile | 10 -
arch/s390/oprofile/init.c
The previous commit already disabled building oprofile, lets remove the
oprofile directory now.
Suggested-by: Christoph Hellwig
Suggested-by: Linus Torvalds
Signed-off-by: Viresh Kumar
---
arch/powerpc/oprofile/Makefile | 19 -
arch/powerpc/oprofile/backtrace.c | 120
Signed-off-by: Viresh Kumar
---
arch/parisc/Kconfig | 1 -
arch/parisc/Makefile | 2 --
arch/parisc/oprofile/Makefile | 10 --
arch/parisc/oprofile/init.c | 23 ---
4 files changed, 36 deletions(-)
delete mode 100644 arch/parisc/oprofile/Makefile
d
Perfmon support (used by oprofile earlier) was removed by commit
ecf5b72d5f66 ("ia64: Remove perfmon") earlier, but it missed few files
to remove/update.
Clean it up.
Suggested-by: Arnd Bergmann
Signed-off-by: Viresh Kumar
---
arch/ia64/include/asm/hw_irq.h| 1 -
Signed-off-by: Viresh Kumar
---
arch/microblaze/Kconfig | 1 -
arch/microblaze/Makefile | 2 --
arch/microblaze/oprofile/Makefile | 14
.../microblaze/oprofile/microblaze_oprofile.c | 22 ---
4 files changed, 39
oprofile's architecture specific support.
Suggested-by: Christoph Hellwig
Suggested-by: Linus Torvalds
Signed-off-by: Viresh Kumar
---
arch/ia64/Kconfig | 1 -
arch/ia64/Makefile | 1 -
arch/ia64/configs/bigsur_defconfig | 1 -
arch/ia64/oprofile/Makefile
Signed-off-by: Viresh Kumar
---
arch/alpha/Kconfig | 1 -
arch/alpha/Makefile | 1 -
arch/alpha/oprofile/Makefile| 20 ---
arch/alpha/oprofile/common.c| 189
arch/alpha/oprofile/op_impl.h | 55 --
arch/alph
The "oprofile" user-space tools don't use the kernel OPROFILE support
any more, and haven't in a long time. User-space has been converted to
the perf interfaces.
Don't select HAVE_OPROFILE for hexagon anymore.
Suggested-by: Christoph Hellwig
Suggested-by: Linus Torvalds
Signed-off-
Signed-off-by: Viresh Kumar
---
arch/arc/Kconfig | 1 -
arch/arc/Makefile | 2 --
arch/arc/oprofile/Makefile | 10 --
arch/arc/oprofile/common.c | 23 ---
4 files changed, 36 deletions(-)
delete mode 100644 arch/arc/oprofile/Makefile
delete mode 10064
Signed-off-by: Viresh Kumar
---
arch/arm/Kconfig | 1 -
arch/arm/Makefile| 2 -
arch/arm/configs/bcm2835_defconfig | 1 -
arch/arm/configs/cns3420vb_defconfig | 1 -
arch/arm/configs/corgi_defconfig | 1 -
arch/arm/configs/imx_v4_v5_defconfig |
The following commit has been merged into the sched/core branch of tip:
Commit-ID: a5418be9dffe70ccbb0b4bd5ea3881c81927e965
Gitweb:
https://git.kernel.org/tip/a5418be9dffe70ccbb0b4bd5ea3881c81927e965
Author:Viresh Kumar
AuthorDate:Tue, 08 Dec 2020 09:46:56 +05:30
The following commit has been merged into the sched/core branch of tip:
Commit-ID: 7d6a905f3dd62c4502cdd772c71319de4058ec89
Gitweb:
https://git.kernel.org/tip/7d6a905f3dd62c4502cdd772c71319de4058ec89
Author:Viresh Kumar
AuthorDate:Tue, 08 Dec 2020 09:46:55 +05:30
The following commit has been merged into the sched/core branch of tip:
Commit-ID: d1515851ca075ed98fe78ac6abf24ba2dd25a63b
Gitweb:
https://git.kernel.org/tip/d1515851ca075ed98fe78ac6abf24ba2dd25a63b
Author:Viresh Kumar
AuthorDate:Tue, 08 Dec 2020 09:46:57 +05:30
On 13-01-21, 11:55, Nicola Mazzucato wrote:
> On 1/12/21 11:17 AM, Viresh Kumar wrote:
> > This could have been done with a per-cpu variable instead.
>
> sure, I can do a DEFINE_PER_CPU() for it if it makes it better.
If we don't go with the linked list app
On 11-01-21, 09:46, Rob Herring wrote:
> On Fri, Jan 8, 2021 at 2:41 AM Viresh Kumar wrote:
> >
> > Now that fdtoverlay is part of the kernel build, start using it to test
> > the unitest overlays we have by applying them statically.
>
> Nice idea.
>
> > Th
301 - 400 of 16408 matches
Mail list logo
