Patchwork arm: kirkwood: convert NETGEAR ReadyNAS Duo v2 to use DT for the PCIe interface

login
register
mail settings
Submitter Arnaud Ebalard
Date May 28, 2013, 10:15 p.m.
Message ID <8738t6ycnm.fsf@natisbad.org>
Download mbox | patch
Permalink /patch/247049/
State New
Headers show

Comments

Arnaud Ebalard - May 28, 2013, 10:15 p.m.
Hi Jason and Thomas,

Thomas, I am following your work on PCIe support for a .dts file I am
working on for (Armada 370-based) Netgear ReadyNAS 102 and noticed your
set of patches to convert kirkwood-based boards to use it in order to
simplify/remove board specific code.

Jason, I gave your associated branch (jcooper/mvebu-next/pcie) a try
with following patch applied and can confirm USB 3.0 host controller
(connected to PCIe bus) is usable on Netgear ReadyNAS *Duo v2*
(88f6282-based brother of the 102).

Note that I had to s/of_pci_range_parser()/of_pci_range_parser_init()/
in drivers/pci/host/pci-mvebu.c to compile the kernel (this may already
have been fixed already):

CHK     kernel/config_data.h
drivers/pci/host/pci-mvebu.c: In function ‘mvebu_pcie_probe’:
drivers/pci/host/pci-mvebu.c:742:2: error: implicit declaration of function ‘of_pci_range_parser’ [-Werror=implicit-function-declaration]
cc1: some warnings being treated as errors
make[3]: *** [drivers/pci/host/pci-mvebu.o] Error 1
make[2]: *** [drivers/pci/host] Error 2
make[1]: *** [drivers/pci] Error 2
make[1]: *** Waiting for unfinished jobs....

Can one of you take the patch below into account? Or 

Cheers,

a+

Signed-off-by: Arnaud Ebalard <arno@natisbad.org>
---
 arch/arm/boot/dts/kirkwood-netgear_readynas_duo_v2.dts |    8 ++++++++
 arch/arm/mach-kirkwood/board-readynas.c                |    1 -
 2 files changed, 8 insertions(+), 1 deletion(-)
Thomas Petazzoni - May 28, 2013, 10:20 p.m.
Dear Arnaud Ebalard,

On Wed, 29 May 2013 00:15:09 +0200, Arnaud Ebalard wrote:

> Thomas, I am following your work on PCIe support for a .dts file I am
> working on for (Armada 370-based) Netgear ReadyNAS 102 and noticed your
> set of patches to convert kirkwood-based boards to use it in order to
> simplify/remove board specific code.

Nice!

> Jason, I gave your associated branch (jcooper/mvebu-next/pcie) a try
> with following patch applied and can confirm USB 3.0 host controller
> (connected to PCIe bus) is usable on Netgear ReadyNAS *Duo v2*
> (88f6282-based brother of the 102).
> 
> Note that I had to s/of_pci_range_parser()/of_pci_range_parser_init()/
> in drivers/pci/host/pci-mvebu.c to compile the kernel (this may already
> have been fixed already):
> 
> CHK     kernel/config_data.h
> drivers/pci/host/pci-mvebu.c: In function ‘mvebu_pcie_probe’:
> drivers/pci/host/pci-mvebu.c:742:2: error: implicit declaration of function ‘of_pci_range_parser’ [-Werror=implicit-function-declaration]
> cc1: some warnings being treated as errors

You're probably not using the latest mvebu/pcie branch from jcooper. In
his branch, I see:

+       if (of_pci_range_parser_init(&parser, np))
+               return -EINVAL;

Which should do the right thing.

Could you check that you're running on top of the latest
jcooper/mvebu/pcie branch? Thanks!

> Can one of you take the patch below into account? Or 

