[U-Boot] [PATCH 0/3] Marvell A7K/A8K PCIe fixes and extensions

[U-Boot] [PATCH 0/3] Marvell A7K/A8K PCIe fixes and extensions

[kostap at marvell.com]

From: Konstantin Porotchkin <kostap@marvell.com>

This patch series includes fix for the mvebu DW PCIe driver that allows
scanning of empty (unlinked) PCIe slots.
The default DTS file for Armada-8040-DB is re-arranged and aligned with
Marvell default configuration "A" for this board.
PCIe devices scan is added to the early init stage for eliminating 
need for usage of "pci enum" command on every reboot.

Konstantin Porotchkin (3):
  arm64: mvebu: Trigger PCI devices scan at early init stage
  fix: mvebu: pcie_dw: Allow probing empty PCIe slots
  mvebu: dts: a80x0: Sync the DB DTS with standard config A

 arch/arm/dts/armada-8040-db.dts    | 222 +++++++++++++++++++------------------
 arch/arm/mach-mvebu/arm64-common.c |  13 ++-
 drivers/pci/pcie_dw_mvebu.c        |  10 +-
 3 files changed, 131 insertions(+), 114 deletions(-)

-- 
2.7.4

[U-Boot] [PATCH 1/3] arm64: mvebu: Trigger PCI devices scan at early init stage

[kostap at marvell.com]

From: Konstantin Porotchkin <kostap@marvell.com>

Add PCIe initialization at early init stage.
This operation has a side effect of detecting all PCIe
plug-in cards, so the operator is not obligated to issue
"pci enum" command though CLI for this purpose.
Also convert the SATA first device scan to a walk through
all availabel SATA devices.

Signed-off-by: Konstantin Porotchkin <kostap@marvell.com>
Cc: Stefan Roese <sr@denx.de>
Cc: Igal Liberman <igall@marvell.com>
Cc: Nadav Haklai <nadavh@marvell.com>
---
 arch/arm/mach-mvebu/arm64-common.c | 13 +++++++++++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-mvebu/arm64-common.c b/arch/arm/mach-mvebu/arm64-common.c
index 8f02655..ff28750 100644
--- a/arch/arm/mach-mvebu/arm64-common.c
+++ b/arch/arm/mach-mvebu/arm64-common.c
@@ -8,6 +8,7 @@
 #include <dm.h>
 #include <fdtdec.h>
 #include <libfdt.h>
+#include <pci.h>
 #include <asm/io.h>
 #include <asm/system.h>
 #include <asm/arch/cpu.h>
@@ -142,8 +143,16 @@ int arch_early_init_r(void)
 			break;
 	}
 
-	/* Cause the SATA device to do its early init */
-	uclass_first_device(UCLASS_AHCI, &dev);
+	/* Cause the SATA devices to do their early init */
+	for (uclass_first_device(UCLASS_AHCI, &dev);
+	     dev;
+	     uclass_next_device(&dev))
+		;
+
+#ifdef CONFIG_DM_PCI
+	/* Trigger PCIe devices detection */
+	pci_init();
+#endif
 
 	return 0;
 }
-- 
2.7.4

[U-Boot] [PATCH 2/3] fix: mvebu: pcie_dw: Allow probing empty PCIe slots

[kostap at marvell.com]

From: Konstantin Porotchkin <kostap@marvell.com>

This patch allows probing all PCIe nodes defined in DTS
even if there no device connected to such node (no link).
Without this fix the driver returns -ENODEV when the PCIe
link is down. As result the pci_init function stops
scanning bus on first empty PCIe slot and all devices
located in higher numbered buses are not discovered.

Signed-off-by: Konstantin Porotchkin <kostap@marvell.com>
Cc: Stefan Roese <sr@denx.de>
Cc: Igal Liberman <igall@marvell.com>
Cc: Nadav Haklai <nadavh@marvell.com>
---
 drivers/pci/pcie_dw_mvebu.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/pci/pcie_dw_mvebu.c b/drivers/pci/pcie_dw_mvebu.c
index d4776a9..05a0660 100644
--- a/drivers/pci/pcie_dw_mvebu.c
+++ b/drivers/pci/pcie_dw_mvebu.c
@@ -487,13 +487,13 @@ static int pcie_dw_mvebu_probe(struct udevice *dev)
 	/* Don't register host if link is down */
 	if (!pcie_dw_mvebu_pcie_link_up(pcie->ctrl_base, LINK_SPEED_GEN_3)) {
 		printf("PCIE-%d: Link down\n", dev->seq);
-		return -ENODEV;
+	} else {
+		printf("PCIE-%d: Link up (Gen%d-x%d, Bus%d)\n", dev->seq,
+		       pcie_dw_get_link_speed(pcie->ctrl_base),
+		       pcie_dw_get_link_width(pcie->ctrl_base),
+		       hose->first_busno);
 	}
 
-	printf("PCIE-%d: Link up (Gen%d-x%d, Bus%d)\n", dev->seq,
-	       pcie_dw_get_link_speed(pcie->ctrl_base),
-	       pcie_dw_get_link_width(pcie->ctrl_base), hose->first_busno);
-
 	pcie_dw_regions_setup(pcie);
 
 	/* Set the CLASS_REV of RC CFG header to PCI_CLASS_BRIDGE_PCI */
-- 
2.7.4

[U-Boot] [PATCH 3/3] mvebu: dts: a80x0: Sync the DB DTS with standard config A

