* [PATCH RFCv3 01/14] arm64: introduce aarch64_insn_gen_comp_branch_imm()
From: Z Lim @ 2014-07-18 5:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140717172526.GC4844@arm.com>
(resending this email in case the first one got caught in your spam
filter. sorry.)
On Thu, Jul 17, 2014 at 06:25:26PM +0100, Will Deacon wrote:
> On Thu, Jul 17, 2014 at 04:59:10PM +0100, Alexei Starovoitov wrote:
> > On Thu, Jul 17, 2014 at 2:19 AM, Will Deacon <will.deacon@arm.com> wrote:
> > > On Wed, Jul 16, 2014 at 10:19:31PM +0100, Zi Shen Lim wrote:
> > >> >
> > >> > Is a BUG_ON justifiable here? Is there not a nicer way to fail?
> > >>
> > >> In general, it'd be nice if we returned something like -EINVAL and
> > >> have all callers handle failures. Today all code gen functions return
> > >> the u32 instruction and there's no error handling by callers.
> > >> I think following the precedence (aarch64_insn_gen_branch_imm())
> > >> of failing with BUG_ON is a reasonable tradeoff.
> > >
> > > Well, I don't necessarily agree with that BUG_ON, either :)
> > > I take it eBPF doesn't have a `trap' instruction or similar? Otherwise, we
> > > could generate that and avoid having to propagate errors directly to the
> > > caller.
> > >
> > >> In this case here, when we hit the default (failure) case, that means
> > >> there's a serious error of attempting to use an unsupported
> > >> variant. I think we're better off failing hard here than trying to
> > >> arbitrarily "fallback" on a default choice.
> > >
> > > It might be a serious error for BPF, but a BUG_ON brings down the entire
> > > machine, which I think is unfortunate.
> >
> > There is some misunderstanding here. Here BUG_ON will trigger
> > only on actual bug in JIT implementation, it cannot be triggered by user.
> > eBPF program is verified before it reaches JIT, so all instructions are
> > valid and input to JIT is proper. Two instruction are not yet
> > implemented in this JIT and they trigger pr_.._once().
> > So I don't see any issue with this usage of BUG_ON
> > imo living with silent bugs in JIT is more dangerous.
> >
> > For the same reason there is no 'trap' instruction in eBPF.
> > Static verifier checks that program is valid. If there was a 'trap'
> > insn the program would be rejected. Like programs with
> > 'div by zero' are rejected. There is normal 'bpf_exit' insn to
> > return from the program.
>
> Ok, so assuming that BPF doesn't have any issues, I take your point.
> However, we could very easily re-use these functions for things like SMP
> alternatives and kprobes, where simply failing the instruction generation
> might be acceptable.
>
> It just feels like a bit hammer to me, when the machine is probably happily
> scheduling user tasks, responding to interrupts, writing data to disk etc.
Yes I agree with you Will, it'd be truly unfortunate if we inadvertently
allow the entire system to be brought down.
Alexei accurately pointed out that if we ever hit such a case, it'd be a bug
in the BPF JIT implementation (or bug in other in-kernel implementations).
Our BPF JIT implementation actually handles this, making sure that input
to the codegen function is valid, or gracefully fail by not JITing and
falling back on the core BPF interpreter. This way our JIT will not trigger
the BUG_ON.
IMO, other future users of these codegen functions should do the same.
An alternative would be to throw away all the BUG_ON and have callers
check for and handle error conditions. I think this is actually more
dangerous as callers who don't handle the error conditions properly may
end up causing system crash later with subtle (and quite possibly hard to
debug) bugs.
>
> Will
^ permalink raw reply
* [RFC] cpufreq: Add bindings for CPU clock sharing topology
From: Viresh Kumar @ 2014-07-18 5:35 UTC (permalink / raw)
To: linux-arm-kernel
Clock lines may or may not be shared among different CPUs on a platform. When
clock lines are shared between CPUs, they change DVFS state together.
Possible configurations:
1.) All CPUs share a single clock line.
2.) All CPUs have independent clock lines.
3.) CPUs within a group/cluster share clock line but each group/cluster have a
separate line for itself.
There is no generic way available today to detect which CPUs share clock lines
and so this is an attempt towards that.
Much of the information is present in the commit and so no point duplicating it
here.
These are obviously not finalized yet and this is an attempt to initiate a
discussion around this.
Please share your valuable feedback.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
I wasn't sure about the path/name of this file, so please don't blast me on that
:)
.../devicetree/bindings/cpufreq/cpu_clocks.txt | 159 +++++++++++++++++++++
1 file changed, 159 insertions(+)
create mode 100644 Documentation/devicetree/bindings/cpufreq/cpu_clocks.txt
diff --git a/Documentation/devicetree/bindings/cpufreq/cpu_clocks.txt b/Documentation/devicetree/bindings/cpufreq/cpu_clocks.txt
new file mode 100644
index 0000000..30ce9ad
--- /dev/null
+++ b/Documentation/devicetree/bindings/cpufreq/cpu_clocks.txt
@@ -0,0 +1,159 @@
+* Generic CPUFreq clock bindings
+
+Clock lines may or may not be shared among different CPUs on a platform.
+
+Possible configurations:
+1.) All CPUs share a single clock line
+2.) All CPUs have independent clock lines
+3.) CPUs within a group/cluster share clock line but each group/cluster have a
+ separate line for itself
+
+Optional Properties:
+- clock-master: This declares cpu as clock master. Other CPUs can either define
+ "clock-ganged" or "clock-master" property, but shouldn't be missing both.
+
+- clock-ganged: Should have phandle of a cpu declared as "clock-master".
+
+If any cpu node, doesn't have both "clock-master" and "clock-ganged" properties
+defined, it would be assumed that all CPUs on that platform share a single clock
+line. This will help supporting already upstreamed platforms.
+
+
+Examples:
+1.) All CPUs share a single clock line
+
+cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu0: cpu at 0 {
+ compatible = "arm,cortex-a15";
+ reg = <0>;
+ next-level-cache = <&L2>;
+ clock-master;
+ operating-points = <
+ /* kHz uV */
+ 792000 1100000
+ 396000 950000
+ 198000 850000
+ >;
+ clock-latency = <61036>; /* two CLK32 periods */
+ };
+
+ cpu1: cpu at 1 {
+ compatible = "arm,cortex-a15";
+ reg = <1>;
+ next-level-cache = <&L2>;
+ clock-ganged = <&cpu0>;
+ };
+};
+
+OR (clock-master/ganged aren't defined)
+
+cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu0: cpu at 0 {
+ compatible = "arm,cortex-a15";
+ reg = <0>;
+ next-level-cache = <&L2>;
+ operating-points = <
+ /* kHz uV */
+ 792000 1100000
+ 396000 950000
+ 198000 850000
+ >;
+ clock-latency = <61036>; /* two CLK32 periods */
+ };
+
+ cpu1: cpu at 1 {
+ compatible = "arm,cortex-a15";
+ reg = <1>;
+ next-level-cache = <&L2>;
+ };
+};
+
+2.) All CPUs have independent clock lines
+cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu0: cpu at 0 {
+ compatible = "arm,cortex-a15";
+ reg = <0>;
+ next-level-cache = <&L2>;
+ clock-master;
+ operating-points = <
+ /* kHz uV */
+ 792000 1100000
+ 396000 950000
+ 198000 850000
+ >;
+ clock-latency = <61036>; /* two CLK32 periods */
+ };
+
+ cpu1: cpu at 1 {
+ compatible = "arm,cortex-a15";
+ reg = <1>;
+ next-level-cache = <&L2>;
+ clock-master;
+ operating-points = <
+ /* kHz uV */
+ 792000 1100000
+ 396000 950000
+ 198000 850000
+ >;
+ clock-latency = <61036>; /* two CLK32 periods */
+ };
+};
+
+3.) CPUs within a group/cluster share single clock line but each group/cluster
+have a separate line for itself
+
+cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu0: cpu at 0 {
+ compatible = "arm,cortex-a15";
+ reg = <0>;
+ next-level-cache = <&L2>;
+ clock-master;
+ operating-points = <
+ /* kHz uV */
+ 792000 1100000
+ 396000 950000
+ 198000 850000
+ >;
+ clock-latency = <61036>; /* two CLK32 periods */
+ };
+
+ cpu1: cpu at 1 {
+ compatible = "arm,cortex-a15";
+ reg = <1>;
+ next-level-cache = <&L2>;
+ clock-ganged = <&cpu0>;
+ };
+
+ cpu2: cpu at 100 {
+ compatible = "arm,cortex-a7";
+ reg = <100>;
+ next-level-cache = <&L2>;
+ clock-master;
+ operating-points = <
+ /* kHz uV */
+ 792000 950000
+ 396000 750000
+ 198000 450000
+ >;
+ clock-latency = <61036>; /* two CLK32 periods */
+ };
+
+ cpu3: cpu at 101 {
+ compatible = "arm,cortex-a7";
+ reg = <101>;
+ next-level-cache = <&L2>;
+ clock-ganged = <&cpu2>;
+ };
+};
--
2.0.0.rc2
^ permalink raw reply related
* [GIT PULL 2/3] ARM: tegra: move fuse code out of arch/arm
From: Olof Johansson @ 2014-07-18 5:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <53C88A4C.3070304@wwwdotorg.org>
On Thu, Jul 17, 2014 at 7:45 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
> On 07/08/2014 11:47 AM, Olof Johansson wrote:
>> On Tue, Jul 8, 2014 at 6:43 AM, Peter De Schrijver
>> <pdeschrijver@nvidia.com> wrote:
>>> On Mon, Jul 07, 2014 at 02:44:17AM +0200, Olof Johansson wrote:
>>>> On Mon, Jun 23, 2014 at 03:23:45PM -0600, Stephen Warren wrote:
>>>>> This branch moves code related to the Tegra fuses out of arch/arm and
>>>>> into a centralized location which could be shared with ARM64. It also
>>>>> adds support for reading the fuse data through sysfs.
>>>>
>>>> The new/moved misc driver isn't acked by any misc maintainer, so I can't
>>>> take this branch.
>>>>
>>>> I saw no indication from searching the mailing list of that either,
>>>> so it wasn't just a missed acked-by.
>>>>
>>>> I wonder if this code should go under drivers/soc/ instead?
>>>
>>> It's modelled after sunxi_sid.c which lives in drivers/misc/eeprom/.
>>> Originally this driver was also in drivers/misc/eeprom/, but Stephen objected
>>> and therefore it was moved to drivers/misc/fuse. I think that's the right
>>> place still.
>>
>> I disagree, I think this belongs under drivers/soc. Especially since
>> you're adding dependencies on this misc driver from other parts of the
>> kernel / other drivers.
>>
>> I also don't like seeing init calls form platform code down into
>> drivers/misc like you're adding here. Can you please look at doing
>> that as a regular init call setup?
>
> I strongly disagree with using init calls for this kind of thing. There
> are ordering dependencies between the initialization code that can only
> be sanely managed by explicitly calling functions in a particular order;
> there's simply no way to manage this using initcalls. This is exactly
> why the hooks in the ARM machine descriptors exist...
Right, but there are non on 64-bit, so you need to solve it for there
anyway. And once it's solved there, you might as well keep it common
with 32-bit.
-Olof
^ permalink raw reply
* [GIT PULL 2/3] ARM: tegra: move fuse code out of arch/arm
From: Olof Johansson @ 2014-07-18 5:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <53C889FF.4070206@wwwdotorg.org>
On Thu, Jul 17, 2014 at 7:44 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
> On 07/08/2014 07:43 AM, Peter De Schrijver wrote:
>> On Mon, Jul 07, 2014 at 02:44:17AM +0200, Olof Johansson wrote:
>>> On Mon, Jun 23, 2014 at 03:23:45PM -0600, Stephen Warren wrote:
>>>> This branch moves code related to the Tegra fuses out of arch/arm and
>>>> into a centralized location which could be shared with ARM64. It also
>>>> adds support for reading the fuse data through sysfs.
>>>
>>> The new/moved misc driver isn't acked by any misc maintainer, so I can't
>>> take this branch.
>>>
>>> I saw no indication from searching the mailing list of that either,
>>> so it wasn't just a missed acked-by.
>>>
>>> I wonder if this code should go under drivers/soc/ instead?
>>
>> It's modelled after sunxi_sid.c which lives in drivers/misc/eeprom/.
>> Originally this driver was also in drivers/misc/eeprom/, but Stephen objected
>> and therefore it was moved to drivers/misc/fuse. I think that's the right
>> place still. We anyway need this driver for sata and xhci.
>
> Sigh. This is exactly why (a) I suggested during that thread that the
> driver should be in drivers/soc not drivers/misc and (b) I sent the pull
> requests early enough so I could deal with any objections before my
> vacation:-( I wish people would just respond to my review comments by
> implementing them rather than persuading me to do the wrong thing. Since
> this is all a dependency for pretty much everything for Tegra for 3.17,
> I guess we should just drop all the Tegra pull requests for 3.17 and
> we'll have to redo all the patches for 3.18:-( But if Thierry can (or
> already has in another thread I haven't seen while on vacation) sort
> this out be redoing all the Tegra branches, that might be fine too.
Thierry has been following up on it, I don't think we're too late for 3.17 yet.
-Olof
^ permalink raw reply
* [PATCH 4/4] (RFC) X86: add IPI tracepoints
From: Nicolas Pitre @ 2014-07-18 5:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405660735-13408-1-git-send-email-nicolas.pitre@linaro.org>
On X86 there are already tracepoints for IRQ vectors through which IPIs
are handled. However this is highly X86 specific, and the IPI signaling
is not currently traced.
This is an attempt at adding generic IPI tracepoints to X86.
Signed-off-by: Nicolas Pitre <nico@linaro.org>
---
arch/x86/kernel/smp.c | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/arch/x86/kernel/smp.c b/arch/x86/kernel/smp.c
index be8e1bde07..e154d176cf 100644
--- a/arch/x86/kernel/smp.c
+++ b/arch/x86/kernel/smp.c
@@ -31,6 +31,12 @@
#include <asm/apic.h>
#include <asm/nmi.h>
#include <asm/trace/irq_vectors.h>
+
+#define CREATE_TRACE_POINTS
+#undef TRACE_INCLUDE_PATH
+#undef TRACE_INCLUDE_FILE
+#include <trace/events/ipi.h>
+
/*
* Some notes on x86 processor bugs affecting SMP operation:
*
@@ -124,11 +130,13 @@ static void native_smp_send_reschedule(int cpu)
WARN_ON(1);
return;
}
+ trace_ipi_raise(cpumask_of(cpu), tracepoint_string("RESCHEDULE"));
apic->send_IPI_mask(cpumask_of(cpu), RESCHEDULE_VECTOR);
}
void native_send_call_func_single_ipi(int cpu)
{
+ trace_ipi_raise(cpumask_of(cpu), tracepoint_string("CALL_FUNCTION_SINGLE"));
apic->send_IPI_mask(cpumask_of(cpu), CALL_FUNCTION_SINGLE_VECTOR);
}
@@ -136,6 +144,8 @@ void native_send_call_func_ipi(const struct cpumask *mask)
{
cpumask_var_t allbutself;
+ trace_ipi_raise(mask, tracepoint_string("CALL_FUNCTION"));
+
if (!alloc_cpumask_var(&allbutself, GFP_ATOMIC)) {
apic->send_IPI_mask(mask, CALL_FUNCTION_VECTOR);
return;
@@ -252,8 +262,10 @@ finish:
*/
static inline void __smp_reschedule_interrupt(void)
{
+ trace_ipi_entry(tracepoint_string("RESCHEDULE"));
inc_irq_stat(irq_resched_count);
scheduler_ipi();
+ trace_ipi_exit(tracepoint_string("RESCHEDULE"));
}
__visible void smp_reschedule_interrupt(struct pt_regs *regs)
@@ -291,8 +303,10 @@ __visible void smp_trace_reschedule_interrupt(struct pt_regs *regs)
static inline void __smp_call_function_interrupt(void)
{
+ trace_ipi_entry(tracepoint_string("CALL_FUNCTION"));
generic_smp_call_function_interrupt();
inc_irq_stat(irq_call_count);
+ trace_ipi_exit(tracepoint_string("CALL_FUNCTION"));
}
__visible void smp_call_function_interrupt(struct pt_regs *regs)
@@ -313,8 +327,10 @@ __visible void smp_trace_call_function_interrupt(struct pt_regs *regs)
static inline void __smp_call_function_single_interrupt(void)
{
+ trace_ipi_entry(tracepoint_string("CALL_FUNCTION_SINGLE"));
generic_smp_call_function_single_interrupt();
inc_irq_stat(irq_call_count);
+ trace_ipi_exit(tracepoint_string("CALL_FUNCTION_SINGLE"));
}
__visible void smp_call_function_single_interrupt(struct pt_regs *regs)
--
1.8.4.108.g55ea5f6
^ permalink raw reply related
* [PATCH 3/4] ARM64: add IPI tracepoints
From: Nicolas Pitre @ 2014-07-18 5:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405660735-13408-1-git-send-email-nicolas.pitre@linaro.org>
The strings used to list IPIs in /proc/interrupts are reused for tracing
purposes.
While at it, the code is slightly cleaned up so the ipi_types array
indices are no longer offset by IPI_RESCHEDULE whose value is 0 anyway.
Signed-off-by: Nicolas Pitre <nico@linaro.org>
---
arch/arm64/kernel/smp.c | 67 +++++++++++++++++++++++++++++++------------------
1 file changed, 42 insertions(+), 25 deletions(-)
diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
index 40f38f46c8..78a5904994 100644
--- a/arch/arm64/kernel/smp.c
+++ b/arch/arm64/kernel/smp.c
@@ -50,6 +50,9 @@
#include <asm/tlbflush.h>
#include <asm/ptrace.h>
+#define CREATE_TRACE_POINTS
+#include <trace/events/ipi.h>
+
/*
* as from 2.5, kernels no longer have an init_tasks structure
* so we need some other way of telling a new secondary core
@@ -307,8 +310,6 @@ void __init smp_prepare_boot_cpu(void)
set_my_cpu_offset(per_cpu_offset(smp_processor_id()));
}
-static void (*smp_cross_call)(const struct cpumask *, unsigned int);
-
/*
* Enumerate the possible CPU set from the device tree and build the
* cpu logical map array containing MPIDR values related to logical
@@ -463,32 +464,19 @@ void __init smp_prepare_cpus(unsigned int max_cpus)
}
}
+static void (*__smp_cross_call)(const struct cpumask *, unsigned int);
void __init set_smp_cross_call(void (*fn)(const struct cpumask *, unsigned int))
{
- smp_cross_call = fn;
-}
-
-void arch_send_call_function_ipi_mask(const struct cpumask *mask)
-{
- smp_cross_call(mask, IPI_CALL_FUNC);
-}
-
-void arch_send_call_function_single_ipi(int cpu)
-{
- smp_cross_call(cpumask_of(cpu), IPI_CALL_FUNC_SINGLE);
+ __smp_cross_call = fn;
}
-#ifdef CONFIG_IRQ_WORK
-void arch_irq_work_raise(void)
-{
- if (smp_cross_call)
- smp_cross_call(cpumask_of(smp_processor_id()), IPI_IRQ_WORK);
-}
+static const char *ipi_types[NR_IPI]
+#ifdef CONFIG_TRACING
+__tracepoint_string
#endif
-
-static const char *ipi_types[NR_IPI] = {
-#define S(x,s) [x - IPI_RESCHEDULE] = s
+= {
+#define S(x,s) [x] = s
S(IPI_RESCHEDULE, "Rescheduling interrupts"),
S(IPI_CALL_FUNC, "Function call interrupts"),
S(IPI_CALL_FUNC_SINGLE, "Single function call interrupts"),
@@ -497,12 +485,18 @@ static const char *ipi_types[NR_IPI] = {
S(IPI_IRQ_WORK, "IRQ work interrupts"),
};
+static void smp_cross_call(const struct cpumask *target, unsigned int ipinr)
+{
+ trace_ipi_raise(target, ipi_types[ipinr]);
+ __smp_cross_call(target, ipinr);
+}
+
void show_ipi_list(struct seq_file *p, int prec)
{
unsigned int cpu, i;
for (i = 0; i < NR_IPI; i++) {
- seq_printf(p, "%*s%u:%s", prec - 1, "IPI", i + IPI_RESCHEDULE,
+ seq_printf(p, "%*s%u:%s", prec - 1, "IPI", i,
prec >= 4 ? " " : "");
for_each_online_cpu(cpu)
seq_printf(p, "%10u ",
@@ -522,6 +516,24 @@ u64 smp_irq_stat_cpu(unsigned int cpu)
return sum;
}
+void arch_send_call_function_ipi_mask(const struct cpumask *mask)
+{
+ smp_cross_call(mask, IPI_CALL_FUNC);
+}
+
+void arch_send_call_function_single_ipi(int cpu)
+{
+ smp_cross_call(cpumask_of(cpu), IPI_CALL_FUNC_SINGLE);
+}
+
+#ifdef CONFIG_IRQ_WORK
+void arch_irq_work_raise(void)
+{
+ if (__smp_cross_call)
+ smp_cross_call(cpumask_of(smp_processor_id()), IPI_IRQ_WORK);
+}
+#endif
+
static DEFINE_RAW_SPINLOCK(stop_lock);
/*
@@ -553,8 +565,10 @@ void handle_IPI(int ipinr, struct pt_regs *regs)
unsigned int cpu = smp_processor_id();
struct pt_regs *old_regs = set_irq_regs(regs);
- if (ipinr >= IPI_RESCHEDULE && ipinr < IPI_RESCHEDULE + NR_IPI)
- __inc_irq_stat(cpu, ipi_irqs[ipinr - IPI_RESCHEDULE]);
+ if ((unsigned)ipinr < NR_IPI) {
+ trace_ipi_entry(ipi_types[ipinr]);
+ __inc_irq_stat(cpu, ipi_irqs[ipinr]);
+ }
switch (ipinr) {
case IPI_RESCHEDULE:
@@ -599,6 +613,9 @@ void handle_IPI(int ipinr, struct pt_regs *regs)
pr_crit("CPU%u: Unknown IPI message 0x%x\n", cpu, ipinr);
break;
}
+
+ if ((unsigned)ipinr < NR_IPI)
+ trace_ipi_exit(ipi_types[ipinr]);
set_irq_regs(old_regs);
}
--
1.8.4.108.g55ea5f6
^ permalink raw reply related
* [PATCH 2/4] ARM: add IPI tracepoints
From: Nicolas Pitre @ 2014-07-18 5:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405660735-13408-1-git-send-email-nicolas.pitre@linaro.org>
The strings used to list IPIs in /proc/interrupts are reused for tracing
purposes.
Signed-off-by: Nicolas Pitre <nico@linaro.org>
---
arch/arm/kernel/smp.c | 72 ++++++++++++++++++++++++++++++++-------------------
1 file changed, 45 insertions(+), 27 deletions(-)
diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
index 7c4fada440..daedff319b 100644
--- a/arch/arm/kernel/smp.c
+++ b/arch/arm/kernel/smp.c
@@ -47,6 +47,9 @@
#include <asm/mach/arch.h>
#include <asm/mpu.h>
+#define CREATE_TRACE_POINTS
+#include <trace/events/ipi.h>
+
/*
* as from 2.5, kernels no longer have an init_tasks structure
* so we need some other way of telling a new secondary core
@@ -430,38 +433,19 @@ void __init smp_prepare_cpus(unsigned int max_cpus)
}
}
-static void (*smp_cross_call)(const struct cpumask *, unsigned int);
+static void (*__smp_cross_call)(const struct cpumask *, unsigned int);
void __init set_smp_cross_call(void (*fn)(const struct cpumask *, unsigned int))
{
- if (!smp_cross_call)
- smp_cross_call = fn;
-}
-
-void arch_send_call_function_ipi_mask(const struct cpumask *mask)
-{
- smp_cross_call(mask, IPI_CALL_FUNC);
-}
-
-void arch_send_wakeup_ipi_mask(const struct cpumask *mask)
-{
- smp_cross_call(mask, IPI_WAKEUP);
-}
-
-void arch_send_call_function_single_ipi(int cpu)
-{
- smp_cross_call(cpumask_of(cpu), IPI_CALL_FUNC_SINGLE);
+ if (!__smp_cross_call)
+ __smp_cross_call = fn;
}
-#ifdef CONFIG_IRQ_WORK
-void arch_irq_work_raise(void)
-{
- if (is_smp())
- smp_cross_call(cpumask_of(smp_processor_id()), IPI_IRQ_WORK);
-}
+static const char *ipi_types[NR_IPI]
+#ifdef CONFIG_TRACING
+__tracepoint_string
#endif
-
-static const char *ipi_types[NR_IPI] = {
+= {
#define S(x,s) [x] = s
S(IPI_WAKEUP, "CPU wakeup interrupts"),
S(IPI_TIMER, "Timer broadcast interrupts"),
@@ -473,6 +457,12 @@ static const char *ipi_types[NR_IPI] = {
S(IPI_COMPLETION, "completion interrupts"),
};
+static void smp_cross_call(const struct cpumask *target, unsigned int ipinr)
+{
+ trace_ipi_raise(target, ipi_types[ipinr]);
+ __smp_cross_call(target, ipinr);
+}
+
void show_ipi_list(struct seq_file *p, int prec)
{
unsigned int cpu, i;
@@ -499,6 +489,29 @@ u64 smp_irq_stat_cpu(unsigned int cpu)
return sum;
}
+void arch_send_call_function_ipi_mask(const struct cpumask *mask)
+{
+ smp_cross_call(mask, IPI_CALL_FUNC);
+}
+
+void arch_send_wakeup_ipi_mask(const struct cpumask *mask)
+{
+ smp_cross_call(mask, IPI_WAKEUP);
+}
+
+void arch_send_call_function_single_ipi(int cpu)
+{
+ smp_cross_call(cpumask_of(cpu), IPI_CALL_FUNC_SINGLE);
+}
+
+#ifdef CONFIG_IRQ_WORK
+void arch_irq_work_raise(void)
+{
+ if (is_smp())
+ smp_cross_call(cpumask_of(smp_processor_id()), IPI_IRQ_WORK);
+}
+#endif
+
#ifdef CONFIG_GENERIC_CLOCKEVENTS_BROADCAST
void tick_broadcast(const struct cpumask *mask)
{
@@ -556,8 +569,10 @@ void handle_IPI(int ipinr, struct pt_regs *regs)
unsigned int cpu = smp_processor_id();
struct pt_regs *old_regs = set_irq_regs(regs);
- if (ipinr < NR_IPI)
+ if ((unsigned)ipinr < NR_IPI) {
+ trace_ipi_entry(ipi_types[ipinr]);
__inc_irq_stat(cpu, ipi_irqs[ipinr]);
+ }
switch (ipinr) {
case IPI_WAKEUP:
@@ -612,6 +627,9 @@ void handle_IPI(int ipinr, struct pt_regs *regs)
cpu, ipinr);
break;
}
+
+ if ((unsigned)ipinr < NR_IPI)
+ trace_ipi_exit(ipi_types[ipinr]);
set_irq_regs(old_regs);
}
--
1.8.4.108.g55ea5f6
^ permalink raw reply related
* [PATCH 1/4] tracepoint: add generic tracepoint definitions for IPI tracing
From: Nicolas Pitre @ 2014-07-18 5:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405660735-13408-1-git-send-email-nicolas.pitre@linaro.org>
The Inter Processor Interrupt is used to make another processor do a
specific action such as rescheduling tasks, signal a timer event or
execute something in another CPU's context. IRQs are already traceable
but IPIs were not. Tracing them is useful for monitoring IPI latency,
or to verify when they are the source of CPU wake-ups with power
management implications.
Three trace hooks are defined: ipi_raise, ipi_entry and ipi_exit. To make
them portable, a string is used to identify them and correlate related
events. Additionally, ipi_raise records a bitmask representing targeted
CPUs.
Signed-off-by: Nicolas Pitre <nico@linaro.org>
---
include/trace/events/ipi.h | 89 ++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 89 insertions(+)
create mode 100644 include/trace/events/ipi.h
diff --git a/include/trace/events/ipi.h b/include/trace/events/ipi.h
new file mode 100644
index 0000000000..834a7362a6
--- /dev/null
+++ b/include/trace/events/ipi.h
@@ -0,0 +1,89 @@
+#undef TRACE_SYSTEM
+#define TRACE_SYSTEM ipi
+
+#if !defined(_TRACE_IPI_H) || defined(TRACE_HEADER_MULTI_READ)
+#define _TRACE_IPI_H
+
+#include <linux/tracepoint.h>
+
+/**
+ * ipi_raise - called when a smp cross call is made
+ *
+ * @mask: mask of recipient CPUs for the IPI
+ * @reason: string identifying the IPI purpose
+ *
+ * It is necessary for @reason to be a static string declared with
+ * __tracepoint_string.
+ */
+TRACE_EVENT(ipi_raise,
+
+ TP_PROTO(const struct cpumask *mask, const char *reason),
+
+ TP_ARGS(mask, reason),
+
+ TP_STRUCT__entry(
+ __bitmask(target_cpus, nr_cpumask_bits)
+ __field(const char *, reason)
+ ),
+
+ TP_fast_assign(
+ __assign_bitmask(target_cpus, cpumask_bits(mask), nr_cpumask_bits);
+ __entry->reason = reason;
+ ),
+
+ TP_printk("target_mask=%s (%s)", __get_bitmask(target_cpus), __entry->reason)
+);
+
+DECLARE_EVENT_CLASS(ipi_handler,
+
+ TP_PROTO(const char *reason),
+
+ TP_ARGS(reason),
+
+ TP_STRUCT__entry(
+ __field(const char *, reason)
+ ),
+
+ TP_fast_assign(
+ __entry->reason = reason;
+ ),
+
+ TP_printk("(%s)", __entry->reason)
+);
+
+/**
+ * ipi_entry - called immediately before the IPI handler
+ *
+ * @reason: string identifying the IPI purpose
+ *
+ * It is necessary for @reason to be a static string declared with
+ * __tracepoint_string, ideally the same as used with trace_ipi_raise
+ * for that IPI.
+ */
+DEFINE_EVENT(ipi_handler, ipi_entry,
+
+ TP_PROTO(const char *reason),
+
+ TP_ARGS(reason)
+);
+
+/**
+ * ipi_exit - called immediately after the IPI handler returns
+ *
+ * @reason: string identifying the IPI purpose
+ *
+ * It is necessary for @reason to be a static string declared with
+ * __tracepoint_string, ideally the same as used with trace_ipi_raise for
+ * that IPI.
+ */
+DEFINE_EVENT(ipi_handler, ipi_exit,
+
+ TP_PROTO(const char *reason),
+
+ TP_ARGS(reason)
+);
+
+#endif /* _TRACE_IPI_H */
+
+/* This part must be outside protection */
+#include <trace/define_trace.h>
--
1.8.4.108.g55ea5f6
^ permalink raw reply related
* [PATCH 0/4] basic IPI tracing
From: Nicolas Pitre @ 2014-07-18 5:18 UTC (permalink / raw)
To: linux-arm-kernel
Part of the energy aware scheduler work is concerned by test and
measurement tools such as idlestat[1]. This relies on the ability to
trace wake-up events, mainly IRQs and IPIs.
While IRQs are already well instrumented with tracepoints, IPIs are rather
lacking on that front, and completely invisible on ARM.
This series defines generic IPI tracepoints and adds them to ARM and
ARM64. An attempt at adding them to X86 is also included for comments.
[1] https://wiki.linaro.org/WorkingGroups/PowerManagement/Resources/Tools/Idlestat
diffstat:
arch/arm/kernel/smp.c | 72 ++++++++++++++++++++------------
arch/arm64/kernel/smp.c | 67 +++++++++++++++++++-----------
arch/x86/kernel/smp.c | 16 ++++++++
include/trace/events/ipi.h | 89 ++++++++++++++++++++++++++++++++++++++++
4 files changed, 192 insertions(+), 52 deletions(-)
^ permalink raw reply
* [PATCH v3 1/2] cpufreq: Don't destroy/realloc policy/sysfs on hotplug/suspend
From: Viresh Kumar @ 2014-07-18 4:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <53C8938F.1070706@codeaurora.org>
On 18 July 2014 08:55, Saravana Kannan <skannan@codeaurora.org> wrote:
> Not really. We much never do it during hotplug. We only do it when the
> cpufreq driver unregisters.
Oh yes.
^ permalink raw reply
* [PATCH] PM / OPP: cpufreq: Avoid sleeping while atomic
From: Viresh Kumar @ 2014-07-18 4:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <53C85BE5.6030901@codeaurora.org>
On 18 July 2014 04:57, Stephen Boyd <sboyd@codeaurora.org> wrote:
> First you need to enable sleeping while atomic checking, but in reality,
> I assume nobody has tried inserting a cpufreq driver as a module. The
I did for sure, but long back. Over 6 months atleast :)
> might_sleep() code has a check to see if the system_state is
> SYSTEM_RUNNING. If it isn't running then there isn't a warning and
> might_sleep() doesn't flag any problem. I wonder if that is actually the
> right thing to do though? Perhaps the intention of that code is to skip
> warning early on in the boot path when the scheduler isn't up and
> running yet. But once the scheduler is running (which is fairly early
> nowadays) I would think we want might_sleep() to trigger warnings. Maybe
> that check in might_sleep() needs to be updated to check for "scheduler
> running" instead of "system running"?
> Right. It seems that we moved to RCU in commit
> 0f5c890e9b9754d9aa5bf6ae2fc00cae65780d23 so the real Fixes line should be:
>
> Fixes: 0f5c890e9b97 "PM / OPP: Remove cpufreq wrapper dependency on
> internal data organization"
Right.
> One way to avoid this problem is to put things back the way they were
> before that change. Is there any real benefit to having this code live
> in drivers/cpufreq/ instead of just under some config option in
> drivers/base/power/opp.c?
Maybe Nishanth can give more arguments than I can :), but the idea was
just to keep cpufreq stuff together..
^ permalink raw reply
* [PATCH v3] PM / devfreq: Add possible_frequencies device attribute
From: Saravana Kannan @ 2014-07-18 3:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <725805840.101171405558256488.JavaMail.weblogic@epmlwas01c>
On 07/16/2014 05:50 PM, MyungJoo Ham wrote:
> On Wed, Jul 16, 2014 at 12:01 PM, Saravana Kannan <skannan@codeaurora.org> wrote:
>> Some devices use freq_table instead of OPP. For those devices, the
>> available_frequencies sysfs file shows up empty. So, add a
>> possible_frequencies attribute/syfs file that list all the possible
>> frequencies.
>>
>> For devices that use OPP, the output of this file will match
>> available_frequencies. It may change in the future to show all OPP
>> frequencies -- even the disabled ones.
>>
>> Signed-off-by: Saravana Kannan <skannan@codeaurora.org>
>
> Hi,
>
>
> Please add a documentation entry for this new ABI having a little justification and usage included.
Will do.
>
> Plus, I am considering to move trans_stat along with this entry to somewhere such as .../stat/*
> (you don't need to take care of this.)
Ok.
>
> Besides, as OPP seems becoming the standard as imagined when devfreq development started,
> soon, devfreq may require OPP unless the devfreq device has continuous frequencies.
I agree. Only one caveat with OPP is that if a device isn't using OPP to
do any voltage scaling, then it forces a voltage column with 0s. Also,
even if we make OPP mandatory, we'll still want trans_stats that
currently seem to depend on freq_table being populated. I was actually
planning on sending out more patches later that'll do a lot of stuff
automatically for devices with OPP. Like creating freq_table, etc.
-Saravana
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply
* [PATCH v12 11/11] seccomp: add thread sync ability
From: James Morris @ 2014-07-18 3:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405620518-18495-1-git-send-email-keescook@chromium.org>
On Thu, 17 Jul 2014, Kees Cook wrote:
> Twelfth time's the charm! :)
Btw, there doesn't seem to be an official seccomp maintainer. Kees, would
you like to volunteer for this? If so, send in a patch for MAINTAINERS,
and set up a git tree for me to pull from.
--
James Morris
<jmorris@namei.org>
^ permalink raw reply
* [PATCH v3 1/2] cpufreq: Don't destroy/realloc policy/sysfs on hotplug/suspend
From: Saravana Kannan @ 2014-07-18 3:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKohpongsNtEVbHL=w1fbw5tEXK=WaMcp1N03ar9Sx_CU=1O-w@mail.gmail.com>
On 07/16/2014 10:35 PM, Viresh Kumar wrote:
> On 17 July 2014 01:26, Saravana Kannan <skannan@codeaurora.org> wrote:
>> On 07/16/2014 04:16 AM, Srivatsa S. Bhat wrote:
>
>>> That is, we wanted
>>> to do the kobject cleanup after releasing the hotplug lock, and POST_DEAD
>>> stage was well-suited for that.
>
> I think, this has changed in Saravana's patch, we do it in the PREPARE stage
> now.
Not really. We much never do it during hotplug. We only do it when the
cpufreq driver unregisters.
This should be easier to see in v4, where I'm breaking up the patches
into easier diffs.
>>> Commit 1aee40ac9c8 (cpufreq: Invoke __cpufreq_remove_dev_finish() after
>>> releasing cpu_hotplug.lock) explains this in detail. Saravana, please take
>>> a
>>> look at that reasoning and ensure that your patch doesn't re-introduce
>>> those
>>> deadlock possibilities!
>>
>>
>> But all of that was needed _because_ we were creating and destroying
>> policies and kobjs all the time. We don't do that anymore. So, I don't think
>> any of that applies. We only destroy when the cpufreq driver is
>> unregistered. That's kinda of the point of this patchset.
>>
>> Thoughts?
>
> See above.
>
-Saravana
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply
* [PATCH v2 3/3] [media] atmel-isi: add primary DT support
From: Josh Wu @ 2014-07-18 3:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2360323.ktzTJnrmOX@avalon>
Dear Laurent
On 7/17/2014 7:00 PM, Laurent Pinchart wrote:
> Hi Josh,
>
> What's the status of this patch set ? Do you plan to rebase and resubmit it ?
Thanks for the reminding.
yes, I will rebase it and resubmit the new version for this patch set
with the data bus width support.
Thanks.
Best Regards,
Josh Wu
>
> On Monday 31 March 2014 17:05:13 Josh Wu wrote:
>> Dear Guennadi
>>
>> On 3/31/2014 5:20 AM, Guennadi Liakhovetski wrote:
>>> Hi Josh,
>>>
>>> Please correct me if I'm wrong, but I don't see how this is going to work
>>> without the central part - building asynchronous V4L2 data structures from
>>> the DT, something that your earlier patch
>> Here you mean Bryan Wu not me, right? ;-)
>> Bryan write the patch "[v2] media: soc-camera: OF cameras" in:
>> https://patchwork.linuxtv.org/patch/22288/.
>> And I saw Ben Dooks already sent out his patch to support soc-camera OF
>> now (https://patchwork.linuxtv.org/patch/23304/) which is simpler than
>> Bryan's.
>>
>>> "media: soc-camera: OF cameras"
>>> was doing, but which you stopped developing after a discussion with Ben
>>> (added to Cc).
>> And yes, atmel-isi dt patch should not work without above SoC-Camera of
>> support patch.
>> But as the atmel-isi dt binding document and port node can be finalized.
>> So I think this patch is ready for the mainline.
>>
>> BTW: I will test Ben's patch with atmel-isi.
^ permalink raw reply
* [GIT PULL 1/3] ARM: tegra: rework PCIe regulators
From: Stephen Warren @ 2014-07-18 2:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140707003854.GD8469@quad.lixom.net>
On 07/06/2014 06:38 PM, Olof Johansson wrote:
> On Mon, Jun 23, 2014 at 03:23:44PM -0600, Stephen Warren wrote:
>> This branch reworks the set of regulators that the Tegra PCIe driver
>> uses, so that the driver and DT bindings more correctly model what's
>> really going on in HW.
>>
>> I've made this a separate branch in case it needs to be pulled into the
>> PCIe tree to resolve any conflicts. Any branch that adds Tegra124
>> support to the PCIe driver will need to be based on this branch, and
>> such patches might show up for 3.17, and be taken through the ARM tree
>> so we can manage our own dependencies.
>
> Isn't PCI broken if you boot with an older device tree now?
>
> I would like to see this as two branches: One to the PCI driver, and one
> modifying DT contents. The PCI driver should remain working for old DTs,
> so the last couple of commits on this branch can't be there.
I thought it was still completely legal to change DT bindings that were
not yet considered stable. None of the Tegra bindings have yet been
deemed stable.
^ permalink raw reply
* [GIT PULL 2/3] ARM: tegra: move fuse code out of arch/arm
From: Stephen Warren @ 2014-07-18 2:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOesGMhoqvqf-dktp-OfUNTPLahPwkyAPiTeDngr4QjH=VfOGA@mail.gmail.com>
On 07/08/2014 11:47 AM, Olof Johansson wrote:
> On Tue, Jul 8, 2014 at 6:43 AM, Peter De Schrijver
> <pdeschrijver@nvidia.com> wrote:
>> On Mon, Jul 07, 2014 at 02:44:17AM +0200, Olof Johansson wrote:
>>> On Mon, Jun 23, 2014 at 03:23:45PM -0600, Stephen Warren wrote:
>>>> This branch moves code related to the Tegra fuses out of arch/arm and
>>>> into a centralized location which could be shared with ARM64. It also
>>>> adds support for reading the fuse data through sysfs.
>>>
>>> The new/moved misc driver isn't acked by any misc maintainer, so I can't
>>> take this branch.
>>>
>>> I saw no indication from searching the mailing list of that either,
>>> so it wasn't just a missed acked-by.
>>>
>>> I wonder if this code should go under drivers/soc/ instead?
>>
>> It's modelled after sunxi_sid.c which lives in drivers/misc/eeprom/.
>> Originally this driver was also in drivers/misc/eeprom/, but Stephen objected
>> and therefore it was moved to drivers/misc/fuse. I think that's the right
>> place still.
>
> I disagree, I think this belongs under drivers/soc. Especially since
> you're adding dependencies on this misc driver from other parts of the
> kernel / other drivers.
>
> I also don't like seeing init calls form platform code down into
> drivers/misc like you're adding here. Can you please look at doing
> that as a regular init call setup?
I strongly disagree with using init calls for this kind of thing. There
are ordering dependencies between the initialization code that can only
be sanely managed by explicitly calling functions in a particular order;
there's simply no way to manage this using initcalls. This is exactly
why the hooks in the ARM machine descriptors exist...
^ permalink raw reply
* [GIT PULL 2/3] ARM: tegra: move fuse code out of arch/arm
From: Stephen Warren @ 2014-07-18 2:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140708134359.GA23218@tbergstrom-lnx.Nvidia.com>
On 07/08/2014 07:43 AM, Peter De Schrijver wrote:
> On Mon, Jul 07, 2014 at 02:44:17AM +0200, Olof Johansson wrote:
>> On Mon, Jun 23, 2014 at 03:23:45PM -0600, Stephen Warren wrote:
>>> This branch moves code related to the Tegra fuses out of arch/arm and
>>> into a centralized location which could be shared with ARM64. It also
>>> adds support for reading the fuse data through sysfs.
>>
>> The new/moved misc driver isn't acked by any misc maintainer, so I can't
>> take this branch.
>>
>> I saw no indication from searching the mailing list of that either,
>> so it wasn't just a missed acked-by.
>>
>> I wonder if this code should go under drivers/soc/ instead?
>
> It's modelled after sunxi_sid.c which lives in drivers/misc/eeprom/.
> Originally this driver was also in drivers/misc/eeprom/, but Stephen objected
> and therefore it was moved to drivers/misc/fuse. I think that's the right
> place still. We anyway need this driver for sata and xhci.
Sigh. This is exactly why (a) I suggested during that thread that the
driver should be in drivers/soc not drivers/misc and (b) I sent the pull
requests early enough so I could deal with any objections before my
vacation:-( I wish people would just respond to my review comments by
implementing them rather than persuading me to do the wrong thing. Since
this is all a dependency for pretty much everything for Tegra for 3.17,
I guess we should just drop all the Tegra pull requests for 3.17 and
we'll have to redo all the patches for 3.18:-( But if Thierry can (or
already has in another thread I haven't seen while on vacation) sort
this out be redoing all the Tegra branches, that might be fine too.
^ permalink raw reply
* The imx6q suspend/resume is broken on 3.16-rc due to PCIe
From: Hong-Xing.Zhu at freescale.com @ 2014-07-18 2:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405605306.12800.7.camel@weser.hi.pengutronix.de>
> -----Original Message-----
> From: Lucas Stach [mailto:l.stach at pengutronix.de]
> Sent: Thursday, July 17, 2014 9:55 PM
> To: Guo Shawn-R65073
> Cc: Zhu Richard-R65037; linux-pci at vger.kernel.org; Sascha Hauer; Bjorn Helgaas;
> Shawn Guo; Fabio Estevam; linux-arm-kernel at lists.infradead.org
> Subject: Re: The imx6q suspend/resume is broken on 3.16-rc due to PCIe
>
> Hi Shawn,
>
> Am Mittwoch, den 16.07.2014, 14:55 +0800 schrieb Shawn Guo:
> > On Mon, Jul 07, 2014 at 09:55:03PM +0800, Shawn Guo wrote:
> > > On Mon, Jul 07, 2014 at 11:10:51AM +0200, Lucas Stach wrote:
> > > > Hi Shawn,
> > > >
> > > > Over the weekend I tried to reproduce your problem on a SabreSD
> > > > board, but wasn't able to trigger the issue. 3.16-rc3 with PCIe
> > > > active works just fine over a suspend and resume cycle for me.
> > >
> > > That's strange. In my setup, PCIe support is enabled in kernel and
> > > DT, but I do not have a PCIe device connected to the board.
> > >
> > > >
> > > > One possibly relevant difference is that I've booted with NFSroot,
> > > > while it seems you are using a SATA connected device. Is this right?
> > >
> > > I have a SATA disk connected, but did boot with NFSroot.
> > >
> > > > If so,
> > > > can you test if it works if you boot from SDcard or the like? This
> > > > might be relevant as PCIe and SATA share some clocks.
> > >
> > > I tried to disable SATA support completely, but it doesn't help.
> >
> > Lucas, any news on this? Or should we just try to use Richard's patch
> > to solve the problem?
>
> I would like to understand the problem first before throwing "fixes" at the
> issue. As you said this isn't a regression we are in no hurry and should try
> to analyze the issue properly. I just retested and I'm still not able to
> reproduce the issue on my SabreSD. Maybe there are board revision that exhibit
> different behavior? My board has two sticks on saying "Rev B3" and "Rev X3".
>
> As you can see from the log suspend/resume is working fine for me with kernel
> 3.16-rc5 + imx_v6_v7_defconfig.
[Richard] As I know that imx6 pcie is not enabled in imx_v6_v7_defconfig in default.
Menu-config is required if you want to tests system suspend/resume with pcie built-in.
Just double confirm, is the pcie built-in at your side?
>
> root at XXX:~ echo mem > /sys/power/state
> PM: Syncing filesystems ... done.
> Freezing user space processes ... (elapsed 0.004 seconds) done.
> Freezing remaining freezable tasks ... (elapsed 0.002 seconds) done.
> Suspending console(s) (use no_console_suspend to debug)
> PM: suspend of devices complete after 95.846 msecs
> PM: suspend devices took 0.100 seconds
> PM: late suspend of devices complete after 5.395 msecs
> PM: noirq suspend of devices complete after 4.914 msecs Disabling non-boot
> CPUs ...
> CPU1: shutdown
> CPU2: shutdown
> CPU3: shutdown
> Enabling non-boot CPUs ...
> CPU1: Booted secondary processor
> CPU1 is up
> CPU2: Booted secondary processor
> CPU2 is up
> CPU3: Booted secondary processor
> CPU3 is up
> PM: noirq resume of devices complete after 1556.385 msecs
> PM: early resume of devices complete after 3.134 msecs
> PM: resume of devices complete after 153.568 msecs
> PM: resume devices took 0.160 seconds
> Restarting tasks ... done.
> ata1: SATA link down (SStatus 0 SControl 300) fec 2188000.ethernet eth0: Link
> is Down fec 2188000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off
> root at XXX:~ echo mem > /sys/power/state
> PM: Syncing filesystems ... done.
> Freezing user space processes ... (elapsed 0.002 seconds) done.
> Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
> Suspending console(s) (use no_console_suspend to debug)
> PM: suspend of devices complete after 87.638 msecs
> PM: suspend devices took 0.090 seconds
> PM: late suspend of devices complete after 4.528 msecs
> PM: noirq suspend of devices complete after 5.031 msecs Disabling non-boot
> CPUs ...
> CPU1: shutdown
> CPU2: shutdown
> CPU3: shutdown
> Enabling non-boot CPUs ...
> CPU1: Booted secondary processor
> CPU1 is up
> CPU2: Booted secondary processor
> CPU2 is up
> CPU3: Booted secondary processor
> CPU3 is up
> PM: noirq resume of devices complete after 1425.302 msecs
> PM: early resume of devices complete after 2.736 msecs
> PM: resume of devices complete after 156.013 msecs
> PM: resume devices took 0.160 seconds
> Restarting tasks ... done.
> ata1: SATA link down (SStatus 0 SControl 300) fec 2188000.ethernet eth0: Link
> is Down fec 2188000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off
> root at XXX:~
>
> --
> Pengutronix e.K. | Lucas Stach |
> Industrial Linux Solutions | http://www.pengutronix.de/ |
Best Regards
Richard Zhu
^ permalink raw reply
* [Patch v7 1/3] usb: dwc3: Add Qualcomm DWC3 glue layer driver
From: Jingoo Han @ 2014-07-18 2:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1404144233-17222-2-git-send-email-agross@codeaurora.org>
On Tuesday, July 01, 2014 1:04 AM, Felipe Balbi wrote:
>
> From: "Ivan T. Ivanov" <iivanov@mm-sol.com>
>
> DWC3 glue layer is hardware layer around Synopsys DesignWare
> USB3 core. Its purpose is to supply Synopsys IP with required
> clocks, voltages and interface it with the rest of the SoC.
>
> Signed-off-by: Ivan T. Ivanov <iivanov@mm-sol.com>
> Signed-off-by: Andy Gross <agross@codeaurora.org>
> ---
> drivers/usb/dwc3/Kconfig | 9 +++
> drivers/usb/dwc3/Makefile | 1 +
> drivers/usb/dwc3/dwc3-qcom.c | 153 ++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 163 insertions(+)
> create mode 100644 drivers/usb/dwc3/dwc3-qcom.c
>
> diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
> index 8eb996e..29fcbfd 100644
> --- a/drivers/usb/dwc3/Kconfig
> +++ b/drivers/usb/dwc3/Kconfig
> @@ -79,6 +79,15 @@ config USB_DWC3_KEYSTONE
> Support of USB2/3 functionality in TI Keystone2 platforms.
> Say 'Y' or 'M' here if you have one such device
>
> +config USB_DWC3_QCOM
> + tristate "Qualcomm Platforms"
> + default USB_DWC3
How about adding the machine dependency? Ex. ARCH_QCOM?
Currently, other dwc3 glue layers are using ARCH_* dependency.
> + select USB_QCOM_DWC3_PHY
> + help
> + Recent Qualcomm SoCs ship with one DesignWare Core USB3 IP inside,
> + say 'Y' or 'M' if you have one such device.
> +
> +
Please remove an unnecessary line. One line is enough.
> comment "Debugging features"
>
> config USB_DWC3_DEBUG
> diff --git a/drivers/usb/dwc3/Makefile b/drivers/usb/dwc3/Makefile
> index 10ac3e7..0da8e75 100644
> --- a/drivers/usb/dwc3/Makefile
> +++ b/drivers/usb/dwc3/Makefile
> @@ -33,3 +33,4 @@ obj-$(CONFIG_USB_DWC3_OMAP) += dwc3-omap.o
> obj-$(CONFIG_USB_DWC3_EXYNOS) += dwc3-exynos.o
> obj-$(CONFIG_USB_DWC3_PCI) += dwc3-pci.o
> obj-$(CONFIG_USB_DWC3_KEYSTONE) += dwc3-keystone.o
> +obj-$(CONFIG_USB_DWC3_QCOM) += dwc3-qcom.o
> diff --git a/drivers/usb/dwc3/dwc3-qcom.c b/drivers/usb/dwc3/dwc3-qcom.c
> new file mode 100644
> index 0000000..e99764a
> --- /dev/null
> +++ b/drivers/usb/dwc3/dwc3-qcom.c
> @@ -0,0 +1,153 @@
> +/* Copyright (c) 2013-2014, The Linux Foundation. All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 and
> + * only version 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/err.h>
> +#include <linux/io.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/of_platform.h>
> +#include <linux/platform_device.h>
> +#include <linux/regulator/consumer.h>
> +#include <linux/usb/phy.h>
> +
> +#include "core.h"
> +
> +
Please remove an unnecessary line. One line is enough.
> +struct dwc3_qcom {
> + struct device *dev;
> +
> + struct clk *core_clk;
> + struct clk *iface_clk;
> + struct clk *sleep_clk;
> +
> + struct regulator *gdsc;
> +};
> +
> +static int dwc3_qcom_probe(struct platform_device *pdev)
> +{
> + struct device_node *node = pdev->dev.of_node;
> + struct dwc3_qcom *qdwc;
> + int ret = 0;
> +
> + qdwc = devm_kzalloc(&pdev->dev, sizeof(*qdwc), GFP_KERNEL);
> + if (!qdwc)
> + return -ENOMEM;
> +
> + platform_set_drvdata(pdev, qdwc);
> +
> + qdwc->dev = &pdev->dev;
> +
> + qdwc->gdsc = devm_regulator_get(qdwc->dev, "gdsc");
> +
> + qdwc->core_clk = devm_clk_get(qdwc->dev, "core");
> + if (IS_ERR(qdwc->core_clk)) {
> + dev_dbg(qdwc->dev, "failed to get core clock\n");
> + return PTR_ERR(qdwc->core_clk);
> + }
> +
> + qdwc->iface_clk = devm_clk_get(qdwc->dev, "iface");
> + if (IS_ERR(qdwc->iface_clk)) {
> + dev_dbg(qdwc->dev, "failed to get iface clock, skipping\n");
> + qdwc->iface_clk = NULL;
> + }
> +
> + qdwc->sleep_clk = devm_clk_get(qdwc->dev, "sleep");
> + if (IS_ERR(qdwc->sleep_clk)) {
> + dev_dbg(qdwc->dev, "failed to get sleep clock, skipping\n");
> + qdwc->sleep_clk = NULL;
> + }
> +
> + if (!IS_ERR(qdwc->gdsc)) {
> + ret = regulator_enable(qdwc->gdsc);
> + if (ret)
> + dev_err(qdwc->dev, "cannot enable gdsc\n");
> + }
> +
> + clk_prepare_enable(qdwc->core_clk);
> +
> + if (qdwc->iface_clk)
> + clk_prepare_enable(qdwc->iface_clk);
> +
> + if (qdwc->sleep_clk)
> + clk_prepare_enable(qdwc->sleep_clk);
> +
> + ret = of_platform_populate(node, NULL, NULL, qdwc->dev);
> + if (ret) {
> + dev_err(qdwc->dev, "failed to register core - %d\n", ret);
> + dev_dbg(qdwc->dev, "failed to add create dwc3 core\n");
Is there any reason to use two similar messages?
For me, it looks duplicated.
> + goto dis_clks;
> + }
> +
> + return 0;
> +
> +dis_clks:
> + if (qdwc->sleep_clk)
> + clk_disable_unprepare(qdwc->sleep_clk);
> +
> + if (qdwc->iface_clk)
> + clk_disable_unprepare(qdwc->iface_clk);
> +
> + clk_disable_unprepare(qdwc->core_clk);
> +
> + if (!IS_ERR(qdwc->gdsc)) {
> + ret = regulator_disable(qdwc->gdsc);
> + if (ret)
> + dev_dbg(qdwc->dev, "cannot disable gdsc\n");
> + }
> +
> + return ret;
> +}
> +
> +static int dwc3_qcom_remove(struct platform_device *pdev)
> +{
> + int ret = 0;
> +
> + struct dwc3_qcom *qdwc = platform_get_drvdata(pdev);
> +
> + if (qdwc->sleep_clk)
> + clk_disable_unprepare(qdwc->sleep_clk);
> +
> + if (qdwc->iface_clk)
> + clk_disable_unprepare(qdwc->iface_clk);
> +
> + clk_disable_unprepare(qdwc->core_clk);
> +
> + if (!IS_ERR(qdwc->gdsc)) {
> + ret = regulator_disable(qdwc->gdsc);
> + if (ret)
> + dev_dbg(qdwc->dev, "cannot disable gdsc\n");
> + }
> + return ret;
> +}
> +
> +static const struct of_device_id of_dwc3_match[] = {
> + { .compatible = "qcom,dwc3" },
> + { /* Sentinel */ }
> +};
> +MODULE_DEVICE_TABLE(of, of_dwc3_match);
> +
> +static struct platform_driver dwc3_qcom_driver = {
> + .probe = dwc3_qcom_probe,
> + .remove = dwc3_qcom_remove,
> + .driver = {
> + .name = "qcom-dwc3",
> + .owner = THIS_MODULE,
> + .of_match_table = of_dwc3_match,
> + },
> +};
> +
> +module_platform_driver(dwc3_qcom_driver);
> +
> +MODULE_ALIAS("platform:qcom-dwc3");
How about adding the module author as Ivan T. Ivanov and you?
MODULE_AUTHOR("Ivan T. Ivanov <iivanov@mm-sol.com>");
MODULE_AUTHOR("Andy Gross <agross@codeaurora.org>");
Best regards,
Jingoo Han
> +MODULE_LICENSE("GPL v2");
> +MODULE_DESCRIPTION("DesignWare USB3 QCOM Glue Layer");
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> hosted by The Linux Foundation
^ permalink raw reply
* [PATCH v7 0/6] cpufreq: use generic cpufreq drivers for exynos platforms
From: Thomas Abraham @ 2014-07-18 2:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <53C86DF3.1040303@samsung.com>
On Fri, Jul 18, 2014 at 6:14 AM, Chanwoo Choi <cw00.choi@samsung.com> wrote:
> Hi Thomas,
>
> On 07/17/2014 02:58 PM, Thomas Abraham wrote:
>> Hi Mike,
>>
>> On Tue, Jul 15, 2014 at 9:20 AM, Thomas Abraham <ta.omasab@gmail.com> wrote:
>>> Hi Tomasz,
>>>
>>> On Mon, Jul 14, 2014 at 7:08 PM, Thomas Abraham <thomas.ab@samsung.com> wrote:
>>>> Changes since v6:
>>>> - Fixes suggested by Amit Daniel <amit.daniel@samsung.com>.
>>>>
>>>> This patch series removes the use of Exynos4210 and Exynos5250 specific cpufreq
>>>> drivers and enables the use of cpufreq-cpu0 driver for these platforms. This
>>>> series also enabled cpufreq support for Exynos5420 using arm_big_little cpufreq
>>>> driver.
>>>>
>>>> Thomas Abraham (6):
>>>> clk: samsung: add infrastructure to register cpu clocks
>>>> clk: samsung: register exynos5420 apll/kpll configuration data
>>>> clk: exynos: use cpu-clock provider type to represent arm clock
>>>> ARM: dts: Exynos: add cpu nodes, opp and cpu clock configuration data
>>>> ARM: Exynos: switch to using generic cpufreq driver for exynos4210/5250
>>>> cpufreq: exynos: remove exynos4210/5250 specific cpufreq driver support
>>>
>>> In this series, support for Exynos5420 has been included. If there are
>>> any more changes required, could you please let me know.
>>
>> This patch series migrates exynos cpufreq support to use generic
>> cpufreq drivers. For this, cpu clock blocks are encapsulated into a
>> cpu clock type and cpufreq driver operates the cpu clock type.
>>
>> We had discussed in the [1] about using coordinated clocks. This
>> series is not using the concept of coordinated clocks but the code in
>> this series can be migrated to use coordinated clocks when it is
>> available.
>>
>> Is it okay to consider this series for v3.17-rc1. I will update this
>> code to use coordinated clocks when it is available. This series helps
>> with cpufreq support for newer Exynos SoCs such as Exynos5420/3250.
>>
>> [1] http://www.spinics.net/lists/cpufreq/msg10042.html
>>
>
> I tested this patchset with Exynos3250 cpufreq patchset[1] on Exynos3250 SoC.
> [1] https://lkml.org/lkml/2014/6/18/126
>
> Tested-by: Chanwoo Choi <cw00.choi@samsung.com>
Hi Chanwoo,
Thanks for using these patches for Exynos3250 cpufreq support.
Regards,
Thomas.
>
> Best Regards,
> Chanwoo Choi
>
^ permalink raw reply
* [PATCH v3 09/12] Revert "sched: Put rq's sched_avg under CONFIG_FAIR_GROUP_SCHED"
From: Yuyang Du @ 2014-07-18 1:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <53C41943.2000601@arm.com>
On Mon, Jul 14, 2014 at 06:54:11PM +0100, Dietmar Eggemann wrote:
> __update_entity_runnable_avg() has an additional parameter 'running' so
> that it can be called for
>
> a) sched_entities in update_entity_load_avg():
>
> __update_entity_runnable_avg(..., se->on_rq, cfs_rq->curr == se))
>
>
> b) rq's in update_rq_runnable_avg():
>
> __update_entity_runnable_avg(..., runnable, runnable);
>
> I can see how it gives us two different signals for a sched_entity but
> for a rq?
>
For rq,
__update_entity_runnable_avg(..., runnable, runnable > 0)
Then, first one would be effectively CPU ConCurrency (fair and !fair) and
second one would be CPU (has task) running (or about CPU utilization for
fair and !fair), :)
Thanks,
Yuyang
^ permalink raw reply
* [PATCH v7 0/6] cpufreq: use generic cpufreq drivers for exynos platforms
From: Chanwoo Choi @ 2014-07-18 0:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJuA9aiVFFZiN7_xBg6iQEX-LJKLMmHKvPhmdmOduouQzBtQJw@mail.gmail.com>
Hi Thomas,
On 07/17/2014 02:58 PM, Thomas Abraham wrote:
> Hi Mike,
>
> On Tue, Jul 15, 2014 at 9:20 AM, Thomas Abraham <ta.omasab@gmail.com> wrote:
>> Hi Tomasz,
>>
>> On Mon, Jul 14, 2014 at 7:08 PM, Thomas Abraham <thomas.ab@samsung.com> wrote:
>>> Changes since v6:
>>> - Fixes suggested by Amit Daniel <amit.daniel@samsung.com>.
>>>
>>> This patch series removes the use of Exynos4210 and Exynos5250 specific cpufreq
>>> drivers and enables the use of cpufreq-cpu0 driver for these platforms. This
>>> series also enabled cpufreq support for Exynos5420 using arm_big_little cpufreq
>>> driver.
>>>
>>> Thomas Abraham (6):
>>> clk: samsung: add infrastructure to register cpu clocks
>>> clk: samsung: register exynos5420 apll/kpll configuration data
>>> clk: exynos: use cpu-clock provider type to represent arm clock
>>> ARM: dts: Exynos: add cpu nodes, opp and cpu clock configuration data
>>> ARM: Exynos: switch to using generic cpufreq driver for exynos4210/5250
>>> cpufreq: exynos: remove exynos4210/5250 specific cpufreq driver support
>>
>> In this series, support for Exynos5420 has been included. If there are
>> any more changes required, could you please let me know.
>
> This patch series migrates exynos cpufreq support to use generic
> cpufreq drivers. For this, cpu clock blocks are encapsulated into a
> cpu clock type and cpufreq driver operates the cpu clock type.
>
> We had discussed in the [1] about using coordinated clocks. This
> series is not using the concept of coordinated clocks but the code in
> this series can be migrated to use coordinated clocks when it is
> available.
>
> Is it okay to consider this series for v3.17-rc1. I will update this
> code to use coordinated clocks when it is available. This series helps
> with cpufreq support for newer Exynos SoCs such as Exynos5420/3250.
>
> [1] http://www.spinics.net/lists/cpufreq/msg10042.html
>
I tested this patchset with Exynos3250 cpufreq patchset[1] on Exynos3250 SoC.
[1] https://lkml.org/lkml/2014/6/18/126
Tested-by: Chanwoo Choi <cw00.choi@samsung.com>
Best Regards,
Chanwoo Choi
^ permalink raw reply
* [PATCH v2 7/7] ARM: dts: add rk3288 evaluation board
From: Heiko Stübner @ 2014-07-18 0:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4868343.UFgjaXesOn@diego>
There exist 2 variants using either the act8846 or rk808 as pmic, while the
rest of the board stays the same.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Tested-by: Will Deacon <will.deacon@arm.com>
---
arch/arm/boot/dts/rk3288-evb-act8846.dts | 134 +++++++++++++++++++++++++++++++
arch/arm/boot/dts/rk3288-evb-rk808.dts | 18 +++++
arch/arm/boot/dts/rk3288-evb.dtsi | 83 +++++++++++++++++++
3 files changed, 235 insertions(+)
create mode 100644 arch/arm/boot/dts/rk3288-evb-act8846.dts
create mode 100644 arch/arm/boot/dts/rk3288-evb-rk808.dts
create mode 100644 arch/arm/boot/dts/rk3288-evb.dtsi
diff --git a/arch/arm/boot/dts/rk3288-evb-act8846.dts b/arch/arm/boot/dts/rk3288-evb-act8846.dts
new file mode 100644
index 0000000..7d59ff4
--- /dev/null
+++ b/arch/arm/boot/dts/rk3288-evb-act8846.dts
@@ -0,0 +1,134 @@
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+/dts-v1/;
+#include "rk3288-evb.dtsi"
+
+/ {
+ compatible = "rockchip,rk3288-evb-act8846", "rockchip,rk3288";
+};
+
+&i2c0 {
+ hym8563 at 51 {
+ compatible = "haoyu,hym8563";
+ reg = <0x51>;
+
+ interrupt-parent = <&gpio0>;
+ interrupts = <4 IRQ_TYPE_EDGE_FALLING>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&hym8563_int>;
+
+ #clock-cells = <0>;
+ clock-output-names = "xin32k";
+ };
+
+ act8846: act8846 at 5a {
+ compatible = "active-semi,act8846";
+ reg = <0x5a>;
+ status = "okay";
+
+ regulators {
+ vcc_ddr: REG1 {
+ regulator-name = "VCC_DDR";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ regulator-always-on;
+ };
+
+ vcc_io: REG2 {
+ regulator-name = "VCC_IO";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+
+ vdd_log: REG3 {
+ regulator-name = "VDD_LOG";
+ regulator-min-microvolt = <1000000>;
+ regulator-max-microvolt = <1000000>;
+ regulator-always-on;
+ };
+
+ vcc_20: REG4 {
+ regulator-name = "VCC_20";
+ regulator-min-microvolt = <2000000>;
+ regulator-max-microvolt = <2000000>;
+ regulator-always-on;
+ };
+
+ vccio_sd: REG5 {
+ regulator-name = "VCCIO_SD";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+
+ vdd10_lcd: REG6 {
+ regulator-name = "VDD10_LCD";
+ regulator-min-microvolt = <1000000>;
+ regulator-max-microvolt = <1000000>;
+ regulator-always-on;
+ };
+
+ vcca_codec: REG7 {
+ regulator-name = "VCCA_CODEC";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+
+ vcca_tp: REG8 {
+ regulator-name = "VCCA_TP";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+
+ vccio_pmu: REG9 {
+ regulator-name = "VCCIO_PMU";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+
+ vdd_10: REG10 {
+ regulator-name = "VDD_10";
+ regulator-min-microvolt = <1000000>;
+ regulator-max-microvolt = <1000000>;
+ regulator-always-on;
+ };
+
+ vcc_18: REG11 {
+ regulator-name = "VCC_18";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ };
+
+ vcc18_lcd: REG12 {
+ regulator-name = "VCC18_LCD";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ };
+ };
+ };
+};
+
+&pinctrl {
+ hym8563 {
+ hym8563_int: hym8563-int {
+ rockchip,pins = <RK_GPIO0 4 RK_FUNC_GPIO &pcfg_pull_up>;
+ };
+ };
+};
diff --git a/arch/arm/boot/dts/rk3288-evb-rk808.dts b/arch/arm/boot/dts/rk3288-evb-rk808.dts
new file mode 100644
index 0000000..9a88b6c
--- /dev/null
+++ b/arch/arm/boot/dts/rk3288-evb-rk808.dts
@@ -0,0 +1,18 @@
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+/dts-v1/;
+#include "rk3288-evb.dtsi"
+
+/ {
+ compatible = "rockchip,rk3288-evb-rk808", "rockchip,rk3288";
+};
diff --git a/arch/arm/boot/dts/rk3288-evb.dtsi b/arch/arm/boot/dts/rk3288-evb.dtsi
new file mode 100644
index 0000000..2afd4f2
--- /dev/null
+++ b/arch/arm/boot/dts/rk3288-evb.dtsi
@@ -0,0 +1,83 @@
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include "rk3288.dtsi"
+
+/ {
+ aliases {
+ serial0 = &uart0;
+ serial1 = &uart1;
+ serial2 = &uart2;
+ serial3 = &uart3;
+ serial4 = &uart4;
+ };
+
+ memory {
+ reg = <0x0 0x80000000>;
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ autorepeat;
+
+ button at 0 {
+ gpios = <&gpio0 5 GPIO_ACTIVE_LOW>;
+ linux,code = <116>;
+ label = "GPIO Key Power";
+ linux,input-type = <1>;
+ gpio-key,wakeup = <1>;
+ debounce-interval = <100>;
+ };
+ };
+
+ i2c0: i2c at ff650000 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c0_xfer>;
+ status = "okay";
+ };
+
+ watchdog at ff800000 {
+ status = "okay";
+ };
+
+ serial at ff180000 {
+ status = "okay";
+ };
+
+ serial at ff190000 {
+ status = "okay";
+ };
+
+ serial at ff690000 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart2_xfer>;
+ status = "okay";
+ };
+
+ serial at ff1b0000 {
+ status = "okay";
+ };
+
+ serial at ff1c0000 {
+ status = "okay";
+ };
+
+ pinctrl {
+ buttons {
+ pwrbtn: pwrbtn {
+ rockchip,pins = <0 5 RK_FUNC_GPIO &pcfg_pull_up>;
+ };
+ };
+ };
+};
--
1.9.0
^ permalink raw reply related
* [PATCH v2 6/7] ARM: dts: rockchip: add core rk3288 dtsi
From: Heiko Stübner @ 2014-07-18 0:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4868343.UFgjaXesOn@diego>
Node definitions shared by all rk3288 based boards.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Tested-by: Will Deacon <will.deacon@arm.com>
---
arch/arm/boot/dts/rk3288.dtsi | 552 ++++++++++++++++++++++++++++++++++++++++++
1 file changed, 552 insertions(+)
create mode 100644 arch/arm/boot/dts/rk3288.dtsi
diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
new file mode 100644
index 0000000..c8e387e
--- /dev/null
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -0,0 +1,552 @@
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/pinctrl/rockchip.h>
+#include <dt-bindings/clock/rk3288-cru.h>
+#include "skeleton.dtsi"
+
+/ {
+ compatible = "rockchip,rk3288";
+
+ interrupt-parent = <&gic>;
+
+ aliases {
+ serial0 = &uart0;
+ serial1 = &uart1;
+ serial2 = &uart2;
+ serial3 = &uart3;
+ serial4 = &uart4;
+ i2c0 = &i2c0;
+ i2c1 = &i2c1;
+ i2c2 = &i2c2;
+ i2c3 = &i2c3;
+ i2c4 = &i2c4;
+ i2c5 = &i2c5;
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu at 500 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a12";
+ reg = <0x500>;
+ };
+ cpu at 501 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a12";
+ reg = <0x501>;
+ };
+ cpu at 502 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a12";
+ reg = <0x502>;
+ };
+ cpu at 503 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a12";
+ reg = <0x503>;
+ };
+ };
+
+ xin24m: xin24m {
+ compatible = "fixed-clock";
+ clock-frequency = <24000000>;
+ #clock-cells = <0>;
+ };
+
+ timer {
+ compatible = "arm,armv7-timer";
+ interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>,
+ <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>,
+ <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>,
+ <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
+ clock-frequency = <24000000>;
+ };
+
+ i2c1: i2c at ff140000 {
+ compatible = "rockchip,rk3288-i2c";
+ reg = <0xff140000 0x1000>;
+ interrupts = <GIC_SPI 62 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clock-names = "i2c";
+ clocks = <&cru PCLK_I2C1>;
+ status = "disabled";
+ };
+
+ i2c3: i2c at ff150000 {
+ compatible = "rockchip,rk3288-i2c";
+ reg = <0xff150000 0x1000>;
+ interrupts = <GIC_SPI 63 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clock-names = "i2c";
+ clocks = <&cru PCLK_I2C3>;
+ status = "disabled";
+ };
+
+ i2c4: i2c at ff160000 {
+ compatible = "rockchip,rk3288-i2c";
+ reg = <0xff160000 0x1000>;
+ interrupts = <GIC_SPI 64 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clock-names = "i2c";
+ clocks = <&cru PCLK_I2C4>;
+ status = "disabled";
+ };
+
+ i2c5: i2c at ff170000 {
+ compatible = "rockchip,rk3288-i2c";
+ reg = <0xff170000 0x1000>;
+ interrupts = <GIC_SPI 65 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clock-names = "i2c";
+ clocks = <&cru PCLK_I2C5>;
+ status = "disabled";
+ };
+
+ uart0: serial at ff180000 {
+ compatible = "rockchip,rk3288-uart", "snps,dw-apb-uart";
+ reg = <0xff180000 0x100>;
+ interrupts = <GIC_SPI 55 IRQ_TYPE_LEVEL_HIGH>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ clocks = <&cru SCLK_UART0>, <&cru PCLK_UART0>;
+ clock-names = "baudclk", "apb_pclk";
+ status = "disabled";
+ };
+
+ uart1: serial at ff190000 {
+ compatible = "rockchip,rk3288-uart", "snps,dw-apb-uart";
+ reg = <0xff190000 0x100>;
+ interrupts = <GIC_SPI 56 IRQ_TYPE_LEVEL_HIGH>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ clocks = <&cru SCLK_UART1>, <&cru PCLK_UART1>;
+ clock-names = "baudclk", "apb_pclk";
+ status = "disabled";
+ };
+
+ uart2: serial at ff690000 {
+ compatible = "rockchip,rk3288-uart", "snps,dw-apb-uart";
+ reg = <0xff690000 0x100>;
+ interrupts = <GIC_SPI 57 IRQ_TYPE_LEVEL_HIGH>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ clocks = <&cru SCLK_UART2>, <&cru PCLK_UART2>;
+ clock-names = "baudclk", "apb_pclk";
+ status = "disabled";
+ };
+
+ uart3: serial at ff1b0000 {
+ compatible = "rockchip,rk3288-uart", "snps,dw-apb-uart";
+ reg = <0xff1b0000 0x100>;
+ interrupts = <GIC_SPI 58 IRQ_TYPE_LEVEL_HIGH>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ clocks = <&cru SCLK_UART3>, <&cru PCLK_UART3>;
+ clock-names = "baudclk", "apb_pclk";
+ status = "disabled";
+ };
+
+ uart4: serial at ff1c0000 {
+ compatible = "rockchip,rk3288-uart", "snps,dw-apb-uart";
+ reg = <0xff1c0000 0x100>;
+ interrupts = <GIC_SPI 59 IRQ_TYPE_LEVEL_HIGH>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ clocks = <&cru SCLK_UART4>, <&cru PCLK_UART4>;
+ clock-names = "baudclk", "apb_pclk";
+ status = "disabled";
+ };
+
+ i2c0: i2c at ff650000 {
+ compatible = "rockchip,rk3288-i2c";
+ reg = <0xff650000 0x1000>;
+ interrupts = <GIC_SPI 60 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clock-names = "i2c";
+ clocks = <&cru PCLK_I2C0>;
+ status = "disabled";
+ };
+
+ i2c2: i2c at ff660000 {
+ compatible = "rockchip,rk3288-i2c";
+ reg = <0xff660000 0x1000>;
+ interrupts = <GIC_SPI 61 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clock-names = "i2c";
+ clocks = <&cru PCLK_I2C2>;
+ status = "disabled";
+ };
+
+ pmu: power-management at ff730000 {
+ compatible = "rockchip,rk3288-pmu", "syscon";
+ reg = <0xff730000 0x100>;
+ };
+
+ sgrf: syscon at ff740000 {
+ compatible = "rockchip,rk3288-sgrf", "syscon";
+ reg = <0xff740000 0x1000>;
+ };
+
+ cru: clock-controller at ff760000 {
+ compatible = "rockchip,rk3288-cru";
+ reg = <0xff760000 0x1000>;
+ rockchip,grf = <&grf>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ };
+
+ grf: syscon at ff770000 {
+ compatible = "rockchip,rk3288-grf", "syscon";
+ reg = <0xff770000 0x1000>;
+ };
+
+ watchdog at ff800000 {
+ compatible = "rockchip,rk3288-wdt", "snps,dw-wdt";
+ reg = <0xff800000 0x100>;
+ interrupts = <GIC_SPI 111 IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
+ };
+
+ gic: interrupt-controller at ffc01000 {
+ compatible = "arm,gic-400";
+ interrupt-controller;
+ #interrupt-cells = <3>;
+ #address-cells = <0>;
+
+ reg = <0xffc01000 0x1000>,
+ <0xffc02000 0x1000>,
+ <0xffc04000 0x2000>,
+ <0xffc06000 0x2000>;
+ interrupts = <GIC_PPI 9 0xf04>;
+ };
+
+ pinctrl: pinctrl {
+ compatible = "rockchip,rk3288-pinctrl";
+ rockchip,grf = <&grf>;
+ rockchip,pmu = <&pmu>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ gpio0: gpio0 at ff750000 {
+ compatible = "rockchip,gpio-bank";
+ reg = <0xff750000 0x100>;
+ interrupts = <GIC_SPI 81 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cru PCLK_GPIO0>;
+
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpio1: gpio1 at ff780000 {
+ compatible = "rockchip,gpio-bank";
+ reg = <0xff780000 0x100>;
+ interrupts = <GIC_SPI 82 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cru PCLK_GPIO1>;
+
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpio2: gpio2 at ff790000 {
+ compatible = "rockchip,gpio-bank";
+ reg = <0xff790000 0x100>;
+ interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cru PCLK_GPIO2>;
+
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpio3: gpio3 at ff7a0000 {
+ compatible = "rockchip,gpio-bank";
+ reg = <0xff7a0000 0x100>;
+ interrupts = <GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cru PCLK_GPIO3>;
+
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpio4: gpio4 at ff7b0000 {
+ compatible = "rockchip,gpio-bank";
+ reg = <0xff7b0000 0x100>;
+ interrupts = <GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cru PCLK_GPIO4>;
+
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpio5: gpio5 at ff7c0000 {
+ compatible = "rockchip,gpio-bank";
+ reg = <0xff7c0000 0x100>;
+ interrupts = <GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cru PCLK_GPIO5>;
+
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpio6: gpio6 at ff7d0000 {
+ compatible = "rockchip,gpio-bank";
+ reg = <0xff7d0000 0x100>;
+ interrupts = <GIC_SPI 87 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cru PCLK_GPIO6>;
+
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpio7: gpio7 at ff7e0000 {
+ compatible = "rockchip,gpio-bank";
+ reg = <0xff7e0000 0x100>;
+ interrupts = <GIC_SPI 88 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cru PCLK_GPIO7>;
+
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpio8: gpio8 at ff7f0000 {
+ compatible = "rockchip,gpio-bank";
+ reg = <0xff7f0000 0x100>;
+ interrupts = <GIC_SPI 89 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cru PCLK_GPIO8>;
+
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ pcfg_pull_up: pcfg_pull_up {
+ bias-pull-up;
+ };
+
+ pcfg_pull_down: pcfg_pull_down {
+ bias-pull-down;
+ };
+
+ pcfg_pull_none: pcfg_pull_none {
+ bias-disable;
+ };
+
+ i2c0 {
+ i2c0_xfer: i2c0-xfer {
+ rockchip,pins = <0 15 RK_FUNC_1 &pcfg_pull_none>,
+ <0 16 RK_FUNC_1 &pcfg_pull_none>;
+ };
+ };
+
+ i2c1 {
+ i2c1_xfer: i2c1-xfer {
+ rockchip,pins = <8 4 RK_FUNC_1 &pcfg_pull_none>,
+ <8 5 RK_FUNC_1 &pcfg_pull_none>;
+ };
+ };
+
+ i2c2 {
+ i2c2_xfer: i2c2-xfer {
+ rockchip,pins = <6 9 RK_FUNC_1 &pcfg_pull_none>,
+ <6 10 RK_FUNC_1 &pcfg_pull_none>;
+ };
+ };
+
+ i2c3 {
+ i2c3_xfer: i2c3-xfer {
+ rockchip,pins = <2 16 RK_FUNC_1 &pcfg_pull_none>,
+ <2 17 RK_FUNC_1 &pcfg_pull_none>;
+ };
+ };
+
+ i2c4 {
+ i2c4_xfer: i2c4-xfer {
+ rockchip,pins = <7 17 RK_FUNC_1 &pcfg_pull_none>,
+ <7 18 RK_FUNC_1 &pcfg_pull_none>;
+ };
+ };
+
+ i2c5 {
+ i2c5_xfer: i2c5-xfer {
+ rockchip,pins = <7 19 RK_FUNC_1 &pcfg_pull_none>,
+ <7 20 RK_FUNC_1 &pcfg_pull_none>;
+ };
+ };
+
+ sdmmc {
+ sdmmc_clk: sdmmc-clk {
+ rockchip,pins = <6 20 RK_FUNC_1 &pcfg_pull_none>;
+ };
+
+ sdmmc_cmd: sdmmc-cmd {
+ rockchip,pins = <6 21 RK_FUNC_1 &pcfg_pull_up>;
+ };
+
+ sdmmc_cd: sdmcc-cd {
+ rockchip,pins = <6 22 RK_FUNC_1 &pcfg_pull_up>;
+ };
+
+ sdmmc_bus1: sdmmc-bus1 {
+ rockchip,pins = <6 16 RK_FUNC_1 &pcfg_pull_up>;
+ };
+
+ sdmmc_bus4: sdmmc-bus4 {
+ rockchip,pins = <6 16 RK_FUNC_1 &pcfg_pull_up>,
+ <6 17 RK_FUNC_1 &pcfg_pull_up>,
+ <6 18 RK_FUNC_1 &pcfg_pull_up>,
+ <6 19 RK_FUNC_1 &pcfg_pull_up>;
+ };
+ };
+
+ emmc {
+ emmc_clk: emmc-clk {
+ rockchip,pins = <3 18 RK_FUNC_2 &pcfg_pull_none>;
+ };
+
+ emmc_cmd: emmc-cmd {
+ rockchip,pins = <3 16 RK_FUNC_2 &pcfg_pull_up>;
+ };
+
+ emmc_pwr: emmc-pwr {
+ rockchip,pins = <3 9 RK_FUNC_2 &pcfg_pull_up>;
+ };
+
+ emmc_bus1: emmc-bus1 {
+ rockchip,pins = <3 0 RK_FUNC_2 &pcfg_pull_up>;
+ };
+
+ emmc_bus4: emmc-bus4 {
+ rockchip,pins = <3 0 RK_FUNC_2 &pcfg_pull_up>,
+ <3 1 RK_FUNC_2 &pcfg_pull_up>,
+ <3 2 RK_FUNC_2 &pcfg_pull_up>,
+ <3 3 RK_FUNC_2 &pcfg_pull_up>;
+ };
+
+ emmc_bus8: emmc-bus8 {
+ rockchip,pins = <3 0 RK_FUNC_2 &pcfg_pull_up>,
+ <3 1 RK_FUNC_2 &pcfg_pull_up>,
+ <3 2 RK_FUNC_2 &pcfg_pull_up>,
+ <3 3 RK_FUNC_2 &pcfg_pull_up>,
+ <3 4 RK_FUNC_2 &pcfg_pull_up>,
+ <3 5 RK_FUNC_2 &pcfg_pull_up>,
+ <3 6 RK_FUNC_2 &pcfg_pull_up>,
+ <3 7 RK_FUNC_2 &pcfg_pull_up>;
+ };
+ };
+
+ uart0 {
+ uart0_xfer: uart0-xfer {
+ rockchip,pins = <4 16 RK_FUNC_1 &pcfg_pull_up>,
+ <4 17 RK_FUNC_1 &pcfg_pull_none>;
+ };
+
+ uart0_cts: uart0-cts {
+ rockchip,pins = <4 18 RK_FUNC_1 &pcfg_pull_none>;
+ };
+
+ uart0_rts: uart0-rts {
+ rockchip,pins = <4 19 RK_FUNC_1 &pcfg_pull_none>;
+ };
+ };
+
+ uart1 {
+ uart1_xfer: uart1-xfer {
+ rockchip,pins = <5 8 RK_FUNC_1 &pcfg_pull_up>,
+ <5 9 RK_FUNC_1 &pcfg_pull_none>;
+ };
+
+ uart1_cts: uart1-cts {
+ rockchip,pins = <5 10 RK_FUNC_1 &pcfg_pull_none>;
+ };
+
+ uart1_rts: uart1-rts {
+ rockchip,pins = <5 11 RK_FUNC_1 &pcfg_pull_none>;
+ };
+ };
+
+ uart2 {
+ uart2_xfer: uart2-xfer {
+ rockchip,pins = <7 22 RK_FUNC_1 &pcfg_pull_up>,
+ <7 23 RK_FUNC_1 &pcfg_pull_none>;
+ };
+ /* no rts / cts for uart2 */
+ };
+
+ uart3 {
+ uart3_xfer: uart3-xfer {
+ rockchip,pins = <7 7 RK_FUNC_1 &pcfg_pull_up>,
+ <7 8 RK_FUNC_1 &pcfg_pull_none>;
+ };
+
+ uart3_cts: uart3-cts {
+ rockchip,pins = <7 9 RK_FUNC_1 &pcfg_pull_none>;
+ };
+
+ uart3_rts: uart3-rts {
+ rockchip,pins = <7 10 RK_FUNC_1 &pcfg_pull_none>;
+ };
+ };
+
+ uart4 {
+ uart4_xfer: uart4-xfer {
+ rockchip,pins = <5 12 3 &pcfg_pull_up>,
+ <5 13 3 &pcfg_pull_none>;
+ };
+
+ uart4_cts: uart4-cts {
+ rockchip,pins = <5 14 3 &pcfg_pull_none>;
+ };
+
+ uart4_rts: uart4-rts {
+ rockchip,pins = <5 15 3 &pcfg_pull_none>;
+ };
+ };
+ };
+};
--
1.9.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox