Hi Gary,
Could you please try these two patches wrt
[Bug 1283532] [NEW] NO_HZ fails for BE
I've tested it on my arndale board with my kernel that
they fix cpu hotplug issue for arndale board. I do not have
RT linux setup, so would appreciate help in testing.
Thanks,
Victor
Victor Kamensky (2):
ARM: EXYNOS: Fix hotplug wfi instruction in BE case
ARM: EXYNOS: Fix hotplug BE image mon and hyp mode BE switch
arch/arm/mach-exynos/headsmp.S | 5 ++++-
arch/arm/mach-exynos/hotplug.c | 2 +-
2 files changed, 5 insertions(+), 2 deletions(-)
--
1.8.1.4
Hi Russell,
Please pull fixes for ARM Kprobes big-endian support.
It is reworked initial Ben's series for big endian support [1].
Dropped patches that are not directly related to kprobes.
Current set of patches is enough to have functional BE kprobes.
One ARM kprobe test fails on Cortex-A15 boards (TC2 and Keystone2 EVM),
while it passes on Pandaboard. The issue is not related to this series
and already present in v3.13-rc7.
[1] http://www.spinics.net/lists/arm-kernel/msg285210.html
--
Taras Kondratiuk
--->8
The following changes since commit 7e22e91102c6b9df7c4ae2168910e19d2bb14cd6:
Linux 3.13-rc8 (2014-01-12 17:04:18 +0700)
are available in the git repository at:
git://git.linaro.org/people/taras.kondratiuk/linux.git tags/for_russell/arm-be-kprobes
for you to fetch changes up to 1c2d814c019b63bf0778fc2d2fd54c6e44f1ab5d:
ARM: kprobes-test: Workaround GAS .align bug (2014-01-13 13:58:52 +0200)
----------------------------------------------------------------
Ben Dooks (4):
ARM: kprobes: fix instruction fetch order with <asm/opcodes.h>
ARM: kprobes-test: use <asm/opcodes.h> for instruction accesses
ARM: kprobes-test: use <asm/opcodes.h> for ARM instruction building
ARM: kprobes-test: use <asm/opcodes.h> for Thumb instruction building
Taras Kondratiuk (1):
ARM: kprobes-test: Workaround GAS .align bug
arch/arm/kernel/kprobes-common.c | 19 +-
arch/arm/kernel/kprobes-test-arm.c | 603 +++++++++++++++++-----------------
arch/arm/kernel/kprobes-test-thumb.c | 447 ++++++++++++-------------
arch/arm/kernel/kprobes-test.c | 13 +-
arch/arm/kernel/kprobes-test.h | 2 +-
arch/arm/kernel/kprobes-thumb.c | 20 +-
arch/arm/kernel/kprobes.c | 9 +-
7 files changed, 562 insertions(+), 551 deletions(-)
Hi Morten,
I have just read your scheduler slide in LCA2014, and have some questions
which want to confirm with you. Before that, I shall say it is an
impressive slide
that well state the importance why scheduler change would benefit the power.
As you may also know the data from ARM's spec for A15/A7 power/performance diff:
http://www.arm.com/files/downloads/big.LITTLE_Final.pdf
It shows one fact that even over one cpu, different tasks would shows different
performance and power difference, as I see the programs like Dhrystone/FDCT
shows different performance growth over A7 when running over A15.
So is it ok to get the cpu's power only by its current usage, like busy ratio?
And don't care for its running task's type?
I am not sure whether this is what your meaning presented in the slide.
That is to modeling the energy diff, and move task around if shows
energy benefit.
Is there any possible to also add task type impact into scheduler design?
Thanks,
Lei
Ideally, .driver_data field of struct cpufreq_frequency_table must not be used
by core at all. But during a recent change if its value is same as
CPUFREQ_BOOST_FREQ macro, then it is treated specially by core.
The value of this macro was set to ~2 earlier, i.e. 0xFFFFFFFD. In case some
driver is using this field for its own data and sets this field to -3, then with
two's complement that value will also become 0xFFFFFFFD.
To fix this issue, lets change value of this flag to a very uncommon value which
shouldn't be used by any driver unless they want to use BOOST feature.
Along with this update comments to make this more clear.
Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org>
---
Gautham/Vaidy: I hope this fixes the problem we discussed for your patchset.
include/linux/cpufreq.h | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
index c48e595..9f25d9d 100644
--- a/include/linux/cpufreq.h
+++ b/include/linux/cpufreq.h
@@ -455,12 +455,18 @@ extern struct cpufreq_governor cpufreq_gov_conservative;
* FREQUENCY TABLE HELPERS *
*********************************************************************/
+/* Special Values of .frequency field */
#define CPUFREQ_ENTRY_INVALID ~0
#define CPUFREQ_TABLE_END ~1
-#define CPUFREQ_BOOST_FREQ ~2
+/* Special Values of .driver_data field */
+#define CPUFREQ_BOOST_FREQ 0xABABABAB
struct cpufreq_frequency_table {
- unsigned int driver_data; /* driver specific data, not used by core */
+ /*
+ * driver specific data, not used by core unless it is set to
+ * CPUFREQ_BOOST_FREQ.
+ */
+ unsigned int driver_data;
unsigned int frequency; /* kHz - doesn't need to be in ascending
* order */
};
--
1.7.12.rc2.18.g61b472e
The mux driver is anomalous among all the serial drivers that can
define SUPPORT_SYSRQ because it can, with some configs, set
SUPPORT_SYSRQ when SERIAL_CORE_CONSOLE is not set.
Not only does this impose a pointless (but tiny) runtime overhead for
such configs but, more significantly, it adds needless complexity when
doing a code review to check for unexpected side effects of any
changes to the serial core.
This is (cross-)compile tested only because I do not have any PA-RISC
hardware.
Signed-off-by: Daniel Thompson <daniel.thompson(a)linaro.org>
---
drivers/tty/serial/mux.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/serial/mux.c b/drivers/tty/serial/mux.c
index 7fd6aaa..9b27d34 100644
--- a/drivers/tty/serial/mux.c
+++ b/drivers/tty/serial/mux.c
@@ -29,7 +29,7 @@
#include <asm/irq.h>
#include <asm/parisc-device.h>
-#ifdef CONFIG_MAGIC_SYSRQ
+#if defined(CONFIG_SERIAL_MUX_CONSOLE) && defined(CONFIG_MAGIC_SYSRQ)
#include <linux/sysrq.h>
#define SUPPORT_SYSRQ
#endif
--
1.9.0
This driver, like several others, uses the upper bits of the character
to track both real and dummy state. Unfortunately it neglects to mask
these bits properly when passing the character data around. This means
neither break detection nor sysrq character handling work correctly.
This patch adds the requires masking and has been tested to confirm
that it correctly handles magic sysrq sequences on ST's B2020 board.
Signed-off-by: Daniel Thompson <daniel.thompson(a)linaro.org>
---
drivers/tty/serial/st-asc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/serial/st-asc.c b/drivers/tty/serial/st-asc.c
index 21e6e84..dd3a96e 100644
--- a/drivers/tty/serial/st-asc.c
+++ b/drivers/tty/serial/st-asc.c
@@ -295,7 +295,7 @@ static void asc_receive_chars(struct uart_port *port)
status & ASC_STA_OE) {
if (c & ASC_RXBUF_FE) {
- if (c == ASC_RXBUF_FE) {
+ if (c == (ASC_RXBUF_FE | ASC_RXBUF_DUMMY_RX)) {
port->icount.brk++;
if (uart_handle_break(port))
continue;
@@ -325,7 +325,7 @@ static void asc_receive_chars(struct uart_port *port)
flag = TTY_FRAME;
}
- if (uart_handle_sysrq_char(port, c))
+ if (uart_handle_sysrq_char(port, c & 0xff))
continue;
uart_insert_char(port, c, ASC_RXBUF_DUMMY_OE, c & 0xff, flag);
--
1.9.0
This driver, like several others, uses the upper bits of the character
to track both real and dummy state. Unfortunately it neglects to mask
these bits properly when passing the character data around. This means
neither break detection nor sysrq character handling work correctly.
This patch adds the requires masking and has been tested to confirm
that it correctly handles magic sysrq sequences on ST's B2020 board.
Signed-off-by: Daniel Thompson <daniel.thompson(a)linaro.org>
---
drivers/tty/serial/st-asc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/serial/st-asc.c b/drivers/tty/serial/st-asc.c
index 21e6e84..dd3a96e 100644
--- a/drivers/tty/serial/st-asc.c
+++ b/drivers/tty/serial/st-asc.c
@@ -295,7 +295,7 @@ static void asc_receive_chars(struct uart_port *port)
status & ASC_STA_OE) {
if (c & ASC_RXBUF_FE) {
- if (c == ASC_RXBUF_FE) {
+ if (c == (ASC_RXBUF_FE | ASC_RXBUF_DUMMY_RX)) {
port->icount.brk++;
if (uart_handle_break(port))
continue;
@@ -325,7 +325,7 @@ static void asc_receive_chars(struct uart_port *port)
flag = TTY_FRAME;
}
- if (uart_handle_sysrq_char(port, c))
+ if (uart_handle_sysrq_char(port, c & 0xff))
continue;
uart_insert_char(port, c, ASC_RXBUF_DUMMY_OE, c & 0xff, flag);
--
1.9.0
CPUFreq core doesn't control value of .driver_data and this field is completely
driver specific. This can contain any value and not only indexes. For most of
the drivers, which aren't using this field, its value is zero. So, printing this
from core doesn't make any sense. Don't print it.
Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org>
---
drivers/cpufreq/freq_table.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/cpufreq/freq_table.c b/drivers/cpufreq/freq_table.c
index 8e54f97..f002272 100644
--- a/drivers/cpufreq/freq_table.c
+++ b/drivers/cpufreq/freq_table.c
@@ -36,8 +36,7 @@ int cpufreq_frequency_table_cpuinfo(struct cpufreq_policy *policy,
&& table[i].driver_data == CPUFREQ_BOOST_FREQ)
continue;
- pr_debug("table entry %u: %u kHz, %u driver_data\n",
- i, freq, table[i].driver_data);
+ pr_debug("table entry %u: %u kHz\n", i, freq);
if (freq < min_freq)
min_freq = freq;
if (freq > max_freq)
@@ -175,8 +174,8 @@ int cpufreq_frequency_table_target(struct cpufreq_policy *policy,
} else
*index = optimal.driver_data;
- pr_debug("target is %u (%u kHz, %u)\n", *index, table[*index].frequency,
- table[*index].driver_data);
+ pr_debug("target index is %u, freq is:%u kHz\n", *index,
+ table[*index].frequency);
return 0;
}
--
1.7.12.rc2.18.g61b472e
.driver_data field is only required to be filled if drivers want to preserve
some data in there which they can use according to the value of .frequency
field. But this driver isn't using this field at all, but just setting it equal
to the index value. Which isn't required. Fix it.
Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org>
---
drivers/cpufreq/ia64-acpi-cpufreq.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/cpufreq/ia64-acpi-cpufreq.c b/drivers/cpufreq/ia64-acpi-cpufreq.c
index 53c6ac6..f0d447d 100644
--- a/drivers/cpufreq/ia64-acpi-cpufreq.c
+++ b/drivers/cpufreq/ia64-acpi-cpufreq.c
@@ -275,7 +275,6 @@ acpi_cpufreq_cpu_init (
/* table init */
for (i = 0; i <= data->acpi_data.state_count; i++)
{
- data->freq_table[i].driver_data = i;
if (i < data->acpi_data.state_count) {
data->freq_table[i].frequency =
data->acpi_data.states[i].core_frequency * 1000;
--
1.7.12.rc2.18.g61b472e
Hi Thomas,
I am going through this piece of code to complete my 'cpusets.quiesce' work.
While going through code I accumulated these patches which are mostly code
cleanups and shouldn't have much functional change.
Thanks for applying yesterdays cleanups :)
Viresh Kumar (14):
hrtimer: replace 'tab' with 'space' after comma ','
hrtimer: Coalesce format fragments in printk()
hrtimer: call hrtimer_set_expires_range() from
hrtimer_set_expires_range_ns()
hrtimer: use base->index instead of basenum in switch_hrtimer_base()
hrtimer: no need to rewrite '1' to hrtimer_hres_enabled
hrtimer: don't rewrite same value to expires_next in
hrtimer_force_reprogram()
hrtimer: use base->hres_active directly instead of
hrtimer_hres_active()
hrtimer: remove dummy definition of hrtimer_force_reprogram()
hrtimer: don't check state of base->hres_active in
hrtimer_switch_to_hres()
hrtimer: remove clock_was_set_delayed() from hrtimer.h
hrtimer: remove active_bases field from struct hrtimer_cpu_base
hrtimer: don't emulate notifier call to initialize timer base
timer: simplify CPU_UP_PREPARE notifier code path
timer: don't emulate notifier call to initialize timer base
include/linux/hrtimer.h | 10 +---------
kernel/hrtimer.c | 40 ++++++++++++++--------------------------
kernel/timer.c | 12 ++----------
3 files changed, 17 insertions(+), 45 deletions(-)
--
1.7.12.rc2.18.g61b472e
Currently, KVM ARM/ARM64 only provides in-kernel emulation of Power State
and Coordination Interface (PSCI) v0.1.
This patchset aims at providing newer PSCI v0.2 for KVM ARM/ARM64 VCPUs
such that it does not break current KVM ARM/ARM64 ABI.
The user space tools (i.e. QEMU or KVMTOOL) will have to explicitly enable
KVM_ARM_VCPU_PSCI_0_2 feature using KVM_ARM_VCPU_INIT ioctl for providing
PSCI v0.2 to VCPUs.
Changlog:
V5:
- Have separate last patch to advertise KVM_CAP_ARM_PSCI_0_2
- Use kvm_psci_version() in kvm_psci_vcpu_on()
- Return ALREADY_ON for PSCI v0.2 CPU_ON if VCPU is not paused
- Remove per-VCPU suspend context
- As-per PSCI v0.2 spec, only current CPU can suspend itself
V4:
- Implement all mandatory functions required by PSCI v0.2
V3:
- Make KVM_ARM_VCPU_PSCI_0_2 feature experiementatl for now so that
it fails for user space till all mandatory PSCI v0.2 functions are
emulated by KVM ARM/ARM64
- Have separate patch for making KVM_ARM_VCPU_PSCI_0_2 feature available
to user space. This patch can be defferred for now
V2:
- Don't rename PSCI return values KVM_PSCI_RET_NI and KVM_PSCI_RET_INVAL
- Added kvm_psci_version() to get PSCI version available to VCPU
- Fixed grammer in Documentation/virtual/kvm/api.txt
V1:
- Initial RFC PATCH
Anup Patel (11):
KVM: Add capability to advertise PSCI v0.2 support
ARM/ARM64: KVM: Add base for PSCI v0.2 emulation
KVM: Documentation: Add info regarding KVM_ARM_VCPU_PSCI_0_2 feature
ARM/ARM64: KVM: Make kvm_psci_call() return convention more flexible
KVM: Add KVM_EXIT_SYSTEM_EVENT to user space API header
ARM/ARM64: KVM: Emulate PSCI v0.2 SYSTEM_OFF and SYSTEM_RESET
ARM/ARM64: KVM: Emulate PSCI v0.2 AFFINITY_INFO
ARM/ARM64: KVM: Emulate PSCI v0.2 MIGRATE_INFO_TYPE and related
functions
ARM/ARM64: KVM: Fix CPU_ON emulation for PSCI v0.2
ARM/ARM64: KVM: Emulate PSCI v0.2 CPU_SUSPEND
ARM/ARM64: KVM: Advertise KVM_CAP_ARM_PSCI_0_2 to user space
Documentation/virtual/kvm/api.txt | 17 +++
arch/arm/include/asm/kvm_host.h | 2 +-
arch/arm/include/asm/kvm_psci.h | 6 +-
arch/arm/include/uapi/asm/kvm.h | 35 +++++-
arch/arm/kvm/arm.c | 1 +
arch/arm/kvm/handle_exit.c | 10 +-
arch/arm/kvm/psci.c | 220 ++++++++++++++++++++++++++++++++++---
arch/arm64/include/asm/kvm_host.h | 2 +-
arch/arm64/include/asm/kvm_psci.h | 6 +-
arch/arm64/include/uapi/asm/kvm.h | 35 +++++-
arch/arm64/kvm/handle_exit.c | 10 +-
include/uapi/linux/kvm.h | 9 ++
12 files changed, 326 insertions(+), 27 deletions(-)
--
1.7.9.5
Add loop to prevent return from machine_power_off if
pm_power_off is null or does not halt the system.
This caused a panic during hibernation testing on Kirkwood
Openblocks A6 board.
Signed-off-by: Sebastian Capella <sebastian.capella(a)linaro.org>
Reported-by: Ezequiel Garcia <ezequiel.garcia(a)free-electrons.com>
Cc: Len Brown <len.brown(a)intel.com>
Cc: Pavel Machek <pavel(a)ucw.cz>
Cc: "Rafael J. Wysocki" <rjw(a)rjwysocki.net>
---
arch/arm/kernel/process.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/kernel/process.c b/arch/arm/kernel/process.c
index f58b723..6ffdc2c 100644
--- a/arch/arm/kernel/process.c
+++ b/arch/arm/kernel/process.c
@@ -217,6 +217,8 @@ void machine_power_off(void)
if (pm_power_off)
pm_power_off();
+ while (1)
+ cpu_relax();
}
/*
--
1.7.9.5
-- resend for correct linaro kernel ML, sorry!
Hi, all,
According to card 1213 https://cards.linaro.org/browse/CARD-1213, LSK need
backport thermal framework DT support. The feature summary is here:
https://lkml.org/lkml/2014/1/23/680
The LSK git tree: git://git.linaro.org/kernel/linux-linaro-stable.git
It should be equal to stable tree on this feature base.
Thanks for Broonie's comments! I remove few trivial bug fix patches, and
drop omap DT changes. The test passed build testing.
Any comments are appreciated!
Thanks
Alex
[PATCH 01/10] thermal: allow registering without .get_temp
[PATCH 02/10] thermal: hwmon: move hwmon support to single file
[PATCH 03/10] drivers: thermal: make usage of CONFIG_THERMAL_HWMON
[PATCH 04/10] thermal: introduce device tree parser
[PATCH 05/10] thermal: core: introduce
[PATCH 06/10] thermal: cpu_cooling: introduce
[PATCH 07/10] hwmon: lm75: expose to thermal fw via DT nodes
[PATCH 08/10] hwmon: tmp102: expose to thermal fw via DT nodes
[PATCH 09/10] MAINTAINERS: add thermal bindings entry in thermal
[PATCH 10/10] thermal: debug: add debug statement for core and
pm_wq work queue is used for runtime suspend/resume work, these
functions are not bound to run on specific CPUs. Having unbounded
type will reduce the waiting time.
Signed-off-by: Sanjay Singh Rawat <sanjay.rawat(a)linaro.org>
---
Need to test on a full runtime supported hardware
---
kernel/power/main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/power/main.c b/kernel/power/main.c
index 1d1bf63..8212528 100644
--- a/kernel/power/main.c
+++ b/kernel/power/main.c
@@ -622,7 +622,7 @@ EXPORT_SYMBOL_GPL(pm_wq);
static int __init pm_start_workqueue(void)
{
- pm_wq = alloc_workqueue("pm", WQ_FREEZABLE, 0);
+ pm_wq = alloc_workqueue("pm", WQ_FREEZABLE | WQ_UNBOUND, 0);
return pm_wq ? 0 : -ENOMEM;
}
--
1.7.10.4
On 03/25/2014 08:30 PM, Mark Brown wrote:
> On Tue, Mar 25, 2014 at 06:49:22PM +0800, Alex Shi wrote:
>> From: Eduardo Valentin <eduardo.valentin(a)ti.com>
>
> Dropping a bunch of irrelevant people/lists.
>
>> This patch changes a dtsi file to contain the thermal data
>> for MPU domain on OMAP4 and later SoCs. This data will
>> enable the passive cooling with CPUfreq cooling device
>> at 100C and the system will do a thermal shutdown at 125C.
>>
>> This thermal data can be reused across TI SoC devices.
>
> We probably shouldn't in general have DTS patches backported to LSK
> unless we're using them for testing - they aren't needed by people using
> the feature and may interfere with downstream users working on these
> boards who have their own modifications. Of course this is OMAP4 which
> is used on Panda so it might make sense since that's already part of our
> test coverage...
>
Yes, the testing show it is ok now. But you are right. it's better not
have this change when think of downstream users. I will remove all dts
patches.
--
Thanks
Alex
From: Mark Brown <broonie(a)linaro.org>
There is no real reason why we require transfers to have a completion and
the only user of the completion now checks to see if one has been provided
before using it so stop enforcing this. This makes it more convenient for
drivers to chain multiple asynchronous transfers together.
Signed-off-by: Mark Brown <broonie(a)linaro.org>
---
drivers/spi/spi.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index 26b331d27c35..121c43b5a8e8 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -1812,8 +1812,6 @@ static int __spi_validate(struct spi_device *spi, struct spi_message *message)
if (list_empty(&message->transfers))
return -EINVAL;
- if (!message->complete)
- return -EINVAL;
/* Half-duplex links include original MicroWire, and ones with
* only one data pin like SPI_3WIRE (switches direction) or where
--
1.9.1
This small series fixes issues found with the kprobes tests during
testing of Dave Long's latest ARM uprobe patches [1]. Whilst these fixes
are based on top of that series all the bugs are already present in the
kernel tree.
[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2014-March/238862.html
Contents:
Jon Medhurst (3):
ARM: kprobes: Prevent known test failures stopping other tests running
ARM: kprobes: Disallow instructions with PC and register specified shift
ARM: kprobes: Fix test code compilation errors for ARMv4 targets
arch/arm/kernel/kprobes-test-arm.c | 33 +++++++++++++++++++++------------
arch/arm/kernel/kprobes-test.c | 10 ++++++++++
arch/arm/kernel/probes-arm.c | 6 +++---
One of the comments in tick_handle_periodic() had 'when' instead of 'which' (My
guess :)). Fix it.
Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org>
---
kernel/time/tick-common.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/time/tick-common.c b/kernel/time/tick-common.c
index 20b2fe3..791a3a2 100644
--- a/kernel/time/tick-common.c
+++ b/kernel/time/tick-common.c
@@ -118,7 +118,7 @@ void tick_handle_periodic(struct clock_event_device *dev)
* to be sure we're using a real hardware clocksource.
* Otherwise we could get trapped in an infinite
* loop, as the tick_periodic() increments jiffies,
- * when then will increment time, posibly causing
+ * which then will increment time, posibly causing
* the loop to trigger again and again.
*/
if (timekeeping_valid_for_hres())
--
1.7.12.rc2.18.g61b472e
One of the comments in tick_handle_periodic() had 'when' instead of 'which' (My
guess :)). Fix it.
Also fix spelling mistake in 'Possible'.
Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org>
---
V1->V2: Fix spelling mistake of possible as well.
kernel/time/tick-common.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/time/tick-common.c b/kernel/time/tick-common.c
index 20b2fe3..0fec634 100644
--- a/kernel/time/tick-common.c
+++ b/kernel/time/tick-common.c
@@ -118,7 +118,7 @@ void tick_handle_periodic(struct clock_event_device *dev)
* to be sure we're using a real hardware clocksource.
* Otherwise we could get trapped in an infinite
* loop, as the tick_periodic() increments jiffies,
- * when then will increment time, posibly causing
+ * which then will increment time, possibly causing
* the loop to trigger again and again.
*/
if (timekeeping_valid_for_hres())
--
1.7.12.rc2.18.g61b472e
tick_handle_periodic() is calling ktime_add() at two places, first before the
infinite loop and then at the end of infinite loop. We can rearrange code a bit
to fix code duplication here.
It looks quite simple and shouldn't break anything, I guess :)
Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org>
---
kernel/time/tick-common.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/kernel/time/tick-common.c b/kernel/time/tick-common.c
index 20b2fe3..d610ae3 100644
--- a/kernel/time/tick-common.c
+++ b/kernel/time/tick-common.c
@@ -98,18 +98,19 @@ static void tick_periodic(int cpu)
void tick_handle_periodic(struct clock_event_device *dev)
{
int cpu = smp_processor_id();
- ktime_t next;
+ ktime_t next = dev->next_event;
tick_periodic(cpu);
if (dev->mode != CLOCK_EVT_MODE_ONESHOT)
return;
- /*
- * Setup the next period for devices, which do not have
- * periodic mode:
- */
- next = ktime_add(dev->next_event, tick_period);
for (;;) {
+ /*
+ * Setup the next period for devices, which do not have
+ * periodic mode:
+ */
+ next = ktime_add(next, tick_period);
+
if (!clockevents_program_event(dev, next, false))
return;
/*
@@ -123,7 +124,6 @@ void tick_handle_periodic(struct clock_event_device *dev)
*/
if (timekeeping_valid_for_hres())
tick_periodic(cpu);
- next = ktime_add(next, tick_period);
}
}
--
1.7.12.rc2.18.g61b472e
From: Mark Brown <broonie(a)linaro.org>
As a legacy of the way 32 bit ARM did things the topology code uses a null
topology map by default and then overwrites it by mapping cores with no
information to a cluster by themselves later. In order to make it simpler
to reset things as part of recovering from parse failures in firmware
information directly set this configuration on init. A core will always be
its own sibling so there should be no risk of confusion with firmware
provided information.
Signed-off-by: Mark Brown <broonie(a)linaro.org>
---
arch/arm64/kernel/topology.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c
index 3e06b0be4ec8..ff662b23af5f 100644
--- a/arch/arm64/kernel/topology.c
+++ b/arch/arm64/kernel/topology.c
@@ -43,9 +43,6 @@ static void update_siblings_masks(unsigned int cpuid)
* reset it to default behaviour
*/
pr_debug("CPU%u: No topology information configured\n", cpuid);
- cpuid_topo->core_id = 0;
- cpumask_set_cpu(cpuid, &cpuid_topo->core_sibling);
- cpumask_set_cpu(cpuid, &cpuid_topo->thread_sibling);
return;
}
@@ -87,9 +84,12 @@ void __init init_cpu_topology(void)
struct cpu_topology *cpu_topo = &cpu_topology[cpu];
cpu_topo->thread_id = -1;
- cpu_topo->core_id = -1;
+ cpu_topo->core_id = 0;
cpu_topo->cluster_id = -1;
+
cpumask_clear(&cpu_topo->core_sibling);
+ cpumask_set_cpu(cpu, &cpu_topo->core_sibling);
cpumask_clear(&cpu_topo->thread_sibling);
+ cpumask_set_cpu(cpu, &cpu_topo->thread_sibling);
}
}
--
1.9.1
This patchset was previously part of the larger tasks packing patchset [1].
I have splitted the latter in 3 different patchsets (at least) to make the
thing easier.
-configuration of sched_domain topology (this patchset)
-update and consolidation of cpu_power
-tasks packing algorithm
Based on Peter Z's proposal [2][3], this patchset modifies the way to configure
the sched_domain level in order to let architectures to add specific level like
the current BOOK level or the proposed power gating level for ARM architecture.
[1] https://lkml.org/lkml/2013/10/18/121
[2] https://lkml.org/lkml/2013/11/5/239
[3] https://lkml.org/lkml/2013/11/5/449
Change since v2:
- remove patch 1 as it has been already applied to metag tree for v3.15
- updates some commit messages
- add new flag description in TOPOLOGY_SD_FLAGS description
Change since v1:
- move sched_domains_curr_level back under #ifdef CONFIG_NUMA
- use function pointer to set flag instead of a plain value.
- add list of tunable flags in the commit message of patch 2
- add SD_SHARE_POWER_DOMAIN flag for powerpc's SMT level
Vincent Guittot (6):
sched: rework of sched_domain topology definition
sched: s390: create a dedicated topology table
sched: powerpc: create a dedicated topology table
sched: add a new SD_SHARE_POWERDOMAIN for sched_domain
sched: ARM: create a dedicated scheduler topology table
sched: powerpc: Add SD_SHARE_POWERDOMAIN for SMT level
arch/arm/kernel/topology.c | 26 +++++
arch/ia64/include/asm/topology.h | 24 ----
arch/powerpc/kernel/smp.c | 31 +++--
arch/s390/include/asm/topology.h | 13 +--
arch/s390/kernel/topology.c | 20 ++++
arch/tile/include/asm/topology.h | 33 ------
include/linux/sched.h | 49 +++++++-
include/linux/topology.h | 128 +++-----------------
kernel/sched/core.c | 244 ++++++++++++++++++++-------------------
9 files changed, 255 insertions(+), 313 deletions(-)
--
1.9.0
[Adding Linaro lists in cc as there are few people here working on power/thermal
stuff.]
On 24 March 2014 15:30, Lukasz Majewski <l.majewski(a)samsung.com> wrote:
>> On 4 March 2014 15:57, Lukasz Majewski <l.majewski(a)samsung.com> wrote:
> I think, that "LAB" name is with us for some time, so it would be a
> pity to discard it.
It doesn't matter with Mainline how you do naming initially for your code :)
We need to pick the right name now, and the decision should be made
now (after discussions obviously) :)
>> What about making it as simple as:
>> - changing the ondemand governor only instead of adding a new governor
>
> My goal is to not touch the ondemand code. It has matured, so I would
> like to leave it as it is.
Because the boost feature is already part of CPUFreq core, I think its
better if we enhance current governors to use it. So, I would like to
make this part of existing governors. Not only ondemand but maybe
conservative as well..
Also, I feel we maynot necessarily move this piece of code into cpufreq.
All you are doing is thermal management here :)
If we are sure we will not burn out our SoC (When many cores are idle),
run at max freq (if there is enough load of course :))..
And if there are chances that we might burn our chip (when very few
cores are idle), don't run on boost frequencies..
This is actually a 'cooling' device :)
Think of it this way: CPUFreq will provide a range of frequency which
SoC's can use. And then based on some conditions we may or may not
want to run on these frequencies.
@Zhang/Eduardo: Can we have your inputs here as well ?
This may look hard but we need to design things in the best possible
way for managing things better in future. Lets see what others have
to say on this.
Whenever we change the frequency of a CPU, we call the PRECHANGE and POSTCHANGE
notifiers. They must be serialized, i.e. PRECHANGE and POSTCHANGE notifiers
should strictly alternate, thereby preventing two different sets of PRECHANGE or
POSTCHANGE notifiers from interleaving arbitrarily.
The following examples illustrate why this is important:
Scenario 1:
-----------
A thread reading the value of cpuinfo_cur_freq, will call
__cpufreq_cpu_get()->cpufreq_out_of_sync()->cpufreq_notify_transition()
The ondemand governor can decide to change the frequency of the CPU at the same
time and hence it can end up sending the notifications via ->target().
If the notifiers are not serialized, the following sequence can occur:
- PRECHANGE Notification for freq A (from cpuinfo_cur_freq)
- PRECHANGE Notification for freq B (from target())
- Freq changed by target() to B
- POSTCHANGE Notification for freq B
- POSTCHANGE Notification for freq A
We can see from the above that the last POSTCHANGE Notification happens for freq
A but the hardware is set to run at freq B.
Where would we break then?: adjust_jiffies() in cpufreq.c & cpufreq_callback()
in arch/arm/kernel/smp.c (which also adjusts the jiffies). All the
loops_per_jiffy calculations will get messed up.
Scenario 2:
-----------
The governor calls __cpufreq_driver_target() to change the frequency. At the
same time, if we change scaling_{min|max}_freq from sysfs, it will end up
calling the governor's CPUFREQ_GOV_LIMITS notification, which will also call
__cpufreq_driver_target(). And hence we end up issuing concurrent calls to
->target().
Typically, platforms have the following logic in their ->target() routines:
(Eg: cpufreq-cpu0, omap, exynos, etc)
A. If new freq is more than old: Increase voltage
B. Change freq
C. If new freq is less than old: decrease voltage
Now, if the two concurrent calls to ->target() are X and Y, where X is trying to
increase the freq and Y is trying to decrease it, we get the following race
condition:
X.A: voltage gets increased for larger freq
Y.A: nothing happens
Y.B: freq gets decreased
Y.C: voltage gets decreased
X.B: freq gets increased
X.C: nothing happens
Thus we can end up setting a freq which is not supported by the voltage we have
set. That will probably make the clock to the CPU unstable and the system might
not work properly anymore.
This patchset introduces a new set of routines cpufreq_freq_transition_begin()
and cpufreq_freq_transition_end(), which will guarantee that calls to frequency
transition routines are serialized. Later patches force other drivers to use
these new routines.
V4: https://lkml.org/lkml/2014/3/21/23
V4->V5:
- Replaced false with 0 as the variable was of int type instead of bool.
- There were some discussions about requirement of a barrier, but it looks like
overkill for now. So, leaving that unless we have a real problem.
Srivatsa S. Bhat (1):
cpufreq: Make sure frequency transitions are serialized
Viresh Kumar (2):
cpufreq: Convert existing drivers to use
cpufreq_freq_transition_{begin|end}
cpufreq: Make cpufreq_notify_transition &
cpufreq_notify_post_transition static
drivers/cpufreq/cpufreq-nforce2.c | 4 +--
drivers/cpufreq/cpufreq.c | 52 +++++++++++++++++++++++++++++-------
drivers/cpufreq/exynos5440-cpufreq.c | 4 +--
drivers/cpufreq/gx-suspmod.c | 4 +--
drivers/cpufreq/integrator-cpufreq.c | 4 +--
drivers/cpufreq/longhaul.c | 4 +--
drivers/cpufreq/pcc-cpufreq.c | 4 +--
drivers/cpufreq/powernow-k6.c | 4 +--
drivers/cpufreq/powernow-k7.c | 4 +--
drivers/cpufreq/powernow-k8.c | 4 +--
drivers/cpufreq/s3c24xx-cpufreq.c | 4 +--
drivers/cpufreq/sh-cpufreq.c | 4 +--
drivers/cpufreq/unicore2-cpufreq.c | 4 +--
include/linux/cpufreq.h | 12 ++++++---
14 files changed, 76 insertions(+), 36 deletions(-)
--
1.7.12.rc2.18.g61b472e
During suspend, we first stop governors and then suspend cpufreq drivers and
resume must be exactly opposite of that. i.e. resume drivers first and then
start governors.
But the current code in resume enables governors first and then resume drivers.
Fix it be changing code sequence there.
Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org>
---
For 3.15-rc2 ..
drivers/cpufreq/cpufreq.c | 9 ++++-----
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 3aa7a7a..d8d6bc9 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -1652,14 +1652,13 @@ void cpufreq_resume(void)
cpufreq_suspended = false;
list_for_each_entry(policy, &cpufreq_policy_list, policy_list) {
- if (__cpufreq_governor(policy, CPUFREQ_GOV_START)
+ if (cpufreq_driver->resume && cpufreq_driver->resume(policy))
+ pr_err("%s: Failed to resume driver: %p\n", __func__,
+ policy);
+ else if (__cpufreq_governor(policy, CPUFREQ_GOV_START)
|| __cpufreq_governor(policy, CPUFREQ_GOV_LIMITS))
pr_err("%s: Failed to start governor for policy: %p\n",
__func__, policy);
- else if (cpufreq_driver->resume
- && cpufreq_driver->resume(policy))
- pr_err("%s: Failed to resume driver: %p\n", __func__,
- policy);
/*
* schedule call cpufreq_update_policy() for boot CPU, i.e. last
--
1.7.12.rc2.18.g61b472e