Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1444852 > unrolled thread

[PATCH v0 00/10] Convert Netgear WNR854T to devicetree

Back to article view | Back to linux.kernel

Contents

  [PATCH v0 00/10] Convert Netgear WNR854T to devicetree Jamie Lentin <jm@lentin.co.uk> - 2016-07-16 17:10 +0200
    [PATCH v0 09/10] net: phy: Re-attempt custom DT configuration after configuration Jamie Lentin <jm@lentin.co.uk> - 2016-07-16 17:10 +0200
      Re: [PATCH v0 09/10] net: phy: Re-attempt custom DT configuration  after configuration Andrew Lunn <andrew@lunn.ch> - 2016-07-16 18:50 +0200
    [PATCH v0 03/10] arm: orion5x: Add clk support for mv88f5181 Jamie Lentin <jm@lentin.co.uk> - 2016-07-16 17:10 +0200
      Re: [PATCH v0 03/10] arm: orion5x: Add clk support for mv88f5181 Andrew Lunn <andrew@lunn.ch> - 2016-07-16 18:20 +0200
      Re: [PATCH v0 03/10] arm: orion5x: Add clk support for mv88f5181 Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> - 2016-07-16 19:40 +0200
      Re: [PATCH v0 03/10] arm: orion5x: Add clk support for mv88f5181 Rob Herring <robh@kernel.org> - 2016-07-17 22:40 +0200
    [PATCH v0 01/10] arm: orion5x: Add required properties for orion-wdt to DT node Jamie Lentin <jm@lentin.co.uk> - 2016-07-16 17:10 +0200
      Re: [PATCH v0 01/10] arm: orion5x: Add required properties for  orion-wdt to DT node Andrew Lunn <andrew@lunn.ch> - 2016-07-16 18:10 +0200
    [PATCH v0 10/10] arm: orion5x: Configure Netgear WNR854T network port LEDs Jamie Lentin <jm@lentin.co.uk> - 2016-07-16 17:10 +0200
    [PATCH v0 06/10] arm: orion5x: Add DT-based support for Netgear WNR854T Jamie Lentin <jm@lentin.co.uk> - 2016-07-16 17:10 +0200
      Re: [PATCH v0 06/10] arm: orion5x: Add DT-based support for Netgear  WNR854T Andrew Lunn <andrew@lunn.ch> - 2016-07-16 18:40 +0200
      Re: [PATCH v0 06/10] arm: orion5x: Add DT-based support for Netgear  WNR854T Andrew Lunn <andrew@lunn.ch> - 2016-07-16 18:40 +0200
      Re: [PATCH v0 06/10] arm: orion5x: Add DT-based support for Netgear WNR854T Arnd Bergmann <arnd@arndb.de> - 2016-07-16 21:20 +0200
        Re: [PATCH v0 06/10] arm: orion5x: Add DT-based support for Netgear  WNR854T Jamie Lentin <jm@lentin.co.uk> - 2016-07-17 12:10 +0200
          Re: [PATCH v0 06/10] arm: orion5x: Add DT-based support for Netgear WNR854T Arnd Bergmann <arnd@arndb.de> - 2016-07-17 22:50 +0200
            Re: [PATCH v0 06/10] arm: orion5x: Add DT-based support for Netgear  WNR854T Thomas Petazzoni <thomas.petazzoni@free-electrons.com> - 2016-07-18 11:50 +0200
              Re: [PATCH v0 06/10] arm: orion5x: Add DT-based support for Netgear WNR854T Arnd Bergmann <arnd@arndb.de> - 2016-07-18 12:10 +0200
                Re: [PATCH v0 06/10] arm: orion5x: Add DT-based support for Netgear WNR854T Arnd Bergmann <arnd@arndb.de> - 2016-07-19 11:50 +0200
                Re: [PATCH v0 06/10] arm: orion5x: Add DT-based support for Netgear  WNR854T Jamie Lentin <jm@lentin.co.uk> - 2016-07-19 12:10 +0200
      Re: [PATCH v0 06/10] arm: orion5x: Add DT-based support for Netgear  WNR854T Rob Herring <robh@kernel.org> - 2016-07-17 23:00 +0200
        Re: [PATCH v0 06/10] arm: orion5x: Add DT-based support for Netgear  WNR854T Jamie Lentin <jm@lentin.co.uk> - 2016-07-19 11:50 +0200
    [PATCH v0 07/10] arm: orion5x: Remove old non-DT-based WNR854T support Jamie Lentin <jm@lentin.co.uk> - 2016-07-16 17:10 +0200
      Re: [PATCH v0 07/10] arm: orion5x: Remove old non-DT-based WNR854T  support Andrew Lunn <andrew@lunn.ch> - 2016-07-16 18:40 +0200
    [PATCH v0 04/10] arm: orion5x: Generalise mv88f5181l pinctrl support for 88f5181 Jamie Lentin <jm@lentin.co.uk> - 2016-07-16 17:10 +0200
      Re: [PATCH v0 04/10] arm: orion5x: Generalise mv88f5181l pinctrl  support for 88f5181 Andrew Lunn <andrew@lunn.ch> - 2016-07-16 18:20 +0200
      Re: [PATCH v0 04/10] arm: orion5x: Generalise mv88f5181l pinctrl  support for 88f5181 Rob Herring <robh@kernel.org> - 2016-07-17 22:50 +0200

Page 1 of 2  [1] 2  Next page →

#1444852 — [PATCH v0 00/10] Convert Netgear WNR854T to devicetree

This is an attempt to resurrect the mainline WNR854T support (I had no
luck getting a non-DT kernel to boot). First 2 patches are trivial,
the next 3 add DT bindings for the SoC, then the old board file is
swapped out for DT. The final 3 patches configure the PHY leds as
Netgear intended.

There's one major flaw; unicast traffic is never received on any port.
Broadcast traffic is received however, and on the correct port. Thus
an external machine can make an ARP request and get a response, for
example. With a manually-entered ARP entry, the router can send pings
out to a remote machine which responds, and the response is lost in the
DSA switch. "ethtool -S" reports pings received on "in_unicast" but
nothing makes it through the switch. This thread[0] seems very similar.
I've run out of ideas here and can't find any switch datasheets to give
me pointers so any suggestions greatly appreciated.

I've not tried to move the PCI support into DT yet. Are there other
branches that tackle this already?

Patch 8 is the least-intrusive patch I could think of to find the PHY
node, but I'm not sure it's the best approach. I tried to get
dsa_slave_phy_connect() to wire up the OF node correctly[1], but doing
this properly would require changes to the mdiobus api, any exposed
methods register all nodes in an MDIO bus node, which doesn't exist in
this case.

Applied against v4.6 mainline, .config:
http://jamie.lentin.co.uk/devices/netgear-wnr854t/wnr854t-support-v0a/kernel-config.txt
Log output:
http://jamie.lentin.co.uk/devices/netgear-wnr854t/wnr854t-support-v0a/u-boot.dmesg.txt

The patchset is also available here:
https://github.com/lentinj/linux/commits/wnr854t-support-v0a

To use the supplied PCI Wifi card see the following patch:
https://github.com/lentinj/linux/commit/d6b7b4695b7dcbf36d0663aea9cb4ecd65a1ada8
...but this is probably a matter for another thread.

Cheers,

[0] http://thread.gmane.org/gmane.linux.network/120616/focus=121320
[1] https://github.com/lentinj/linux/commit/a4bceebb08ecdc25a4d49e23f2abad214868460e