[kostap at marvell.com]

From: Konstantin Porotchkin <kostap@marvell.com>

Sync the default configuration of Armada-8040-DB with
Marvell u-boot-2015  standard configuration "A" for the same board.
The standard configuration "A" enables 2 PCIe slots on CP0
and 3 PCIe slots on CP1.
This is the main configuration used for u-boot  and Linux tests.
This patch also re-arranges the DTS file entries by grouping
all nodes related to CP0 and CP1.

Signed-off-by: Konstantin Porotchkin <kostap@marvell.com>
Cc: Stefan Roese <sr@denx.de>
Cc: Igal Liberman <igall@marvell.com>
Cc: Nadav Haklai <nadavh@marvell.com>
---
 arch/arm/dts/armada-8040-db.dts | 222 +++++++++++++++++++++-------------------
 1 file changed, 115 insertions(+), 107 deletions(-)

diff --git a/arch/arm/dts/armada-8040-db.dts b/arch/arm/dts/armada-8040-db.dts
index 40def9d..e1e6dfd 100644
--- a/arch/arm/dts/armada-8040-db.dts
+++ b/arch/arm/dts/armada-8040-db.dts
@@ -83,28 +83,68 @@
 
 &cpm_pinctl {
 	/* MPP Bus:
-	 * [0-31] = 0xff: Keep default CP0_shared_pins:
-	 * [11] CLKOUT_MPP_11 (out)
-	 * [23] LINK_RD_IN_CP2CP (in)
-	 * [25] CLKOUT_MPP_25 (out)
-	 * [29] AVS_FB_IN_CP2CP (in)
-	 * [32,34] SMI
-	 * [31]    GPIO: push button/Wake
-	 * [35-36] GPIO
-	 * [37-38] I2C
-	 * [40-41] SATA[0/1]_PRESENT_ACTIVEn
-	 * [42-43] XSMI
-	 * [44-55] RGMII1
-	 * [56-62] SD
+	 *	[0-31]	= 0xff: Keep default CP0_shared_pins
+	 *	[11]	CLKOUT_MPP_11 (out)
+	 *	[23]	LINK_RD_IN_CP2CP (in)
+	 *	[25]	CLKOUT_MPP_25 (out)
+	 *	[29]	AVS_FB_IN_CP2CP (in)
+	 *	[32,34]	GE_MDIO/MDC
+	 *	[33]	GPIO: GE_INT#/push button/Wake
+	 *	[35]	MSS_GPIO[3]: MSS_PWDN
+	 *	[36]	MSS_GPIO[5]: MSS_VTT_EN
+	 *	[37-38]	I2C0
+	 *	[39]	PTP_CLK
+	 *	[40-41]	SATA[0/1]_PRESENT_ACTIVEn
+	 *	[42-43]	XG_MDC/XG_MDIO (XSMI)
+	 *	[44-55]	RGMII1
+	 *	[56-62]	SD
 	 */
-		/*   0    1    2    3    4    5    6    7    8    9 */
+	/*   0    1    2    3    4    5    6    7    8    9 */
 	pin-func = < 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
 		     0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
 		     0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
-		     0xff 0    7    0    7    0    0    2    2    0
-		     0    0    8    8    1    1    1    1    1    1
-		     1    1    1    1    1    1    0xe  0xe  0xe  0xe
-		     0xe  0xe  0xe >;
+		     0xff 0xff 0x7  0x0  0x7  0xa  0xa  0x2  0x2  0x5
+		     0x9  0x9  0x8  0x8  0x1  0x1  0x1  0x1  0x1  0x1
+		     0x1  0x1  0x1  0x1  0x1  0x1  0xe  0xe  0xe  0xe
+		     0xe  0xe  0xe>;
+};
+
+&cpm_comphy {
+	/* Serdes Configuration:
+	 *	Lane 0: PCIe0 (x1)
+	 *	Lane 1: SATA0
+	 *	Lane 2: KR (10G)
+	 *	Lane 3: SATA1
+	 *	Lane 4: USB3_HOST1
+	 *	Lane 5: PCIe2 (x1)
+	 */
+	phy0 {
+		phy-type = <PHY_TYPE_PEX0>;
+	};
+	phy1 {
+		phy-type = <PHY_TYPE_SATA0>;
+	};
+	phy2 {
+		phy-type = <PHY_TYPE_KR>;
+	};
+	phy3 {
+		phy-type = <PHY_TYPE_SATA1>;
+	};
+	phy4 {
+		phy-type = <PHY_TYPE_USB3_HOST1>;
+	};
+	phy5 {
+		phy-type = <PHY_TYPE_PEX2>;
+	};
+};
+
+/* CON6 on CP0 expansion */
+&cpm_pcie0 {
+	status = "okay";
+};
+
+&cpm_pcie1 {
+	status = "disabled";
 };
 
 /* CON5 on CP0 expansion */
@@ -134,21 +174,69 @@
 	status = "okay";
 };
 
