From: Mark Brown <broonie(a)linaro.org>
The expected semantic for something expressed as a tolerance is that it
should deliver the specified value with some deviation allowed but this
is not what set_voltage_tol() currently does. Instead it just passes
the maximum possible range to set_voltage() which will typically result
in a voltage aimed at lower than the target voltage.
Instead first try to set a voltage between the target voltage and the
upper limit, then fall back on the full range. This will be much more
robust against physical variation in systems and makes the API behave
more like users would expect.
Signed-off-by: Mark Brown <broonie(a)linaro.org>
---
include/linux/regulator/consumer.h | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/include/linux/regulator/consumer.h b/include/linux/regulator/consumer.h
index 3a76389..3610df8 100644
--- a/include/linux/regulator/consumer.h
+++ b/include/linux/regulator/consumer.h
@@ -369,8 +369,11 @@ static inline int regulator_count_voltages(struct regulator *regulator)
static inline int regulator_set_voltage_tol(struct regulator *regulator,
int new_uV, int tol_uV)
{
- return regulator_set_voltage(regulator,
- new_uV - tol_uV, new_uV + tol_uV);
+ if (regulator_set_voltage(regulator, new_uV, new_uV + tol_uV) == 0)
+ return 0;
+ else
+ return regulator_set_voltage(regulator,
+ new_uV - tol_uV, new_uV + tol_uV);
}
static inline int regulator_is_supported_voltage_tol(struct regulator *regulator,
--
1.8.3.2
Hi,
I'm looking into migrating the kernel patches for the Nanos G20 to
something more recent (3.10) from 2.6.35.7 which it is currently.
It's only 241 lines of code (not counting empty lines) so it can't be
that much work :-)
The board code is in the mach-at91 tree, processor: ARM926EJ-S rev 5
(v5l).
I applied the patch to the 3.10 code and apart from small fixes to
Kconfig and Makefile, it applied cleanly.
But before I continue this work: do you people know this board/cpu? Is
it maybe already in some form in the tree?
regards
Folkert van Heusden
--
MultiTail è uno flexible tool per seguire di logfiles e effettuazione
di commissioni. Feltrare, provedere da colore, merge, 'diff-view',
etc. http://www.vanheusden.com/multitail/
----------------------------------------------------------------------
Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com
From: Mark Brown <broonie(a)linaro.org>
Many regulators have several linear ranges of selector with different
step sizes, for example offering better resolution at lower voltages.
Provide regulator_{map,list}_voltage_linear_range() allowing these
regulators to use generic code. To do so a table of regulator_linear_range
structs needs to be pointed to from the descriptor.
This was inspired by similar code included in a driver submission from
Chao Xie and Yi Zhang at Marvell.
Signed-off-by: Mark Brown <broonie(a)linaro.org>
---
drivers/regulator/core.c | 87 ++++++++++++++++++++++++++++++++++++++++
include/linux/regulator/driver.h | 25 ++++++++++++
2 files changed, 112 insertions(+)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 288c75a..e8604be 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -2079,6 +2079,43 @@ int regulator_list_voltage_linear(struct regulator_dev *rdev,
EXPORT_SYMBOL_GPL(regulator_list_voltage_linear);
/**
+ * regulator_list_voltage_linear_range - List voltages for linear ranges
+ *
+ * @rdev: Regulator device
+ * @selector: Selector to convert into a voltage
+ *
+ * Regulators with a series of simple linear mappings between voltages
+ * and selectors can set linear_ranges in the regulator descriptor and
+ * then use this function as their list_voltage() operation,
+ */
+int regulator_list_voltage_linear_range(struct regulator_dev *rdev,
+ unsigned int selector)
+{
+ const struct regulator_linear_range *range;
+ int i;
+
+ if (!rdev->desc->n_linear_ranges) {
+ BUG_ON(!rdev->desc->n_linear_ranges);
+ return -EINVAL;
+ }
+
+ for (i = 0; i < rdev->desc->n_linear_ranges; i++) {
+ range = &rdev->desc->linear_ranges[i];
+
+ if (!(selector >= range->min_sel &&
+ selector <= range->max_sel))
+ continue;
+
+ selector -= range->min_sel;
+
+ return range->min_uV + (range->uV_step * selector);
+ }
+
+ return -EINVAL;
+}
+EXPORT_SYMBOL_GPL(regulator_list_voltage_linear_range);
+
+/**
* regulator_list_voltage_table - List voltages with table based mapping
*
* @rdev: Regulator device
@@ -2368,6 +2405,56 @@ int regulator_map_voltage_linear(struct regulator_dev *rdev,
}
EXPORT_SYMBOL_GPL(regulator_map_voltage_linear);
+/**
+ * regulator_map_voltage_linear - map_voltage() for multiple linear ranges
+ *
+ * @rdev: Regulator to operate on
+ * @min_uV: Lower bound for voltage
+ * @max_uV: Upper bound for voltage
+ *
+ * Drivers providing linear_ranges in their descriptor can use this as
+ * their map_voltage() callback.
+ */
+int regulator_map_voltage_linear_range(struct regulator_dev *rdev,
+ int min_uV, int max_uV)
+{
+ const struct regulator_linear_range *range;
+ int ret = -EINVAL;
+ int voltage, i;
+
+ if (!rdev->desc->n_linear_ranges) {
+ BUG_ON(!rdev->desc->n_linear_ranges);
+ return -EINVAL;
+ }
+
+ for (i = 0; i < rdev->desc->n_linear_ranges; i++) {
+ range = &rdev->desc->linear_ranges[i];
+
+ if (!(min_uV <= range->max_uV && max_uV >= range->min_uV))
+ continue;
+
+ if (min_uV <= range->min_uV)
+ min_uV = range->min_uV;
+
+ ret = DIV_ROUND_UP(min_uV - range->min_uV, range->uV_step);
+ if (ret < 0)
+ return ret;
+
+ break;
+ }
+
+ if (i == rdev->desc->n_linear_ranges)
+ return -EINVAL;
+
+ /* Map back into a voltage to verify we're still in bounds */
+ voltage = rdev->desc->ops->list_voltage(rdev, ret);
+ if (voltage < min_uV || voltage > max_uV)
+ return -EINVAL;
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(regulator_map_voltage_linear_range);
+
static int _regulator_do_set_voltage(struct regulator_dev *rdev,
int min_uV, int max_uV)
{
diff --git a/include/linux/regulator/driver.h b/include/linux/regulator/driver.h
index 6700cc9..67e13aa 100644
--- a/include/linux/regulator/driver.h
+++ b/include/linux/regulator/driver.h
@@ -40,6 +40,24 @@ enum regulator_status {
};
/**
+ * Specify a range of voltages for regulator_map_linar_range() and
+ * regulator_list_linear_range().
+ *
+ * @min_uV: Lowest voltage in range
+ * @max_uV: Highest voltage in range
+ * @min_sel: Lowest selector for range
+ * @max_sel: Highest selector for range
+ * @uV_step: Step size
+ */
+struct regulator_linear_range {
+ unsigned int min_uV;
+ unsigned int max_uV;
+ unsigned int min_sel;
+ unsigned int max_sel;
+ unsigned int uV_step;
+};
+
+/**
* struct regulator_ops - regulator operations.
*
* @enable: Configure the regulator as enabled.
@@ -223,6 +241,9 @@ struct regulator_desc {
unsigned int linear_min_sel;
unsigned int ramp_delay;
+ const struct regulator_linear_range *linear_ranges;
+ int n_linear_ranges;
+
const unsigned int *volt_table;
unsigned int vsel_reg;
@@ -326,10 +347,14 @@ int regulator_mode_to_status(unsigned int);
int regulator_list_voltage_linear(struct regulator_dev *rdev,
unsigned int selector);
+int regulator_list_voltage_linear_range(struct regulator_dev *rdev,
+ unsigned int selector);
int regulator_list_voltage_table(struct regulator_dev *rdev,
unsigned int selector);
int regulator_map_voltage_linear(struct regulator_dev *rdev,
int min_uV, int max_uV);
+int regulator_map_voltage_linear_range(struct regulator_dev *rdev,
+ int min_uV, int max_uV);
int regulator_map_voltage_iterate(struct regulator_dev *rdev,
int min_uV, int max_uV);
int regulator_map_voltage_ascend(struct regulator_dev *rdev,
--
1.8.3.1
Commit 7c30ed ("cpufreq: make sure frequency transitions are serialized")
interacts poorly with systems that have a single core freqency for all
cores. On such systems we have a single policy for all cores with
several CPUs. When we do a frequency transition the governor calls the
pre and post change notifiers which causes cpufreq_notify_transition()
per CPU. Since the policy is the same for all of them all CPUs after
the first and the warnings added are generated by checking a per-policy
flag the warnings will be triggered for all cores after the first.
Fix this by allowing notifier to be called for n times. Where n is the number of
cpus in policy->cpus.
Reported-and-Tested-by: Mark Brown <broonie(a)linaro.org>
Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org>
---
Hi Rafael,
This is a fix for 3.11.
drivers/cpufreq/cpufreq.c | 7 ++++---
include/linux/cpufreq.h | 2 +-
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index b557503..b7bda8d 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -312,11 +312,12 @@ static void __cpufreq_notify_transition(struct cpufreq_policy *policy,
switch (state) {
case CPUFREQ_PRECHANGE:
- if (WARN(policy->transition_ongoing,
+ if (WARN(policy->transition_ongoing ==
+ cpumask_weight(policy->cpus),
"In middle of another frequency transition\n"))
return;
- policy->transition_ongoing = true;
+ policy->transition_ongoing++;
/* detect if the driver reported a value as "old frequency"
* which is not equal to what the cpufreq core thinks is
@@ -341,7 +342,7 @@ static void __cpufreq_notify_transition(struct cpufreq_policy *policy,
"No frequency transition in progress\n"))
return;
- policy->transition_ongoing = false;
+ policy->transition_ongoing--;
adjust_jiffies(CPUFREQ_POSTCHANGE, freqs);
pr_debug("FREQ: %lu - CPU: %lu", (unsigned long)freqs->new,
diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
index 4d7390b..90d5a15 100644
--- a/include/linux/cpufreq.h
+++ b/include/linux/cpufreq.h
@@ -119,7 +119,7 @@ struct cpufreq_policy {
struct kobject kobj;
struct completion kobj_unregister;
- bool transition_ongoing; /* Tracks transition status */
+ int transition_ongoing; /* Tracks transition status */
};
#define CPUFREQ_ADJUST (0)
--
1.7.12.rc2.18.g61b472e
Hi all,
Just wanted to make sure everyone interested in virtualization
was aware that we are bootstrapping a VIRTIO Technical Committee over at
OASIS. All welcome!
http://www.oasis-open.org/committees/virtio
Cheers,
Rusty.
Enable the Versatile Express voltage regulators by default.
This should work on all verstatile express platforms and not enabling it
prevents a defconfig'ed kernel from using the SD card controller on the
qemu emulated platform, which is unfortunate for first-time casual
users.
Cc: Peter Maydell <peter.maydell(a)linaro.org>
Signed-off-by: Christoffer Dall <christoffer.dall(a)linaro.org>
---
arch/arm/configs/vexpress_defconfig | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/configs/vexpress_defconfig b/arch/arm/configs/vexpress_defconfig
index f2de51f..17104d9 100644
--- a/arch/arm/configs/vexpress_defconfig
+++ b/arch/arm/configs/vexpress_defconfig
@@ -138,3 +138,6 @@ CONFIG_DEBUG_LL=y
CONFIG_EARLY_PRINTK=y
# CONFIG_CRYPTO_ANSI_CPRNG is not set
# CONFIG_CRYPTO_HW is not set
+CONFIG_REGULATOR=y
+CONFIG_REGULATOR_FIXED_VOLTAGE=y
+CONFIG_REGULATOR_VEXPRESS=y
--
1.7.9.5
From: Naresh Bhat <naresh.bhat(a)linaro.org>
CC drivers/acpi/fan.o
drivers/acpi/fan.c: In function ‘fan_get_cur_state’:
drivers/acpi/fan.c:96:9: warning: ‘acpi_state’ may be used uninitialized in this function [-Wuninitialized]
---
drivers/acpi/fan.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/acpi/fan.c b/drivers/acpi/fan.c
index f815da8..f961435 100644
--- a/drivers/acpi/fan.c
+++ b/drivers/acpi/fan.c
@@ -84,7 +84,7 @@ static int fan_get_cur_state(struct thermal_cooling_device *cdev, unsigned long
{
struct acpi_device *device = cdev->devdata;
int result;
- int acpi_state;
+ int acpi_state = ACPI_STATE_D0;
if (!device)
return -EINVAL;
--
1.7.9.5
On 10 October 2012 19:37, Viresh Kumar <viresh.kumar(a)linaro.org> wrote:
> On 10 October 2012 19:14, Sudeep KarkadaNagesha
> <Sudeep.KarkadaNagesha(a)arm.com> wrote:
>> Here is my understanding on this patch. This change is closely related
>> to ACPI cpufreq driver(used mostly on Intel cores). This change was
>> introduced to keep track of the related cpus as returned by ACPI
>> firmware along with affected cpus as imposed by SW. I don't understand
>> the exact difference in Intel cores.
>> I believe it's just for tracking and not used much in the driver.
>
> Then i believe we shouldn't fill the related_cpus field for ARM cores. As anyway
> the show_related_cpus will pick affected cpus in that case.
Ahh, I was searching for something in my Archives and found this old
unanswered mail. As I have understood the difference between between
these two variables (affected and related cpus) now until this happened:
951fc5f4 (in v3.9). I thought it would be good to bury the actual answers
somewhere in Archives so that somebody looking for the answer can find
it easily.
What it was:
Affected CPUs: List of CPUs which share clock domain and s/w was responsible
to managing these.
Related CPUs: List of CPUs which share clock domain and only h/w was
responsible for managing these.
What do we mean by software and hardware managed stuff?
It was specific for acpi-cpufreq driver and nobody else :)
The firmware below kernel layer for hardware using this driver wanted to
manage cpus (sharing clock domain) by itself. i.e. It wanted the actual freq
request to go to it, it will then pick the highest freq requested for a clock
domain and set it for all cpus under policy->cpus. But kernel wouldn't know
these details at all. CPUFreq core would think that these cores don't
actually share clock line and so are independent.
Then there were some user space applications (like DVFS controllers),
which wanted to know the exact hardware coordination details rather than
what is present with cpufreq core. And so related_cpus was created for
them with this commit: e8628dd06d66f2e3965ec9742029b401d63434f1
related_cpus wasn't used in making kernel decisions at all and was only
for the applications who want to know exact hardware details.
As it didn't make sense to keep acpi-cpufreq specific stuff in CPUFreq core,
it was eventually moved into acpi-cpufreq driver with the name:
freqdomain_cpus in 3.11. related_cpus was kept in kernel but its meaning
is now changed.
affected_cpus: List of Online CPUs that require software coordination
of frequency.
related_cpus: List of Online + Offline CPUs that need software
coordination of frequency.
--
viresh
There has long been a syntax problem in iop3xx_i2c_wait_event() which
has been somehow hidden by the macros in <linux/wait.h>. After some
recent cleanup/rework of the wait_event_* helpers, the bug has come
out from hiding and now results in build failure:
/work/kernel/next/drivers/i2c/busses/i2c-iop3xx.c: In function 'iop3xx_i2c_wait_event':
/work/kernel/next/drivers/i2c/busses/i2c-iop3xx.c:176:143: error: expected ')' before ';' token
/work/kernel/next/drivers/i2c/busses/i2c-iop3xx.c:176:157: error: expected ')' before ';' token
/work/kernel/next/drivers/i2c/busses/i2c-iop3xx.c:176:213: error: expected ')' before ';' token
/work/kernel/next/drivers/i2c/busses/i2c-iop3xx.c:176:291: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement]
/work/kernel/next/drivers/i2c/busses/i2c-iop3xx.c:176:551: error: expected ')' before ';' token
/work/kernel/next/drivers/i2c/busses/i2c-iop3xx.c:176:565: error: expected ')' before ';' token
/work/kernel/next/drivers/i2c/busses/i2c-iop3xx.c:176:764: error: expected ')' before ';' token
/work/kernel/next/drivers/i2c/busses/i2c-iop3xx.c:176:778: error: expected ')' b
Fix by removing stray ';'
Signed-off-by: Kevin Hilman <khilman(a)linaro.org>
---
Discovered in new build failure of iop32xx_defconfig with next-20130628
drivers/i2c/busses/i2c-iop3xx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-iop3xx.c b/drivers/i2c/busses/i2c-iop3xx.c
index bc99333..dd24aa0 100644
--- a/drivers/i2c/busses/i2c-iop3xx.c
+++ b/drivers/i2c/busses/i2c-iop3xx.c
@@ -176,7 +176,7 @@ iop3xx_i2c_wait_event(struct i2c_algo_iop3xx_data *iop3xx_adap,
interrupted = wait_event_interruptible_timeout (
iop3xx_adap->waitq,
(done = compare( sr = iop3xx_i2c_get_srstat(iop3xx_adap) ,flags )),
- 1 * HZ;
+ 1 * HZ
);
if ((rc = iop3xx_i2c_error(sr)) < 0) {
*status = sr;
--
1.8.3
From: Naresh Bhat <naresh.bhat(a)linaro.org>
CC drivers/acpi/fan.o
drivers/acpi/fan.c: In function ‘fan_get_cur_state’:
drivers/acpi/fan.c:96:9: warning: ‘acpi_state’ may be used uninitialized in this function [-Wuninitialized]
---
drivers/acpi/fan.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/acpi/fan.c b/drivers/acpi/fan.c
index f815da8..f61f7fd 100644
--- a/drivers/acpi/fan.c
+++ b/drivers/acpi/fan.c
@@ -84,7 +84,7 @@ static int fan_get_cur_state(struct thermal_cooling_device *cdev, unsigned long
{
struct acpi_device *device = cdev->devdata;
int result;
- int acpi_state;
+ int acpi_state = 0;
if (!device)
return -EINVAL;
--
1.7.9.5
PRECHANGE and POSTCHANGE notifiers must be called in groups, i.e either both
should be called or both shouldn't be.
In case we have started PRECHANGE notifier and found an error, we must call
POSTCHANGE notifier with freqs.new = freqs.old to guarantee that sequence of
calling notifiers is complete.
This isn't obeyed by many of the drivers and core wasn't forcing it.
This patchset first fixes all the driver to follow it strictly and then adds
some protection against this. Now, we keep track of the last transaction and see
if something went wrong.
Last patch is intentionally kept towards the end, so that git bisect still works
well for all the faulty drivers.
This is pushed here and a pull request for 3.11 would be sent after few days.
git://git.linaro.org/people/vireshk/linux.git cpufreq-fix-notification
Viresh Kumar (13):
cpufreq: acpi: call CPUFREQ_POSTCHANGE notfier in error cases
cpufreq: arm-big-little: call CPUFREQ_POSTCHANGE notfier in error
cases
cpufreq: davinci: call CPUFREQ_POSTCHANGE notfier in error cases
cpufreq: dbx500: call CPUFREQ_POSTCHANGE notfier in error cases
cpufreq: e_powersave: call CPUFREQ_POSTCHANGE notfier in error cases
cpufreq: exynos: call CPUFREQ_POSTCHANGE notfier in error cases
cpufreq: imx6q: call CPUFREQ_POSTCHANGE notfier in error cases
cpufreq: omap: call CPUFREQ_POSTCHANGE notfier in error cases
cpufreq: pcc: call CPUFREQ_POSTCHANGE notfier in error cases
cpufreq: powernow-k8: call CPUFREQ_POSTCHANGE notfier in error cases
cpufreq: s3c64xx: call CPUFREQ_POSTCHANGE notfier in error cases
cpufreq: tegra: call CPUFREQ_POSTCHANGE notfier in error cases
cpufreq: make sure frequency transitions are serialized
drivers/cpufreq/acpi-cpufreq.c | 6 ++++--
drivers/cpufreq/arm_big_little.c | 4 +---
drivers/cpufreq/cpufreq.c | 9 +++++++++
drivers/cpufreq/davinci-cpufreq.c | 3 +++
drivers/cpufreq/dbx500-cpufreq.c | 4 ++--
drivers/cpufreq/e_powersaver.c | 3 +++
drivers/cpufreq/exynos-cpufreq.c | 10 ++++++++--
drivers/cpufreq/imx6q-cpufreq.c | 17 +++++++++++------
drivers/cpufreq/omap-cpufreq.c | 6 +++---
drivers/cpufreq/pcc-cpufreq.c | 2 ++
drivers/cpufreq/powernow-k8.c | 6 +++---
drivers/cpufreq/s3c64xx-cpufreq.c | 8 ++++++--
drivers/cpufreq/tegra-cpufreq.c | 4 ++--
13 files changed, 57 insertions(+), 25 deletions(-)
--
1.7.12.rc2.18.g61b472e
From: Naresh Bhat <naresh.bhat(a)linaro.org>
CC drivers/acpi/fan.o
drivers/acpi/fan.c: In function ‘fan_get_cur_state’:
drivers/acpi/fan.c:96:9: warning: ‘acpi_state’ may be used uninitialized in this function [-Wuninitialized]
---
drivers/acpi/fan.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/acpi/fan.c b/drivers/acpi/fan.c
index f815da8..f61f7fd 100644
--- a/drivers/acpi/fan.c
+++ b/drivers/acpi/fan.c
@@ -84,7 +84,7 @@ static int fan_get_cur_state(struct thermal_cooling_device *cdev, unsigned long
{
struct acpi_device *device = cdev->devdata;
int result;
- int acpi_state;
+ int acpi_state = 0;
if (!device)
return -EINVAL;
--
1.7.9.5
From: "David A. Long" <dave.long(a)linaro.org>
This patch series adds basic uprobes support to ARM. It is based on patches
developed earlier by Rabin Vincent. That approach of adding special cases into
the kprobes instruction parsing code was not well received. This approach
separates the ARM instruction parsing code in kprobes out into a separate set
of functions which can be used by both kprobes and uprobes. Both kprobes and
uprobes then provide their own semantic action tables to process the results of
the parsing.
One regression bug fix is still in progress on this, and some more definitions
may be moved from kprobes*.h files into more generic include files. However,
at this point feedback on the basic approach would be appreciated.
These patches are based on v3.10-rc7
David A. Long (3):
uprobes: move function declarations out of arch
ARM: Separate kprobes instruction parsing into routines
ARM: add uprobes support
Rabin Vincent (4):
uprobes: allow ignoring of probe hits
uprobes: allow arch access to xol slot
uprobes: allow arch-specific initialization
uprobes: add arch write opcode hook
arch/arm/Kconfig | 4 +
arch/arm/include/asm/kprobes.h | 17 +-
arch/arm/include/asm/probes.h | 23 ++
arch/arm/include/asm/ptrace.h | 6 +
arch/arm/include/asm/thread_info.h | 5 +-
arch/arm/include/asm/uprobes.h | 34 ++
arch/arm/kernel/Makefile | 3 +-
arch/arm/kernel/kprobes-arm.c | 495 ++++++-----------------------
arch/arm/kernel/kprobes-common.c | 260 +---------------
arch/arm/kernel/kprobes-thumb.c | 31 +-
arch/arm/kernel/kprobes.c | 7 +-
arch/arm/kernel/kprobes.h | 51 +--
arch/arm/kernel/probes-arm.h | 66 ++++
arch/arm/kernel/probes.c | 624 +++++++++++++++++++++++++++++++++++++
arch/arm/kernel/signal.c | 4 +
arch/arm/kernel/uprobes-arm.c | 220 +++++++++++++
arch/arm/kernel/uprobes.c | 203 ++++++++++++
arch/arm/kernel/uprobes.h | 25 ++
arch/powerpc/include/asm/uprobes.h | 1 -
arch/x86/include/asm/uprobes.h | 7 -
include/linux/uprobes.h | 17 +
kernel/events/uprobes.c | 54 +++-
22 files changed, 1426 insertions(+), 731 deletions(-)
create mode 100644 arch/arm/include/asm/probes.h
create mode 100644 arch/arm/include/asm/uprobes.h
create mode 100644 arch/arm/kernel/probes-arm.h
create mode 100644 arch/arm/kernel/probes.c
create mode 100644 arch/arm/kernel/uprobes-arm.c
create mode 100644 arch/arm/kernel/uprobes.c
create mode 100644 arch/arm/kernel/uprobes.h
--
1.8.1.2
More than 256 entries in ACPI MADT is supported from ACPI 3.0 Specification,
So the outdated description for MADT entries should be removed.
Signed-off-by: Hanjun Guo <hanjun.guo(a)linaro.org>
---
Documentation/cpu-hotplug.txt | 3 ---
1 file changed, 3 deletions(-)
diff --git a/Documentation/cpu-hotplug.txt b/Documentation/cpu-hotplug.txt
index 9f40135..2e36e40 100644
--- a/Documentation/cpu-hotplug.txt
+++ b/Documentation/cpu-hotplug.txt
@@ -370,9 +370,6 @@ A: There is no clear spec defined way from ACPI that can give us that
CPUs in MADT as hotpluggable CPUS. In the case there are no disabled CPUS
we assume 1/2 the number of CPUs currently present can be hotplugged.
- Caveat: Today's ACPI MADT can only provide 256 entries since the apicid field
- in MADT is only 8 bits.
-
User Space Notification
Hotplug support for devices is common in Linux today. Its being used today to
--
1.7.9.5
This is a first draft at a process for getting things integrated into
the Linaro Stable Kernel releases. Any feedback is appreciated,
hopefully this is all fairly boring and uncontroversial so there
shouldn't be too many surprises.
The first thing to say here is that all LSK releases will be based off
the latest generic Linux stable kernel so the best way to get a change
into a Linaro release is to get it into the generic Linux stable kernel
using the standard processes. This will maximise the number of people
who can use the change and is just generally good practice.
New features
------------
Features for the stable kernel are agreed by the TSC. Once a feature
has been agreed by the TSC there should be an owner assigned to deliver
a feature branch into the stable kernel and work with the stable kernel
team to resolve any integration issues at least up until the feature has
been included in a release. This will be done per kernel version.
These feature branches should be based on the relevant upstream kernel
as far as possible (any dependencies on other branches should be
discussed with the stable kernel team). Some information about where
the code came fromm should be included along with the code, in order of
preference:
1. Commit IDs from the standard kernel in the changelogs of the
individual patches.
2. A description of how the equivalent change was made upstream or
why it isn't required in LSK (eg, explaining that this is taken
care of by features not present in the stable kernel).
3. References to where out of tree development is happening
including contact information for followup.
The code should be sent as a pull request or patches, with review by the
stable team following normal kernel process and focusing on backporting
and integration issues. Relevant testing infrastructure should also be
available in LAVA for QA and the review will also include ensuring that
the testsuite passes with the changes integrated.
Once the code has been accepted it will be stored as a branch in the LSK
tree and the submission branch can be deleted.
Updating code in the LSK
------------------------
The LSK can be updated either by replacing an existing topic branch or
by submitting incremental patches. Replacement would be most useful in
cases where a feature has not yet been merged into the standard kernel
and is still being redeveloped there but otherwise incremental updates
are preferred. The process for submitting changes is the same as for
new features with the exception that incremental updates should be based
on the topic branch in the LSK git rather than the standard kernel.
Hi,
A number of patch sets related to power-efficient scheduling have been
posted over the last couple of months. Most of them do not have much
data to back them up, so I decided to do some testing.
Common for all of the patch sets that I have tested, except one, is that
they attempt to pack tasks on as few cpus as possible to allow the
remaining cpus to enter deeper sleep states - a strategy that should
make sense on most platforms that support per-cpu power gating and
multi-socket machines.
Kernel: 3.9
Patch sets:
rlb-v4: sched: use runnable load based balance (Alex Shi)
<https://lkml.org/lkml/2013/4/27/13>
pas-v7: sched: power aware scheduling (Alex Shi)
<https://lkml.org/lkml/2013/4/3/732>
pst-v3: sched: packing small tasks (Vincent Guittot)
<https://lkml.org/lkml/2013/3/22/183>
pst-v4: sched: packing small tasks (Vincent Guittot)
<https://lkml.org/lkml/2013/4/25/396>
Configuration:
pas-v7: Set to "powersaving" mode.
pst-v4: Set to "Full" packing mode.
Platform:
ARM TC2 (test-chip), 2xCortex-A15 + 3xCortex-A7. Cortex-A15s disabled.
Measurement technique:
Time spent non-idle (not in idle state) for each cpu based on cpuidle
ftrace events. TC2 does not have per-core power-gating, so packing
inside the A7 cluster does not lead to any significant power savings.
Note that any product grade hardware (TC2 is a test-chip) will very
likely have per-core power-gating, so in those cases packing will have
an appreciable effect on power savings.
Measuring non-idle time rather than power should give a more clear idea
about the effect of the patch sets given that the idle back-end is
highly implementation specific.
Benchmarks:
audio playback (Android): 30s mp3 file playback on Android.
bbench+audio (Android): Web page rendering while doing mp3 playback.
andebench_native (Android): Android benchmark running in native mode.
cyclictest: Short periodic tasks.
Results:
Two runs for each patch set.
audio playback (Android) SMP
non-idle % cpu 0 cpu 1 cpu 2
3.9_1 11.96 2.86 2.48
3.9_2 12.64 2.81 1.88
rlb-v4_1 12.61 2.44 1.90
rlb-v4_2 12.45 2.44 1.90
pas-v7_1 16.17 0.03 0.24
pas-v7_2 16.08 0.28 0.07
pst-v3_1 15.18 2.76 1.70
pst-v3_2 15.13 0.80 0.38
pst-v4_1 16.14 0.05 0.00
pst-v4_2 16.34 0.06 0.00
bbench+audio (Android) SMP
non-idle % cpu 0 cpu 1 cpu 2 render time
3.9_1 25.00 20.73 21.22 812
3.9_2 24.29 19.78 22.34 795
rlb-v4_1 23.84 19.36 22.74 782
rlb-v4_2 24.07 19.36 22.74 797
pas-v7_1 28.29 17.86 16.01 869
pas-v7_2 28.62 18.54 15.05 908
pst-v3_1 29.14 20.59 21.72 830
pst-v3_2 27.69 18.81 20.06 830
pst-v4_1 42.20 13.63 2.29 880
pst-v4_2 41.56 14.40 2.17 935
andebench_native (8 threads) (Android) SMP
non-idle % cpu 0 cpu 1 cpu 2 Score
3.9_1 99.22 98.88 99.61 4139
3.9_2 99.56 99.31 99.46 4148
rlb-v4_1 99.49 99.61 99.53 4153
rlb-v4_2 99.56 99.61 99.53 4149
pas-v7_1 99.53 99.59 99.29 4149
pas-v7_2 99.42 99.63 99.48 4150
pst-v3_1 97.89 99.33 99.42 4097
pst-v3_2 99.16 99.62 99.42 4097
pst-v4_1 99.34 99.01 99.59 4146
pst-v4_2 99.49 99.52 99.20 4146
cyclictest SMP
non-idle % cpu 0 cpu 1 cpu 2
3.9_1 9.13 8.88 8.41
3.9_2 10.27 8.02 6.30
rlb-v4_1 8.88 8.09 8.11
rlb-v4_2 8.49 8.09 8.11
pas-v7_1 10.20 0.02 11.50
pas-v7_2 7.86 14.31 0.02
pst-v3_1 20.44 8.68 7.97
pst-v3_2 20.41 0.78 1.00
pst-v4_1 21.32 0.21 0.05
pst-v4_2 21.56 0.21 0.04
Overall, pas-v7 seems to do a fairly good job at packing. The idle time
distribution seems to be somewhere between pst-v3 and the more
aggressive pst-v4 for all the benchmarks. pst-v4 manages to keep two
cpus nearly idle (<0.25% non-idle) for both cyclictest and audio, which
is better than both pst-v3 and pas-v7. pas-v7 fails to pack cyclictest.
Packing does come at at cost which can be seen for bbench+audio, where
pst-v3 and rlb-v4 get better render times than pas-v7 and pst-v4 which
do more aggressive packing. rlb-v4 does not pack, it is only included
for reference.
>From a packing perspective pst-v4 seems to do the best job for the
workloads that I have tested on ARM TC2. The less aggressive packing in
pst-v3 may be a better choice for in terms of performance.
I'm well aware that these tests are heavily focused on mobile workloads.
I would therefore encourage people to share your test results for your
workloads on your platforms to complete the picture. Comments are also
welcome.
Thanks,
Morten
ACPI_PROCESSOR_FILE_INFO, ACPI_PROCESSOR_FILE_THROTTLING and
ACPI_PROCESSOR_FILE_LIMIT are used for procfs, but this feature was removed
in commit d09fe555 (ACPI processor: remove deprecated ACPI procfs I/F) long
ago. So, these macros should also be removed.
ACPI_PROCESSOR_LIMIT_USER and ACPI_PROCESSOR_LIMIT_THERMAL are not used
by any code, remove them too.
Signed-off-by: Hanjun Guo <hanjun.guo(a)linaro.org>
---
drivers/acpi/processor_driver.c | 6 ------
1 file changed, 6 deletions(-)
diff --git a/drivers/acpi/processor_driver.c b/drivers/acpi/processor_driver.c
index d93963f..823be116 100644
--- a/drivers/acpi/processor_driver.c
+++ b/drivers/acpi/processor_driver.c
@@ -43,16 +43,10 @@
#define PREFIX "ACPI: "
-#define ACPI_PROCESSOR_FILE_INFO "info"
-#define ACPI_PROCESSOR_FILE_THROTTLING "throttling"
-#define ACPI_PROCESSOR_FILE_LIMIT "limit"
#define ACPI_PROCESSOR_NOTIFY_PERFORMANCE 0x80
#define ACPI_PROCESSOR_NOTIFY_POWER 0x81
#define ACPI_PROCESSOR_NOTIFY_THROTTLING 0x82
-#define ACPI_PROCESSOR_LIMIT_USER 0
-#define ACPI_PROCESSOR_LIMIT_THERMAL 1
-
#define _COMPONENT ACPI_PROCESSOR_COMPONENT
ACPI_MODULE_NAME("processor_driver");
--
1.7.9.5
Hi Rafael,
This is part of my patchset "CPUFreq: Fix {PRE|POST}CHANGE notification
sequence". It contains changes specific to cpufreq core and ARM drivers.
I have left changes to non-ARM cpufreq drivers from this pull request. See if
you can take them for 3.11.
The following changes since commit 9e895ace5d82df8929b16f58e9f515f6d54ab82d:
Linux 3.10-rc7 (2013-06-22 09:47:31 -1000)
are available in the git repository at:
git://git.linaro.org/people/vireshk/linux.git cpufreq-fix-notification-arm
for you to fetch changes up to f2d65dd0d573e6961165f0be35bac84997b9e707:
cpufreq: tegra: call CPUFREQ_POSTCHANGE notfier in error cases
(2013-06-24 11:14:24 +0530)
----------------------------------------------------------------
Viresh Kumar (9):
cpufreq: make sure frequency transitions are serialized
cpufreq: arm-big-little: call CPUFREQ_POSTCHANGE notfier in error cases
cpufreq: davinci: call CPUFREQ_POSTCHANGE notfier in error cases
cpufreq: dbx500: call CPUFREQ_POSTCHANGE notfier in error cases
cpufreq: exynos: call CPUFREQ_POSTCHANGE notfier in error cases
cpufreq: imx6q: call CPUFREQ_POSTCHANGE notfier in error cases
cpufreq: omap: call CPUFREQ_POSTCHANGE notfier in error cases
cpufreq: s3c64xx: call CPUFREQ_POSTCHANGE notfier in error cases
cpufreq: tegra: call CPUFREQ_POSTCHANGE notfier in error cases
drivers/cpufreq/arm_big_little.c | 4 +---
drivers/cpufreq/cpufreq.c | 9 +++++++++
drivers/cpufreq/davinci-cpufreq.c | 3 +++
drivers/cpufreq/dbx500-cpufreq.c | 4 ++--
drivers/cpufreq/exynos-cpufreq.c | 10 ++++++++--
drivers/cpufreq/imx6q-cpufreq.c | 17 +++++++++++------
drivers/cpufreq/omap-cpufreq.c | 6 +++---
drivers/cpufreq/s3c64xx-cpufreq.c | 8 ++++++--
drivers/cpufreq/tegra-cpufreq.c | 4 ++--
9 files changed, 45 insertions(+), 20 deletions(-)
There were few noticeable formatting issues present in core cpufreq code. This
patch tries to fix them to make code look better. These are:
- Removing few extra blank lines
- Adding few blank lines
- replacing spaces with tabs
- removing unnecessary spaces
- rearranging code a bit
- Fixing multiline comments
- Break lines longer than 80 columns into multi-line.
At the end it also updates copyright information in cpufreq.c to include my name
for 2013.
Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org>
---
drivers/cpufreq/cpufreq.c | 61 +++++++++++++++--------------------
drivers/cpufreq/cpufreq_governor.h | 4 +--
drivers/cpufreq/cpufreq_performance.c | 4 ---
drivers/cpufreq/cpufreq_powersave.c | 6 ++--
drivers/cpufreq/cpufreq_stats.c | 4 +--
drivers/cpufreq/cpufreq_userspace.c | 4 ---
include/linux/cpufreq.h | 41 ++++++++++++-----------
7 files changed, 52 insertions(+), 72 deletions(-)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 2d53f47..7c38842 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -3,6 +3,7 @@
*
* Copyright (C) 2001 Russell King
* (C) 2002 - 2003 Dominik Brodowski <linux(a)brodo.de>
+ * (C) 2013 Viresh Kumar <viresh.kumar(a)linaro.org>
*
* Oct 2005 - Ashok Raj <ashok.raj(a)intel.com>
* Added handling for CPU hotplug
@@ -12,7 +13,6 @@
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
- *
*/
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
@@ -41,11 +41,12 @@
*/
static struct cpufreq_driver *cpufreq_driver;
static DEFINE_PER_CPU(struct cpufreq_policy *, cpufreq_cpu_data);
+static DEFINE_RWLOCK(cpufreq_driver_lock);
+
#ifdef CONFIG_HOTPLUG_CPU
/* This one keeps track of the previously set governor of a removed CPU */
static DEFINE_PER_CPU(char[CPUFREQ_NAME_LEN], cpufreq_cpu_governor);
#endif
-static DEFINE_RWLOCK(cpufreq_driver_lock);
/*
* cpu_policy_rwsem is a per CPU reader-writer semaphore designed to cure
@@ -150,7 +151,6 @@ static struct cpufreq_policy *__cpufreq_cpu_get(unsigned int cpu, bool sysfs)
if (!try_module_get(cpufreq_driver->owner))
goto err_out_unlock;
-
/* get the CPU */
data = per_cpu(cpufreq_cpu_data, cpu);
@@ -220,7 +220,7 @@ static void cpufreq_cpu_put_sysfs(struct cpufreq_policy *data)
*/
#ifndef CONFIG_SMP
static unsigned long l_p_j_ref;
-static unsigned int l_p_j_ref_freq;
+static unsigned int l_p_j_ref_freq;
static void adjust_jiffies(unsigned long val, struct cpufreq_freqs *ci)
{
@@ -233,7 +233,7 @@ static void adjust_jiffies(unsigned long val, struct cpufreq_freqs *ci)
pr_debug("saving %lu as reference value for loops_per_jiffy; "
"freq is %u kHz\n", l_p_j_ref, l_p_j_ref_freq);
}
- if ((val == CPUFREQ_POSTCHANGE && ci->old != ci->new) ||
+ if ((val == CPUFREQ_POSTCHANGE && ci->old != ci->new) ||
(val == CPUFREQ_RESUMECHANGE || val == CPUFREQ_SUSPENDCHANGE)) {
loops_per_jiffy = cpufreq_scale(l_p_j_ref, l_p_j_ref_freq,
ci->new);
@@ -248,7 +248,6 @@ static inline void adjust_jiffies(unsigned long val, struct cpufreq_freqs *ci)
}
#endif
-
void __cpufreq_notify_transition(struct cpufreq_policy *policy,
struct cpufreq_freqs *freqs, unsigned int state)
{
@@ -294,6 +293,7 @@ void __cpufreq_notify_transition(struct cpufreq_policy *policy,
break;
}
}
+
/**
* cpufreq_notify_transition - call notifier chain and adjust_jiffies
* on frequency transition.
@@ -311,7 +311,6 @@ void cpufreq_notify_transition(struct cpufreq_policy *policy,
EXPORT_SYMBOL_GPL(cpufreq_notify_transition);
-
/*********************************************************************
* SYSFS INTERFACE *
*********************************************************************/
@@ -376,7 +375,6 @@ out:
return err;
}
-
/**
* cpufreq_per_cpu_attr_read() / show_##file_name() -
* print out cpufreq information
@@ -441,7 +439,6 @@ static ssize_t show_cpuinfo_cur_freq(struct cpufreq_policy *policy,
return sprintf(buf, "%u\n", cur_freq);
}
-
/**
* show_scaling_governor - show the current policy for the specified CPU
*/
@@ -457,7 +454,6 @@ static ssize_t show_scaling_governor(struct cpufreq_policy *policy, char *buf)
return -EINVAL;
}
-
/**
* store_scaling_governor - store policy for the specified CPU
*/
@@ -480,8 +476,10 @@ static ssize_t store_scaling_governor(struct cpufreq_policy *policy,
&new_policy.governor))
return -EINVAL;
- /* Do not use cpufreq_set_policy here or the user_policy.max
- will be wrongly overridden */
+ /*
+ * Do not use cpufreq_set_policy here or the user_policy.max
+ * will be wrongly overridden
+ */
ret = __cpufreq_set_policy(policy, &new_policy);
policy->user_policy.policy = policy->policy;
@@ -1005,7 +1003,8 @@ static void update_policy_cpu(struct cpufreq_policy *policy, unsigned int cpu)
* Caller should already have policy_rwsem in write mode for this CPU.
* This routine frees the rwsem before returning.
*/
-static int __cpufreq_remove_dev(struct device *dev, struct subsys_interface *sif)
+static int __cpufreq_remove_dev(struct device *dev,
+ struct subsys_interface *sif)
{
unsigned int cpu = dev->id, ret, cpus;
unsigned long flags;
@@ -1112,7 +1111,6 @@ static int __cpufreq_remove_dev(struct device *dev, struct subsys_interface *sif
return 0;
}
-
static int cpufreq_remove_dev(struct device *dev, struct subsys_interface *sif)
{
unsigned int cpu = dev->id;
@@ -1125,7 +1123,6 @@ static int cpufreq_remove_dev(struct device *dev, struct subsys_interface *sif)
return retval;
}
-
static void handle_update(struct work_struct *work)
{
struct cpufreq_policy *policy =
@@ -1136,7 +1133,8 @@ static void handle_update(struct work_struct *work)
}
/**
- * cpufreq_out_of_sync - If actual and saved CPU frequency differs, we're in deep trouble.
+ * cpufreq_out_of_sync - If actual and saved CPU frequency differs, we're
+ * in deep trouble.
* @cpu: cpu number
* @old_freq: CPU frequency the kernel thinks the CPU runs at
* @new_freq: CPU frequency the CPU actually runs at
@@ -1151,7 +1149,6 @@ static void cpufreq_out_of_sync(unsigned int cpu, unsigned int old_freq,
struct cpufreq_freqs freqs;
unsigned long flags;
-
pr_debug("Warning: CPU frequency out of sync: cpufreq and timing "
"core thinks of %u, is %u kHz.\n", old_freq, new_freq);
@@ -1166,7 +1163,6 @@ static void cpufreq_out_of_sync(unsigned int cpu, unsigned int old_freq,
cpufreq_notify_transition(policy, &freqs, CPUFREQ_POSTCHANGE);
}
-
/**
* cpufreq_quick_get - get the CPU frequency (in kHz) from policy->cur
* @cpu: CPU number
@@ -1212,7 +1208,6 @@ unsigned int cpufreq_quick_get_max(unsigned int cpu)
}
EXPORT_SYMBOL(cpufreq_quick_get_max);
-
static unsigned int __cpufreq_get(unsigned int cpu)
{
struct cpufreq_policy *policy = per_cpu(cpufreq_cpu_data, cpu);
@@ -1271,7 +1266,6 @@ static struct subsys_interface cpufreq_interface = {
.remove_dev = cpufreq_remove_dev,
};
-
/**
* cpufreq_bp_suspend - Prepare the boot CPU for system suspend.
*
@@ -1408,11 +1402,10 @@ int cpufreq_register_notifier(struct notifier_block *nb, unsigned int list)
}
EXPORT_SYMBOL(cpufreq_register_notifier);
-
/**
* cpufreq_unregister_notifier - unregister a driver with cpufreq
* @nb: notifier block to be unregistered
- * @list: CPUFREQ_TRANSITION_NOTIFIER or CPUFREQ_POLICY_NOTIFIER
+ * @list: CPUFREQ_TRANSITION_NOTIFIER or CPUFREQ_POLICY_NOTIFIER
*
* Remove a driver from the CPU frequency notifier list.
*
@@ -1448,7 +1441,6 @@ EXPORT_SYMBOL(cpufreq_unregister_notifier);
* GOVERNORS *
*********************************************************************/
-
int __cpufreq_driver_target(struct cpufreq_policy *policy,
unsigned int target_freq,
unsigned int relation)
@@ -1581,7 +1573,6 @@ static int __cpufreq_governor(struct cpufreq_policy *policy,
return ret;
}
-
int cpufreq_register_governor(struct cpufreq_governor *governor)
{
int err;
@@ -1606,7 +1597,6 @@ int cpufreq_register_governor(struct cpufreq_governor *governor)
}
EXPORT_SYMBOL_GPL(cpufreq_register_governor);
-
void cpufreq_unregister_governor(struct cpufreq_governor *governor)
{
#ifdef CONFIG_HOTPLUG_CPU
@@ -1636,7 +1626,6 @@ void cpufreq_unregister_governor(struct cpufreq_governor *governor)
EXPORT_SYMBOL_GPL(cpufreq_unregister_governor);
-
/*********************************************************************
* POLICY INTERFACE *
*********************************************************************/
@@ -1665,7 +1654,6 @@ int cpufreq_get_policy(struct cpufreq_policy *policy, unsigned int cpu)
}
EXPORT_SYMBOL(cpufreq_get_policy);
-
/*
* data : current policy.
* policy : policy to be set.
@@ -1699,8 +1687,10 @@ static int __cpufreq_set_policy(struct cpufreq_policy *data,
blocking_notifier_call_chain(&cpufreq_policy_notifier_list,
CPUFREQ_INCOMPATIBLE, policy);
- /* verify the cpu speed can be set within this limit,
- which might be different to the first one */
+ /*
+ * verify the cpu speed can be set within this limit, which might be
+ * different to the first one
+ */
ret = cpufreq_driver->verify(policy);
if (ret)
goto error_out;
@@ -1802,8 +1792,10 @@ int cpufreq_update_policy(unsigned int cpu)
policy.policy = data->user_policy.policy;
policy.governor = data->user_policy.governor;
- /* BIOS might change freq behind our back
- -> ask driver for current freq and notify governors about a change */
+ /*
+ * BIOS might change freq behind our back
+ * -> ask driver for current freq and notify governors about a change
+ */
if (cpufreq_driver->get) {
policy.cur = cpufreq_driver->get(cpu);
if (!data->cur) {
@@ -1852,7 +1844,7 @@ static int __cpuinit cpufreq_cpu_callback(struct notifier_block *nfb,
}
static struct notifier_block __refdata cpufreq_cpu_notifier = {
- .notifier_call = cpufreq_cpu_callback,
+ .notifier_call = cpufreq_cpu_callback,
};
/*********************************************************************
@@ -1864,7 +1856,7 @@ static struct notifier_block __refdata cpufreq_cpu_notifier = {
* @driver_data: A struct cpufreq_driver containing the values#
* submitted by the CPU Frequency driver.
*
- * Registers a CPU Frequency driver to this core code. This code
+ * Registers a CPU Frequency driver to this core code. This code
* returns zero on success, -EBUSY when another driver got here first
* (and isn't unregistered in the meantime).
*
@@ -1931,11 +1923,10 @@ err_null_driver:
}
EXPORT_SYMBOL_GPL(cpufreq_register_driver);
-
/**
* cpufreq_unregister_driver - unregister the current CPUFreq driver
*
- * Unregister the current CPUFreq driver. Only call this if you have
+ * Unregister the current CPUFreq driver. Only call this if you have
* the right to do so, i.e. if you have succeeded in initialising before!
* Returns zero if successful, and -EINVAL if the cpufreq_driver is
* currently not initialised.
diff --git a/drivers/cpufreq/cpufreq_governor.h b/drivers/cpufreq/cpufreq_governor.h
index e16a961..72e7994 100644
--- a/drivers/cpufreq/cpufreq_governor.h
+++ b/drivers/cpufreq/cpufreq_governor.h
@@ -81,7 +81,7 @@ static ssize_t show_##file_name##_gov_sys \
return sprintf(buf, "%u\n", tuners->file_name); \
} \
\
-static ssize_t show_##file_name##_gov_pol \
+static ssize_t show_##file_name##_gov_pol \
(struct cpufreq_policy *policy, char *buf) \
{ \
struct dbs_data *dbs_data = policy->governor_data; \
@@ -91,7 +91,7 @@ static ssize_t show_##file_name##_gov_pol \
#define store_one(_gov, file_name) \
static ssize_t store_##file_name##_gov_sys \
-(struct kobject *kobj, struct attribute *attr, const char *buf, size_t count) \
+(struct kobject *kobj, struct attribute *attr, const char *buf, size_t count) \
{ \
struct dbs_data *dbs_data = _gov##_dbs_cdata.gdbs_data; \
return store_##file_name(dbs_data, buf, count); \
diff --git a/drivers/cpufreq/cpufreq_performance.c b/drivers/cpufreq/cpufreq_performance.c
index ceee068..9fef7d6 100644
--- a/drivers/cpufreq/cpufreq_performance.c
+++ b/drivers/cpufreq/cpufreq_performance.c
@@ -17,7 +17,6 @@
#include <linux/cpufreq.h>
#include <linux/init.h>
-
static int cpufreq_governor_performance(struct cpufreq_policy *policy,
unsigned int event)
{
@@ -44,19 +43,16 @@ struct cpufreq_governor cpufreq_gov_performance = {
.owner = THIS_MODULE,
};
-
static int __init cpufreq_gov_performance_init(void)
{
return cpufreq_register_governor(&cpufreq_gov_performance);
}
-
static void __exit cpufreq_gov_performance_exit(void)
{
cpufreq_unregister_governor(&cpufreq_gov_performance);
}
-
MODULE_AUTHOR("Dominik Brodowski <linux(a)brodo.de>");
MODULE_DESCRIPTION("CPUfreq policy governor 'performance'");
MODULE_LICENSE("GPL");
diff --git a/drivers/cpufreq/cpufreq_powersave.c b/drivers/cpufreq/cpufreq_powersave.c
index 2d948a1..32109a1 100644
--- a/drivers/cpufreq/cpufreq_powersave.c
+++ b/drivers/cpufreq/cpufreq_powersave.c
@@ -1,7 +1,7 @@
/*
- * linux/drivers/cpufreq/cpufreq_powersave.c
+ * linux/drivers/cpufreq/cpufreq_powersave.c
*
- * Copyright (C) 2002 - 2003 Dominik Brodowski <linux(a)brodo.de>
+ * Copyright (C) 2002 - 2003 Dominik Brodowski <linux(a)brodo.de>
*
*
* This program is free software; you can redistribute it and/or modify
@@ -48,13 +48,11 @@ static int __init cpufreq_gov_powersave_init(void)
return cpufreq_register_governor(&cpufreq_gov_powersave);
}
-
static void __exit cpufreq_gov_powersave_exit(void)
{
cpufreq_unregister_governor(&cpufreq_gov_powersave);
}
-
MODULE_AUTHOR("Dominik Brodowski <linux(a)brodo.de>");
MODULE_DESCRIPTION("CPUfreq policy governor 'powersave'");
MODULE_LICENSE("GPL");
diff --git a/drivers/cpufreq/cpufreq_stats.c b/drivers/cpufreq/cpufreq_stats.c
index fb65dec..6d35caa 100644
--- a/drivers/cpufreq/cpufreq_stats.c
+++ b/drivers/cpufreq/cpufreq_stats.c
@@ -27,7 +27,7 @@ static spinlock_t cpufreq_stats_lock;
struct cpufreq_stats {
unsigned int cpu;
unsigned int total_trans;
- unsigned long long last_time;
+ unsigned long long last_time;
unsigned int max_state;
unsigned int state_num;
unsigned int last_index;
@@ -116,7 +116,7 @@ static ssize_t show_trans_table(struct cpufreq_policy *policy, char *buf)
len += snprintf(buf + len, PAGE_SIZE - len, "%9u: ",
stat->freq_table[i]);
- for (j = 0; j < stat->state_num; j++) {
+ for (j = 0; j < stat->state_num; j++) {
if (len >= PAGE_SIZE)
break;
len += snprintf(buf + len, PAGE_SIZE - len, "%9u ",
diff --git a/drivers/cpufreq/cpufreq_userspace.c b/drivers/cpufreq/cpufreq_userspace.c
index bbeb9c0..c4f2dc3 100644
--- a/drivers/cpufreq/cpufreq_userspace.c
+++ b/drivers/cpufreq/cpufreq_userspace.c
@@ -104,7 +104,6 @@ static int cpufreq_set(struct cpufreq_policy *policy, unsigned int freq)
return ret;
}
-
static ssize_t show_speed(struct cpufreq_policy *policy, char *buf)
{
return sprintf(buf, "%u\n", per_cpu(cpu_cur_freq, policy->cpu));
@@ -185,7 +184,6 @@ static int cpufreq_governor_userspace(struct cpufreq_policy *policy,
return rc;
}
-
#ifndef CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE
static
#endif
@@ -202,13 +200,11 @@ static int __init cpufreq_gov_userspace_init(void)
return cpufreq_register_governor(&cpufreq_gov_userspace);
}
-
static void __exit cpufreq_gov_userspace_exit(void)
{
cpufreq_unregister_governor(&cpufreq_gov_userspace);
}
-
MODULE_AUTHOR("Dominik Brodowski <linux(a)brodo.de>, "
"Russell King <rmk(a)arm.linux.org.uk>");
MODULE_DESCRIPTION("CPUfreq policy governor 'userspace'");
diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
index 037d36a..dc204c3 100644
--- a/include/linux/cpufreq.h
+++ b/include/linux/cpufreq.h
@@ -1,8 +1,8 @@
/*
- * linux/include/linux/cpufreq.h
+ * linux/include/linux/cpufreq.h
*
- * Copyright (C) 2001 Russell King
- * (C) 2002 - 2003 Dominik Brodowski <linux(a)brodo.de>
+ * Copyright (C) 2001 Russell King
+ * (C) 2002 - 2003 Dominik Brodowski <linux(a)brodo.de>
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
@@ -26,7 +26,6 @@
/* Print length for names. Extra 1 space for accomodating '\n' in prints */
#define CPUFREQ_NAME_PLEN (CPUFREQ_NAME_LEN + 1)
-
/*********************************************************************
* CPUFREQ NOTIFIER INTERFACE *
*********************************************************************/
@@ -148,17 +147,18 @@ struct cpufreq_freqs {
u8 flags; /* flags of cpufreq_driver, see below. */
};
-
/**
- * cpufreq_scale - "old * mult / div" calculation for large values (32-bit-arch safe)
+ * cpufreq_scale - "old * mult / div" calculation for large values (32-bit-arch
+ * safe)
* @old: old value
* @div: divisor
* @mult: multiplier
*
*
- * new = old * mult / div
+ * new = old * mult / div
*/
-static inline unsigned long cpufreq_scale(unsigned long old, u_int div, u_int mult)
+static inline unsigned long cpufreq_scale(unsigned long old, u_int div,
+ u_int mult)
{
#if BITS_PER_LONG == 32
@@ -211,14 +211,12 @@ extern int __cpufreq_driver_target(struct cpufreq_policy *policy,
unsigned int target_freq,
unsigned int relation);
-
extern int __cpufreq_driver_getavg(struct cpufreq_policy *policy,
unsigned int cpu);
int cpufreq_register_governor(struct cpufreq_governor *governor);
void cpufreq_unregister_governor(struct cpufreq_governor *governor);
-
/*********************************************************************
* CPUFREQ DRIVER INTERFACE *
*********************************************************************/
@@ -229,7 +227,7 @@ void cpufreq_unregister_governor(struct cpufreq_governor *governor);
struct freq_attr;
struct cpufreq_driver {
- struct module *owner;
+ struct module *owner;
char name[CPUFREQ_NAME_LEN];
u8 flags;
/*
@@ -277,11 +275,11 @@ struct cpufreq_driver {
int cpufreq_register_driver(struct cpufreq_driver *driver_data);
int cpufreq_unregister_driver(struct cpufreq_driver *driver_data);
-
void cpufreq_notify_transition(struct cpufreq_policy *policy,
struct cpufreq_freqs *freqs, unsigned int state);
-static inline void cpufreq_verify_within_limits(struct cpufreq_policy *policy, unsigned int min, unsigned int max)
+static inline void cpufreq_verify_within_limits(struct cpufreq_policy *policy,
+ unsigned int min, unsigned int max)
{
if (policy->min < min)
policy->min = min;
@@ -342,7 +340,9 @@ int cpufreq_update_policy(unsigned int cpu);
bool have_governor_per_policy(void);
#ifdef CONFIG_CPU_FREQ
-/* query the current CPU frequency (in kHz). If zero, cpufreq couldn't detect it */
+/*
+ * query the current CPU frequency (in kHz). If zero, cpufreq couldn't detect it
+ */
unsigned int cpufreq_get(unsigned int cpu);
#else
static inline unsigned int cpufreq_get(unsigned int cpu)
@@ -351,7 +351,9 @@ static inline unsigned int cpufreq_get(unsigned int cpu)
}
#endif
-/* query the last known CPU freq (in kHz). If zero, cpufreq couldn't detect it */
+/*
+ * query the last known CPU freq (in kHz). If zero, cpufreq couldn't detect it
+ */
#ifdef CONFIG_CPU_FREQ
unsigned int cpufreq_quick_get(unsigned int cpu);
unsigned int cpufreq_quick_get_max(unsigned int cpu);
@@ -366,16 +368,14 @@ static inline unsigned int cpufreq_quick_get_max(unsigned int cpu)
}
#endif
-
/*********************************************************************
* CPUFREQ DEFAULT GOVERNOR *
*********************************************************************/
-
/*
- Performance governor is fallback governor if any other gov failed to
- auto load due latency restrictions
-*/
+ * Performance governor is fallback governor if any other gov failed to auto
+ * load due latency restrictions
+ */
#ifdef CONFIG_CPU_FREQ_GOV_PERFORMANCE
extern struct cpufreq_governor cpufreq_gov_performance;
#endif
@@ -395,7 +395,6 @@ extern struct cpufreq_governor cpufreq_gov_conservative;
#define CPUFREQ_DEFAULT_GOVERNOR (&cpufreq_gov_conservative)
#endif
-
/*********************************************************************
* FREQUENCY TABLE HELPERS *
*********************************************************************/
--
1.7.12.rc2.18.g61b472e
More than 256 entries in ACPI MADT is supported from ACPI 3.0, so the
information should be updated.
-v2: Rephrase the information instead of simply removing it according
to Rafael's advice.
Suggested-by: Rafael J. Wysocki <rjw(a)sisk.pl>
Signed-off-by: Hanjun Guo <hanjun.guo(a)linaro.org>
---
Documentation/cpu-hotplug.txt | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/Documentation/cpu-hotplug.txt b/Documentation/cpu-hotplug.txt
index 9f40135..67f733d 100644
--- a/Documentation/cpu-hotplug.txt
+++ b/Documentation/cpu-hotplug.txt
@@ -370,8 +370,10 @@ A: There is no clear spec defined way from ACPI that can give us that
CPUs in MADT as hotpluggable CPUS. In the case there are no disabled CPUS
we assume 1/2 the number of CPUs currently present can be hotplugged.
- Caveat: Today's ACPI MADT can only provide 256 entries since the apicid field
- in MADT is only 8 bits.
+ Caveat: ACPI MADT can only provide 256 entries in systems with only ACPI 2.0c
+ or earlier ACPI version supported, because the apicid field in MADT is only
+ 8 bits. From ACPI 3.0, this limitation was removed since the apicid field
+ was extended to 32 bits with x2APIC introduced.
User Space Notification
--
1.7.9.5
Hi Rafael,
The following changes since commit 9e895ace5d82df8929b16f58e9f515f6d54ab82d:
Linux 3.10-rc7 (2013-06-22 09:47:31 -1000)
are available in the git repository at:
git://git.linaro.org/people/vireshk/linux.git cpufreq-next
for you to fetch changes up to 166b9addd83aaf6eb22d9db7dc015f81913c9a0e:
cpufreq: s3c2416: fix forgotten driver_data conversions (2013-06-24
11:22:33 +0530)
----------------------------------------------------------------
Heiko Stübner (1):
cpufreq: s3c2416: fix forgotten driver_data conversions
drivers/cpufreq/s3c2416-cpufreq.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
This patch adds support for defining and passing earlyprintk
related information i.e. device and address information via
device tree by adding it inside "chosen" node.
This will help user to just specify "earlyprintk" from bootargs
without actually knowing the address and device to enable
earlyprintk.
Mechanism:
One can just append earlyprintk=device-type,address (same as we pass
through command line) in "/chosen" node to notify kernel which is the
earlyprintk device and what is its address.
Backward Compatibility:
This patch also allows existing method of specifying earlyprintk
parameter via bootargs.
Existing method i.e. passing via bootargs will still have precedence
over device tree i.e. if one specifies earlyprintk=device-type,address
in bootargs then kernel will use information from bootargs instead of
device tree.
If user just specifies earlyprintk (without =...) then kernel will
look for device tree earlyprintk parameter.
Signed-off-by: Pranavkumar Sawargaonkar <pranavkumar(a)linaro.org>
Signed-off-by: Anup Patel <anup.patel(a)linaro.org>
---
arch/arm64/kernel/early_printk.c | 7 +++++++
arch/arm64/kernel/setup.c | 21 ++++++++++++++++++++-
2 files changed, 27 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/kernel/early_printk.c b/arch/arm64/kernel/early_printk.c
index fbb6e18..4e6f845 100644
--- a/arch/arm64/kernel/early_printk.c
+++ b/arch/arm64/kernel/early_printk.c
@@ -29,6 +29,8 @@
static void __iomem *early_base;
static void (*printch)(char ch);
+extern char *earlyprintk_dt_args;
+
/*
* PL011 single character TX.
*/
@@ -116,6 +118,11 @@ static int __init setup_early_printk(char *buf)
phys_addr_t paddr = 0;
if (!buf) {
+ /* Try to check if Device Tree has this argument or not ? */
+ buf = earlyprintk_dt_args;
+ }
+
+ if (!buf) {
pr_warning("No earlyprintk arguments passed.\n");
return 0;
}
diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index 6a9a532..fb2d56f 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -60,6 +60,8 @@ EXPORT_SYMBOL(processor_id);
unsigned int elf_hwcap __read_mostly;
EXPORT_SYMBOL_GPL(elf_hwcap);
+char *earlyprintk_dt_args;
+
static const char *cpu_name;
static const char *machine_name;
phys_addr_t __fdt_pointer __initdata;
@@ -122,6 +124,23 @@ static void __init setup_processor(void)
elf_hwcap = 0;
}
+int __init early_init_dt_scan_chosen_arm64(unsigned long node,
+ const char *uname,
+ int depth, void *data)
+{
+ char *prop;
+
+ /* Check if this is chosen node */
+ if (early_init_dt_scan_chosen(node, uname, depth, data) == 0)
+ return 0;
+
+ prop = of_get_flat_dt_prop(node, "earlyprintk", NULL);
+ if (prop)
+ earlyprintk_dt_args = prop;
+
+ return 1;
+}
+
static void __init setup_machine_fdt(phys_addr_t dt_phys)
{
struct boot_param_header *devtree;
@@ -165,7 +184,7 @@ static void __init setup_machine_fdt(phys_addr_t dt_phys)
pr_info("Machine: %s\n", machine_name);
/* Retrieve various information from the /chosen node */
- of_scan_flat_dt(early_init_dt_scan_chosen, boot_command_line);
+ of_scan_flat_dt(early_init_dt_scan_chosen_arm64, boot_command_line);
/* Initialize {size,address}-cells info */
of_scan_flat_dt(early_init_dt_scan_root, NULL);
/* Setup memory, calling early_init_dt_add_memory_arch */
--
1.7.9.5
The number of cpuidle drivers is increasing more and more. Today we have
in total 24 drivers. A lot of the code is duplicated, at least for the
initialization. A work of consolidation has been done during this year:
* a lot of code cleanup in all the drivers
* time keeping is now part of the framework
* timer broadcast is now part of the framework
* a WFI state function for ARM is defined and used in the drivers
* an init function has been proposed to factor out the initialization across
the drivers (patchset pending)
What has been observed is a lot of code duplicationis, modification made in
the framework takes awhile before reaching the driver which uses an old API,
duplicate routine and bugs, etc ...
It appears the drivers are belonging to different trees, the cpuidle framework
is under linux-pm, the drivers are per SoC tree. The communication is made
difficult because of the different mailing lists where the cpuidle are
submitted.
After this work, it is time to prevent all these problems to occur again.
I propose to move the cpuidle drivers to the drivers/cpuidle directory, hence
having one single submission path for cpuidle in order to have the cpuidle
framework and the different drivers synced.
This series move the AT91 cpuidle driver under drivers/cpuidle. That does not
change the rule to have the patches acked-by the author of the driver.
Note the calxeda and kirkwood drivers are now in drivers/cpuidle.
Daniel Lezcano (2):
ARM: at91: cpuidle: encapsulate the standby code
ARM: at91: cpuidle: move the driver to drivers/cpuidle directory
arch/arm/mach-at91/Makefile | 1 -
arch/arm/mach-at91/cpuidle.c | 66 ------------------------------------------
arch/arm/mach-at91/pm.c | 8 ++++-
drivers/cpuidle/Makefile | 1 +
drivers/cpuidle/at91.c | 55 +++++++++++++++++++++++++++++++++++
5 files changed, 63 insertions(+), 68 deletions(-)
delete mode 100644 arch/arm/mach-at91/cpuidle.c
create mode 100644 drivers/cpuidle/at91.c
--
1.7.9.5
The recent modification in the cpuidle framework consolidated the timer
broadcast code across the different drivers by setting a new flag in the idle
state. It tells the cpuidle core code to enter/exit to the broadcast mode for
the cpu when entering a deep idle state. The broadcast timer enter/exit is no
longer handled by the back-end driver.
This change made the local interrupt to be enabled *before* calling
CLOCK_EVENT_NOTIFY_EXIT. bad or not (see below) ?
On a tegra114, a four cores system, when the flag has been introduced in the
driver, the following warning appeared:
[ 25.629559] WARNING: CPU: 2 PID: 0 at
kernel/time/tick-broadcast.c:578 tick_broadcast_oneshot_control
+0x1a4/0x1d0()
[ 25.629565] Modules linked in:
[ 25.629574] CPU: 2 PID: 0 Comm: swapper/2 Not tainted
3.10.0-rc3-next-20130529+ #15
[ 25.629601] [<c00148f4>] (unwind_backtrace+0x0/0xf8) from
[<c0011040>] (show_stack+0x10/0x14)
[ 25.629616] [<c0011040>] (show_stack+0x10/0x14) from [<c0504248>]
(dump_stack+0x80/0xc4)
[ 25.629633] [<c0504248>] (dump_stack+0x80/0xc4) from [<c00231ac>]
(warn_slowpath_common+0x64/0x88)
[ 25.629646] [<c00231ac>] (warn_slowpath_common+0x64/0x88) from
[<c00231ec>] (warn_slowpath_null+0x1c/0x24)
[ 25.629657] [<c00231ec>] (warn_slowpath_null+0x1c/0x24) from
[<c00667f8>] (tick_broadcast_oneshot_control+0x1a4/0x1d0)
[ 25.629670] [<c00667f8>] (tick_broadcast_oneshot_control+0x1a4/0x1d0)
from [<c0065cd0>] (tick_notify+0x240/0x40c)
[ 25.629685] [<c0065cd0>] (tick_notify+0x240/0x40c) from [<c0044724>]
(notifier_call_chain+0x44/0x84)
[ 25.629699] [<c0044724>] (notifier_call_chain+0x44/0x84) from
[<c0044828>] (raw_notifier_call_chain+0x18/0x20)
[ 25.629712] [<c0044828>] (raw_notifier_call_chain+0x18/0x20) from
[<c00650cc>] (clockevents_notify+0x28/0x170)
[ 25.629726] [<c00650cc>] (clockevents_notify+0x28/0x170) from
[<c033f1f0>] (cpuidle_idle_call+0x11c/0x168)
[ 25.629739] [<c033f1f0>] (cpuidle_idle_call+0x11c/0x168) from
[<c000ea94>] (arch_cpu_idle+0x8/0x38)
[ 25.629755] [<c000ea94>] (arch_cpu_idle+0x8/0x38) from [<c005ea80>]
(cpu_startup_entry+0x60/0x134)
[ 25.629767] [<c005ea80>] (cpu_startup_entry+0x60/0x134) from
[<804fe9a4>] (0x804fe9a4)
[ 25.629772] ---[ end trace 5484e77e2531bccc ]---
I don't have the hardware, so I wasn't able to reproduce the warning but after
looking a while in the code, I deduced the following:
1. the CPU2 enters a deep idle state and sets the broadcast timer
2. the timer expires, the tick_handle_oneshot_broadcast function is called,
setting the tick_broadcast_pending_mask and waking up the idle cpu CPU2
3. the CPU2 exits idle and invokes tick_broadcast_oneshot_control with
CLOCK_EVENT_NOTIFY_EXIT with the following code:
[...]
if (dev->next_event.tv64 == KTIME_MAX)
goto out;
if (cpumask_test_and_clear_cpu(cpu,
tick_broadcast_pending_mask))
goto out;
[...]
4. if there is no next event planned for CPU2, we fulfil the first condition and
we jump to the 'out' section without clearing the tick_broadcast_pending_mask
5. CPU2 goes to deep idle again and calls tick_broadcast_oneshot_control with
CLOCK_NOTIFY_EVENT_ENTER but with the tick_broadcast_pending_mask set for
CPU2, leading to the WARNING.
Above, it is mentionned the change moved the CLOCK_EVENT_NOTIFY_EXIT after the
local interrupt were enabled. If it is before, this warning does not occur. My
hypothesis is the code path described before does not happen because when a
broadcast timer expires, dev->next_event.tv64 is always different from KTIME_MAX
because the timer handler did not set the value yet (local interrupt are still
disabled).
I don't see anywhere in the code, a clockevents_notify(ENTER/EXIT) block must be
done with the local interrupt disabled in between, furthermore the function uses
'raw_spin_lock_irqsave' which make me think, we don't care about that.
Invert the conditions and make the tick broadcast code immune from the local
interrupts context.
Signed-off-by: Daniel Lezcano <daniel.lezcano(a)linaro.org>
Reported-by: Joseph Lo <josephl(a)nvidia.com>
---
kernel/time/tick-broadcast.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/time/tick-broadcast.c b/kernel/time/tick-broadcast.c
index d067c01..58d88e8 100644
--- a/kernel/time/tick-broadcast.c
+++ b/kernel/time/tick-broadcast.c
@@ -610,8 +610,6 @@ void tick_broadcast_oneshot_control(unsigned long reason)
} else {
if (cpumask_test_and_clear_cpu(cpu, tick_broadcast_oneshot_mask)) {
clockevents_set_mode(dev, CLOCK_EVT_MODE_ONESHOT);
- if (dev->next_event.tv64 == KTIME_MAX)
- goto out;
/*
* The cpu which was handling the broadcast
* timer marked this cpu in the broadcast
@@ -625,6 +623,8 @@ void tick_broadcast_oneshot_control(unsigned long reason)
tick_broadcast_pending_mask))
goto out;
+ if (dev->next_event.tv64 == KTIME_MAX)
+ goto out;
/*
* If the pending bit is not set, then we are
* either the CPU handling the broadcast
--
1.7.9.5
This patch series adds support for user space save/restore of the VGIC
state. Instead of expanding the ONE_REG interface, which works on
VCPUs, we first introduce support for the new KVM device control API and
the VGIC. Now, instead of calling KVM_CREATE_IRQCHIP, user space can
call KVM_CREATE_DEVICE and perform operations on the device fd, such as
KVM_SET_DEVICE_ATTR to set a device attribute.
We leverage the KVM_{SET/GET}_DEVICE_ATTR API to export the state of the
VGIC to user space. Instead of coming up with our own custom format for
exporting the VGIC state, we simply export all the state visible to an
emulated guest, which must contain the full GIC state to provide
save/restore of the GIC state for power management purposes. This
further provides the benefit of being able to re-use the MMIO emulation
code for the distributor for save/restore.
However, the need to save/restore cpu-specific state demands that user
space can save/restore state accessible through the CPU interface, and
we therefore add an emulation interface for the CPU-specific interface.
This is considered a first attempt, and I am not married to the device
control API. If there are good technical arguments to take another
approach, I am of course willing to discuss this. However, my attempts
with the ONE_REG interface did not look very nice.
[ WARINING: The patch set core functionality is completely untested;
the basic KVM system has been briefly tested on TC2 and it doesn't
seem like I've broken existing functionality. ]
I wanted to get this out early to get feedback on the overall API and
idea, and I'm writing some user QEMU for the user space side to test
the new functionality meanwhile.
Patches are against kvm-arm-next and also available here:
git://git.linaro.org/people/cdall/linux-kvm-arm.git vgic-migrate
Christoffer Dall (7):
KVM: arm-vgic: Support KVM_CREATE_DEVICE for VGIC
KVM: arm-vgic: Set base addr through device API
irqchip: arm-gic: Define additional MMIO offsets and masks
KVM: arm-vgic: Make vgic mmio functions more generic
KVM: arm-vgic: Add vgic reg access from dev attr
KVM: arm-vgic: Add GICD_SPENDSGIR and GICD_CPENDSGIR handlers
KVM: arm-vgic: Support CPU interface reg access
Documentation/virtual/kvm/api.txt | 5 +-
Documentation/virtual/kvm/devices/arm-vgic.txt | 52 +++
arch/arm/include/uapi/asm/kvm.h | 8 +
arch/arm/kvm/arm.c | 3 +-
include/kvm/arm_vgic.h | 2 +-
include/linux/irqchip/arm-gic.h | 14 +
include/linux/kvm_host.h | 1 +
include/uapi/linux/kvm.h | 1 +
virt/kvm/arm/vgic.c | 452 +++++++++++++++++++++++-
virt/kvm/kvm_main.c | 4 +
10 files changed, 522 insertions(+), 20 deletions(-)
create mode 100644 Documentation/virtual/kvm/devices/arm-vgic.txt
--
1.7.9.5
Hi Todd and others,
If we have a multi-package system, where we have multiple instances of struct
policy (per package), currently we can't have multiple instances of same
governor. i.e. We can't have multiple instances of Interactive governor for
multiple packages.
This is a bottleneck for multicluster system, where we want different packages
to use Interactive governor, but with different tunables.
---------x------------x---------
Recently, I have upstreamed this support in 3.10-rc1 for cpufreq core, Ondemand
and Conservative governor. Now is an attempt for Interactive Governor.
I didn't had any clue on what kernel to rebase my patches over as I couldn't
find a 3.10-rc based branch in your tree and so based it on
experimental/android-3.9.
So, this is what this patchset does:
- Backports some important patches from v3.10-rc1/2 to v3.9: First 8 patches
- Added few more supportive patches which might go in rc3: Next 4 patches
- Finally updated Interactive governor: Last 4 patches
So, Review is probably required only for last 4 patches. The last patch is a bit
long, it is mostly rearrangement of the code rather then major update. It is
based on the patchset which I wrote for Ondemand/Conservative governor.
This has been tested on ARM big LITTLE platform which has multiple packages
requiring separate tunables.
Nathan Zimmer (1):
cpufreq: Convert the cpufreq_driver_lock to a rwlock
Stratos Karafotis (1):
cpufreq: governors: Calculate iowait time only when necessary
Viresh Kumar (14):
cpufreq: Add per policy governor-init/exit infrastructure
cpufreq: governor: Implement per policy instances of governors
cpufreq: Call __cpufreq_governor() with correct policy->cpus mask
cpufreq: Don't call __cpufreq_governor() for drivers without target()
cpufreq: governors: Fix CPUFREQ_GOV_POLICY_{INIT|EXIT} notifiers
cpufreq: Issue CPUFREQ_GOV_POLICY_EXIT notifier before dropping
policy refcount
cpufreq: Add EXPORT_SYMBOL_GPL for have_governor_per_policy
cpufreq: governors: Move get_governor_parent_kobj() to cpufreq.c
cpufreq: Drop rwsem lock around CPUFREQ_GOV_POLICY_EXIT
cpufreq: Move get_cpu_idle_time() to cpufreq.c
cpufreq: interactive: Use generic get_cpu_idle_time() from cpufreq.c
cpufreq: interactive: Remove unnecessary cpu_online() check
cpufreq: interactive: Move definition of cpufreq_gov_interactive
downwards
cpufreq: Interactive: Implement per policy instances of governor
drivers/cpufreq/cpufreq.c | 157 ++++++--
drivers/cpufreq/cpufreq_conservative.c | 195 ++++++----
drivers/cpufreq/cpufreq_governor.c | 273 +++++++-------
drivers/cpufreq/cpufreq_governor.h | 120 +++++-
drivers/cpufreq/cpufreq_interactive.c | 663 +++++++++++++++++++--------------
drivers/cpufreq/cpufreq_ondemand.c | 274 ++++++++------
include/linux/cpufreq.h | 19 +-
7 files changed, 1043 insertions(+), 658 deletions(-)
--
1.7.12.rc2.18.g61b472e
Hi Peter/Ingo,
This set contains few more minor fixes that I could find for code responsible
for creating sched domains. They are rebased of my earlier fixes:
Part 1:
https://lkml.org/lkml/2013/6/4/253
Part 2:
https://lkml.org/lkml/2013/6/10/141
They should be applied in this order to avoid conflicts.
My study of "How scheduling domains are created" is almost over now and so
probably this is my last patchset for fixes related to scheduling domains.
Sorry for three separate sets, I sent them as soon as I had few of them sitting
in my tree.
Viresh Kumar (3):
sched: Use cached value of span instead of calling
sched_domain_span()
sched: don't call get_group() for covered cpus
sched: remove WARN_ON(!sd) from init_sched_groups_power()
kernel/sched/core.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
--
1.7.12.rc2.18.g61b472e
Good day Jon,
Please include the included patch in your tree. It is a fix for [1].
Thanks,
Mathieu.
[1]. https://bugs.launchpad.net/linaro-big-little-system/+bug/1097213
-------- Original Message --------
Subject: Re: Update on LP1097213
Date: Mon, 17 Jun 2013 16:31:47 +0100
From: Morten Rasmussen <morten.rasmussen(a)arm.com>
To: Mathieu Poirier <mathieu.poirier(a)linaro.org>
CC: Vincent Guittot <vincent.guittot(a)linaro.org>, Serge Broslavsky
<serge.broslavsky(a)linaro.org>, Amit Kucheria <amit.kucheria(a)linaro.org>,
Nicolas Pitre <nicolas.pitre(a)linaro.org>, Naresh Kamboju
<naresh.kamboju(a)linaro.org>
Hi Mathieu,
I had a quick look at the hmp_next_{up,down}_delay() stuff. It is all
introduced in the patch: "sched: SCHED_HMP multi-domain task migration
control". Reverting it requires some manual conflict fixing and you will
also need to remove the extra hmp_next_down_delay() added by a later patch.
I've attached a revert patch for debugging purposes that should do it all.
I'm not sure if this will just remove the symptom or if the sched_clock
accesses are the true cause of the problem.
I hope it helps,
Morten
On 17/06/13 14:26, Vincent Guittot wrote:
> Mathieu,
>
> Please find below the mail we have discussed during the call
>
> Vincent
>
> On 14 June 2013 15:21, Vincent Guittot <vincent.guittot(a)linaro.org> wrote:
>> On 14 June 2013 15:14, Vincent Guittot <vincent.guittot(a)linaro.org> wrote:
>>> On 14 June 2013 14:39, Mathieu Poirier <mathieu.poirier(a)linaro.org> wrote:
>>>> Anything on this ?!? Morten, Vincent ?
>>>
>>> Hi Mathieu,
>>>
>>> I haven't noticed that the problem can be reproduced on a snowball,
>>> the 1st time i read your email.
>>> It's means that the hmp specific function are also called on smp system ?
>>>
>>> I'm going to look more ddeplyin the code
>>>
>>
>> for_each_online_cpu is used in hmp_force_up_migration but it's not
>> protected against hotplug so it can used a cpu that is going to be
>> unplugged
>>
>> We should probably protect the sequence with get/put_online_cpus
>>
>> Vincent
>>
>>> Vincent
>>>
>>>>
>>>> On 13-06-12 03:13 PM, Mathieu Poirier wrote:
>>>>> Good day gents,
>>>>>
>>>>> I have been working on [1] for a while now, on and off as time
>>>>> permitted. The problem has always been very elusive but definitely
>>>>> present. As some of the notes in the bug report indicate TC2 wasn't the
>>>>> only ARM system I could reproduce this on - snowball suffered from the
>>>>> exact same problem.
>>>>>
>>>>> I started looking at this again for 3.10 and I have good and bad news.
>>>>>
>>>>> The good news is that I can't reproduce the problem anymore if
>>>>> CONFIG_SCHED_HMP is not enabled. I ran the attached script for more
>>>>> than 16 hours without even the hint of a problem. Normally one would
>>>>> get a crash [2] in less than a minute. I won't go so far as claiming
>>>>> that upstream solved the problem. Maybe we are lucky and timing in 3.10
>>>>> simply doesn't allow for the fault to occur. In any case, all we can do
>>>>> is continue monitoring the situation in upcoming versions.
>>>>>
>>>>> On the flip side we have a definite problem with hotplug when
>>>>> CONFIG_SCHED_HMP is defined. The crash in [2] is consistent and can be
>>>>> reproduced at will. Looking at the trace the problem happens in
>>>>> 'select_task_rq_fair' where calls to 'hmp_next_up_delay' and
>>>>> 'hmp_next_down_delay' end up referencing 'cfs_rq_clock_task' where
>>>>> cfs-rq->rq point to a bogus address.
>>>>>
>>>>> Have a look at line 9 in [2] - this is a little bit of instrumentation I
>>>>> started working on. It basically outputs the new and previous CPUs in
>>>>> 'hmp_[up,down]_migration' conditional statements along with the
>>>>> direction of the migration [3]. In every instances the system was going
>>>>> from the A15 to the A7 cluster. I haven't found a single instance where
>>>>> the opposite was be true.
>>>>>
>>>>> Since this is directly related to our efforts to make the scheduler
>>>>> power aware and based on Ingo's latest rebuttal, I am not sure that it
>>>>> wise for me to continue working on this - specifically if we end up
>>>>> scrapping that portion of the code. I'm eager to hear your opinion.
>>>>>
>>>>> On the flip side it highlights (once again) that we need to invest
>>>>> massively in the hotplug subsystem, more specifically in its relation to
>>>>> the scheduler and the RCU subsystem.
>>>>>
>>>>> Mathieu.
>>>>>
>>>>> PS. I have purposely kept the audience to a minimum - forward as you
>>>>> see fit.
>>>>>
>>>>> [1]. https://bugs.launchpad.net/linaro-big-little-system/+bug/1188778
>>>>> [2]. https://pastebin.linaro.org/view/0751c84b
>>>>> [3]. https://pastebin.linaro.org/view/4491ee27
>>>>>
>>>>
>
-- IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended
recipient, please notify the sender immediately and do not disclose the
contents to any other person, use it for any purpose, or store or copy
the information in any medium. Thank you.