From: Mark Brown <broonie(a)linaro.org>
Another spin of the arm64 topology work - this should incorporate most
of the feedback from Lorenzo, there's a few things that were still under
discussion the main ones being:
- Should we have a smp_store_cpu_info(); like I say I like the errors
it generates for omitted cores and the reuse of the SMP enumeration
code (and cross-check with that I guess - make sure we don't get
confused about which CPUs are getting enabled).
- Should we update the binding to allow cores in the root cpu_map node
(since it's less effort in code and not a meaningful difference
semantically), warn if we find cores in the cpu_map node or actively
reject such DTs?
In both cases I don't much mind but I think what's there is reasonable
so I've left the code as-is pending further feedback. I also didn't
update the code to get more reuse of the iteration code, like I said I
did look at that when writing the code but couldn't find anything that
actually made things more pleasant but if someone has some ideas...
Everything else raised should be addressed I think.
Mark Brown (4):
arm64: topology: Implement basic CPU topology support
arm64: topology: Add support for topology DT bindings
arm64: topology: Tell the scheduler about the relative power of cores
arm64: topology: Provide relative power numbers for cores
arch/arm64/Kconfig | 24 +++
arch/arm64/include/asm/topology.h | 39 ++++
arch/arm64/kernel/Makefile | 1 +
arch/arm64/kernel/smp.c | 12 ++
arch/arm64/kernel/topology.c | 384 ++++++++++++++++++++++++++++++++++++++
5 files changed, 460 insertions(+)
create mode 100644 arch/arm64/include/asm/topology.h
create mode 100644 arch/arm64/kernel/topology.c
--
1.8.5.2
Hi Tushar / Samsung,
I am a bit confused on the interrupt number for CNTVIRQ..CNTHPIRQ. Can
you please help here.
As per the exynos5 public manual
What is the difference between  CPU_nCNTHPIRQ[0] and CNTHPIRQ.
While the later has an interrupt ID 26, the former is part of a group
with combined interrupt id as 33 for core 0 and 54 for core 1.
For a timer interrupt which goes to PL2, which id should be used 26 or
33 for core 0 ?
Please clear this confusion.
Many Thanks
There are several problems cpufreq stats in the way it handles
cpufreq_unregister_driver() and suspend/resume..
- We must not loose data collected so far when suspend/resume happens and so
stats directories must not be removed/allocated during these operations, Which
is done currently.
- cpufreq_stat has registered notifiers with both cpufreq and hotplug. It adds
sysfs stats directory with a cpufreq notifier: CPUFREQ_NOTIFY and removes this
directory with a notifier from hotplug core.
In case cpufreq_unregister_driver() is called (on rmmod cpufreq driver), stats
directories per cpu aren't removed as CPUs are still online. The only call
cpufreq_stats gets is cpufreq_stats_update_policy_cpu for all CPUs except the
last of each policy. And pointer to stat information is stored in the entry
for last cpu in per-cpu cpufreq_stats_table. But policy structure would be
freed inside cpufreq core and so that will result in memory leak inside
cpufreq stats (as we are never freeing memory for stats).
Now if we again insert the module cpufreq_register_driver() will be called and
we will again allocate stats data and put it on for first cpu of every policy.
In case we only have a single cpu per policy we will return with a error from
cpufreq_stats_create_table() due to below code:
if (per_cpu(cpufreq_stats_table, cpu))
return -EBUSY;
And so probably cpufreq stats directory would show up anymore (as it was added
inside last policies->kobj which doesn't exist anymore). I haven't tested it
though. Also the values in stats files wouldn't be refreshed as we are using
the earlier stats structure.
- CPUFREQ_NOTIFY is called from cpufreq_set_policy() which is called for
scenarios where we don't really want cpufreq_stat_notifier_policy() to get
called. For example whenever we are changing anything related to a policy:
min/max/current freq, etc.. cpufreq_set_policy() is called and so cpufreq
stats is notified. Where we don't do any useful stuff other than simply
returning with -EBUSY from cpufreq_stats_create_table(). And so this isn't the
right notifier that cpufreq stats..
Due to all above reasons this patch does following changes:
- Add new notifiers CPUFREQ_CREATE_POLICY and CPUFREQ_REMOVE_POLICY, which are
only called when policy is created/destroyed. They aren't called for
suspend/resume paths..
- Use these notifiers in cpufreq_stat_notifier_policy() to create/destory stats
sysfs entries. And so cpufreq_unregister_driver() or suspend/resume shouldn't
be a problem for cpufreq_stats.
- Return early from cpufreq_stat_cpu_callback() for suspend/resume sequence, so
that we don't free stats structure.
Acked-and-tested-by: Nicolas Pitre <nico(a)linaro.org>
Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org>
---
drivers/cpufreq/cpufreq.c | 5 +++++
drivers/cpufreq/cpufreq_stats.c | 24 +++++++++++++++++-------
include/linux/cpufreq.h | 2 ++
3 files changed, 24 insertions(+), 7 deletions(-)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 3509ca0..1afbe52 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -943,6 +943,9 @@ static void cpufreq_policy_put_kobj(struct cpufreq_policy *policy)
struct kobject *kobj;
struct completion *cmp;
+ blocking_notifier_call_chain(&cpufreq_policy_notifier_list,
+ CPUFREQ_REMOVE_POLICY, policy);
+
down_read(&policy->rwsem);
kobj = &policy->kobj;
cmp = &policy->kobj_unregister;
@@ -1148,6 +1151,8 @@ static int __cpufreq_add_dev(struct device *dev, struct subsys_interface *sif,
ret = cpufreq_add_dev_interface(policy, dev);
if (ret)
goto err_out_unregister;
+ blocking_notifier_call_chain(&cpufreq_policy_notifier_list,
+ CPUFREQ_CREATE_POLICY, policy);
}
write_lock_irqsave(&cpufreq_driver_lock, flags);
diff --git a/drivers/cpufreq/cpufreq_stats.c b/drivers/cpufreq/cpufreq_stats.c
index 4cf0d28..0f71562 100644
--- a/drivers/cpufreq/cpufreq_stats.c
+++ b/drivers/cpufreq/cpufreq_stats.c
@@ -277,7 +277,7 @@ static void cpufreq_stats_update_policy_cpu(struct cpufreq_policy *policy)
static int cpufreq_stat_notifier_policy(struct notifier_block *nb,
unsigned long val, void *data)
{
- int ret;
+ int ret = 0;
struct cpufreq_policy *policy = data;
struct cpufreq_frequency_table *table;
unsigned int cpu = policy->cpu;
@@ -287,15 +287,21 @@ static int cpufreq_stat_notifier_policy(struct notifier_block *nb,
return 0;
}
- if (val != CPUFREQ_NOTIFY)
- return 0;
table = cpufreq_frequency_get_table(cpu);
if (!table)
return 0;
- ret = cpufreq_stats_create_table(policy, table);
- if (ret)
- return ret;
- return 0;
+
+ if (val == CPUFREQ_CREATE_POLICY)
+ ret = cpufreq_stats_create_table(policy, table);
+ else if (val == CPUFREQ_REMOVE_POLICY) {
+ /* This might already be freed by cpu hotplug notifier */
+ if (per_cpu(cpufreq_stats_table, cpu)) {
+ cpufreq_stats_free_sysfs(cpu);
+ cpufreq_stats_free_table(cpu);
+ }
+ }
+
+ return ret;
}
static int cpufreq_stat_notifier_trans(struct notifier_block *nb,
@@ -340,6 +346,10 @@ static int cpufreq_stat_cpu_callback(struct notifier_block *nfb,
{
unsigned int cpu = (unsigned long)hcpu;
+ /* Don't free/allocate stats during suspend/resume */
+ if (action & CPU_TASKS_FROZEN)
+ return 0;
+
switch (action) {
case CPU_DOWN_PREPARE:
cpufreq_stats_free_sysfs(cpu);
diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
index aaf800e..bb727eb 100644
--- a/include/linux/cpufreq.h
+++ b/include/linux/cpufreq.h
@@ -308,6 +308,8 @@ cpufreq_verify_within_cpu_limits(struct cpufreq_policy *policy)
#define CPUFREQ_NOTIFY (2)
#define CPUFREQ_START (3)
#define CPUFREQ_UPDATE_POLICY_CPU (4)
+#define CPUFREQ_CREATE_POLICY (5)
+#define CPUFREQ_REMOVE_POLICY (6)
#ifdef CONFIG_CPU_FREQ
int cpufreq_register_notifier(struct notifier_block *nb, unsigned int list);
--
1.7.12.rc2.18.g61b472e
Hi,
While reading the kernel logs for arm64 (as one does) I noticed a few
patches that seemed like candidates for either LTS or LTSI. I've also
had a couple of others mentioned via other routes. What do you think of
these?
4ecf7ccb1973 arm64: spinlock: retry trylock operation if strex fails on free lock
This seems like a correctness fix for spinlocks, though since the
callers should cope with failure it's arguably just an optimisation.
53ae3acd4390 arm64: Only enable local interrupts after the CPU is marked online
82b2f495fba3 arm64: virt: ensure visibility of __boot_cpu_mode
845ad05ec31e arm64: Change kernel stack size to 16K
6db83cea1c97 arm64: fix possible invalid FPSIMD initialization state
7b22c03536a5 arm64: check for number of arguments in syscall_get/set_arguments()
df503ba7f653 arm64: dts: Reserve the memory used for secondary CPU release address
These all look like correctness fixes of one kind or another; the change
to 16K stacks is poorly explained but it looks like it's fixing failures
of some kind.
f0dd718090ae arm64: Remove unused cpu_name ascii in arch/arm64/mm/proc.S
A user was reporting that this caused build failures due to alignment
issues with some of the debug options turned on. I've not fully
investigated yet, this might be a toolchain issue though given how
simple the change is.
0d651e4e65e9 clocksource: arch_timer: use virtual counters
This is as mentioned in the changelog a correctness fix for avoiding
clocks going backwards and has also been found to be required to avoid
boot hangs with CONFIG_PROVE_RCU_DELAY enabled.
There were also a few others that aren't entirely -stable material but
might be a fit for LTSI (and the above might be if not -stable in
themselves):
b5b6c9e9149d arm64: Avoid cache flushing in flush_dcache_page()
7249b79f6b4c arm64: Do not flush the D-cache for anonymous pages
4f00130b70e5 arm64: Use Normal NonCacheable memory for writecombine
These look like simple, localised optimisations.
Thanks,
Mark
Hi Guys,
Here is series that enables KVM support for V7 big endian kernels. Mostly
it deals with BE KVM host support. Marc Zyngier showed before with his patches
how BE guest could run on top LE host. With these patches BE guest runs on
top of BE host. If Marc's kvmtool is used with few additional changes I tested
that BE host could run LE guest. Also I verified that there were no
regressions in BE guest on top of LE host case.
Note that posted series covers only kernel side changes. The changes were
tested inside of bigger setup with additional changes in qemu and kvmtool.
I will post those changes separately in proper aliases but for completeness
sake Appendix A gives pointers to git repositories and branches with all
needed changes.
Please note first patch is not related to BE KVM per se. I've run
into an issue of conflicting 'push' identifier use while trying to include
assembler.h into KVM .S files. Details of an issue I observed covered in
Appendix B. The first patch is my take on solving it.
Victor Kamensky (5):
ARM: kvm: replace push and pop with stdmb and ldmia instrs to enable
assembler.h inclusion
ARM: fix KVM assembler files to work in BE case
ARM: kvm one_reg coproc set and get BE fixes
ARM: kvm vgic mmio should return data in BE format in BE case
ARM: kvm MMIO support BE host running LE code
arch/arm/include/asm/assembler.h | 7 +++
arch/arm/include/asm/kvm_asm.h | 4 +-
arch/arm/include/asm/kvm_emulate.h | 22 +++++++--
arch/arm/kvm/coproc.c | 94 ++++++++++++++++++++++++++++----------
arch/arm/kvm/init.S | 7 ++-
arch/arm/kvm/interrupts.S | 50 +++++++++++---------
arch/arm/kvm/interrupts_head.S | 61 +++++++++++++++----------
virt/kvm/arm/vgic.c | 4 +-
8 files changed, 168 insertions(+), 81 deletions(-)
--
1.8.1.4
Thanks,
Victor
Appendix A: Testing and Full Setup Description
----------------------------------------------
I) No mixed mode setup - i.e BE guest on BE host; and LE guest
on LE host tested to make sure no regressions.
KVM host and guest kernels:
TC2 on top of Linus 3.13-rc4 (this patch series):
git: git://git.linaro.org/people/victor.kamensky/linux-linaro-tracking-be.git
branch: armv7be-kvm-3.13-rc4
TC2 and Arndale on top of Linaro BE tree:
git: git://git.linaro.org/people/victor.kamensky/linux-linaro-tracking-be.git
branch: llct-be-20131216-kvm
- TC1 kernels used as guests
qemu:
git: git://git.linaro.org/people/victor.kamensky/qemu-be.git
branch: armv7be-v1
description: changes to run qemu on armeb target; and other
changes to work with be image on top of be host
kvmtool:
git: git://git.linaro.org/people/victor.kamensky/linux-linaro-tracking-be.git
branch: kvmtool-armv7be-v1
desciption: minimal changes to build kvmtool for armeb target; and
tiny change with virtio magic
II) Mixed mode setup all possible combinations within V7 (LE guest on BE host;
BE guest on LE host as Marc's setup tested to make sure no regressions) only
with kvmtool.
This work is based on Marc Zyngier's work that made BE guest to run on top
of LE host. For this setup special version of kvmtool should be used and
in addition I had to apply patch to guest kernel that would switch reading
virtio configs reads to be LE only, that is made on top of previous Rusty
Russell's changes. Effectively I just had to do very minor addition to make
LE guest to work on BE host, most of heavy lifting was done before by Marc.
KVM host kernels: as in previous setup
Guest TC1 kernels with LE virtio config patch:
git: git://git.linaro.org/people/victor.kamensky/linux-linaro-tracking-be.git
branch: virtio-leconfig-3.13-rc4
kvmtool:
git: git://git.linaro.org/people/victor.kamensky/linux-linaro-tracking-be.git
branch: kvmtool-mixed-v1
description: based on git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git
branch kvm-arm64/kvmtool-be-on-le; adds missing include fix; above armeb target
build patches; and one fix related to BE mode
qemu:
git: git://git.linaro.org/people/victor.kamensky/qemu-be.git
branch: armv7be-leconfig-v1
description: change virtio-blk that so qemu could work with guest image
where virtio leconfig is made; note it does not work in mixed mode; to do
so qemu would need bunch of similar changes that Marc did in kvmtool
Appendix B: kvm asm file and asm/assembler.h file issue
-------------------------------------------------------
diff --git a/arch/arm/kvm/interrupts.S b/arch/arm/kvm/interrupts.S
index ddc1553..5d3b511 100644
--- a/arch/arm/kvm/interrupts.S
+++ b/arch/arm/kvm/interrupts.S
@@ -25,6 +25,7 @@
#include <asm/kvm_asm.h>
#include <asm/kvm_arm.h>
#include <asm/vfpmacros.h>
+#include <asm/assembler.h>
#include "interrupts_head.S"
.text
produce the following compilation errors:
/run/media/kamensky/wd/linaro/linux-linaro-core-tracking/092913/linux-linaro-tracking-be/arch/arm/kvm/interrupts.S: Assembler messages:
/run/media/kamensky/wd/linaro/linux-linaro-core-tracking/092913/linux-linaro-tracking-be/arch/arm/kvm/interrupts.S:51: Error: ARM register expected -- `lsr {r2,r3}'
/run/media/kamensky/wd/linaro/linux-linaro-core-tracking/092913/linux-linaro-tracking-be/arch/arm/kvm/interrupts.S:100: Error: ARM register expected -- `lsr {r2}'
/run/media/kamensky/wd/linaro/linux-linaro-core-tracking/092913/linux-linaro-tracking-be/arch/arm/kvm/interrupts.S:100: Error: ARM register expected -- `lsr {r4-r12}'
Missed lists earlier :(
On 7 January 2014 20:31, Viresh Kumar <viresh.kumar(a)linaro.org> wrote:
> Hi Kevin/Frederic,
>
> In my traces I see a guaranteed interrupt on the isolated
> core, which is running under NO_HZ_FULL mode and is
> running a single thread "stress", after ~90 seconds.
>
> When I look into the traces I see we get only two events:
> - irq-handler-entry
> - irq-handler-exit
>
> And no more detail is available in the traces, system again
> goes to no interruption mode for next 90 seconds.
>
> I hope this is because the timers we have queued for long
> enough times are getting overflowed? I tried to enable
> cpusets and then see which timers are active on CPU1 from
> /proc/timer_list and that gave me:
>
> tick_sched_timer and it_real_fn. These are probably queued
> for long enough times, around 450 seconds and 2000 seconds.
>
> So, my question is: Why are these getting queued? And how
> can I get rid of those for my case, where I want zero interruption
> on isolated core, as that would be running a userspace thread
> to handle data plane packets.
>
>
> Another thing I tried out recently was to make my single threaded
> task "stress" a real time task with priority 99 (along with cpusets).
> But it seems there are more than one thread getting on that CPU
> and so tick occurs immediately.
>
> I tried to call "stress" with help of chrt.
>
> --
> viresh
From: Mark Brown <broonie(a)linaro.org>
Now that the SPI controllers are disabled by default for Exynos5250
there is no need to explicitly disable them in individual board files.
This hunk appears not to have been merged when doing the original
conversion, add it now.
Signed-off-by: Mark Brown <broonie(a)linaro.org>
---
arch/arm/boot/dts/exynos5250-smdk5250.dts | 4 ----
1 file changed, 4 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts b/arch/arm/boot/dts/exynos5250-smdk5250.dts
index 3e69837c435c..b370f8a20cdf 100644
--- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
+++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
@@ -164,10 +164,6 @@
};
};
- spi_0: spi@12d20000 {
- status = "disabled";
- };
-
spi_1: spi@12d30000 {
status = "okay";
--
1.8.5.2
Hi Frederic/Kevin,
I was doing some work where I was required to use NO_HZ_FULL
on core 1 on a dual core ARM machine.
I observed that I was able to isolate the second core using cpusets
but whenever the tick occurs, it occurs twice. i.e. Timer count
gets updated by two every time my core is disturbed.
I tried to trace it (output attached) and found this sequence (Talking
only about core 1 here):
- Single task was running on Core 1 (using cpusets)
- got an arch_timer interrupt
- started servicing vmstat stuff
- so came out of NO_HZ_FULL domain as there is more than
one task on Core
- queued work again and went to the existing single task (stress)
- again got arch_timer interrupt after 5 ms (HZ=200)
- got "tick_stop" event and went into NO_HZ_FULL domain again..
- Got isolated again for long duration..
So the query is: why don't we check that at the end of servicing vmstat
stuff and migrating back to "stress" ??
Thanks.
--
viresh
From: Al Stone <al.stone(a)linaro.org>
This series of patches starts with Hanjun's patch to create a kernel
config item for CONFIG_ACPI_REDUCED_HARDWARE [0]. Building on that, I
then reviewed all of the code that touched any of several fields in the
FADT that the OSPM is supposed to ignore when ACPI is in Hardware Reduced
mode [1]. Any time there was a use of one of the fields to be ignored,
I evaluated whether or not the code was implementing Hardware Reduced
mode correctly. Similarly, for each the flags in the FADT flags field
that are to be ignored in Hardware Reduced mode, the kernel code was again
scanned for proper usage. The remainder of the patches are to fix all of
the situations I could find where the kernel would not behave correctly
in this ACPI mode.
These seem to work just fine on the RTSM model for ARMv7, both with and
without ACPI enabled, and with and without ACPI_REDUCED_HARDWARE enabled;
similarly for the FVP model for ARMv8. The patches for ACPI on ARM
hardware have been submitted elsewhere but they presume that reduced HW
mode is functioning correctly. In the meantime, there's no way I can think
of to test all possible scenarios so feedback would be greatly appreciated.
[0] List at https://wiki.linaro.org/LEG/Engineering/Kernel/ACPI/AcpiReducedHw#Section_5…
[1] Please see the ACPI Specification v5.0 for details on Hardware Reduced
mode (sections 3.11.1, 4.1, 5.2.9, at a minimum).
Changes for v4:
-- Given the current state of ACPICA, disable CONFIG_ACPI_REDUCED_HARDWARE
for use on anything other than ARM.
-- Replaced #ifdefs with run-time checking for hardware reduced mode,
whenever possible
Changes for v3:
-- Modified enabling ACPI_REDUCED_HARDWARE in ACPICA when using
kernel config item CONFIG_ACPI_REDUCED_HARDWARE; now consistent
with ACPICA code base where needed
-- Enable X86 for CONFIG_ACPI_REDUCED_HARDWARE
-- Minimize bus master reload patching
-- Remove unneeded patch for dmi_check_system() (was 4/6)
-- Correct the patch for removing unneeded map/unmap of FADT fields
Changes for v2:
-- Remove patch that was outside of reduced HW mode changes
-- Simplify CONFIG_ACPI_REDUCED_HARDWARE in Kconfig
-- Simplify use of CONFIG_ACPI_REDUCED_HARDWARE in #ifdefs
-- Ensure changelogs are present
-- Combine and simplify previous patches 8 & 10
Al Stone (5):
ACPI: introduce CONFIG_ACPI_REDUCED_HARDWARE to enable this ACPI mode
ACPI: bus master reload not supported in reduced HW mode
ACPI: HW reduced mode does not allow use of the FADT sci_interrupt
field
ACPI: in HW reduced mode, using FADT PM information is not allowed.
ACPI: do not map/unmap memory regions for FADT entries in reduced HW
mode
drivers/acpi/Kconfig | 8 ++++++++
drivers/acpi/bus.c | 30 ++++++++++++++++--------------
drivers/acpi/osl.c | 38 +++++++++++++++++++-------------------
drivers/acpi/pci_link.c | 2 ++
drivers/acpi/processor_idle.c | 14 ++++++++++++--
include/acpi/platform/aclinux.h | 6 ++++++
6 files changed, 63 insertions(+), 35 deletions(-)
--
1.8.3.1
Hi Rafael,
I know you asked me not to send any more patches before the earlier ones get
into kernel. I got to this as Nicolas Pitre required to send few CPUFreq patches
for ARM's big LITTLE In-Kernel-Switcher. And within linaro we have hacked these
bugs in a bad way..
Because of his dependency I am forced to send these.. These aren't introduced
recently and so they can be included in 3.13.
There are several problems/bugs in cpufreq-stats specially with cpufreq drivers
as modules and suspend/resume path. These are mentioned well in changelogs.
These are tested over my thinkpad (acpi-cpufreq) in following way:
[1] offline+online all CPUs except boot cpu in a while loop
[2] then do suspend resume
[3] repeat [1] and [2] several times.
No issues found..
Also tested on my exynos board:
- Added cpufreq_unregister/register while loop in exynos-cpufreq.c so that we
continuously register/unregister driver... Stats were working fine now..
- Compile cpufreq-stats as module and insert/remove it several times after
removing above hack (as that doesn't let linux boot :) )..
@Srivatsa: You also have fairly good idea of cpufreq now, so please give some
time to review this :)
@Nico: Can you remove the hacky code from IKS tree and test these instead to see
if we still have any issues?
--
viresh
Viresh Kumar (4):
cpufreq: stats: handle cpufreq_unregister_driver() and suspend/resume
properly
cpufreq: stats: remove hotplug notifiers
cpufreq: stats: free table and remove sysfs entry in a single routine
cpufreq: stats: create sysfs entries when cpufreq_stats is a module
drivers/cpufreq/cpufreq.c | 5 ++
drivers/cpufreq/cpufreq_stats.c | 109 ++++++++++++++++++----------------------
include/linux/cpufreq.h | 2 +
3 files changed, 55 insertions(+), 61 deletions(-)
--
1.7.12.rc2.18.g61b472e
Hi all,
Can anyone help on this...
Looking for latest linux version working with FastModel (A15x2 or A15x2_A7x2)
along with device tree and config file.
Many thanks
This patchset does a cleanup on the parameters passed from the function
'trigger_load_balance' to the underneath functions.
The cpu is passed as parameter to the different functions as well as the struct
rq but this one contains already the cpu information. Moreover, in the call
stack for these functions, we have the struct rq retrieved from the cpu, and then
the cpu retrieve from the struct rq, etc ...
The patchset unifies all these functions to have a struct rq parameter and
removes the pointless parameters.
-static inline int find_new_ilb(int call_cpu)
+static inline int find_new_ilb(void)
-static void nohz_balancer_kick(int cpu)
+static void nohz_balancer_kick(void)
-static void rebalance_domains(int cpu, enum cpu_idle_type idle)
+static void rebalance_domains(struct rq *rq, enum cpu_idle_type idle)
-static void nohz_idle_balance(int this_cpu, enum cpu_idle_type idle)
+static void nohz_idle_balance(struct rq *this_rq, enum cpu_idle_type idle)
-static inline int nohz_kick_needed(struct rq *rq, int cpu)
+static inline int nohz_kick_needed(struct rq *rq)
-static inline int on_null_domain(int cpu)
+static inline int on_null_domain(struct rq *rq)
Daniel Lezcano (7):
sched: reduce nohz_kick_needed parameters
sched: pass struct rq to on_null_domain function
sched: remove unused parameter for find_new_ilb
sched: remove unused parameter in nohz_balancer_kick function
sched: pass struct rq to rebalance_domains function
sched: pass struct rq to nohz_idle_balance function
sched: factor out on_null_domain check in trigger_load_balance
function
kernel/sched/fair.c | 45 ++++++++++++++++++++++-----------------------
1 file changed, 22 insertions(+), 23 deletions(-)
--
1.7.9.5
arm_big_little cpufreq driver is only used for ARM bigLITTLE platforms and hence
must be dependent on CONFIG_BIG_LITTLE.
This was highlighted by Russell earlier when he reported this issue:
drivers/built-in.o: In function `bL_cpufreq_set_rate':
powercap_sys.c:(.text+0x5ed9a0): undefined reference to `bL_switch_request_cb'
Reported-by: Russell King <linux(a)arm.linux.org.uk>
Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org>
---
drivers/cpufreq/Kconfig.arm | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index 456ba5e..3275e9c 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -4,7 +4,7 @@
config ARM_BIG_LITTLE_CPUFREQ
tristate "Generic ARM big LITTLE CPUfreq driver"
- depends on ARM && ARM_CPU_TOPOLOGY && HAVE_CLK
+ depends on ARM && BIG_LITTLE && ARM_CPU_TOPOLOGY && HAVE_CLK
select PM_OPP
help
This enables the Generic CPUfreq driver for ARM big.LITTLE platforms.
--
1.7.12.rc2.18.g61b472e
This introduces another routine cpufreq_notify_post_transition() which can be
used to send POSTCHANGE notification for new freq with or without both
{PRE|POST}CHANGE notifications for last freq. This is useful at multiple places,
specially for sending transition failure notifications.
Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org>
---
V1->V2:
- Not required to push it for 3.13 anymore and can go in 3.14.
- Rebased over following patchset as there were conflicts in unicore2 driver if
following patchset is applied first (which should be the case):
https://lkml.org/lkml/2013/10/30/553 (create cpufreq_generic_get() routine)
drivers/cpufreq/cpufreq.c | 14 ++++++++++++++
include/linux/cpufreq.h | 2 ++
2 files changed, 16 insertions(+)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 5e27def..3b877d4 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -338,6 +338,20 @@ void cpufreq_notify_transition(struct cpufreq_policy *policy,
}
EXPORT_SYMBOL_GPL(cpufreq_notify_transition);
+/* Do post notifications when there are chances that transition has failed */
+void cpufreq_notify_post_transition(struct cpufreq_policy *policy,
+ struct cpufreq_freqs *freqs, int transition_failed)
+{
+ cpufreq_notify_transition(policy, freqs, CPUFREQ_POSTCHANGE);
+ if (!transition_failed)
+ return;
+
+ swap(freqs->old, freqs->new);
+ cpufreq_notify_transition(policy, freqs, CPUFREQ_PRECHANGE);
+ cpufreq_notify_transition(policy, freqs, CPUFREQ_POSTCHANGE);
+}
+EXPORT_SYMBOL_GPL(cpufreq_notify_post_transition);
+
/*********************************************************************
* SYSFS INTERFACE *
diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
index 276e646..b26bfab 100644
--- a/include/linux/cpufreq.h
+++ b/include/linux/cpufreq.h
@@ -316,6 +316,8 @@ int cpufreq_unregister_notifier(struct notifier_block *nb, unsigned int list);
void cpufreq_notify_transition(struct cpufreq_policy *policy,
struct cpufreq_freqs *freqs, unsigned int state);
+void cpufreq_notify_post_transition(struct cpufreq_policy *policy,
+ struct cpufreq_freqs *freqs, int transition_failed);
#else /* CONFIG_CPU_FREQ */
static inline int cpufreq_register_notifier(struct notifier_block *nb,
--
1.7.12.rc2.18.g61b472e
__cpufreq_add_dev() can fail sometimes while we are resuming our system.
Currently we are clearing all sysfs nodes for cpufreq's failed policy as that
could make userspace unstable. But if we suspend/resume again, we should atleast
try to bring back those policies.
This patch fixes this issue by clearing fallback data on failure and trying to
allocate a new struct cpufreq_policy on second resume.
Reported-and-tested-by: Bjørn Mork <bjorn(a)mork.no>
Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org>
---
These are sent again (earlier sent as reply to emails), so that people can
give inputs if they have any.
Tested on my thinkpad T420.
drivers/cpufreq/cpufreq.c | 22 ++++++++++++++++++----
1 file changed, 18 insertions(+), 4 deletions(-)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 16d7b4a..0a48e71 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -1016,16 +1016,24 @@ static int __cpufreq_add_dev(struct device *dev, struct subsys_interface *sif,
read_unlock_irqrestore(&cpufreq_driver_lock, flags);
#endif
- if (frozen)
+ if (frozen) {
/* Restore the saved policy when doing light-weight init */
policy = cpufreq_policy_restore(cpu);
- else
+
+ /*
+ * As we failed to resume cpufreq core last time, lets try to
+ * create a new policy.
+ */
+ if (!policy)
+ frozen = false;
+ }
+
+ if (!frozen)
policy = cpufreq_policy_alloc();
if (!policy)
goto nomem_out;
-
/*
* In the resume path, since we restore a saved policy, the assignment
* to policy->cpu is like an update of the existing policy, rather than
@@ -1118,8 +1126,14 @@ err_get_freq:
if (cpufreq_driver->exit)
cpufreq_driver->exit(policy);
err_set_policy_cpu:
- if (frozen)
+ if (frozen) {
+ /*
+ * Clear fallback data as we should try to make things work on
+ * next suspend/resume
+ */
+ per_cpu(cpufreq_cpu_data_fallback, cpu) = NULL;
cpufreq_policy_put_kobj(policy);
+ }
cpufreq_policy_free(policy);
nomem_out:
--
1.7.12.rc2.18.g61b472e