Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH v2 1/4] irqchip: add basic infrastructure
From: Rob Herring @ 2012-10-28 13:30 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20121028142408.7512671c@skate>

On 10/28/2012 08:24 AM, Thomas Petazzoni wrote:
> Rob,
> 
> On Sun, 28 Oct 2012 08:18:42 -0500, Rob Herring wrote:
> 
>>> diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
>>> index 1bb8bf6..e0ff166 100644
>>> --- a/drivers/irqchip/Kconfig
>>> +++ b/drivers/irqchip/Kconfig
>>> @@ -1 +1,2 @@
>>> -# empty
>>> +config USE_IRQCHIP
>>> +	bool
>>
>> This should depend on OF_IRQ.
> 
> It is correct that the mechanism only works for irqchip drivers that
> are probed through the Device Tree. However, having a "depends on"
> inside a configuration that gets "select"ed by other configuration
> options (in our case ARCH_BCM2835 and ARCH_MVEBU select USE_IRQCHIP) is
> useless: kconfig doesn't care of the "depends on" dependencies when
> you're "select"ing an option.
> 
> So, I can add it for documentation purposes, but it is practically
> useless.

It will give a kconfig error rather than build error on of_irq_init
which would result in patches for empty of_irq_init.

How about default y and depends on OF_IRQ. Then you don't need a select.
I think we want all DT enabled platforms to use this and it's only a
small amount of init space.

Rob

> 
> Best regards,
> 
> Thomas
> 

^ permalink raw reply

* [PATCH v2] Introduce minimal irqchip infrastructure
From: Thomas Petazzoni @ 2012-10-28 13:26 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <508D31EA.3050307@gmail.com>


On Sun, 28 Oct 2012 08:23:54 -0500, Rob Herring wrote:

> Other than the 2 minor things I mentioned, this series looks good.
> 
> Reviewed-by: Rob Herring <rob.herring@calxeda.com>

Thanks, I'll repost a v3 once you confirm the part about "depends on
OF_IRQ".

> Also, I have some follow-on patches to move the GIC and VIC to
> drivers/irqchip. It was much more simple than I expected. I'll post them
> later.

Ah good. Aren't they some remaining non-DT users of the GIC and VIC
drivers?

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 1/4] irqchip: add basic infrastructure
From: Thomas Petazzoni @ 2012-10-28 13:24 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <508D30B2.6070806@gmail.com>

Rob,

On Sun, 28 Oct 2012 08:18:42 -0500, Rob Herring wrote:

> > diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
> > index 1bb8bf6..e0ff166 100644
> > --- a/drivers/irqchip/Kconfig
> > +++ b/drivers/irqchip/Kconfig
> > @@ -1 +1,2 @@
> > -# empty
> > +config USE_IRQCHIP
> > +	bool
> 
> This should depend on OF_IRQ.

It is correct that the mechanism only works for irqchip drivers that
are probed through the Device Tree. However, having a "depends on"
inside a configuration that gets "select"ed by other configuration
options (in our case ARCH_BCM2835 and ARCH_MVEBU select USE_IRQCHIP) is
useless: kconfig doesn't care of the "depends on" dependencies when
you're "select"ing an option.

So, I can add it for documentation purposes, but it is practically
useless.

Best regards,

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] Introduce minimal irqchip infrastructure
From: Rob Herring @ 2012-10-28 13:23 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1351416634-3352-1-git-send-email-thomas.petazzoni@free-electrons.com>

On 10/28/2012 04:30 AM, Thomas Petazzoni wrote:
> Thomas, Rob, Arnd,
> 
> Here is a small set of patches that introduces a small irqchip
> infrastructure that allows the registration of irqchip drivers without
> having each of those drivers to expose a public API in
> include/linux/irqchip/ (patch 1/4), moves the only existing irqchip
> driver, irq-bcm2835 to this infrastructure (patch 2/4), moves the
> irqchip driver for the Armada 370 / Armada XP SoCs to the
> drivers/irqchip directory (patch 3/4) and finally adds the
> drivers/irqchip directory to the IRQ subsystem entry in the
> MAINTAINERS file (patch 4/4).
> 
> Changes since v1:
> 
>  * Add a new patch mentionning the drivers/irqchip in the list of
>    directories part of the IRQ subsystem maintained by Thomas Gleixner
>    in the MAINTAINERS file. Requested by Arnd Bergmann.
> 
>  * Reduce the amount of code movement in the irq-bcm2835.c and
>    irq-armada-370-xp.c files by using one forward declaration for the
>    IRQ handling entry point. Requested by Stephen Warren.
> 
>  * Rename the armctrl_of_init() function to bcm2835_irqchip_init() as
>    requested by Stephen Warren.
> 
>  * Added the formal Acked-by and Reviewed-by received from Stephen
>    Warren.

Other than the 2 minor things I mentioned, this series looks good.

Reviewed-by: Rob Herring <rob.herring@calxeda.com>

Also, I have some follow-on patches to move the GIC and VIC to
drivers/irqchip. It was much more simple than I expected. I'll post them
later.

Rob

^ permalink raw reply

* [PATCH v2 1/4] irqchip: add basic infrastructure
From: Rob Herring @ 2012-10-28 13:18 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1351416634-3352-2-git-send-email-thomas.petazzoni@free-electrons.com>

On 10/28/2012 04:30 AM, Thomas Petazzoni wrote:
> With the recent creation of the drivers/irqchip/ directory, it is
> desirable to move irq controller drivers here. At the moment, the only
> driver here is irq-bcm2835, the driver for the irq controller found in
> the ARM BCM2835 SoC, present in Rasberry Pi systems. This irq
> controller driver was exporting its initialization function and its
> irq handling function through a header file in
> <linux/irqchip/bcm2835.h>.
> 
> When proposing to also move another irq controller driver in
> drivers/irqchip, Rob Herring raised the very valid point that moving
> things to drivers/irqchip was good in order to remove more stuff from
> arch/arm, but if it means adding gazillions of headers files in
> include/linux/irqchip/, it would not be very nice.
> 
> So, upon the suggestion of Rob Herring and Arnd Bergmann, this commit
> introduces a small infrastructure that defines a central
> irqchip_init() function in drivers/irqchip/irqchip.c, which is meant
> to be called as the ->init_irq() callback of ARM platforms. This
> function calls of_irq_init() with an array that will progressively
> contain the compatible strings of each irq controller driver, and also
> a reference to the initialization functions of such drivers. The
> drivers/irqchip/irqchip.h header file, currently empty, is added to
> allow irq controller drivers to expose their initialization function
> to the main irqchip.c file. Note that the irq controller driver
> initialization function is responsible for setting the global
> handle_arch_irq() variable, so that ARM platforms no longer have to
> define the ->handle_irq field in their DT_MACHINE structure.
> 
> A global header, <linux/irqchip.h> is also added to expose the single
> irqchip_init() function to the reset of the kernel.
> 
> A further commit moves the BCM2835 irq controller driver to this new
> small infrastructure, therefore removing the include/linux/irqchip/
> directory.
> 
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> Reviewed-by: Stephen Warren <swarren@wwwdotorg.org>
> ---
>  drivers/irqchip/Kconfig   |    3 ++-
>  drivers/irqchip/Makefile  |    1 +
>  drivers/irqchip/irqchip.c |   23 +++++++++++++++++++++++
>  drivers/irqchip/irqchip.h |   14 ++++++++++++++
>  include/linux/irqchip.h   |   16 ++++++++++++++++
>  5 files changed, 56 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/irqchip/irqchip.c
>  create mode 100644 drivers/irqchip/irqchip.h
>  create mode 100644 include/linux/irqchip.h
> 
> diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
> index 1bb8bf6..e0ff166 100644
> --- a/drivers/irqchip/Kconfig
> +++ b/drivers/irqchip/Kconfig
> @@ -1 +1,2 @@
> -# empty
> +config USE_IRQCHIP
> +	bool