Jamie Lentin (10):
  arm: orion5x: Add required properties for orion-wdt to DT node
  arm: orion5x: Add documentation for SoC and board bindings
  arm: orion5x: Add clk support for mv88f5181
  arm: orion5x: Generalise mv88f5181l pinctrl support for 88f5181
  arm: orion5x: Add DT include for mv88f5181
  arm: orion5x: Add DT-based support for Netgear WNR854T
  arm: orion5x: Remove old non-DT-based WNR854T support
  net: phy: Try looking for a phy-handle property to find the OF node
  net: phy: Re-attempt custom DT configuration after configuration
  arm: orion5x: Configure Netgear WNR854T network port LEDs

 .../bindings/arm/marvell/marvell,orion5x.txt       |  25 +++
 .../devicetree/bindings/clock/mvebu-core-clock.txt |   1 +
 .../bindings/pinctrl/marvell,orion-pinctrl.txt     |   4 +-
 arch/arm/boot/dts/Makefile                         |   1 +
 arch/arm/boot/dts/orion5x-mv88f5181.dtsi           |  35 +++
 arch/arm/boot/dts/orion5x-netgear-wnr854t.dts      | 245 +++++++++++++++++++++
 arch/arm/boot/dts/orion5x.dtsi                     |   3 +-
 arch/arm/mach-orion5x/Kconfig                      |   6 +
 arch/arm/mach-orion5x/Makefile                     |   2 +-
 arch/arm/mach-orion5x/board-wnr854t.c              |  78 +++++++
 arch/arm/mach-orion5x/wnr854t-setup.c              | 185 ----------------
 drivers/clk/mvebu/orion.c                          |  70 ++++++
 drivers/net/phy/marvell.c                          |  26 ++-
 drivers/pinctrl/mvebu/pinctrl-orion.c              |  23 +-
 14 files changed, 498 insertions(+), 206 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/marvell/marvell,orion5x.txt
 create mode 100644 arch/arm/boot/dts/orion5x-mv88f5181.dtsi
 create mode 100644 arch/arm/boot/dts/orion5x-netgear-wnr854t.dts
 create mode 100644 arch/arm/mach-orion5x/board-wnr854t.c
 delete mode 100644 arch/arm/mach-orion5x/wnr854t-setup.c

-- 
2.8.1

[toc] | [next] | [standalone]

#1444853 — [PATCH v0 09/10] net: phy: Re-attempt custom DT configuration after configuration

marvell,reg-init is generally used to apply a custom LED configuration
on boot. However this is then blatted in m88e1121_config_aneg when the
interface is brought up. Re-apply any custom configuration afterwards,
to keep custom LED configuration.

Signed-off-by: Jamie Lentin <jm@lentin.co.uk>
---
 drivers/net/phy/marvell.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
index c2ca347..b55e4e0 100644
--- a/drivers/net/phy/marvell.c
+++ b/drivers/net/phy/marvell.c
@@ -424,6 +424,10 @@ static int m88e1121_config_aneg(struct phy_device *phydev)
 	phy_write(phydev, MII_MARVELL_PHY_PAGE, oldpage);
 
 	err = genphy_config_aneg(phydev);
+	if (err < 0)
+		return err;
+
+	err = marvell_of_reg_init(phydev);
 
 	return err;
 }
-- 
2.8.1

[toc] | [prev] | [next] | [standalone]

#1444887 — Re: [PATCH v0 09/10] net: phy: Re-attempt custom DT configuration after configuration

On Sat, Jul 16, 2016 at 03:29:07PM +0100, Jamie Lentin wrote:
> marvell,reg-init is generally used to apply a custom LED configuration
> on boot. However this is then blatted in m88e1121_config_aneg when the
> interface is brought up. Re-apply any custom configuration afterwards,
> to keep custom LED configuration.

This has been fixed in net-next.

     Andrew

[toc] | [prev] | [next] | [standalone]

#1444855 — [PATCH v0 03/10] arm: orion5x: Add clk support for mv88f5181

Referring to values in the u-boot port, add support for the mv88f5181

Signed-off-by: Jamie Lentin <jm@lentin.co.uk>
---
 .../devicetree/bindings/clock/mvebu-core-clock.txt |  1 +
 drivers/clk/mvebu/orion.c                          | 70 ++++++++++++++++++++++
 2 files changed, 71 insertions(+)

diff --git a/Documentation/devicetree/bindings/clock/mvebu-core-clock.txt b/Documentation/devicetree/bindings/clock/mvebu-core-clock.txt
index 670c2af..eb985a6 100644
--- a/Documentation/devicetree/bindings/clock/mvebu-core-clock.txt
+++ b/Documentation/devicetree/bindings/clock/mvebu-core-clock.txt
@@ -52,6 +52,7 @@ Required properties:
 	"marvell,dove-core-clock" - for Dove SoC core clocks
 	"marvell,kirkwood-core-clock" - for Kirkwood SoC (except mv88f6180)
 	"marvell,mv88f6180-core-clock" - for Kirkwood MV88f6180 SoC
+	"marvell,mv88f5181-core-clock" - for Orion MV88F5181 SoC
 	"marvell,mv88f5182-core-clock" - for Orion MV88F5182 SoC
 	"marvell,mv88f5281-core-clock" - for Orion MV88F5281 SoC
 	"marvell,mv88f6183-core-clock" - for Orion MV88F6183 SoC
diff --git a/drivers/clk/mvebu/orion.c b/drivers/clk/mvebu/orion.c
index fd12956..a6e5bee 100644
--- a/drivers/clk/mvebu/orion.c
+++ b/drivers/clk/mvebu/orion.c
@@ -21,6 +21,76 @@ static const struct coreclk_ratio orion_coreclk_ratios[] __initconst = {
 };
 
 /*
+ * Orion 5181
+ */
+
+#define SAR_MV88F5181_TCLK_FREQ      8
+#define SAR_MV88F5181_TCLK_FREQ_MASK 0x3
+
+static u32 __init mv88f5181_get_tclk_freq(void __iomem *sar)
+{
+	u32 opt = (readl(sar) >> SAR_MV88F5181_TCLK_FREQ) &
+		SAR_MV88F5181_TCLK_FREQ_MASK;
+	if (opt == 0)
+		return 133333333;
+	else if (opt == 1)
+		return 150000000;
+	else if (opt == 2)
+		return 166666667;
+	else
+		return 0;
+}
+
+#define SAR_MV88F5181_CPU_FREQ       4
+#define SAR_MV88F5181_CPU_FREQ_MASK  0xf
+
+static u32 __init mv88f5181_get_cpu_freq(void __iomem *sar)
+{
+	u32 opt = (readl(sar) >> SAR_MV88F5181_CPU_FREQ) &
+		SAR_MV88F5181_CPU_FREQ_MASK;
+	if (opt == 0)
+		return 333333333;
+	else if (opt == 1 || opt == 2)
+		return 400000000;
+	else if (opt == 3)
+		return 500000000;
+	else
+		return 0;
+}
+
+static void __init mv88f5181_get_clk_ratio(void __iomem *sar, int id,
+					   int *mult, int *div)
+{
+	u32 opt = (readl(sar) >> SAR_MV88F5181_CPU_FREQ) &
+		SAR_MV88F5181_CPU_FREQ_MASK;
+	if (opt == 0 || opt == 1) {
+		*mult = 1;
+		*div  = 2;
+	} else if (opt == 2 || opt == 3) {
+		*mult = 1;
+		*div  = 3;
+	} else {
+		*mult = 0;
+		*div  = 1;
+	}
+}
+
+static const struct coreclk_soc_desc mv88f5181_coreclks = {
+	.get_tclk_freq = mv88f5181_get_tclk_freq,
+	.get_cpu_freq = mv88f5181_get_cpu_freq,
+	.get_clk_ratio = mv88f5181_get_clk_ratio,
+	.ratios = orion_coreclk_ratios,
+	.num_ratios = ARRAY_SIZE(orion_coreclk_ratios),
+};
+
+static void __init mv88f5181_clk_init(struct device_node *np)
+{
+	return mvebu_coreclk_setup(np, &mv88f5181_coreclks);
+}
+
+CLK_OF_DECLARE(mv88f5181_clk, "marvell,mv88f5181-core-clock", mv88f5181_clk_init);
+
+/*
  * Orion 5182
  */
 
