Hi,
I was looking at the code of cpuidle menu governor. Have some queries
regarding the function
performance_multiplier().
1. In mainline kernel it does -
mult += 2 * get_loadavg();
However, in linux-linaro-tracking, its commented out with below comment -
/*
* this doesn't work as intended - it is almost always 0, but can
* sometimes, depending on workload, spike very high
into the hundreds
* even when the average cpu load is under 10%.
*/
/* mult += 2 * get_loadavg(); */
Does this change need to be upstreamed?
2. In the next line the code does -
/* for IO wait tasks (per cpu!) we add 5x each */
mult += 10 * nr_iowait_cpu(smp_processor_id());
Why is the multiplication by 10? Is the code assuming there are
only 2 cpus (2 * 5)?
Should it be mult += 5 * nr_iowait(); as per comment?
or
for_each_online_cpu(cpu)
mult += 5 * nr_iowait_cpu(cpu);
since we probably want to consider only online cpus?
--
Thanks,
-Meraj
idle_exit event is the first event after a core exits
idle state. So this should be traced before local irq
is ebabled. Likewise idle_entry is the last event before
a core enters idle state. This will ease visualising the
cpu idle state from kernel traces.
Signed-off-by: Sandeep Tripathy <sandeep.tripathy(a)linaro.org>
---
drivers/cpuidle/cpuidle.c | 3 +++
kernel/sched/idle.c | 4 ----
2 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
index 8236746..97680d0 100644
--- a/drivers/cpuidle/cpuidle.c
+++ b/drivers/cpuidle/cpuidle.c
@@ -99,12 +99,15 @@ int cpuidle_enter_state(struct cpuidle_device *dev, struct cpuidle_driver *drv,
ktime_t time_start, time_end;
s64 diff;
+ trace_cpu_idle_rcuidle(index, dev->cpu);
time_start = ktime_get();
entered_state = target_state->enter(dev, drv, index);
time_end = ktime_get();
+ trace_cpu_idle_rcuidle(PWR_EVENT_EXIT, dev->cpu);
+
if (!cpuidle_state_is_coupled(dev, drv, entered_state))
local_irq_enable();
diff --git a/kernel/sched/idle.c b/kernel/sched/idle.c
index 8f4390a..07c446a 100644
--- a/kernel/sched/idle.c
+++ b/kernel/sched/idle.c
@@ -141,7 +141,6 @@ static int cpuidle_idle_call(void)
&dev->cpu);
if (!ret) {
- trace_cpu_idle_rcuidle(next_state, dev->cpu);
/*
* Enter the idle state previously
@@ -154,9 +153,6 @@ static int cpuidle_idle_call(void)
entered_state = cpuidle_enter(drv, dev,
next_state);
- trace_cpu_idle_rcuidle(PWR_EVENT_EXIT,
- dev->cpu);
-
if (broadcast)
clockevents_notify(
CLOCK_EVT_NOTIFY_BROADCAST_EXIT,
--
1.9.1
hrtimer_start*() family never fails to enqueue a hrtimer to a clock-base. The
only special case is when the hrtimer was in past. If it is getting enqueued to
local CPUs's clock-base, we raise a softirq and exit, else we handle that on
next interrupt on remote CPU.
At several places in the kernel, we try to make sure if hrtimer was added
properly or not by calling hrtimer_active(), like:
hrtimer_start(timer, expires, mode);
if (hrtimer_active(timer)) {
/* Added successfully */
} else {
/* Was added in the past */
}
As hrtimer_start*() never fails, hrtimer_active() is guaranteed to return '1'.
So, there is no point calling hrtimer_active().
First patch adds a WARN_ON_ONCE() to __hrtimer_start_range_ns() to make sure
hrtimers are always enqueued from it. Next 6 patches update several parts of
kernel to drop calls to hrtimer_active() after starting a hrtimer.
Rebased over 3.16-rc4 and pushed here:
git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/linux.git hrtimer/drop-hrtimer-active-calls
Cc: Darren Hart <dvhart(a)linux.intel.com>
Cc: "David S. Miller" <davem(a)davemloft.net>
Cc: Ingo Molnar <mingo(a)redhat.com>
Cc: netdev(a)vger.kernel.org
Cc: Peter Zijlstra <peterz(a)infradead.org>
Viresh Kumar (7):
hrtimer: Warn if hrtimer_start*() failed to enqueue hrtimer
hrtimer: don't check for active hrtimer after adding it
tick: don't check for active hrtimer after adding it
sched: don't check for active hrtimer after adding it
futex: don't check for active hrtimer after adding it
rtmutex: don't check for active hrtimer after adding it
net: don't check for active hrtimer after adding it
kernel/futex.c | 5 +----
kernel/hrtimer.c | 6 ++----
kernel/locking/rtmutex.c | 5 +----
kernel/sched/core.c | 20 +++++++++-----------
kernel/sched/deadline.c | 2 +-
kernel/time/tick-sched.c | 45 ++++++++++++++++++---------------------------
net/core/pktgen.c | 2 --
7 files changed, 32 insertions(+), 53 deletions(-)
--
2.0.0.rc2
This is only relevant to implementations with multiple clusters, where clusters
have separate clock lines but all CPUs within a cluster share it.
Consider a dual cluster platform with 2 cores per cluster. During suspend we
start offlining CPUs from 1 to 3. When CPU2 is remove, policy->kobj would be
moved to CPU3 and when CPU3 goes down we wouldn't free policy or its kobj.
Now on resume, we will get CPU2 before CPU3 and will call __cpufreq_add_dev().
We will recover the old policy and update policy->cpu from 3 to 2 from
update_policy_cpu().
But the kobj is still tied to CPU3 and wasn't moved to CPU2. We wouldn't create
a link for CPU2, but would try that while bringing CPU3 online. Which will
report errors as CPU3 already has kobj assigned to it.
This bug got introduced with commit 42f921a, which overlooked this scenario.
To fix this, lets move kobj to the new policy->cpu while bringing first CPU of a
cluster back.
Fixes: ("42f921a cpufreq: remove sysfs files for CPUs which failed to come back after resume")
Cc: Stable <stable(a)vger.kernel.org> # 3.13+
Reported-by: Bu Yitian <ybu(a)qti.qualcomm.com>
Reported-by: Saravana Kannan <skannan(a)codeaurora.org>
Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org>
---
Hi Rafael,
This is for 3.16 release, please take it once Yitian/Saravana test this out.
@Yitian/Saravana: Sorry of overlooking this when both of you reported this
first. I (and Srivatsa as well) was damn sure that this scenario is taken into
account in current code and a close look proved that wrong.
I couldn't test it out, can any of you please see if it fixes things for you?
drivers/cpufreq/cpufreq.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 62259d2..6f02485 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -1153,10 +1153,12 @@ static int __cpufreq_add_dev(struct device *dev, struct subsys_interface *sif)
* the creation of a brand new one. So we need to perform this update
* by invoking update_policy_cpu().
*/
- if (recover_policy && cpu != policy->cpu)
+ if (recover_policy && cpu != policy->cpu) {
update_policy_cpu(policy, cpu);
- else
+ WARN_ON(kobject_move(&policy->kobj, &dev->kobj));
+ } else {
policy->cpu = cpu;
+ }
cpumask_copy(policy->cpus, cpumask_of(cpu));
--
2.0.0.rc2
We do report driver's successful {un}registration from cpufreq core, but is done
with pr_debug() and so this doesn't appear in boot logs.
Convert this to pr_info() to make it visible in logs.
Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org>
---
drivers/cpufreq/cpufreq.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 62259d2..63d8f8f 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -2468,7 +2468,7 @@ int cpufreq_register_driver(struct cpufreq_driver *driver_data)
}
register_hotcpu_notifier(&cpufreq_cpu_notifier);
- pr_debug("driver %s up and running\n", driver_data->name);
+ pr_info("driver %s up and running\n", driver_data->name);
return 0;
err_if_unreg:
@@ -2499,7 +2499,7 @@ int cpufreq_unregister_driver(struct cpufreq_driver *driver)
if (!cpufreq_driver || (driver != cpufreq_driver))
return -EINVAL;
- pr_debug("unregistering driver %s\n", driver->name);
+ pr_info("unregistering driver %s\n", driver->name);
subsys_interface_unregister(&cpufreq_interface);
if (cpufreq_boost_supported())
--
2.0.0.rc2
Lorenzo and Mark agreed on the following updated patch from Lorenzo:
http://www.spinics.net/lists/arm-kernel/msg336998.html
W.r.t. cluster numbering, we're now back to where we were with the
the original patch sent out in April:
https://lkml.org/lkml/2014/4/22/951
Were there any other objections to this approach?
AFAICT, this patch should be good to go for 3.16.
------->8--------
Create cpu topology based on MPIDR. When hardware sets MPIDR to sane
values, this method will always work. Therefore it should also work well
as the fallback method. [1]
When we have multiple processing elements in the system, we create
the cpu topology by mapping each affinity level (from lowest to highest)
to threads (if they exist), cores, and clusters.
[1] http://www.spinics.net/lists/arm-kernel/msg317445.html
Acked-by: Lorenzo Pieralisi <lorenzo.pieralisi(a)arm.com>
Signed-off-by: Zi Shen Lim <zlim(a)broadcom.com>
Signed-off-by: Mark Brown <broonie(a)linaro.org>
---
arch/arm64/include/asm/cputype.h | 2 ++
arch/arm64/kernel/topology.c | 47 ++++++++++++++++++++++++++++------------
2 files changed, 35 insertions(+), 14 deletions(-)
diff --git a/arch/arm64/include/asm/cputype.h b/arch/arm64/include/asm/cputype.h
index c404fb0..7639e8b 100644
--- a/arch/arm64/include/asm/cputype.h
+++ b/arch/arm64/include/asm/cputype.h
@@ -18,6 +18,8 @@
#define INVALID_HWID ULONG_MAX
+#define MPIDR_UP_BITMASK (0x1 << 30)
+#define MPIDR_MT_BITMASK (0x1 << 24)
#define MPIDR_HWID_BITMASK 0xff00ffffff
#define MPIDR_LEVEL_BITS_SHIFT 3
diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c
index 43514f9..b6ee26b 100644
--- a/arch/arm64/kernel/topology.c
+++ b/arch/arm64/kernel/topology.c
@@ -20,6 +20,7 @@
#include <linux/of.h>
#include <linux/sched.h>
+#include <asm/cputype.h>
#include <asm/topology.h>
static int __init get_cpu_for_node(struct device_node *node)
@@ -188,13 +189,9 @@ static int __init parse_dt_topology(void)
* Check that all cores are in the topology; the SMP code will
* only mark cores described in the DT as possible.
*/
- for_each_possible_cpu(cpu) {
- if (cpu_topology[cpu].cluster_id == -1) {
- pr_err("CPU%d: No topology information specified\n",
- cpu);
+ for_each_possible_cpu(cpu)
+ if (cpu_topology[cpu].cluster_id == -1)
ret = -EINVAL;
- }
- }
out_map:
of_node_put(map);
@@ -219,14 +216,6 @@ static void update_siblings_masks(unsigned int cpuid)
struct cpu_topology *cpu_topo, *cpuid_topo = &cpu_topology[cpuid];
int cpu;
- if (cpuid_topo->cluster_id == -1) {
- /*
- * DT does not contain topology information for this cpu.
- */
- pr_debug("CPU%u: No topology information configured\n", cpuid);
- return;
- }
-
/* update core and thread sibling masks */
for_each_possible_cpu(cpu) {
cpu_topo = &cpu_topology[cpu];
@@ -249,6 +238,36 @@ static void update_siblings_masks(unsigned int cpuid)
void store_cpu_topology(unsigned int cpuid)
{
+ struct cpu_topology *cpuid_topo = &cpu_topology[cpuid];
+ u64 mpidr;
+
+ if (cpuid_topo->cluster_id != -1)
+ goto topology_populated;
+
+ mpidr = read_cpuid_mpidr();
+
+ /* Uniprocessor systems can rely on default topology values */
+ if (mpidr & MPIDR_UP_BITMASK)
+ return;
+
+ /* Create cpu topology mapping based on MPIDR. */
+ if (mpidr & MPIDR_MT_BITMASK) {
+ /* Multiprocessor system : Multi-threads per core */
+ cpuid_topo->thread_id = MPIDR_AFFINITY_LEVEL(mpidr, 0);
+ cpuid_topo->core_id = MPIDR_AFFINITY_LEVEL(mpidr, 1);
+ cpuid_topo->cluster_id = MPIDR_AFFINITY_LEVEL(mpidr, 2);
+ } else {
+ /* Multiprocessor system : Single-thread per core */
+ cpuid_topo->thread_id = -1;
+ cpuid_topo->core_id = MPIDR_AFFINITY_LEVEL(mpidr, 0);
+ cpuid_topo->cluster_id = MPIDR_AFFINITY_LEVEL(mpidr, 1);
+ }
+
+ pr_debug("CPU%u: cluster %d core %d thread %d mpidr %#016llx\n",
+ cpuid, cpuid_topo->cluster_id, cpuid_topo->core_id,
+ cpuid_topo->thread_id, mpidr);
+
+topology_populated:
update_siblings_masks(cpuid);
}
--
1.8.4
Hi Thomas/Daniel et al,
This isn't about the problem I reported earlier, where you advised
to add ONESHOT_STOPPED mode: https://lkml.org/lkml/2014/5/9/508.
Above problem was about stopping the clock-event device when
its not used anymore.
This ($subject) problem was initially spotted on Ivybrdge V2, 12 core
X86 server by Santosh. And then I reproduced it on Dual core ARM
Exynos (isn't that frequent as it was on x86 though).
Problem: Getting spurious ticks where hrtimer_interrupt() returns
without servicing any hrtimers.
Kernel hack to catch this: http://pastebin.com/bTM7nqDc (Over 3.16-rc3)
X86 boot logs: http://pastebin.com/E6axDnsa (search: hrtimer_interrupt)
/proc/cpuinfo: http://pastebin.com/uQx9TmsA
The last I could debug it to is:
- Clockevent device is programmed for time 'x' seconds (Verified this
by storing next-event from within lapic_next_event()).
- Tick fires ~300 us before 'x'
- Traversing through the list of hrtimers doesn't result in any pending
hrtimer and we simply return. And so *spurious* interrupt.
- Happens when ticks are active or stopped (search for "tick-stopped"
in logs)
Driver monitored for x86: arch/x86/kernel/apic/apic.c
Similar behavior observed on exynos with arm_arch_timer.c
I couldn't get any deeper into it to see what's going on. From the behavior
It looks lik the calculations we are doing with dev->mult/shift gives
timeout <= next-event, whereas it should be >= ? Not at all sure though.
Reported-by: Santosh Shukla <santosh.shukla(a)linaro.org>
Note: Even the Hacky patchset that tried to to disable clockevent device
when not used anymore, isn't able to fix it:
https://lkml.org/lkml/2014/5/9/99..
--
viresh
Implement and enable context tracking for arm64 (which is
a prerequisite for FULL_NOHZ support). This patchset
builds upon earlier work by Kevin Hilman and is based on
Will Deacon's tree.
Changes v7 to v8:
* Fix bug where el1_irq was calling ct_user_exit rather than el0_irq
Changes v6 to v7:
* Rename parameter of ct_user_exit from restore to syscall
Changes v5 to v6:
* Don't save far_el1 in x26 in el0_dbg path (not needed)
* TIF_NOHZ processes go through the slow path (so no register
save/restore is needed in ct_user_enter)
Changes v4 to v5:
* Improvement to code restoring far_el1 (suggested by Christopher Covington)
* Improvement to register save/restore in ct_user_enter
Changes v3 to v4:
* Rename parameter of ct_user_exit from save to restore
* Rebased patch to Will Deacon's tree (branch remotes/origin/aarch64
of git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git)
Changes v2 to v3:
* Save/restore necessary registers in ct_user_enter and ct_user_exit
* Annotate "error paths" out of el0_sync with ct_user_exit
Changes v1 to v2:
* Save far_el1 in x26 temporarily
Larry Bassel (2):
arm64: adjust el0_sync so that a function can be called
arm64: enable context tracking
arch/arm64/Kconfig | 1 +
arch/arm64/include/asm/thread_info.h | 4 +++
arch/arm64/kernel/entry.S | 58 +++++++++++++++++++++++++++++++-----
3 files changed, 56 insertions(+), 7 deletions(-)
--
1.8.3.2
(I don't think that discussions below about ptrace() have impact on
this patchset.
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/268923.html
)
(Please apply this patch after my audit patch in order to avoid some
conflict on arm64/Kconfig.)
This patch enables secure computing (system call filtering) on arm64.
System calls can be allowed or denied by loaded bpf-style rules.
Architecture specific part is to run secure_computing() on syscall entry
and check the result. See [2/2]
This code is tested on ARMv8 fast model using libseccomp v2.1.1 with
modifications for arm64 and verified by its "live" tests, 20, 21 and 24.
Changes v3 -> v4:
* removed the following patch and moved it to "arm64: prerequisites for
audit and ftrace" patchset since it is required for audit and ftrace in
case of !COMPAT, too.
"arm64: is_compat_task is defined both in asm/compat.h and linux/compat.h"
Changes v2 -> v3:
* removed unnecessary 'type cast' operations [2/3]
* check for a return value (-1) of secure_computing() explicitly [2/3]
* aligned with the patch, "arm64: split syscall_trace() into separate
functions for enter/exit" [2/3]
* changed default of CONFIG_SECCOMP to n [2/3]
Changes v1 -> v2:
* added generic seccomp.h for arm64 to utilize it [1,2/3]
* changed syscall_trace() to return more meaningful value (-EPERM)
on seccomp failure case [2/3]
* aligned with the change in "arm64: make a single hook to syscall_trace()
for all syscall features" v2 [2/3]
* removed is_compat_task() definition from compat.h [3/3]
AKASHI Takahiro (2):
asm-generic: Add generic seccomp.h for secure computing mode 1
arm64: Add seccomp support
arch/arm64/Kconfig | 14 ++++++++++++++
arch/arm64/include/asm/seccomp.h | 25 +++++++++++++++++++++++++
arch/arm64/include/asm/unistd.h | 3 +++
arch/arm64/kernel/entry.S | 4 ++++
arch/arm64/kernel/ptrace.c | 6 ++++++
include/asm-generic/seccomp.h | 28 ++++++++++++++++++++++++++++
6 files changed, 80 insertions(+)
create mode 100644 arch/arm64/include/asm/seccomp.h
create mode 100644 include/asm-generic/seccomp.h
--
1.7.9.5
- Robustify the user backtrace code, as done on other architectures.
- Provide the symbols resolution when triggering from tracepoints.
Big thanks to Steve Capper for the help in debugging and rephrasing the
commits descriptions.
Stress tested with perf record and tracepoints triggering (-e <tracepoint>),
with unwinding using fp (--call-graph fp) and dwarf info (--call-graph dwarf).
Jean Pihet (3):
ARM: perf: Check that current->mm is alive before getting user
callchain
ARM: perf: disable the pagefault handler when reading from user space
ARM: perf: allow tracing with kernel tracepoints events
arch/arm/include/asm/perf_event.h | 19 +++++++++++++++++++
arch/arm/kernel/perf_event.c | 13 +++++++++++--
2 files changed, 30 insertions(+), 2 deletions(-)
--
1.8.1.2
hrtimer_start*() family never fails to enqueue a hrtimer to a clock-base. In
case the hrtimer was in past and getting added on this_cpu's clock-base, we
raise a softirq and exit.
At several places in the kernel, we try to make sure if hrtimer was added
properly or not by calling hrtimer_active(), like:
hrtimer_start(timer, expires, mode);
if (hrtimer_active(timer)) {
/* Added successfully */
} else {
/* Was added in the past */
}
As hrtimer_start*() never fails, hrtimer_active() is guaranteed to return
'true'. So, there is no point calling hrtimer_active().
Also this is done in while loop at several places, which isn't required if
hrtimer_start*() never fails. Drop those loops as well.
This patch only updates tick-sched.c file currently, others will be fixed if
above explanation holds true.
Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org>
---
This was also raised here and didn't attract many:
https://www.lkml.org/lkml/2014/7/3/559
Pushed here:
git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/linux.git
tick/remove-stale-hrtimer_active
kernel/time/tick-sched.c | 45 ++++++++++++++++++---------------------------
1 file changed, 18 insertions(+), 27 deletions(-)
diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
index 6558b7a..66ca5ab 100644
--- a/kernel/time/tick-sched.c
+++ b/kernel/time/tick-sched.c
@@ -658,9 +658,7 @@ static ktime_t tick_nohz_stop_sched_tick(struct tick_sched *ts,
if (ts->nohz_mode == NOHZ_MODE_HIGHRES) {
hrtimer_start(&ts->sched_timer, expires,
HRTIMER_MODE_ABS_PINNED);
- /* Check, if the timer was already in the past */
- if (hrtimer_active(&ts->sched_timer))
- goto out;
+ goto out;
} else if (!tick_program_event(expires, 0))
goto out;
/*
@@ -844,24 +842,25 @@ static void tick_nohz_restart(struct tick_sched *ts, ktime_t now)
hrtimer_cancel(&ts->sched_timer);
hrtimer_set_expires(&ts->sched_timer, ts->last_tick);
- while (1) {
- /* Forward the time to expire in the future */
- hrtimer_forward(&ts->sched_timer, now, tick_period);
+ /* Forward the time to expire in the future */
+ hrtimer_forward(&ts->sched_timer, now, tick_period);
- if (ts->nohz_mode == NOHZ_MODE_HIGHRES) {
- hrtimer_start_expires(&ts->sched_timer,
- HRTIMER_MODE_ABS_PINNED);
- /* Check, if the timer was already in the past */
- if (hrtimer_active(&ts->sched_timer))
- break;
- } else {
- if (!tick_program_event(
- hrtimer_get_expires(&ts->sched_timer), 0))
- break;
- }
+ if (ts->nohz_mode == NOHZ_MODE_HIGHRES) {
+ hrtimer_start_expires(&ts->sched_timer,
+ HRTIMER_MODE_ABS_PINNED);
+ return;
+ }
+
+ while (1) {
+ if (!tick_program_event(hrtimer_get_expires(&ts->sched_timer),
+ 0))
+ break;
/* Reread time and update jiffies */
now = ktime_get();
tick_do_update_jiffies64(now);
+
+ /* Forward the time to expire in the future */
+ hrtimer_forward(&ts->sched_timer, now, tick_period);
}
}
@@ -1104,7 +1103,6 @@ early_param("skew_tick", skew_tick);
void tick_setup_sched_timer(void)
{
struct tick_sched *ts = &__get_cpu_var(tick_cpu_sched);
- ktime_t now = ktime_get();
/*
* Emulate tick processing via per-CPU hrtimers:
@@ -1123,15 +1121,8 @@ void tick_setup_sched_timer(void)
hrtimer_add_expires_ns(&ts->sched_timer, offset);
}
- for (;;) {
- hrtimer_forward(&ts->sched_timer, now, tick_period);
- hrtimer_start_expires(&ts->sched_timer,
- HRTIMER_MODE_ABS_PINNED);
- /* Check, if the timer was already in the past */
- if (hrtimer_active(&ts->sched_timer))
- break;
- now = ktime_get();
- }
+ hrtimer_forward(&ts->sched_timer, ktime_get(), tick_period);
+ hrtimer_start_expires(&ts->sched_timer, HRTIMER_MODE_ABS_PINNED);
#ifdef CONFIG_NO_HZ_COMMON
if (tick_nohz_enabled) {
--
2.0.0.rc2
Changes in v5:
- Put all registers(exclude translation table associated) definition into each
smmu private file.
Changes in v4:
- Add device_remove hook, so hisi-smmu and smmu-v3 can reclaim other resources.
like dynamic allocted memory. And s1cbt and s2cbt memory are now allocated in
driver(Previously, I hope BIOS to do this).
- Fix bugs according to review comments. CB_FAR_LOW, CB_FAR_HIGH are (n) << 3.
- Change context_map in struct arm_smmu_device to dynamic allocate memory.
- Merge original patch 3 and 4 into one patch.
Changes in v3:
- Split arm-smmu.c into three files: arm-smmu.h arm-smmu-base.c arm-smmu.c.
To build stardard arm-smmu driver, use these three files.
To build hisilicon smmu driver, replace arm-smmu.c with hisi-smmu.c.
Now, hisi smmu driver is not dependent on arm smmu driver. They can seperate
exist, or coexist, when both building and running time.
- Give up Hisilicon private properties.
- Place hooks from global variable into struct arm_smmu_device.
And deleted three hooks: tlb_sync, flush_pgtable and dt_cfg_probe.
- Share the codes which are used to limit the size of smmu ias,oas,ubs.
- Add two little patchs about code style, variable types, etc.
Changes in v2:
- Split Hisilicon smmu implementation in a separate file, hisi-smmu.c
- Refactor arm-smmu.c. Some direct call hardware dependent functions replaced
with hooks. And move common struct and marco definition into arm-smmu.h
- Merge the description of Hisilicon private properties into arm,smmu.txt
I tried to merge hisi-smmu driver into arm-smmu.c, but it looks impossible.
The biggest problem is that too many registers are diffrent: the base address,
the field definition, or present only on one side. And if I use #if, hisi-smmu
and arm-smmu can not coexist in one binary file. Almost need 20 #if.
In addition, SMMUv3 is also not compatible with v2. And something is similar
with hisi-smmu: registers definition and fault handler is different with v2,
but can reuse fdt configuration and memory map. Hence, arm-smmu-base.c and
arm-smmu.h should be shared by all SMMUs(v2, v3 and hisi), and each smmu will
own a private file, like: arm-smmu.c(for v1 and v2), arm-smmu-v3.c, hisi-smmu.c
All marcos which are not used in arm-smmu-base.c and not shared by all SMMUs,
have been placed into each private file, some are duplicated. But I think it
will not bring any maintenance headaches, except when need rename the marcos.
After all, it is hardware dependent.
Zhen Lei (5):
iommu/arm: change some structure member types in arm_smmu_device
iommu/arm: eliminate errors reported by checkpatch
iommu/arm: apart arm-smmu.c to share code with other SMMUs
iommu/hisilicon: Add support for Hisilicon Ltd. System MMU
architecture
documentation/iommu: Add description of Hisilicon SMMU private
binding
.../devicetree/bindings/iommu/arm,smmu.txt | 2 +
drivers/iommu/Kconfig | 14 +
drivers/iommu/Makefile | 2 +
drivers/iommu/arm-smmu-base.c | 1085 +++++++++++++++++
drivers/iommu/arm-smmu.c | 1247 +-------------------
drivers/iommu/arm-smmu.h | 258 ++++
drivers/iommu/hisi-smmu.c | 575 +++++++++
7 files changed, 1985 insertions(+), 1198 deletions(-)
create mode 100644 drivers/iommu/arm-smmu-base.c
create mode 100644 drivers/iommu/arm-smmu.h
create mode 100644 drivers/iommu/hisi-smmu.c
--
1.8.0
From: Mark Brown <broonie(a)linaro.org>
Even though we mostly use GPIO descriptors internally we still use
gpio_request_one() to request so we need to pair that with gpio_free() to
release the GPIO.
Reported-by: Linus Walleij <linus.walleij(a)linaro.org>
Signed-off-by: Mark Brown <broonie(a)linaro.org>
---
drivers/regulator/core.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index c563d93125cd..80381409f856 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -1710,7 +1710,12 @@ static void regulator_ena_gpio_free(struct regulator_dev *rdev)
if (pin->gpiod == rdev->ena_pin->gpiod) {
if (pin->request_count <= 1) {
pin->request_count = 0;
- gpiod_put(pin->gpiod);
+ /*
+ * Since we requested with gpio_request_one()
+ * we still need to free with gpio_free()
+ * for now.
+ */
+ gpio_free(desc_to_gpio(pin->gpiod));
list_del(&pin->list);
kfree(pin);
} else {
--
2.0.0
I'm dropping the RFC tag now as I have the feeling that we are starting to have something in
a good shape that can be pushed for more testing in near future.
This is v7 of my attempt to add support for a generic pci_host_bridge controller created
from a description passed in the device tree.
Changes from v6:
- Made pci_register_io_range() return an error if PCI_IOBASE is not defined. When the
cleanup of PCI_IOBASE use is going to happen, that will catch all those architectures
that don't use virtual mapping of I/O ranges (like x86) or don't support PCI at all.
- Improved the error handling in of_pci_range_to_resource() and made it propagate the
error as well.
- Bail out of the parsing of PCI ranges if of_pci_range_to_resource() fails.
Changes from v5:
- Tested by Tanmay Inamdar, thanks Tanmay!
- dropped v5 5/7 pci: Use parent domain number when allocating child busses.
- Added weak implementation of pcibios_fixup_bridge_ranges() in drivers/pci/host-bridge.c
so that architectures that enable CONFIG_OF and CONFIG_PCI don't suddenly get compilation
errors. While at this, changed the signature of the function so that an error can be
returned.
- With the new error code in pcibios_fixup_bridge_ranges(), reworked the error handling
in pci_host_bridge_of_get_ranges() and of_create_pci_host_bridge().
- Add linux/slab.h to the #include list
- Revisit the error path in pci_create_root_bus[_in_domain]() and fixed the case where
failing to allocate the bus will not return an error.
Changes from v4:
- Export pci_find_host_bridge() to be used by arch code. There is scope for
making the arch/arm64 version of pci_domain_nr the default weak implementation
but that would double the size of this series in order to handle all #define
versions of the pci_domain_nr() function, so I suggest keeping that for a separate
cleanup series.
Changes from v3:
- Dynamically allocate bus_range resource in of_create_pci_host_bridge()
- Fix the domain number used when creating child busses.
- Changed domain number allocator to use atomic operations.
- Use ERR_PTR() to propagate the error out of pci_create_root_bus_in_domain()
and of_create_pci_host_bridge().
Changes from v2:
- Use range->cpu_addr when calling pci_address_to_pio()
- Introduce pci_register_io_range() helper function in order to register
io ranges ahead of their conversion to PIO values. This is needed as no
information is being stored yet regarding the range mapping, making
pci_address_to_pio() fail. Default weak implementation does nothing,
to cover the default weak implementation of pci_address_to_pio() that
expects direct mapping of physical addresses into PIO values (x86 view).
Changes from v1:
- Add patch to fix conversion of IO ranges into IO resources.
- Added a domain_nr member to pci_host_bridge structure, and a new function
to create a root bus in a given domain number. In order to facilitate that
I propose changing the order of initialisation between pci_host_bridge and
it's related bus in pci_create_root_bus() as sort of a rever of 7b5436635800.
This is done in patch 1/4 and 2/4.
- Added a simple allocator of domain numbers in drivers/pci/host-bridge.c. The
code will first try to get a domain id from of_alias_get_id(..., "pci-domain")
and if that fails assign the next unallocated domain id.
- Changed the name of the function that creates the generic host bridge from
pci_host_bridge_of_init to of_create_pci_host_bridge and exported as GPL symbol.
v6 thread here: https://lkml.org/lkml/2014/3/5/179
v5 thread here: https://lkml.org/lkml/2014/3/4/318
v4 thread here: https://lkml.org/lkml/2014/3/3/301
v3 thread here: https://lkml.org/lkml/2014/2/28/216
v2 thread here: https://lkml.org/lkml/2014/2/27/245
v1 thread here: https://lkml.org/lkml/2014/2/3/380
Best regards,
Liviu
Liviu Dudau (6):
pci: Introduce pci_register_io_range() helper function.
pci: OF: Fix the conversion of IO ranges into IO resources.
pci: Create pci_host_bridge before its associated bus in pci_create_root_bus.
pci: Introduce a domain number for pci_host_bridge.
pci: Export find_pci_host_bridge() function.
pci: Add support for creating a generic host_bridge from device tree
drivers/of/address.c | 49 +++++++++++
drivers/pci/host-bridge.c | 161 ++++++++++++++++++++++++++++++++++-
drivers/pci/probe.c | 73 ++++++++++------
include/linux/of_address.h | 14 +--
include/linux/pci.h | 17 ++++
5 files changed, 278 insertions(+), 36 deletions(-)
--
1.9.0
Hello,
On Linaro Android 14.04, with custom compiled kernel (config file attached),
I am facing a kernel crash (details log attached).
I am running on Samsung Arndale Board with Exynos 5250.
Output from my /sys/kernel/debug/gpio looks as below -
root@arndale:/ # cat /sys/kernel/debug/gpio
GPIOs 0-7, GPA0:
gpio-0 (s3c24xx-uart ) in hi
gpio-1 (s3c24xx-uart ) in hi
gpio-2 (s3c24xx-uart ) in lo
gpio-3 (s3c24xx-uart ) in hi
gpio-6 (i2c-bus ) in hi
gpio-7 (i2c-bus ) in hi
GPIOs 9-14, GPA1:
gpio-9 (s3c24xx-uart ) in hi
gpio-10 (s3c24xx-uart ) in hi
gpio-11 (s3c24xx-uart ) in hi
gpio-12 (s3c24xx-uart ) in hi
gpio-13 (s3c24xx-uart ) in lo
gpio-14 (s3c24xx-uart ) in hi
GPIOs 16-23, GPA2:
GPIOs 25-29, GPB0:
GPIOs 31-35, GPB1:
GPIOs 37-40, GPB2:
GPIOs 42-45, GPB3:
gpio-42 (i2c-bus ) in hi
gpio-43 (i2c-bus ) in hi
GPIOs 47-53, GPC0:
gpio-47 (dw-mci-bus ) in lo
gpio-48 (dw-mci-bus ) in hi
gpio-50 (dw-mci-bus ) in hi
gpio-51 (dw-mci-bus ) in hi
gpio-52 (dw-mci-bus ) in hi
gpio-53 (dw-mci-bus ) in hi
GPIOs 55-58, GPC1:
gpio-55 (dw-mci-bus ) in hi
gpio-56 (dw-mci-bus ) in hi
gpio-57 (dw-mci-bus ) in hi
gpio-58 (dw-mci-bus ) in hi
GPIOs 60-66, GPC2:
GPIOs 68-74, GPC3:
gpio-68 (dw-mci-bus ) in lo
gpio-69 (dw-mci-bus ) in hi
gpio-70 (dw-mci-cd ) in lo
gpio-71 (dw-mci-bus ) in lo
gpio-72 (dw-mci-bus ) in hi
gpio-73 (dw-mci-bus ) in hi
gpio-74 (dw-mci-bus ) in hi
GPIOs 76-82, GPC4:
GPIOs 84-87, GPD0:
gpio-84 (s3c24xx-uart ) in lo
gpio-85 (s3c24xx-uart ) in hi
gpio-86 (s3c24xx-uart ) in lo
gpio-87 (s3c24xx-uart ) in hi
GPIOs 89-96, GPD1:
GPIOs 98-103, GPY0:
GPIOs 105-108, GPY1:
GPIOs 110-115, GPY2:
GPIOs 117-124, GPY3:
GPIOs 126-133, GPY4:
GPIOs 135-142, GPY5:
GPIOs 144-151, GPY6:
GPIOs 153-160, GPX0:
GPIOs 162-169, GPX1:
gpio-163 (VDD_33ON_2.8V ) out hi
GPIOs 171-178, GPX2:
gpio-174 (S5M8767 DS2 ) out lo
gpio-175 (S5M8767 DS3 ) out lo
gpio-176 (S5M8767 DS4 ) out lo
GPIOs 180-187, GPX3:
gpio-187 (HPD ) in lo
GPIOs 189-196, GPE0:
GPIOs 198-199, GPE1:
GPIOs 201-204, GPF0:
GPIOs 206-209, GPF1:
GPIOs 211-218, GPG0:
GPIOs 220-227, GPG1:
GPIOs 229-230, GPG2:
GPIOs 232-235, GPH0:
GPIOs 237-244, GPH1:
GPIOs 246-253, GPV0:
GPIOs 255-262, GPV1:
GPIOs 264-271, GPV2:
GPIOs 273-280, GPV3:
GPIOs 282-283, GPV4:
GPIOs 285-291, GPZ:
While trying to export gpio 8, the crash happens -
root@arndale:/ # echo 8 > /sys/class/gpio/export
1Unable to handle kernel NULL pointer dereference at virtual address 00000044
[ 26.700000] Unable to handle kernel NULL pointer dereference at
virtual address 00000044
1pgd = e8848000
[ 26.700000] pgd = e8848000
[00000044] *pgd=00000000[ 26.720000] [00000044] *pgd=00000000
Internal error: Oops: 5 [#1] PREEMPT SMP ARM
[ 26.730000] Internal error: Oops: 5 [#1] PREEMPT SMP ARM
>From above, I noted that gpio 0 - 7 are associated with GPA0 and gpio
9 - 14 with GPA1.
gpio 8 is not existent in /sys/kernel/debug/gpio file.
On the same board, I ran Linaro Saucy server, and there the crash does
not happen. /sys/kernel/debug/gpio
on saucy server looks as below -
GPIOs 0-7, platform/11400000.pinctrl, gpa0:
GPIOs 8-13, platform/11400000.pinctrl, gpa1:
GPIOs 14-21, platform/11400000.pinctrl, gpa2:
GPIOs 22-26, platform/11400000.pinctrl, gpb0:
GPIOs 27-31, platform/11400000.pinctrl, gpb1:
GPIOs 32-35, platform/11400000.pinctrl, gpb2:
GPIOs 36-39, platform/11400000.pinctrl, gpb3:
GPIOs 40-46, platform/11400000.pinctrl, gpc0:
GPIOs 47-50, platform/11400000.pinctrl, gpc1:
GPIOs 51-57, platform/11400000.pinctrl, gpc2:
GPIOs 58-64, platform/11400000.pinctrl, gpc3:
GPIOs 65-68, platform/11400000.pinctrl, gpd0:
GPIOs 69-76, platform/11400000.pinctrl, gpd1:
gpio-76 (usb3503 connect ) out hi
GPIOs 77-83, platform/11400000.pinctrl, gpc4:
GPIOs 84-89, platform/11400000.pinctrl, gpy0:
GPIOs 90-93, platform/11400000.pinctrl, gpy1:
GPIOs 94-99, platform/11400000.pinctrl, gpy2:
GPIOs 100-107, platform/11400000.pinctrl, gpy3:
GPIOs 108-115, platform/11400000.pinctrl, gpy4:
GPIOs 116-123, platform/11400000.pinctrl, gpy5:
GPIOs 124-131, platform/11400000.pinctrl, gpy6:
GPIOs 132-139, platform/11400000.pinctrl, gpx0:
GPIOs 140-147, platform/11400000.pinctrl, gpx1:
gpio-141 (VDD_33ON_2.8V ) out hi
gpio-144 (SW-TACT2 ) in hi
gpio-145 (SW-TACT3 ) in hi
gpio-146 (SW-TACT4 ) in hi
gpio-147 (SW-TACT5 ) in hi
GPIOs 148-155, platform/11400000.pinctrl, gpx2:
gpio-148 (SW-TACT6 ) in hi
gpio-149 (SW-TACT7 ) in hi
gpio-151 (S5M8767 DS2 ) out lo
gpio-152 (S5M8767 DS3 ) out lo
gpio-153 (S5M8767 DS4 ) out lo
GPIOs 156-163, platform/11400000.pinctrl, gpx3:
gpio-161 (usb3503 reset ) out hi
gpio-163 (HPD ) in lo
GPIOs 164-171, platform/13400000.pinctrl, gpe0:
GPIOs 172-173, platform/13400000.pinctrl, gpe1:
GPIOs 174-177, platform/13400000.pinctrl, gpf0:
GPIOs 178-181, platform/13400000.pinctrl, gpf1:
GPIOs 182-189, platform/13400000.pinctrl, gpg0:
GPIOs 190-197, platform/13400000.pinctrl, gpg1:
GPIOs 198-199, platform/13400000.pinctrl, gpg2:
GPIOs 200-203, platform/13400000.pinctrl, gph0:
GPIOs 204-211, platform/13400000.pinctrl, gph1:
GPIOs 212-219, platform/10d10000.pinctrl, gpv0:
GPIOs 220-227, platform/10d10000.pinctrl, gpv1:
GPIOs 228-235, platform/10d10000.pinctrl, gpv2:
GPIOs 236-243, platform/10d10000.pinctrl, gpv3:
GPIOs 244-245, platform/10d10000.pinctrl, gpv4:
GPIOs 246-252, platform/3860000.pinctrl, gpz:
Questions -
1. Is it kernel bug?
2. Why are some gpios (8, 15, 24, etc) not mapped to any device on android?
--
Thanks,
- Meraj
- Robustify the user backtrace code, as done on other architectures.
- Provide the symbols resolution when triggering from tracepoints.
Tested with perf record and tracepoints triggering (-e <tracepoint>), with
unwinding using fp (--call-graph fp) and dwarf info (--call-graph dwarf).
Jean Pihet (3):
ARM: perf: Check that current->mm is alive before getting user
callchain
ARM: perf: disable the pagefault handler when reading from user space
ARM: perf: allow tracing with kernel tracepoints events
arch/arm/include/asm/perf_event.h | 19 +++++++++++++++++++
arch/arm/kernel/perf_event.c | 13 +++++++++++--
2 files changed, 30 insertions(+), 2 deletions(-)
--
1.8.1.2
When expiry is set to KTIME_MAX, we cancel the 'tick-sched' hrtimer in highres
mode and skip reprogramming clockevent device in lowres mode. But, the
clockevent device is already reprogrammed from tick-handler.
We will surely get interrupted atleast one more time at tick-interval.
In highres mode, as there is no tick-sched hrtimer to service, we wouldn't
restart the tick.
But in lowres mode, we unconditionally reschedule the tick every time
tick_nohz_handler() is called. So, even if 'tick_stopped' is set to '1', we will
never be in full dynticks mode.
To fix this, lets skip rescheduling next tick from tick-handler when we are
running tickless.
'tick_stopped' can be set to '1' in one more case, i.e. when expires isn't equal
to KTIME_MAX but is greater than equal to two jiffies. We can still avoid
reprogramming clock device from the tick in this case as it's going to be
reprogrammed from irq_exit() anyway. So we could avoid one useless device write.
Similar piece of code was present initially when dynticks functionality was
first added: 79bf2bb3.
But later commit fb02fbc removed this check to keep jiffies updated for the sake
of long running softirqs, but was later again reverted in ae99286b due to
spurious wakeups. However it was not entirely reverted. The long running
softirqs were asked to fix themselves.
Introducing this change again shouldn't result in 'long running softirqs' issue
discussed in fb02fbc, as tick_nohz_kick_tick() is still commented out.
Reviewed-by: Preeti U Murthy <preeti(a)linux.vnet.ibm.com>
Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org>
---
V1->V2:
- Updated comments a bit for this one and added new patch 2/2.
- Rebased over 3.16-rc3
Pushed here:
git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/linux.git tick/lowres-go-tickless
kernel/time/tick-sched.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
index 6558b7a..bb7b736 100644
--- a/kernel/time/tick-sched.c
+++ b/kernel/time/tick-sched.c
@@ -956,6 +956,12 @@ static void tick_nohz_handler(struct clock_event_device *dev)
tick_sched_do_timer(now);
tick_sched_handle(ts, regs);
+ /*
+ * Skip reprogramming next event if we are running tickless.
+ */
+ if (unlikely(ts->tick_stopped))
+ return;
+
while (tick_nohz_reprogram(ts, now)) {
now = ktime_get();
tick_do_update_jiffies64(now);
--
2.0.0.rc2