This should depend on OF_IRQ.

Rob

^ permalink raw reply

* [PATCH v2 4/4] irqchip: add to the directories part of the IRQ subsystem in MAINTAINERS
From: Rob Herring @ 2012-10-28 13:11 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1351416634-3352-5-git-send-email-thomas.petazzoni@free-electrons.com>

On 10/28/2012 04:30 AM, Thomas Petazzoni wrote:
> Now that the drivers/irqchip/ directory is getting more code, it needs
> a maintainer. The obvious maintainer for it is Thomas Gleixner, who is
> maintaining the overall IRQ subsystem. So we add drivers/irqchip/ in
> the list of directories that are part of the IRQ subsystem.
> 
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> ---
>  MAINTAINERS |    1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 027ec2b..c057bfc 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -4034,6 +4034,7 @@ M:	Thomas Gleixner <tglx@linutronix.de>
>  S:	Maintained
>  T:	git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git irq/core
>  F:	kernel/irq/
> +F:	drivers/irchip/

s/irchip/irqchip/

>  
>  IRQ DOMAINS (IRQ NUMBER MAPPING LIBRARY)
>  M:	Benjamin Herrenschmidt <benh@kernel.crashing.org>
> 

^ permalink raw reply

* [PATCH] arm: bcm2835: enable proc and sysfs in defconfig
From: Thomas Petazzoni @ 2012-10-28 12:28 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <508D1A65.20506@mvista.com>

Dear Sergei Shtylyov,

On Sun, 28 Oct 2012 15:43:33 +0400, Sergei Shtylyov wrote:

> > diff --git a/arch/arm/configs/bcm2835_defconfig b/arch/arm/configs/bcm2835_defconfig
> > index 7aea702..74e27f0 100644
> > --- a/arch/arm/configs/bcm2835_defconfig
> > +++ b/arch/arm/configs/bcm2835_defconfig
> > @@ -66,8 +66,6 @@ CONFIG_TTY_PRINTK=y
> >   # CONFIG_FILE_LOCKING is not set
> >   # CONFIG_DNOTIFY is not set
> >   # CONFIG_INOTIFY_USER is not set
> > -# CONFIG_PROC_FS is not set
> > -# CONFIG_SYSFS is not set
> 
>     Hm, I don't see where are you enabling them... So I miss something?

Yes:

config PROC_FS
        bool "/proc file system support" if EXPERT
        default y

config SYSFS
        bool "sysfs file system support" if EXPERT
        default y

Those options are enabled by default. So, when there's nothing in the
defconfig file to disable them, they are enabled.

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] mvebu-gpio: Disable blinking when enabling a GPIO for output
From: Jamie Lentin @ 2012-10-28 12:23 UTC (permalink / raw)
  To: linux-arm-kernel

The plat-orion GPIO driver would disable any pin blinking whenever
using a pin for output. Do the same here, as a blinking LED will
continue to blink regardless of what the GPIO pin level is.

Signed-off-by: Jamie Lentin <jm@lentin.co.uk>
---
The power LED on the DNS-320/DNS-325 is left blinking by the bootloader,
the LED turning steady indicates it's booted. The blinking needs to be
disabled before setting the GPIO pin level has any effect.

Apart from the custom init code running too soon, I think everything is
working now.

I haven't tested this on any other boards, so not sure if it's sensible
beyond the kirkwood/orion world.

 drivers/gpio/gpio-mvebu.c |   23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)

diff --git a/drivers/gpio/gpio-mvebu.c b/drivers/gpio/gpio-mvebu.c
index cf7afb9..be65c04 100644
--- a/drivers/gpio/gpio-mvebu.c
+++ b/drivers/gpio/gpio-mvebu.c
@@ -92,6 +92,11 @@ static inline void __iomem *mvebu_gpioreg_out(struct mvebu_gpio_chip *mvchip)
 	return mvchip->membase + GPIO_OUT_OFF;
 }
 
+static inline void __iomem *mvebu_gpioreg_blink(struct mvebu_gpio_chip *mvchip)
+{
+	return mvchip->membase + GPIO_BLINK_EN_OFF;
+}
+
 static inline void __iomem *mvebu_gpioreg_io_conf(struct mvebu_gpio_chip *mvchip)
 {
 	return mvchip->membase + GPIO_IO_CONF_OFF;
@@ -206,6 +211,23 @@ static int mvebu_gpio_get(struct gpio_chip *chip, unsigned pin)
 	return (u >> pin) & 1;
 }
 
