* [PATCH V3 01/13] ARM: OMAP: Add DMTIMER definitions for posted mode
From: Jon Hunter @ 2012-11-12 18:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352744444-2633-1-git-send-email-jon-hunter@ti.com>
For OMAP2+ devices, when using DMTIMERs for system timers (clock-events and
clock-source) the posted mode configuration of the timers is used. To allow
the compiler to optimise the functions for configuring and reading the system
timers, the posted flag variable is hard-coded with the value 1. To make it
clear that posted mode is being used add some definitions so that it is more
readable.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
arch/arm/mach-omap2/timer.c | 17 ++++++++++-------
arch/arm/plat-omap/include/plat/dmtimer.h | 4 ++++
2 files changed, 14 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 684d2fc..a135d28 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -108,7 +108,7 @@ static int omap2_gp_timer_set_next_event(unsigned long cycles,
struct clock_event_device *evt)
{
__omap_dm_timer_load_start(&clkev, OMAP_TIMER_CTRL_ST,
- 0xffffffff - cycles, 1);
+ 0xffffffff - cycles, OMAP_TIMER_POSTED);
return 0;
}
@@ -118,7 +118,7 @@ static void omap2_gp_timer_set_mode(enum clock_event_mode mode,
{
u32 period;
- __omap_dm_timer_stop(&clkev, 1, clkev.rate);
+ __omap_dm_timer_stop(&clkev, OMAP_TIMER_POSTED, clkev.rate);
switch (mode) {
case CLOCK_EVT_MODE_PERIODIC:
@@ -126,10 +126,10 @@ static void omap2_gp_timer_set_mode(enum clock_event_mode mode,
period -= 1;
/* Looks like we need to first set the load value separately */
__omap_dm_timer_write(&clkev, OMAP_TIMER_LOAD_REG,
- 0xffffffff - period, 1);
+ 0xffffffff - period, OMAP_TIMER_POSTED);
__omap_dm_timer_load_start(&clkev,
OMAP_TIMER_CTRL_AR | OMAP_TIMER_CTRL_ST,
- 0xffffffff - period, 1);
+ 0xffffffff - period, OMAP_TIMER_POSTED);
break;
case CLOCK_EVT_MODE_ONESHOT:
break;
@@ -359,7 +359,8 @@ static bool use_gptimer_clksrc;
*/
static cycle_t clocksource_read_cycles(struct clocksource *cs)
{
- return (cycle_t)__omap_dm_timer_read_counter(&clksrc, 1);
+ return (cycle_t)__omap_dm_timer_read_counter(&clksrc,
+ OMAP_TIMER_POSTED);
}
static struct clocksource clocksource_gpt = {
@@ -373,7 +374,8 @@ static struct clocksource clocksource_gpt = {
static u32 notrace dmtimer_read_sched_clock(void)
{
if (clksrc.reserved)
- return __omap_dm_timer_read_counter(&clksrc, 1);
+ return __omap_dm_timer_read_counter(&clksrc,
+ OMAP_TIMER_POSTED);
return 0;
}
@@ -455,7 +457,8 @@ static void __init omap2_gptimer_clocksource_init(int gptimer_id,
BUG_ON(res);
__omap_dm_timer_load_start(&clksrc,
- OMAP_TIMER_CTRL_ST | OMAP_TIMER_CTRL_AR, 0, 1);
+ OMAP_TIMER_CTRL_ST | OMAP_TIMER_CTRL_AR, 0,
+ OMAP_TIMER_POSTED);
setup_sched_clock(dmtimer_read_sched_clock, 32, clksrc.rate);
if (clocksource_register_hz(&clocksource_gpt, clksrc.rate))
diff --git a/arch/arm/plat-omap/include/plat/dmtimer.h b/arch/arm/plat-omap/include/plat/dmtimer.h
index f8943c8..1bee0ac 100644
--- a/arch/arm/plat-omap/include/plat/dmtimer.h
+++ b/arch/arm/plat-omap/include/plat/dmtimer.h
@@ -55,6 +55,10 @@
#define OMAP_TIMER_TRIGGER_OVERFLOW 0x01
#define OMAP_TIMER_TRIGGER_OVERFLOW_AND_COMPARE 0x02
+/* posted mode types */
+#define OMAP_TIMER_NONPOSTED 0x00
+#define OMAP_TIMER_POSTED 0x01
+
/* timer capabilities used in hwmod database */
#define OMAP_TIMER_SECURE 0x80000000
#define OMAP_TIMER_ALWON 0x40000000
--
1.7.9.5
^ permalink raw reply related
* [PATCH V3 00/13] ARM: OMAP: DMTIMER fixes
From: Jon Hunter @ 2012-11-12 18:20 UTC (permalink / raw)
To: linux-arm-kernel
This series includes several fixes for the OMAP DMTIMER driver. This is
based upon Tony Lindgren's current master branch [1].
Tested on OMAP5912 OSK, OMAP2420 H4, OMAP3430 Beagle and OMAP4430 Panda.
Testing includes ...
1. Booting kernel on above boards
2. Set date and ensuring time of day is correct after 24 hours
3. Checking the timer counter is incrementing when configuring and starting
a timer
4. Checking the timer overflow interrupt when timer expires.
5. Using different clock sources to operate the timer with.
6. Running a loop test overnight that continually runs test #3 and #4 for
each available timer
This has also been boot tested on the AM335x Beagle Bone.
V3 changes:
- Combined patches #2 and #3 in version 2 series into single patch.
- Updated errata i103/i767 workaround to pass errata information via
platform data to avoid using cpu_is_xxxx() macros in dmtimer driver.
[1] http://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git
Jon Hunter (13):
ARM: OMAP: Add DMTIMER definitions for posted mode
ARM: OMAP3+: Implement timer workaround for errata i103 and i767
ARM: OMAP: Fix timer posted mode support
ARM: OMAP3: Correct HWMOD DMTIMER SYSC register declarations
ARM: OMAP2/3: Define HWMOD software reset status for DMTIMERs
ARM: OMAP2+: Don't use __omap_dm_timer_reset()
ARM: OMAP: Fix dmtimer reset for timer1
ARM: OMAP: Don't restore of DMTIMER TISTAT register
ARM: OMAP: Don't restore DMTIMER interrupt status register
ARM: OMAP: Fix spurious interrupts when using timer match feature
ARM: OMAP: Add dmtimer interrupt disable function
ARM: OMAP: Remove unnecessary call to clk_get()
ARM: OMAP: Remove __omap_dm_timer_set_source function
arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c | 15 +++-
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 41 +++++------
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 4 +
arch/arm/mach-omap2/timer.c | 70 +++++++++++++-----
arch/arm/plat-omap/dmtimer.c | 77 ++++++++++++--------
arch/arm/plat-omap/include/plat/dmtimer.h | 72 +++++++++++++-----
6 files changed, 188 insertions(+), 91 deletions(-)
--
1.7.9.5
^ permalink raw reply
* [PATCH 1/3] gpio: Add simple poweroff-gpio driver
From: Andrew Lunn @ 2012-11-12 18:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50A1212C.2080601@wwwdotorg.org>
On Mon, Nov 12, 2012 at 09:17:48AM -0700, Stephen Warren wrote:
> On 11/12/2012 01:25 AM, Andrew Lunn wrote:
> > On Sun, Nov 11, 2012 at 03:03:49PM -0700, Stephen Warren wrote:
> >> On 11/11/2012 09:21 AM, Andrew Lunn wrote:
> >>> From: Jamie Lentin <jm@lentin.co.uk>
> >>>
> >>> Given appropriate devicetree bindings, this driver registers a
> >>> pm_power_off function to set a GPIO line high/low to power down
> >>> your board.
>
> >>> diff --git a/Documentation/devicetree/bindings/gpio/gpio-poweroff.txt b/Documentation/devicetree/bindings/gpio/gpio-poweroff.txt
> >>
> >>> +Required properties:
> >>> +- compatible : should be "gpio-poweroff".
> >>> +- gpios : The GPIO to set high/low, see "gpios property" in
> >>> + Documentation/devicetree/bindings/gpio/gpio.txt. If the pin should be
> >>> + low to power down the board set it to "Active Low", otherwise set
> >>> + gpio to "Active High".
> >>
> >> Unfortunately, not all GPIO bindings support active high/low flags in
> >> the GPIO specifier. As such, the flags there are basically useless.
> >> Other bindings (e.g. IIRC the fixed-regulator binding) have added a
> >> separate active-high property to indicate the GPIO polarity. This
> >> binding should probably follow suite.
> >
> > Humm, so are you saying of_get_named_gpio_flags() is deprecated?
>
> I don't know if it's deprecated, but it's certainly not useful in
> generic code.
Hi Linus, Anton
How do you see this?
I'm happy to implement an enable-active-high property, but it seems to
go against the purpose of of_get_named_gpio_flags(). Is that function
deprecated?
Thanks
Andrew
^ permalink raw reply
* [RFC PATCH 1/4] ARM: S3C24XX: move s3c24xx-irq to drivers/irqchip
From: Heiko Stübner @ 2012-11-12 18:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50A12C63.2000609@wwwdotorg.org>
Am Montag, 12. November 2012, 18:05:39 schrieb Stephen Warren:
> On 11/12/2012 06:47 AM, Heiko St?bner wrote:
> > Removes another part from plat-s3c24xx and also enables further
> > improvements happening in the correct location.
> >
> > Signed-off-by: Heiko Stuebner <heiko@sntech.de>
> > ---
> >
> > arch/arm/Kconfig | 1 +
> > arch/arm/plat-s3c24xx/Makefile | 1 -
> > drivers/irqchip/Kconfig | 3 +++
> > drivers/irqchip/Makefile | 1 +
> > .../irq.c => drivers/irqchip/irq-s3c24xx.c | 0
> > 5 files changed, 5 insertions(+), 1 deletions(-)
> > rename arch/arm/plat-s3c24xx/irq.c => drivers/irqchip/irq-s3c24xx.c
> > (100%)
>
> Presumably there's a header file somewhere that defines the interface to
> irq-s3c24xx.c that other code in arch/arm/plat-s3c24xx is using to
> initialize it. That header should be moved somewhere public (i.e.
> outside {mach,plat}-*/include/{mach,plat}). However, you then end up
> with a header file per IRQ driver in that public location. So, Thomas
>
> Petazzoni started working on a solution for that:
> > http://lists.arm.linux.org.uk/lurker/message/20121027.164514.11eb86db.en.
> > html
cool, thanks for the pointer :-) .
For the headers, yes they are present and still in mach/plat. My intention was
to first clean it up and then move the remaing necessary header.
I'm not sure what is the policy for adding stuff to drivers/irqchip (dt-
only?), because _all_ s3c24xx subtypes using devicetree seems very very far in
the future, if at all.
So when thinking a bit more about it, it might be better to keep the irq code
in arch/arm for the time being?
Because non-dt init code will probably be necessary for a lot more time.
Heiko
^ permalink raw reply
* [PATCH v4] Network driver for the Armada 370 and Armada XP ARM Marvell SoCs
From: Thomas Petazzoni @ 2012-11-12 17:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121103115321.GA4539@electric-eye.fr.zoreil.com>
Hello Fran?ois,
On Sat, 3 Nov 2012 12:53:21 +0100, Francois Romieu wrote:
> Thomas Petazzoni <thomas.petazzoni@free-electrons.com> :
> [...]
> > Any comments on this patch set? What should I do to make it progress
> > towards integration?
>
> Nits review above. I'll search more substantial things this evening.
> It looks quite good.
Thanks a lot for your reviews. I completely forgot to take your
comments into account for my v5, I was focused on the MDIO changes. I
will resend a v6 tomorrow that takes into account your comments.
Do not hesitate to get back to me if you have more comments after a
more substantial review.
Thanks,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH linux-next] ARM: OMAP2: Fix compillation error in cm_common
From: Tony Lindgren @ 2012-11-12 17:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1211121625150.6043@utopia.booyaka.com>
* Paul Walmsley <paul@pwsan.com> [121112 08:27]:
> Hi
>
> On Mon, 12 Nov 2012, Peter Ujfalusi wrote:
>
> > Fixes the following error:
> > CC arch/arm/mach-omap2/cm_common.o
> > arch/arm/mach-omap2/cm_common.c: In function ?cm_register?:
> > arch/arm/mach-omap2/cm_common.c:42:11: error: ?EINVAL? undeclared (first use in this function)
> > arch/arm/mach-omap2/cm_common.c:42:11: note: each undeclared identifier is reported only once for each function it appears in
> > arch/arm/mach-omap2/cm_common.c:45:11: error: ?EEXIST? undeclared (first use in this function)
> > arch/arm/mach-omap2/cm_common.c: In function ?cm_unregister?:
> > arch/arm/mach-omap2/cm_common.c:66:11: error: ?EINVAL? undeclared (first use in this function)
> > make[1]: *** [arch/arm/mach-omap2/cm_common.o] Error 1
> > make: *** [arch/arm/mach-omap2] Error 2
> >
> > Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
> > ---
> >
> > Hi,
> >
> > with today's linux-next the kernel build failed with the abive error for OMAP.
> >
> > Regards,
> > Peter
> >
> > arch/arm/mach-omap2/cm_common.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/arch/arm/mach-omap2/cm_common.c b/arch/arm/mach-omap2/cm_common.c
> > index 3246cef..3fafc27 100644
> > --- a/arch/arm/mach-omap2/cm_common.c
> > +++ b/arch/arm/mach-omap2/cm_common.c
> > @@ -13,6 +13,7 @@
> >
> > #include <linux/kernel.h>
> > #include <linux/init.h>
> > +#include <linux/errno.h>
> >
> > #include "cm2xxx.h"
> > #include "cm3xxx.h"
> > --
> > 1.8.0
>
> Acked-by: Paul Walmsley <paul@pwsan.com>
>
> Thanks Peter.
>
> Tony, how would you like to handle this one?
I can queue it.
Regards,
Tony
^ permalink raw reply
* [PATCH] ARM: SPEAr3xx: Shirq: Move shirq controller out of plat/
From: Viresh Kumar @ 2012-11-12 17:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <71bbb1faf3cd048953dcf24ef9ce6d9dd37fe8e1.1352608333.git.viresh.kumar@linaro.org>
This patch moves shirq interrupt controllers driver and header file out of
plat-spear directory. It is moved to drivers/irqchip/ directory.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
Hi Arnd,
This is an follow-up patch of my earlier patchset:
http://www.spinics.net/lists/arm-kernel/msg206253.html
Please apply it after applying them.
arch/arm/mach-spear3xx/spear3xx.c | 2 +-
arch/arm/plat-spear/Makefile | 2 +-
drivers/irqchip/Makefile | 5 +++--
arch/arm/plat-spear/shirq.c => drivers/irqchip/spear-shirq.c | 9 +++++----
.../plat/shirq.h => include/linux/irqchip/spear-shirq.h | 10 ++++------
5 files changed, 14 insertions(+), 14 deletions(-)
rename arch/arm/plat-spear/shirq.c => drivers/irqchip/spear-shirq.c (97%)
rename arch/arm/plat-spear/include/plat/shirq.h => include/linux/irqchip/spear-shirq.h (90%)
diff --git a/arch/arm/mach-spear3xx/spear3xx.c b/arch/arm/mach-spear3xx/spear3xx.c
index f1aaf5b..38fe95d 100644
--- a/arch/arm/mach-spear3xx/spear3xx.c
+++ b/arch/arm/mach-spear3xx/spear3xx.c
@@ -15,12 +15,12 @@
#include <linux/amba/pl022.h>
#include <linux/amba/pl08x.h>
+#include <linux/irqchip/spear-shirq.h>
#include <linux/of_irq.h>
#include <linux/io.h>
#include <asm/hardware/pl080.h>
#include <asm/hardware/vic.h>
#include <plat/pl080.h>
-#include <plat/shirq.h>
#include <mach/generic.h>
#include <mach/spear.h>
diff --git a/arch/arm/plat-spear/Makefile b/arch/arm/plat-spear/Makefile
index 2607bd0..01e8853 100644
--- a/arch/arm/plat-spear/Makefile
+++ b/arch/arm/plat-spear/Makefile
@@ -5,5 +5,5 @@
# Common support
obj-y := restart.o time.o
-obj-$(CONFIG_ARCH_SPEAR3XX) += pl080.o shirq.o
+obj-$(CONFIG_ARCH_SPEAR3XX) += pl080.o
obj-$(CONFIG_ARCH_SPEAR6XX) += pl080.o
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index e2e6eb5..fee05b1 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -1,2 +1,3 @@
-obj-$(CONFIG_ARCH_BCM2835) += irq-bcm2835.o
-obj-$(CONFIG_VERSATILE_FPGA_IRQ) += irq-versatile-fpga.o
+obj-$(CONFIG_ARCH_BCM2835) += irq-bcm2835.o
+obj-$(CONFIG_ARCH_SPEAR3XX) += spear-shirq.o
+obj-$(CONFIG_VERSATILE_FPGA_IRQ) += irq-versatile-fpga.o
diff --git a/arch/arm/plat-spear/shirq.c b/drivers/irqchip/spear-shirq.c
similarity index 97%
rename from arch/arm/plat-spear/shirq.c
rename to drivers/irqchip/spear-shirq.c
index 955c724..80e1d2f 100644
--- a/arch/arm/plat-spear/shirq.c
+++ b/drivers/irqchip/spear-shirq.c
@@ -1,11 +1,12 @@
/*
- * arch/arm/plat-spear/shirq.c
- *
* SPEAr platform shared irq layer source file
*
- * Copyright (C) 2009 ST Microelectronics
+ * Copyright (C) 2009-2012 ST Microelectronics
* Viresh Kumar <viresh.linux@gmail.com>
*
+ * Copyright (C) 2012 ST Microelectronics
+ * Shiraz Hashim <shiraz.hashim@st.com>
+ *
* This file is licensed under the terms of the GNU General Public
* License version 2. This program is licensed "as is" without any
* warranty of any kind, whether express or implied.
@@ -18,11 +19,11 @@
#include <linux/io.h>
#include <linux/irq.h>
#include <linux/irqdomain.h>
+#include <linux/irqchip/spear-shirq.h>
#include <linux/of.h>
#include <linux/of_address.h>
#include <linux/of_irq.h>
#include <linux/spinlock.h>
-#include <plat/shirq.h>
static DEFINE_SPINLOCK(lock);
diff --git a/arch/arm/plat-spear/include/plat/shirq.h b/include/linux/irqchip/spear-shirq.h
similarity index 90%
rename from arch/arm/plat-spear/include/plat/shirq.h
rename to include/linux/irqchip/spear-shirq.h
index c51b355..c8be16d 100644
--- a/arch/arm/plat-spear/include/plat/shirq.h
+++ b/include/linux/irqchip/spear-shirq.h
@@ -1,9 +1,7 @@
/*
- * arch/arm/plat-spear/include/plat/shirq.h
- *
* SPEAr platform shared irq layer header file
*
- * Copyright (C) 2009 ST Microelectronics
+ * Copyright (C) 2009-2012 ST Microelectronics
* Viresh Kumar <viresh.linux@gmail.com>
*
* This file is licensed under the terms of the GNU General Public
@@ -11,8 +9,8 @@
* warranty of any kind, whether express or implied.
*/
-#ifndef __PLAT_SHIRQ_H
-#define __PLAT_SHIRQ_H
+#ifndef __SPEAR_SHIRQ_H
+#define __SPEAR_SHIRQ_H
#include <linux/irq.h>
#include <linux/types.h>
@@ -63,4 +61,4 @@ int __init spear310_shirq_of_init(struct device_node *np,
int __init spear320_shirq_of_init(struct device_node *np,
struct device_node *parent);
-#endif /* __PLAT_SHIRQ_H */
+#endif /* __SPEAR_SHIRQ_H */
--
1.7.12.rc2.18.g61b472e
^ permalink raw reply related
* [4/4] arm: mvebu: enable Ethernet controllers on Armada 370/XP eval boards
From: Thomas Petazzoni @ 2012-11-12 17:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121104020311.GA26747@obsidianresearch.com>
Jason,
On Sat, 3 Nov 2012 20:03:11 -0600, Jason Gunthorpe wrote:
> We've been using the patches from Ian Molton for the mv643xx driver
> that make it use the more standard, separately described MDIO
> bus..
>
> Please consider not copying the unsual 'phy-addr' binding
> for the new driver.
I have just sent a fifth version of the patch set that implements a
separate DT node for the PHY devices, as well as a separate MDIO bus.
Please let me know if it solves your comment.
Thanks!
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH v2 2/5] ARM: kernel: add device tree init map function
From: Dave Martin @ 2012-11-12 17:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352471654-20207-3-git-send-email-lorenzo.pieralisi@arm.com>
On Fri, Nov 09, 2012 at 02:34:11PM +0000, Lorenzo Pieralisi wrote:
> 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 and the DT defines a CPU node that 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 | 84 ++++++++++++++++++++++++++
> arch/arm/include/asm/prom.h | 2 +
> arch/arm/kernel/devtree.c | 76 +++++++++++++++++++++++
> 3 files changed, 162 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..83cd98a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/cpus.txt
> @@ -0,0 +1,84 @@
> +* 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
> +- compatible: must be set to "arm, <cpu-model>"
> + where <cpu-model> is the full processor name as used in the
> + processor Technical Reference Manual, eg:
> + - for a Cortex A9 processor
> + compatible = <arm, cortex-a9>;
> + - for a Cortex A15 processor
> + compatible = <arm, cortex-a15>;
> +
> +List of possible "compatible" string ids:
> +
> +<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, fa526>
> +<arm, feroceon>
> +<arm, mohawk>
> +<arm, sa110>
> +<arm, sa1100>
> +<arm, xsc3>
> +<arm, xscale>
> +<arm, cortex-a5>
> +<arm, cortex-a7>
> +<arm, cortex-a8>
> +<arm, cortex-a9>
> +<arm, cortex-a15>
> +<arm, arm1136>
> +<arm, arm11-mpcore>
> +
> +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 {
Should we document the unit address convention as part of the binding
documentation?
Using the MPIDR value here is a bit cumbersome, but I'm not sure if
there's a better alternative, unless we make a multi-element vector
out of the MPIDR to use as the address -- sounds like overkill.
> + 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..d64d222 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,80 @@ 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
> + */
Can this function sanity-check that we do not assign the same MPIDR
value for multiple logical CPUs?
It turns out to be surprisingly easy to write a DT with duplicate reg
properties in the CPUs node due to careless cut-and-paste. (i.e., I
did it, but have been getting away with it up to now).
> +void __init arm_dt_init_cpu_maps(void)
> +{
[...]
Cheers
---Dave
^ permalink raw reply
* [PATCH 1/7] I2c-nomadik: Fix the usage of wait_for_completion_timeout
From: Wolfram Sang @ 2012-11-12 17:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352222317.15558.1584.camel@cliu38-desktop-build>
On Wed, Nov 07, 2012 at 01:18:37AM +0800, Chuansheng Liu wrote:
>
> The return value of wait_for_completion_timeout() is always
> >= 0 with unsigned int type.
>
> So the condition "ret < 0" or "ret >= 0" is pointless.
>
> Signed-off-by: liu chuansheng <chuansheng.liu@intel.com>
You forgot to add the i2c-list, so I nearly overlooked this patch.
Luckily I haven't, so applied to for-next, thanks! Did you use a script
to find all occurences? Would be nice to know. Also, please take care of
the subject line. "I2c" is misspelled.
@Linus: I am not pushing out today, so if you want to add acks or so...
Thanks,
Wolfram
> ---
> drivers/i2c/busses/i2c-nomadik.c | 14 --------------
> 1 files changed, 0 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-nomadik.c b/drivers/i2c/busses/i2c-nomadik.c
> index 02c3115..8b2ffcf 100644
> --- a/drivers/i2c/busses/i2c-nomadik.c
> +++ b/drivers/i2c/busses/i2c-nomadik.c
> @@ -435,13 +435,6 @@ static int read_i2c(struct nmk_i2c_dev *dev, u16 flags)
> timeout = wait_for_completion_timeout(
> &dev->xfer_complete, dev->adap.timeout);
>
> - if (timeout < 0) {
> - dev_err(&dev->adev->dev,
> - "wait_for_completion_timeout "
> - "returned %d waiting for event\n", timeout);
> - status = timeout;
> - }
> -
> if (timeout == 0) {
> /* Controller timed out */
> dev_err(&dev->adev->dev, "read from slave 0x%x timed out\n",
> @@ -523,13 +516,6 @@ static int write_i2c(struct nmk_i2c_dev *dev, u16 flags)
> timeout = wait_for_completion_timeout(
> &dev->xfer_complete, dev->adap.timeout);
>
> - if (timeout < 0) {
> - dev_err(&dev->adev->dev,
> - "wait_for_completion_timeout "
> - "returned %d waiting for event\n", timeout);
> - status = timeout;
> - }
> -
> if (timeout == 0) {
> /* Controller timed out */
> dev_err(&dev->adev->dev, "write to slave 0x%x timed out\n",
> --
> 1.7.0.4
>
>
>
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121112/b7c7ac45/attachment.sig>
^ permalink raw reply
* [PATCH 8/9] ARM: support uprobe handling
From: Rabin Vincent @ 2012-11-12 17:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121104101327.GZ21164@n2100.arm.linux.org.uk>
2012/11/4 Russell King - ARM Linux <linux@arm.linux.org.uk>
> On Sun, Oct 14, 2012 at 09:23:12PM +0200, Rabin Vincent wrote:
> > Extend the kprobes code to handle user-space probes. Much of the code
> > can be reused so currently the ARM uprobes code reuses the kprobes
> > structures. The decode tables are reused, with the modification that
> > for those instruction that require custom decoding for uprobes, a new
> > element is added in the table to specify a custom decoder function.
>
> How are accesses to userspace handled by the kprobes code? Please point
> me to where these accesses are performed.
If you mean the accesses where we write the probe opcode, this is done
in write_opcode() in kernel/events/uprobes.c
If you instead mean the accesses which load/store instructions would
perform, this is done from userspace itself, by placing the modified
instruction in an executable area which is mapped to userspace, and
modifying the PC to point there. See xol_get_insn_slot() in
kernel/events/uprobes.c
^ permalink raw reply
* [PATCH 6/6] arm: mvebu: add LED support in defconfig
From: Thomas Petazzoni @ 2012-11-12 17:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352740839-13586-1-git-send-email-thomas.petazzoni@free-electrons.com>
The recently added support for the PlatHome Openblocks AX3 platform
requires the LED framework, so let's add it to mvebu_defconfig.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Tested-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
This is 3.8 material
---
arch/arm/configs/mvebu_defconfig | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/configs/mvebu_defconfig b/arch/arm/configs/mvebu_defconfig
index 3458752..b7ca617 100644
--- a/arch/arm/configs/mvebu_defconfig
+++ b/arch/arm/configs/mvebu_defconfig
@@ -26,6 +26,11 @@ CONFIG_SERIAL_OF_PLATFORM=y
CONFIG_GPIOLIB=y
CONFIG_GPIO_SYSFS=y
# CONFIG_USB_SUPPORT is not set
+CONFIG_NEW_LEDS=y
+CONFIG_LEDS_CLASS=y
+CONFIG_LEDS_GPIO=y
+CONFIG_LEDS_TRIGGERS=y
+CONFIG_LEDS_TRIGGER_HEARTBEAT=y
# CONFIG_IOMMU_SUPPORT is not set
CONFIG_EXT2_FS=y
CONFIG_EXT3_FS=y
--
1.7.9.5
^ permalink raw reply related
* [PATCH 5/6] arm: mvebu: support for the Globalscale Mirabox board
From: Thomas Petazzoni @ 2012-11-12 17:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352740839-13586-1-git-send-email-thomas.petazzoni@free-electrons.com>
From: Gregory CLEMENT <gregory.clement@free-electrons.com>
This platform, available from Globalscale has an Armada 370. For now,
only the serial port is supported. Support for network, USB and other
peripherals will be added as drivers for them become available for
Armada 370 in mainline.
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
This is 3.8 material.
Changes from original version posted by Gregory:
* Renamed .dts file to armada-370-mirabox.dts
* Change compatible string to 'globalscale,mirabox'
* Remove compatible string from armada-370-xp.c
* Removed references to MBX0001
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/armada-370-mirabox.dts | 37 ++++++++++++++++++++++++++++++
2 files changed, 38 insertions(+)
create mode 100644 arch/arm/boot/dts/armada-370-mirabox.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 718584d..32d1d40 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -44,6 +44,7 @@ dtb-$(CONFIG_ARCH_KIRKWOOD) += kirkwood-dns320.dtb \
dtb-$(CONFIG_ARCH_MSM) += msm8660-surf.dtb \
msm8960-cdp.dtb
dtb-$(CONFIG_ARCH_MVEBU) += armada-370-db.dtb \
+ armada-370-mirabox.dtb \
armada-xp-db.dtb \
armada-xp-openblocks-ax3-4.dtb
dtb-$(CONFIG_ARCH_MXC) += imx51-babbage.dtb \
diff --git a/arch/arm/boot/dts/armada-370-mirabox.dts b/arch/arm/boot/dts/armada-370-mirabox.dts
new file mode 100644
index 0000000..9eef8dd
--- /dev/null
+++ b/arch/arm/boot/dts/armada-370-mirabox.dts
@@ -0,0 +1,37 @@
+/*
+ * Device Tree file for Globalscale Mirabox
+ *
+ * Gregory CLEMENT <gregory.clement@free-electrons.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+/dts-v1/;
+/include/ "armada-370.dtsi"
+
+/ {
+ model = "Globalscale Mirabox";
+ compatible = "globalscale,mirabox", "marvell,armada370", "marvell,armada-370-xp";
+
+ chosen {
+ bootargs = "console=ttyS0,115200 earlyprintk";
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0x00000000 0x20000000>; /* 512 MB */
+ };
+
+ soc {
+ serial at d0012000 {
+ clock-frequency = <200000000>;
+ status = "okay";
+ };
+ timer at d0020300 {
+ clock-frequency = <600000000>;
+ status = "okay";
+ };
+ };
+};
--
1.7.9.5
^ permalink raw reply related
* [PATCH 4/6] arm: mvebu: support for the PlatHome OpenBlocks AX3-4 board
From: Thomas Petazzoni @ 2012-11-12 17:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352740839-13586-1-git-send-email-thomas.petazzoni@free-electrons.com>
This platform, available in Japan from PlatHome, has a dual-core
Armada XP, the MV78260. For now, only the two serial ports and the
three front LEDs are supported. Support for SMP, network, SATA, USB
and other peripherals will be added as drivers for them become
available for Armada XP in mainline.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Tested-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
This is 3.8 material.
Changes since v2:
* Renamed the .dts file to armada-xp-openblocks-ax3-4.dts
* Removed the compatible string from armada-370-xp.c (which now only
lists the common SoC compatible string)
Changes since v1:
* Renamed the board to OpenBlocks AX3-4, since there is a variant
called AX3-2 which has less RAM, and no mini PCIe port. Requested
by Andrew Lunn.
* Fix the amount of memory to 3 GB. In fact, the board has 1 GB
soldered, and 2 GB in a SODIMM slot (which is therefore
removable). But as the board is delivered as is, we'll assume it
has 3 GB of memory by default.
---
arch/arm/boot/dts/Makefile | 3 +-
arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts | 69 ++++++++++++++++++++++
2 files changed, 71 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index f37cf9f..718584d 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -44,7 +44,8 @@ dtb-$(CONFIG_ARCH_KIRKWOOD) += kirkwood-dns320.dtb \
dtb-$(CONFIG_ARCH_MSM) += msm8660-surf.dtb \
msm8960-cdp.dtb
dtb-$(CONFIG_ARCH_MVEBU) += armada-370-db.dtb \
- armada-xp-db.dtb
+ armada-xp-db.dtb \
+ armada-xp-openblocks-ax3-4.dtb
dtb-$(CONFIG_ARCH_MXC) += imx51-babbage.dtb \
imx53-ard.dtb \
imx53-evk.dtb \
diff --git a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
new file mode 100644
index 0000000..cb86853
--- /dev/null
+++ b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
@@ -0,0 +1,69 @@
+/*
+ * Device Tree file for OpenBlocks AX3-4 board
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+/dts-v1/;
+/include/ "armada-xp-mv78260.dtsi"
+
+/ {
+ model = "PlatHome OpenBlocks AX3-4 board";
+ compatible = "plathome,openblocks-ax3-4", "marvell,armadaxp-mv78260", "marvell,armadaxp", "marvell,armada-370-xp";
+
+ chosen {
+ bootargs = "console=ttyS0,115200 earlyprintk";
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0x00000000 0xC0000000>; /* 3 GB */
+ };
+
+ soc {
+ serial at d0012000 {
+ clock-frequency = <250000000>;
+ status = "okay";
+ };
+ serial at d0012100 {
+ clock-frequency = <250000000>;
+ status = "okay";
+ };
+ pinctrl {
+ led_pins: led-pins-0 {
+ marvell,pins = "mpp49", "mpp51", "mpp53";
+ marvell,function = "gpio";
+ };
+ };
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&led_pins>;
+
+ red_led {
+ label = "red_led";
+ gpios = <&gpio1 17 1>;
+ default-state = "off";
+ };
+
+ yellow_led {
+ label = "yellow_led";
+ gpios = <&gpio1 19 1>;
+ default-state = "off";
+ };
+
+ green_led {
+ label = "green_led";
+ gpios = <&gpio1 21 1>;
+ default-state = "off";
+ linux,default-trigger = "heartbeat";
+ };
+ };
+ };
+};
--
1.7.9.5
^ permalink raw reply related
* [PATCH 3/6] arm: mvebu: fix typo in machine name for Armada 370/XP
From: Thomas Petazzoni @ 2012-11-12 17:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352740839-13586-1-git-send-email-thomas.petazzoni@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Tested-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
arch/arm/mach-mvebu/armada-370-xp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-mvebu/armada-370-xp.c b/arch/arm/mach-mvebu/armada-370-xp.c
index 29c27cd..a2f5bbc 100644
--- a/arch/arm/mach-mvebu/armada-370-xp.c
+++ b/arch/arm/mach-mvebu/armada-370-xp.c
@@ -51,7 +51,7 @@ static const char * const armada_370_xp_dt_compat[] = {
NULL,
};
-DT_MACHINE_START(ARMADA_XP_DT, "Marvell Aramada 370/XP (Device Tree)")
+DT_MACHINE_START(ARMADA_XP_DT, "Marvell Armada 370/XP (Device Tree)")
.init_machine = armada_370_xp_dt_init,
.map_io = armada_370_xp_map_io,
.init_irq = armada_370_xp_init_irq,
--
1.7.9.5
^ permalink raw reply related
* [PATCH 2/6] arm: mvebu: don't list all boards in dt compat field for Armada 370/XP
From: Thomas Petazzoni @ 2012-11-12 17:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352740839-13586-1-git-send-email-thomas.petazzoni@free-electrons.com>
Instead of listing explicitly all boards in the .dt_compat field of
the DT_MACHINE_START structure for Armada 370/XP, use instead a
compatible string that is common to all boards using the Armada
370/XP.
This allows to add new boards by just using a different Device Tree,
without having to modify the source code of the kernel.
Note that the name of the array containing the compatible string is
also renamed, to reflect the fact that it no longer contains the list
of all boards.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Tested-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
This might be considered 3.7 material if not late. Otherwise, there's
no big deal if it goes into 3.8.
---
arch/arm/mach-mvebu/armada-370-xp.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-mvebu/armada-370-xp.c b/arch/arm/mach-mvebu/armada-370-xp.c
index 49d7915..29c27cd 100644
--- a/arch/arm/mach-mvebu/armada-370-xp.c
+++ b/arch/arm/mach-mvebu/armada-370-xp.c
@@ -46,9 +46,8 @@ static void __init armada_370_xp_dt_init(void)
of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
}
-static const char * const armada_370_xp_dt_board_dt_compat[] = {
- "marvell,a370-db",
- "marvell,axp-db",
+static const char * const armada_370_xp_dt_compat[] = {
+ "marvell,armada-370-xp",
NULL,
};
@@ -59,5 +58,5 @@ DT_MACHINE_START(ARMADA_XP_DT, "Marvell Aramada 370/XP (Device Tree)")
.handle_irq = armada_370_xp_handle_irq,
.timer = &armada_370_xp_timer,
.restart = mvebu_restart,
- .dt_compat = armada_370_xp_dt_board_dt_compat,
+ .dt_compat = armada_370_xp_dt_compat,
MACHINE_END
--
1.7.9.5
^ permalink raw reply related
* [PATCH 1/6] arm: mvebu: fix compatible string in armada-370-xp.dtsi
From: Thomas Petazzoni @ 2012-11-12 17:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352740839-13586-1-git-send-email-thomas.petazzoni@free-electrons.com>
All the Device Tree files for Armada 370 and XP SoCs and boards use
the "armada-370-xp" common compatible string, except
armada-370-xp.dtsi which was specifying "armada_370_xp".
Fix this inconsistency by making armada-370-xp.dtsi declare a
compatible string of "armada-370-xp" like everyone else.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Tested-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
This might be considered 3.7 material if not late. Otherwise, there's
no big deal if it goes into 3.8.
---
arch/arm/boot/dts/armada-370-xp.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi b/arch/arm/boot/dts/armada-370-xp.dtsi
index 16cc82c..b113e0b 100644
--- a/arch/arm/boot/dts/armada-370-xp.dtsi
+++ b/arch/arm/boot/dts/armada-370-xp.dtsi
@@ -20,7 +20,7 @@
/ {
model = "Marvell Armada 370 and XP SoC";
- compatible = "marvell,armada_370_xp";
+ compatible = "marvell,armada-370-xp";
cpus {
cpu at 0 {
--
1.7.9.5
^ permalink raw reply related
* arm: mvebu: Pull request for 'marvell-boards' branch
From: Thomas Petazzoni @ 2012-11-12 17:20 UTC (permalink / raw)
To: linux-arm-kernel
Jason, Andrew,
The following changes since commit 77b67063bb6bce6d475e910d3b886a606d0d91f7:
Linux 3.7-rc5 (2012-11-11 13:44:33 +0100)
are available in the git repository at:
git at github.com:MISL-EBU-System-SW/mainline-public.git marvell-boards
for you to fetch changes up to 39325a96e1d082bf71b7a4d9ac2d5806f80c6d13:
arm: mvebu: add LED support in defconfig (2012-11-12 18:13:41 +0100)
----------------------------------------------------------------
Gregory CLEMENT (1):
arm: mvebu: support for the Globalscale Mirabox board
Thomas Petazzoni (5):
arm: mvebu: fix compatible string in armada-370-xp.dtsi
arm: mvebu: don't list all boards in dt compat field for Armada 370/XP
arm: mvebu: fix typo in machine name for Armada 370/XP
arm: mvebu: support for the PlatHome OpenBlocks AX3-4 board
arm: mvebu: add LED support in defconfig
arch/arm/boot/dts/Makefile | 4 +-
arch/arm/boot/dts/armada-370-mirabox.dts | 37 ++++++++++++
arch/arm/boot/dts/armada-370-xp.dtsi | 2 +-
arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts | 69 ++++++++++++++++++++++
arch/arm/configs/mvebu_defconfig | 5 ++
arch/arm/mach-mvebu/armada-370-xp.c | 9 ++-
6 files changed, 119 insertions(+), 7 deletions(-)
create mode 100644 arch/arm/boot/dts/armada-370-mirabox.dts
create mode 100644 arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
^ permalink raw reply
* [PATCH 00/14] ARM: SPEAr: DT updates
From: Viresh Kumar @ 2012-11-12 17:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201211121521.58766.arnd@arndb.de>
On 12 November 2012 20:51, Arnd Bergmann <arnd@arndb.de> wrote:
> On Sunday 11 November 2012, Viresh Kumar wrote:
> I tried pulling in patches 2 to 11, but it no longer builds because of the
> dependency you mentioned. Can you be more specific which branch I need
> to pull in?
pinctrl/for-next
^ permalink raw reply
* [PATCH] fixup! ARM: SPEAr3xx: shirq: simplify and move the shared irq multiplexor to DT
From: Viresh Kumar @ 2012-11-12 17:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <71bbb1faf3cd048953dcf24ef9ce6d9dd37fe8e1.1352608333.git.viresh.kumar@linaro.org>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
Hi Arnd,
This is the fixup of the major issues you pointed out. Please go ahead
and apply this series. I will then move all this out of plat.
arch/arm/mach-spear3xx/spear3xx.c | 6 +--
arch/arm/plat-spear/include/plat/shirq.h | 6 ++-
arch/arm/plat-spear/shirq.c | 70 ++++++++++++++------------------
3 files changed, 39 insertions(+), 43 deletions(-)
diff --git a/arch/arm/mach-spear3xx/spear3xx.c b/arch/arm/mach-spear3xx/spear3xx.c
index 781aec9..f1aaf5b 100644
--- a/arch/arm/mach-spear3xx/spear3xx.c
+++ b/arch/arm/mach-spear3xx/spear3xx.c
@@ -122,9 +122,9 @@ struct sys_timer spear3xx_timer = {
static const struct of_device_id vic_of_match[] __initconst = {
{ .compatible = "arm,pl190-vic", .data = vic_of_init, },
- { .compatible = "st,spear300-shirq", .data = spear3xx_shirq_of_init, },
- { .compatible = "st,spear310-shirq", .data = spear3xx_shirq_of_init, },
- { .compatible = "st,spear320-shirq", .data = spear3xx_shirq_of_init, },
+ { .compatible = "st,spear300-shirq", .data = spear300_shirq_of_init, },
+ { .compatible = "st,spear310-shirq", .data = spear310_shirq_of_init, },
+ { .compatible = "st,spear320-shirq", .data = spear320_shirq_of_init, },
{ /* Sentinel */ }
};
diff --git a/arch/arm/plat-spear/include/plat/shirq.h b/arch/arm/plat-spear/include/plat/shirq.h
index 1215afe..c51b355 100644
--- a/arch/arm/plat-spear/include/plat/shirq.h
+++ b/arch/arm/plat-spear/include/plat/shirq.h
@@ -56,7 +56,11 @@ struct spear_shirq {
struct shirq_regs regs;
};
-int __init spear3xx_shirq_of_init(struct device_node *np,
+int __init spear300_shirq_of_init(struct device_node *np,
+ struct device_node *parent);
+int __init spear310_shirq_of_init(struct device_node *np,
+ struct device_node *parent);
+int __init spear320_shirq_of_init(struct device_node *np,
struct device_node *parent);
#endif /* __PLAT_SHIRQ_H */
diff --git a/arch/arm/plat-spear/shirq.c b/arch/arm/plat-spear/shirq.c
index 3912646..955c724 100644
--- a/arch/arm/plat-spear/shirq.c
+++ b/arch/arm/plat-spear/shirq.c
@@ -246,10 +246,17 @@ static void __init spear_shirq_register(struct spear_shirq *shirq)
}
static int __init shirq_init(struct spear_shirq **shirq_blocks, int block_nr,
- void __iomem *base, struct device_node *np)
+ struct device_node *np)
{
int i, irq_base, hwirq = 0, irq_nr = 0;
static struct irq_domain *shirq_domain;
+ void __iomem *base;
+
+ base = of_iomap(np, 0);
+ if (!base) {
+ pr_err("%s: failed to map shirq registers\n", __func__);
+ return -ENXIO;
+ }
for (i = 0; i < block_nr; i++)
irq_nr += shirq_blocks[i]->irq_nr;
@@ -257,15 +264,14 @@ static int __init shirq_init(struct spear_shirq **shirq_blocks, int block_nr,
irq_base = irq_alloc_descs(-1, 0, irq_nr, 0);
if (IS_ERR_VALUE(irq_base)) {
pr_err("%s: irq desc alloc failed\n", __func__);
- return -ENXIO;
+ goto err_unmap;
}
shirq_domain = irq_domain_add_legacy(np, irq_nr, irq_base, 0,
&irq_domain_simple_ops, NULL);
if (WARN_ON(!shirq_domain)) {
pr_warn("%s: irq domain init failed\n", __func__);
- irq_free_descs(irq_base, irq_nr);
- return -ENXIO;
+ goto err_free_desc;
}
for (i = 0; i < block_nr; i++) {
@@ -279,45 +285,31 @@ static int __init shirq_init(struct spear_shirq **shirq_blocks, int block_nr,
}
return 0;
+
+err_free_desc:
+ irq_free_descs(irq_base, irq_nr);
+err_unmap:
+ iounmap(base);
+ return -ENXIO;
}
-int __init spear3xx_shirq_of_init(struct device_node *np,
+int __init spear300_shirq_of_init(struct device_node *np,
struct device_node *parent)
{
- struct spear_shirq **shirq_blocks;
- void __iomem *base;
- int block_nr, ret;
-
- base = of_iomap(np, 0);
- if (!base) {
- pr_err("%s: failed to map shirq registers\n", __func__);
- return -ENXIO;
- }
-
- if (of_device_is_compatible(np, "st,spear300-shirq")) {
- shirq_blocks = spear300_shirq_blocks;
- block_nr = ARRAY_SIZE(spear300_shirq_blocks);
- } else if (of_device_is_compatible(np, "st,spear310-shirq")) {
- shirq_blocks = spear310_shirq_blocks;
- block_nr = ARRAY_SIZE(spear310_shirq_blocks);
- } else if (of_device_is_compatible(np, "st,spear320-shirq")) {
- shirq_blocks = spear320_shirq_blocks;
- block_nr = ARRAY_SIZE(spear320_shirq_blocks);
- } else {
- pr_err("%s: unknown platform\n", __func__);
- ret = -EINVAL;
- goto unmap;
- }
-
- ret = shirq_init(shirq_blocks, block_nr, base, np);
- if (ret) {
- pr_err("%s: shirq initialization failed\n", __func__);
- goto unmap;
- }
+ return shirq_init(spear300_shirq_blocks,
+ ARRAY_SIZE(spear300_shirq_blocks), np);
+}
- return ret;
+int __init spear310_shirq_of_init(struct device_node *np,
+ struct device_node *parent)
+{
+ return shirq_init(spear310_shirq_blocks,
+ ARRAY_SIZE(spear310_shirq_blocks), np);
+}
-unmap:
- iounmap(base);
- return ret;
+int __init spear320_shirq_of_init(struct device_node *np,
+ struct device_node *parent)
+{
+ return shirq_init(spear320_shirq_blocks,
+ ARRAY_SIZE(spear320_shirq_blocks), np);
}
--
1.7.12.rc2.18.g61b472e
^ permalink raw reply related
* [PATCH v2] Add support for generic BCM SoC chipsets
From: Stephen Warren @ 2012-11-12 17:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201211121705.29191.arnd@arndb.de>
On 11/12/2012 10:05 AM, Arnd Bergmann wrote:
> On Monday 12 November 2012, Domenico Andreoli wrote:
>> On Mon, Nov 12, 2012 at 03:00:57PM +0000, Arnd Bergmann wrote:
>>> On Sunday 11 November 2012, Stephen Warren wrote:
>>>>> I'm following the other mobile ARM SoCs which all have a single mach-
>>>>> directory for various families of chips (mach-tegra, mach-omap2,
>>>>> etc...). Plus the intent is to have a single set of mach files that
>>>>> works across bcm SoCs, so it is preferable to keep it in a single mach-bcm.
>>>>
>>>> It's quite possible to create one directory now, e.g. mach-bcm281xx, and
>>>> then when consolidation with other mach-bcm* happens, merge all those
>>>> directories into a single mach-bcm. I would tend to prefer (but only
>>>> lightly) using mach-bcm281xx now and then renaming later, unless you
>>>> plan on expanding the SoC support in the pretty near future.
>>>
>>> I think the main question is how many files we expect to see in the
>>> platform directories for each of bcm3528, bcm281xx and bcm476x. Right
>>> now, my feeling is that each of them can be a single file, since most
>>> of the stuff that has traditionally been in mach-* directories is
>>> moving out to drivers now.
>>
>> I expect only DT-only stuff will be mainlined so one directory
>> (plat-brcm?) should be ok, right?
>
> Right. The usual naming is to use 'mach-*' for one platform, and 'plat-*'
> for stuff that spreads multiple 'mach-*' directories. In this case, the
> name I would expect is either 'mach-bcm' as Christian suggested, or
> 'mach-brcm' if people have strong opinions in favor of that, but not
> 'plat-brcm'.
>
>>> You still have to work out how you want to maintain that directory though,
>>> either just having per-file maintainers, or having multiple people
>>> take responsible for the entire directory.
>>
>> I'd like to take care of the bcm476x and related drivers unless Broadcom
>> wants to do it.
>
> Yes, of course.
>
>> Let me know in which directory.
>
> I'll let you work that out with Stephen and Christian. I think just
> 'mach-bcm' is sufficent, but I think the three of you should come to
> an agreement first.
I don't really have too strong of a preference. If the eventual intent
is for the directory to host all ARM Broadcom SoCs, then mach-bcm seems
reasonable.
^ permalink raw reply
* [PATCH 7/7] arm: mvebu: enable Ethernet controllers on Mirabox platform
From: Thomas Petazzoni @ 2012-11-12 17:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352740030-12801-1-git-send-email-thomas.petazzoni@free-electrons.com>
The Globalscale Mirabox platform has two Ethernet interfaces,
connected to the SoC with a RGMII interface.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
arch/arm/boot/dts/armada-370-mirabox.dts | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
diff --git a/arch/arm/boot/dts/armada-370-mirabox.dts b/arch/arm/boot/dts/armada-370-mirabox.dts
index 9eef8dd..8554dbe 100644
--- a/arch/arm/boot/dts/armada-370-mirabox.dts
+++ b/arch/arm/boot/dts/armada-370-mirabox.dts
@@ -33,5 +33,26 @@
clock-frequency = <600000000>;
status = "okay";
};
+ mdio {
+ phy0: ethernet-phy at 0 {
+ reg = <0>;
+ };
+
+ phy1: ethernet-phy at 1 {
+ reg = <1>;
+ };
+ };
+ ethernet at d0070000 {
+ clock-frequency = <200000000>;
+ status = "okay";
+ phy = <&phy0>;
+ phy-mode = "rgmii-id";
+ };
+ ethernet at d0074000 {
+ clock-frequency = <200000000>;
+ status = "okay";
+ phy = <&phy1>;
+ phy-mode = "rgmii-id";
+ };
};
};
--
1.7.9.5
^ permalink raw reply related
* [PATCH 6/7] arm: mvebu: enable Ethernet controllers on OpenBlocks AX3-4 platform
From: Thomas Petazzoni @ 2012-11-12 17:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352740030-12801-1-git-send-email-thomas.petazzoni@free-electrons.com>
The PlatHome OpenBlocks AX3-4 platform has 4 Ethernet ports, connected
to a single quad-port PHY through SGMII.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts | 43 ++++++++++++++++++++++
1 file changed, 43 insertions(+)
diff --git a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
index cb86853..bb8d83c 100644
--- a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
+++ b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
@@ -65,5 +65,48 @@
linux,default-trigger = "heartbeat";
};
};
+
+ mdio {
+ phy0: ethernet-phy at 0 {
+ reg = <0>;
+ };
+
+ phy1: ethernet-phy at 1 {
+ reg = <1>;
+ };
+
+ phy2: ethernet-phy at 2 {
+ reg = <2>;
+ };
+
+ phy3: ethernet-phy at 3 {
+ reg = <3>;
+ };
+ };
+
+ ethernet at d0070000 {
+ clock-frequency = <250000000>;
+ status = "okay";
+ phy = <&phy0>;
+ phy-mode = "sgmii";
+ };
+ ethernet at d0074000 {
+ clock-frequency = <250000000>;
+ status = "okay";
+ phy = <&phy1>;
+ phy-mode = "sgmii";
+ };
+ ethernet at d0030000 {
+ clock-frequency = <250000000>;
+ status = "okay";
+ phy = <&phy2>;
+ phy-mode = "sgmii";
+ };
+ ethernet at d0034000 {
+ clock-frequency = <250000000>;
+ status = "okay";
+ phy = <&phy3>;
+ phy-mode = "sgmii";
+ };
};
};
--
1.7.9.5
^ permalink raw reply related
* [PATCH 5/7] arm: mvebu: enable Ethernet controllers on Armada 370/XP eval boards
From: Thomas Petazzoni @ 2012-11-12 17:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352740030-12801-1-git-send-email-thomas.petazzoni@free-electrons.com>
This patch enables the two network interfaces of the Armada 370
official Marvell evaluation platform, and the four network interfaces
of the Armada XP official Marvell evaluation platform.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
arch/arm/boot/dts/armada-370-db.dts | 23 +++++++++++++++++++
arch/arm/boot/dts/armada-xp-db.dts | 43 +++++++++++++++++++++++++++++++++++
2 files changed, 66 insertions(+)
diff --git a/arch/arm/boot/dts/armada-370-db.dts b/arch/arm/boot/dts/armada-370-db.dts
index fffd5c2..76362f7 100644
--- a/arch/arm/boot/dts/armada-370-db.dts
+++ b/arch/arm/boot/dts/armada-370-db.dts
@@ -38,5 +38,28 @@
clock-frequency = <600000000>;
status = "okay";
};
+
+ mdio {
+ phy0: ethernet-phy at 0 {
+ reg = <0>;
+ };
+
+ phy1: ethernet-phy at 1 {
+ reg = <1>;
+ };
+ };
+
+ ethernet at d0070000 {
+ clock-frequency = <200000000>;
+ status = "okay";
+ phy = <&phy0>;
+ phy-mode = "rgmii-id";
+ };
+ ethernet at d0074000 {
+ clock-frequency = <200000000>;
+ status = "okay";
+ phy = <&phy1>;
+ phy-mode = "rgmii-id";
+ };
};
};
diff --git a/arch/arm/boot/dts/armada-xp-db.dts b/arch/arm/boot/dts/armada-xp-db.dts
index b1fc728..b614bd0 100644
--- a/arch/arm/boot/dts/armada-xp-db.dts
+++ b/arch/arm/boot/dts/armada-xp-db.dts
@@ -46,5 +46,48 @@
clock-frequency = <250000000>;
status = "okay";
};
+
+ mdio {
+ phy0: ethernet-phy at 0 {
+ reg = <0>;
+ };
+
+ phy1: ethernet-phy at 1 {
+ reg = <1>;
+ };
+
+ phy2: ethernet-phy at 2 {
+ reg = <25>;
+ };
+
+ phy3: ethernet-phy at 3 {
+ reg = <27>;
+ };
+ };
+
+ ethernet at d0070000 {
+ clock-frequency = <250000000>;
+ status = "okay";
+ phy = <&phy0>;
+ phy-mode = "rgmii-id";
+ };
+ ethernet at d0074000 {
+ clock-frequency = <250000000>;
+ status = "okay";
+ phy = <&phy1>;
+ phy-mode = "rgmii-id";
+ };
+ ethernet at d0030000 {
+ clock-frequency = <250000000>;
+ status = "okay";
+ phy = <&phy2>;
+ phy-mode = "sgmii";
+ };
+ ethernet at d0034000 {
+ clock-frequency = <250000000>;
+ status = "okay";
+ phy = <&phy3>;
+ phy-mode = "sgmii";
+ };
};
};
--
1.7.9.5
^ permalink raw reply related
* [PATCH 4/7] arm: mvebu: add Ethernet controllers using mvneta driver for Armada 370/XP
From: Thomas Petazzoni @ 2012-11-12 17:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352740030-12801-1-git-send-email-thomas.petazzoni@free-electrons.com>
The Armada 370 SoC has two network units, while the Armada XP has four
network units. The first two network units are common to both the
Armada XP and Armada 370, so they are added to armada-370-xp.dtsi,
while the other two network units are specific to the Armada XP and
therefore added to armada-xp.dtsi.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
arch/arm/boot/dts/armada-370-xp.dtsi | 21 +++++++++++++++++++++
arch/arm/boot/dts/armada-xp.dtsi | 14 ++++++++++++++
2 files changed, 35 insertions(+)
diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi b/arch/arm/boot/dts/armada-370-xp.dtsi
index b113e0b..0cd3331 100644
--- a/arch/arm/boot/dts/armada-370-xp.dtsi
+++ b/arch/arm/boot/dts/armada-370-xp.dtsi
@@ -68,6 +68,27 @@
compatible = "marvell,armada-addr-decoding-controller";
reg = <0xd0020000 0x258>;
};
+
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "marvell,orion-mdio";
+ reg = <0xd0072004 0x4>;
+ };
+
+ ethernet at d0070000 {
+ compatible = "marvell,armada-370-neta";
+ reg = <0xd0070000 0x2500>;
+ interrupts = <8>;
+ status = "disabled";
+ };
+
+ ethernet at d0074000 {
+ compatible = "marvell,armada-370-neta";
+ reg = <0xd0074000 0x2500>;
+ interrupts = <10>;
+ status = "disabled";
+ };
};
};
diff --git a/arch/arm/boot/dts/armada-xp.dtsi b/arch/arm/boot/dts/armada-xp.dtsi
index 71d6b5d..3bbbccf 100644
--- a/arch/arm/boot/dts/armada-xp.dtsi
+++ b/arch/arm/boot/dts/armada-xp.dtsi
@@ -51,5 +51,19 @@
compatible = "marvell,armada-370-xp-system-controller";
reg = <0xd0018200 0x500>;
};
+
+ ethernet at d0030000 {
+ compatible = "marvell,armada-370-neta";
+ reg = <0xd0030000 0x2500>;
+ interrupts = <12>;
+ status = "disabled";
+ };
+
+ ethernet at d0034000 {
+ compatible = "marvell,armada-370-neta";
+ reg = <0xd0034000 0x2500>;
+ interrupts = <14>;
+ status = "disabled";
+ };
};
};
--
1.7.9.5
^ 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