-- 
2.8.1

[toc] | [prev] | [next] | [standalone]

#1444879 — Re: [PATCH v0 03/10] arm: orion5x: Add clk support for mv88f5181

On Sat, Jul 16, 2016 at 03:29:01PM +0100, Jamie Lentin wrote:
> Referring to values in the u-boot port, add support for the mv88f5181
> 
> Signed-off-by: Jamie Lentin <jm@lentin.co.uk>

Reviewed-by: Andrew Lunn <andrew@lunn.ch>

    Andrew

[toc] | [prev] | [next] | [standalone]

#1444893 — Re: [PATCH v0 03/10] arm: orion5x: Add clk support for mv88f5181

Hello.

On 7/16/2016 5:29 PM, Jamie Lentin wrote:

> Referring to values in the u-boot port, add support for the mv88f5181
>
> Signed-off-by: Jamie Lentin <jm@lentin.co.uk>

[...]
> diff --git a/drivers/clk/mvebu/orion.c b/drivers/clk/mvebu/orion.c
> index fd12956..a6e5bee 100644
> --- a/drivers/clk/mvebu/orion.c
> +++ b/drivers/clk/mvebu/orion.c
> @@ -21,6 +21,76 @@ static const struct coreclk_ratio orion_coreclk_ratios[] __initconst = {
>  };
>
>  /*
> + * Orion 5181
> + */
> +
> +#define SAR_MV88F5181_TCLK_FREQ      8
> +#define SAR_MV88F5181_TCLK_FREQ_MASK 0x3
> +
> +static u32 __init mv88f5181_get_tclk_freq(void __iomem *sar)
> +{
> +	u32 opt = (readl(sar) >> SAR_MV88F5181_TCLK_FREQ) &
> +		SAR_MV88F5181_TCLK_FREQ_MASK;
> +	if (opt == 0)
> +		return 133333333;
> +	else if (opt == 1)
> +		return 150000000;
> +	else if (opt == 2)
> +		return 166666667;

    Do you know about the *switch* statement? :-)

> +	else
> +		return 0;
> +}
> +
> +#define SAR_MV88F5181_CPU_FREQ       4
> +#define SAR_MV88F5181_CPU_FREQ_MASK  0xf
> +
> +static u32 __init mv88f5181_get_cpu_freq(void __iomem *sar)
> +{
> +	u32 opt = (readl(sar) >> SAR_MV88F5181_CPU_FREQ) &
> +		SAR_MV88F5181_CPU_FREQ_MASK;
> +	if (opt == 0)
> +		return 333333333;
> +	else if (opt == 1 || opt == 2)
> +		return 400000000;
> +	else if (opt == 3)
> +		return 500000000;

    Asks to be a *switch* as well...

> +	else
> +		return 0;
> +}
> +
> +static void __init mv88f5181_get_clk_ratio(void __iomem *sar, int id,
> +					   int *mult, int *div)
> +{
> +	u32 opt = (readl(sar) >> SAR_MV88F5181_CPU_FREQ) &
> +		SAR_MV88F5181_CPU_FREQ_MASK;
> +	if (opt == 0 || opt == 1) {
> +		*mult = 1;
> +		*div  = 2;
> +	} else if (opt == 2 || opt == 3) {
> +		*mult = 1;
> +		*div  = 3;
> +	} else {
> +		*mult = 0;
> +		*div  = 1;
> +	}

     This one too...

[...]

MBR, Sergei

[toc] | [prev] | [next] | [standalone]

#1445116 — Re: [PATCH v0 03/10] arm: orion5x: Add clk support for mv88f5181

On Sat, Jul 16, 2016 at 03:29:01PM +0100, Jamie Lentin wrote:
> Referring to values in the u-boot port, add support for the mv88f5181
> 
> Signed-off-by: Jamie Lentin <jm@lentin.co.uk>
> ---
>  .../devicetree/bindings/clock/mvebu-core-clock.txt |  1 +

Acked-by: Rob Herring <robh@kernel.org>

>  drivers/clk/mvebu/orion.c                          | 70 ++++++++++++++++++++++
>  2 files changed, 71 insertions(+)

[toc] | [prev] | [next] | [standalone]

#1444858 — [PATCH v0 01/10] arm: orion5x: Add required properties for orion-wdt to DT node

orion-wdt refuses to start without these properties defined, so lift
definitions out of kirkwood/dove.dtsi

Signed-off-by: Jamie Lentin <jm@lentin.co.uk>
---
 arch/arm/boot/dts/orion5x.dtsi | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/orion5x.dtsi b/arch/arm/boot/dts/orion5x.dtsi
index e1b6d2a..fbccfbb 100644
--- a/arch/arm/boot/dts/orion5x.dtsi
+++ b/arch/arm/boot/dts/orion5x.dtsi
@@ -144,9 +144,10 @@
 
 			wdt: wdt@20300 {
 				compatible = "marvell,orion-wdt";
-				reg = <0x20300 0x28>;
+				reg = <0x20300 0x28>, <0x20108 0x4>;
 				interrupt-parent = <&bridge_intc>;
 				interrupts = <3>;
+				clocks = <&core_clk 0>;
 				status = "okay";
 			};
 
-- 
2.8.1

[toc] | [prev] | [next] | [standalone]

#1444872 — Re: [PATCH v0 01/10] arm: orion5x: Add required properties for orion-wdt to DT node

On Sat, Jul 16, 2016 at 03:28:59PM +0100, Jamie Lentin wrote:
> orion-wdt refuses to start without these properties defined, so lift
> definitions out of kirkwood/dove.dtsi
> 
> Signed-off-by: Jamie Lentin <jm@lentin.co.uk>

Reviewed-by: Andrew Lunn <andrew@lunn.ch>

    Andrew


> ---
>  arch/arm/boot/dts/orion5x.dtsi | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/boot/dts/orion5x.dtsi b/arch/arm/boot/dts/orion5x.dtsi
> index e1b6d2a..fbccfbb 100644
> --- a/arch/arm/boot/dts/orion5x.dtsi
> +++ b/arch/arm/boot/dts/orion5x.dtsi
> @@ -144,9 +144,10 @@
>  
>  			wdt: wdt@20300 {
>  				compatible = "marvell,orion-wdt";
> -				reg = <0x20300 0x28>;
> +				reg = <0x20300 0x28>, <0x20108 0x4>;
>  				interrupt-parent = <&bridge_intc>;
>  				interrupts = <3>;
> +				clocks = <&core_clk 0>;
>  				status = "okay";
>  			};
>  
> -- 
> 2.8.1
> 

[toc] | [prev] | [next] | [standalone]

#1444859 — [PATCH v0 10/10] arm: orion5x: Configure Netgear WNR854T network port LEDs

The default bootloader leaves the LEDs orange, and the 88E1121R driver
applies it's own inappropriate configuration. Configure as per manual,
i.e. orange = 100 / green = 1000 / blink = activity

Signed-off-by: Jamie Lentin <jm@lentin.co.uk>
---
 arch/arm/boot/dts/orion5x-netgear-wnr854t.dts | 45 +++++++++++++++++++++++++++
 1 file changed, 45 insertions(+)

diff --git a/arch/arm/boot/dts/orion5x-netgear-wnr854t.dts b/arch/arm/boot/dts/orion5x-netgear-wnr854t.dts
index a8e89d8..635b396 100644
--- a/arch/arm/boot/dts/orion5x-netgear-wnr854t.dts
+++ b/arch/arm/boot/dts/orion5x-netgear-wnr854t.dts
@@ -81,16 +81,19 @@
 			port@0 {
 				reg = <0>;
 				label = "lan3";
+				phy-handle = <&lan3phy>;
 			};
 
 			port@1 {
 				reg = <1>;
 				label = "lan4";
+				phy-handle = <&lan4phy>;
 			};
 
 			port@2 {
 				reg = <2>;
 				label = "wan";
+				phy-handle = <&wanphy>;
 			};
 
 			port@3 {
@@ -101,11 +104,13 @@
 			port@5 {
 				reg = <5>;
 				label = "lan1";
+				phy-handle = <&lan1phy>;
 			};
 
 			port@7 {
 				reg = <7>;
 				label = "lan2";
+				phy-handle = <&lan2phy>;
 			};
 		};
 	};
