Another round of Device Tree enablement for Snowball
Subsystems (10)
cover Another round of Device Tree enablement for Snowball
This patch-set enables the following devices:
- External bus for Ethernet chip
- SMSC9115 Ethernet chip
- DB8500 PRCMU
- DB8500 PRCMU Timer (Clocksource)
... and provides the following functionality:
- Nomadik GPIO controller irqdomain support
... and fixes the following bugs:
- Attempt to free a non-existent IRQ in SMSC911x
- Attempt to probe non-existent devices on Snowball
.../devicetree/bindings/gpio/gpio-nmk.txt | 2 + arch/arm/boot/dts/db8500.dtsi | 39 ++++++++++++++++++- arch/arm/boot/dts/snowball.dts | 40 ++++++++++---------- arch/arm/mach-ux500/board-mop500.c | 38 ++++++++++++------- arch/arm/mach-ux500/board-mop500.h | 3 + arch/arm/mach-ux500/cpu-db8500.c | 33 ++++++++++++++++ arch/arm/mach-ux500/cpu.c | 1 + arch/arm/mach-ux500/timer.c | 24 ++++++++++++ drivers/gpio/gpio-nomadik.c | 40 ++++++++++++++++++- drivers/mfd/db8500-prcmu.c | 10 ++++- drivers/mmc/host/mmci.c | 5 +- drivers/net/ethernet/smsc/smsc911x.c | 3 +- 12 files changed, 192 insertions(+), 46 deletions(-)
PATCH 1/16 ARM: ux500: Enable the external bus with Device Tree
To allow for proper initialisation of the SMSC9115 Ethernet chip and other devices which may be connected to the 'external bus', Device Tree must first enable and traverse though it. This patch enables the 'external bus' which will facilitate further initialisation of its suborantate DT nodes.
--- arch/arm/mach-ux500/board-mop500.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-)
arch/arm/mach-ux500/board-mop500.c +1 -0
@@ -770,6 +770,7 @@ struct of_dev_auxdata u8500_auxdata_lookup[] __initdata = {static const struct of_device_id u8500_soc_node[] = {/* only create devices below soc node */ { .compatible ="stericsson,db8500" , }, + { .compatible ="simple-bus" }, { }, };
Signature · 1 line
1.7.9.1
Linus Walleij
AppliedPATCH 1/16 ARM: ux500: Enable the external bus with Device Tree
Quoted 7 lines · Lee Jones
To allow for proper initialisation of the SMSC9115 Ethernet chip and other devices which may be connected to the 'external bus', Device Tree must first enable and traverse though it. This patch enables the 'external bus' which will facilitate further initialisation of its suborantate DT nodes.
Signed-off-by Lee Jones <[email protected]>
The array the array containing the orthogonal (I guess?) buses is named "u8500_soc_node" and this one bus is not on the SoC right?
So take this opportunity to rename the device ID array from "u8500_soc_node" to "u8500_local_bus_nodes" or something that properly describes what it contains.
Or am I just dead wrong here?
Applied,
Linus Walleij
PATCH 2/16 drivers/gpio: gpio-nomadik: Add support for irqdomains
In reply to Lee JonesAdd irq domain support to the gpio-nomadik GPIO driver. This enables its users to support dynamic IRQ assignment, which is requried by Device Tree.
--- arch/arm/mach-ux500/cpu.c | 1 + drivers/gpio/gpio-nomadik.c | 40 +++++++++++++++++++++++++++++++++++++--- 2 files changed, 38 insertions(+), 3 deletions(-)
arch/arm/mach-ux500/cpu.c +1 -0
@@ -30,6 +30,7 @@void __iomem *_PRCMU_BASE; +/* FIXME: should we set up the GPIO domain here? */ static const struct of_device_id ux500_dt_irq_match[] = { { .compatible ="arm,cortex-a9-gic" , .data = gic_of_init, }, {},
drivers/gpio/gpio-nomadik.c +37 -3
@@ -22,6 +22,7 @@#include <linux/spinlock.h> #include <linux/interrupt.h> #include <linux/irq.h> +#include <linux/irqdomain.h> #include <linux/slab.h> #include <asm/mach/irq.h>
@@ -677,7 +678,6 @@ static int nmk_gpio_irq_set_type(struct irq_data *d, unsigned int type) bitmask =nmk_gpio_get_bitmask (gpio);if (!nmk_chip)return -EINVAL ; -if (type &IRQ_TYPE_LEVEL_HIGH )return -EINVAL ;if (type &IRQ_TYPE_LEVEL_LOW )
@@ -782,6 +782,33 @@ static void nmk_gpio_secondary_irq_handler(unsigned int irq,__nmk_gpio_irq_handler (irq, desc, status); } +#ifdef CONFIG_IRQ_DOMAIN +int nmk_gpio_irq_map (struct irq_domain *d,unsigned int irq, +irq_hw_number_t hwirq) +{ +return 0 ; +} + +const struct irq_domain_ops nmk_gpio_irq_simple_ops = { + .map = nmk_gpio_irq_map, + .xlate = irq_domain_xlate_twocell, +}; + +struct irq_domain *nmk_gpio_irq_domain_add (struct device_node *np, +struct nmk_gpio_platform_data *pdata) +{ +return irq_domain_add_legacy (np,NMK_GPIO_PER_CHIP , +NOMADIK_GPIO_TO_IRQ (pdata->first_gpio), +0 , &nmk_gpio_irq_simple_ops,NULL ); +} +#else +struct irq_domain *nmk_gpio_irq_domain_add (struct device_node *np, +struct nmk_gpio_platform_data *pdata) +{ +return NULL ; +} +#endif +static int nmk_gpio_init_irq (struct nmk_gpio_chip *nmk_chip) {unsigned int first_irq;
@@ -1072,6 +1099,7 @@ static int __devinit nmk_gpio_probe(struct platform_device *dev) {struct nmk_gpio_platform_data *pdata = dev->dev.platform_data;struct device_node *np = dev->dev.of_node; +struct irq_domain *domain =NULL ;struct nmk_gpio_chip *nmk_chip;struct gpio_chip *chip;struct resource *res;
@@ -1096,13 +1124,20 @@ static int __devinit nmk_gpio_probe(struct platform_device *dev)if (of_property_read_u32 (np,"gpio-bank" , &dev->id)) {dev_err (&dev->dev,"gpio-bank property not found\n" ); ret = -EINVAL ; - goto out_dt; + goto out; } pdata->first_gpio = dev->id *NMK_GPIO_PER_CHIP ; pdata->num_gpio =NMK_GPIO_PER_CHIP ; } + domain =nmk_gpio_irq_domain_add (np, pdata); +if (!domain) { +pr_err ("%s: Failed to create irqdomain - required for DT\n" , + np->full_name); +return -ENOSYS ; + } + res =platform_get_resource (dev,IORESOURCE_MEM ,0 );if (!res) { ret = -ENOENT ;
@@ -1189,7 +1224,6 @@ out_release: out:dev_err (&dev->dev,"Failure %i for GPIO %i-%i\n" , ret, pdata->first_gpio, pdata->first_gpio+31 ); -out_dt:if (np)kfree (pdata);
Signature · 1 line
1.7.9.1
PATCH 2/16 drivers/gpio: gpio-nomadik: Add support for irqdomains
arch/arm/mach-ux500/cpu.c line 33
Quoted 9 lines · Lee Jones
arch/arm/mach-ux500/cpu.c +1
-0@@ -30,6 +30,7 @@ ?void __iomem *_PRCMU_BASE; +/* FIXME: should we set up the GPIO domain here? */
Why on earth would we want to do that?
Get rid of the comment simply...
Quoted 21 lines
drivers/gpio/gpio-nomadik.c +0
-0@@ -22,6 +22,7 @@?#include <
linux/spinlock.h>
?#include <linux/interrupt.h>
?#include <linux/irq.h>
+#include <linux/irqdomain.h>
?#include <linux/slab.h>?#include <
asm/mach/irq.h>drivers/gpio/gpio-nomadik.c +0
-1@@ -677,7 +678,6 @@ static int nmk_gpio_irq_set_type(struct irq_data *d, unsigned int type) ? ? ? ?bitmask = nmk_gpio_get_bitmask(gpio); ? ? ? ?if (!nmk_chip) ? ? ? ? ? ? ? ?return -EINVAL; - ? ? ? ?if (type & IRQ_TYPE_LEVEL_HIGH) ? ? ? ? ? ? ? ?return -EINVAL; ? ? ? ?if (type & IRQ_TYPE_LEVEL_LOW)
drivers/gpio/gpio-nomadik.c static void nmk_gpio_secondary_irq_handler(unsigned int irq, · line 785
Quoted 4 lines
drivers/gpio/gpio-nomadik.c +1
-0@@ -782,6 +782,33 @@ static void nmk_gpio_secondary_irq_handler(unsigned int irq, ? ? ? ?__nmk_gpio_irq_handler(irq, desc, status); ?} +#ifdef CONFIG_IRQ_DOMAIN
No, modify Kconfig to select IRQ_DOMAIN for the driver instead. We want this also for the non-DT case.
drivers/gpio/gpio-nomadik.c static void nmk_gpio_secondary_irq_handler(unsigned int irq, · line 795
Quoted 10 lines
drivers/gpio/gpio-nomadik.c +10
-0+int nmk_gpio_irq_map (struct irq_domain *d,unsigned int irq, + ? ? ? ? ? ? ? ? ? ? ? ? irq_hw_number_t hwirq) +{ + ? ? ? return 0; +} + +const struct irq_domain_ops nmk_gpio_irq_simple_ops = { + ? ? ? .map = nmk_gpio_irq_map, + ? ? ? .xlate = irq_domain_xlate_twocell, +};
This is just a copy of irq_domain_simple_ops so get rid of that and use the simple ops directly.
drivers/gpio/gpio-nomadik.c static void nmk_gpio_secondary_irq_handler(unsigned int irq, · line 802
Quoted 7 lines
drivers/gpio/gpio-nomadik.c +7
-0+ +struct irq_domain *nmk_gpio_irq_domain_add (struct device_node *np, + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? struct nmk_gpio_platform_data *pdata) +{ + ? ? ? return irq_domain_add_legacy(np, NMK_GPIO_PER_CHIP, + ? ? ? ? ? ? ? ? ? ? ? NOMADIK_GPIO_TO_IRQ(pdata->first_gpio), + ? ? ? ? ? ? ? ? ? ? ? 0, &nmk_gpio_irq_simple_ops, NULL);
irq_domain_simple_ops then.
drivers/gpio/gpio-nomadik.c static void nmk_gpio_secondary_irq_handler(unsigned int irq, · line 810
Quoted 8 lines
drivers/gpio/gpio-nomadik.c +8
-0+} +#else +struct irq_domain *nmk_gpio_irq_domain_add (struct device_node *np, + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? struct nmk_gpio_platform_data *pdata) +{ + ? ? ? return NULL; +} +#endif
And since this is not going to be #ifdef:ed, just inline it.
Quoted 17 lines
drivers/gpio/gpio-nomadik.c +2
-1+ ?static int nmk_gpio_init_irq(struct nmk_gpio_chip *nmk_chip) ?{ ? ? ? ?unsigned int first_irq;@@ -1072,6 +1099,7 @@ static int __devinit nmk_gpio_probe(struct platform_device *dev) ?{ ? ? ? ?struct nmk_gpio_platform_data *pdata = dev->dev.platform_data; ? ? ? ?struct device_node *np = dev->dev.of_node; + ? ? ? struct irq_domain *domain = NULL; ? ? ? ?struct nmk_gpio_chip *nmk_chip; ? ? ? ?struct gpio_chip *chip; ? ? ? ?struct resource *res;@@ -1096,13 +1124,20 @@ static int __devinit nmk_gpio_probe(struct platform_device *dev) ? ? ? ? ? ? ? ?if (of_property_read_u32(np, "gpio-bank", &dev->id)) { ? ? ? ? ? ? ? ? ? ? ? ?dev_err(&dev->dev, "gpio-bank property not found\n"); ? ? ? ? ? ? ? ? ? ? ? ?ret = -EINVAL; - ? ? ? ? ? ? ? ? ? ? ? goto out_dt;
drivers/gpio/gpio-nomadik.c static int __devinit nmk_gpio_probe(struct platform_device *dev) · line 1136
Quoted 10 lines
drivers/gpio/gpio-nomadik.c +4
-0+ ? ? ? ? ? ? ? ? ? ? ? goto out; ? ? ? ? ? ? ? ?} ? ? ? ? ? ? ? ?pdata->first_gpio = dev->id * NMK_GPIO_PER_CHIP; ? ? ? ? ? ? ? ?pdata->num_gpio ? = NMK_GPIO_PER_CHIP; ? ? ? ?} + ? ? ? domain = nmk_gpio_irq_domain_add(np, pdata); + ? ? ? if (!domain) { + ? ? ? ? ? ? ? pr_err("%s: Failed to create irqdomain - required for DT\n",
Not just for DT, let's do this always.
Quoted 8 lines
drivers/gpio/gpio-nomadik.c +4
-0+ ? ? ? ? ? ? ? ? ? ? ? np->full_name); + ? ? ? ? ? ? ? return -ENOSYS; + ? ? ? } + ? ? ? ?res = platform_get_resource(dev, IORESOURCE_MEM, 0); ? ? ? ?if (!res) { ? ? ? ? ? ? ? ?ret = -ENOENT;@@ -1189,7 +1224,6 @@ out_release:
Quoted 6 lines
?out:
? ? ? ?dev_err(&dev->dev, "Failure %i for GPIO %i-%i\n", ret, ? ? ? ? ? ? ? ? ?pdata->first_gpio, pdata->first_gpio+31); -out_dt:
? ? ? ?if (np)
? ? ? ? ? ? ? ?kfree(pdata);
This patch is not complete:
__nmk_gpio_irq_handler() and friends need to be rewritten to use the mapper. i.e. no first_irq = NOMADIK_GPIO_TO_IRQ() etc in the interrupt handler, use the domain to translate the HW IRQ using irq_find_mapping(domain, irq), that's the whole point of the domain IIRC.
Yours,
Linus Walleij
PATCH 2/16 drivers/gpio: gpio-nomadik: Add support for irqdomains
Quoted 8 lines · Linus Walleij
Quoted 6 lines · Lee Jones
arch/arm/mach-ux500/cpu.c +0
-0@@ -30,6 +30,7 @@
Quoted 7 lines
arch/arm/mach-ux500/cpu.c line 33
Quoted 3 lines
arch/arm/mach-ux500/cpu.c +1
-0void __iomem *_PRCMU_BASE; +/* FIXME: should we set up the GPIO domain here? */ Why on earth would we want to do that?
Get rid of the comment simply...
I asked Lee to put it in ;-)
The problem is that we cannot put the interrupt resources into the platform device until the irq domain has been added. Right now, we set the gic interrupt domain from init_IRQ(), then add the load the gpio driver from core_initcall(nmk_gpio_init) and add the platform devices from arch_initcall(customize_machine).
This feels fragile because it depends on the gpio device getting probed before any device using the gpio interrupts. It does seem to work fine right now, but I'm not convinced that this is just coincidence.
Arnd
PATCH 2/16 drivers/gpio: gpio-nomadik: Add support for irqdomains
Quoted 9 lines · Arnd Bergmann
The problem is that we cannot put the interrupt resources into the platform device until the irq domain has been added. Right now, we set the gic interrupt domain from
init_IRQ(), then add the load the gpio driver fromcore_initcall(nmk_gpio_init)and add the platform devices fromarch_initcall(customize_machine).This feels fragile because it depends on the gpio device getting probed before any device using the gpio interrupts. It does seem to work fine right now, but I'm not convinced that this is just coincidence.
Aha OK. Why not put in that big comment then, thus nobody will ever miss the point like I did :-)
Thanks!
Linus Walleij
PATCH 2/16 drivers/gpio: gpio-nomadik: Add support for irqdomains
Quoted 9 lines · Linus Walleij
Quoted 6 lines · Arnd Bergmann
The problem is that we cannot put the interrupt resources into the platform device until the irq domain has been added. Right now, we set the gic interrupt domain from
init_IRQ(), then add the load the gpio driver fromcore_initcall(nmk_gpio_init)and add the platform devices fromarch_initcall(customize_machine).
Quoted 7 lines
Quoted 3 lines
This feels fragile because it depends on the gpio device getting probed before any device using the gpio interrupts. It does seem to work fine right now, but I'm not convinced that this is just coincidence.
Aha OK. Why not put in that big comment then, thus nobody will ever miss the point like I did :-)
I think I've just come up with a solution to this problem and would like to hear what Rob and Grant think about this:
If we move the code that adds the resources to a platform_device from of_device_alloc() to platform_drv_probe(), we can defer looking up the interrupt number until the driver actually gets probed and bail out early with -EPROBE_DEFER if the irq domain is not available yet. That will even work when we have a builtin driver for a device that uses a GPIO interrupt and the gpio controller driver is a loadable module.
Arnd
PATCH 2/16 drivers/gpio: gpio-nomadik: Add support for irqdomains
Quoted 21 lines · Arnd Bergmann
Quoted 9 lines · Linus Walleij
Quoted 6 lines · Arnd Bergmann
The problem is that we cannot put the interrupt resources into the platform device until the irq domain has been added. Right now, we set the gic interrupt domain from
init_IRQ(), then add the load the gpio driver fromcore_initcall(nmk_gpio_init)and add the platform devices fromarch_initcall(customize_machine).Quoted 7 lines
Quoted 3 lines
This feels fragile because it depends on the gpio device getting probed before any device using the gpio interrupts. It does seem to work fine right now, but I'm not convinced that this is just coincidence.
Aha OK. Why not put in that big comment then, thus nobody will ever miss the point like I did :-)
I think I've just come up with a solution to this problem and would like to hear what Rob and Grant think about this:
Quoted 8 lines
If we move the code that adds the resources to a
platform_devicefromof_device_alloc()toplatform_drv_probe(), we can defer looking up the interrupt number until the driver actually gets probed and bail out early with -EPROBE_DEFER if the irq domain is not available yet. That will even work when we have a builtin driver for a device that uses a GPIO interrupt and the gpio controller driver is a loadable module.
That certainly seems like a plausible solution and I don't have any thing better to suggest. Does that affect non-DT platform devices in a negative way?
Rob
Quoted 7 lines
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
PATCH 2/16 drivers/gpio: gpio-nomadik: Add support for irqdomains
Quoted 31 lines · Rob Herring
Quoted 21 lines · Arnd Bergmann
Quoted 9 lines · Linus Walleij
Quoted 6 lines · Arnd Bergmann
The problem is that we cannot put the interrupt resources into the platform device until the irq domain has been added. Right now, we set the gic interrupt domain from
init_IRQ(), then add the load the gpio driver fromcore_initcall(nmk_gpio_init)and add the platform devices fromarch_initcall(customize_machine).Quoted 7 lines
Quoted 3 lines
This feels fragile because it depends on the gpio device getting probed before any device using the gpio interrupts. It does seem to work fine right now, but I'm not convinced that this is just coincidence.
Aha OK. Why not put in that big comment then, thus nobody will ever miss the point like I did :-)
I think I've just come up with a solution to this problem and would like to hear what Rob and Grant think about this:
Quoted 8 lines
If we move the code that adds the resources to a
platform_devicefromof_device_alloc()toplatform_drv_probe(), we can defer looking up the interrupt number until the driver actually gets probed and bail out early with -EPROBE_DEFER if the irq domain is not available yet. That will even work when we have a builtin driver for a device that uses a GPIO interrupt and the gpio controller driver is a loadable module.
Quoted 3 lines
That certainly seems like a plausible solution and I don't have any thing better to suggest. Does that affect non-DT platform devices in a negative way?
I've been thinking about doing something like this for a while. If drivers are encouraged to use something like platform_get_irq(), or maybe a more generic interface for more than just platform devices, then there can be hooks in there to resolve irqs at probe time instead of device creation time. So I certainly support that approach.
g.
PATCH 2/16 drivers/gpio: gpio-nomadik: Add support for irqdomains
In reply to Arnd BergmannQuoted 7 lines · Arnd Bergmann
If we move the code that adds the resources to a
platform_devicefromof_device_alloc()to ?platform_drv_probe(), we can defer looking up the interrupt number until the driver actually gets probed and bail out early with -EPROBE_DEFER if the irq domain is not available yet. That will even work when we have a builtin driver for a device that uses a GPIO interrupt and the gpio controller driver is a loadable module.
Sounds like a good idea, we just need to make sure that the corresponding AMBA/PrimeCell devices doesn't end up with different semantics because of this.
So might need some patching around that bus as well.
Yours,
Linus Walleij
PATCH 3/16 ARM: ux500: Use correct format for dynamic IRQ assignment
In reply to Lee JonesThis patch applies the correct format requested by the irq domain. For chained IRQs which use GPIO lines as IRQs, we stipulate that a two cell request is required. The first cell contains the requested IRQ and the second can contain flags pertaining to edge detection and level sensitive values. The zeroth cell specifies the GPIO controller by use of a phandle.
--- arch/arm/boot/dts/db8500.dtsi | 22 ++++++++++++++++++++-- arch/arm/boot/dts/snowball.dts | 20 +++++++++----------- 2 files changed, 29 insertions(+), 13 deletions(-)
arch/arm/boot/dts/db8500.dtsi +20 -2
@@ -24,7 +24,6 @@ #interrupt-cells = <3>; #address-cells = <1>; interrupt-controller; - interrupt-parent; reg = <0xa0411000 0x1000>, <0xa0410100 0x100>; };
@@ -59,6 +58,8 @@ "st,nomadik-gpio"; reg = <0x8012e000 0x80>; interrupts = <0 119 0x4>; + interrupt-controller; + #interrupt-cells = <2>; supports-sleepmode; gpio-controller; #gpio-cells = <2>;
@@ -70,6 +71,8 @@ "st,nomadik-gpio"; reg = <0x8012e080 0x80>; interrupts = <0 120 0x4>; + interrupt-controller; + #interrupt-cells = <2>; supports-sleepmode; gpio-controller; #gpio-cells = <2>;
@@ -81,6 +84,8 @@ "st,nomadik-gpio"; reg = <0x8000e000 0x80>; interrupts = <0 121 0x4>; + interrupt-controller; + #interrupt-cells = <2>; supports-sleepmode; gpio-controller; #gpio-cells = <2>;
@@ -92,6 +97,8 @@ "st,nomadik-gpio"; reg = <0x8000e080 0x80>; interrupts = <0 122 0x4>; + interrupt-controller; + #interrupt-cells = <2>; supports-sleepmode; gpio-controller; #gpio-cells = <2>;
@@ -103,6 +110,8 @@ "st,nomadik-gpio"; reg = <0x8000e100 0x80>; interrupts = <0 123 0x4>; + interrupt-controller; + #interrupt-cells = <2>; supports-sleepmode; gpio-controller; #gpio-cells = <2>;
@@ -114,6 +123,8 @@ "st,nomadik-gpio"; reg = <0x8000e180 0x80>; interrupts = <0 124 0x4>; + interrupt-controller; + #interrupt-cells = <2>; supports-sleepmode; gpio-controller; #gpio-cells = <2>;
@@ -125,6 +136,8 @@ "st,nomadik-gpio"; reg = <0x8011e000 0x80>; interrupts = <0 125 0x4>; + interrupt-controller; + #interrupt-cells = <2>; supports-sleepmode; gpio-controller; #gpio-cells = <2>;
@@ -136,6 +149,8 @@ "st,nomadik-gpio"; reg = <0x8011e080 0x80>; interrupts = <0 126 0x4>; + interrupt-controller; + #interrupt-cells = <2>; supports-sleepmode; gpio-controller; #gpio-cells = <2>;
@@ -147,6 +162,8 @@ "st,nomadik-gpio"; reg = <0xa03fe000 0x80>; interrupts = <0 127 0x4>; + interrupt-controller; + #interrupt-cells = <2>; supports-sleepmode; gpio-controller; #gpio-cells = <2>;
@@ -230,7 +247,8 @@ status = "disabled"; // Add one of these for each child device - cs-gpios = <&gpio0 31 &gpio4 14 &gpio4 16 &gpio6 22 &gpio7 0>; + cs-gpios = <&gpio0 31 0x4 &gpio4 14 0x4 &gpio4 16 0x4 + &gpio6 22 0x4 &gpio7 0 0x4>; };
arch/arm/boot/dts/snowball.dts +9 -11
@@ -30,35 +30,35 @@ wakeup = <1>; linux,code = <2>; label = "userpb"; - gpios = <&gpio1 0 0>; + gpios = <&gpio1 0 0x4>; }; button at 2 { debounce_interval = <50>; wakeup = <1>; linux,code = <3>; label = "extkb1"; - gpios = <&gpio4 23 0>; + gpios = <&gpio4 23 0x4>; }; button at 3 { debounce_interval = <50>; wakeup = <1>; linux,code = <4>; label = "extkb2"; - gpios = <&gpio4 24 0>; + gpios = <&gpio4 24 0x4>; }; button at 4 { debounce_interval = <50>; wakeup = <1>; linux,code = <5>; label = "extkb3"; - gpios = <&gpio5 1 0>; + gpios = <&gpio5 1 0x4>; }; button at 5 { debounce_interval = <50>; wakeup = <1>; linux,code = <6>; label = "extkb4"; - gpios = <&gpio5 2 0>; + gpios = <&gpio5 2 0x4>; }; };
@@ -66,12 +66,11 @@ compatible = "gpio-leds"; used-led { label = "user_led"; - gpios = <&gpio4 14>; + gpios = <&gpio4 14 0x4>; }; }; soc-u9500 { - external-bus at 50000000 { compatible = "simple-bus"; reg = <0x50000000 0x10000000>;
@@ -82,7 +81,7 @@ ethernet at 50000000 { compatible = "smsc,9111"; reg = <0x50000000 0x10000>; - interrupts = <12>; + interrupts = <12 0x4>; interrupt-parent = <&gpio4>; }; };
@@ -94,8 +93,7 @@ bus-width = <8>; mmc-cap-mmc-highspeed; - #gpio-cells = <1>; - cd-gpios = <&gpio6 26>; // 218 + cd-gpios = <&gpio6 26 0x4>; // 218 cd-inverted; status = "okay";
@@ -127,7 +125,7 @@ tc3589x at 42 { //compatible = "tc3589x"; reg = <0x42>; - interrupts = <25>; + gpios = <&gpio6 25 0x4>; interrupt-parent = <&gpio6>; }; tps61052 at 33 {
Signature · 1 line
1.7.9.1
PATCH 3/16 ARM: ux500: Use correct format for dynamic IRQ assignment
Quoted 2 lines · Lee Jones
This patch applies the correct format requested by the irq domain.
Looks OK but can I apply this without applying the GPIO domain patch? Saving for later...
Yours,
Linus Walleij
PATCH 4/16 drivers/net: Do not free an IRQ if its request failed
In reply to Lee JonesRefrain from attempting to free an interrupt line if the request fails and hence, there is no IRQ to free.
--- drivers/net/ethernet/smsc/smsc911x.c | 3 +-- 1 files changed, 1 insertions(+), 2 deletions(-)
drivers/net/ethernet/smsc/smsc911x.c +1 -2
@@ -2382,7 +2382,6 @@ static int __devinit smsc911x_drv_probe(struct platform_device *pdev)SET_NETDEV_DEV (dev, &pdev->dev); pdata =netdev_priv (dev); - dev->irq = irq_res->start; irq_flags = irq_res->flags &IRQF_TRIGGER_MASK ; pdata->ioaddr =ioremap_nocache (res->start, res_size);
@@ -2446,7 +2445,7 @@ static int __devinit smsc911x_drv_probe(struct platform_device *pdev)if (retval) {SMSC_WARN (pdata, probe,"Unable to claim requested irq: %d" , dev->irq); - goto out_free_irq; + goto out_disable_resources; } retval =register_netdev (dev);
Signature · 1 line
1.7.9.1
PATCH 4/16 drivers/net: Do not free an IRQ if its request failed
Quoted 7 lines · Lee Jones
Refrain from attempting to free an interrupt line if the request fails and hence, there is no IRQ to free.
Signed-off-by Lee Jones <[email protected]>---
?drivers/net/ethernet/smsc/smsc911x.c | ? ?3 +--
?1 files changed, 1 insertions(+), 2 deletions(-)
You need to send this to linux-netdev, these are merged in David Millers tree.
Yours,
Linus Walleij
PATCH 5/16 ARM: ux500: New DT:ed snowball_platform_devs for one-by-one device enablement
In reply to Lee JonesDuring Device Tree enablement it is necessary to remove snowball_<device>* platform_data segments one at at time, as and when particular devices are DT enabled. This patch provides a temporary solution. Once this new struct is empty it will be removed again.
--- arch/arm/mach-ux500/board-mop500.c | 19 +++++++++++++++++-- 1 files changed, 17 insertions(+), 2 deletions(-)
arch/arm/mach-ux500/board-mop500.c +17 -2
@@ -609,6 +609,13 @@ static struct platform_device *snowball_platform_devs[] __initdata = { &ab8500_device, }; +static struct platform_device *snowball_of_platform_devs[]__initdata = { + &snowball_led_dev, + &snowball_key_dev, + &snowball_sbnet_dev, + &ab8500_device, +}; +static void __init mop500_init_machine (void ) {struct device *parent =NULL ;
@@ -801,8 +808,16 @@ static void __init u8500_init_machine(void)mop500_sdi_init (parent); }else if (of_machine_is_compatible ("calaosystems,snowball-a9500" )) {snowball_pins_init (); -platform_add_devices (snowball_platform_devs, -ARRAY_SIZE (snowball_platform_devs)); + +/* +* Devices to be DT:ed: +* snowball_led_dev = todo +* snowball_key_dev = todo +* snowball_sbnet_dev = done +* ab8500_device = todo +*/ +platform_add_devices (snowball_of_platform_devs, +ARRAY_SIZE (snowball_of_platform_devs)); }else if (of_machine_is_compatible ("st-ericsson,hrefv60+" )) {/*
Signature · 1 line
1.7.9.1
PATCH 6/16 ARM: ux500: New DT:ed u8500_init_devices for one-by-one device enablement
In reply to Lee JonesDuring Device Tree enablement it is necessary to remove <hw_component>_add_<device> calls one at at time, as and when particular devices are DT enabled. This patch provides a temporary solution. Once the new *of_init_devices function has been fully unpopulated it will be removed again.
--- arch/arm/mach-ux500/board-mop500.c | 2 +- arch/arm/mach-ux500/board-mop500.h | 3 +++ arch/arm/mach-ux500/cpu-db8500.c | 22 ++++++++++++++++++++++ 3 files changed, 26 insertions(+), 1 deletions(-)
arch/arm/mach-ux500/board-mop500.c +1 -1
@@ -787,7 +787,7 @@ static void __init u8500_init_machine(void)int i2c0_devs;int i; - parent =u8500_init_devices (); + parent =u8500_of_init_devices (); i2c0_devs =ARRAY_SIZE (mop500_i2c0_devices);for (i =0 ; i <ARRAY_SIZE (mop500_platform_devs); i++)
arch/arm/mach-ux500/board-mop500.h +3 -0
@@ -92,4 +92,7 @@ void __init snowball_pins_init(void);void mop500_uib_i2c_add (int busnum,struct i2c_board_info *info,unsigned n); +/* TODO: Once all pieces are DT:ed, remove completely. */ +struct device *__init u8500_of_init_devices (void ); +#endif
arch/arm/mach-ux500/cpu-db8500.c +22 -0
@@ -206,3 +206,25 @@ struct device * __init u8500_init_devices(void)return parent; } + +/* TODO: Once all pieces are DT:ed, remove completely. */ +struct device *__init u8500_of_init_devices (void ) +{ +struct device *parent; +int i; + + parent =db8500_soc_device_init (); + +db8500_add_rtc (parent); +db8500_add_usb (parent, usb_db8500_rx_dma_cfg, usb_db8500_tx_dma_cfg); + +platform_device_register_data (parent, +"cpufreq-u8500" ,-1 ,NULL ,0 ); + +for (i =0 ; i <ARRAY_SIZE (platform_devs); i++) + platform_devs[i]->dev.parent = parent; + +platform_add_devices (platform_devs,ARRAY_SIZE (platform_devs)); + +return parent; +}
Signature · 1 line
1.7.9.1
PATCH 7/16 ARM: ux500: Enable the SMSC9115 on Snowball via Device Tree
In reply to Lee JonesEnable the Ethernet port by providing correct information via DT.
--- arch/arm/boot/dts/snowball.dts | 10 ++++++++-- arch/arm/mach-ux500/board-mop500.c | 1 - 2 files changed, 8 insertions(+), 3 deletions(-)
arch/arm/boot/dts/snowball.dts +8 -2
@@ -79,10 +79,16 @@ ranges; ethernet at 50000000 { - compatible = "smsc,9111"; + compatible = "smsc,lan9115"; reg = <0x50000000 0x10000>; - interrupts = <12 0x4>; + interrupts = <12 0x1>; interrupt-parent = <&gpio4>; + + reg-shift = <1>; + reg-io-width = <2>; + smsc,force-internal-phy; + smsc,irq-active-high; + smsc,irq-push-pull; }; };
arch/arm/mach-ux500/board-mop500.c +0 -1
@@ -612,7 +612,6 @@ static struct platform_device *snowball_platform_devs[] __initdata = {static struct platform_device *snowball_of_platform_devs[]__initdata = { &snowball_led_dev, &snowball_key_dev, - &snowball_sbnet_dev, &ab8500_device, };
Signature · 1 line
1.7.9.1
PATCH 7/16 ARM: ux500: Enable the SMSC9115 on Snowball via Device Tree
Quoted 3 lines · Lee Jones
Enable the Ethernet port by providing correct information via DT.
Signed-off-by Lee Jones <[email protected]>
I guess patches 5-7 are dependent on the GPIO IRQ domain being fixed first in order to be applied or they won't work?
Yours,
Linus Walleij
PATCH 8/16 drivers/mmc: MMCI: Use correct GPIO binding for IRQ requests
In reply to Lee JonesNow there are irqdomains in place for Snowball, we can request GPIO IRQs directly by their binding. This replaces the previous method of hard-coding the hwirq using u32 values in the DT.
--- drivers/mmc/host/mmci.c | 5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-)
drivers/mmc/host/mmci.c +3 -2
@@ -26,6 +26,7 @@#include <linux/clk.h> #include <linux/scatterlist.h> #include <linux/gpio.h> +#include <linux/of_gpio.h> #include <linux/regulator/consumer.h> #include <linux/dmaengine.h> #include <linux/dma-mapping.h>
@@ -1203,11 +1204,11 @@ static void mmci_dt_populate_generic_pdata(struct device_node *np, {int bus_width =0 ; -of_property_read_u32 (np,"wp-gpios" , &pdata->gpio_wp); + pdata->gpio_wp =of_get_named_gpio (np,"wp-gpios" ,0 );if (!pdata->gpio_wp) pdata->gpio_wp =-1 ; -of_property_read_u32 (np,"cd-gpios" , &pdata->gpio_cd); + pdata->gpio_cd =of_get_named_gpio (np,"cd-gpios" ,0 );if (!pdata->gpio_cd) pdata->gpio_cd =-1 ;
Signature · 1 line
1.7.9.1
PATCH 8/16 drivers/mmc: MMCI: Use correct GPIO binding for IRQ requests
Quoted 5 lines · Lee Jones
Now there are irqdomains in place for Snowball, we can request GPIO IRQs directly by their binding. This replaces the previous method of hard-coding the hwirq using u32 values in the DT.
Signed-off-by Lee Jones <[email protected]>
Please just squash this into the previous MMCI patch and resend it.
Yours,
Linus Walleij
PATCH 9/16 ARM: ux500: Correctly describe SMSC9115 for Snowball in DT
In reply to Lee JonesHere we split the description of the external-bus at 50000000 over two description files. In the more generic db8500 description file we only specify the external-bus. Normally this would be used to communicate with a NOR-flash device. On the Snowball however, the SMSC9115 Ethernet chip occupies it. In the Snowball board specific description file is where we actually specify that it is in fact the Ethernet device which lives here.
--- arch/arm/boot/dts/db8500.dtsi | 9 +++++++++ arch/arm/boot/dts/snowball.dts | 10 +++------- 2 files changed, 12 insertions(+), 7 deletions(-)
arch/arm/boot/dts/db8500.dtsi +9 -0
@@ -307,5 +307,14 @@ interrupts = <0 100 0x4>; status = "disabled"; }; + + external-bus at 50000000 { + compatible = "simple-bus"; + reg = <0x50000000 0x4000000>; + #address-cells = <1>; + #size-cells = <1>; + ranges = <0 0x50000000 0x4000000>; + status = "disabled"; + }; }; };
arch/arm/boot/dts/snowball.dts +3 -7
@@ -72,15 +72,11 @@ soc-u9500 { external-bus at 50000000 { - compatible = "simple-bus"; - reg = <0x50000000 0x10000000>; - #address-cells = <1>; - #size-cells = <1>; - ranges; + status = "okay"; - ethernet at 50000000 { + ethernet at 0 { compatible = "smsc,lan9115"; - reg = <0x50000000 0x10000>; + reg = <0 0x10000>; interrupts = <12 0x1>; interrupt-parent = <&gpio4>;
Signature · 1 line
1.7.9.1
PATCH 10/16 drivers/gpio: represent gpio-nomadik as an IRQ controller in DT documentation
In reply to Lee JonesNow gpio-nomadik has proper bindings devices initialised by Device Tree entries are able to use the chained GPIO IRQ lines it provides. This patch aims to reflect that in the gpio-nmk documentation.
--- .../devicetree/bindings/gpio/gpio-nmk.txt | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-)
Documentation/devicetree/bindings/gpio/gpio-nmk.txt +2 -0
@@ -13,6 +13,7 @@ Required properties: 4 = active high level-sensitive. 8 = active low level-sensitive. - gpio-controller : Marks the device node as a GPIO controller. +- gpio-interrupt : Marks the device node as a GPIO controller. - gpio-bank : Specifies which bank a controller owns. - st,supports-sleepmode : Specifies whether controller can sleep or not
@@ -24,6 +25,7 @@ Example: interrupts = <0 120 0x4>; #gpio-cells = <2>; gpio-controller; + interrupt-controller; supports-sleepmode; gpio-bank = <1>; };
Signature · 1 line
1.7.9.1
PATCH 10/16 drivers/gpio: represent gpio-nomadik as an IRQ controller in DT documentation
Quoted 11 lines · Lee Jones
Documentation/devicetree/bindings/gpio/gpio-nmk.txt +1
-0@@ -13,6 +13,7 @@ Required properties: 4 = active high level-sensitive. 8 = active low level-sensitive. - gpio-controller : Marks the device node as a GPIO controller. +- gpio-interrupt : Marks the device node as a GPIO controller. - gpio-bank : Specifies which bank a controller owns. - st,supports-sleepmode : Specifies whether controller can sleep or not
Documentation/devicetree/bindings/gpio/gpio-nmk.txt Example: · line 31
Quoted 7 lines
Documentation/devicetree/bindings/gpio/gpio-nmk.txt +1
-0@@ -24,6 +25,7 @@ Example: interrupts = <0 120 0x4>; #gpio-cells = <2>; gpio-controller; + interrupt-controller; supports-sleepmode; gpio-bank = <1>; };
Documentation doesn't match the example or the code: it should be 'interrupt-controller' above, not 'gpio-interrupt'.
Arnd
PATCH 10/16 drivers/gpio: represent gpio-nomadik as an IRQ controller in DT documentation
Quoted 11 lines · Arnd Bergmann
Quoted 10 lines · Lee Jones
Documentation/devicetree/bindings/gpio/gpio-nmk.txt +1
-0@@ -13,6 +13,7 @@ Required properties: 4 = active high level-sensitive. 8 = active low level-sensitive. - gpio-controller : Marks the device node as a GPIO controller. +- gpio-interrupt : Marks the device node as a GPIO controller. - gpio-bank : Specifies which bank a controller owns. - st,supports-sleepmode : Specifies whether controller can sleep or not
Quoted 11 lines
Documentation/devicetree/bindings/gpio/gpio-nmk.txt Example: · line 31
Quoted 8 lines
Documentation/devicetree/bindings/gpio/gpio-nmk.txt +1
-0@@ -24,6 +25,7 @@ Example: interrupts =<0 120 0x4>; #gpio-cells =<2>; gpio-controller; + interrupt-controller; supports-sleepmode; gpio-bank =<1>; };Documentation doesn't match the example or the code: it should be 'interrupt-controller' above, not 'gpio-interrupt'.
Yes, this is actually wrong is a number of ways. I believe this was an early adaptation, which I was in the middle of editing. I don't know how I ended up committing it. I'll fix and resend.
Signature · 5 lines
Lee Jones Linaro ST-Ericsson Landing Team Lead M: +44 77 88 633 515 Linaro.org ? Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
PATCH v2 10/16 drivers/gpio: represent gpio-nomadik as an IRQ controller in DT documentation
In reply to Arnd BergmannFrom: Lee Jones <[email protected]>
Date: Fri, 13 Apr 2012 16:05:26 +0100
Subject: [PATCH 10/16] drivers/gpio: represent gpio-nomadik as an IRQ
controller in DT documentation
Now gpio-nomadik has proper bindings devices initialised by Device Tree entries are able to use the chained GPIO IRQ lines it provides. This patch aims to reflect that in the gpio-nmk documentation.
--- .../devicetree/bindings/gpio/gpio-nmk.txt | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-)
(quoted diff) +0 -0
b/Documentation/devicetree/bindings/gpio/gpio-nmk.txt index 3856789..ee87467 100644
Documentation/devicetree/bindings/gpio/gpio-nmk.txt +2 -0
@@ -13,6 +13,7 @@ Required properties: 4 = active high level-sensitive. 8 = active low level-sensitive. - gpio-controller : Marks the device node as a GPIO controller. +- interrupt-controller : Marks the device node as an interrupt controller. - gpio-bank : Specifies which bank a controller owns. - st,supports-sleepmode : Specifies whether controller can sleep or not
@@ -24,6 +25,7 @@ Example: interrupts = <0 120 0x4>; #gpio-cells = <2>; gpio-controller; + interrupt-controller; supports-sleepmode; gpio-bank = <1>; };
Signature · 8 lines
1.7.9.1 -- Lee Jones Linaro ST-Ericsson Landing Team Lead M: +44 77 88 633 515 Linaro.org ? Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
PATCH v2 10/16 drivers/gpio: represent gpio-nomadik as an IRQ controller in DT documentation
In reply to Arnd BergmannFrom: Lee Jones <[email protected]>
Date: Fri, 13 Apr 2012 16:05:26 +0100
Subject: [PATCH 10/16] drivers/gpio: represent gpio-nomadik as an IRQ
controller in DT documentation
Now gpio-nomadik has proper bindings devices initialised by Device Tree entries are able to use the chained GPIO IRQ lines it provides. This patch aims to reflect that in the gpio-nmk documentation.
--- .../devicetree/bindings/gpio/gpio-nmk.txt | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-)
Documentation/devicetree/bindings/gpio/gpio-nmk.txt +2 -0
@@ -13,6 +13,7 @@ Required properties: 4 = active high level-sensitive. 8 = active low level-sensitive. - gpio-controller : Marks the device node as a GPIO controller. +- interrupt-controller : Marks the device node as an interrupt controller. - gpio-bank : Specifies which bank a controller owns. - st,supports-sleepmode : Specifies whether controller can sleep or not
@@ -24,6 +25,7 @@ Example: interrupts = <0 120 0x4>; #gpio-cells = <2>; gpio-controller; + interrupt-controller; supports-sleepmode; gpio-bank = <1>; };
Signature · 1 line
1.7.9.1
PATCH 11/16 ARM: ux500: Do not attempt to register non-existent i2c devices on Snowball
In reply to Lee JonesThis patch prevents i2c devices which are not present on the Snowball low-cost development board from being registered. Devices such as; tc3589x, bu1780 and lp5521 are present on other supported boards, but are not located on Snowball.
--- arch/arm/mach-ux500/board-mop500.c | 17 ++++++----------- 1 files changed, 6 insertions(+), 11 deletions(-)
arch/arm/mach-ux500/board-mop500.c +6 -11
@@ -652,7 +652,6 @@ static void __init mop500_init_machine(void)static void __init snowball_init_machine (void ) {struct device *parent =NULL ; -int i2c0_devs;int i; parent =u8500_init_devices ();
@@ -670,11 +669,6 @@ static void __init snowball_init_machine(void)mop500_spi_init (parent);mop500_uart_init (parent); - i2c0_devs =ARRAY_SIZE (mop500_i2c0_devices); -i2c_register_board_info (0 , mop500_i2c0_devices, i2c0_devs); -i2c_register_board_info (2 , mop500_i2c2_devices, -ARRAY_SIZE (mop500_i2c2_devices)); -/* This board has full regulator constraints */ regulator_has_full_constraints (); }
@@ -787,7 +781,6 @@ static void __init u8500_init_machine(void)int i; parent =u8500_of_init_devices (); - i2c0_devs =ARRAY_SIZE (mop500_i2c0_devices);for (i =0 ; i <ARRAY_SIZE (mop500_platform_devs); i++) mop500_platform_devs[i]->dev.parent = parent;
@@ -805,6 +798,12 @@ static void __init u8500_init_machine(void) ARRAY_SIZE(mop500_platform_devs));mop500_sdi_init (parent); + + i2c0_devs =ARRAY_SIZE (mop500_i2c0_devices); +i2c_register_board_info (0 , mop500_i2c0_devices, i2c0_devs); +i2c_register_board_info (2 , mop500_i2c2_devices, +ARRAY_SIZE (mop500_i2c2_devices)); + }else if (of_machine_is_compatible ("calaosystems,snowball-a9500" )) {snowball_pins_init ();
@@ -834,10 +833,6 @@ static void __init u8500_init_machine(void) }mop500_i2c_init (parent); -i2c_register_board_info (0 , mop500_i2c0_devices, i2c0_devs); -i2c_register_board_info (2 , mop500_i2c2_devices, -ARRAY_SIZE (mop500_i2c2_devices)); -/* This board has full regulator constraints */ regulator_has_full_constraints (); }
Signature · 1 line
1.7.9.1
PATCH 11/16 ARM: ux500: Do not attempt to register non-existent i2c devices on Snowball
Quoted 5 lines · Lee Jones
This patch prevents i2c devices which are not present on the Snowball low-cost development board from being registered. Devices such as; tc3589x, bu1780 and lp5521 are present on other supported boards, but are not located on Snowball.
It looks like you only register the devices on mop500 now, but no longer on hrev60+, which before this patch registers a subset.
Arnd
PATCH 11/16 ARM: ux500: Do not attempt to register non-existent i2c devices on Snowball
Quoted 9 lines · Arnd Bergmann
Quoted 5 lines · Lee Jones
This patch prevents i2c devices which are not present on the Snowball low-cost development board from being registered. Devices such as; tc3589x, bu1780 and lp5521 are present on other supported boards, but are not located on Snowball.
It looks like you only register the devices on mop500 now, but no longer on hrev60+, which before this patch registers a subset.
Quite right. I'll fix.
Signature · 5 lines
Lee Jones Linaro ST-Ericsson Landing Team Lead M: +44 77 88 633 515 Linaro.org ? Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
PATCH v2 11/16 ARM: ux500: Do not attempt to register non-existent i2c devices on Snowball
In reply to Lee JonesFrom: Lee Jones <[email protected]>
Date: Mon, 16 Apr 2012 15:26:55 +0100
Subject: [PATCH 11/16] ARM: ux500: Do not attempt to register non-existent
i2c devices on Snowball
This patch prevents i2c devices which are not present on the Snowball low-cost development board from being registered. Devices such as; tc3589x, bu1780 and lp5521 are present on other supported boards, but are not located on Snowball.
--- arch/arm/mach-ux500/board-mop500.c | 24 +++++++++++++----------- 1 files changed, 13 insertions(+), 11 deletions(-)
arch/arm/mach-ux500/board-mop500.c +13 -11
@@ -652,7 +652,6 @@ static void __init mop500_init_machine(void)static void __init snowball_init_machine (void ) {struct device *parent =NULL ; -int i2c0_devs;int i; parent =u8500_init_devices ();
@@ -670,11 +669,6 @@ static void __init snowball_init_machine(void)mop500_spi_init (parent);mop500_uart_init (parent); - i2c0_devs =ARRAY_SIZE (mop500_i2c0_devices); -i2c_register_board_info (0 , mop500_i2c0_devices, i2c0_devs); -i2c_register_board_info (2 , mop500_i2c2_devices, -ARRAY_SIZE (mop500_i2c2_devices)); -/* This board has full regulator constraints */ regulator_has_full_constraints (); }
@@ -787,7 +781,6 @@ static void __init u8500_init_machine(void)int i; parent =u8500_of_init_devices (); - i2c0_devs =ARRAY_SIZE (mop500_i2c0_devices);for (i =0 ; i <ARRAY_SIZE (mop500_platform_devs); i++) mop500_platform_devs[i]->dev.parent = parent;
@@ -805,6 +798,12 @@ static void __init u8500_init_machine(void) ARRAY_SIZE(mop500_platform_devs));mop500_sdi_init (parent); + + i2c0_devs =ARRAY_SIZE (mop500_i2c0_devices); +i2c_register_board_info (0 , mop500_i2c0_devices, i2c0_devs); +i2c_register_board_info (2 , mop500_i2c2_devices, +ARRAY_SIZE (mop500_i2c2_devices)); + }else if (of_machine_is_compatible ("calaosystems,snowball-a9500" )) {snowball_pins_init ();
@@ -831,13 +830,16 @@ static void __init u8500_init_machine(void) ARRAY_SIZE(mop500_platform_devs));hrefv60_sdi_init (parent); + + i2c0_devs =ARRAY_SIZE (mop500_i2c0_devices); + i2c0_devs -=NUM_PRE_V60_I2C0_DEVICES ; + +i2c_register_board_info (0 , mop500_i2c0_devices, i2c0_devs); +i2c_register_board_info (2 , mop500_i2c2_devices, +ARRAY_SIZE (mop500_i2c2_devices)); }mop500_i2c_init (parent); -i2c_register_board_info (0 , mop500_i2c0_devices, i2c0_devs); -i2c_register_board_info (2 , mop500_i2c2_devices, -ARRAY_SIZE (mop500_i2c2_devices)); -/* This board has full regulator constraints */ regulator_has_full_constraints (); }
Signature · 8 lines
1.7.9.1 -- Lee Jones Linaro ST-Ericsson Landing Team Lead M: +44 77 88 633 515 Linaro.org ? Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
PATCH v2 11/16 ARM: ux500: Do not attempt to register non-existent i2c devices on Snowball
Quoted 11 lines · Lee Jones
From: Lee Jones <[email protected]>
Date: Mon, 16 Apr 2012 15:26:55 +0100
Subject: [PATCH 11/16] ARM: ux500: Do not attempt to register non-existent
i2c devices on SnowballThis patch prevents i2c devices which are not present on the Snowball low-cost development board from being registered. Devices such as; tc3589x, bu1780 and lp5521 are present on other supported boards, but are not located on Snowball.
Signed-off-by Lee Jones <[email protected]>
arch/arm/mach-ux500/board-mop500.c static void __init u8500_init_machine(void) · line 841
Quoted 13 lines
arch/arm/mach-ux500/board-mop500.c +7
-0@@ -831,13 +830,16 @@ static void __init u8500_init_machine(void) ARRAY_SIZE(mop500_platform_devs));hrefv60_sdi_init (parent); + + i2c0_devs =ARRAY_SIZE (mop500_i2c0_devices); + i2c0_devs -=NUM_PRE_V60_I2C0_DEVICES ; + +i2c_register_board_info (0 , mop500_i2c0_devices, i2c0_devs); +i2c_register_board_info (2 , mop500_i2c2_devices, +ARRAY_SIZE (mop500_i2c2_devices)); }mop500_i2c_init (parent);
You could still simplify this and get rid of the i2c0_devs variable, but this version is fine too, since it does match the hrefv60_init_machine() function that has the same code in it.
Arnd
PATCH 12/16 mfd/db8500-prcmu: Register as a platform driver instead of only probing
In reply to Lee JonesPass the probe function as part of the platform_driver struct and register using the more common platform_driver_register call. In subsequent patches we'll also add DT support into the struct.
--- drivers/mfd/db8500-prcmu.c | 5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-)
drivers/mfd/db8500-prcmu.c +3 -2
@@ -2957,7 +2957,7 @@ static struct mfd_cell db8500_prcmu_devs[] = {* prcmu_fw_init - arch init call for the Linux PRCMU fw init logic * */ -static int __init db8500_prcmu_probe (struct platform_device *pdev) +static int __devinit db8500_prcmu_probe (struct platform_device *pdev) {int err =0 ;
@@ -2998,11 +2998,12 @@ static struct platform_driver db8500_prcmu_driver = { .name = "db8500-prcmu", .owner = THIS_MODULE, }, + .probe = db8500_prcmu_probe, };static int __init db8500_prcmu_init (void ) { -return platform_driver_probe (&db8500_prcmu_driver, db8500_prcmu_probe); +return platform_driver_register (&db8500_prcmu_driver); }arch_initcall (db8500_prcmu_init);
Signature · 1 line
1.7.9.1
PATCH 12/16 mfd/db8500-prcmu: Register as a platform driver instead of only probing
Quoted 5 lines · Lee Jones
Pass the probe function as part of the
platform_driverstruct and register using the more commonplatform_driver_registercall. In subsequent patches we'll also add DT support into the struct.Signed-off-by Lee Jones <[email protected]>
This goes through the MFD tree so send it to Samuel Ortiz + LKML.
If you get his ACK I can take it through ux500-core.
Yours,
Linus Walleij
PATCH 13/16 mfd/db8500-prcmu: Add Device Tree support
In reply to Lee JonesHere we see the db8500-prcmu driver obtain DT support. In its current state, all we have to do is offer a matching compatible node and the driver will register and initialise correctly.
--- drivers/mfd/db8500-prcmu.c | 5 +++++ 1 files changed, 5 insertions(+), 0 deletions(-)
drivers/mfd/db8500-prcmu.c +5 -0
@@ -2992,11 +2992,16 @@ static int __devinit db8500_prcmu_probe(struct platform_device *pdev) no_irq_return:return err; } +static const struct of_device_id db8500_prcmu_match[] = { + { .compatible ="stericsson,db8500-prcmu" }, + { }, +};static struct platform_driver db8500_prcmu_driver = { .driver = { .name ="db8500-prcmu" , .owner =THIS_MODULE , + .of_match_table = db8500_prcmu_match, }, .probe = db8500_prcmu_probe, };
Signature · 1 line
1.7.9.1
PATCH 13/16 mfd/db8500-prcmu: Add Device Tree support
Quoted 8 lines · Lee Jones
Here we see the db8500-prcmu driver obtain DT support. In its current state, all we have to do is offer a matching compatible node and the driver will register and initialise correctly.
Signed-off-by Lee Jones <[email protected]>---
?drivers/mfd/db8500-prcmu.c | ? ?5 +++++
?1 files changed, 5 insertions(+), 0 deletions(-)
Goes through the MFD tree or I need Sam's ACK.
Yours,
Linus Walleij
PATCH 14/16 ARM: ux500: Fork cpu-db8500 platform_devs for sequential DT enablement
In reply to Lee JonesTo aid in sequential one-by-one Device Tree enablement, we split cpu-db8500's platform_devs structure into normal platform boot, where we leave all devices to be added in tact and a DT version where we will remove the devices as they are DT enabled.
--- arch/arm/mach-ux500/cpu-db8500.c | 18 +++++++++++++++--- 1 files changed, 15 insertions(+), 3 deletions(-)
arch/arm/mach-ux500/cpu-db8500.c +15 -3
@@ -121,6 +121,12 @@ static struct platform_device *platform_devs[] __initdata = { &db8500_prcmu_device, }; +static struct platform_device *of_platform_devs[]__initdata = { + &u8500_dma40_device, + &db8500_pmu_device, + &db8500_prcmu_device, +}; +static resource_size_t __initdata db8500_gpio_base[] = {U8500_GPIOBANK0_BASE ,U8500_GPIOBANK1_BASE ,
@@ -221,10 +227,16 @@ struct device * __init u8500_of_init_devices(void)platform_device_register_data (parent,"cpufreq-u8500" ,-1 ,NULL ,0 ); -for (i =0 ; i <ARRAY_SIZE (platform_devs); i++) - platform_devs[i]->dev.parent = parent; +for (i =0 ; i <ARRAY_SIZE (of_platform_devs); i++) + of_platform_devs[i]->dev.parent = parent; -platform_add_devices (platform_devs,ARRAY_SIZE (platform_devs)); +/* +* Devices to be DT:ed: +* u8500_dma40_device = todo +* db8500_pmu_device = todo +* db8500_prcmu_device = todo +*/ +platform_add_devices (of_platform_devs,ARRAY_SIZE (of_platform_devs));return parent; }
Signature · 1 line
1.7.9.1
PATCH 15/16 ARM: ux500: Apply Device Tree settings for the DB8500 PRCMU
In reply to Lee JonesIn this patch we enable the db8500-prcmu via DT and take out any enablement previously carried out by platform code.
--- arch/arm/mach-ux500/cpu-db8500.c | 3 +-- 1 files changed, 1 insertions(+), 2 deletions(-)
arch/arm/mach-ux500/cpu-db8500.c +1 -2
@@ -124,7 +124,6 @@ static struct platform_device *platform_devs[] __initdata = {static struct platform_device *of_platform_devs[]__initdata = { &u8500_dma40_device, &db8500_pmu_device, - &db8500_prcmu_device, };static resource_size_t __initdata db8500_gpio_base[] = {
@@ -234,7 +233,7 @@ struct device * __init u8500_of_init_devices(void)* Devices to be DT:ed: * u8500_dma40_device = todo * db8500_pmu_device = todo -* db8500_prcmu_device = todo +* db8500_prcmu_device = done */ platform_add_devices (of_platform_devs,ARRAY_SIZE (of_platform_devs));
Signature · 1 line
1.7.9.1
PATCH 15/16 ARM: ux500: Apply Device Tree settings for the DB8500 PRCMU
Quoted 4 lines · Lee Jones
In this patch we enable the db8500-prcmu via DT and take out any enablement previously carried out by platform code.
Signed-off-by Lee Jones <[email protected]>
This patch by itself is broken, because it relies on patch 16. I suggest merging the two into a single patch to atomically move over from the static definition of the prcmu to the device tree based definition. You can also combine it with patch 14, which by itself is harmless but also pointless.
Arnd
PATCH 15/16 ARM: ux500: Apply Device Tree settings for the DB8500 PRCMU
Quoted 11 lines · Arnd Bergmann
Quoted 4 lines · Lee Jones
In this patch we enable the db8500-prcmu via DT and take out any enablement previously carried out by platform code.
Signed-off-by Lee Jones<[email protected]>This patch by itself is broken, because it relies on patch 16. I suggest merging the two into a single patch to atomically move over from the static definition of the prcmu to the device tree based definition. You can also combine it with patch 14, which by itself is harmless but also pointless.
Not as far as I can tell. This patch relies on 12 and 13. Patch 16 is for the PRCMU timer, which is a different entity.
Signature · 5 lines
Lee Jones Linaro ST-Ericsson Landing Team Lead M: +44 77 88 633 515 Linaro.org ? Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
PATCH 15/16 ARM: ux500: Apply Device Tree settings for the DB8500 PRCMU
Quoted 8 lines · Lee Jones
Quoted 6 lines · Arnd Bergmann
Quoted 4 lines · Lee Jones
In this patch we enable the db8500-prcmu via DT and take out any enablement previously carried out by platform code.
Signed-off-by Lee Jones<[email protected]>
Quoted 9 lines
Quoted 5 lines
This patch by itself is broken, because it relies on patch 16. I suggest merging the two into a single patch to atomically move over from the static definition of the prcmu to the device tree based definition. You can also combine it with patch 14, which by itself is harmless but also pointless.
Not as far as I can tell. This patch relies on 12 and 13. Patch 16 is for the PRCMU timer, which is a different entity.
Ah, I see. In this case, I would combine patches 13 and 15 because otherwise you end up with a duplicate prcmu device when only patch 13 is applied.
Arnd
PATCH 15/16 ARM: ux500: Apply Device Tree settings for the DB8500 PRCMU
Quoted 15 lines · Arnd Bergmann
Quoted 14 lines · Lee Jones
Quoted 11 lines · Arnd Bergmann
Quoted 4 lines · Lee Jones
In this patch we enable the db8500-prcmu via DT and take out any enablement previously carried out by platform code.
Signed-off-by Lee Jones<[email protected]>This patch by itself is broken, because it relies on patch 16. I suggest merging the two into a single patch to atomically move over from the static definition of the prcmu to the device tree based definition. You can also combine it with patch 14, which by itself is harmless but also pointless.
Quoted 7 lines
Quoted 3 lines
Not as far as I can tell. This patch relies on 12 and 13. Patch 16 is for the PRCMU timer, which is a different entity.
Ah, I see. In this case, I would combine patches 13 and 15 because otherwise you end up with a duplicate prcmu device when only patch 13 is applied.
Okay, give me 1 minute.
Signature · 5 lines
Lee Jones Linaro ST-Ericsson Landing Team Lead M: +44 77 88 633 515 Linaro.org ? Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
PATCH v2 1/1 ARM: ux500: Apply Device Tree settings for the DB8500 PRCMU
In reply to Lee JonesFrom: Lee Jones <[email protected]>
Date: Tue, 17 Apr 2012 10:42:41 +0100
Subject: [PATCH 1/2] mfd/db8500-prcmu: Add Device Tree support and enable
ux500 platforms
Here we see the db8500-prcmu driver obtain DT support. In its current state, all we have to do is offer a matching compatible node and the driver will register and initialise correctly. We Also remove any initialisation completed in platform code to prevent any device duplication.
--- arch/arm/mach-ux500/cpu-db8500.c | 3 +-- drivers/mfd/db8500-prcmu.c | 5 +++++ 2 files changed, 6 insertions(+), 2 deletions(-)
arch/arm/mach-ux500/cpu-db8500.c +1 -2
@@ -124,7 +124,6 @@ static struct platform_device *platform_devs[] __initdata = {static struct platform_device *of_platform_devs[]__initdata = { &u8500_dma40_device, &db8500_pmu_device, - &db8500_prcmu_device, };static resource_size_t __initdata db8500_gpio_base[] = {
@@ -234,7 +233,7 @@ struct device * __init u8500_of_init_devices(void)* Devices to be DT:ed: * u8500_dma40_device = todo * db8500_pmu_device = todo -* db8500_prcmu_device = todo +* db8500_prcmu_device = done */ platform_add_devices (of_platform_devs,ARRAY_SIZE (of_platform_devs));
drivers/mfd/db8500-prcmu.c +5 -0
@@ -2992,11 +2992,16 @@ static int __devinit db8500_prcmu_probe(struct platform_device *pdev) no_irq_return:return err; } +static const struct of_device_id db8500_prcmu_match[] = { + { .compatible ="stericsson,db8500-prcmu" }, + { }, +};static struct platform_driver db8500_prcmu_driver = { .driver = { .name ="db8500-prcmu" , .owner =THIS_MODULE , + .of_match_table = db8500_prcmu_match, }, .probe = db8500_prcmu_probe, };
Signature · 1 line
1.7.9.1
PATCH v2 1/1 ARM: ux500: Apply Device Tree settings for the DB8500 PRCMU
Quoted 5 lines · Lee Jones
From: Lee Jones <[email protected]>
Date: Tue, 17 Apr 2012 10:42:41 +0100
Subject: [PATCH 1/2] mfd/db8500-prcmu: Add Device Tree support and enable ?ux500 platforms
Quoted 7 lines
Here we see the db8500-prcmu driver obtain DT support. In its current state, all we have to do is offer a matching compatible node and the driver will register and initialise correctly. We Also remove any initialisation completed in platform code to prevent any device duplication.
Signed-off-by Lee Jones <[email protected]>
And this (while it looks OK) still needs to go through the MFD tree or have Sam's ACK.
Yours,
Linus Walleij
PATCH 16/16 ARM: ux500: Enable PRCMU Timer 4 (clocksource) via Device Tree
In reply to Lee JonesIn dbx500 based devices the PRCMU Timer 4 is used as a clocksource and sched_clock. Here we fetch all necessary addressing information required for correct PRCMU initialisation from the Device Tree instead of using hard-coded values.
--- arch/arm/boot/dts/db8500.dtsi | 8 +++++++- arch/arm/mach-ux500/timer.c | 24 ++++++++++++++++++++++++ 2 files changed, 31 insertions(+), 1 deletions(-)
arch/arm/boot/dts/db8500.dtsi +7 -1
@@ -189,7 +189,13 @@ reg = <0x80157000 0x1000>; interrupts = <46 47>; #address-cells = <1>; - #size-cells = <0>; + #size-cells = <1>; + ranges; + + prcmu-timer-4 at 80157450 { + compatible = "stericsson,db8500-prcmu-timer-4"; + reg = <0x80157450 0xC>; + }; ab8500 at 5 { compatible = "stericsson,ab8500";
arch/arm/mach-ux500/timer.c +24 -0
@@ -8,6 +8,7 @@#include <linux/errno.h> #include <linux/clksrc-dbx500-prcmu.h> #include <linux/of.h> +#include <linux/of_address.h> #include <asm/smp_twd.h>
@@ -43,10 +44,17 @@ static void __init ux500_twd_init(void)#define ux500_twd_init () do { } while(0)#endif +const static struct of_device_id prcmu_timer_of_match[]__initconst = { + { .compatible ="stericsson,db8500-prcmu-timer-4" , }, + { }, +}; +static void __init ux500_timer_init (void ) {void __iomem *mtu_timer_base;void __iomem *prcmu_timer_base; +void __iomem *tmp_base; +struct device_node *np;if (cpu_is_u5500 ()) { mtu_timer_base =__io_address (U5500_MTU0_BASE );
@@ -58,6 +66,22 @@ static void __init ux500_timer_init(void)ux500_unknown_soc (); } +/* TODO: Once MTU has been DT:ed place code above into else. */ +if (of_have_populated_dt ()) { + np =of_find_matching_node (NULL , prcmu_timer_of_match); +if (!np) + goto dt_fail; + + tmp_base =of_iomap (np,0 ); +if (!tmp_base) + goto dt_fail; + + prcmu_timer_base = tmp_base; + } + +dt_fail: +/* Doing it the old fashioned way. */ +/* * Here we register the timerblocks active in the system. * Localtimers (twd) is started when both cpu is up and running.
Signature · 1 line
1.7.9.1
cover Another round of Device Tree enablement for Snowball
In reply to Lee JonesQuoted 7 lines · Lee Jones
This patch-set enables the following devices:
- External bus for Ethernet chip
- SMSC9115 Ethernet chip
- DB8500 PRCMU
- DB8500 PRCMU Timer (Clocksource)
Quoted 6 lines
... and provides the following functionality:
- Nomadik GPIO controller irqdomain support... and fixes the following bugs:
- Attempt to free a non-existent IRQ in SMSC911x
- Attempt to probe non-existent devices on Snowball
I found small problems in three patches, everything else