+&cpm_utmi0 {
+	status = "okay";
+};
+
+&cpm_utmi1 {
+	status = "okay";
+};
+
 &cps_pinctl {
 	/* MPP Bus:
-	 * [0-11]  RGMII0
-	 * [13-16] SPI1
-	 * [27,31] GE_MDIO/MDC
-	 * [32-62] = 0xff: Keep default CP1_shared_pins:
+	 *	[0-11]	RGMII0
+	 *	[13-16]	SPI1
+	 *	[27,31]	GE_MDIO/MDC
+	 *	[28]	SATA1_PRESENT_ACTIVEn
+	 *	[29-30]	UART0
+	 *	[32-62]	= 0xff: Keep default CP1_shared_pins
 	 */
-		/*   0    1    2    3    4    5    6    7    8    9 */
+	/*   0    1    2    3    4    5    6    7    8    9 */
 	pin-func = < 0x3  0x3  0x3  0x3  0x3  0x3  0x3  0x3  0x3  0x3
-		     0x3  0x3  0xff 0x3  0x3  0x3  0x3  0xff 0xff 0xff
-		     0xff 0xff 0xff 0xff 0xff 0xff 0xff 0x8  0xff 0xff
-		     0xff 0x8  0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
+		     0x3  0x3  0x3  0x3  0x3  0x3  0x3  0xff 0xff 0xff
+		     0xff 0xff 0xff 0xff 0xff 0xff 0xff 0x8  0x9  0xa
+		     0xA  0x8  0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
 		     0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
 		     0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
-		     0xff 0xff 0xff >;
+		     0xff 0xff 0xff>;
+};
+
+&cps_comphy {
+	/* Serdes Configuration:
+	 *	Lane 0: PCIe0 (x1)
+	 *	Lane 1: SATA0
+	 *	Lane 2: KR (10G)
+	 *	Lane 3: SATA1
+	 *	Lane 4: PCIe1 (x1)
+	 *	Lane 5: PCIe2 (x1)
+	 */
+	phy0 {
+		phy-type = <PHY_TYPE_PEX0>;
+	};
+	phy1 {
+		phy-type = <PHY_TYPE_SATA0>;
+	};
+	phy2 {
+		phy-type = <PHY_TYPE_KR>;
+	};
+	phy3 {
+		phy-type = <PHY_TYPE_SATA1>;
+	};
+	phy4 {
+		phy-type = <PHY_TYPE_PEX1>;
+	};
+	phy5 {
+		phy-type = <PHY_TYPE_PEX2>;
+	};
+};
+
+/* CON6 on CP1 expansion */
+&cps_pcie0 {
+	status = "okay";
+};
+
+&cps_pcie1 {
+	status = "okay";
 };
 
 /* CON5 on CP1 expansion */
@@ -200,86 +288,6 @@
 	status = "okay";
 };
 
-&cpm_comphy {
-	/*
-	 * Serdes Configuration:
-	 * Lane 0: SGMII2
-	 * Lane 1: USB3_HOST0
-	 * Lane 2: KR (10G)
-	 * Lane 3: SATA1
-	 * Lane 4: USB3_HOST1
-	 * Lane 5: PEX2x1
-	 */
-	phy0 {
-		phy-type = <PHY_TYPE_SGMII2>;
-		phy-speed = <PHY_SPEED_3_125G>;
-	};
-
-	phy1 {
-		phy-type = <PHY_TYPE_USB3_HOST0>;
-	};
-
-	phy2 {
-		phy-type = <PHY_TYPE_KR>;
-	};
-
-	phy3 {
-		phy-type = <PHY_TYPE_SATA1>;
-	};
-
-	phy4 {
-		phy-type = <PHY_TYPE_USB3_HOST1>;
-	};
-
-	phy5 {
-		phy-type = <PHY_TYPE_PEX2>;
-	};
-};
-
-&cps_comphy {
-	/*
-	 * Serdes Configuration:
-	 * Lane 0: SGMII2
-	 * Lane 1: USB3_HOST0
-	 * Lane 2: KR (10G)
-	 * Lane 3: SATA1
-	 * Lane 4: Unconnected
-	 * Lane 5: PEX2x1
-	 */
-	phy0 {
-		phy-type = <PHY_TYPE_SGMII2>;
-		phy-speed = <PHY_SPEED_3_125G>;
-	};
-
-	phy1 {
-		phy-type = <PHY_TYPE_USB3_HOST0>;
-	};
-
-	phy2 {
-		phy-type = <PHY_TYPE_KR>;
-	};
-
-	phy3 {
-		phy-type = <PHY_TYPE_SATA1>;
-	};
-
-	phy4 {
-		phy-type = <PHY_TYPE_UNCONNECTED>;
-	};
-
-	phy5 {
-		phy-type = <PHY_TYPE_PEX2>;
-	};
-};
-
-&cpm_utmi0 {
-	status = "okay";
-};
-
-&cpm_utmi1 {
-	status = "okay";
-};
-
 &cps_utmi0 {
 	status = "okay";
 };
-- 
2.7.4

[U-Boot] [PATCH 1/3] arm64: mvebu: Trigger PCI devices scan at early init stage

[Stefan Roese]

(adding Simon to Cc for PCI related question)

On 28.03.2017 17:36, kostap at marvell.com wrote:
> From: Konstantin Porotchkin <kostap@marvell.com>
>
> Add PCIe initialization at early init stage.
> This operation has a side effect of detecting all PCIe
> plug-in cards, so the operator is not obligated to issue
> "pci enum" command though CLI for this purpose.

I'm not sure, if this should be handled this way. Simon, how
is such a default PCI scan with DM supposed to get done? Is
there a way do do this automatically without the need that
the user has to issue "pci enum" manually?

> Also convert the SATA first device scan to a walk through
> all availabel SATA devices.