@@ -148,6 +153,46 @@
 
 &mdio {
 	status = "okay";
+
+	lan3phy: ethernet-phy@0 {
+		/* Marvell 88E1121R (port 1) */
+		compatible = "ethernet-phy-id0141.0cb0",
+			     "ethernet-phy-ieee802.3-c22";
+		reg = <0>;
+		marvell,reg-init = <3 16 0 0x1777 3 17 0 0x15>;
+	};
+
+	lan4phy: ethernet-phy@1 {
+		/* Marvell 88E1121R (port 2) */
+		compatible = "ethernet-phy-id0141.0cb0",
+			     "ethernet-phy-ieee802.3-c22";
+		reg = <1>;
+		marvell,reg-init = <3 16 0 0x1777 3 17 0 0x15>;
+	};
+
+	wanphy: ethernet-phy@2 {
+		/* Marvell 88E1121R (port 1) */
+		compatible = "ethernet-phy-id0141.0cb0",
+			     "ethernet-phy-ieee802.3-c22";
+		reg = <2>;
+		marvell,reg-init = <3 16 0 0x1777 3 17 0 0x15>;
+	};
+
+	lan1phy: ethernet-phy@5 {
+		/* Marvell 88E1112 */
+		compatible = "ethernet-phy-id0141.0cb0",
+			     "ethernet-phy-ieee802.3-c22";
+		reg = <5>;
+		marvell,reg-init = <3 16 0 0x1777 3 17 0 0x15>;
+	};
+
+	lan2phy: ethernet-phy@7 {
+		/* Marvell 88E1112 */
+		compatible = "ethernet-phy-id0141.0cb0",
+			     "ethernet-phy-ieee802.3-c22";
+		reg = <7>;
+		marvell,reg-init = <3 16 0 0x1777 3 17 0 0x15>;
+	};
 };
 
 &eth {
-- 
2.8.1

[toc] | [prev] | [next] | [standalone]

#1444860 — [PATCH v0 06/10] arm: orion5x: Add DT-based support for Netgear WNR854T

This is a router based on the mv88f5181 chipset.

http://www.netgear.com/support/product/WNR854T.aspx
http://wiki.openwrt.org/toh/netgear/wnr854t

Signed-off-by: Jamie Lentin <jm@lentin.co.uk>
---
 .../bindings/arm/marvell/marvell,orion5x.txt       |   1 +
 arch/arm/boot/dts/Makefile                         |   1 +
 arch/arm/boot/dts/orion5x-netgear-wnr854t.dts      | 200 +++++++++++++++++++++
 arch/arm/mach-orion5x/Kconfig                      |   6 +
 arch/arm/mach-orion5x/Makefile                     |   1 +
 arch/arm/mach-orion5x/board-wnr854t.c              |  78 ++++++++
 6 files changed, 287 insertions(+)
 create mode 100644 arch/arm/boot/dts/orion5x-netgear-wnr854t.dts
 create mode 100644 arch/arm/mach-orion5x/board-wnr854t.c

diff --git a/Documentation/devicetree/bindings/arm/marvell/marvell,orion5x.txt b/Documentation/devicetree/bindings/arm/marvell/marvell,orion5x.txt
index ff3c120..748a8f2 100644
--- a/Documentation/devicetree/bindings/arm/marvell/marvell,orion5x.txt
+++ b/Documentation/devicetree/bindings/arm/marvell/marvell,orion5x.txt
@@ -22,3 +22,4 @@ board. Currently known boards are:
 "lacie,d2-network"
 "marvell,rd-88f5182-nas"
 "maxtor,shared-storage-2"
+"netgear,wnr854t"
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 95c1923..63b9202 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -535,6 +535,7 @@ dtb-$(CONFIG_ARCH_ORION5X) += \
 	orion5x-linkstation-lswtgl.dtb \
 	orion5x-lswsgl.dtb \
 	orion5x-maxtor-shared-storage-2.dtb \
+	orion5x-netgear-wnr854t.dtb \
 	orion5x-rd88f5182-nas.dtb
 dtb-$(CONFIG_ARCH_PRIMA2) += \
 	prima2-evb.dtb
diff --git a/arch/arm/boot/dts/orion5x-netgear-wnr854t.dts b/arch/arm/boot/dts/orion5x-netgear-wnr854t.dts
new file mode 100644
index 0000000..a8e89d8
--- /dev/null
+++ b/arch/arm/boot/dts/orion5x-netgear-wnr854t.dts
@@ -0,0 +1,200 @@
+/*
+ * Copyright (C) 2014 Jamie Lentin <jm@lentin.co.uk>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+#include "orion5x-mv88f5181.dtsi"
+
+/ {
+	model = "Netgear WNR854-t";
+	compatible = "netgear,wnr854t", "marvell,orion5x-88f5181",
+			"marvell,orion5x";
+
+	memory {
+		reg = <0x00000000 0x2000000>; /* 32 MB */
+	};
+
+	chosen {
+		bootargs = "console=ttyS0,115200n8 earlyprintk";
+		linux,stdout-path = &uart0;
+	};
+
+	soc {
+		ranges = <MBUS_ID(0xf0, 0x01) 0 0xf1000000 0x100000>,
+			<MBUS_ID(0x09, 0x00) 0 0xf2200000 0x800>,
+			<MBUS_ID(0x01, 0x0f) 0 0xf4000000 0x800000>;
+	};
+
+	gpio-keys {
+		compatible = "gpio-keys";
+		pinctrl-0 = <&pmx_reset_switch>;
+		pinctrl-names = "default";
+
+		reset {
+			label = "Reset Button";
+			linux,code = <KEY_RESTART>;
+			gpios = <&gpio0 1 GPIO_ACTIVE_LOW>;
+		};
+	};
+
+	gpio-leds {
+		compatible = "gpio-leds";
+		pinctrl-0 = <&pmx_power_led &pmx_power_led_blink &pmx_wan_led>;
+		pinctrl-names = "default";
+
+		led@0 {
+			label = "power:green";
+			gpios = <&gpio0 0 GPIO_ACTIVE_LOW>;
+		};
+
+		led@1 {
+			label = "power:blink";
+			gpios = <&gpio0 2 GPIO_ACTIVE_LOW>;
+		};
+
+		led@2 {
+			label = "wan:green";
+			gpios = <&gpio0 3 GPIO_ACTIVE_LOW>;
+		};
+	};
+
+	dsa@0 {
+		compatible = "marvell,dsa";
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		dsa,ethernet = <&ethport>;
+		dsa,mii-bus = <&mdio>;
+
+		switch@0 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0 0>;	/* MDIO address 0, switch 0 in tree */
+
+			port@0 {
+				reg = <0>;
+				label = "lan3";
+			};
+
+			port@1 {
+				reg = <1>;
+				label = "lan4";
+			};
+
+			port@2 {
+				reg = <2>;
+				label = "wan";
+			};
+
+			port@3 {
+				reg = <3>;
+				label = "cpu";
+			};
+
+			port@5 {
+				reg = <5>;
+				label = "lan1";
+			};
+
+			port@7 {
+				reg = <7>;
+				label = "lan2";
+			};
+		};
+	};
+};
+
+&devbus_bootcs {
+	status = "okay";
+
+	devbus,keep-config;
+
+	flash@0 {
+		compatible = "cfi-flash";
+		reg = <0 0x800000>;
+		bank-width = <1>;
+		#address-cells = <1>;
+		#size-cells = <1>;
+
+		partition@0 {
+			label = "kernel";
+			reg = <0x0 0x100000>;
+		};
+
+		partition@100000 {
+			label = "rootfs";
+			reg = <0x100000 0x660000>;
+		};
+
+		partition@760000 {
+			label = "uboot_env";
+			reg = <0x760000 0x20000>;
+		};
+
+		partition@780000 {
+			label = "uboot";
+			reg = <0x780000 0x80000>;
+			read-only;
+		};
+	};
+};
+
+&mdio {
+	status = "okay";
+};
+
+&eth {
+	status = "okay";
+	ethernet-port@0 {
+		speed = <1000>;
+		duplex = <1>;
+	};
+};
+
+&pinctrl {
+	pinctrl-0 = <&pmx_pci_gpios &pmx_ge>;
+	pinctrl-names = "default";
+
+	pmx_power_led: pmx-power-led {
+		marvell,pins = "mpp0";
+		marvell,function = "gpio";
+	};
+
+	pmx_reset_switch: pmx-reset-switch {
+		marvell,pins = "mpp1";
+		marvell,function = "gpio";
+	};
+
+	pmx_power_led_blink: pmx-power-led-blink {
+		marvell,pins = "mpp2";
+		marvell,function = "gpio";
+	};
+
+	pmx_wan_led: pmx-wan-led {
+		marvell,pins = "mpp3";
+		marvell,function = "gpio";
+	};
+
+	pmx_pci_gpios: pmx-pci-gpios {
+		marvell,pins = "mpp4";
+		marvell,function = "gpio";
+	};
+
+	pmx_ge: pmx-ge {
+		marvell,pins = "mpp9", "mpp12",	"mpp13", "mpp14", "mpp15",
+				"mpp16", "mpp17", "mpp18", "mpp19";
+		marvell,function = "ge";
+	};
+};
+
+&uart0 {
+	/* Pin 1: Tx, Pin 7: Rx, Pin 8: Gnd */
+	status = "okay";
+};
diff --git a/arch/arm/mach-orion5x/Kconfig b/arch/arm/mach-orion5x/Kconfig
index a2af158..1fdb95d 100644
--- a/arch/arm/mach-orion5x/Kconfig
+++ b/arch/arm/mach-orion5x/Kconfig
@@ -151,6 +151,12 @@ config MACH_MSS2_DT
 	  Say 'Y' here if you want your kernel to support the
 	  Maxtor Shared Storage II platform.
 
