* [U-Boot] [PATCH 0/3] Marvell A7K/A8K PCIe fixes and extensions
@ 2017-03-28 15:36 kostap at marvell.com
2017-03-28 15:36 ` [U-Boot] [PATCH 1/3] arm64: mvebu: Trigger PCI devices scan at early init stage kostap at marvell.com
` (2 more replies)
0 siblings, 3 replies; 12+ messages in thread
From: kostap at marvell.com @ 2017-03-28 15:36 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 12+ messages in thread* [U-Boot] [PATCH 1/3] arm64: mvebu: Trigger PCI devices scan at early init stage 2017-03-28 15:36 [U-Boot] [PATCH 0/3] Marvell A7K/A8K PCIe fixes and extensions kostap at marvell.com @ 2017-03-28 15:36 ` kostap at marvell.com 2017-03-30 13:31 ` Stefan Roese 2017-03-28 15:36 ` [U-Boot] [PATCH 2/3] fix: mvebu: pcie_dw: Allow probing empty PCIe slots kostap at marvell.com 2017-03-28 15:36 ` [U-Boot] [PATCH 3/3] mvebu: dts: a80x0: Sync the DB DTS with standard config A kostap at marvell.com 2 siblings, 1 reply; 12+ messages in thread From: kostap at marvell.com @ 2017-03-28 15:36 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply related [flat|nested] 12+ messages in thread
* [U-Boot] [PATCH 1/3] arm64: mvebu: Trigger PCI devices scan at early init stage 2017-03-28 15:36 ` [U-Boot] [PATCH 1/3] arm64: mvebu: Trigger PCI devices scan at early init stage kostap at marvell.com @ 2017-03-30 13:31 ` Stefan Roese 2017-03-30 13:58 ` Konstantin Porotchkin 0 siblings, 1 reply; 12+ messages in thread From: Stefan Roese @ 2017-03-30 13:31 UTC (permalink / raw) To: u-boot (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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* [U-Boot] [PATCH 1/3] arm64: mvebu: Trigger PCI devices scan at early init stage 2017-03-30 13:31 ` Stefan Roese @ 2017-03-30 13:58 ` Konstantin Porotchkin 2017-04-01 4:23 ` Simon Glass 0 siblings, 1 reply; 12+ messages in thread From: Konstantin Porotchkin @ 2017-03-30 13:58 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* [U-Boot] [PATCH 1/3] arm64: mvebu: Trigger PCI devices scan at early init stage 2017-03-30 13:58 ` Konstantin Porotchkin @ 2017-04-01 4:23 ` Simon Glass 2017-04-02 11:50 ` [U-Boot] [EXT] " Konstantin Porotchkin 0 siblings, 1 reply; 12+ messages in thread From: Simon Glass @ 2017-04-01 4:23 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* [U-Boot] [EXT] Re: [PATCH 1/3] arm64: mvebu: Trigger PCI devices scan at early init stage 2017-04-01 4:23 ` Simon Glass @ 2017-04-02 11:50 ` Konstantin Porotchkin 2017-04-09 19:27 ` Simon Glass 0 siblings, 1 reply; 12+ messages in thread From: Konstantin Porotchkin @ 2017-04-02 11:50 UTC (permalink / raw) To: u-boot 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 > ^ permalink raw reply [flat|nested] 12+ messages in thread
* [U-Boot] [EXT] Re: [PATCH 1/3] arm64: mvebu: Trigger PCI devices scan at early init stage 2017-04-02 11:50 ` [U-Boot] [EXT] " Konstantin Porotchkin @ 2017-04-09 19:27 ` Simon Glass 0 siblings, 0 replies; 12+ messages in thread From: Simon Glass @ 2017-04-09 19:27 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* [U-Boot] [PATCH 2/3] fix: mvebu: pcie_dw: Allow probing empty PCIe slots 2017-03-28 15:36 [U-Boot] [PATCH 0/3] Marvell A7K/A8K PCIe fixes and extensions kostap at marvell.com 2017-03-28 15:36 ` [U-Boot] [PATCH 1/3] arm64: mvebu: Trigger PCI devices scan at early init stage kostap at marvell.com @ 2017-03-28 15:36 ` kostap at marvell.com 2017-03-30 13:39 ` Stefan Roese 2017-05-09 14:42 ` Stefan Roese 2017-03-28 15:36 ` [U-Boot] [PATCH 3/3] mvebu: dts: a80x0: Sync the DB DTS with standard config A kostap at marvell.com 2 siblings, 2 replies; 12+ messages in thread From: kostap at marvell.com @ 2017-03-28 15:36 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply related [flat|nested] 12+ messages in thread
* [U-Boot] [PATCH 2/3] fix: mvebu: pcie_dw: Allow probing empty PCIe slots 2017-03-28 15:36 ` [U-Boot] [PATCH 2/3] fix: mvebu: pcie_dw: Allow probing empty PCIe slots kostap at marvell.com @ 2017-03-30 13:39 ` Stefan Roese 2017-05-09 14:42 ` Stefan Roese 1 sibling, 0 replies; 12+ messages in thread From: Stefan Roese @ 2017-03-30 13:39 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* [U-Boot] [PATCH 2/3] fix: mvebu: pcie_dw: Allow probing empty PCIe slots 2017-03-28 15:36 ` [U-Boot] [PATCH 2/3] fix: mvebu: pcie_dw: Allow probing empty PCIe slots kostap at marvell.com 2017-03-30 13:39 ` Stefan Roese @ 2017-05-09 14:42 ` Stefan Roese 1 sibling, 0 replies; 12+ messages in thread From: Stefan Roese @ 2017-05-09 14:42 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* [U-Boot] [PATCH 3/3] mvebu: dts: a80x0: Sync the DB DTS with standard config A 2017-03-28 15:36 [U-Boot] [PATCH 0/3] Marvell A7K/A8K PCIe fixes and extensions kostap at marvell.com 2017-03-28 15:36 ` [U-Boot] [PATCH 1/3] arm64: mvebu: Trigger PCI devices scan at early init stage kostap at marvell.com 2017-03-28 15:36 ` [U-Boot] [PATCH 2/3] fix: mvebu: pcie_dw: Allow probing empty PCIe slots kostap at marvell.com @ 2017-03-28 15:36 ` kostap at marvell.com 2017-03-30 13:40 ` Stefan Roese 2 siblings, 1 reply; 12+ messages in thread From: kostap at marvell.com @ 2017-03-28 15:36 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply related [flat|nested] 12+ messages in thread
* [U-Boot] [PATCH 3/3] mvebu: dts: a80x0: Sync the DB DTS with standard config A 2017-03-28 15:36 ` [U-Boot] [PATCH 3/3] mvebu: dts: a80x0: Sync the DB DTS with standard config A kostap at marvell.com @ 2017-03-30 13:40 ` Stefan Roese 0 siblings, 0 replies; 12+ messages in thread From: Stefan Roese @ 2017-03-30 13:40 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2017-05-09 14:42 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-03-28 15:36 [U-Boot] [PATCH 0/3] Marvell A7K/A8K PCIe fixes and extensions kostap at marvell.com 2017-03-28 15:36 ` [U-Boot] [PATCH 1/3] arm64: mvebu: Trigger PCI devices scan at early init stage kostap at marvell.com 2017-03-30 13:31 ` Stefan Roese 2017-03-30 13:58 ` Konstantin Porotchkin 2017-04-01 4:23 ` Simon Glass 2017-04-02 11:50 ` [U-Boot] [EXT] " Konstantin Porotchkin 2017-04-09 19:27 ` Simon Glass 2017-03-28 15:36 ` [U-Boot] [PATCH 2/3] fix: mvebu: pcie_dw: Allow probing empty PCIe slots kostap at marvell.com 2017-03-30 13:39 ` Stefan Roese 2017-05-09 14:42 ` Stefan Roese 2017-03-28 15:36 ` [U-Boot] [PATCH 3/3] mvebu: dts: a80x0: Sync the DB DTS with standard config A kostap at marvell.com 2017-03-30 13:40 ` Stefan Roese
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.