You should probably resend your patch with a proper description. Your
description now includes a lot information about unrelated things (the
Armada 370 board you're working on, the build failure you had, etc.).

Best regards,

Thomas
Jason - May 28, 2013, 10:38 p.m.
On Wed, May 29, 2013 at 12:20:53AM +0200, Thomas Petazzoni wrote:
> On Wed, 29 May 2013 00:15:09 +0200, Arnaud Ebalard wrote:
> > Jason, I gave your associated branch (jcooper/mvebu-next/pcie) a try
> > with following patch applied and can confirm USB 3.0 host controller
> > (connected to PCIe bus) is usable on Netgear ReadyNAS *Duo v2*
> > (88f6282-based brother of the 102).
> > 
> > Note that I had to s/of_pci_range_parser()/of_pci_range_parser_init()/
> > in drivers/pci/host/pci-mvebu.c to compile the kernel (this may already
> > have been fixed already):
> > 
> > CHK     kernel/config_data.h
> > drivers/pci/host/pci-mvebu.c: In function ‘mvebu_pcie_probe’:
> > drivers/pci/host/pci-mvebu.c:742:2: error: implicit declaration of function ‘of_pci_range_parser’ [-Werror=implicit-function-declaration]
> > cc1: some warnings being treated as errors
> 
> You're probably not using the latest mvebu/pcie branch from jcooper. In
> his branch, I see:
> 
> +       if (of_pci_range_parser_init(&parser, np))
> +               return -EINVAL;
> 
> Which should do the right thing.
> 
> Could you check that you're running on top of the latest
> jcooper/mvebu/pcie branch? Thanks!

Actually, you want jcooper/mvebu/pcie_kirkwood.  I split out the
kirkwood driver so that if it causes a build breakage and gets dropped,
mvebu/pcie can still go in.

> > Can one of you take the patch below into account? Or 
> 
> You should probably resend your patch with a proper description. Your
> description now includes a lot information about unrelated things (the
> Armada 370 board you're working on, the build failure you had, etc.).

That stuff can go below the '---' in the future.  Don't stress about it,
though.  I'll clean it up when I apply it if needed.

thx,

Jason.
Thomas Petazzoni - May 29, 2013, 7:42 a.m.
Dear Jason Cooper,

On Tue, 28 May 2013 18:38:17 -0400, Jason Cooper wrote:

> > Could you check that you're running on top of the latest
> > jcooper/mvebu/pcie branch? Thanks!
> 
> Actually, you want jcooper/mvebu/pcie_kirkwood.  I split out the
> kirkwood driver so that if it causes a build breakage and gets dropped,
> mvebu/pcie can still go in.

There's not really a "kirkwood" driver for PCIe. The pcie-kirkwood
stuff is really all about adding the right Device Tree informations,
and switching from a legacy-style probing to a DT-style probing.

That said, I definitely agree with the idea of having that as a
separate branch.

Best regards,

Thomas
Jason - May 29, 2013, 10:14 a.m.
On Wed, May 29, 2013 at 09:42:36AM +0200, Thomas Petazzoni wrote:
> On Tue, 28 May 2013 18:38:17 -0400, Jason Cooper wrote:
> 
> > > Could you check that you're running on top of the latest
> > > jcooper/mvebu/pcie branch? Thanks!
> > 
> > Actually, you want jcooper/mvebu/pcie_kirkwood.  I split out the
> > kirkwood driver so that if it causes a build breakage and gets dropped,
> > mvebu/pcie can still go in.
> 
> There's not really a "kirkwood" driver for PCIe. The pcie-kirkwood
> stuff is really all about adding the right Device Tree informations,
> and switching from a legacy-style probing to a DT-style probing.

Agreed.  Bad word choice on my part.  It was late/early, too much/too
little coffee. ;-)

You still need mvebu/pcie_kirkwood for:

  005625f pci: mvebu: enable driver usage on Kirkwood

thx,

Jason.

Patch

diff --git a/arch/arm/boot/dts/kirkwood-netgear_readynas_duo_v2.dts b/arch/arm/boot/dts/kirkwood-netgear_readynas_duo_v2.dts
index 1ca66ab..f9706da 100644
--- a/arch/arm/boot/dts/kirkwood-netgear_readynas_duo_v2.dts
+++ b/arch/arm/boot/dts/kirkwood-netgear_readynas_duo_v2.dts
@@ -111,6 +111,14 @@ 
 			status = "okay";
 			nr-ports = <2>;
 		};
+
+		pcie-controller {
+			status = "okay";
+
+			pcie@1,0 {
+				 status = "okay";
+			};
+		};
 	};
 
 	gpio-leds {
diff --git a/arch/arm/mach-kirkwood/board-readynas.c b/arch/arm/mach-kirkwood/board-readynas.c
index fb42c20..341b82d 100644
--- a/arch/arm/mach-kirkwood/board-readynas.c
+++ b/arch/arm/mach-kirkwood/board-readynas.c
@@ -24,5 +24,4 @@  static struct mv643xx_eth_platform_data netgear_readynas_ge00_data = {
 void __init netgear_readynas_init(void)
 {
 	kirkwood_ge00_init(&netgear_readynas_ge00_data);
-	kirkwood_pcie_init(KW_PCIE0);
 }