+config MACH_WNR854T_DT
+	bool "Netgear WNR854T (Flattened Device Tree)"
+	help
+	  Say 'Y' here if you want your kernel to support the
+	  Netgear WNR854T platform.
+
 config MACH_WNR854T
 	bool "Netgear WNR854T"
 	help
diff --git a/arch/arm/mach-orion5x/Makefile b/arch/arm/mach-orion5x/Makefile
index 4b2502b..9dff2d3 100644
--- a/arch/arm/mach-orion5x/Makefile
+++ b/arch/arm/mach-orion5x/Makefile
@@ -24,3 +24,4 @@ obj-$(CONFIG_ARCH_ORION5X_DT)		+= board-dt.o
 obj-$(CONFIG_MACH_D2NET_DT)	+= board-d2net.o
 obj-$(CONFIG_MACH_MSS2_DT)	+= board-mss2.o
 obj-$(CONFIG_MACH_RD88F5182_DT)	+= board-rd88f5182.o
+obj-$(CONFIG_MACH_WNR854T_DT)	+= board-wnr854t.o
diff --git a/arch/arm/mach-orion5x/board-wnr854t.c b/arch/arm/mach-orion5x/board-wnr854t.c
new file mode 100644
index 0000000..c506e33
--- /dev/null
+++ b/arch/arm/mach-orion5x/board-wnr854t.c
@@ -0,0 +1,78 @@
+/*
+ * Netgear WNR854T PCI setup
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+#include <linux/gpio.h>
+#include <linux/platform_device.h>
+#include <linux/pci.h>
+#include <asm/mach/pci.h>
+#include "common.h"
+#include "orion5x.h"
+
+#define WNR854T_PCI_SLOT0_OFFS	7
+#define WNR854T_PCI_SLOT0_IRQ_PIN	4
+
+static void __init wnr854t_pci_preinit(void)
+{
+	int pin;
+
+	/*
+	 * Configure PCI GPIO IRQ pins
+	 */
+	pin = WNR854T_PCI_SLOT0_IRQ_PIN;
+	if (gpio_request(pin, "PCI Int") == 0) {
+		if (gpio_direction_input(pin) == 0) {
+			irq_set_irq_type(gpio_to_irq(pin), IRQ_TYPE_LEVEL_LOW);
+		} else {
+			pr_err("wnr854t_pci_preinit failed to set_irq_type pin %d\n",
+				pin);
+			gpio_free(pin);
+		}
+	} else {
+		pr_err("wnr854t_pci_preinit failed to request gpio %d\n", pin);
+	}
+}
+
+static int __init wnr854t_pci_map_irq(const struct pci_dev *dev, u8 slot,
+	u8 pin)
+{
+	int irq;
+
+	/*
+	 * Check for devices with hard-wired IRQs.
+	 */
+	irq = orion5x_pci_map_irq(dev, slot, pin);
+	if (irq != -1)
+		return irq;
+
+	/*
+	 * PCI IRQs are connected via GPIOs
+	 */
+	switch (slot - WNR854T_PCI_SLOT0_OFFS) {
+	case 0:
+		return gpio_to_irq(WNR854T_PCI_SLOT0_IRQ_PIN);
+	default:
+		return -1;
+	}
+}
+
+static struct hw_pci wnr854t_pci __initdata = {
+	.nr_controllers	= 2,
+	.preinit	= wnr854t_pci_preinit,
+	.setup		= orion5x_pci_sys_setup,
+	.scan		= orion5x_pci_sys_scan_bus,
+	.map_irq	= wnr854t_pci_map_irq,
+};
+
+static int __init wnr854t_pci_init(void)
+{
+	if (of_machine_is_compatible("netgear,wnr854t"))
+		pci_common_init(&wnr854t_pci);
+
+	return 0;
+}
+/* NB: Use late_initcall so we can gpio_request() without being deferred */
+late_initcall(wnr854t_pci_init);
-- 
2.8.1