This should be done in a separate patch. But seeing this,
won't this SATA / AHCI code be gone completely from this
file, once this is converted into a "real" DM AHCI / SCSI
driver (please look at my preliminary patch for this).

> Signed-off-by: Konstantin Porotchkin <kostap@marvell.com>
> Cc: Stefan Roese <sr@denx.de>
> Cc: Igal Liberman <igall@marvell.com>
> Cc: Nadav Haklai <nadavh@marvell.com>
> ---
>  arch/arm/mach-mvebu/arm64-common.c | 13 +++++++++++--
>  1 file changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-mvebu/arm64-common.c b/arch/arm/mach-mvebu/arm64-common.c
> index 8f02655..ff28750 100644
> --- a/arch/arm/mach-mvebu/arm64-common.c
> +++ b/arch/arm/mach-mvebu/arm64-common.c
> @@ -8,6 +8,7 @@
>  #include <dm.h>
>  #include <fdtdec.h>
>  #include <libfdt.h>
> +#include <pci.h>
>  #include <asm/io.h>
>  #include <asm/system.h>
>  #include <asm/arch/cpu.h>
> @@ -142,8 +143,16 @@ int arch_early_init_r(void)
>  			break;
>  	}
>
> -	/* Cause the SATA device to do its early init */
> -	uclass_first_device(UCLASS_AHCI, &dev);
> +	/* Cause the SATA devices to do their early init */
> +	for (uclass_first_device(UCLASS_AHCI, &dev);
> +	     dev;
> +	     uclass_next_device(&dev))
> +		;
> +
> +#ifdef CONFIG_DM_PCI
> +	/* Trigger PCIe devices detection */
> +	pci_init();
> +#endif
>
>  	return 0;
>  }
>

Thanks,
Stefan

[U-Boot] [PATCH 2/3] fix: mvebu: pcie_dw: Allow probing empty PCIe slots

[Stefan Roese]

On 28.03.2017 17:36, kostap at marvell.com wrote:
> From: Konstantin Porotchkin <kostap@marvell.com>
>
> This patch allows probing all PCIe nodes defined in DTS
> even if there no device connected to such node (no link).
> Without this fix the driver returns -ENODEV when the PCIe
> link is down. As result the pci_init function stops
> scanning bus on first empty PCIe slot and all devices
> located in higher numbered buses are not discovered.
>
> Signed-off-by: Konstantin Porotchkin <kostap@marvell.com>
> Cc: Stefan Roese <sr@denx.de>
> Cc: Igal Liberman <igall@marvell.com>
> Cc: Nadav Haklai <nadavh@marvell.com>
> ---
>  drivers/pci/pcie_dw_mvebu.c | 10 +++++-----
>  1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/pci/pcie_dw_mvebu.c b/drivers/pci/pcie_dw_mvebu.c
> index d4776a9..05a0660 100644
> --- a/drivers/pci/pcie_dw_mvebu.c
> +++ b/drivers/pci/pcie_dw_mvebu.c
> @@ -487,13 +487,13 @@ static int pcie_dw_mvebu_probe(struct udevice *dev)
>  	/* Don't register host if link is down */
>  	if (!pcie_dw_mvebu_pcie_link_up(pcie->ctrl_base, LINK_SPEED_GEN_3)) {
>  		printf("PCIE-%d: Link down\n", dev->seq);
> -		return -ENODEV;
> +	} else {
> +		printf("PCIE-%d: Link up (Gen%d-x%d, Bus%d)\n", dev->seq,
> +		       pcie_dw_get_link_speed(pcie->ctrl_base),
> +		       pcie_dw_get_link_width(pcie->ctrl_base),
> +		       hose->first_busno);
>  	}
>
> -	printf("PCIE-%d: Link up (Gen%d-x%d, Bus%d)\n", dev->seq,
> -	       pcie_dw_get_link_speed(pcie->ctrl_base),
> -	       pcie_dw_get_link_width(pcie->ctrl_base), hose->first_busno);
> -
>  	pcie_dw_regions_setup(pcie);
>
>  	/* Set the CLASS_REV of RC CFG header to PCI_CLASS_BRIDGE_PCI */
>

Reviewed-by: Stefan Roese <sr@denx.de>

Thanks,
Stefan

[U-Boot] [PATCH 3/3] mvebu: dts: a80x0: Sync the DB DTS with standard config A

[Stefan Roese]

