* [PATCH 1/1] ARM: ux500: Describe UART platform registering issues more accurately
From: Lee Jones @ 2012-11-15 12:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201211151223.46989.arnd@arndb.de>
On Thu, 15 Nov 2012, Arnd Bergmann wrote:
> On Thursday 15 November 2012, Lee Jones wrote:
> > UARTs no longer require call-back information, since the reset
> > call-back was removed in 43b5f0d69291374f602ad8e1817f329573a59010.
> > The only AUXDATA dependencies remaining for UARTs are DMA settings.
> >
> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
>
> Acked-by: Arnd Bergmann <arnd@arndb.de>
>
> What is the state of the DMA binding now? We originally wanted to merge
> it for 3.7, but that didn't work out, so I hope we can get it done for
> 3.8.
It's dead. The conversation has been stale for weeks.
Perhaps you'd like to go and poke it? :)
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH] ARM: Fix errata 751472 handling on Cortex-A9 r1p*
From: Siarhei Siamashka @ 2012-11-15 12:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121115110137.GA25985@arm.com>
On Thu, Nov 15, 2012 at 1:01 PM, Catalin Marinas
<catalin.marinas@arm.com> wrote:
> On Thu, Nov 15, 2012 at 12:54:48AM +0000, Rob Herring wrote:
>> On 11/14/2012 04:21 PM, Tony Lindgren wrote:
>> > * Rob Herring <robherring2@gmail.com> [121114 13:59]:
>> >> On 11/14/2012 02:32 PM, Tony Lindgren wrote:
>> >>>
>> >>> Checking for the bit already set should work in this case, I'll post
>> >>> a patch for that shortly.
>> >>
>> >> Can you actually read the state of the diagnostic register in non-secure
>> >> mode? If you can on the A9, is the same true on A8 or others?
>> >
>> > Looks like it can be read on at least TI omap 4430 which is A9.
>> > But it reads as zero, so the below patch is what I came up with.
>> >
>> > No idea if assuming that zero value for the diagnostic register
>> > is safe.. What's the default value of the diagnostic register supposed
>> > to be?
>>
>> RTFM. Oh, wait it's a super secret, undocumented register. We shouldn't
>> even be talking about it.
>>
>> It could vary by rev, but I see 0 for the reset value, so this would not
>> work if the bootloader did not do any setup of the diagnostic register.
>>
>> One way to determine secure mode on the A9 would be seeing if you can
>> change the auxcr register. Something like this (untested):
>>
>> mrc p15, 0, r0, c1, c0, 1; Read ACTLR
>> eor r1, r0, #0x100 ; Modify alloc in 1 way
>> mcr p15, 0, r1, c1, c0, 1
>> mrc p15, 0, r2, c1, c0, 1; Read ACTLR
>> mcr p15, 0, r0, c1, c0, 1 ; Restore original value
>> cmp r1, r2
>> bne skip_errata
>
> This would fail on platforms where Linux runs in non-secure mode. What
> we do for some errata workarounds is to test whether the bit was already
> set and avoid writing the register. But this assumes that, for a given
> workaround in the kernel, there is a corresponding workaround in the
> code running before the kernel (boot-loader, firmware) which sets that
> bit.
>
> Since the kernel will run more often in non-secure mode (on Cortex-A15
> you need this for the virtualisation extensions) I strongly suggest that
> the workaround (usually undocumented bit setting) is done before the
> kernel is started and we simply remove it from Linux (or add a clear
> comment that it only works if running in secure mode; if unsure say
> 'N').
>
> I don't think it's worth the hassle detecting whether the kernel runs in
> secure or non-secure mode, just assume the latter and get SoC vendors to
> update the boot loaders or firmware (if possible) with any errata
> workarounds.
>
> Having a common SMC API for errata workarounds is not feasible since not
> all registers are public, most are implementation specific and it could
> have secure implications with exposing them.
BTW, I always wondered about what could be preventing TI and the other
silicon vendors from using something like an SMC API based on
asymmetric cryptography? My understanding is that for OMAP4 GP chips,
ROM code switches to non-secure mode before passing control to the
bootloader and there is simply no way to workaround bugs like this.
The users are screwed.
Having some way to pass a small signed chunk of code through SMC API
could be a life saver if the erratum is particularly nasty. The vendor
could just contribute the signed piece of code with a few instructions
to set the needed bits in the needed registers in the case of
emergency.
--
Best regards,
Siarhei Siamashka
^ permalink raw reply
* [PATCH v3 0/5] ARM: multi-cluster aware boot protocol
From: Lorenzo Pieralisi @ 2012-11-15 12:46 UTC (permalink / raw)
To: linux-arm-kernel
This series is v3, referred to this previous posting:
http://lists.infradead.org/pipermail/linux-arm-kernel/2012-November/130966.html
Changes in v3:
- Fixed compatible string list format and vendors in Documentation
- Added check for MPIDR duplicates in the DT
- Added is_smp() check before reading the MPIDR in smp_setup_processor_id()
and also arm_dt_init_cpu_maps()
- Added check for 8 MSBs in arm_dt_init_cpu_maps()
- Updated comments and commit logs
Changes in v2:
- Reworded and added compatible property to cpus.txt
- Replaced while loop in arm_dt_init_cpu_maps() with a combination of
of_find_node_by_path and for_each_child_of_node
- Replaced of_get_property with of_property_read_u32
- Added further checks for DT /cpu nodes and implemented stashed array
to avoid overwriting the cpu_logical_map if DT contains errors
- Added GIC CPU IF define in the GIC probing code
- Removed printk for boot CPU MPIDR and added a patch that prints the full
extent of MPIDR in smp_setup_processor_id()
- Updated smp_setup_processor_id() so that it uses nr_cpu_ids
- Dropped RFC tag
The introduction of multi-cluster ARM systems in SoC designs requires the
kernel to become cluster aware, so that it can be booted on every CPU in the
system and it can build an appropriate HW-to-logical cpu map.
Current code in the kernel, in particular the boot sequence, hinges upon a
sequential mapping of MPIDR values for cpus and related interrupt controller
CPU interfaces to logical cpu indexing.
This hypothesis is not valid when the concept of cluster is introduced since
the MPIDR cannot be represented as a single index and interrupt controller
CPU interfaces can be wired with a numbering scheme following per-SoC
design parameters which can be only detected through probing or device
tree representation.
Through the device tree and "cpu" nodes bindings, the kernel is provided
with HW values for MPIDR registers that allow the kernel to identify the
HW CPU ids that are present in the platform.
The GIC code has been extended to allow automatic detection of GIC CPU IF ids
at boot. IPIs are broadcast to all possible CPUs, and every time a secondary
CPU is booted, it initializes its own mask and clears itself from the mask of
all other logical CPUs.
The device tree bindings and GIC probing allow to boot the Linux kernel on any
CPU of a multi-cluster system without relying on a platform specific hook to
identify the number of CPUs and hypothesis on the sequential pattern of MPIDRs
and relative GIC CPU IF ids.
Pen release code for all converted platforms will need patching to extend the
current MPIDR range check; this will take place as soon as the bindings and
code for the multi-cluster boot protocol will be reviewed and accepted.
The patchset has been tested on:
- TC2 testchip
to boot a 5-core dual-cluster system on every possible CPU.
Lorenzo Pieralisi (4):
ARM: kernel: smp_setup_processor_id() updates
ARM: kernel: add device tree init map function
ARM: kernel: add cpu logical map DT init in setup_arch
ARM: kernel: add logical mappings look-up
Nicolas Pitre (1):
ARM: gic: use a private mapping for CPU target interfaces
Documentation/devicetree/bindings/arm/cpus.txt | 78 ++++++++++++++++++++
arch/arm/common/gic.c | 45 +++++++++---
arch/arm/include/asm/prom.h | 2 +
arch/arm/include/asm/smp_plat.h | 17 +++++
arch/arm/kernel/devtree.c | 99 ++++++++++++++++++++++++++
arch/arm/kernel/setup.c | 8 ++-
6 files changed, 237 insertions(+), 12 deletions(-)
create mode 100644 Documentation/devicetree/bindings/arm/cpus.txt
--
1.7.12
^ permalink raw reply
* [PATCH v3 1/5] ARM: kernel: smp_setup_processor_id() updates
From: Lorenzo Pieralisi @ 2012-11-15 12:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352983614-22924-1-git-send-email-lorenzo.pieralisi@arm.com>
This patch applies some basic changes to the smp_setup_processor_id()
ARM implementation to make the code that builds cpu_logical_map more
uniform across the kernel.
The function now prints the full extent of the boot CPU MPIDR[23:0] and
initializes the cpu_logical_map for CPUs up to nr_cpu_ids.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
---
arch/arm/kernel/setup.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index da1d1aa..d0df6c8 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -426,13 +426,14 @@ int __cpu_logical_map[NR_CPUS];
void __init smp_setup_processor_id(void)
{
int i;
- u32 cpu = is_smp() ? read_cpuid_mpidr() & 0xff : 0;
+ u32 mpidr = is_smp() ? read_cpuid_mpidr() & 0xffffff : 0;
+ u32 cpu = mpidr & 0xff;
cpu_logical_map(0) = cpu;
- for (i = 1; i < NR_CPUS; ++i)
+ for (i = 1; i < nr_cpu_ids; ++i)
cpu_logical_map(i) = i == cpu ? 0 : i;
- printk(KERN_INFO "Booting Linux on physical CPU %d\n", cpu);
+ printk(KERN_INFO "Booting Linux on physical CPU 0x%x\n", mpidr);
}
static void __init setup_processor(void)
--
1.7.12
^ permalink raw reply related
* [PATCH v3 2/5] ARM: kernel: add device tree init map function
From: Lorenzo Pieralisi @ 2012-11-15 12:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352983614-22924-1-git-send-email-lorenzo.pieralisi@arm.com>
When booting through a device tree, the kernel cpu logical id map can be
initialized using device tree data passed by FW or through an embedded blob.
This patch adds a function that parses device tree "cpu" nodes and
retrieves the corresponding CPUs hardware identifiers (MPIDR).
It sets the possible cpus and the cpu logical map values according to
the number of CPUs defined in the device tree and respective properties.
The device tree HW identifiers are considered valid if all CPU nodes contain
a "reg" property, there are no duplicate "reg" entries and the DT defines a
CPU node whose "reg" property matches the MPIDR[23:0] of the boot CPU.
The primary CPU is assigned cpu logical number 0 to keep the current convention
valid.
Current bindings documentation is included in the patch:
Documentation/devicetree/bindings/arm/cpus.txt
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
---
Documentation/devicetree/bindings/arm/cpus.txt | 78 ++++++++++++++++++++
arch/arm/include/asm/prom.h | 2 +
arch/arm/kernel/devtree.c | 99 ++++++++++++++++++++++++++
3 files changed, 179 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/cpus.txt
diff --git a/Documentation/devicetree/bindings/arm/cpus.txt b/Documentation/devicetree/bindings/arm/cpus.txt
new file mode 100644
index 0000000..1fab07a
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/cpus.txt
@@ -0,0 +1,78 @@
+* ARM CPUs binding description
+
+The device tree allows to describe the layout of CPUs in a system through
+the "cpus" node, which in turn contains a number of subnodes (ie "cpu")
+defining properties for every cpu.
+
+Bindings for CPU nodes follow the ePAPR standard, available from:
+
+http://devicetree.org
+
+For the ARM architecture every CPU node must contain the following properties:
+
+- reg: property matching the CPU MPIDR[23:0] register bits
+ reg[31:24] bits must be set to 0
+- compatible: should be one of:
+ "arm,arm1020"
+ "arm,arm1020e"
+ "arm,arm1022"
+ "arm,arm1026"
+ "arm,arm720"
+ "arm,arm740"
+ "arm,arm7tdmi"
+ "arm,arm920"
+ "arm,arm922"
+ "arm,arm925"
+ "arm,arm926"
+ "arm,arm940"
+ "arm,arm946"
+ "arm,arm9tdmi"
+ "arm,cortex-a5"
+ "arm,cortex-a7"
+ "arm,cortex-a8"
+ "arm,cortex-a9"
+ "arm,cortex-a15"
+ "arm,arm1136"
+ "arm,arm1156"
+ "arm,arm1176"
+ "arm,arm11mpcore"
+ "faraday,fa526"
+ "intel,sa110"
+ "intel,sa1100"
+ "marvell,feroceon"
+ "marvell,mohawk"
+ "marvell,xsc3"
+ "marvell,xscale"
+
+Every cpu node is required to set its device_type to "cpu".
+
+Example:
+
+ cpus {
+ #size-cells = <0>;
+ #address-cells = <1>;
+
+ CPU0: cpu at 0 {
+ device_type = "cpu";
+ compatible = <arm, cortex-a15>;
+ reg = <0x0>;
+ };
+
+ CPU1: cpu at 1 {
+ device_type = "cpu";
+ compatible = <arm, cortex-a15>;
+ reg = <0x1>;
+ };
+
+ CPU2: cpu at 100 {
+ device_type = "cpu";
+ compatible = <arm, cortex-a7>;
+ reg = <0x100>;
+ };
+
+ CPU3: cpu at 101 {
+ device_type = "cpu";
+ compatible = <arm, cortex-a7>;
+ reg = <0x101>;
+ };
+ };
diff --git a/arch/arm/include/asm/prom.h b/arch/arm/include/asm/prom.h
index aeae9c6..8dd51dc 100644
--- a/arch/arm/include/asm/prom.h
+++ b/arch/arm/include/asm/prom.h
@@ -15,6 +15,7 @@
extern struct machine_desc *setup_machine_fdt(unsigned int dt_phys);
extern void arm_dt_memblock_reserve(void);
+extern void __init arm_dt_init_cpu_maps(void);
#else /* CONFIG_OF */
@@ -24,6 +25,7 @@ static inline struct machine_desc *setup_machine_fdt(unsigned int dt_phys)
}
static inline void arm_dt_memblock_reserve(void) { }
+static inline void arm_dt_init_cpu_maps(void) { }
#endif /* CONFIG_OF */
#endif /* ASMARM_PROM_H */
diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
index bee7f9d..cf840b3 100644
--- a/arch/arm/kernel/devtree.c
+++ b/arch/arm/kernel/devtree.c
@@ -19,8 +19,10 @@
#include <linux/of_irq.h>
#include <linux/of_platform.h>
+#include <asm/cputype.h>
#include <asm/setup.h>
#include <asm/page.h>
+#include <asm/smp_plat.h>
#include <asm/mach/arch.h>
#include <asm/mach-types.h>
@@ -61,6 +63,103 @@ void __init arm_dt_memblock_reserve(void)
}
}
+/*
+ * arm_dt_init_cpu_maps - Function retrieves cpu nodes from the device tree
+ * and builds the cpu logical map array containing MPIDR values related to
+ * logical cpus
+ *
+ * Updates the cpu possible mask with the number of parsed cpu nodes
+ */
+void __init arm_dt_init_cpu_maps(void)
+{
+ /*
+ * Temp logical map is initialized with UINT_MAX values that are
+ * considered invalid logical map entries since the logical map must
+ * contain a list of MPIDR[23:0] values where MPIDR[31:24] must
+ * read as 0.
+ */
+ struct device_node *cpu, *cpus;
+ u32 i, j, cpuidx = 1;
+ u32 mpidr = is_smp() ? read_cpuid_mpidr() & 0xffffff : 0;
+ u32 tmp_map[NR_CPUS] = { [0 ... NR_CPUS-1] = UINT_MAX };
+ bool bootcpu_valid = false;
+ cpus = of_find_node_by_path("/cpus");
+
+ if (!cpus)
+ return;
+
+ for_each_child_of_node(cpus, cpu) {
+ u32 hwid;
+
+ pr_debug(" * %s...\n", cpu->full_name);
+ /*
+ * A device tree containing CPU nodes with missing "reg"
+ * properties is considered invalid to build the
+ * cpu_logical_map.
+ */
+ if (of_property_read_u32(cpu, "reg", &hwid)) {
+ pr_debug(" * %s missing reg property\n",
+ cpu->full_name);
+ return;
+ }
+
+ /*
+ * 8 MSBs must be set to 0 in the DT since the reg property
+ * defines the MPIDR[23:0].
+ */
+ if (hwid & 0xff000000)
+ return;
+
+ /*
+ * Duplicate MPIDRs are a recipe for disaster.
+ * Scan all initialized entries and check for
+ * duplicates. If any is found just bail out.
+ * temp values were initialized to UINT_MAX
+ * to avoid matching valid MPIDR[23:0] values.
+ */
+ for (j = 0; j < cpuidx; j++)
+ if (WARN(tmp_map[j] == hwid, "Duplicate /cpu reg "
+ "properties in the DT\n"))
+ return;
+
+ /*
+ * Build a stashed array of MPIDR values. Numbering scheme
+ * requires that if detected the boot CPU must be assigned
+ * logical id 0. Other CPUs get sequential indexes starting
+ * from 1. If a CPU node with a reg property matching the
+ * boot CPU MPIDR is detected, this is recorded so that the
+ * logical map built from DT is validated and can be used
+ * to override the map created in smp_setup_processor_id().
+ */
+ if (hwid == mpidr) {
+ i = 0;
+ bootcpu_valid = true;
+ } else {
+ i = cpuidx++;
+ }
+
+ tmp_map[i] = hwid;
+
+ if (cpuidx > nr_cpu_ids)
+ break;
+ }
+
+ if (WARN(!bootcpu_valid, "DT missing boot CPU MPIDR[23:0], "
+ "fall back to default cpu_logical_map\n"))
+ return;
+
+ /*
+ * Since the boot CPU node contains proper data, and all nodes have
+ * a reg property, the DT CPU list can be considered valid and the
+ * logical map created in smp_setup_processor_id() can be overridden
+ */
+ for (i = 0; i < cpuidx; i++) {
+ set_cpu_possible(i, true);
+ cpu_logical_map(i) = tmp_map[i];
+ pr_debug("cpu logical map 0x%x\n", cpu_logical_map(i));
+ }
+}
+
/**
* setup_machine_fdt - Machine setup when an dtb was passed to the kernel
* @dt_phys: physical address of dt blob
--
1.7.12
^ permalink raw reply related
* [PATCH v3 3/5] ARM: kernel: add cpu logical map DT init in setup_arch
From: Lorenzo Pieralisi @ 2012-11-15 12:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352983614-22924-1-git-send-email-lorenzo.pieralisi@arm.com>
As soon as the device tree is unflattened the cpu logical to physical
mapping is carried out in setup_arch to build a proper array of MPIDR and
corresponding logical indexes.
The mapping could have been carried out using the flattened DT blob and
related primitives, but since the mapping is not needed by early boot
code it can safely be executed when the device tree has been uncompressed to
its tree data structure.
This patch adds the arm_dt_init_cpu maps() function call in setup_arch().
If the kernel is not compiled with DT support the function is empty and
no logical mapping takes place through it; the mapping carried out in
smp_setup_processor_id() is left unchanged.
If DT is supported the mapping created in smp_setup_processor_id() is overriden.
The DT mapping also sets the possible cpus mask, hence platform
code need not set it again in the respective smp_init_cpus() functions.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Acked-by: Will Deacon <will.deacon@arm.com>
---
arch/arm/kernel/setup.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index d0df6c8..7352073 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -759,6 +759,7 @@ void __init setup_arch(char **cmdline_p)
unflatten_device_tree();
+ arm_dt_init_cpu_maps();
#ifdef CONFIG_SMP
if (is_smp()) {
smp_set_ops(mdesc->smp);
--
1.7.12
^ permalink raw reply related
* [PATCH v3 4/5] ARM: kernel: add logical mappings look-up
From: Lorenzo Pieralisi @ 2012-11-15 12:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352983614-22924-1-git-send-email-lorenzo.pieralisi@arm.com>
In ARM SMP systems the MPIDR register ([23:0] bits) is used to uniquely
identify CPUs.
In order to retrieve the logical CPU index corresponding to a given
MPIDR value and guarantee a consistent translation throughout the kernel,
this patch adds a look-up based on the MPIDR[23:0] so that kernel subsystems
can use it whenever the logical cpu index corresponding to a given MPIDR
value is needed.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Acked-by: Will Deacon <will.deacon@arm.com>
---
arch/arm/include/asm/smp_plat.h | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/arch/arm/include/asm/smp_plat.h b/arch/arm/include/asm/smp_plat.h
index 558d6c8..aaa61b6 100644
--- a/arch/arm/include/asm/smp_plat.h
+++ b/arch/arm/include/asm/smp_plat.h
@@ -5,6 +5,9 @@
#ifndef __ASMARM_SMP_PLAT_H
#define __ASMARM_SMP_PLAT_H
+#include <linux/cpumask.h>
+#include <linux/err.h>
+
#include <asm/cputype.h>
/*
@@ -48,5 +51,19 @@ static inline int cache_ops_need_broadcast(void)
*/
extern int __cpu_logical_map[];
#define cpu_logical_map(cpu) __cpu_logical_map[cpu]
+/*
+ * Retrieve logical cpu index corresponding to a given MPIDR[23:0]
+ * - mpidr: MPIDR[23:0] to be used for the look-up
+ *
+ * Returns the cpu logical index or -EINVAL on look-up error
+ */
+static inline int get_logical_index(u32 mpidr)
+{
+ int cpu;
+ for (cpu = 0; cpu < nr_cpu_ids; cpu++)
+ if (cpu_logical_map(cpu) == mpidr)
+ return cpu;
+ return -EINVAL;
+}
#endif
--
1.7.12
^ permalink raw reply related
* [PATCH v3 5/5] ARM: gic: use a private mapping for CPU target interfaces
From: Lorenzo Pieralisi @ 2012-11-15 12:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352983614-22924-1-git-send-email-lorenzo.pieralisi@arm.com>
From: Nicolas Pitre <nicolas.pitre@linaro.org>
The GIC interface numbering does not necessarily follow the logical
CPU numbering, especially for complex topologies such as multi-cluster
systems.
Fortunately we can easily probe the GIC to create a mapping as the
Interrupt Processor Targets Registers for the first 32 interrupts are
read-only, and each field returns a value that always corresponds to
the processor reading the register.
Initially all mappings target all CPUs in case an IPI is required to
boot secondary CPUs. It is refined as those CPUs discover what their
actual mapping is.
Signed-off-by: Nicolas Pitre <nico@linaro.org>
Acked-by: Will Deacon <will.deacon@arm.com>
---
arch/arm/common/gic.c | 45 ++++++++++++++++++++++++++++++++++++---------
1 file changed, 36 insertions(+), 9 deletions(-)
diff --git a/arch/arm/common/gic.c b/arch/arm/common/gic.c
index 50c9eef..2203c92 100644
--- a/arch/arm/common/gic.c
+++ b/arch/arm/common/gic.c
@@ -70,6 +70,14 @@ struct gic_chip_data {
static DEFINE_RAW_SPINLOCK(irq_controller_lock);
/*
+ * The GIC mapping of CPU interfaces does not necessarily match
+ * the logical CPU numbering. Let's use a mapping as returned
+ * by the GIC itself.
+ */
+#define NR_GIC_CPU_IF 8
+static u8 gic_cpu_map[NR_GIC_CPU_IF] __read_mostly;
+
+/*
* Supported arch specific GIC irq extension.
* Default make them NULL.
*/
@@ -238,11 +246,11 @@ static int gic_set_affinity(struct irq_data *d, const struct cpumask *mask_val,
unsigned int cpu = cpumask_any_and(mask_val, cpu_online_mask);
u32 val, mask, bit;
- if (cpu >= 8 || cpu >= nr_cpu_ids)
+ if (cpu >= NR_GIC_CPU_IF || cpu >= nr_cpu_ids)
return -EINVAL;
mask = 0xff << shift;
- bit = 1 << (cpu_logical_map(cpu) + shift);
+ bit = gic_cpu_map[cpu] << shift;
raw_spin_lock(&irq_controller_lock);
val = readl_relaxed(reg) & ~mask;
@@ -349,11 +357,6 @@ static void __init gic_dist_init(struct gic_chip_data *gic)
u32 cpumask;
unsigned int gic_irqs = gic->gic_irqs;
void __iomem *base = gic_data_dist_base(gic);
- u32 cpu = cpu_logical_map(smp_processor_id());
-
- cpumask = 1 << cpu;
- cpumask |= cpumask << 8;
- cpumask |= cpumask << 16;
writel_relaxed(0, base + GIC_DIST_CTRL);
@@ -366,6 +369,7 @@ static void __init gic_dist_init(struct gic_chip_data *gic)
/*
* Set all global interrupts to this CPU only.
*/
+ cpumask = readl_relaxed(base + GIC_DIST_TARGET + 0);
for (i = 32; i < gic_irqs; i += 4)
writel_relaxed(cpumask, base + GIC_DIST_TARGET + i * 4 / 4);
@@ -389,9 +393,25 @@ static void __cpuinit gic_cpu_init(struct gic_chip_data *gic)
{
void __iomem *dist_base = gic_data_dist_base(gic);
void __iomem *base = gic_data_cpu_base(gic);
+ unsigned int cpu_mask, cpu = smp_processor_id();
int i;
/*
+ * Get what the GIC says our CPU mask is.
+ */
+ BUG_ON(cpu >= NR_GIC_CPU_IF);
+ cpu_mask = readl_relaxed(dist_base + GIC_DIST_TARGET + 0);
+ gic_cpu_map[cpu] = cpu_mask;
+
+ /*
+ * Clear our mask from the other map entries in case they're
+ * still undefined.
+ */
+ for (i = 0; i < NR_GIC_CPU_IF; i++)
+ if (i != cpu)
+ gic_cpu_map[i] &= ~cpu_mask;
+
+ /*
* Deal with the banked PPI and SGI interrupts - disable all
* PPI interrupts, ensure all SGI interrupts are enabled.
*/
@@ -654,7 +674,7 @@ void __init gic_init_bases(unsigned int gic_nr, int irq_start,
{
irq_hw_number_t hwirq_base;
struct gic_chip_data *gic;
- int gic_irqs, irq_base;
+ int gic_irqs, irq_base, i;
BUG_ON(gic_nr >= MAX_GIC_NR);
@@ -692,6 +712,13 @@ void __init gic_init_bases(unsigned int gic_nr, int irq_start,
}
/*
+ * Initialize the CPU interface map to all CPUs.
+ * It will be refined as each CPU probes its ID.
+ */
+ for (i = 0; i < NR_GIC_CPU_IF; i++)
+ gic_cpu_map[i] = 0xff;
+
+ /*
* For primary GICs, skip over SGIs.
* For secondary GICs, skip over PPIs, too.
*/
@@ -746,7 +773,7 @@ void gic_raise_softirq(const struct cpumask *mask, unsigned int irq)
/* Convert our logical CPU mask into a physical one. */
for_each_cpu(cpu, mask)
- map |= 1 << cpu_logical_map(cpu);
+ map |= gic_cpu_map[cpu];
/*
* Ensure that stores to Normal memory are visible to the
--
1.7.12
^ permalink raw reply related
* [PATCH] ARM: pxa: remove pxa95x support
From: Arnd Bergmann @ 2012-11-15 12:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAN1soZyfPT7pJjyO_vxGGhzC5hB_5XX1DAR2VwDP9XtH29FV8A@mail.gmail.com>
On Thursday 15 November 2012, Haojian Zhuang wrote:
> On Thu, Nov 15, 2012 at 8:14 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Thursday 15 November 2012, Arnd Bergmann wrote:
> >
> > "The assumption is that nobody will miss this support. If you are
> > reading this text because you actually require pxa95x support on
> > a new kernel, we can work out a way to revert this patch or add
> > support to the mmp platform".
>
> Yes, it's great. Please help to paste it into the changeset.
>
Ok, applied.
Arnd
^ permalink raw reply
* [GIT PULL][for 3.8] pull request from upload/board in arch-pxa git tree
From: Arnd Bergmann @ 2012-11-15 13:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50991FF6.8070709@yahoo.com>
On Tuesday 06 November 2012, Paul Parsons wrote:
> On 06/11/12 14:00, Olof Johansson wrote:
> > On Sun, Oct 28, 2012 at 07:59:54AM +0800, Haojian Zhuang wrote:
> >> ----------------------------------------------------------------
> >> Paul Parsons (1):
> >> ARM: pxa2xx: Remove EXPERIMENTAL dependency from spi-pxa2xx driver
> >
> > This is a SPI driver change, and should either go through or be acked by that
> > maintainer. In this particular case, there's been several series of the
> > EXPERIMENTAL removals, and I think Kees Cook has one that removes it for all
> > options in one go. So please ack that patch instead.
>
> According to the current MAINTAINERS file, the drivers/spi/spi-pxa2xx*
> driver is maintained by the PXA2xx/PXA3xx guys.
> That is why I submitted this patch to the linux-arm-kernel list.
> Is the MAINTAINERS file incorrect?
The file is correct, but it's not always easy to understand. drivers/spi
overall is maintained by Grant, which arch/arm/mach-* is maintained by
Olof and me. Haojian maintains the PXA components for each one, so the
formal way to do this is to have arch/arm/mach-pxa patches go
Author -> Haojian -> arm-soc -> Torvalds
while drivers/spi/spi-pxa* change go
Author -> Haojian -> Grant -> Torvalds
In some cases, you need extra knowledge that is not documented properly,
e.g. that Grant was on leave recently, and Mark Brown stepped in for
him, or that the arm-soc maintainership has not been documented at
all for some time (fixed now). In doubt, just add more people to Cc.
We're all good at ignoring email that doesn't seem to address us ;-)
Arnd
^ permalink raw reply
* [PATCH] ARM: add get_user() support for 8 byte types
From: Rob Clark @ 2012-11-15 13:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201211150919.37343.arnd@arndb.de>
On Thu, Nov 15, 2012 at 3:19 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Tuesday 13 November 2012, Russell King - ARM Linux wrote:
>> You're missing something; that is one of the greatest powers of open
>> source. The many eyes (and minds) effect. Someone out there probably
>> has a solution to whatever problem, the trick is to find that person. :)
>>
>> I think we have a working solution for this for ARM. It won't be suitable
>> for every arch, where they have 8-bit and 16-bit registers able to be
>> allocated by the compiler, but for architectures where the minimum register
>> size is 32-bit, what we have below should work.
>
> I don't mind at all adding the extension to ARM, and I think it's pretty
> cool that you guys actually found a working solution.
>
> The part that worries me is that we are making architecture independent
> code depend on a clever hack that may or may not be possible to implement
> on a given architecture, and that most architecture maintainers wouldn't
> know how to implement correctly even if it's possible.
I could always send a 3rd version with a comment smashed on about why
that works if you think this is a problem..
BR,
-R
> Arnd
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 1/2] ARM: ux500: Disable the MMCI gpio-regulator by default
From: Lee Jones @ 2012-11-15 13:14 UTC (permalink / raw)
To: linux-arm-kernel
Not all supported boards will require a MMCI gpio-regulator,
therefore it's a good idea to only enable the node when and if
it is required. Let's disable it by default.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
arch/arm/boot/dts/dbx5x0.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/dbx5x0.dtsi b/arch/arm/boot/dts/dbx5x0.dtsi
index 7ce45fc..d8ba489 100644
--- a/arch/arm/boot/dts/dbx5x0.dtsi
+++ b/arch/arm/boot/dts/dbx5x0.dtsi
@@ -642,6 +642,8 @@
gpio-enable = <&tc3589x_gpio 17 0x4>;
states = <1800000 0x1
2900000 0x0>;
+
+ status = "disabled";
};
};
};
--
1.7.9.5
^ permalink raw reply related
* [PATCH 2/2] ARM: ux500: Move board specific GPIO info out to subordinate DTS files
From: Lee Jones @ 2012-11-15 13:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352985288-29518-1-git-send-email-lee.jones@linaro.org>
GPIO numbers for the newly created gpio-regulator will differ from
board to board. Therefore it's not sensible to leave this information
in the top level DTSI file. Let's move them out to the DTS files
where they can correctly vary.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
arch/arm/boot/dts/dbx5x0.dtsi | 2 --
arch/arm/boot/dts/hrefprev60.dts | 7 +++++++
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/dbx5x0.dtsi b/arch/arm/boot/dts/dbx5x0.dtsi
index d8ba489..9f55363 100644
--- a/arch/arm/boot/dts/dbx5x0.dtsi
+++ b/arch/arm/boot/dts/dbx5x0.dtsi
@@ -638,8 +638,6 @@
regulator-name = "mmci-reg";
regulator-type = "voltage";
- gpios = <&tc3589x_gpio 18 0x4>;
- gpio-enable = <&tc3589x_gpio 17 0x4>;
states = <1800000 0x1
2900000 0x0>;
diff --git a/arch/arm/boot/dts/hrefprev60.dts b/arch/arm/boot/dts/hrefprev60.dts
index b398946..eec29c4 100644
--- a/arch/arm/boot/dts/hrefprev60.dts
+++ b/arch/arm/boot/dts/hrefprev60.dts
@@ -37,5 +37,12 @@
reset-gpio = <&tc3589x_gpio 13 0x4>;
};
};
+
+ vmmci: regulator-gpio {
+ gpios = <&tc3589x_gpio 18 0x4>;
+ gpio-enable = <&tc3589x_gpio 17 0x4>;
+
+ status = "okay";
+ };
};
};
--
1.7.9.5
^ permalink raw reply related
* [PATCH 1/1] mtd: physmap_of: allow to specify the mtd name for retro compatiblity
From: Grant Likely @ 2012-11-15 13:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352062641-31850-1-git-send-email-plagnioj@jcrosoft.com>
On Sun, 4 Nov 2012 21:57:21 +0100, Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> wrote:
> linux,mtd-name allow to specify the mtd name for retro capability with
> physmap-flash drivers as boot loader pass the mtd partition via the old
> device name physmap-flash.
Ummm. I don't follow. Could you explain more about how this change will
be used?
Thanks,
g.
>
> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
> ---
> Documentation/devicetree/bindings/mtd/mtd-physmap.txt | 3 +++
> drivers/mtd/maps/physmap_of.c | 5 ++++-
> 2 files changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/mtd/mtd-physmap.txt b/Documentation/devicetree/bindings/mtd/mtd-physmap.txt
> index 94de19b..dab7847 100644
> --- a/Documentation/devicetree/bindings/mtd/mtd-physmap.txt
> +++ b/Documentation/devicetree/bindings/mtd/mtd-physmap.txt
> @@ -23,6 +23,9 @@ file systems on embedded devices.
> unaligned accesses as implemented in the JFFS2 code via memcpy().
> By defining "no-unaligned-direct-access", the flash will not be
> exposed directly to the MTD users (e.g. JFFS2) any more.
> + - linux,mtd-name: allow to specify the mtd name for retro capability with
> + physmap-flash drivers as boot loader pass the mtd partition via the old
> + device name physmap-flash.
>
> For JEDEC compatible devices, the following additional properties
> are defined:
> diff --git a/drivers/mtd/maps/physmap_of.c b/drivers/mtd/maps/physmap_of.c
> index 6f19aca..9a8db0c 100644
> --- a/drivers/mtd/maps/physmap_of.c
> +++ b/drivers/mtd/maps/physmap_of.c
> @@ -170,6 +170,7 @@ static int __devinit of_flash_probe(struct platform_device *dev)
> resource_size_t res_size;
> struct mtd_part_parser_data ppdata;
> bool map_indirect;
> + const char *mtd_name;
>
> match = of_match_device(of_flash_match, &dev->dev);
> if (!match)
> @@ -178,6 +179,8 @@ static int __devinit of_flash_probe(struct platform_device *dev)
>
> reg_tuple_size = (of_n_addr_cells(dp) + of_n_size_cells(dp)) * sizeof(u32);
>
> + of_property_read_string(dp, "linux,mtd-name", &mtd_name);
> +
> /*
> * Get number of "reg" tuples. Scan for MTD devices on area's
> * described by each "reg" region. This makes it possible (including
> @@ -234,7 +237,7 @@ static int __devinit of_flash_probe(struct platform_device *dev)
> goto err_out;
> }
>
> - info->list[i].map.name = dev_name(&dev->dev);
> + info->list[i].map.name = mtd_name ? mtd_name : dev_name(&dev->dev);
> info->list[i].map.phys = res.start;
> info->list[i].map.size = res_size;
> info->list[i].map.bankwidth = be32_to_cpup(width);
> --
> 1.7.10.4
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
Grant Likely, B.Sc, P.Eng.
Secret Lab Technologies, Ltd.
^ permalink raw reply
* [RFC PATCH 0/3] introduce static_vm for ARM-specific static mapped area
From: JoonSoo Kim @ 2012-11-15 13:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121114173928.GK3290@n2100.arm.linux.org.uk>
Hello, Russell.
Thanks for review.
2012/11/15 Russell King - ARM Linux <linux@arm.linux.org.uk>:
> On Thu, Nov 15, 2012 at 01:55:51AM +0900, Joonsoo Kim wrote:
>> In current implementation, we used ARM-specific flag, that is,
>> VM_ARM_STATIC_MAPPING, for distinguishing ARM specific static mapped area.
>> The purpose of static mapped area is to re-use static mapped area when
>> entire physical address range of the ioremap request can be covered
>> by this area.
>>
>> This implementation causes needless overhead for some cases.
>
> In what cases?
For example, assume that there is only one static mapped area and
vmlist has 300 areas.
Every time we call ioremap, we check 300 areas for deciding whether it
is matched or not.
Moreover, even if there is no static mapped area and vmlist has 300 areas,
every time we call ioremap, we check 300 areas in now.
>> We unnecessarily iterate vmlist for finding matched area even if there
>> is no static mapped area. And if there are some static mapped areas,
>> iterating whole vmlist is not preferable.
>
> Why not? Please put some explanation into your message rather than
> just statements making unexplained assertions.
If we construct a extra list for static mapped area, we can eliminate
above mentioned overhead.
With a extra list, if there is one static mapped area,
we just check only one area and proceed next operation quickly.
>> Another reason for doing this work is for removing architecture dependency
>> on vmalloc layer. I think that vmlist and vmlist_lock is internal data
>> structure for vmalloc layer. Some codes for debugging and stat inevitably
>> use vmlist and vmlist_lock. But it is preferable that they are used outside
>> of vmalloc.c as least as possible.
>
> The vmalloc layer is also made available for ioremap use, and it is
> intended that architectures hook into this for ioremap support.
Yes.
But, I think that it is preferable to use well-defined vmalloc API rather than
directly manipulating low-level data structure. IMHO, if there is no suitable
vmalloc API, making new one is better than directly manipulating
low-level data structure. It makes vmalloc code more maintainable.
I'm not expert, so please let me know what I missed.
Thanks.
^ permalink raw reply
* [PATCH v5 0/4] arch/arm: support seccomp
From: Will Deacon @ 2012-11-15 13:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGXu5jKYGCkL3GS4Tbep==WUAqP-c_0edAdgy0XQ84rJxZUU2Q@mail.gmail.com>
On Wed, Nov 14, 2012 at 07:07:13PM +0000, Kees Cook wrote:
> Hi, any more thoughts on this series? I'd really like to get it into
> -next. It's been running happily for a while now in the Chrome OS ARM
> devices.
I'm not familiar with seccomp in general, but the changes look ok now from
an ARM point-of-view:
Reviewed-by: Will Deacon <will.deacon@arm.com>
These should probably go via Russell (who will put them into -next), so
please send them to the patch system.
Will
^ permalink raw reply
* [PATCH 0/2] clk: ux500: Make mtu driver use apb_pclock
From: Linus Walleij @ 2012-11-15 13:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201211151221.30217.arnd@arndb.de>
On Thu, Nov 15, 2012 at 1:21 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> If I understand the problem at hand correctly, the safe solution
> should be to base the ux500 clk changes on top of c3b9d1db23c4e,
> which is in the nomadik/plat-removal branch in arm-soc that got
> merged into next/multiplatform. I would prefer if you use that
> as a base instead of the larger next/multiplatform branch that
> also contains vt8500 and other changes.
OK I'll take a stab at this and see if I can fix it...
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] arm/dts: Add basic support for gta04 (Openmoko next generation) board.
From: Belisko Marek @ 2012-11-15 13:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121115115925.2FE453E09BB@localhost>
CC'ing Tony
On Thu, Nov 15, 2012 at 12:59 PM, Grant Likely
<grant.likely@secretlab.ca> wrote:
> On Wed, 14 Nov 2012 21:26:58 +0100, Belisko Marek <marek.belisko@gmail.com> wrote:
>> CC' Grant & Rob
>
> Hi Marek
>
> Since this is an OMAP board, you should send the changes to Tony and
> they should be merged through the arm-soc tree.
>
> g.
>
>>
>> On Tue, Oct 30, 2012 at 10:42 PM, Marek Belisko
>> <marek.belisko@open-nandra.com> wrote:
>> > Signed-off-by: Marek Belisko <marek.belisko@open-nandra.com>
>> > ---
>> > arch/arm/boot/dts/omap3-gta04.dts | 65 +++++++++++++++++++++++++++++++++++++
>> > 1 file changed, 65 insertions(+)
>> > create mode 100644 arch/arm/boot/dts/omap3-gta04.dts
>> >
>> > diff --git a/arch/arm/boot/dts/omap3-gta04.dts b/arch/arm/boot/dts/omap3-gta04.dts
>> > new file mode 100644
>> > index 0000000..76efd13
>> > --- /dev/null
>> > +++ b/arch/arm/boot/dts/omap3-gta04.dts
>> > @@ -0,0 +1,65 @@
>> > +/*
>> > + * Copyright (C) 2012 Marek Belisko <marek.belisko@open-nandra.com>
>> > + *
>> > + * Based on omap3-beagle-xm.dts
>> > + *
>> > + * This program is free software; you can redistribute it and/or modify
>> > + * it under the terms of the GNU General Public License version 2 as
>> > + * published by the Free Software Foundation.
>> > + */
>> > +/dts-v1/;
>> > +
>> > +/include/ "omap3.dtsi"
>> > +
>> > +/ {
>> > + model = "OMAP3 GTA04";
>> > + compatible = "ti,omap3-gta04", "ti,omap3";
>> > +
>> > + memory {
>> > + device_type = "memory";
>> > + reg = <0x80000000 0x20000000>; /* 512 MB */
>> > + };
>> > +
>> > + gpio-keys {
>> > + compatible = "gpio-keys";
>> > + #address-cells = <1>;
>> > + #size-cells = <0>;
>> > + aux-button {
>> > + label = "AUX";
>> > + linux,code = <169>;
>> > + gpios = <&gpio1 7 1>;
>> > + gpio-key,wakeup;
>> > + };
>> > + };
>> > +};
>> > +
>> > +&i2c1 {
>> > + clock-frequency = <2600000>;
>> > +
>> > + twl: twl at 48 {
>> > + reg = <0x48>;
>> > + interrupts = <7>; /* SYS_NIRQ cascaded to intc */
>> > + interrupt-parent = <&intc>;
>> > + };
>> > +};
>> > +
>> > +/include/ "twl4030.dtsi"
>> > +
>> > +&i2c2 {
>> > + clock-frequency = <400000>;
>> > + /* Pressure Sensor */
>> > + bmp085 at 77 {
>> > + compatible = "bosch,bmp085";
>> > + reg = <0x77>;
>> > + };
>> > +};
>> > +
>> > +&i2c3 {
>> > + clock-frequency = <100000>;
>> > +};
>> > +
>> > +&mmc1 {
>> > + vmmc-supply = <&vmmc1>;
>> > + bus-width = <4>;
>> > +};
>> > +
>> > --
>> > 1.7.9.5
>> >
>>
>>
>>
>> --
>> as simple and primitive as possible
>> -------------------------------------------------
>> Marek Belisko - OPEN-NANDRA
>> Freelance Developer
>>
>> Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
>> Tel: +421 915 052 184
>> skype: marekwhite
>> twitter: #opennandra
>> web: http://open-nandra.com
>
> --
> Grant Likely, B.Sc, P.Eng.
> Secret Lab Technologies, Ltd.
Marek
--
as simple and primitive as possible
-------------------------------------------------
Marek Belisko - OPEN-NANDRA
Freelance Developer
Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
^ permalink raw reply
* [PATCH] ARM i.MX dts: Consistently add labels to devicenodes
From: Sascha Hauer @ 2012-11-15 13:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121115134831.GA2546@S2100-06.ap.freescale.net>
On Thu, Nov 15, 2012 at 09:48:33PM +0800, Shawn Guo wrote:
> On Thu, Nov 15, 2012 at 09:31:52AM +0100, Sascha Hauer wrote:
> > Having labels before each node allows board bindings to reference
> > to nodes by using the &nodename {} notation.
>
> I can understand this part.
>
> > This way boards do not
> > have to resemble the whole devicetree layout. Due to less indention
> > needed the board files also get better readability.
>
> I do not understand it. Don't we have to always maintain the device
> tree layout defined by <soc>.dtsi in <board>.dts, do we?
Have a look at for example arch/arm/boot/dts/omap5-evm.dts, it is
written like this:
...
&mmc1 {
vmmc-supply = <&vmmcsd_fixed>;
bus-width = <4>;
};
&mmc2 {
vmmc-supply = <&vmmcsd_fixed>;
bus-width = <8>;
ti,non-removable;
};
&mmc3 {
bus-width = <4>;
ti,non-removable;
};
...
I've written some board dts from scratch yesterday and this is much
easier to write (and I think also easier to read as I don't have to
care about the tree layout when writing a dts).
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* [PATCH] ARM: Fix errata 751472 handling on Cortex-A9 r1p*
From: Russell King - ARM Linux @ 2012-11-15 13:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACY+gR3PurUofCbUeG40B6vXqXAoHrMmbOQSuwAGoc1LS8XXJQ@mail.gmail.com>
On Thu, Nov 15, 2012 at 02:41:43PM +0200, Siarhei Siamashka wrote:
> BTW, I always wondered about what could be preventing TI and the other
> silicon vendors from using something like an SMC API based on
> asymmetric cryptography?
The answer is... nothing. But it didn't happen and we're stuck with the
consequences of that.
^ permalink raw reply
* [PATCH v2 1/2] ARM: mx27: Add VPU support
From: Fabio Estevam @ 2012-11-15 13:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121115081223.GY10369@pengutronix.de>
On Thu, Nov 15, 2012 at 6:12 AM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> As Eric mentioned this may lead to problems on the i.MX27L without VPU.
> Do you have the possibility to test this?
I do not have any board with a MX27L variant. Maybe we could try
reading the SREV info register to distinguish between MX27 and MX27L.
MX27RM does not provide any info on this though.
If this does not work, then maybe we should register VPU as per board
like the v1 patch did.
Regards,
Fabio Estevam
^ permalink raw reply
* [PATCH] ARM: add get_user() support for 8 byte types
From: Arnd Bergmann @ 2012-11-15 13:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAF6AEGv-O_D6nOnEwi5w8NUcv+dQFe7pJBXhUA8xq+tykG4dfg@mail.gmail.com>
On Thursday 15 November 2012, Rob Clark wrote:
> On Thu, Nov 15, 2012 at 3:19 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Tuesday 13 November 2012, Russell King - ARM Linux wrote:
> >> You're missing something; that is one of the greatest powers of open
> >> source. The many eyes (and minds) effect. Someone out there probably
> >> has a solution to whatever problem, the trick is to find that person. :)
> >>
> >> I think we have a working solution for this for ARM. It won't be suitable
> >> for every arch, where they have 8-bit and 16-bit registers able to be
> >> allocated by the compiler, but for architectures where the minimum register
> >> size is 32-bit, what we have below should work.
> >
> > I don't mind at all adding the extension to ARM, and I think it's pretty
> > cool that you guys actually found a working solution.
> >
> > The part that worries me is that we are making architecture independent
> > code depend on a clever hack that may or may not be possible to implement
> > on a given architecture, and that most architecture maintainers wouldn't
> > know how to implement correctly even if it's possible.
>
> I could always send a 3rd version with a comment smashed on about why
> that works if you think this is a problem..
Comments are always good, so I'd surely like to see those get added.
As I said, I don't have any objections to the addition of your patch to
the ARM code, which sounds useful to have.
I still haven't heard a conclusive argument why we need to use get_user()
rather than copy_from_user() in the DRM code. Is this about a fast path
where you want to shave off a few cycles for each call, or does this
simplify the code structure, or something else?
Arnd
^ permalink raw reply
* ttySAC0 or ttyS0 in 3.6.x ARM Linux?
From: Domenico Andreoli @ 2012-11-15 13:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <k824bb$7kp$1@ger.gmane.org>
On Thu, Nov 15, 2012 at 03:07:24PM +0800, woody wrote:
> Hi,
Hi,
> In the 3.6.6 ARM kernel, should I use ttySAC0 or ttyS0 to specify
> the 'console' kernel command line?
it depends on the driver used for your console. ttySAC is Samsung. which
kind of uart do you have?
Regards,
Domenico
^ permalink raw reply
* [PATCH 1/4] pinctrl: dove: Prevent NULL dereference if of_match_device returns NULL
From: Axel Lin @ 2012-11-15 13:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121115083511.08f5a16f@skate>
2012/11/15 Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> Dear Axel Lin,
>
> On Thu, 15 Nov 2012 12:51:36 +0800, Axel Lin wrote:
> > of_match_device() may return NULL.
> >
> > Signed-off-by: Axel Lin <axel.lin@ingics.com>
>
> Could you detail under what conditions of_match_device() may return
> NULL in the specific case of this driver? This of_match_device() call
> is using the same dove_pinctrl_of_match array that is used to ->probe()
> this driver. So I don't see how you can get into ->probe() without
> having a matching entry.
>
> Am I missing something?
>
hi Thomas,
You are right.
I was thinking when the case CONFIG_OF is not selected,
of_match_ptr(dove_pinctrl_of_match) is NULL and of_match_device returns
NULL.
But this driver only works when CONFIG_OF is selected.
BTW, I found there is no way to compile the dove and kirkwood pinctrl
drivers.
I need add below patch to compile these two drivers, how do you think about
below patch?
( In dove, the USE_OF is optional, it is selected only when MACH_DOVE_DT is
enabled )
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 14f8160..dda6785 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -531,6 +531,8 @@ config ARCH_DOVE
select CPU_V7
select GENERIC_CLOCKEVENTS
select MIGHT_HAVE_PCI
+ select PINCTRL
+ select PINCTRL_DOVE if USE_OF
select PLAT_ORION_LEGACY
select USB_ARCH_HAS_EHCI
help
@@ -542,6 +544,8 @@ config ARCH_KIRKWOOD
select CPU_FEROCEON
select GENERIC_CLOCKEVENTS
select PCI
+ select PINCTRL
+ select PINCTRL_KIRKWOOD
select PLAT_ORION_LEGACY
help
Support for the following Marvell Kirkwood series SoCs:
Regards,
Axel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121115/be2e1627/attachment-0001.html>
^ permalink raw reply related
* [PATCH v2 1/2] ARM: mx27: Add VPU support
From: Sascha Hauer @ 2012-11-15 13:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5BrzD5okmRMcY3X3aquMpmxV5Pn2k2upsQNhsmq_Pi5-A@mail.gmail.com>
On Thu, Nov 15, 2012 at 11:38:01AM -0200, Fabio Estevam wrote:
> On Thu, Nov 15, 2012 at 6:12 AM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
>
> > As Eric mentioned this may lead to problems on the i.MX27L without VPU.
> > Do you have the possibility to test this?
>
> I do not have any board with a MX27L variant. Maybe we could try
> reading the SREV info register to distinguish between MX27 and MX27L.
> MX27RM does not provide any info on this though.
If that works I would prefer this, but I also have no i.MX27L to test
it. Otherwise doing it like v1 is the best we can do.
You should probably put the changes to Javiers board into a separate
patch so that Javier can Ack it indepently of what we are coming up
with.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
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