[toc] | [prev] | [next] | [standalone]

#1444882 — Re: [PATCH v0 06/10] arm: orion5x: Add DT-based support for Netgear WNR854T

> +	pmx_reset_switch: pmx-reset-switch {
> +		marvell,pins = "mpp1";
> +		marvell,function = "gpio";
> +	};

Ah! I think i interpreted that wrong. This does not reset the Ethernet
switch. It is actually a switch on the front to reset the whole box?

How about calling it button, not switch?

    Andrew

[toc] | [prev] | [next] | [standalone]

#1444885 — Re: [PATCH v0 06/10] arm: orion5x: Add DT-based support for Netgear WNR854T

> +	chosen {
> +		bootargs = "console=ttyS0,115200n8 earlyprintk";
> +		linux,stdout-path = &uart0;
> +	};

You can put the board rate etc in the stdout-patch. Something like:

                stdout-path = "serial0:115200n8";

> +	gpio-leds {
> +		compatible = "gpio-leds";
> +		pinctrl-0 = <&pmx_power_led &pmx_power_led_blink &pmx_wan_led>;
> +		pinctrl-names = "default";
> +
> +		led@0 {
> +			label = "power:green";

Documentation/leds/leds-class.txt says:

LED Device Naming
=================

Is currently of the form:

"devicename:colour:function"

> +	dsa@0 {
> +		compatible = "marvell,dsa";
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +
> +		dsa,ethernet = <&ethport>;
> +		dsa,mii-bus = <&mdio>;
> +
> +		switch@0 {
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +			reg = <0 0>;	/* MDIO address 0, switch 0 in tree */
> +
> +			port@0 {
> +				reg = <0>;
> +				label = "lan3";
> +			};
> +
> +			port@1 {
> +				reg = <1>;
> +				label = "lan4";
> +			};
> +
> +			port@2 {
> +				reg = <2>;
> +				label = "wan";
> +			};
> +
> +			port@3 {
> +				reg = <3>;
> +				label = "cpu";
> +			};
> +
> +			port@5 {
> +				reg = <5>;
> +				label = "lan1";
> +			};
> +
> +			port@7 {
> +				reg = <7>;
> +				label = "lan2";
> +			};
> +		};
> +	};
> +};

This all looks sensible, if a bit mixed up. Lets discuss the switch
issue in a different thread.

> +&devbus_bootcs {
> +	status = "okay";
> +
> +	devbus,keep-config;
> +
> +	flash@0 {
> +		compatible = "cfi-flash";
> +		reg = <0 0x800000>;
> +		bank-width = <1>;
> +		#address-cells = <1>;
> +		#size-cells = <1>;

Documentation/devicetree/bindings/mtd/partition.txt says the
partitions should be placed under a partitions node. There are some
conditions when that does not work. So please try it, and if it does
not, ignore my comment...

> +
> +		partition@0 {
> +			label = "kernel";
> +			reg = <0x0 0x100000>;
> +		};
> +
> +		partition@100000 {
> +			label = "rootfs";
> +			reg = <0x100000 0x660000>;
> +		};
> +
> +		partition@760000 {
> +			label = "uboot_env";
> +			reg = <0x760000 0x20000>;
> +		};
> +
> +		partition@780000 {
> +			label = "uboot";
> +			reg = <0x780000 0x80000>;
> +			read-only;
> +		};
> +	};
> +};

> +&pinctrl {
> +	pinctrl-0 = <&pmx_pci_gpios &pmx_ge>;
> +	pinctrl-names = "default";
> +
> +	pmx_power_led: pmx-power-led {
> +		marvell,pins = "mpp0";
> +		marvell,function = "gpio";
> +	};
> +
> +	pmx_reset_switch: pmx-reset-switch {
> +		marvell,pins = "mpp1";
> +		marvell,function = "gpio";
> +	};

Ah, this is missing from your DSA node. You can then add:

reset-gpios = <&gpio0 1 GPIO_ACTIVE_LOW>;

inside the switch@0 node.

> +	pmx_ge: pmx-ge {
> +		marvell,pins = "mpp9", "mpp12",	"mpp13", "mpp14", "mpp15",
> +				"mpp16", "mpp17", "mpp18", "mpp19";
> +		marvell,function = "ge";
> +	};
> +};

This can go into the .dtsi file your previous patch added. 

> +
> +&uart0 {
> +	/* Pin 1: Tx, Pin 7: Rx, Pin 8: Gnd */
> +	status = "okay";

Nice to see the comment.

     Andrew

[toc] | [prev] | [next] | [standalone]

#1444901 — Re: [PATCH v0 06/10] arm: orion5x: Add DT-based support for Netgear WNR854T

On Saturday, July 16, 2016 3:29:04 PM CEST Jamie Lentin wrote:
> +
> +#define WNR854T_PCI_SLOT0_OFFS	7
> +#define WNR854T_PCI_SLOT0_IRQ_PIN	4
> +
> +static void __init wnr854t_pci_preinit(void)
> +{
> +	int pin;
> +
> +	/*
> +	 * Configure PCI GPIO IRQ pins
> +	 */
> +	pin = WNR854T_PCI_SLOT0_IRQ_PIN;
> +	if (gpio_request(pin, "PCI Int") == 0) {
> +		if (gpio_direction_input(pin) == 0) {
> +			irq_set_irq_type(gpio_to_irq(pin), IRQ_TYPE_LEVEL_LOW);
> +		} else {
> +			pr_err("wnr854t_pci_preinit failed to set_irq_type pin %d\n",
> +				pin);
> +			gpio_free(pin);
> +		}
> +	} else {
> +		pr_err("wnr854t_pci_preinit failed to request gpio %d\n", pin);
> +	}
> +}
> +
> +static int __init wnr854t_pci_map_irq(const struct pci_dev *dev, u8 slot,
> +	u8 pin)
> +{
> +	int irq;
> +
> +	/*
> +	 * Check for devices with hard-wired IRQs.
> +	 */
> +	irq = orion5x_pci_map_irq(dev, slot, pin);
> +	if (irq != -1)
> +		return irq;
> +
> +	/*
> +	 * PCI IRQs are connected via GPIOs
> +	 */
> +	switch (slot - WNR854T_PCI_SLOT0_OFFS) {
> +	case 0:
> +		return gpio_to_irq(WNR854T_PCI_SLOT0_IRQ_PIN);
> +	default:
> +		return -1;
> +	}
> +}

The other patches all appear good to me, but I find this one suspicious.

Why are you not using the device tree for probing PCI? Is there anything
missing in drivers/pci/host/pci-mvebu.c, or do you just need help
describing it in DT?

	Arnd

[toc] | [prev] | [next] | [standalone]

#1445037 — Re: [PATCH v0 06/10] arm: orion5x: Add DT-based support for Netgear WNR854T

On Sat, 16 Jul 2016, Arnd Bergmann wrote:

> On Saturday, July 16, 2016 3:29:04 PM CEST Jamie Lentin wrote:
>> +
>> +#define WNR854T_PCI_SLOT0_OFFS	7
>> +#define WNR854T_PCI_SLOT0_IRQ_PIN	4
>> +
>> +static void __init wnr854t_pci_preinit(void)
>> +{
>> +	int pin;
>> +
>> +	/*
>> +	 * Configure PCI GPIO IRQ pins
>> +	 */
>> +	pin = WNR854T_PCI_SLOT0_IRQ_PIN;
>> +	if (gpio_request(pin, "PCI Int") == 0) {
>> +		if (gpio_direction_input(pin) == 0) {
>> +			irq_set_irq_type(gpio_to_irq(pin), IRQ_TYPE_LEVEL_LOW);
>> +		} else {
>> +			pr_err("wnr854t_pci_preinit failed to set_irq_type pin %d\n",
>> +				pin);
>> +			gpio_free(pin);
>> +		}
>> +	} else {
>> +		pr_err("wnr854t_pci_preinit failed to request gpio %d\n", pin);
>> +	}
>> +}
>> +
>> +static int __init wnr854t_pci_map_irq(const struct pci_dev *dev, u8 slot,
>> +	u8 pin)
>> +{
>> +	int irq;
>> +
>> +	/*
>> +	 * Check for devices with hard-wired IRQs.
>> +	 */
>> +	irq = orion5x_pci_map_irq(dev, slot, pin);
>> +	if (irq != -1)
>> +		return irq;
>> +
>> +	/*
>> +	 * PCI IRQs are connected via GPIOs
>> +	 */
>> +	switch (slot - WNR854T_PCI_SLOT0_OFFS) {
>> +	case 0:
>> +		return gpio_to_irq(WNR854T_PCI_SLOT0_IRQ_PIN);
>> +	default:
>> +		return -1;
>> +	}
>> +}
>
> The other patches all appear good to me, but I find this one suspicious.
>
> Why are you not using the device tree for probing PCI? Is there anything
> missing in drivers/pci/host/pci-mvebu.c, or do you just need help
> describing it in DT?

Unlike the other SoC's supported by pci-mvebu.c, orion5x has one PCI port 
as well as a PCIe port. Given no other orion5x boards seem to use 
pci-mvebu, I'm assuming there's work to be done before the PCI port can be 
used via. pci-mvebu.c

This is something I can look into if there aren't patches out there, but 
wanted to get the rest into a reasonable state first.

>
> 	Arnd
>

-- 
Jamie Lentin

[toc] | [prev] | [next] | [standalone]

#1445120 — Re: [PATCH v0 06/10] arm: orion5x: Add DT-based support for Netgear WNR854T

On Sunday, July 17, 2016 10:39:01 AM CEST Jamie Lentin wrote:
> On Sat, 16 Jul 2016, Arnd Bergmann wrote:

> > The other patches all appear good to me, but I find this one suspicious.
> >
> > Why are you not using the device tree for probing PCI? Is there anything
> > missing in drivers/pci/host/pci-mvebu.c, or do you just need help
> > describing it in DT?
> 
> Unlike the other SoC's supported by pci-mvebu.c, orion5x has one PCI port 
> as well as a PCIe port. Given no other orion5x boards seem to use 
> pci-mvebu, I'm assuming there's work to be done before the PCI port can be 
> used via. pci-mvebu.c
> 
> This is something I can look into if there aren't patches out there, but 
> wanted to get the rest into a reasonable state first.

Ok, I see your point. However, we also don't have any other Orion5x machines
using DT that rely on old probe method, and I this is something that
is particularly hard to retrofit later.

I would assume that the PCIe port should work out of the box with the driver
we have, but the PCI controller does not, and it will require some work.
Looking at https://wiki.openwrt.org/toh/netgear/wnr854t, I assume that
you want only PCI but not PCIe, correct?

The good news is that we can completely separate the two, we just have two
different PCI domains if both are enabled, so we just need to add a new
driver for the PCI port to drivers/pci/host. The pci_ops can be copied
from the existing driver, although a couple of minor cleanups would be
possible. The special handling of bus numbers and the rc_pci_fixup()
can probably just go away, and the latter part is particularly
important, because building a kernel with the fixup included might
break any system with a Marvell host bridge.

We also don't seem to need any MBUS window setup for the I/O and
memory spaces, which greatly simplifies the driver compared to the
pci-mvebu one, it would be a fairly straightforward implementation
based on pci-host-generic.c (which unfortunately just got way
more complicated and might need to go on a diet).

	Arnd

[toc] | [prev] | [next] | [standalone]

#1445340 — Re: [PATCH v0 06/10] arm: orion5x: Add DT-based support for Netgear WNR854T

Hello,

On Sun, 17 Jul 2016 22:41:35 +0200, Arnd Bergmann wrote:

> I would assume that the PCIe port should work out of the box with the driver

Unfortunately, no. The PCIe on Orion5x requires a workaround for
reading/writing the PCI configuration space. Instead of doing MMIO
accesses to PCIE_CONF_ADDR_OFF / PCIE_CONF_DATA_OFF, you must map a
MBus window, which provides a memory-mapped view of the PCI
configuration space.

Definitely not impossible to implement, but the driver doesn't work
as-is.

> We also don't seem to need any MBUS window setup for the I/O and
> memory spaces, which greatly simplifies the driver compared to the
> pci-mvebu one, it would be a fairly straightforward implementation
> based on pci-host-generic.c (which unfortunately just got way
> more complicated and might need to go on a diet).

MBus windows are needed. See:

        mvebu_mbus_add_window_remap_by_id(ORION_MBUS_PCI_IO_TARGET,
                                          ORION_MBUS_PCI_IO_ATTR,
                                          ORION5X_PCI_IO_PHYS_BASE,
                                          ORION5X_PCI_IO_SIZE,
                                          ORION5X_PCI_IO_BUS_BASE);
        mvebu_mbus_add_window_by_id(ORION_MBUS_PCI_MEM_TARGET,
                                    ORION_MBUS_PCI_MEM_ATTR,
                                    ORION5X_PCI_MEM_PHYS_BASE,
                                    ORION5X_PCI_MEM_SIZE);

in orion5x_setup_wins().

Note that we already have some Orion5x converted to DT, and that use
PCI: board-rd88f5182.c is an example. So we could very well take Jamie
patches as-is, and move later to a DT-representation for PCI/PCIe.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[toc] | [prev] | [next] | [standalone]

#1445356 — Re: [PATCH v0 06/10] arm: orion5x: Add DT-based support for Netgear WNR854T

On Monday, July 18, 2016 11:44:24 AM CEST Thomas Petazzoni wrote:
> 
> On Sun, 17 Jul 2016 22:41:35 +0200, Arnd Bergmann wrote:
> 
> > I would assume that the PCIe port should work out of the box with the driver
> 
> Unfortunately, no. The PCIe on Orion5x requires a workaround for
> reading/writing the PCI configuration space. Instead of doing MMIO
> accesses to PCIE_CONF_ADDR_OFF / PCIE_CONF_DATA_OFF, you must map a
> MBus window, which provides a memory-mapped view of the PCI
> configuration space.
> 
> Definitely not impossible to implement, but the driver doesn't work
> as-is.

Ok.

> > We also don't seem to need any MBUS window setup for the I/O and
> > memory spaces, which greatly simplifies the driver compared to the
> > pci-mvebu one, it would be a fairly straightforward implementation
> > based on pci-host-generic.c (which unfortunately just got way
> > more complicated and might need to go on a diet).
> 
> MBus windows are needed. See:
> 
>         mvebu_mbus_add_window_remap_by_id(ORION_MBUS_PCI_IO_TARGET,
>                                           ORION_MBUS_PCI_IO_ATTR,
>                                           ORION5X_PCI_IO_PHYS_BASE,
>                                           ORION5X_PCI_IO_SIZE,
>                                           ORION5X_PCI_IO_BUS_BASE);
>         mvebu_mbus_add_window_by_id(ORION_MBUS_PCI_MEM_TARGET,
>                                     ORION_MBUS_PCI_MEM_ATTR,
>                                     ORION5X_PCI_MEM_PHYS_BASE,
>                                     ORION5X_PCI_MEM_SIZE);
> 
> in orion5x_setup_wins().

Ok, I was just looking at the wrong file, as they are set up from
common.c, not pci.c.

> Note that we already have some Orion5x converted to DT, and that use
> PCI: board-rd88f5182.c is an example. So we could very well take Jamie
> patches as-is, and move later to a DT-representation for PCI/PCIe.

Ah, I thought all the DT users were moved to mach-mvebu. I agree
this new patch isn't introducing anything we don't already have then,
so we can just take it, but the conversion will not be nice when
we do that.

I was also hoping that we could get to the point where pci_common_init()
is only used for legacy machines without DT and without multiplatform,
it seems I missed a couple of users here.

	Arnd

[toc] | [prev] | [next] | [standalone]

#1446297 — Re: [PATCH v0 06/10] arm: orion5x: Add DT-based support for Netgear WNR854T

On Tuesday, July 19, 2016 10:40:16 AM CEST Jamie Lentin wrote:
> On Mon, 18 Jul 2016, Arnd Bergmann wrote:
> 
> > On Monday, July 18, 2016 11:44:24 AM CEST Thomas Petazzoni wrote:
> >>
> >> On Sun, 17 Jul 2016 22:41:35 +0200, Arnd Bergmann wrote:
> >>
> >>> I would assume that the PCIe port should work out of the box with the driver
> >>
> >> Unfortunately, no. The PCIe on Orion5x requires a workaround for
> >> reading/writing the PCI configuration space. Instead of doing MMIO
> >> accesses to PCIE_CONF_ADDR_OFF / PCIE_CONF_DATA_OFF, you must map a
> >> MBus window, which provides a memory-mapped view of the PCI
> >> configuration space.
> >>
> >> Definitely not impossible to implement, but the driver doesn't work
> >> as-is.
> >
> > Ok.
> 
> Unfortunately this isn't something I can test as the PCIe port on the SoC 
> doesn't go anywhere in my case.

As I said, this wouldn't be a problem: we should consider the PCI and PCIe
ports on this chip as completely separate anyway, so we can work on
the drivers independently.

> >>> We also don't seem to need any MBUS window setup for the I/O and
> >>> memory spaces, which greatly simplifies the driver compared to the
> >>> pci-mvebu one, it would be a fairly straightforward implementation
> >>> based on pci-host-generic.c (which unfortunately just got way
> >>> more complicated and might need to go on a diet).
> >>
> >> MBus windows are needed. See:
> >>
> >>         mvebu_mbus_add_window_remap_by_id(ORION_MBUS_PCI_IO_TARGET,
> >>                                           ORION_MBUS_PCI_IO_ATTR,
> >>                                           ORION5X_PCI_IO_PHYS_BASE,
> >>                                           ORION5X_PCI_IO_SIZE,
> >>                                           ORION5X_PCI_IO_BUS_BASE);
> >>         mvebu_mbus_add_window_by_id(ORION_MBUS_PCI_MEM_TARGET,
> >>                                     ORION_MBUS_PCI_MEM_ATTR,
> >>                                     ORION5X_PCI_MEM_PHYS_BASE,
> >>                                     ORION5X_PCI_MEM_SIZE);
> >>
> >> in orion5x_setup_wins().
> >
> > Ok, I was just looking at the wrong file, as they are set up from
> > common.c, not pci.c.
> >
> >> Note that we already have some Orion5x converted to DT, and that use
> >> PCI: board-rd88f5182.c is an example. So we could very well take Jamie
> >> patches as-is, and move later to a DT-representation for PCI/PCIe.
> >
> > Ah, I thought all the DT users were moved to mach-mvebu. I agree
> > this new patch isn't introducing anything we don't already have then,
> > so we can just take it, but the conversion will not be nice when
> > we do that.
> 
> Yes, board-wnr854t.c is a clone of the existing board-rd88f5182.c. 
> Although I'd presume that it too would need late_initcall() or somesuch 
> mechanism to probe PCI once the GPIO controller is available.

Deferred probing should be fine once the driver is migrated from
pci_common_init() to registering the host bridge directly.

	Arnd

[toc] | [prev] | [next] | [standalone]

#1446308 — Re: [PATCH v0 06/10] arm: orion5x: Add DT-based support for Netgear WNR854T

On Mon, 18 Jul 2016, Arnd Bergmann wrote:

> On Monday, July 18, 2016 11:44:24 AM CEST Thomas Petazzoni wrote:
>>
>> On Sun, 17 Jul 2016 22:41:35 +0200, Arnd Bergmann wrote:
>>
>>> I would assume that the PCIe port should work out of the box with the driver
>>
>> Unfortunately, no. The PCIe on Orion5x requires a workaround for
>> reading/writing the PCI configuration space. Instead of doing MMIO
>> accesses to PCIE_CONF_ADDR_OFF / PCIE_CONF_DATA_OFF, you must map a
>> MBus window, which provides a memory-mapped view of the PCI
>> configuration space.
>>
>> Definitely not impossible to implement, but the driver doesn't work
>> as-is.
>
> Ok.

Unfortunately this isn't something I can test as the PCIe port on the SoC 
doesn't go anywhere in my case.

>>> We also don't seem to need any MBUS window setup for the I/O and
>>> memory spaces, which greatly simplifies the driver compared to the
>>> pci-mvebu one, it would be a fairly straightforward implementation
>>> based on pci-host-generic.c (which unfortunately just got way
>>> more complicated and might need to go on a diet).
>>
>> MBus windows are needed. See:
>>
>>         mvebu_mbus_add_window_remap_by_id(ORION_MBUS_PCI_IO_TARGET,
>>                                           ORION_MBUS_PCI_IO_ATTR,
>>                                           ORION5X_PCI_IO_PHYS_BASE,
>>                                           ORION5X_PCI_IO_SIZE,
>>                                           ORION5X_PCI_IO_BUS_BASE);
>>         mvebu_mbus_add_window_by_id(ORION_MBUS_PCI_MEM_TARGET,
>>                                     ORION_MBUS_PCI_MEM_ATTR,
>>                                     ORION5X_PCI_MEM_PHYS_BASE,
>>                                     ORION5X_PCI_MEM_SIZE);
>>
>> in orion5x_setup_wins().
>
> Ok, I was just looking at the wrong file, as they are set up from
> common.c, not pci.c.
>
>> Note that we already have some Orion5x converted to DT, and that use
>> PCI: board-rd88f5182.c is an example. So we could very well take Jamie
>> patches as-is, and move later to a DT-representation for PCI/PCIe.
>
> Ah, I thought all the DT users were moved to mach-mvebu. I agree
> this new patch isn't introducing anything we don't already have then,
> so we can just take it, but the conversion will not be nice when
> we do that.

Yes, board-wnr854t.c is a clone of the existing board-rd88f5182.c. 
Although I'd presume that it too would need late_initcall() or somesuch 
mechanism to probe PCI once the GPIO controller is available.

> I was also hoping that we could get to the point where pci_common_init()
> is only used for legacy machines without DT and without multiplatform,
> it seems I missed a couple of users here.
>
> 	Arnd
>

-- 
Jamie Lentin

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.kernel

csiph-web