On 28.03.2017 17:36, kostap at marvell.com wrote:
> From: Konstantin Porotchkin <kostap@marvell.com>
>
> Sync the default configuration of Armada-8040-DB with
> Marvell u-boot-2015  standard configuration "A" for the same board.
> The standard configuration "A" enables 2 PCIe slots on CP0
> and 3 PCIe slots on CP1.
> This is the main configuration used for u-boot  and Linux tests.
> This patch also re-arranges the DTS file entries by grouping
> all nodes related to CP0 and CP1.
>
> Signed-off-by: Konstantin Porotchkin <kostap@marvell.com>
> Cc: Stefan Roese <sr@denx.de>
> Cc: Igal Liberman <igall@marvell.com>
> Cc: Nadav Haklai <nadavh@marvell.com>
> ---
>  arch/arm/dts/armada-8040-db.dts | 222 +++++++++++++++++++++-------------------
>  1 file changed, 115 insertions(+), 107 deletions(-)
>
> diff --git a/arch/arm/dts/armada-8040-db.dts b/arch/arm/dts/armada-8040-db.dts
> index 40def9d..e1e6dfd 100644
> --- a/arch/arm/dts/armada-8040-db.dts
> +++ b/arch/arm/dts/armada-8040-db.dts
> @@ -83,28 +83,68 @@
>
>  &cpm_pinctl {
>  	/* MPP Bus:
> -	 * [0-31] = 0xff: Keep default CP0_shared_pins:
> -	 * [11] CLKOUT_MPP_11 (out)
> -	 * [23] LINK_RD_IN_CP2CP (in)
> -	 * [25] CLKOUT_MPP_25 (out)
> -	 * [29] AVS_FB_IN_CP2CP (in)
> -	 * [32,34] SMI
> -	 * [31]    GPIO: push button/Wake
> -	 * [35-36] GPIO
> -	 * [37-38] I2C
> -	 * [40-41] SATA[0/1]_PRESENT_ACTIVEn
> -	 * [42-43] XSMI
> -	 * [44-55] RGMII1
> -	 * [56-62] SD
> +	 *	[0-31]	= 0xff: Keep default CP0_shared_pins
> +	 *	[11]	CLKOUT_MPP_11 (out)
> +	 *	[23]	LINK_RD_IN_CP2CP (in)
> +	 *	[25]	CLKOUT_MPP_25 (out)
> +	 *	[29]	AVS_FB_IN_CP2CP (in)
> +	 *	[32,34]	GE_MDIO/MDC
> +	 *	[33]	GPIO: GE_INT#/push button/Wake
> +	 *	[35]	MSS_GPIO[3]: MSS_PWDN
> +	 *	[36]	MSS_GPIO[5]: MSS_VTT_EN
> +	 *	[37-38]	I2C0
> +	 *	[39]	PTP_CLK
> +	 *	[40-41]	SATA[0/1]_PRESENT_ACTIVEn
> +	 *	[42-43]	XG_MDC/XG_MDIO (XSMI)
> +	 *	[44-55]	RGMII1
> +	 *	[56-62]	SD
>  	 */
> -		/*   0    1    2    3    4    5    6    7    8    9 */
> +	/*   0    1    2    3    4    5    6    7    8    9 */
>  	pin-func = < 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
>  		     0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
>  		     0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
> -		     0xff 0    7    0    7    0    0    2    2    0
> -		     0    0    8    8    1    1    1    1    1    1
> -		     1    1    1    1    1    1    0xe  0xe  0xe  0xe
> -		     0xe  0xe  0xe >;
> +		     0xff 0xff 0x7  0x0  0x7  0xa  0xa  0x2  0x2  0x5
> +		     0x9  0x9  0x8  0x8  0x1  0x1  0x1  0x1  0x1  0x1
> +		     0x1  0x1  0x1  0x1  0x1  0x1  0xe  0xe  0xe  0xe
> +		     0xe  0xe  0xe>;
> +};
> +
> +&cpm_comphy {
> +	/* Serdes Configuration:
> +	 *	Lane 0: PCIe0 (x1)
> +	 *	Lane 1: SATA0
> +	 *	Lane 2: KR (10G)
> +	 *	Lane 3: SATA1
> +	 *	Lane 4: USB3_HOST1
> +	 *	Lane 5: PCIe2 (x1)
> +	 */
> +	phy0 {
> +		phy-type = <PHY_TYPE_PEX0>;
> +	};
> +	phy1 {
> +		phy-type = <PHY_TYPE_SATA0>;
> +	};
> +	phy2 {
> +		phy-type = <PHY_TYPE_KR>;
> +	};
> +	phy3 {
> +		phy-type = <PHY_TYPE_SATA1>;
> +	};
> +	phy4 {
> +		phy-type = <PHY_TYPE_USB3_HOST1>;
> +	};
> +	phy5 {
> +		phy-type = <PHY_TYPE_PEX2>;
> +	};
> +};
> +
> +/* CON6 on CP0 expansion */
> +&cpm_pcie0 {
> +	status = "okay";
> +};
> +
> +&cpm_pcie1 {
> +	status = "disabled";
>  };
>
>  /* CON5 on CP0 expansion */
> @@ -134,21 +174,69 @@
>  	status = "okay";
>  };
>
> +&cpm_utmi0 {
> +	status = "okay";
> +};
> +
> +&cpm_utmi1 {
> +	status = "okay";
> +};
> +
>  &cps_pinctl {
>  	/* MPP Bus:
> -	 * [0-11]  RGMII0
> -	 * [13-16] SPI1
> -	 * [27,31] GE_MDIO/MDC
> -	 * [32-62] = 0xff: Keep default CP1_shared_pins:
> +	 *	[0-11]	RGMII0
> +	 *	[13-16]	SPI1
> +	 *	[27,31]	GE_MDIO/MDC
> +	 *	[28]	SATA1_PRESENT_ACTIVEn
> +	 *	[29-30]	UART0
> +	 *	[32-62]	= 0xff: Keep default CP1_shared_pins
>  	 */
> -		/*   0    1    2    3    4    5    6    7    8    9 */
> +	/*   0    1    2    3    4    5    6    7    8    9 */
>  	pin-func = < 0x3  0x3  0x3  0x3  0x3  0x3  0x3  0x3  0x3  0x3
> -		     0x3  0x3  0xff 0x3  0x3  0x3  0x3  0xff 0xff 0xff
> -		     0xff 0xff 0xff 0xff 0xff 0xff 0xff 0x8  0xff 0xff
> -		     0xff 0x8  0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
> +		     0x3  0x3  0x3  0x3  0x3  0x3  0x3  0xff 0xff 0xff
> +		     0xff 0xff 0xff 0xff 0xff 0xff 0xff 0x8  0x9  0xa
> +		     0xA  0x8  0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
>  		     0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
>  		     0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
> -		     0xff 0xff 0xff >;
> +		     0xff 0xff 0xff>;
> +};
> +
> +&cps_comphy {
> +	/* Serdes Configuration:
> +	 *	Lane 0: PCIe0 (x1)
> +	 *	Lane 1: SATA0
> +	 *	Lane 2: KR (10G)
> +	 *	Lane 3: SATA1
> +	 *	Lane 4: PCIe1 (x1)
> +	 *	Lane 5: PCIe2 (x1)
> +	 */
> +	phy0 {
> +		phy-type = <PHY_TYPE_PEX0>;
> +	};
> +	phy1 {
> +		phy-type = <PHY_TYPE_SATA0>;
> +	};
> +	phy2 {
> +		phy-type = <PHY_TYPE_KR>;
> +	};
> +	phy3 {
> +		phy-type = <PHY_TYPE_SATA1>;
> +	};
> +	phy4 {
> +		phy-type = <PHY_TYPE_PEX1>;
> +	};
> +	phy5 {
> +		phy-type = <PHY_TYPE_PEX2>;
> +	};
> +};
> +
> +/* CON6 on CP1 expansion */
> +&cps_pcie0 {
> +	status = "okay";
> +};
> +
> +&cps_pcie1 {
> +	status = "okay";
>  };
>
>  /* CON5 on CP1 expansion */
> @@ -200,86 +288,6 @@
>  	status = "okay";
>  };
>
> -&cpm_comphy {
> -	/*
> -	 * Serdes Configuration:
> -	 * Lane 0: SGMII2
> -	 * Lane 1: USB3_HOST0
> -	 * Lane 2: KR (10G)
> -	 * Lane 3: SATA1
> -	 * Lane 4: USB3_HOST1
> -	 * Lane 5: PEX2x1
> -	 */
> -	phy0 {
> -		phy-type = <PHY_TYPE_SGMII2>;
> -		phy-speed = <PHY_SPEED_3_125G>;
> -	};
> -
> -	phy1 {
> -		phy-type = <PHY_TYPE_USB3_HOST0>;
> -	};
> -
> -	phy2 {
> -		phy-type = <PHY_TYPE_KR>;
> -	};
> -
> -	phy3 {
> -		phy-type = <PHY_TYPE_SATA1>;
> -	};
> -
> -	phy4 {
> -		phy-type = <PHY_TYPE_USB3_HOST1>;
> -	};
> -
> -	phy5 {
> -		phy-type = <PHY_TYPE_PEX2>;
> -	};
> -};
> -
> -&cps_comphy {
> -	/*
> -	 * Serdes Configuration:
> -	 * Lane 0: SGMII2
> -	 * Lane 1: USB3_HOST0
> -	 * Lane 2: KR (10G)
> -	 * Lane 3: SATA1
> -	 * Lane 4: Unconnected
> -	 * Lane 5: PEX2x1
> -	 */
> -	phy0 {
> -		phy-type = <PHY_TYPE_SGMII2>;
> -		phy-speed = <PHY_SPEED_3_125G>;
> -	};
> -
> -	phy1 {
> -		phy-type = <PHY_TYPE_USB3_HOST0>;
> -	};
> -
> -	phy2 {
> -		phy-type = <PHY_TYPE_KR>;
> -	};
> -
> -	phy3 {
> -		phy-type = <PHY_TYPE_SATA1>;
> -	};
> -
> -	phy4 {
> -		phy-type = <PHY_TYPE_UNCONNECTED>;
> -	};
> -
> -	phy5 {
> -		phy-type = <PHY_TYPE_PEX2>;
> -	};
> -};
> -
> -&cpm_utmi0 {
> -	status = "okay";
> -};
> -
> -&cpm_utmi1 {
> -	status = "okay";
> -};
> -
>  &cps_utmi0 {
>  	status = "okay";
>  };
>

Reviewed-by: Stefan Roese <sr@denx.de>

Thanks,
Stefan

[U-Boot] [PATCH 1/3] arm64: mvebu: Trigger PCI devices scan at early init stage

[Konstantin Porotchkin]

On 03/30/2017 04:31 PM, Stefan Roese wrote:
> (adding Simon to Cc for PCI related question)
>
> On 28.03.2017 17:36, kostap at marvell.com wrote:
>> From: Konstantin Porotchkin <kostap@marvell.com>
>>
>> Add PCIe initialization at early init stage.
>> This operation has a side effect of detecting all PCIe
>> plug-in cards, so the operator is not obligated to issue
>> "pci enum" command though CLI for this purpose.
>
> I'm not sure, if this should be handled this way. Simon, how
> is such a default PCI scan with DM supposed to get done? Is
> there a way do do this automatically without the need that
> the user has to issue "pci enum" manually?
I was not sure either, but did not see any other way of doing so.
I asked to add this change by our Robot/Jenkins automation test team.
>
>> Also convert the SATA first device scan to a walk through
>> all availabel SATA devices.
>
> This should be done in a separate patch. But seeing this,
> won't this SATA / AHCI code be gone completely from this
> file, once this is converted into a "real" DM AHCI / SCSI
> driver (please look at my preliminary patch for this).
Will check your patch, thank you.
Maybe this change has to be completely removed if Simon guide me to the 
right solution for automatic PCIe enumeration.

>
>> Signed-off-by: Konstantin Porotchkin <kostap@marvell.com>
>> Cc: Stefan Roese <sr@denx.de>
>> Cc: Igal Liberman <igall@marvell.com>
>> Cc: Nadav Haklai <nadavh@marvell.com>
>> ---
>>  arch/arm/mach-mvebu/arm64-common.c | 13 +++++++++++--
>>  1 file changed, 11 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm/mach-mvebu/arm64-common.c
>> b/arch/arm/mach-mvebu/arm64-common.c
>> index 8f02655..ff28750 100644
>> --- a/arch/arm/mach-mvebu/arm64-common.c
>> +++ b/arch/arm/mach-mvebu/arm64-common.c
>> @@ -8,6 +8,7 @@
>>  #include <dm.h>
>>  #include <fdtdec.h>
>>  #include <libfdt.h>
>> +#include <pci.h>
>>  #include <asm/io.h>
>>  #include <asm/system.h>
>>  #include <asm/arch/cpu.h>
>> @@ -142,8 +143,16 @@ int arch_early_init_r(void)
>>              break;
>>      }
>>
>> -    /* Cause the SATA device to do its early init */
>> -    uclass_first_device(UCLASS_AHCI, &dev);
>> +    /* Cause the SATA devices to do their early init */
>> +    for (uclass_first_device(UCLASS_AHCI, &dev);
>> +         dev;
>> +         uclass_next_device(&dev))
>> +        ;
>> +
>> +#ifdef CONFIG_DM_PCI
>> +    /* Trigger PCIe devices detection */
>> +    pci_init();
>> +#endif
>>
>>      return 0;
>>  }
>>
>
> Thanks,
> Stefan

[U-Boot] [PATCH 1/3] arm64: mvebu: Trigger PCI devices scan at early init stage

[Simon Glass]

Hi Konstanitin,

On 30 March 2017 at 07:58, Konstantin Porotchkin <kostap@marvell.com> wrote:
>
>
> On 03/30/2017 04:31 PM, Stefan Roese wrote:
>>
>> (adding Simon to Cc for PCI related question)
>>
>> On 28.03.2017 17:36, kostap at marvell.com wrote:
>>>
>>> From: Konstantin Porotchkin <kostap@marvell.com>
>>>
>>> Add PCIe initialization at early init stage.
>>> This operation has a side effect of detecting all PCIe
>>> plug-in cards, so the operator is not obligated to issue
>>> "pci enum" command though CLI for this purpose.
>>
>>
>> I'm not sure, if this should be handled this way. Simon, how
>> is such a default PCI scan with DM supposed to get done? Is
>> there a way do do this automatically without the need that
>> the user has to issue "pci enum" manually?
>
> I was not sure either, but did not see any other way of doing so.
> I asked to add this change by our Robot/Jenkins automation test team.

It seems reasonable. We actually have some platforms that require PCI
buses to be probed before we know what devices are in the system, and
some of these are important.

For example, if your network controller is on PCI then U-Boot will not
know about it (unless you have it in the device tree) until PCI is
probed.

I am wondering whether we should add a uclass flag that indicates that
uclass members should be automatically probed on start-up?

It would not be set for SATA, but would be for PCI.

>>
>>
>>> Also convert the SATA first device scan to a walk through
>>> all availabel SATA devices.
>>
>>
>> This should be done in a separate patch. But seeing this,
>> won't this SATA / AHCI code be gone completely from this
>> file, once this is converted into a "real" DM AHCI / SCSI
>> driver (please look at my preliminary patch for this).
>
> Will check your patch, thank you.
> Maybe this change has to be completely removed if Simon guide me to the
> right solution for automatic PCIe enumeration.
>

Regards,
Simon

[U-Boot] [EXT] Re: [PATCH 1/3] arm64: mvebu: Trigger PCI devices scan at early init stage

[Konstantin Porotchkin]

Hi, Simon,

On 04/01/2017 07:23 AM, Simon Glass wrote:
> External Email
>
> ----------------------------------------------------------------------
> Hi Konstanitin,
>
> On 30 March 2017 at 07:58, Konstantin Porotchkin <kostap@marvell.com> wrote:
>>
>>
>> On 03/30/2017 04:31 PM, Stefan Roese wrote:
>>>
>>> (adding Simon to Cc for PCI related question)
>>>
>>> On 28.03.2017 17:36, kostap at marvell.com wrote:
>>>>
>>>> From: Konstantin Porotchkin <kostap@marvell.com>
>>>>
>>>> Add PCIe initialization at early init stage.
>>>> This operation has a side effect of detecting all PCIe
>>>> plug-in cards, so the operator is not obligated to issue
>>>> "pci enum" command though CLI for this purpose.
>>>
>>>
>>> I'm not sure, if this should be handled this way. Simon, how
>>> is such a default PCI scan with DM supposed to get done? Is
>>> there a way do do this automatically without the need that
>>> the user has to issue "pci enum" manually?
>>
>> I was not sure either, but did not see any other way of doing so.
>> I asked to add this change by our Robot/Jenkins automation test team.
>
> It seems reasonable. We actually have some platforms that require PCI
> buses to be probed before we know what devices are in the system, and
> some of these are important.
>
> For example, if your network controller is on PCI then U-Boot will not
> know about it (unless you have it in the device tree) until PCI is
> probed.
>
> I am wondering whether we should add a uclass flag that indicates that
> uclass members should be automatically probed on start-up?
>
> It would not be set for SATA, but would be for PCI.
Thank you for your explanation.
So, as the bottom line - Can I leave the PCIe init call in place and 
remove the SATA devices walk through from this patch?
In my case the PCIe devices should be initialized for detection of a 
network card.

Thanks
Kosta
>
>>>
>>>
>>>> Also convert the SATA first device scan to a walk through
>>>> all availabel SATA devices.
>>>
>>>
>>> This should be done in a separate patch. But seeing this,
>>> won't this SATA / AHCI code be gone completely from this
>>> file, once this is converted into a "real" DM AHCI / SCSI
>>> driver (please look at my preliminary patch for this).
>>
>> Will check your patch, thank you.
>> Maybe this change has to be completely removed if Simon guide me to the
>> right solution for automatic PCIe enumeration.
>>
>
> Regards,
> Simon
>

[U-Boot] [EXT] Re: [PATCH 1/3] arm64: mvebu: Trigger PCI devices scan at early init stage

[Simon Glass]

Hi,

On 2 April 2017 at 05:50, Konstantin Porotchkin <kostap@marvell.com> wrote:
> Hi, Simon,
>
> On 04/01/2017 07:23 AM, Simon Glass wrote:
>>
>> External Email
>>
>> ----------------------------------------------------------------------
>>
>> Hi Konstanitin,
>>
>> On 30 March 2017 at 07:58, Konstantin Porotchkin <kostap@marvell.com>
>> wrote:
>>>
>>>
>>>
>>> On 03/30/2017 04:31 PM, Stefan Roese wrote:
>>>>
>>>>
>>>> (adding Simon to Cc for PCI related question)
>>>>
>>>> On 28.03.2017 17:36, kostap at marvell.com wrote:
>>>>>
>>>>>
>>>>> From: Konstantin Porotchkin <kostap@marvell.com>
>>>>>
>>>>> Add PCIe initialization at early init stage.
>>>>> This operation has a side effect of detecting all PCIe
>>>>> plug-in cards, so the operator is not obligated to issue
>>>>> "pci enum" command though CLI for this purpose.
>>>>
>>>>
>>>>
>>>> I'm not sure, if this should be handled this way. Simon, how
>>>> is such a default PCI scan with DM supposed to get done? Is
>>>> there a way do do this automatically without the need that
>>>> the user has to issue "pci enum" manually?
>>>
>>>
>>> I was not sure either, but did not see any other way of doing so.
>>> I asked to add this change by our Robot/Jenkins automation test team.
>>
>>
>> It seems reasonable. We actually have some platforms that require PCI
>> buses to be probed before we know what devices are in the system, and
>> some of these are important.
>>
>> For example, if your network controller is on PCI then U-Boot will not
>> know about it (unless you have it in the device tree) until PCI is
>> probed.
>>
>> I am wondering whether we should add a uclass flag that indicates that
>> uclass members should be automatically probed on start-up?
>>
>> It would not be set for SATA, but would be for PCI.
>
> Thank you for your explanation.
> So, as the bottom line - Can I leave the PCIe init call in place and remove
> the SATA devices walk through from this patch?
> In my case the PCIe devices should be initialized for detection of a network
> card.
>

I think we should add a new DM_UC_FLAG_AUTO_PROBE to uclass.h which
causes U-Boot to probe all devices in that uclass. This code could be
added to dm_init_and_scan(). You could set the flag for PCI. Do you
want to work up a patch for that?

This is your board code so I don't have a strong opinion on exactly
what you do here - but I'd prefer to figure out a generic solution.

> Thanks
> Kosta
>
>>
>>>>
>>>>
>>>>> Also convert the SATA first device scan to a walk through
>>>>> all availabel SATA devices.
>>>>
>>>>
>>>>
>>>> This should be done in a separate patch. But seeing this,
>>>> won't this SATA / AHCI code be gone completely from this
>>>> file, once this is converted into a "real" DM AHCI / SCSI
>>>> driver (please look at my preliminary patch for this).
>>>
>>>
>>> Will check your patch, thank you.
>>> Maybe this change has to be completely removed if Simon guide me to the
>>> right solution for automatic PCIe enumeration.
>>>
>>
>> Regards,
>> Simon
>>

Regards,
Simon

[U-Boot] [PATCH 2/3] fix: mvebu: pcie_dw: Allow probing empty PCIe slots

[Stefan Roese]

On 28.03.2017 17:36, kostap at marvell.com wrote:
> From: Konstantin Porotchkin <kostap@marvell.com>
>
> This patch allows probing all PCIe nodes defined in DTS
> even if there no device connected to such node (no link).
> Without this fix the driver returns -ENODEV when the PCIe
> link is down. As result the pci_init function stops
> scanning bus on first empty PCIe slot and all devices
> located in higher numbered buses are not discovered.
>
> Signed-off-by: Konstantin Porotchkin <kostap@marvell.com>
> Cc: Stefan Roese <sr@denx.de>
> Cc: Igal Liberman <igall@marvell.com>
> Cc: Nadav Haklai <nadavh@marvell.com>

Applied to u-boot-marvell/master.

Thanks,
Stefan