+static void mvebu_gpio_blink(struct gpio_chip *chip, unsigned pin, int value)
+{
+	struct mvebu_gpio_chip *mvchip =
+		container_of(chip, struct mvebu_gpio_chip, chip);
+	unsigned long flags;
+	u32 u;
+
+	spin_lock_irqsave(&mvchip->lock, flags);
+	u = readl_relaxed(mvebu_gpioreg_blink(mvchip));
+	if (value)
+		u |= 1 << pin;
+	else
+		u &= ~(1 << pin);
+	writel_relaxed(u, mvebu_gpioreg_blink(mvchip));
+	spin_unlock_irqrestore(&mvchip->lock, flags);
+}
+
 static int mvebu_gpio_direction_input(struct gpio_chip *chip, unsigned pin)
 {
 	struct mvebu_gpio_chip *mvchip =
@@ -244,6 +266,7 @@ static int mvebu_gpio_direction_output(struct gpio_chip *chip, unsigned pin,
 	if (ret)
 		return ret;
 
+	mvebu_gpio_blink(chip, pin, 0);
 	mvebu_gpio_set(chip, pin, value);
 
 	spin_lock_irqsave(&mvchip->lock, flags);
-- 
1.7.10.4

^ permalink raw reply related

* [PATCH] GPIO: mvebu-gpio: Don't initialize the mask_cache
From: Jamie Lentin @ 2012-10-28 12:17 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1351344538-5238-1-git-send-email-andrew@lunn.ch>

On Sat, 27 Oct 2012, Andrew Lunn wrote:

> Due to the SMP nature of some of the chips, which have per CPU
> registers, the driver does not use the generic irq_gc_mask_set_bit() &
> irq_gc_mask_clr_bit() functions, which only support a single register.
> The driver has its own implementation of these functions, which can
> pick the correct register depending on the CPU being used. The
> functions do however use the gc->mask_cache value.
>
> The call to irq_setup_generic_chip() was passing
> IRQ_GC_INIT_MASK_CACHE, which caused the gc->mask_cache to be
> initialized to the contents of some random register. This resulted in
> unexpected interrupts been delivered from random GPIO lines.
>
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>

Tested-by: Jamie Lentin <jm@lentin.co.uk>

This is what was causing my NAS to lock up when I turned the LEDs off. 
Thanks! The only one not working now is the power LED, patch coming soon 
to fix that.

> ---
> drivers/gpio/gpio-mvebu.c |    2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpio/gpio-mvebu.c b/drivers/gpio/gpio-mvebu.c
> index eb42ab1..cf7afb9 100644
> --- a/drivers/gpio/gpio-mvebu.c
> +++ b/drivers/gpio/gpio-mvebu.c
> @@ -646,7 +646,7 @@ static int __devinit mvebu_gpio_probe(struct platform_device *pdev)
> 	ct->handler = handle_edge_irq;
> 	ct->chip.name = mvchip->chip.label;
>
> -	irq_setup_generic_chip(gc, IRQ_MSK(ngpios), IRQ_GC_INIT_MASK_CACHE,
> +	irq_setup_generic_chip(gc, IRQ_MSK(ngpios), 0,
> 			       IRQ_NOREQUEST, IRQ_LEVEL | IRQ_NOPROBE);
>
> 	/* Setup irq domain on top of the generic chip. */
>

-- 
Jamie Lentin

^ permalink raw reply

* [PATCH 00/16] treewide: Convert dev_printk(KERN_<LEVEL> to dev_<level>(
From: Joe Perches @ 2012-10-28 12:12 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <508D0ECA.8040008@mvista.com>

On Sun, 2012-10-28 at 14:54 +0400, Sergei Shtylyov wrote:
> Hello.

Hi Sergei.

> On 28-10-2012 12:05, Joe Perches wrote:
> 
> > dev_<level> create smaller objects than dev_printk(KERN_<LEVEL>.
> > Convert non-debug calls to this form.
> 
> > Joe Perches (16):
> >    tile: Convert dev_printk(KERN_<LEVEL> to dev_<level>(
> [...]
> >    tile: Convert dev_printk(KERN_<LEVEL> to dev_<level>(
> [...]
> >    tile: Convert dev_printk(KERN_<LEVEL> to dev_<level>(
> 
>     Hm, somehow this patch is repeated thrice?

Nope, I forgot to edit the 0000 file after I edited
patches locally when I noticed I forgot to update
the subject lines.  Patches are corrected, 0000 not.

I don't think it's a bit deal, I could repost just the 0000
if you want though.

cheers, Joe

^ permalink raw reply

* [PATCH] arm: bcm2835: enable proc and sysfs in defconfig
From: Sergei Shtylyov @ 2012-10-28 11:43 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1351357249-17658-1-git-send-email-thomas.petazzoni@free-electrons.com>

Hello.

On 27-10-2012 21:00, Thomas Petazzoni wrote:

> For some reason, support for proc and sysfs is currently disabled in
> the bcm2835_defconfig, even though those filesystems are quite
> essential even for very basic Linux userspace. As most defconfig have
> them enabled by default, enable them as well in bcm2835_defconfig.

> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> ---
>   arch/arm/configs/bcm2835_defconfig |    2 --
>   1 file changed, 2 deletions(-)

> diff --git a/arch/arm/configs/bcm2835_defconfig b/arch/arm/configs/bcm2835_defconfig
> index 7aea702..74e27f0 100644
> --- a/arch/arm/configs/bcm2835_defconfig
> +++ b/arch/arm/configs/bcm2835_defconfig
> @@ -66,8 +66,6 @@ CONFIG_TTY_PRINTK=y
>   # CONFIG_FILE_LOCKING is not set
>   # CONFIG_DNOTIFY is not set
>   # CONFIG_INOTIFY_USER is not set
> -# CONFIG_PROC_FS is not set
> -# CONFIG_SYSFS is not set

    Hm, I don't see where are you enabling them... So I miss something?

WBR, Sergei

^ permalink raw reply

* [RFC PATCH v3 16/16] ARM: dts: add AM33XX SPI support
From: Sekhar Nori @ 2012-10-28 11:31 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1350566815-409-17-git-send-email-mporter@ti.com>

On 10/18/2012 6:56 PM, Matt Porter wrote:
> Adds AM33XX SPI support for am335x-bone and am335x-evm.
> 
> Signed-off-by: Matt Porter <mporter@ti.com>
> ---
>  arch/arm/boot/dts/am335x-bone.dts |   17 +++++++++++++++
>  arch/arm/boot/dts/am335x-evm.dts  |    9 ++++++++
>  arch/arm/boot/dts/am33xx.dtsi     |   43 +++++++++++++++++++++++++++++++++++++
>  3 files changed, 69 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/am335x-bone.dts b/arch/arm/boot/dts/am335x-bone.dts
> index 5510979..23edfd8 100644
> --- a/arch/arm/boot/dts/am335x-bone.dts
> +++ b/arch/arm/boot/dts/am335x-bone.dts
> @@ -18,6 +18,17 @@
>  		reg = <0x80000000 0x10000000>; /* 256 MB */
>  	};
>  
> +	am3358_pinmux: pinmux at 44e10800 {
> +		spi1_pins: pinmux_spi1_pins {
> +			pinctrl-single,pins = <
> +				0x190 0x13	/* mcasp0_aclkx.spi1_sclk, OUTPUT_PULLUP | MODE3 */
> +				0x194 0x33	/* mcasp0_fsx.spi1_d0, INPUT_PULLUP | MODE3 */
> +				0x198 0x13	/* mcasp0_axr0.spi1_d1, OUTPUT_PULLUP | MODE3 */
> +				0x19c 0x13	/* mcasp0_ahclkr.spi1_cs0, OUTPUT_PULLUP | MODE3 */
> +			>;

Is there a single pinmux setting that provides SPI functionality on the
bone headers? Or this is specific to a cape you tested with?

Thanks,
Sekhar

^ permalink raw reply

* [PATCH 01/12] ARM: shmobile: r8a7740: Enable PMU
From: Sergei Shtylyov @ 2012-10-28 11:28 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1351391173-32379-2-git-send-email-horms@verge.net.au>

Hello.

On 28-10-2012 6:26, Simon Horman wrote:

> From: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>

> This patch enables PMU for r8a7740.

    And enables performance events on the Armadillo board. Perhaps the 
defconfig part was worth a separate patch...

> Signed-off-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
> Signed-off-by: Simon Horman <horms@verge.net.au>
[...]

> diff --git a/arch/arm/mach-shmobile/setup-r8a7740.c b/arch/arm/mach-shmobile/setup-r8a7740.c
> index 11bb1d9..1e032cb 100644
> --- a/arch/arm/mach-shmobile/setup-r8a7740.c
> +++ b/arch/arm/mach-shmobile/setup-r8a7740.c
> @@ -590,6 +590,21 @@ static struct platform_device i2c1_device = {
>   	.num_resources	= ARRAY_SIZE(i2c1_resources),
>   };
>
> +static struct resource pmu_resources[] = {
> +	[0] = {
> +		.start	= evt2irq(0x19a0),
> +		.end	= evt2irq(0x19a0),
> +		.flags  = IORESOURCE_IRQ,
> +	},
> +};
> +
> +static struct platform_device pmu_device = {
> +	.name	= "arm-pmu",
> +	.id		= -1,

    I think you should either align '=' with tabs, or not bother doing this, 
not both. :-)

> +	.num_resources = ARRAY_SIZE(pmu_resources),
> +	.resource = pmu_resources,
> +};
> +
>   static struct platform_device *r8a7740_late_devices[] __initdata = {
>   	&i2c0_device,
>   	&i2c1_device,

WBR, Sergei

^ permalink raw reply

* [RFC PATCH v3 08/16] ARM: dts: add AM33XX EDMA support
From: Sekhar Nori @ 2012-10-28 11:16 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1350566815-409-9-git-send-email-mporter@ti.com>

On 10/18/2012 6:56 PM, Matt Porter wrote:
> Adds AM33XX EDMA support to the am33xx.dtsi as documented in
> Documentation/devicetree/bindings/dma/ti-edma.txt
> 
> Signed-off-by: Matt Porter <mporter@ti.com>
> ---
>  arch/arm/boot/dts/am33xx.dtsi |   31 +++++++++++++++++++++++++++++++
>  1 file changed, 31 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
> index bb31bff..ab9c78f 100644
> --- a/arch/arm/boot/dts/am33xx.dtsi
> +++ b/arch/arm/boot/dts/am33xx.dtsi
> @@ -62,6 +62,37 @@
>  			reg = <0x48200000 0x1000>;
>  		};
>  
> +		edma: edma at 49000000 {
> +			compatible = "ti,edma3";
> +			ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2";
> +			reg =	<0x49000000 0x10000>,
> +				<0x44e10f90 0x10>;
> +			interrupt-parent = <&intc>;
> +			interrupts = <12 13 14>;
> +			#dma-cells = <1>;
> +			dma-channels = <64>;
> +			ti,edma-regions = <4>;
> +			ti,edma-slots = <256>;
> +			ti,edma-reserved-channels = <0  2
> +						     14 2
> +						     26 6
> +						     48 4
> +						     56 8>;
> +			ti,edma-reserved-slots = <0  2
> +						  14 2
> +						  26 6
> +						  48 4
> +						  56 8
> +						  64 127>;

No need to reserve any channels or slots on AM335x, I think. This is
used on DaVinci devices to share channels with DSP. I am not sure the
cortex-M3 or PRU on the AM335x need to (or even can) have EDMA access.

Thanks,
Sekhar

^ permalink raw reply

* [RFC PATCH v3 05/16] ARM: edma: add AM33XX crossbar event support
From: Sekhar Nori @ 2012-10-28 11:11 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1350566815-409-6-git-send-email-mporter@ti.com>

On 10/18/2012 6:56 PM, Matt Porter wrote:
> Adds support for the per-EDMA channel event mux. This is required
> for any peripherals using DMA crossbar mapped events.
> 
> Signed-off-by: Matt Porter <mporter@ti.com>
> ---
>  arch/arm/common/edma.c             |   63 +++++++++++++++++++++++++++++++++++-
>  include/linux/platform_data/edma.h |    1 +
>  2 files changed, 63 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
> index 6d2a590..b761b7a 100644
> --- a/arch/arm/common/edma.c
> +++ b/arch/arm/common/edma.c
> @@ -1425,6 +1425,53 @@ static int edma_of_read_u32_to_s16_array(const struct device_node *np,
>  	return 0;
>  }
>  
> +static int edma_xbar_event_map(struct device *dev,
> +			       struct device_node *node,
> +			       struct edma_soc_info *pdata, int len)
> +{
> +	int ret = 0;
> +	int i;
> +	struct resource res;
> +	void *xbar;
> +	s16 (*xbar_chans)[2];
> +	u32 shift, offset, mux;
> +
> +	xbar_chans = devm_kzalloc(dev,
> +				  len/sizeof(s16) + 2*sizeof(s16),
> +				  GFP_KERNEL);
> +	if (!xbar_chans)
> +		return -ENOMEM;
> +
> +	ret = of_address_to_resource(node, 1, &res);
> +	if (IS_ERR_VALUE(ret))
> +		return -EIO;
> +
> +	xbar = devm_ioremap(dev, res.start, resource_size(&res));
> +	if (!xbar)
> +		return -EIO;

-ENOMEM is more appropiate for ioremap failures.

> +
> +	ret = edma_of_read_u32_to_s16_array(node,
> +					    "ti,edma-xbar-event-map",
> +					    (s16 *)xbar_chans,
> +					    len/sizeof(u32));
> +	if (IS_ERR_VALUE(ret))
> +		return -EIO;
> +
> +	for (i = 0; xbar_chans[i][0] != -1; i++) {
> +		shift = (xbar_chans[i][1] % 4) * 8;
> +		offset = xbar_chans[i][1] >> 2;
> +		offset <<= 2;
> +		mux = __raw_readl((void *)((u32)xbar + offset));

Dont use __raw* variants of io accessors. There will be ordering issues
on ARMv7.

> +		mux &= (~(0xff << shift));
> +		mux |= (xbar_chans[i][0] << shift);

Unnecessary parens above.

> +		__raw_writel(mux, (void *)((u32)xbar + offset));
> +	}
> +
> +	pdata->xbar_chans = xbar_chans;
> +
> +	return 0;
> +}
> +
>  static int edma_of_parse_dt(struct device *dev,
>  			    struct device_node *node,
>  			    struct edma_soc_info *pdata)
> @@ -1453,7 +1500,6 @@ static int edma_of_parse_dt(struct device *dev,
>  	pdata->n_slot = value;
>  
>  	pdata->n_cc = 1;
> -	/* This is unused */

The comment should have not been part of 4/16?

Thanks,
Sekhar

^ permalink raw reply

* [RFC PATCH v3 04/16] ARM: edma: add DT and runtime PM support for AM33XX
From: Sekhar Nori @ 2012-10-28 11:03 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1350566815-409-5-git-send-email-mporter@ti.com>

On 10/18/2012 6:56 PM, Matt Porter wrote:
> Adds support for parsing the TI EDMA DT data into the required
> EDMA private API platform data.
> 
> Calls runtime PM API only in the DT case in order to unidle the
> associated hwmods on AM33XX.

Runtime PM is supported on DaVinci now, so if that was the reason for
this choice, then it doesn't need to be that way.

> 
> Signed-off-by: Matt Porter <mporter@ti.com>
> ---
>  arch/arm/common/edma.c                      |  255 +++++++++++++++++++++++++--
>  arch/arm/mach-davinci/board-da830-evm.c     |    4 +-
>  arch/arm/mach-davinci/board-da850-evm.c     |    8 +-
>  arch/arm/mach-davinci/board-dm646x-evm.c    |    4 +-
>  arch/arm/mach-davinci/board-omapl138-hawk.c |    8 +-
>  arch/arm/mach-davinci/devices-da8xx.c       |    8 +-
>  arch/arm/mach-davinci/devices-tnetv107x.c   |    4 +-
>  arch/arm/mach-davinci/dm355.c               |    4 +-
>  arch/arm/mach-davinci/dm365.c               |    4 +-
>  arch/arm/mach-davinci/dm644x.c              |    4 +-
>  arch/arm/mach-davinci/dm646x.c              |    4 +-
>  include/linux/platform_data/edma.h          |    8 +-
>  12 files changed, 272 insertions(+), 43 deletions(-)
> 
> diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
> index a3d189d..6d2a590 100644
> --- a/arch/arm/common/edma.c
> +++ b/arch/arm/common/edma.c
> @@ -24,6 +24,13 @@
>  #include <linux/platform_device.h>
>  #include <linux/io.h>
>  #include <linux/slab.h>
> +#include <linux/edma.h>
> +#include <linux/err.h>
> +#include <linux/of_address.h>
> +#include <linux/of_device.h>
> +#include <linux/of_dma.h>
> +#include <linux/of_irq.h>
> +#include <linux/pm_runtime.h>
>  
>  #include <linux/platform_data/edma.h>
>  
> @@ -1366,31 +1373,237 @@ void edma_clear_event(unsigned channel)
>  EXPORT_SYMBOL(edma_clear_event);
>  
>  /*-----------------------------------------------------------------------*/
> +static int edma_of_read_u32_to_s8_array(const struct device_node *np,
> +					 const char *propname, s8 *out_values,
> +					 size_t sz)
> +{
> +	struct property *prop = of_find_property(np, propname, NULL);
> +	const __be32 *val;
> +
> +	if (!prop)
> +		return -EINVAL;
> +	if (!prop->value)
> +		return -ENODATA;
> +	if ((sz * sizeof(u32)) > prop->length)
> +		return -EOVERFLOW;
> +
> +	val = prop->value;
> +
> +	while (sz--)
> +		*out_values++ = (s8)(be32_to_cpup(val++) & 0xff);
> +
> +	/* Terminate it */
> +	*out_values++ = -1;
> +	*out_values++ = -1;
> +
> +	return 0;
> +}
> +
> +static int edma_of_read_u32_to_s16_array(const struct device_node *np,
> +					 const char *propname, s16 *out_values,
> +					 size_t sz)
> +{
> +	struct property *prop = of_find_property(np, propname, NULL);
> +	const __be32 *val;
> +
> +	if (!prop)
> +		return -EINVAL;
> +	if (!prop->value)
> +		return -ENODATA;
> +	if ((sz * sizeof(u32)) > prop->length)
> +		return -EOVERFLOW;
> +
> +	val = prop->value;
> +
> +	while (sz--)
> +		*out_values++ = (s16)(be32_to_cpup(val++) & 0xffff);
> +
> +	/* Terminate it */
> +	*out_values++ = -1;
> +	*out_values++ = -1;
> +
> +	return 0;
> +}

I think these helper functions will have some general use beyond EDMA
and can be kept in drivers/of/base.c. Grant/Rob need to agree though.

> diff --git a/arch/arm/mach-davinci/board-da830-evm.c b/arch/arm/mach-davinci/board-da830-evm.c
> index 95b5e10..ffcbec1 100644
> --- a/arch/arm/mach-davinci/board-da830-evm.c
> +++ b/arch/arm/mach-davinci/board-da830-evm.c
> @@ -512,7 +512,7 @@ static struct davinci_i2c_platform_data da830_evm_i2c_0_pdata = {
>   * example: Timer, GPIO, UART events etc) on da830/omap-l137 EVM, hence
>   * they are being reserved for codecs on the DSP side.
>   */
> -static const s16 da830_dma_rsv_chans[][2] = {
> +static s16 da830_dma_rsv_chans[][2] = {

I wonder why you had to remove const here and in other places. You seem
to be allocating new memory for DT case anyway. Its also not a good idea
to modify the passed platform data.

Thanks,
Sekhar

^ permalink raw reply

* [PATCH 12/12] ARM: mach-shmobile: Use DT_MACHINE for mackerel
From: Thomas Petazzoni @ 2012-10-28 10:57 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20121028104438.GC10073@verge.net.au>

Simon,

On Sun, 28 Oct 2012 19:44:38 +0900, Simon Horman wrote:

> shmobile is very much in the transition phase and we are, patch by patch,
> working towards full(er) DT support for boards, SoCs and drivers. I am not
> sure that now is the right time to jump to a approach similar to that taken
> by mach-kirkwood/board-dt.c.

Ok, I understand that for transition needs, each SoC family may need a
different method. My comment was more a general comment to make sure
that the right final direction is being taken. For sure the
intermediate steps may be different.

Best regards,

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 00/16] treewide: Convert dev_printk(KERN_<LEVEL> to dev_<level>(
From: Sergei Shtylyov @ 2012-10-28 10:54 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <cover.1351411047.git.joe@perches.com>

Hello.

On 28-10-2012 12:05, Joe Perches wrote:

> dev_<level> create smaller objects than dev_printk(KERN_<LEVEL>.
> Convert non-debug calls to this form.

> Joe Perches (16):
>    tile: Convert dev_printk(KERN_<LEVEL> to dev_<level>(
[...]
>    tile: Convert dev_printk(KERN_<LEVEL> to dev_<level>(
[...]
>    tile: Convert dev_printk(KERN_<LEVEL> to dev_<level>(

    Hm, somehow this patch is repeated thrice?

MBR, Sergei

^ permalink raw reply

* [PATCH 12/12] ARM: mach-shmobile: Use DT_MACHINE for mackerel
From: Simon Horman @ 2012-10-28 10:44 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20121028103711.4e89deb3@skate>

On Sun, Oct 28, 2012 at 10:37:11AM +0100, Thomas Petazzoni wrote:
> Dear Simon Horman,
> 
> On Sun, 28 Oct 2012 11:26:13 +0900, Simon Horman wrote:
> 
> > -MACHINE_START(MACKEREL, "mackerel")
> > +static const char *mackerel_boards_compat_dt[] __initdata = {
> > +	"renesas,mackerel",
> > +	NULL,
> > +};
> > +
> > +DT_MACHINE_START(MACKEREL_DT, "mackerel")
> >  	.map_io		= sh7372_map_io,
> >  	.init_early	= sh7372_add_early_devices,
> >  	.init_irq	= sh7372_init_irq,
> > @@ -1659,4 +1664,5 @@ MACHINE_START(MACKEREL, "mackerel")
> >  	.init_machine	= mackerel_init,
> >  	.init_late	= sh7372_pm_init_late,
> >  	.timer		= &shmobile_timer,
> > +	.dt_compat  = mackerel_boards_compat_dt,
> >  MACHINE_END
> 
> Not sure what is the status of mach-shmobile with regard to the device
> tree, but one of the idea of the device tree is to avoid having one .c
> file per board, and therefore one DT_MACHINE_START definition per
> board. There should be only only DT_MACHINE_START definition per SoC or
> SoC family, with the DT giving the detailed hardware description.
> 
> Of course, during a transition period, not all your drivers may have DT
> bindings, and therefore some devices may need to be probed in the "old"
> way (manual registration of platform_device). In that case, your
> ->init_machine() hook can call initialization function on a per-board
> basis by testing if the machine is such or such board.
> 
> See arch/arm/mach-kirkwood/board-dt.c for an example. The advantage is
> that with this solution, the board specific C files are progressively
> reducing in size as more and more devices get registered through the
> Device Tree, until the point where they become empty and can be removed.

Hi Thomas,

shmobile is very much in the transition phase and we are, patch by patch,
working towards full(er) DT support for boards, SoCs and drivers. I am not
sure that now is the right time to jump to a approach similar to that taken
by mach-kirkwood/board-dt.c.

^ permalink raw reply

* [PATCH 2/2] arm: bcm2835: properly use IOMEM() to define virtual address constants
From: Thomas Petazzoni @ 2012-10-28 10:24 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1351419853-25146-1-git-send-email-thomas.petazzoni@free-electrons.com>

Like we now do for all ARM platforms, use IOMEM() to define virtual
address constants, so that they get typed as 'void __iomem *'
pointers. It for now requires a cast when defining the map_desc entry,
but that cast should disappear once we switch map_desc to the usage of
'void __iomem *' pointers.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 arch/arm/mach-bcm2835/bcm2835.c |    2 +-
 arch/arm/mach-bcm2835/bcm2835.h |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-bcm2835/bcm2835.c b/arch/arm/mach-bcm2835/bcm2835.c
index cb2f963..9366c8f 100644
--- a/arch/arm/mach-bcm2835/bcm2835.c
+++ b/arch/arm/mach-bcm2835/bcm2835.c
@@ -24,7 +24,7 @@
 #include "bcm2835.h"
 
 static struct map_desc io_map __initdata = {
-	.virtual = BCM2835_PERIPH_VIRT,
+	.virtual = (unsigned long) BCM2835_PERIPH_VIRT,
 	.pfn = __phys_to_pfn(BCM2835_PERIPH_PHYS),
 	.length = BCM2835_PERIPH_SIZE,
 	.type = MT_DEVICE
diff --git a/arch/arm/mach-bcm2835/bcm2835.h b/arch/arm/mach-bcm2835/bcm2835.h
index 8fbad3a..db9d51e 100644
--- a/arch/arm/mach-bcm2835/bcm2835.h
+++ b/arch/arm/mach-bcm2835/bcm2835.h
@@ -21,7 +21,7 @@
 #include <asm/sizes.h>
 
 #define BCM2835_PERIPH_PHYS	0x20000000
-#define BCM2835_PERIPH_VIRT	0xf0000000
+#define BCM2835_PERIPH_VIRT	IOMEM(0xf0000000)
 #define BCM2835_PERIPH_SIZE	SZ_16M
 
 #endif
-- 
1.7.9.5

^ permalink raw reply related

* [PATCH 1/2] arm: bcm2835: move to the multiplatform support
From: Thomas Petazzoni @ 2012-10-28 10:24 UTC (permalink / raw)
  To: linux-arm-kernel

This commit integrates the bcm2835 into the list of platforms
supported by the multiplatform mechanism, which makes it possible to
build a single kernel binary image that boots on various SoCs.

In order to make this happen, we have to:

 * Move the ARCH_BCM2835 Kconfig option down to
   arch/arm/mach-bcm2835/Kconfig and make a few adjustements.

 * Move the DEBUG_LL/earlyprintk support from
   arch/arm/mach-bcm2835/include/mach/ to arch/arm/include/debug/

 * Remove files that have become useless (timex.h, uncompress.h)

 * Move the last remaining header file bcm2835_soc.h down to
   arch/arm/mach-bcm2835/.

The resulting binary kernel has been successfully booted on both the
Rasberry Pi platform and the Globalscale Mirabox (a Marvell Armada 370
based platform).

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
Note that if you have CONFIG_VFP enabled, you need "[PATCH v3] ARM:
vfp: fix save and restore when running on pre-VFPv3 and CONFIG_VFPv3
set" to be applied in order to avoid a VFP-related kernel panic when
starting the first userspace application. Thanks to Albin Tonnerre for
pointing me to the right fix for this problem!
---
 arch/arm/Kconfig                                   |   20 +--------
 arch/arm/Kconfig.debug                             |    8 ++++
 .../mach/debug-macro.S => include/debug/bcm2835.S} |    3 +-
 arch/arm/mach-bcm2835/Kconfig                      |   18 ++++++++
 arch/arm/mach-bcm2835/Makefile.boot                |    3 --
 arch/arm/mach-bcm2835/bcm2835.c                    |    2 +-
 .../{include/mach/bcm2835_soc.h => bcm2835.h}      |    2 -
 arch/arm/mach-bcm2835/include/mach/timex.h         |   26 -----------
 arch/arm/mach-bcm2835/include/mach/uncompress.h    |   45 --------------------
 9 files changed, 31 insertions(+), 96 deletions(-)
 rename arch/arm/{mach-bcm2835/include/mach/debug-macro.S => include/debug/bcm2835.S} (86%)
 create mode 100644 arch/arm/mach-bcm2835/Kconfig
 delete mode 100644 arch/arm/mach-bcm2835/Makefile.boot
 rename arch/arm/mach-bcm2835/{include/mach/bcm2835_soc.h => bcm2835.h} (91%)
 delete mode 100644 arch/arm/mach-bcm2835/include/mach/timex.h
 delete mode 100644 arch/arm/mach-bcm2835/include/mach/uncompress.h

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 7030500..7681840 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -334,24 +334,6 @@ config ARCH_AT91
 	  This enables support for systems based on Atmel
 	  AT91RM9200 and AT91SAM9* processors.
 
-config ARCH_BCM2835
-	bool "Broadcom BCM2835 family"
-	select ARCH_WANT_OPTIONAL_GPIOLIB
-	select ARM_AMBA
-	select ARM_ERRATA_411920
-	select ARM_TIMER_SP804
-	select CLKDEV_LOOKUP
-	select COMMON_CLK
-	select CPU_V6
-	select GENERIC_CLOCKEVENTS
-	select MULTI_IRQ_HANDLER
-	select SPARSE_IRQ
-	select USE_OF
-	select USE_IRQCHIP
-	help
-	  This enables support for the Broadcom BCM2835 SoC. This SoC is
-	  use in the Raspberry Pi, and Roku 2 devices.
-
 config ARCH_CNS3XXX
 	bool "Cavium Networks CNS3XXX family"
 	select ARM_GIC
@@ -1023,6 +1005,8 @@ source "arch/arm/mach-mvebu/Kconfig"
 
 source "arch/arm/mach-at91/Kconfig"
 
+source "arch/arm/mach-bcm2835/Kconfig"
+
 source "arch/arm/mach-clps711x/Kconfig"
 
 source "arch/arm/mach-cns3xxx/Kconfig"
diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index b0f3857..23495b3 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -89,6 +89,13 @@ choice
 		bool "Kernel low-level debugging on 9263 and 9g45"
 		depends on HAVE_AT91_DBGU1
 
+	config DEBUG_BCM2835_UART
+		bool "Kernel low-level debugging messages via BCM2835 UART"
+		depends on ARCH_BCM2835
+		help
+		  Say Y here if you want kernel low-level debugging support
+		  on BCM2835 based platforms.
+
 	config DEBUG_CLPS711X_UART1
 		bool "Kernel low-level debugging messages via UART1"
 		depends on ARCH_CLPS711X
@@ -411,6 +418,7 @@ endchoice
 
 config DEBUG_LL_INCLUDE
 	string
+	default "debug/bcm2835.S" if DEBUG_BCM2835_UART
 	default "debug/icedcc.S" if DEBUG_ICEDCC
 	default "debug/highbank.S" if DEBUG_HIGHBANK_UART
 	default "debug/mvebu.S" if DEBUG_MVEBU_UART
diff --git a/arch/arm/mach-bcm2835/include/mach/debug-macro.S b/arch/arm/include/debug/bcm2835.S
similarity index 86%
rename from arch/arm/mach-bcm2835/include/mach/debug-macro.S
rename to arch/arm/include/debug/bcm2835.S
index 8a161e4..afe8e04 100644
--- a/arch/arm/mach-bcm2835/include/mach/debug-macro.S
+++ b/arch/arm/include/debug/bcm2835.S
@@ -11,7 +11,8 @@
  *
  */
 
-#include <mach/bcm2835_soc.h>
+#define BCM2835_DEBUG_PHYS	0x20201000
+#define BCM2835_DEBUG_VIRT	0xf0201000
 
 	.macro	addruart, rp, rv, tmp
 	ldr	\rp, =BCM2835_DEBUG_PHYS
diff --git a/arch/arm/mach-bcm2835/Kconfig b/arch/arm/mach-bcm2835/Kconfig
new file mode 100644
index 0000000..e9bb58d
--- /dev/null
+++ b/arch/arm/mach-bcm2835/Kconfig
@@ -0,0 +1,18 @@
+config ARCH_BCM2835
+	bool "Broadcom BCM2835 family" if ARCH_MULTI_V6
+	select ARCH_WANT_OPTIONAL_GPIOLIB
+	select ARM_AMBA
+	select ARM_ERRATA_411920
+	select ARM_TIMER_SP804
+	select CLKDEV_LOOKUP
+	select COMMON_CLK
+	select CPU_V6
+	select GENERIC_CLOCKEVENTS
+	select MULTI_IRQ_HANDLER
+	select SPARSE_IRQ
+	select USE_OF
+	select USE_IRQCHIP
+	help
+	  This enables support for the Broadcom BCM2835 SoC. This SoC is
+	  use in the Raspberry Pi, and Roku 2 devices.
+
diff --git a/arch/arm/mach-bcm2835/Makefile.boot b/arch/arm/mach-bcm2835/Makefile.boot
deleted file mode 100644
index 2d30e17..0000000
--- a/arch/arm/mach-bcm2835/Makefile.boot
+++ /dev/null
@@ -1,3 +0,0 @@
-   zreladdr-y := 0x00008000
-params_phys-y := 0x00000100
-initrd_phys-y := 0x00800000
diff --git a/arch/arm/mach-bcm2835/bcm2835.c b/arch/arm/mach-bcm2835/bcm2835.c
index ab1bccd..cb2f963 100644
--- a/arch/arm/mach-bcm2835/bcm2835.c
+++ b/arch/arm/mach-bcm2835/bcm2835.c
@@ -21,7 +21,7 @@
 #include <asm/mach/arch.h>
 #include <asm/mach/map.h>
 
-#include <mach/bcm2835_soc.h>
+#include "bcm2835.h"
 
 static struct map_desc io_map __initdata = {
 	.virtual = BCM2835_PERIPH_VIRT,
diff --git a/arch/arm/mach-bcm2835/include/mach/bcm2835_soc.h b/arch/arm/mach-bcm2835/bcm2835.h
similarity index 91%
rename from arch/arm/mach-bcm2835/include/mach/bcm2835_soc.h
rename to arch/arm/mach-bcm2835/bcm2835.h
index d4dfcf7..8fbad3a 100644
--- a/arch/arm/mach-bcm2835/include/mach/bcm2835_soc.h
+++ b/arch/arm/mach-bcm2835/bcm2835.h
@@ -23,7 +23,5 @@
 #define BCM2835_PERIPH_PHYS	0x20000000
 #define BCM2835_PERIPH_VIRT	0xf0000000
 #define BCM2835_PERIPH_SIZE	SZ_16M
-#define BCM2835_DEBUG_PHYS	0x20201000
-#define BCM2835_DEBUG_VIRT	0xf0201000
 
 #endif
diff --git a/arch/arm/mach-bcm2835/include/mach/timex.h b/arch/arm/mach-bcm2835/include/mach/timex.h
deleted file mode 100644
index 6d021e1..0000000
--- a/arch/arm/mach-bcm2835/include/mach/timex.h
+++ /dev/null
@@ -1,26 +0,0 @@
-/*
- *  BCM2835 system clock frequency
- *
- *  Copyright (C) 2010 Broadcom
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
- */
-
-#ifndef __ASM_ARCH_TIMEX_H
-#define __ASM_ARCH_TIMEX_H
-
-#define CLOCK_TICK_RATE		(1000000)
-
-#endif
diff --git a/arch/arm/mach-bcm2835/include/mach/uncompress.h b/arch/arm/mach-bcm2835/include/mach/uncompress.h
deleted file mode 100644
index cc46dcc..0000000
--- a/arch/arm/mach-bcm2835/include/mach/uncompress.h
+++ /dev/null
@@ -1,45 +0,0 @@
-/*
- * Copyright (C) 2010 Broadcom
- * Copyright (C) 2003 ARM Limited
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- */
-
-#include <linux/io.h>
-#include <linux/amba/serial.h>
-#include <mach/bcm2835_soc.h>
-
-#define UART0_BASE BCM2835_DEBUG_PHYS
-
-#define BCM2835_UART_DR IOMEM(UART0_BASE + UART01x_DR)
-#define BCM2835_UART_FR IOMEM(UART0_BASE + UART01x_FR)
-#define BCM2835_UART_CR IOMEM(UART0_BASE + UART011_CR)
-
-static inline void putc(int c)
-{
-	while (__raw_readl(BCM2835_UART_FR) & UART01x_FR_TXFF)
-		barrier();
-
-	__raw_writel(c, BCM2835_UART_DR);
-}
-
-static inline void flush(void)
-{
-	int fr;
-
-	do {
-		fr = __raw_readl(BCM2835_UART_FR);
-		barrier();
-	} while ((fr & (UART011_FR_TXFE | UART01x_FR_BUSY)) != UART011_FR_TXFE);
-}
-
-#define arch_decomp_setup()
-#define arch_decomp_wdog()
-- 
1.7.9.5

^ permalink raw reply related

* [PATCH v2 3/4] arm: mvebu: move irq controller driver to drivers/irqchip
From: Thomas Petazzoni @ 2012-10-28  9:42 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1351416634-3352-4-git-send-email-thomas.petazzoni@free-electrons.com>

Now that the drivers/irqchip/ directory has a minimal infrastructure
to support the addition of irq controller driver, we move the irq
controller driver for Armada 370 and Armada XP ARM SoCs from the
arch/arm/mach-mvebu/ directory to the drivers/irqchip/ directory and
update the irqchip infrastructure to take into account this new
driver.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Stephen Warren <swarren@wwwdotorg.org>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Gregory Clement <gregory.clement@free-electrons.com>
---
 arch/arm/mach-mvebu/Kconfig                        |    1 +
 arch/arm/mach-mvebu/Makefile                       |    2 +-
 arch/arm/mach-mvebu/armada-370-xp.c                |    4 ++--
 arch/arm/mach-mvebu/common.h                       |    3 ---
 drivers/irqchip/Makefile                           |    1 +
 .../irqchip}/irq-armada-370-xp.c                   |   25 +++++++++-----------
 drivers/irqchip/irqchip.c                          |    6 +++++
 drivers/irqchip/irqchip.h                          |    2 ++
 8 files changed, 24 insertions(+), 20 deletions(-)
 rename {arch/arm/mach-mvebu => drivers/irqchip}/irq-armada-370-xp.c (87%)

diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index 416d46e..415ed0f 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -9,6 +9,7 @@ config ARCH_MVEBU
 	select PINCTRL
 	select PLAT_ORION
 	select SPARSE_IRQ
+	select USE_IRQCHIP
 
 if ARCH_MVEBU
 
diff --git a/arch/arm/mach-mvebu/Makefile b/arch/arm/mach-mvebu/Makefile
index 57f996b..7f4e9f4 100644
--- a/arch/arm/mach-mvebu/Makefile
+++ b/arch/arm/mach-mvebu/Makefile
@@ -2,4 +2,4 @@ ccflags-$(CONFIG_ARCH_MULTIPLATFORM) := -I$(srctree)/$(src)/include \
 	-I$(srctree)/arch/arm/plat-orion/include
 
 obj-y += system-controller.o
-obj-$(CONFIG_MACH_ARMADA_370_XP) += armada-370-xp.o irq-armada-370-xp.o addr-map.o
+obj-$(CONFIG_MACH_ARMADA_370_XP) += armada-370-xp.o addr-map.o
diff --git a/arch/arm/mach-mvebu/armada-370-xp.c b/arch/arm/mach-mvebu/armada-370-xp.c
index 68f1483..9b28991 100644
--- a/arch/arm/mach-mvebu/armada-370-xp.c
+++ b/arch/arm/mach-mvebu/armada-370-xp.c
@@ -16,6 +16,7 @@
 #include <linux/init.h>
 #include <linux/of_platform.h>
 #include <linux/io.h>
+#include <linux/irqchip.h>
 #include <linux/time-armada-370-xp.h>
 #include <asm/mach/arch.h>
 #include <asm/mach/map.h>
@@ -56,8 +57,7 @@ static const char * const armada_370_xp_dt_board_dt_compat[] = {
 DT_MACHINE_START(ARMADA_XP_DT, "Marvell Aramada 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,
-	.handle_irq     = armada_370_xp_handle_irq,
+	.init_irq	= irqchip_init,
 	.timer		= &armada_370_xp_timer,
 	.restart	= mvebu_restart,
 	.dt_compat	= armada_370_xp_dt_board_dt_compat,
diff --git a/arch/arm/mach-mvebu/common.h b/arch/arm/mach-mvebu/common.h
index 02f89ea..f0eaa21 100644
--- a/arch/arm/mach-mvebu/common.h
+++ b/arch/arm/mach-mvebu/common.h
@@ -17,7 +17,4 @@
 
 void mvebu_restart(char mode, const char *cmd);
 
-void armada_370_xp_init_irq(void);
-void armada_370_xp_handle_irq(struct pt_regs *regs);
-
 #endif
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index 77adcb1..d1a163c 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -1,2 +1,3 @@
 obj-$(CONFIG_USE_IRQCHIP) += irqchip.o
 obj-$(CONFIG_ARCH_BCM2835) += irq-bcm2835.o
+obj-$(CONFIG_ARCH_MVEBU)   += irq-armada-370-xp.o
diff --git a/arch/arm/mach-mvebu/irq-armada-370-xp.c b/drivers/irqchip/irq-armada-370-xp.c
similarity index 87%
rename from arch/arm/mach-mvebu/irq-armada-370-xp.c
rename to drivers/irqchip/irq-armada-370-xp.c
index 5f5f939..140c6b3 100644
--- a/arch/arm/mach-mvebu/irq-armada-370-xp.c
+++ b/drivers/irqchip/irq-armada-370-xp.c
@@ -23,6 +23,7 @@
 #include <linux/of_irq.h>
 #include <linux/irqdomain.h>
 #include <asm/mach/arch.h>
+#include <asm/mach/irq.h>
 #include <asm/exception.h>
 
 /* Interrupt Controller Registers Map */
@@ -77,8 +78,11 @@ static struct irq_domain_ops armada_370_xp_mpic_irq_ops = {
 	.xlate = irq_domain_xlate_onecell,
 };
 
-static int __init armada_370_xp_mpic_of_init(struct device_node *node,
-					     struct device_node *parent)
+static asmlinkage void
+armada_370_xp_handle_irq(struct pt_regs *regs);
+
+int __init armada_370_xp_mpic_of_init(struct device_node *node,
+				      struct device_node *parent)
 {
 	u32 control;
 
@@ -98,11 +102,14 @@ static int __init armada_370_xp_mpic_of_init(struct device_node *node,
 		panic("Unable to add Armada_370_Xp MPIC irq domain (DT)\n");
 
 	irq_set_default_host(armada_370_xp_mpic_domain);
+
+	handle_arch_irq = armada_370_xp_handle_irq;
+
 	return 0;
 }
 
-asmlinkage void __exception_irq_entry armada_370_xp_handle_irq(struct pt_regs
-							       *regs)
+static asmlinkage void __exception_irq_entry
+armada_370_xp_handle_irq(struct pt_regs *regs)
 {
 	u32 irqstat, irqnr;
 
@@ -121,13 +128,3 @@ asmlinkage void __exception_irq_entry armada_370_xp_handle_irq(struct pt_regs
 		break;
 	} while (1);
 }
-
-static const struct of_device_id mpic_of_match[] __initconst = {
-	{.compatible = "marvell,mpic", .data = armada_370_xp_mpic_of_init},
-	{},
-};
-
-void __init armada_370_xp_init_irq(void)
-{
-	of_irq_init(mpic_of_match);
-}
diff --git a/drivers/irqchip/irqchip.c b/drivers/irqchip/irqchip.c
index e2496e4..f36d423 100644
--- a/drivers/irqchip/irqchip.c
+++ b/drivers/irqchip/irqchip.c
@@ -20,6 +20,12 @@ static const struct of_device_id irqchip_of_match[] __initconst = {
 		.data = bcm2835_irqchip_init,
 	},
 #endif
+#ifdef CONFIG_ARCH_MVEBU
+	{
+		.compatible = "marvell,mpic",
+		.data = armada_370_xp_mpic_of_init,
+	},
+#endif
 	{},
 };
 
diff --git a/drivers/irqchip/irqchip.h b/drivers/irqchip/irqchip.h
index 1075537..0a0d7af 100644
--- a/drivers/irqchip/irqchip.h
+++ b/drivers/irqchip/irqchip.h
@@ -12,5 +12,7 @@
 #define _IRQCHIP_H
 
 int bcm2835_irqchip_init(struct device_node *node, struct device_node *parent);
+int armada_370_xp_mpic_of_init(struct device_node *node,
+			       struct device_node *parent);
 
 #endif
-- 
1.7.9.5

^ permalink raw reply related

* [PATCH v2 3/4] arm: mvebu: move irq controller driver to drivers/irqchip
From: Thomas Petazzoni @ 2012-10-28  9:41 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1351416634-3352-4-git-send-email-thomas.petazzoni@free-electrons.com>


On Sun, 28 Oct 2012 10:30:33 +0100, Thomas Petazzoni wrote:
> Now that the drivers/irqchip/ directory has a minimal infrastructure
> to support the addition of irq controller driver, we move the irq
> controller driver for Armada 370 and Armada XP ARM SoCs from the
> arch/arm/mach-mvebu/ directory to the drivers/irqchip/ directory and
> update the irqchip infrastructure to take into account this new
> driver.
> 
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> Reviewed-by: Stephen Warren <swarren@wwwdotorg.org>
> Cc: Jason Cooper <jason@lakedaemon.net>
> Cc: Andrew Lunn <andrew@lunn.ch>
> Cc: Gregory Clement <gregory.clement@free-electrons.com>

Grr, forgot -M when doing the format-patch, so it's showing a huge +/-
delta due to the code movement. Will repost an updated version of this
one.

Guess it's time to figure out how to make -M being the default for
format-patch here.

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 12/12] ARM: mach-shmobile: Use DT_MACHINE for mackerel
From: Thomas Petazzoni @ 2012-10-28  9:37 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1351391173-32379-13-git-send-email-horms@verge.net.au>

Dear Simon Horman,

On Sun, 28 Oct 2012 11:26:13 +0900, Simon Horman wrote:

> -MACHINE_START(MACKEREL, "mackerel")
> +static const char *mackerel_boards_compat_dt[] __initdata = {
> +	"renesas,mackerel",
> +	NULL,
> +};
> +
> +DT_MACHINE_START(MACKEREL_DT, "mackerel")
>  	.map_io		= sh7372_map_io,
>  	.init_early	= sh7372_add_early_devices,
>  	.init_irq	= sh7372_init_irq,
> @@ -1659,4 +1664,5 @@ MACHINE_START(MACKEREL, "mackerel")
>  	.init_machine	= mackerel_init,
>  	.init_late	= sh7372_pm_init_late,
>  	.timer		= &shmobile_timer,
> +	.dt_compat  = mackerel_boards_compat_dt,
>  MACHINE_END

Not sure what is the status of mach-shmobile with regard to the device
tree, but one of the idea of the device tree is to avoid having one .c
file per board, and therefore one DT_MACHINE_START definition per
board. There should be only only DT_MACHINE_START definition per SoC or
SoC family, with the DT giving the detailed hardware description.

Of course, during a transition period, not all your drivers may have DT
bindings, and therefore some devices may need to be probed in the "old"
way (manual registration of platform_device). In that case, your
->init_machine() hook can call initialization function on a per-board
basis by testing if the machine is such or such board.

See arch/arm/mach-kirkwood/board-dt.c for an example. The advantage is
that with this solution, the board specific C files are progressively
reducing in size as more and more devices get registered through the
Device Tree, until the point where they become empty and can be removed.

Best regards,

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 4/4] irqchip: add to the directories part of the IRQ subsystem in MAINTAINERS
From: Thomas Petazzoni @ 2012-10-28  9:30 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1351416634-3352-1-git-send-email-thomas.petazzoni@free-electrons.com>

Now that the drivers/irqchip/ directory is getting more code, it needs
a maintainer. The obvious maintainer for it is Thomas Gleixner, who is
maintaining the overall IRQ subsystem. So we add drivers/irqchip/ in
the list of directories that are part of the IRQ subsystem.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 MAINTAINERS |    1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 027ec2b..c057bfc 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4034,6 +4034,7 @@ M:	Thomas Gleixner <tglx@linutronix.de>
 S:	Maintained
 T:	git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git irq/core
 F:	kernel/irq/
+F:	drivers/irchip/
 
 IRQ DOMAINS (IRQ NUMBER MAPPING LIBRARY)
 M:	Benjamin Herrenschmidt <benh@kernel.crashing.org>
-- 
1.7.9.5

^ permalink raw reply related


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox