Another round of Device Tree enablement for Snowball

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]>

Add irq domain support to the gpio-nomadik GPIO driver. This enables its users to support dynamic IRQ assignment, which is requried by Device Tree.

Signed-off-by Lee Jones <[email protected]>

Quoted 4 lines · Lee Jones

Add irq domain support to the gpio-nomadik GPIO driver. This enables its users to support dynamic IRQ assignment, which is requried by Device Tree.

Quoted 1 line

Signed-off-by Lee Jones <[email protected]>

Hey, it works!

Applied to my gpio-and-pin ux500 branch.

Note to Grant: I'm shepherding the ux500 GPIO patches for funneling through the ARM SoC tree.

This 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.

Signed-off-by Lee Jones <[email protected]>

---
?arch/arm/boot/dts/db8500.dtsi ?| ? 22 ++++++++++++++++++++-- ?arch/arm/boot/dts/snowball.dts | ? 20 +++++++++----------- ?2 files changed, 29 insertions(+), 13 deletions(-)

Quoted 7 lines · Lee Jones

This 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.

Quoted 5 lines

Signed-off-by Lee Jones<[email protected]>

---
  arch/arm/boot/dts/db8500.dtsi  |   22 ++++++++++++++++++++--
  arch/arm/boot/dts/snowball.dts |   20 +++++++++-----------
  2 files changed, 29 insertions(+), 13 deletions(-)

So I created a separate ux500-devicetree branch and split off the changes under arch/arm/boot/dts/* here. For example I have split the patch:
"drivers/gpio: gpio-nomadik: Apply Device Tree bindings"

Into one changing code and one changing the device tree itself. Else this won't be possible to keep separate topic branches, and we want that.

Then applied this on top.

I hope you're OK with this?

Refrain from attempting to free an interrupt line if the request fails and hence, there is no IRQ to free.

CC netdev at vger.kernel.org

Signed-off-by Lee Jones<[email protected]>

---
  drivers/net/ethernet/smsc/smsc911x.c |    3 +--
  1 files changed, 1 insertions(+), 2 deletions(-)

drivers/net/ethernet/smsc/smsc911x.c +0 -1

index 4a69710..f17a76e 100644
@@ -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);

Quoted 5 lines · Lee Jones

- ? ? ? ? ? ? ? goto out_free_irq;
+ ? ? ? ? ? ? ? goto out_disable_resources;
? ? ? ?}

? ? ? ?retval = register_netdev(dev);

Anything on this from the Net guys?

Quoted 6 lines · Lee Jones

Quoted 4 lines · Lee Jones

drivers/net/ethernet/smsc/smsc911x.c +1 -1

-               goto out_free_irq;
+               goto out_disable_resources;
        }

Quoted 4 lines

Quoted 1 line

        retval = register_netdev(dev);

Anything on this from the Net guys?

This was merged for 3.4-rc5, check:
https://lkml.org/lkml/2012/4/29/2

Linus, Can you please take 05 and 06 please, as some of the other patches depend on them. Thanks.

Quoted 2 lines

Linus, Can you please take 05 and 06 please, as some of the other patches depend on them. Thanks.

I think I've done that now and I'm planning a first pull request to ARM SoC to get the base into -next ASAP.

Looks like neither of these made it into Mainline, however subsequent patches which made changes to them did. This has caused some merge error, thus the code, especially in arch/arm/mach-ux500/cpu-db8500.c, but also in arch/arm/mach-ux500/board-mop500.c is quite wrong. :(

Enable the Ethernet port by providing correct information via DT.

Signed-off-by Lee Jones <[email protected]>

---
?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 +1 -2

index 0ba0955..22b82cc 100644
@@ -79,10 +79,16 @@
 ? ? ? ? ? ? ? ? ? ? ? ?ranges;
 
 ? ? ? ? ? ? ? ? ? ? ? ?ethernet at 50000000 {
- ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? compatible = "smsc,9111";
+ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? compatible = "smsc,lan9115";
 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?reg = <0x50000000 0x10000>;
- ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? interrupts = <12 0x4>;

From: Lee Jones <[email protected]>
Date: Tue, 24 Apr 2012 10:53:18 +0100
Subject: [PATCH 07.1/15] ARM: ux500: Enable the SMSC9115 on Snowball via Device Tree

Here 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.

Signed-off-by Lee Jones <[email protected]>

From: Lee Jones <[email protected]>
Date: Tue, 24 Apr 2012 10:54:25 +0100
Subject: [PATCH 7.2/15] ARM: ux500: Disable SMSC911x platform code registration when DT is enabled

Now the SCMC911x is correctly enabled in Device Tree, there is no need to continue registering it from platform code. In fact, if we continue doing so, the system will throw an error on boot.

Signed-off-by Lee Jones <[email protected]>

---
 arch/arm/mach-ux500/board-mop500.c |    1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

arch/arm/mach-ux500/board-mop500.c +0 -0

index 50809af..9dbd34b 100644

This version of the patch looks good, the version that was applied does not. (...)
Linus and Lee, what's going on here?

Quoted 3 lines · Arnd Bergmann

This version of the patch looks good, the version that was applied does not. (...)
Linus and Lee, what's going on here?

Probably just my screwups when applying Lee's patches out-of-order and splitting them.

I saw lee sent a new pull request with his baseline, throw the devcietree branch from me out and use his branch instead.

commit dc315c470b6b69018e6b65beb1e5b0d8f737261d

Author: Lee Jones <[email protected]>
Date:   Tue Apr 24 10:54:25 2012 +0100

ARM: ux500: Disable SMSC911x platform code registration when DT is enabled

Now the SCMC911x is correctly enabled in Device Tree, there is no need to continue registering it from platform code. In fact, if we continue doing so, the system will throw an error on boot.

SAcked-by Linus Walleij <[email protected]>

Signed-off-by Arnd Bergmann <[email protected]>

igned-off-by Lee Jones <[email protected]>

arch/arm/mach-ux500/board-mop500.c +0 -0

index cdf0ecf..d554a8b 100644

commit f58546a17c5dc2255c40e4bc4287e06a93b5c9a0

Author: Lee Jones <[email protected]>
Date:   Tue Apr 24 10:54:25 2012 +0100

ARM: ux500: Disable SMSC911x platform code registration when DT is enabled

Now the SCMC911x is correctly enabled in Device Tree, there is no need to continue registering it from platform code. In fact, if we continue doing so, the system will throw an error on boot.

Signed-off-by Lee Jones <[email protected]>

Signed-off-by Linus Walleij <[email protected]>

arch/arm/mach-ux500/board-mop500.c +0 -0

index b885f27..f815015 100644

On 03/05/12 18:14, Linus Walleij wrote:

In the pull request was:

Quoted 1 line

(quoted diff) +0 -0

@@ -612,7 +612,6 @@ static struct platform_device *snowball_platform_devs[] __initdata = {

But this made it into arm-soc:

Review static void __init mop500_uart_init(struct device *parent)

Quoted 1 line

(quoted diff) +0 -0

@@ -605,7 +605,6 @@ static void __init mop500_uart_init(struct device *parent)

Somehow the incorrect *_platform_devs[] was amended. Some kind of git automatic conflict resolution error?

Quoted 4 lines · Lee Jones

On 03/05/12 18:14, Linus Walleij wrote:

In the pull request was:

Quoted 1 line

(quoted diff) +0 -0

@@ -612,7 +612,6 @@ static struct platform_device *snowball_platform_devs[] __initdata = {

(...)

Quoted 2 lines

But this made it into arm-soc:

Review static void __init mop500_uart_init(struct device *parent)

Quoted 1 line

(quoted diff) +0 -0

@@ -605,7 +605,6 @@ static void __init mop500_uart_init(struct device *parent)

Two exactly identical arrays just on different line numbers, yeah...

Quoted 2 lines

Somehow the incorrect *_platform_devs[] was amended. Some kind of git automatic conflict resolution error?

Probably a patch -p1< foo.patch error, that's the kind of stuff it causes. My fault, certainly. The problem is that I don't see the problem with git diff, it looks correct there too.

I thought that my bad branch had been replaced with a different (correct) pull request from you though :-/

So how to we fix it? With an incremental patch on top?

Quoted 4 lines · Linus Walleij

Quoted 1 line · On Wed, May 16, 2012 at 9:12 AM, Lee Jones<[email protected]> ?wrote:

On 03/05/12 18:14, Linus Walleij wrote:

Two exactly identical arrays just on different line numbers, yeah...

Eh? Did you quote the wrong line?

Quoted 1 line

So how to we fix it? With an incremental patch on top?

I can provide you with a patch really quickly if that's the way you want to go.

Quoted 4 lines · Lee Jones

Quoted 3 lines · Linus Walleij

Quoted 1 line · Lee Jones

On 03/05/12 18:14, Linus Walleij wrote:

Quoted 3 lines

Quoted 1 line

Two exactly identical arrays just on different line numbers, yeah...

Eh? Did you quote the wrong line?

Maybe, anyway that was the problem, was it not? I'm ever more confused with this, maybe git is confused too :-)

static struct platform_device *snowball_of_platform_devs[] static struct platform_device *snowball_platform_devs[]

Quoted 4 lines

Quoted 1 line

So how to we fix it? With an incremental patch on top?

I can provide you with a patch really quickly if that's the way you want to go.

You can send it directly to ARM SoC maintainers I think, since that is where the problem sits right now. I'll just ACK it.

Quoted 3 lines · Arnd Bergmann

This version of the patch looks good, the version that was applied does not. (...)
Linus and Lee, what's going on here?

Probably just my screwups when applying Lee's patches out-of-order and splitting them.

I saw lee sent a new pull request with his baseline, throw the devcietree branch from me out and use his branch instead.

commit dc315c470b6b69018e6b65beb1e5b0d8f737261d

Author: Lee Jones <[email protected]>
Date:   Tue Apr 24 10:54:25 2012 +0100

ARM: ux500: Disable SMSC911x platform code registration when DT is enabled

Now the SCMC911x is correctly enabled in Device Tree, there is no need to continue registering it from platform code. In fact, if we continue doing so, the system will throw an error on boot.

SAcked-by Linus Walleij <[email protected]>

Signed-off-by Arnd Bergmann <[email protected]>

igned-off-by Lee Jones <[email protected]>

arch/arm/mach-ux500/board-mop500.c +0 -0

index cdf0ecf..d554a8b 100644

commit f58546a17c5dc2255c40e4bc4287e06a93b5c9a0

Author: Lee Jones <[email protected]>
Date:   Tue Apr 24 10:54:25 2012 +0100

ARM: ux500: Disable SMSC911x platform code registration when DT is enabled

Now the SCMC911x is correctly enabled in Device Tree, there is no need to continue registering it from platform code. In fact, if we continue doing so, the system will throw an error on boot.

Signed-off-by Lee Jones <[email protected]>

Signed-off-by Linus Walleij <[email protected]>

arch/arm/mach-ux500/board-mop500.c +0 -0

index b885f27..f815015 100644

From: Lee Jones<[email protected]>
Date: Tue, 24 Apr 2012 09:50:20 +0100
Subject: [PATCH 07/16] ARM: ux500: Enable the SMSC9115 on Snowball via Device Tree

Here 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.

Signed-off-by Lee Jones<[email protected]>

---
  arch/arm/boot/dts/snowball.dts |   10 ++++++++--
  1 files changed, 8 insertions(+), 2 deletions(-)

arch/arm/boot/dts/snowball.dts +8 -2

index 0ba0955..22b82cc 100644
@@ -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;
  			};
  		};
 

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]>

Quoted 4 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.

Quoted 1 line

Signed-off-by Lee Jones<[email protected]>

Acked-by Linus Walleij<[email protected]>

Why not squash this with the previous MMCI device tree patch and update it?

Quoted 2 lines · Linus Walleij

Why not squash this with the previous MMCI device tree patch and update it?

You mean the one I sent a couple of weeks ago?

I'd rather let that one sit in Russell's patch tracker and send this as an update, if it's all the same to you?

Here 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.

Signed-off-by Lee Jones <[email protected]>

Quoted 8 lines · Lee Jones

Here 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.

Quoted 1 line

Signed-off-by Lee Jones<[email protected]>

Can you please squash this into patch 7?

It seems like I get a bit more development history than I need here.

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.

Signed-off-by Lee Jones <[email protected]>

---
?.../devicetree/bindings/gpio/gpio-nmk.txt ? ? ? ? ?| ? ?2 ++ ?1 files changed, 2 insertions(+), 0 deletions(-)

Quoted 8 lines · Lee Jones

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.

Signed-off-by Lee Jones<[email protected]>

---
  .../devicetree/bindings/gpio/gpio-nmk.txt          |    2 ++
  1 files changed, 2 insertions(+), 0 deletions(-)

Thanks, applied to the ux500-devicetree branch.

I will likely have to update the subject of each and every patch on this branch to reflect the fact that it's just touching the device tree files per se.

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.

Signed-off-by Lee Jones <[email protected]>

Pass 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.

CC Samuel Ortiz <[email protected]>

Signed-off-by Lee Jones <[email protected]>

Quoted 4 lines · Lee Jones

Pass 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.

Quoted 2 lines

CC Samuel Ortiz<[email protected]>

Signed-off-by Lee Jones<[email protected]>

Acked-by Linus Walleij<[email protected]>

Alternatively, if you get Sam's ACK I can carry this in the ux500 tree.

Quoted 6 lines · Lee Jones

Pass 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.

CC Samuel Ortiz <[email protected]>

Signed-off-by Lee Jones <[email protected]>

Acked-by Linus Walleij <[email protected]>

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.

CC Samuel Ortiz <[email protected]>

Signed-off-by Lee Jones <[email protected]>

Quoted 6 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. We Also remove any initialisation completed in platform code to prevent any device duplication.

Quoted 2 lines

CC Samuel Ortiz<[email protected]>

Signed-off-by Lee Jones<[email protected]>

OK I need Sam's ACK on this too, then it seems a good idea to take all three patches touching the PRCMU driver through the ux500-core tree.

Quoted 6 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. We Also remove any initialisation completed in platform code to prevent any device duplication.

Quoted 2 lines

CC Samuel Ortiz <[email protected]>

Signed-off-by Lee Jones <[email protected]>

OK I need Sam's ACK on this too, then it seems a good idea to take all three patches touching the PRCMU driver through the ux500-core tree.

In 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.

CC Samuel Ortiz <[email protected]>

Signed-off-by Lee Jones <[email protected]>