RE: [PATCH] arch: arm: recode the initialization of GICv3 ITS Re-Distributor tables
Hi Marc,
Thanks a lot for your comments!
> -Original Message-
> From: Marc Zyngier
> Sent: 2022年2月26日 19:10
> To: Z.Q. Hou
> Cc: u-boot@lists.denx.de; s...@chromium.org;
> bharat.go...@broadcom.com; Priyanka Jain ;
> mich...@walle.cc
> Subject: Re: [PATCH] arch: arm: recode the initialization of GICv3 ITS
> Re-Distributor tables
>
> On Fri, 25 Feb 2022 13:41:06 +,
> Zhiqiang Hou wrote:
> >
> > From: Hou Zhiqiang
> >
> > The current implementation needs the caller provides the memory region
> > for the property and pending tables and the number of re-distibutor,
> > and it doesn't handle the address alignment of the tables and doesn't
> > help to add the reserved-memory node for the tables.
> >
> > This patch change to use the device tree blob as argument and deal
> > with the aboves in the internal of this helper to make it easier to use.
> >
> > Signed-off-by: Hou Zhiqiang
> > ---
> > arch/arm/Kconfig| 1 -
> > arch/arm/cpu/armv8/fsl-layerscape/fdt.c | 4 +-
> > arch/arm/cpu/armv8/fsl-layerscape/soc.c | 46 +---
> > arch/arm/include/asm/gic-v3.h | 4 +-
> > arch/arm/lib/gic-v3-its.c | 142 ++--
> > 5 files changed, 62 insertions(+), 135 deletions(-)
> >
> > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index
> > 391a77c2b4..0f6a32b428 100644
> > --- a/arch/arm/Kconfig
> > +++ b/arch/arm/Kconfig
> > @@ -82,7 +82,6 @@ config GICV3
> >
> > config GIC_V3_ITS
> > bool "ARM GICV3 ITS"
> > - select IRQ
> > help
> > ARM GICV3 Interrupt translation service (ITS).
> > Basic support for programming locality specific peripheral diff
> > --git a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> > b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> > index 2fa7ebf163..10cb675fae 100644
> > --- a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> > +++ b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> > @@ -1,7 +1,7 @@
> > // SPDX-License-Identifier: GPL-2.0+
> > /*
> > * Copyright 2014-2015 Freescale Semiconductor, Inc.
> > - * Copyright 2020-2021 NXP
> > + * Copyright 2020-2022 NXP
>
> Really? Isn't that what the git log is for?
This is required by NXP policy.
>
> > */
> >
> > #include
> > @@ -653,7 +653,7 @@ void ft_cpu_setup(void *blob, struct bd_info *bd)
> > get_board_sys_clk(), 1);
> >
> > #ifdef CONFIG_GIC_V3_ITS
> > - ls_gic_rd_tables_init(blob);
> > + gic_lpi_tables_init(blob);
> > #endif
>
> gic_lpi_tables_init() already has a definition when CONFIG_GIC_V3_ITS isn't
> selected. Why the #ifdef-ery?
I'll remove it in next version.
>
> >
> > #if defined(CONFIG_PCIE_LAYERSCAPE) ||
> > defined(CONFIG_PCIE_LAYERSCAPE_GEN4)
> > diff --git a/arch/arm/cpu/armv8/fsl-layerscape/soc.c
> > b/arch/arm/cpu/armv8/fsl-layerscape/soc.c
> > index d3a5cfaac1..51ed942f57 100644
> > --- a/arch/arm/cpu/armv8/fsl-layerscape/soc.c
> > +++ b/arch/arm/cpu/armv8/fsl-layerscape/soc.c
> > @@ -1,17 +1,15 @@
> > // SPDX-License-Identifier: GPL-2.0+
> > /*
> > * Copyright 2014-2015 Freescale Semiconductor
> > - * Copyright 2019-2021 NXP
> > + * Copyright 2019-2022 NXP
> > */
> >
> > #include
> > #include
> > -#include
> > #include
> > #include
> > #include
> > #include
> > -#include
> > #include
> > #include
> > #include
> > @@ -21,7 +19,6 @@
> > #include
> > #include
> > #include
> > -#include
> > #ifdef CONFIG_LAYERSCAPE_NS_ACCESS
> > #include
> > #endif
> > @@ -36,47 +33,6 @@
> > #include
> > #include
> > #include
> > -#ifdef CONFIG_GIC_V3_ITS
> > -DECLARE_GLOBAL_DATA_PTR;
> > -#endif
> > -
> > -#ifdef CONFIG_GIC_V3_ITS
> > -#define PENDTABLE_MAX_SZ ALIGN(BIT(ITS_MAX_LPI_NRBITS), SZ_64K)
> > -#define PROPTABLE_MAX_SZ ALIGN(BIT(ITS_MAX_LPI_NRBITS) / 8,
> SZ_64K)
> > -#define GIC_LPI_SIZE ALIGN(cpu_numcores() *
> PENDTABLE_MAX_SZ + \
> > - PROPTABLE_MAX_SZ, SZ_1M)
> > -static int fdt_add_resv_mem_gic_rd_tables(void *blob, u64 base,
> > size_t size) -{
> > - int err;
> > - struct fdt_memory gic_rd_tables;
> > -
> > - gic_rd_tables.start = base;
> > - gic_rd_tables.end = base + size - 1;
> > - err = fdtdec_add_reserved_memory(blob, "gic-rd-tables",
> _rd_tables,
> > -
RE: [PATCH] armv8: fsl-layerscape: use previous aligned address for gic_lpi_base
Hi Wasim, Marc and all, > -Original Message- > From: Wasim Khan (OSS) > Sent: 2022年2月21日 21:23 > To: Marc Zyngier ; Michael Walle ; > Z.Q. Hou > Cc: Wasim Khan (OSS) ; s...@chromium.org; > Priyanka Jain ; tred...@nvidia.com; > twar...@nvidia.com; Varun Sethi ; > u-boot@lists.denx.de > Subject: RE: [PATCH] armv8: fsl-layerscape: use previous aligned address for > gic_lpi_base > > Hi Marc, Zhiqiang > > > -Original Message- > > From: Marc Zyngier > > Sent: Monday, February 21, 2022 4:23 PM > > To: Michael Walle > > Cc: Wasim Khan (OSS) ; s...@chromium.org; > > Priyanka Jain ; tred...@nvidia.com; > > twar...@nvidia.com; Varun Sethi ; u- > > b...@lists.denx.de; Wasim Khan > > Subject: Re: [PATCH] armv8: fsl-layerscape: use previous aligned > > address for gic_lpi_base > > > > On Mon, 21 Feb 2022 10:24:36 +, > > Michael Walle wrote: > > > > > > Hi, > > > > > > Am 2022-02-21 11:16, schrieb Wasim Khan: > > > > From: Wasim Khan > > > > > > > > Memory after gd->arch.resv_ram is reserved for MC block. > > > > Use ALIGN_DOWN to avoid updating MC block for unaligned address. > > > > > > I cannot really tell what you are trying to do here. But I know Marc > > > has offered to also take a look at the GIC/LPI stuff. So I've put > > > him on CC. > > > > > > -michael > > > > > > > > > > > Signed-off-by: Wasim Khan > > > > --- > > > > arch/arm/cpu/armv8/fsl-layerscape/soc.c | 2 +- > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > diff --git a/arch/arm/cpu/armv8/fsl-layerscape/soc.c > > > > b/arch/arm/cpu/armv8/fsl-layerscape/soc.c > > > > index d3a5cfaac1..746c93cf51 100644 > > > > --- a/arch/arm/cpu/armv8/fsl-layerscape/soc.c > > > > +++ b/arch/arm/cpu/armv8/fsl-layerscape/soc.c > > > > @@ -65,7 +65,7 @@ int ls_gic_rd_tables_init(void *blob) > > > > u64 gic_lpi_base; > > > > int ret; > > > > > > > > - gic_lpi_base = ALIGN(gd->arch.resv_ram - GIC_LPI_SIZE, SZ_64K); > > > > + gic_lpi_base = ALIGN_DOWN(gd->arch.resv_ram - GIC_LPI_SIZE, > > > > +SZ_64K); > > > > ret = fdt_add_resv_mem_gic_rd_tables(blob, gic_lpi_base, > > > > GIC_LPI_SIZE); > > > > if (ret) > > > > return ret; > > > > > > > It is the usual accumulation of nonsense. We have > > > > #define ITS_MAX_LPI_NRBITS16 > > > > which is not necessarily what the HW exposes > > > > #define PENDTABLE_MAX_SZALIGN(BIT(ITS_MAX_LPI_NRBITS), > SZ_64K) > > > > The *base* of the pending table has to be 64kB aligned, but not its > > size. Yes, that's a helpful shortcut, but that's still wrong. > > > > #define PROPTABLE_MAX_SZALIGN(BIT(ITS_MAX_LPI_NRBITS) / > 8, > > SZ_64K) > > > > This 64kB alignment is silly, specially considering the hardcoding of > > the number of ID bits. > > > > #define GIC_LPI_SIZEALIGN(cpu_numcores() * > PENDTABLE_MAX_SZ + > > \ > > PROPTABLE_MAX_SZ, SZ_1M) > > > > This 1MB alignment doesn't exist. Convenience again? > > > > And then this patch adds some bizarre alignment for reasons that have > > nothing to do with the GIC, but because there is so other reservations > > this steps on, which probably means that the allocator is doing something > wrong... > > > > The whole thing needs reworking from first principle, at which point > > it will become clearer what this is trying to do. > > > > M. > > > > -- > > Without deviation from the norm, progress is not possible. > > > Added Zhiqiang to respond to Marc's questions. I've submit a patch to recode the whole gic-v3-its.c, with that patch we don't need these platform specific code anymore, I pasted its link below for your reference: http://patchwork.ozlabs.org/project/uboot/patch/20220225134106.24186-1-zhiqiang@nxp.com/ Thanks, Zhiqiang > > > Regarding this patch: > if gd->arch.resv_ram points to some address which is not 64K aligned (as per > current code), Using ALIGN can be problematic in that case. > > Ex: > Currently MC reserved regions is [0x27_8000_ , 0x27__] > gd->arch.resv_ram point to 0x27_8000_. > > Now suppose if I have requirement to reserve a block (say XYZ) of 32KB size > just before MC block, i will update gd->arch.resv_ram to point to > 0x27_7FFF_8000. > Now, Calling ' gic_lpi_base = ALIGN(gd->arch.resv_ram - GIC_LPI_SIZE, > SZ_64K);' will eat up space reserved for XYZ. > > So, I think ALIGN_DOWN should be used for gic_lpi_base . > gic_lpi_base = ALIGN_DOWN(gd->arch.resv_ram - GIC_LPI_SIZE, SZ_64K);
RE: [PATCH v2] tools: mkimage: Call verify_header after writing image to disk
> -Original Message- > From: Pali Rohár > Sent: 2022年2月16日 3:52 > To: Priyanka Jain > Cc: Tom Rini ; Alison Wang ; > Mingkai Hu ; Rajesh Bhagat > ; Jiafei Pan ; Simon Glass > ; Alexandru Gagniuc ; Yann > Dirson ; Stefan Roese ; Marek > Behún ; u-boot@lists.denx.de > Subject: Re: [PATCH v2] tools: mkimage: Call verify_header after writing > image to disk > > On Wednesday 02 February 2022 09:06:30 Priyanka Jain wrote: > > >-Original Message- > > >From: Tom Rini > > >Sent: Saturday, January 22, 2022 10:05 PM > > >To: Pali Rohár ; Alison Wang ; > > >Priyanka Jain ; Mingkai Hu > > >; Rajesh Bhagat > > >Cc: Simon Glass ; Alexandru Gagniuc > > >; Yann Dirson ; > Stefan > > >Roese ; Marek Behún ; u- > > >b...@lists.denx.de > > >Subject: Re: [PATCH v2] tools: mkimage: Call verify_header after > > >writing image to disk > > > > > >On Sat, Jan 22, 2022 at 05:31:18PM +0100, Pali Rohár wrote: > > >> On Friday 21 January 2022 21:15:43 Tom Rini wrote: > > >> > On Sat, Jan 22, 2022 at 02:44:22AM +0100, Pali Rohár wrote: > > >> > > On Friday 21 January 2022 16:21:33 Tom Rini wrote: > > >> > > > On Fri, Jan 14, 2022 at 06:34:43PM +0100, Pali Rohár wrote: > > >> > > > > > >> > > > > If image backend provides verify_header callback then call > > >> > > > > it after writing image to disk. This ensures that written image > > >> > > > > is > correct. > > >> > > > > > > >> > > > > Signed-off-by: Pali Rohár > > >> > > > > Reviewed-by: Stefan Roese > > >> > > > > Reviewed-by: Simon Glass > > >> > > > > --- > > >> > > > > tools/mkimage.c | 41 > > >> > > > > + > > >> > > > > 1 file changed, 41 insertions(+) > > >> > > > > > >> > > > This breaks a number of platforms such as > > >> > > > ls1021atwr_sdcard_qspi and it's not clear to me why exactly. > > >> > > > > >> > > Maybe they were already broken and this patch just detected it? > > >> > > Or verify_header callback for particular image type is reject > > >> > > valid image? > > >> > > > > >> > > Do you have some pointers to failed build logs? > > >> > > > >> > Try building for ls1021atwr_sdcard_qspi with your patch applied, > > >> > the only new thing that's shown in the logs is the error message. > > >> > > >> So... I have tried following without this patch: > > >> > > >> $ make ls1021atwr_sdcard_qspi_defconfig $ make > > >> CROSS_COMPILE=arm-linux-gnueabi- -j8 > > >> > > >> It generated file spl/u-boot-spl.pbl without error. Now I called -l > > >> on this generated file for type pblimage and I got following output: > > >> > > >> $ ./tools/dumpimage -T pblimage -l spl/u-boot-spl.pbl GP Header: > > >> Size > > >> aa55aa55 LoadAddr 1ee0100 > > >> > > >> $ ./tools/mkimage -T pblimage -l spl/u-boot-spl.pbl GP Header: Size > > >> aa55aa55 LoadAddr 1ee0100 > > >> > > >> "GP Header:" line is from the TI OMAP image backend type gpimage or > > >> type omapimage (implemented in file gpimage-common.c). > > >> > > >> So it means that files generated by ls1021atwr_sdcard_qspi are > > >> already broken and my patch just detected it. Or it is also > > >> possible that validation code in pblimage.c file is incorrect and broken. > > >> > > >> What to do with it now? > > > > > >Thanks for digging. This is a problem for a number of the ls1021, > > >ls1043 and ls1046 platforms, so lets add some maintainers there. > > > > > >-- > > >Tom > > > > > > I will ask NXP-platform owners to check on this. > > > > Thanks > > Priyanka > > Hello! Any news on this? Indeed it is a historical problem and exposed by this patch. The problem is the RCW headers are different on PPC and ARM platforms, while ls1021a/ls1043a/ls1046a leveraged the PPC tool to generate PBL image, but didn’t handle this differentially, this result in the image header verification failed. I'll submit a patch to fix it. Thanks, Zhiqiang
RE: [PATCH 2/2] Revert "arch: arm: use dt and UCLASS_SYSCON to get gic lpi details"
> -Original Message-
> From: Marc Zyngier [mailto:m...@kernel.org]
> Sent: 2021年10月29日 5:09
> To: Michael Walle
> Cc: u-boot@lists.denx.de; Vladimir Oltean ; Z.Q. Hou
> ; Bharat Gooty ;
> Rayagonda Kokatanur ; Simon Glass
> ; Priyanka Jain ; Tom Rini
>
> Subject: Re: [PATCH 2/2] Revert "arch: arm: use dt and UCLASS_SYSCON to get
> gic
> lpi details"
>
> On Wed, 27 Oct 2021 17:54:54 +0100,
> Michael Walle wrote:
> >
> > Stop using the device tree as a source for ad-hoc information.
> >
> > This reverts commit 2ae7adc659f7fca9ea65df4318e5bca2b8274310.
> >
> > Signed-off-by: Michael Walle
> > ---
> > arch/arm/Kconfig| 2 -
> > arch/arm/cpu/armv8/fsl-layerscape/soc.c | 27 +-
> > arch/arm/include/asm/gic-v3.h | 4 +-
> > arch/arm/lib/gic-v3-its.c | 66 +++--
> > 4 files changed, 36 insertions(+), 63 deletions(-)
> >
> > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index
> > 02f8306f15..86c1ebde05 100644
> > --- a/arch/arm/Kconfig
> > +++ b/arch/arm/Kconfig
> > @@ -82,8 +82,6 @@ config GICV3
> >
> > config GIC_V3_ITS
> > bool "ARM GICV3 ITS"
> > - select REGMAP
> > - select SYSCON
> > select IRQ
> > help
> > ARM GICV3 Interrupt translation service (ITS).
> > diff --git a/arch/arm/cpu/armv8/fsl-layerscape/soc.c
> > b/arch/arm/cpu/armv8/fsl-layerscape/soc.c
> > index c0e100d21c..a08ed3f544 100644
> > --- a/arch/arm/cpu/armv8/fsl-layerscape/soc.c
> > +++ b/arch/arm/cpu/armv8/fsl-layerscape/soc.c
>
> Why is this FSL specific?
>
> > @@ -41,11 +41,36 @@ DECLARE_GLOBAL_DATA_PTR; #endif
> >
> > #ifdef CONFIG_GIC_V3_ITS
> > +#define PENDTABLE_MAX_SZ ALIGN(BIT(ITS_MAX_LPI_NRBITS), SZ_64K)
> > +#define PROPTABLE_MAX_SZ ALIGN(BIT(ITS_MAX_LPI_NRBITS) / 8,
> SZ_64K)
>
> This looks completely wrong.
>
> The pending table needs one bit per LPI, and the property table one byte per
> LPI.
> Here, you have it the other way around.
It's a typo, will fix after the revert patch applied.
> Also, the property table alignment
> requirement is 4kB, not 64kB, and its size is defined as the maximum number of
> LPIs - 8192.
As in the accessor gic_lpi_tables_init() there isn't alignment operation for
both property table and pending table, we have to pass a 64KB alignment
address, even though the property table only requires 4KB alignment.
>
> Finally, ITS_MAX_LPI_NRBITS is hardcoded to 16, while it can actually vary
> from 14
> to 32 (and even further limited by some hypervisors), depending on the
> implementation. Granted, this was broken before this patch, and in most cases,
> 64k is more than enough.
>
This is only for Layerscape platforms, so hardcoded to 16 bit works.
> However, given that this defining the number of LPIs for the lifetime of the
> system,
> it would be better to actually allocate what the HW advertises
> (GICD_TYPER.IDbits,
> capped by GICD_TYPER.num_LPIs).
>
> > +#define GIC_LPI_SIZE ALIGN(cpu_numcores() * PENDTABLE_MAX_SZ
> > + \
> > + PROPTABLE_MAX_SZ, SZ_1M)
>
> Why the 1MB alignment? There is no such requirement in the architecture (64kB
> for the pending tables, 4kB for the property table).
This is definition of the size instead of address, 1MB size alignment is to
ensure we have enough space to do address alignment, perhaps 64KB should be
enough.
>
> > +static int fdt_add_resv_mem_gic_rd_tables(void *blob, u64 base,
> > +size_t size) {
> > + int err;
> > + struct fdt_memory gic_rd_tables;
> > +
> > + gic_rd_tables.start = base;
> > + gic_rd_tables.end = base + size - 1;
> > + err = fdtdec_add_reserved_memory(blob, "gic-rd-tables", _rd_tables,
> > +NULL, 0, NULL, 0);
> > + if (err < 0)
> > + debug("%s: failed to add reserved memory: %d\n", __func__, err);
> > +
> > + return err;
> > +}
> > +
> > int ls_gic_rd_tables_init(void *blob) {
> > + u64 gic_lpi_base;
> > int ret;
> >
> > - ret = gic_lpi_tables_init();
> > + gic_lpi_base = ALIGN(gd->arch.resv_ram - GIC_LPI_SIZE, SZ_64K);
> > + ret = fdt_add_resv_mem_gic_rd_tables(blob, gic_lpi_base, GIC_LPI_SIZE);
> > + if (ret)
> > + return ret;
> > +
> > + ret = gic_lpi_tables_init(gic_lpi_base, cpu_numcores());
>
> This really should fetch the number of CPUs from the DT rather then some SoC
> specific black magic...
C
RE: [PATCH v5 23/28] pci: layerscape: add official ls1028a binding support
> -Original Message-
> From: Michael Walle [mailto:mich...@walle.cc]
> Sent: 2021年10月14日 0:14
> To: u-boot@lists.denx.de
> Cc: Jagan Teki ; Priyanka Jain
> ; Vladimir Oltean ; Tom Rini
> ; Peter Griffin ; Manivannan
> Sadhasivam ; Michael Walle
> ; Z.Q. Hou
> Subject: [PATCH v5 23/28] pci: layerscape: add official ls1028a binding
> support
>
> The official bindind of the PCIe controller of the ls1028a has the following
> compatible string:
> compatible = "fsl,ls1028a-pcie";
>
> Additionally, the resource names and count are different. Update the driver to
> support this binding and change the entry in the ls1028a device tree.
>
> Cc: Hou Zhiqiang
> Signed-off-by: Michael Walle
> ---
> arch/arm/dts/fsl-ls1028a.dtsi| 20 +--
> drivers/pci/pcie_layerscape_rc.c | 61 +++-
> 2 files changed, 53 insertions(+), 28 deletions(-)
>
> diff --git a/arch/arm/dts/fsl-ls1028a.dtsi b/arch/arm/dts/fsl-ls1028a.dtsi
> index
> cc055e65e5..435b965d00 100644
> --- a/arch/arm/dts/fsl-ls1028a.dtsi
> +++ b/arch/arm/dts/fsl-ls1028a.dtsi
> @@ -344,12 +344,10 @@
> };
>
> pcie1: pcie@340 {
> - compatible = "fsl,ls-pcie", "fsl,ls1028-pcie",
> "snps,dw-pcie";
> - reg = <0x00 0x0340 0x0 0x8
> -0x00 0x0348 0x0 0x4 /* lut registers */
> -0x00 0x034c 0x0 0x4 /* pf controls
> registers
> */
> -0x80 0x 0x0 0x2>; /* configuration
> space
> */
> - reg-names = "dbi", "lut", "ctrl", "config";
> + compatible = "fsl,ls1028a-pcie";
> + reg = <0x00 0x0340 0x0 0x0010>, /* controller
> registers
> */
> + <0x80 0x 0x0 0x2000>; /* configuration
> space */
> + reg-names = "regs", "config";
> #address-cells = <3>;
> #size-cells = <2>;
> device_type = "pci";
> @@ -360,12 +358,10 @@
> };
>
> pcie2: pcie@350 {
> - compatible = "fsl,ls-pcie", "fsl,ls1028-pcie",
> "snps,dw-pcie";
> - reg = <0x00 0x0350 0x0 0x8
> -0x00 0x0358 0x0 0x4 /* lut registers */
> -0x00 0x035c 0x0 0x4 /* pf controls
> registers
> */
> -0x88 0x 0x0 0x2>; /* configuration
> space
> */
> - reg-names = "dbi", "lut", "ctrl", "config";
> + compatible = "fsl,ls1028a-pcie";
> + reg = <0x00 0x0350 0x0 0x0010>, /* controller
> registers
> */
> + <0x88 0x 0x0 0x2000>; /* configuration
> space */
> + reg-names = "regs", "config";
> #address-cells = <3>;
> #size-cells = <2>;
> device_type = "pci";
> diff --git a/drivers/pci/pcie_layerscape_rc.c
> b/drivers/pci/pcie_layerscape_rc.c
> index f50d6ef653..217b420076 100644
> --- a/drivers/pci/pcie_layerscape_rc.c
> +++ b/drivers/pci/pcie_layerscape_rc.c
> @@ -21,6 +21,12 @@
>
> DECLARE_GLOBAL_DATA_PTR;
>
> +struct ls_pcie_drvdata {
> + u32 lut_offset;
> + u32 ctrl_offset;
> + bool big_endian;
> +};
> +
> static void ls_pcie_cfg0_set_busdev(struct ls_pcie_rc *pcie_rc, u32 busdev)
> {
> struct ls_pcie *pcie = pcie_rc->pcie;
> @@ -243,6 +249,7 @@ static void ls_pcie_setup_ctrl(struct ls_pcie_rc *pcie_rc)
>
> static int ls_pcie_probe(struct udevice *dev) {
> + const struct ls_pcie_drvdata *drvdata = (void
> +*)dev_get_driver_data(dev);
> struct ls_pcie_rc *pcie_rc = dev_get_priv(dev);
> const void *fdt = gd->fdt_blob;
> int node = dev_of_offset(dev);
> @@ -260,8 +267,12 @@ static int ls_pcie_probe(struct udevice *dev)
>
> pcie_rc->pcie = pcie;
>
> + /* try resource name of the official binding first */
> ret = fdt_get_named_resource(fdt, node, "reg", "reg-names",
> - "dbi", _rc->dbi_res);
> + "regs", _rc->dbi_res);
&
RE: [PATCH v4 23/29] pci: layerscape: add official ls1028a binding support
> -Original Message-
> From: Michael Walle [mailto:mich...@walle.cc]
> Sent: 2021年10月13日 15:49
> To: Z.Q. Hou
> Cc: u-boot@lists.denx.de; Jagan Teki ; Priyanka
> Jain ; Vladimir Oltean ; Tom
> Rini ; Peter Griffin ;
> Manivannan
> Sadhasivam
> Subject: Re: [PATCH v4 23/29] pci: layerscape: add official ls1028a binding
> support
>
> Hi Zhiqiang,
>
> thanks for looking at this patch.
>
> Am 2021-10-13 03:46, schrieb Z.Q. Hou:
> >> -Original Message-
> >> From: Michael Walle
> >> Sent: 2021年10月5日 16:38
> >> To: u-boot@lists.denx.de
> >> Cc: Jagan Teki ; Priyanka Jain
> >> ; Vladimir Oltean ;
> >> Tom Rini ; Peter Griffin
> >> ; Manivannan Sadhasivam
> >> ; Michael Walle ;
> >> Z.Q. Hou
> >> Subject: [PATCH v4 23/29] pci: layerscape: add official ls1028a
> >> binding support
> >>
> >> The official bindind of the PCIe controller of the ls1028a has the
> >> following compatible string:
> >> compatible = "fsl,ls1028a-pcie";
> >>
> >> Additionally, the resource names and count are different. Update the
> >> driver to support this binding and change the entry in the ls1028a
> >> device tree.
> >>
> >> Cc: Hou Zhiqiang
> >> Signed-off-by: Michael Walle
> >> ---
> >> arch/arm/dts/fsl-ls1028a.dtsi| 20 +--
> >> drivers/pci/pcie_layerscape_rc.c | 61
> >> +++-
> >> 2 files changed, 53 insertions(+), 28 deletions(-)
> >>
> >> diff --git a/arch/arm/dts/fsl-ls1028a.dtsi
> >> b/arch/arm/dts/fsl-ls1028a.dtsi index cc055e65e5..435b965d00 100644
> >> --- a/arch/arm/dts/fsl-ls1028a.dtsi
> >> +++ b/arch/arm/dts/fsl-ls1028a.dtsi
> >> @@ -344,12 +344,10 @@
> >>};
> >>
> >>pcie1: pcie@340 {
> >> - compatible = "fsl,ls-pcie", "fsl,ls1028-pcie",
> >> "snps,dw-pcie";
> >> - reg = <0x00 0x0340 0x0 0x8
> >> - 0x00 0x0348 0x0 0x4 /* lut registers */
> >> - 0x00 0x034c 0x0 0x4 /* pf controls
> >> registers */
> >> - 0x80 0x 0x0 0x2>; /* configuration
> >> space */
> >> - reg-names = "dbi", "lut", "ctrl", "config";
> >> + compatible = "fsl,ls1028a-pcie";
> >> + reg = <0x00 0x0340 0x0 0x0010>, /* controller
> >> registers */
> >> +<0x80 0x 0x0 0x2000>; /* configuration
> >> space */
> >> + reg-names = "regs", "config";
> >>#address-cells = <3>;
> >>#size-cells = <2>;
> >>device_type = "pci";
> >> @@ -360,12 +358,10 @@
> >>};
> >>
> >>pcie2: pcie@350 {
> >> - compatible = "fsl,ls-pcie", "fsl,ls1028-pcie",
> >> "snps,dw-pcie";
> >> - reg = <0x00 0x0350 0x0 0x8
> >> - 0x00 0x0358 0x0 0x4 /* lut registers */
> >> - 0x00 0x035c 0x0 0x4 /* pf controls
> >> registers */
> >> - 0x88 0x 0x0 0x2>; /* configuration
> >> space */
> >> - reg-names = "dbi", "lut", "ctrl", "config";
> >> + compatible = "fsl,ls1028a-pcie";
> >> + reg = <0x00 0x0350 0x0 0x0010>, /* controller
> >> registers */
> >> +<0x88 0x 0x0 0x2000>; /* configuration
> >> space */
> >> + reg-names = "regs", "config";
> >>#address-cells = <3>;
> >>#size-cells = <2>;
> >>device_type = "pci";
> >> diff --git a/drivers/pci/pcie_layerscape_rc.c
> >> b/drivers/pci/pcie_layerscape_rc.c
> >> index f50d6ef653..217b420076 100644
> >> --- a/drivers/pci/pcie_layerscape_rc.c
> >> +++ b/drivers/pci/pcie_layerscape_rc.c
> >> @@ -21,6 +21,12 @@
> >>
> >>
RE: [PATCH v4 23/29] pci: layerscape: add official ls1028a binding support
> -Original Message-
> From: Michael Walle
> Sent: 2021年10月5日 16:38
> To: u-boot@lists.denx.de
> Cc: Jagan Teki ; Priyanka Jain
> ; Vladimir Oltean ;
> Tom Rini ; Peter Griffin ;
> Manivannan Sadhasivam ; Michael
> Walle ; Z.Q. Hou
> Subject: [PATCH v4 23/29] pci: layerscape: add official ls1028a binding
> support
>
> The official bindind of the PCIe controller of the ls1028a has the following
> compatible string:
> compatible = "fsl,ls1028a-pcie";
>
> Additionally, the resource names and count are different. Update the driver
> to support this binding and change the entry in the ls1028a device tree.
>
> Cc: Hou Zhiqiang
> Signed-off-by: Michael Walle
> ---
> arch/arm/dts/fsl-ls1028a.dtsi| 20 +--
> drivers/pci/pcie_layerscape_rc.c | 61 +++-
> 2 files changed, 53 insertions(+), 28 deletions(-)
>
> diff --git a/arch/arm/dts/fsl-ls1028a.dtsi b/arch/arm/dts/fsl-ls1028a.dtsi
> index cc055e65e5..435b965d00 100644
> --- a/arch/arm/dts/fsl-ls1028a.dtsi
> +++ b/arch/arm/dts/fsl-ls1028a.dtsi
> @@ -344,12 +344,10 @@
> };
>
> pcie1: pcie@340 {
> - compatible = "fsl,ls-pcie", "fsl,ls1028-pcie",
> "snps,dw-pcie";
> - reg = <0x00 0x0340 0x0 0x8
> -0x00 0x0348 0x0 0x4 /* lut registers */
> -0x00 0x034c 0x0 0x4 /* pf controls
> registers */
> -0x80 0x 0x0 0x2>; /* configuration
> space */
> - reg-names = "dbi", "lut", "ctrl", "config";
> + compatible = "fsl,ls1028a-pcie";
> + reg = <0x00 0x0340 0x0 0x0010>, /* controller
> registers */
> + <0x80 0x 0x0 0x2000>; /* configuration
> space */
> + reg-names = "regs", "config";
> #address-cells = <3>;
> #size-cells = <2>;
> device_type = "pci";
> @@ -360,12 +358,10 @@
> };
>
> pcie2: pcie@350 {
> - compatible = "fsl,ls-pcie", "fsl,ls1028-pcie",
> "snps,dw-pcie";
> - reg = <0x00 0x0350 0x0 0x8
> -0x00 0x0358 0x0 0x4 /* lut registers */
> -0x00 0x035c 0x0 0x4 /* pf controls
> registers */
> -0x88 0x 0x0 0x2>; /* configuration
> space */
> - reg-names = "dbi", "lut", "ctrl", "config";
> + compatible = "fsl,ls1028a-pcie";
> + reg = <0x00 0x0350 0x0 0x0010>, /* controller
> registers */
> + <0x88 0x 0x0 0x2000>; /* configuration
> space */
> + reg-names = "regs", "config";
> #address-cells = <3>;
> #size-cells = <2>;
> device_type = "pci";
> diff --git a/drivers/pci/pcie_layerscape_rc.c
> b/drivers/pci/pcie_layerscape_rc.c
> index f50d6ef653..217b420076 100644
> --- a/drivers/pci/pcie_layerscape_rc.c
> +++ b/drivers/pci/pcie_layerscape_rc.c
> @@ -21,6 +21,12 @@
>
> DECLARE_GLOBAL_DATA_PTR;
>
> +struct ls_pcie_drvdata {
> + u32 lut_offset;
> + u32 ctrl_offset;
> + bool big_endian;
The endianness property is better only put in the DT nodes.
The others looks good for me.
Thanks,
Zhiqiang
RE: [PATCH v3 25/29] arm: dts: ls1028a: move the PCI I/O window to match
> -Original Message- > From: Vladimir Oltean > Sent: 2021年9月15日 8:13 > To: Michael Walle ; Z.Q. Hou > Cc: u-boot@lists.denx.de; Jagan Teki ; > Priyanka Jain ; Tom Rini ; > Peter Griffin ; Manivannan Sadhasivam > > Subject: Re: [PATCH v3 25/29] arm: dts: ls1028a: move the PCI I/O window > to match > > On Thu, Sep 02, 2021 at 06:45:54PM +0200, Michael Walle wrote: > > To make the synchronization of the u-boot device tree with the one > > from linux easier, move the I/O window to the one which is specified > > in the linux device tree. The actual value shouldn't matter as long as > > it mapped to the corresponding memory window of the PCIe controller > > which is a 32GiB window at 80__h (first controller) or > > 88__h (second controller). > > > > Signed-off-by: Michael Walle > > --- > > arch/arm/dts/fsl-ls1028a.dtsi | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/arch/arm/dts/fsl-ls1028a.dtsi > > b/arch/arm/dts/fsl-ls1028a.dtsi index 3ef710bb3d..f11e75032b 100644 > > --- a/arch/arm/dts/fsl-ls1028a.dtsi > > +++ b/arch/arm/dts/fsl-ls1028a.dtsi > > @@ -352,7 +352,7 @@ > > #size-cells = <2>; > > device_type = "pci"; > > bus-range = <0x0 0xff>; > > - ranges = <0x8100 0x0 0x 0x80 0x0002 0x0 > 0x0001 /* downstream I/O */ > > + ranges = <0x8100 0x0 0x 0x80 0x0001 0x0 > 0x0001 /* downstream I/O */ > > 0x8200 0x0 0x4000 0x80 0x4000 0x0 > 0x4000>; /* non-prefetchable memory */ > > }; > > > > @@ -365,7 +365,7 @@ > > #size-cells = <2>; > > device_type = "pci"; > > bus-range = <0x0 0xff>; > > - ranges = <0x8100 0x0 0x 0x88 0x0002 0x0 > 0x0001 /* downstream I/O */ > > + ranges = <0x8100 0x0 0x 0x88 0x0001 0x0 > 0x0001 /* downstream I/O */ > > 0x8200 0x0 0x4000 0x88 0x4000 0x0 > 0x4000>; /* non-prefetchable memory */ > > }; > > > > -- > > 2.30.2 > > > > Zhiqiang, can you please review this patch? Reviewed-by: Hou Zhiqiang
RE: [PATCH 1/1] Revert "arm64: Layerscape: Survive LPI one-way reset workaround"
+ author of gic_lpi_syscon driver
Hi Rayagonda,
Please add the binding for gic_lpi_syscon driver.
Thanks,
Zhiqiang
> -Original Message-
> From: Tom Rini
> Sent: 2021年8月26日 5:05
> To: u-boot@lists.denx.de
> Cc: Z.Q. Hou ; Priyanka Jain
>
> Subject: [PATCH 1/1] Revert "arm64: Layerscape: Survive LPI one-way reset
> workaround"
>
> Ad-hoc bindings that are not part of the upstream device tree / bindings are
> not allowed in-tree. Only bindings that are in-progress with upstream and
> then re-synced once agreed upon are.
>
> This reverts commit af288cb291da3abef6be0875527729296f7de7a0.
>
> Cc: Hou Zhiqiang
> Cc: Priyanka Jain
> Reported-by: Michael Walle
> Signed-off-by: Tom Rini
> ---
> arch/arm/cpu/armv8/fsl-layerscape/soc.c | 17 +
> arch/arm/dts/fsl-ls1028a.dtsi | 6 --
> arch/arm/dts/fsl-ls1088a.dtsi | 6 --
> arch/arm/dts/fsl-ls2080a.dtsi | 6 --
> arch/arm/dts/fsl-lx2160a.dtsi | 6 --
> 5 files changed, 1 insertion(+), 40 deletions(-)
>
> diff --git a/arch/arm/cpu/armv8/fsl-layerscape/soc.c
> b/arch/arm/cpu/armv8/fsl-layerscape/soc.c
> index 42a096854629..12a64baf 100644
> --- a/arch/arm/cpu/armv8/fsl-layerscape/soc.c
> +++ b/arch/arm/cpu/armv8/fsl-layerscape/soc.c
> @@ -43,22 +43,7 @@ DECLARE_GLOBAL_DATA_PTR; #ifdef
> CONFIG_GIC_V3_ITS int ls_gic_rd_tables_init(void *blob) {
> - struct fdt_memory lpi_base;
> - fdt_addr_t addr;
> - fdt_size_t size;
> - int offset, ret;
> -
> - offset = fdt_path_offset(gd->fdt_blob, "/syscon@0x8000");
> - addr = fdtdec_get_addr_size_auto_noparent(gd->fdt_blob, offset,
> "reg",
> - 0, , false);
> -
> - lpi_base.start = addr;
> - lpi_base.end = addr + size - 1;
> - ret = fdtdec_add_reserved_memory(blob, "lpi_rd_table", _base,
> NULL, false);
> - if (ret) {
> - debug("%s: failed to add reserved memory\n", __func__);
> - return ret;
> - }
> + int ret;
>
> ret = gic_lpi_tables_init();
> if (ret)
> diff --git a/arch/arm/dts/fsl-ls1028a.dtsi b/arch/arm/dts/fsl-ls1028a.dtsi
> index 50f9b527cde1..53b052ed3271 100644
> --- a/arch/arm/dts/fsl-ls1028a.dtsi
> +++ b/arch/arm/dts/fsl-ls1028a.dtsi
> @@ -44,12 +44,6 @@
>IRQ_TYPE_LEVEL_LOW)>;
> };
>
> - gic_lpi_base: syscon@0x8000 {
> - compatible = "gic-lpi-base";
> - reg = <0x0 0x8000 0x0 0x10>;
> - max-gic-redistributors = <2>;
> - };
> -
> timer {
> compatible = "arm,armv8-timer";
> interrupts = a/arch/arm/dts/fsl-ls1088a.dtsi b/arch/arm/dts/fsl-ls1088a.dtsi index
> 64caa600ad77..3a5a50fb8313 100644
> --- a/arch/arm/dts/fsl-ls1088a.dtsi
> +++ b/arch/arm/dts/fsl-ls1088a.dtsi
> @@ -27,12 +27,6 @@
> interrupts = <1 9 0x4>;
> };
>
> - gic_lpi_base: syscon@0x8000 {
> - compatible = "gic-lpi-base";
> - reg = <0x0 0x8000 0x0 0x10>;
> - max-gic-redistributors = <8>;
> - };
> -
> timer {
> compatible = "arm,armv8-timer";
> interrupts = <1 13 0x8>, /* Physical Secure PPI, active-low */
> diff
> --git a/arch/arm/dts/fsl-ls2080a.dtsi b/arch/arm/dts/fsl-ls2080a.dtsi index
> 7374d580e07e..278daeeb6eea 100644
> --- a/arch/arm/dts/fsl-ls2080a.dtsi
> +++ b/arch/arm/dts/fsl-ls2080a.dtsi
> @@ -27,12 +27,6 @@
> interrupts = <1 9 0x4>;
> };
>
> - gic_lpi_base: syscon@0x8000 {
> - compatible = "gic-lpi-base";
> - reg = <0x0 0x8000 0x0 0x10>;
> - max-gic-redistributors = <8>;
> - };
> -
> timer {
> compatible = "arm,armv8-timer";
> interrupts = <1 13 0x8>, /* Physical Secure PPI, active-low */
> diff
> --git a/arch/arm/dts/fsl-lx2160a.dtsi b/arch/arm/dts/fsl-lx2160a.dtsi index
> a6f0e9bc56be..3b5f0d119e76 100644
> --- a/arch/arm/dts/fsl-lx2160a.dtsi
> +++ b/arch/arm/dts/fsl-lx2160a.dtsi
> @@ -43,12 +43,6 @@
> interrupts = <1 9 0x4>;
> };
>
> - gic_lpi_base: syscon@0x8000 {
> - compatible = "gic-lpi-base";
> - reg = <0x0 0x8000 0x0 0x20>;
> - max-gic-redistributors = <16>;
> - };
> -
> timer {
> compatible = "arm,armv8-timer";
> interrupts = <1 13 0x8>, /* Physical Secure PPI, active-low */
> --
> 2.17.1
RE: [PATCH] configs: Layerscape: Remove the 'fdt_addr' env
> -Original Message- > From: Priyanka Jain (OSS) > Sent: 2021年8月18日 18:33 > To: Z.Q. Hou ; u-boot@lists.denx.de > Cc: ykau...@suse.de; feste...@gmail.com; tr...@konsulko.com; Z.Q. Hou > > Subject: RE: [PATCH] configs: Layerscape: Remove the 'fdt_addr' env > > > > >-Original Message- > >From: U-Boot On Behalf Of Zhiqiang Hou > >Sent: Thursday, August 12, 2021 12:59 PM > >To: u-boot@lists.denx.de; Priyanka Jain > >Cc: ykau...@suse.de; feste...@gmail.com; tr...@konsulko.com; Z.Q. > Hou > > > >Subject: [PATCH] configs: Layerscape: Remove the 'fdt_addr' env > > > >From: Hou Zhiqiang > > > >On Layerscape platforms, the DTB is loaded from boot filesystem, per > >the fdt_addr description in doc/README.distro, it must be removed. > > > > Below description is unrelated . > It is due to some other issue. Kindly remove it from this patch. OK > > > >And on many platforms, like ls1046a, ls1088a, ls2088a and lx216xa, the > 'fdt_addr' > >pointed address is not accessible. > >And with the current EFI boot process, since the EFI_LOADER and > >CMD_BOOTEFI_BOOTMGR are enabled by default, if the EFI boot > components > >are not deployed in the boot filesystem, it will try to get DTB at address > 'fdt_addr' > >and then result in "SError" or "Synchronous Abort": > > > >Error log on ls1046ardb: > > => run distro_bootcmd > > switch to partitions #0, OK > > mmc0 is current device > > Scanning mmc 0:1... > > libfdt fdt_check_header(): FDT_ERR_BADMAGIC > > Scanning disk es...@156.blk... > > Found 5 disks > > No EFI system partition > > "Error" handler, esr 0xbf00 > > elr: 820704f4 lr : 820080d4 (reloc) > > elr: fbd914f4 lr : fbd290d4 > > x0 : 64f0 x1 : edfe0dd0 > > x2 : x3 : > > x4 : fbc2ee1a x5 : 000f > > x6 : x7 : 0008 > > x8 : 0010 x9 : 0008 > > x10: 0044 x11: 00080220 > > x12: fbdaa748 x13: fbda70f8 > > x14: fbd21d20 x15: fbc194e8 > > x16: fbd70fc8 x17: > > x18: fbc1cdb0 x19: fbd21bf0 > > x20: 64f0 x21: fbda6fb8 > > x22: 0018 x23: 0018 > > x24: fbde6344 x25: > > x26: x27: > > x28: fbc53660 x29: fbc19220 > > > > Code: 7a419060 1a9f3000 a8c17bfd d65f03c0 (12800100) > > > > Resetting CPU ... > > > >Signed-off-by: Hou Zhiqiang > >--- > > include/configs/ls1012a2g5rdb.h | 1 - > > include/configs/ls1012afrdm.h| 2 +- > > include/configs/ls1012afrwy.h| 1 - > > include/configs/ls1012aqds.h | 1 - > > include/configs/ls1012ardb.h | 1 - > > include/configs/ls1021atsn.h | 3 +-- > > include/configs/ls1021atwr.h | 4 +--- > > include/configs/ls1028aqds.h | 3 +-- > > include/configs/ls1028ardb.h | 3 +-- > > include/configs/ls1043a_common.h | 1 - > >include/configs/ls1046a_common.h | 1 - > > include/configs/ls1088ardb.h | 2 -- > > include/configs/ls2080ardb.h | 2 -- > > include/configs/lx2160a_common.h | 1 - > > 14 files changed, 5 insertions(+), 21 deletions(-) > > > >diff --git a/include/configs/ls1012a2g5rdb.h > >b/include/configs/ls1012a2g5rdb.h index 44f9da7306..d9ff011bac 100644 > >--- a/include/configs/ls1012a2g5rdb.h > >+++ b/include/configs/ls1012a2g5rdb.h > >@@ -29,7 +29,6 @@ > > #define CONFIG_EXTRA_ENV_SETTINGS \ > > "verify=no\0" \ > > "initrd_high=0x\0" \ > >-"fdt_addr=0x00f0\0" \ > > Getting below checkpatch error: > ERROR: fdt or initrd relocation disabled at boot time > #76: FILE: include/configs/ls1012a2g5rdb.h:31: > "initrd_high=0x\0" \ > > Kindly remove unused 'initrd_high' variable as well in this patch in all > header > files. No, the 'initrd_high' is the context, but it's not changed in this patch. Thanks, Zhiqiang > > Regards > Priyanka
RE: [PATCH] configs: Layerscape: Remove the 'fdt_addr' env
Hello Wolfgang, > -Original Message- > From: Wolfgang Denk > Sent: 2021年8月12日 15:24 > To: Z.Q. Hou > Cc: u-boot@lists.denx.de; Priyanka Jain ; > ykau...@suse.de; feste...@gmail.com; tr...@konsulko.com > Subject: Re: [PATCH] configs: Layerscape: Remove the 'fdt_addr' env > > Dear Zhiqiang Hou, > > In message <20210812072846.39305-1-zhiqiang@nxp.com> you wrote: > > > diff --git a/include/configs/ls1012afrdm.h > > b/include/configs/ls1012afrdm.h index 2711f651d7..c7fdd10cf5 100644 > > --- a/include/configs/ls1012afrdm.h > > +++ b/include/configs/ls1012afrdm.h > > @@ -1,6 +1,7 @@ > > /* SPDX-License-Identifier: GPL-2.0+ */ > > /* > > * Copyright 2016 Freescale Semiconductor, Inc. > > + * Copyright 2021 NXP > > */ > > > > #ifndef __LS1012ARDB_H__ > > @@ -24,7 +25,6 @@ > > #define CONFIG_EXTRA_ENV_SETTINGS \ > > "verify=no\0" \ > > "fdt_high=0x\0" \ > > - "fdt_addr=0x00f0\0" \ > > "kernel_addr=0x0100\0" \ > > "scriptaddr=0x8000\0" \ > > "fdtheader_addr_r=0x8010\0" \ > > diff --git a/include/configs/ls1012afrwy.h > > b/include/configs/ls1012afrwy.h > > Adding or - like here, even worse - removing just a few lines of data > definitions is certainly nothing where you can claim a copyright on. > It's NXP's legal check policy. Thanks, Zhiqiang > Best regards, > > Wolfgang Denk > > -- > DENX Software Engineering GmbH, Managing Director: Wolfgang > Denk > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany > Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de > HR Manager to job candidate "I see you've had no computer training. > Although that qualifies you for upper management, it means you're > under-qualified for our entry level positions."
RE: [PATCH] configs: layerscape: Disable the EFI_LOADER feature
> -Original Message- > From: Mian Yousaf Kaukab > Sent: 2021年8月3日 22:52 > To: Z.Q. Hou > Cc: Michael Walle ; Tom Rini ; > Heinrich Schuchardt ; u-boot@lists.denx.de; Priyanka > Jain > Subject: Re: [PATCH] configs: layerscape: Disable the EFI_LOADER feature > > On Mon, Jul 26, 2021 at 07:37:53AM +, Z.Q. Hou wrote: > > Hi Micheal, > > > > Pasted the log below, the direct cause seems the u-boot DTB doesn't have > /cpus node. > > > > => run bootcmd_mmc0 > > switch to partitions #0, OK > > mmc0 is current device > > Scanning mmc 0:1... > > libfdt fdt_check_header(): FDT_ERR_BADMAGIC Scanning disk > > es...@156.blk... > > Found 5 disks > > No EFI system partition > > couldn't find /cpus > > "Synchronous Abort" handler, esr 0x9606 > > elr: 82004a6c lr : 82004a30 (reloc) > > elr: fbd25a6c lr : fbd25a30 > > x0 : 87f00a88 x1 : 1cfbfd5e > > x2 : efbeaddeefbeadde x3 : efbeadde > > x4 : fffc x5 : 87f037d2 > > x6 : 0a58 x7 : 0003 > > x8 : 87f0 x9 : 0008 > > x10: 0a44 x11: fbc17c6c > > x12: 09e4 x13: > > x14: 87f0 x15: fbc180d8 > > x16: fbd742d0 x17: > > x18: fbc1cdb0 x19: 09e4 > > x20: 87f0 x21: fbdb3404 > > x22: fbdb4a97 x23: 0018 > > x24: fbde5d44 x25: > > x26: x27: > > x28: fbc5ba60 x29: fbc17d30 > > > > Code: a94153f3 a9425bf5 a8c47bfd d65f03c0 (b8617803) Resetting CPU ... > > > > > > > > > > And why don't you fix the fdt_addr then? Shouldn't it be unset if there is > no > > > actual device tree present in a ROM section? (I don't say there isn't > another > > > underlying problem when you use an invalid fdt_addr). > > > > The problem shown in above log is triggered when unset the fdt_addr. > On which platform are you seeing this issue? > > I have tested v2021.07 on ls1043a-rdb and it doesn't reproduce. On LS1043ARDB, the fdt_addr points to the NOR flash, so no this issue. Reproduce on LS1046ARDB, on which no NOR flash is mapped to that space. > > Board is booting from NOR and I have two mmc partitions: > Device Start End Sectors Size Type > /dev/mmcblk0p12048 1048576 1046529 511M Linux filesystem > /dev/mmcblk0p2 1050624 15523806 14473183 6.9G Linux filesystem > > => run bootcmd_mmc0 > switch to partitions #0, OK > mmc0 is current device > Scanning mmc 0:1... > Scanning disk es...@156.blk... > Found 3 disks > No EFI system partition > PCIe1: pcie@340 disabled > PCIe2: pcie@350 Root Complex: no link > PCIe3: pcie@360 Root Complex: no link > WARNING failed to get smmu node: FDT_ERR_NOTFOUND > WARNING failed to get smmu node: FDT_ERR_NOTFOUND > BootOrder not defined > EFI boot manager: Cannot load any image > Scanning mmc 0:2... > WARNING failed to get smmu node: FDT_ERR_NOTFOUND > WARNING failed to get smmu node: FDT_ERR_NOTFOUND > BootOrder not defined > EFI boot manager: Cannot load any image > => > > I still don't see the issue even if I remove fdt_addr: > => setenv fdt_addr > => run bootcmd_mmc0 > switch to partitions #0, OK > mmc0 is current device > Scanning mmc 0:1... > WARNING failed to get smmu node: FDT_ERR_NOTFOUND > WARNING failed to get smmu node: FDT_ERR_NOTFOUND > BootOrder not defined > EFI boot manager: Cannot load any image > Scanning mmc 0:2... > WARNING failed to get smmu node: FDT_ERR_NOTFOUND > WARNING failed to get smmu node: FDT_ERR_NOTFOUND > BootOrder not defined > EFI boot manager: Cannot load any image > => Dig deeper, it's a NXP internal patch that results in the SError, upsteam doesn't have this problem. The SError is triggered during the DT setup phase of bootefi when using the u-boot packaged fdt. To resolve the 'Sync Abort' issue, I'll send a patch to remove the 'fdt_addr' env, it was added by mistake since the DTB is loaded from boot filesystem instead of hardware ROM. Thanks, Zhiqiang > > > If it not unset, the SError is triggered when to check the magic of the fdt > header. > > > > Thanks, > > Zhiqiang > > > > > > > > -michael > BR, > Yousaf
RE: [PATCH] configs: layerscape: Disable the EFI_LOADER feature
> -Original Message-
> From: Tom Rini
> Sent: 2021年7月27日 21:08
> To: Z.Q. Hou
> Cc: Michael Walle ; Heinrich Schuchardt
> ; u-boot@lists.denx.de; Priyanka Jain
>
> Subject: Re: [PATCH] configs: layerscape: Disable the EFI_LOADER feature
>
> On Tue, Jul 27, 2021 at 05:42:51AM +, Z.Q. Hou wrote:
> > Hi Tom,
> >
> > > -Original Message-
> > > From: Tom Rini
> > > Sent: 2021年7月26日 20:29
> > > To: Z.Q. Hou
> > > Cc: Michael Walle ; Heinrich Schuchardt
> > > ; u-boot@lists.denx.de; Priyanka Jain
> > >
> > > Subject: Re: [PATCH] configs: layerscape: Disable the EFI_LOADER
> > > feature
> > >
> > > On Mon, Jul 26, 2021 at 07:37:53AM +, Z.Q. Hou wrote:
> > > > Hi Micheal,
> > > >
> > > > > -Original Message-
> > > > > From: Michael Walle
> > > > > Sent: 2021年7月26日 15:13
> > > > > To: Z.Q. Hou
> > > > > Cc: Tom Rini ; Heinrich Schuchardt
> > > > > ; u-boot@lists.denx.de; Priyanka Jain
> > > > >
> > > > > Subject: Re: [PATCH] configs: layerscape: Disable the EFI_LOADER
> > > > > feature
> > > > >
> > > > > Am 2021-07-26 09:01, schrieb Z.Q. Hou:
> > > > > > Hi Michael,
> > > > > >
> > > > > >> -Original Message-
> > > > > >> From: Michael Walle
> > > > > >> Sent: 2021年7月23日 1:01
> > > > > >> To: Tom Rini
> > > > > >> Cc: Z.Q. Hou ; Heinrich Schuchardt
> > > > > >> ; u-boot@lists.denx.de; Priyanka Jain
> > > > > >>
> > > > > >> Subject: Re: [PATCH] configs: layerscape: Disable the
> > > > > >> EFI_LOADER feature
> > > > > >>
> > > > > >> Am 2021-07-22 17:26, schrieb Tom Rini:
> > > > > >> > On Thu, Jul 22, 2021 at 02:25:59PM +0800, Zhiqiang Hou wrote:
> > > > > >> >
> > > > > >> >> From: Hou Zhiqiang
> > > > > >> >>
> > > > > >> >> The feature BOOTENV_SHARED_EFI is not supported on
> > > > > >> >> layerscape
> > > > > >> boards,
> > > > > >> >> it didn't result kernel boot crash previously since there
> > > > > >> >> isn't the efi/boot/"BOOTEFI_NAME" and it skip calling of
> > > 'boot_efi_binary'.
> > > > > >> >>
> > > > > >> >> But since the commit f3866909e350 ("distro_bootcmd: call
> > > > > >> >> EFI bootmgr even without having /EFI/boot"), it will cause
> > > > > >> >> kernel boot crash as there isn't a valid fdt_addr and it
> > > > > >> >> finially uses the device tree blob of U-Boot and further cause
> errors.
> > > > > >> >>
> > > > > >> >> As this feature is enabled by default for armv7 and armv8,
> > > > > >> >> so disable it explicitly to avoid calling the
> > > > > >> >> 'scan_dev_for_efi'.
> > > > > >> >
> > > > > >> > I'm not thrilled with this. Why isn't the solution to get
> > > > > >> > and keep in sync the device trees, so that the tree U-Boot
> > > > > >> > has is valid for the kernel? I'm also open to discussing
> > > > > >> > f3866909e350 more. But I'm really opposed to disabling
> > > > > >> > EFI_LOADER on modern platforms as that will make adoption
> > > > > >> > of U-Boot in device harder I
> > > feel.
> > > > > >>
> > > > > >> I don't know whats going on with the NXP boards, but the sl28
> > > > > >> is a layerscape board it is working pretty well with EFI boot.
> > > > > >
> > > > > > Do you mean the EFI boot work well on sl28?
> > > > > This, for example, I can boot the debian installer
> > > > > out-of-the-box, given that the fdtfile variable is set correctly.
> > > >
> > > > Oh, we are talking on different case.
> > > >
> > > > >
> > > > > > Or the EFI boot doesn't break other boot ways?
> > > > > >
> > > > > > In my case, there are
RE: [PATCH] configs: layerscape: Disable the EFI_LOADER feature
Hi Tom,
> -Original Message-
> From: Tom Rini
> Sent: 2021年7月26日 20:29
> To: Z.Q. Hou
> Cc: Michael Walle ; Heinrich Schuchardt
> ; u-boot@lists.denx.de; Priyanka Jain
>
> Subject: Re: [PATCH] configs: layerscape: Disable the EFI_LOADER feature
>
> On Mon, Jul 26, 2021 at 07:37:53AM +, Z.Q. Hou wrote:
> > Hi Micheal,
> >
> > > -Original Message-
> > > From: Michael Walle
> > > Sent: 2021年7月26日 15:13
> > > To: Z.Q. Hou
> > > Cc: Tom Rini ; Heinrich Schuchardt
> > > ; u-boot@lists.denx.de; Priyanka Jain
> > >
> > > Subject: Re: [PATCH] configs: layerscape: Disable the EFI_LOADER
> > > feature
> > >
> > > Am 2021-07-26 09:01, schrieb Z.Q. Hou:
> > > > Hi Michael,
> > > >
> > > >> -Original Message-
> > > >> From: Michael Walle
> > > >> Sent: 2021年7月23日 1:01
> > > >> To: Tom Rini
> > > >> Cc: Z.Q. Hou ; Heinrich Schuchardt
> > > >> ; u-boot@lists.denx.de; Priyanka Jain
> > > >>
> > > >> Subject: Re: [PATCH] configs: layerscape: Disable the EFI_LOADER
> > > >> feature
> > > >>
> > > >> Am 2021-07-22 17:26, schrieb Tom Rini:
> > > >> > On Thu, Jul 22, 2021 at 02:25:59PM +0800, Zhiqiang Hou wrote:
> > > >> >
> > > >> >> From: Hou Zhiqiang
> > > >> >>
> > > >> >> The feature BOOTENV_SHARED_EFI is not supported on layerscape
> > > >> boards,
> > > >> >> it didn't result kernel boot crash previously since there
> > > >> >> isn't the efi/boot/"BOOTEFI_NAME" and it skip calling of
> 'boot_efi_binary'.
> > > >> >>
> > > >> >> But since the commit f3866909e350 ("distro_bootcmd: call EFI
> > > >> >> bootmgr even without having /EFI/boot"), it will cause kernel
> > > >> >> boot crash as there isn't a valid fdt_addr and it finially
> > > >> >> uses the device tree blob of U-Boot and further cause errors.
> > > >> >>
> > > >> >> As this feature is enabled by default for armv7 and armv8, so
> > > >> >> disable it explicitly to avoid calling the 'scan_dev_for_efi'.
> > > >> >
> > > >> > I'm not thrilled with this. Why isn't the solution to get and
> > > >> > keep in sync the device trees, so that the tree U-Boot has is
> > > >> > valid for the kernel? I'm also open to discussing f3866909e350
> > > >> > more. But I'm really opposed to disabling EFI_LOADER on modern
> > > >> > platforms as that will make adoption of U-Boot in device harder I
> feel.
> > > >>
> > > >> I don't know whats going on with the NXP boards, but the sl28 is
> > > >> a layerscape board it is working pretty well with EFI boot.
> > > >
> > > > Do you mean the EFI boot work well on sl28?
> > > This, for example, I can boot the debian installer out-of-the-box,
> > > given that the fdtfile variable is set correctly.
> >
> > Oh, we are talking on different case.
> >
> > >
> > > > Or the EFI boot doesn't break other boot ways?
> > > >
> > > > In my case, there are 4 MMC partitions and a boot script with boot
> > > > images in the 2nd partition, while nothing in the 1st partition.
> > > > So the expected boot flow is the 'bootcmd_mmc0' scan the 1st
> > > > partition and find it's not bootable and then the 2nd partition
> > > > and boot with the script. But actually the 'scan_dev_for_efi' got
> > > > problem when scan the 1st partition, as the u-boot DTB is used in
> > > > 'bootefi bootmgr' and result in some error related to the DTB.
> > >
> > > As mentioned in the other mail, I'm not sure why "bootefi bootmgr"
> > > does something at all, because AFAIK it needs the BootOrder/BootNext
> > > variables. Heinrich, please correct me if I'm wrong.
> >
> > I'm not familiar with EFI boot, In this case, the 'scan_dev_for_efi' calls
> > 'run
> boot_efi_bootmgr' then 'bootefi bootmgr', seems it doesn't check if the
> needed components exist.
> > Is the cmd 'scan_dev_for_efi' wrong?
>
> I'll let Heinrich comment on this part.
>
> > > > Actually, if give a readable but invalid 'fdt_addr' in env, the
> > > > EFI boot can
RE: [PATCH] configs: layerscape: Disable the EFI_LOADER feature
Hi Micheal,
> -Original Message-
> From: Michael Walle
> Sent: 2021年7月26日 15:13
> To: Z.Q. Hou
> Cc: Tom Rini ; Heinrich Schuchardt
> ; u-boot@lists.denx.de; Priyanka Jain
>
> Subject: Re: [PATCH] configs: layerscape: Disable the EFI_LOADER feature
>
> Am 2021-07-26 09:01, schrieb Z.Q. Hou:
> > Hi Michael,
> >
> >> -Original Message-
> >> From: Michael Walle
> >> Sent: 2021年7月23日 1:01
> >> To: Tom Rini
> >> Cc: Z.Q. Hou ; Heinrich Schuchardt
> >> ; u-boot@lists.denx.de; Priyanka Jain
> >>
> >> Subject: Re: [PATCH] configs: layerscape: Disable the EFI_LOADER
> >> feature
> >>
> >> Am 2021-07-22 17:26, schrieb Tom Rini:
> >> > On Thu, Jul 22, 2021 at 02:25:59PM +0800, Zhiqiang Hou wrote:
> >> >
> >> >> From: Hou Zhiqiang
> >> >>
> >> >> The feature BOOTENV_SHARED_EFI is not supported on layerscape
> >> boards,
> >> >> it didn't result kernel boot crash previously since there isn't
> >> >> the efi/boot/"BOOTEFI_NAME" and it skip calling of 'boot_efi_binary'.
> >> >>
> >> >> But since the commit f3866909e350 ("distro_bootcmd: call EFI
> >> >> bootmgr even without having /EFI/boot"), it will cause kernel boot
> >> >> crash as there isn't a valid fdt_addr and it finially uses the
> >> >> device tree blob of U-Boot and further cause errors.
> >> >>
> >> >> As this feature is enabled by default for armv7 and armv8, so
> >> >> disable it explicitly to avoid calling the 'scan_dev_for_efi'.
> >> >
> >> > I'm not thrilled with this. Why isn't the solution to get and keep
> >> > in sync the device trees, so that the tree U-Boot has is valid for
> >> > the kernel? I'm also open to discussing f3866909e350 more. But
> >> > I'm really opposed to disabling EFI_LOADER on modern platforms as
> >> > that will make adoption of U-Boot in device harder I feel.
> >>
> >> I don't know whats going on with the NXP boards, but the sl28 is a
> >> layerscape board it is working pretty well with EFI boot.
> >
> > Do you mean the EFI boot work well on sl28?
> This, for example, I can boot the debian installer out-of-the-box, given that
> the fdtfile variable is set correctly.
Oh, we are talking on different case.
>
> > Or the EFI boot doesn't break other boot ways?
> >
> > In my case, there are 4 MMC partitions and a boot script with boot
> > images in the 2nd partition, while nothing in the 1st partition. So
> > the expected boot flow is the 'bootcmd_mmc0' scan the 1st partition
> > and find it's not bootable and then the 2nd partition and boot with
> > the script. But actually the 'scan_dev_for_efi' got problem when scan
> > the 1st partition, as the u-boot DTB is used in 'bootefi bootmgr' and
> > result in some error related to the DTB.
>
> As mentioned in the other mail, I'm not sure why "bootefi bootmgr"
> does something at all, because AFAIK it needs the BootOrder/BootNext
> variables. Heinrich, please correct me if I'm wrong.
I'm not familiar with EFI boot, In this case, the 'scan_dev_for_efi' calls 'run
boot_efi_bootmgr' then 'bootefi bootmgr', seems it doesn't check if the needed
components exist.
Is the cmd 'scan_dev_for_efi' wrong?
>
> > Actually, if give a readable but invalid 'fdt_addr' in env, the EFI
> > boot can also be skipped during the scan of the 1st partition.
> > Actually on some Layerscape boards the provided env 'fdt_addr' with a
> > non-readable address, and on other boards a readable 'fdt_addr'. Seems
> > the patch author copy them from somewhere but didn't cause issue that
> > time. But this is just a workaround, the EFI boot should not cause
> > problem during the scan phase when there isn't needed components in
> > one of these partitions.
>
> What exactly is going wrong? Is linux booting at all? Or does the bootloader
> abort?
Pasted the log below, the direct cause seems the u-boot DTB doesn't have /cpus
node.
=> run bootcmd_mmc0
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
libfdt fdt_check_header(): FDT_ERR_BADMAGIC
Scanning disk es...@156.blk...
Found 5 disks
No EFI system partition
couldn't find /cpus
"Synchronous Abort" handler, esr 0x9606
elr: 82004a6c lr : 82004a30 (reloc)
elr: fbd25a6c lr : fbd25a30
x0 : 87f00a88 x1 : 1cfbfd5e
x2 : efbeaddeefbeadde x3 : efbeadde
x4 : fffc x5 : 87f037d2
x6 :
RE: [PATCH] configs: layerscape: Disable the EFI_LOADER feature
Hi Fabio, > -Original Message- > From: Fabio Estevam > Sent: 2021年7月23日 1:10 > To: Michael Walle > Cc: Tom Rini ; Z.Q. Hou ; > Heinrich Schuchardt ; U-Boot-Denx > ; Priyanka Jain > Subject: Re: [PATCH] configs: layerscape: Disable the EFI_LOADER feature > > On Thu, Jul 22, 2021 at 2:00 PM Michael Walle wrote: > > > I don't know whats going on with the NXP boards, but the sl28 is a > > layerscape board it is working pretty well with EFI boot. > > > > So why don't you fix the root cause instead of disabling this feature? > > Agreed. > > Besides that, the way to disable this option is not correct. > > It should be: > > # CONFIG_EFI_LOADER is not set > > instead of > > CONFIG_EFI_LOADER=n Thanks for the correction! Regards, Zhiqiang
RE: [PATCH] configs: layerscape: Disable the EFI_LOADER feature
Hi Michael,
> -Original Message-
> From: Michael Walle
> Sent: 2021年7月23日 1:01
> To: Tom Rini
> Cc: Z.Q. Hou ; Heinrich Schuchardt
> ; u-boot@lists.denx.de; Priyanka Jain
>
> Subject: Re: [PATCH] configs: layerscape: Disable the EFI_LOADER feature
>
> Am 2021-07-22 17:26, schrieb Tom Rini:
> > On Thu, Jul 22, 2021 at 02:25:59PM +0800, Zhiqiang Hou wrote:
> >
> >> From: Hou Zhiqiang
> >>
> >> The feature BOOTENV_SHARED_EFI is not supported on layerscape
> boards,
> >> it didn't result kernel boot crash previously since there isn't the
> >> efi/boot/"BOOTEFI_NAME" and it skip calling of 'boot_efi_binary'.
> >>
> >> But since the commit f3866909e350 ("distro_bootcmd: call EFI bootmgr
> >> even without having /EFI/boot"), it will cause kernel boot crash as
> >> there isn't a valid fdt_addr and it finially uses the device tree
> >> blob of U-Boot and further cause errors.
> >>
> >> As this feature is enabled by default for armv7 and armv8, so disable
> >> it explicitly to avoid calling the 'scan_dev_for_efi'.
> >
> > I'm not thrilled with this. Why isn't the solution to get and keep in
> > sync the device trees, so that the tree U-Boot has is valid for the
> > kernel? I'm also open to discussing f3866909e350 more. But I'm
> > really opposed to disabling EFI_LOADER on modern platforms as that
> > will make adoption of U-Boot in device harder I feel.
>
> I don't know whats going on with the NXP boards, but the sl28 is a
> layerscape board it is working pretty well with EFI boot.
Do you mean the EFI boot work well on sl28? Or the EFI boot doesn't break other
boot ways?
In my case, there are 4 MMC partitions and a boot script with boot images in
the 2nd partition, while nothing in the 1st partition. So the expected boot
flow is the 'bootcmd_mmc0' scan the 1st partition and find it's not bootable
and then the 2nd partition and boot with the script. But actually the
'scan_dev_for_efi' got problem when scan the 1st partition, as the u-boot DTB
is used in 'bootefi bootmgr' and result in some error related to the DTB.
Actually, if give a readable but invalid 'fdt_addr' in env, the EFI boot can
also be skipped during the scan of the 1st partition. Actually on some
Layerscape boards the provided env 'fdt_addr' with a non-readable address, and
on other boards a readable 'fdt_addr'. Seems the patch author copy them from
somewhere but didn't cause issue that time. But this is just a workaround, the
EFI boot should not cause problem during the scan phase when there isn't needed
components in one of these partitions.
Thanks,
Zhiqiang
>
> So why don't you fix the root cause instead of disabling this feature?
>
> -michael
RE: [PATCH] configs: layerscape: Disable the EFI_LOADER feature
Hi Tom,
> -Original Message-
> From: Tom Rini
> Sent: 2021年7月22日 23:26
> To: Z.Q. Hou ; Michael Walle ;
> Heinrich Schuchardt
> Cc: u-boot@lists.denx.de; Priyanka Jain
> Subject: Re: [PATCH] configs: layerscape: Disable the EFI_LOADER feature
>
> On Thu, Jul 22, 2021 at 02:25:59PM +0800, Zhiqiang Hou wrote:
>
> > From: Hou Zhiqiang
> >
> > The feature BOOTENV_SHARED_EFI is not supported on layerscape boards,
> > it didn't result kernel boot crash previously since there isn't the
> > efi/boot/"BOOTEFI_NAME" and it skip calling of 'boot_efi_binary'.
> >
> > But since the commit f3866909e350 ("distro_bootcmd: call EFI bootmgr
> > even without having /EFI/boot"), it will cause kernel boot crash as
> > there isn't a valid fdt_addr and it finially uses the device tree blob
> > of U-Boot and further cause errors.
> >
> > As this feature is enabled by default for armv7 and armv8, so disable
> > it explicitly to avoid calling the 'scan_dev_for_efi'.
>
> I'm not thrilled with this. Why isn't the solution to get and keep in sync
> the
> device trees, so that the tree U-Boot has is valid for the kernel? I'm also
> open to discussing f3866909e350 more. But I'm really opposed to disabling
> EFI_LOADER on modern platforms as that will make adoption of U-Boot in
> device harder I feel.
>
I think it doesn't make sense for the platforms on which the EFI boot is not
planed.
As there isn't EFI boot needed components in the search path, finally the EFI
boot
will be skipped. I don't want to look into the EFI boot process, so I trend to
disable
the feature, is it acceptable?
Thanks,
Zhiqiang
> --
> Tom
RE: [PATCH] net: e1000: Fix Unchecked return value coverity
> -Original Message-
> From: Ramon Fried [mailto:rfried@gmail.com]
> Sent: 2021年6月12日 7:47
> To: Z.Q. Hou
> Cc: Joe Hershberger ; U-Boot Mailing List
>
> Subject: Re: [PATCH] net: e1000: Fix Unchecked return value coverity
>
> On Fri, Jun 11, 2021 at 5:56 AM Z.Q. Hou wrote:
> >
> >
> >
> > > -Original Message-
> > > From: Ramon Fried
> > > Sent: 2021年6月10日 13:49
> > > To: Z.Q. Hou
> > > Cc: Joe Hershberger ; U-Boot Mailing List
> > >
> > > Subject: Re: [PATCH] net: e1000: Fix Unchecked return value coverity
> > >
> > > On Mon, May 31, 2021 at 6:12 PM Zhiqiang Hou
> > > wrote:
> > > >
> > > > From: Hou Zhiqiang
> > > >
> > > > Added check for return value of e1000_read_phy_reg().
> > > >
> > > > Signed-off-by: Hou Zhiqiang
> > > > ---
> > > > drivers/net/e1000.c | 12
> > > > 1 file changed, 8 insertions(+), 4 deletions(-)
> > > >
> > > > diff --git a/drivers/net/e1000.c b/drivers/net/e1000.c index
> > > > 694114eca7..1f0d559415 100644
> > > > --- a/drivers/net/e1000.c
> > > > +++ b/drivers/net/e1000.c
> > > > @@ -4738,12 +4738,16 @@ e1000_phy_init_script(struct e1000_hw
> *hw)
> > > > uint16_t fused, fine, coarse;
> > > >
> > > > /* Move to analog registers page */
> > > > - e1000_read_phy_reg(hw,
> > > > -
> > > IGP01E1000_ANALOG_SPARE_FUSE_STATUS, );
> > > > + if (e1000_read_phy_reg(hw,
> > > > +
> > > IGP01E1000_ANALOG_SPARE_FUSE_STATUS,
> > > > + ))
> > > > + return;
> > > >
> > > > if (!(fused &
> > > IGP01E1000_ANALOG_SPARE_FUSE_ENABLED)) {
> > > > - e1000_read_phy_reg(hw,
> > > > -
> > > IGP01E1000_ANALOG_FUSE_STATUS, );
> > > > + if (e1000_read_phy_reg(hw,
> > > > +
> > > IGP01E1000_ANALOG_FUSE_STATUS,
> > > > +
> > > ))
> > > > + return;
> > > >
> > > > fine = fused &
> > > IGP01E1000_ANALOG_FUSE_FINE_MASK;
> > > > coarse = fused
> > > > --
> > > > 2.17.1
> > > >
> > > What about some error messages ?
> >
> > CID 43664 (#15 of 15): Unchecked return value (CHECKED_RETURN) 6.
> > check_return: Calling e1000_read_phy_reg without checking return value
> (as is done elsewhere 44 out of 47 times).
> >
> > - Zhiqiang
> It's not clear enough why you're leaving the function early, better add some
> comments in the commit message and in the code.
If it should continue to run while it failed to read the PHY registers? Anyone
can comments on this?
Thanks,
Zhiqiang
RE: [PATCH] net: e1000: Fix Unchecked return value coverity
> -Original Message-
> From: Ramon Fried
> Sent: 2021年6月10日 13:49
> To: Z.Q. Hou
> Cc: Joe Hershberger ; U-Boot Mailing List
>
> Subject: Re: [PATCH] net: e1000: Fix Unchecked return value coverity
>
> On Mon, May 31, 2021 at 6:12 PM Zhiqiang Hou
> wrote:
> >
> > From: Hou Zhiqiang
> >
> > Added check for return value of e1000_read_phy_reg().
> >
> > Signed-off-by: Hou Zhiqiang
> > ---
> > drivers/net/e1000.c | 12
> > 1 file changed, 8 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/net/e1000.c b/drivers/net/e1000.c index
> > 694114eca7..1f0d559415 100644
> > --- a/drivers/net/e1000.c
> > +++ b/drivers/net/e1000.c
> > @@ -4738,12 +4738,16 @@ e1000_phy_init_script(struct e1000_hw *hw)
> > uint16_t fused, fine, coarse;
> >
> > /* Move to analog registers page */
> > - e1000_read_phy_reg(hw,
> > -
> IGP01E1000_ANALOG_SPARE_FUSE_STATUS, );
> > + if (e1000_read_phy_reg(hw,
> > +
> IGP01E1000_ANALOG_SPARE_FUSE_STATUS,
> > + ))
> > + return;
> >
> > if (!(fused &
> IGP01E1000_ANALOG_SPARE_FUSE_ENABLED)) {
> > - e1000_read_phy_reg(hw,
> > -
> IGP01E1000_ANALOG_FUSE_STATUS, );
> > + if (e1000_read_phy_reg(hw,
> > +
> IGP01E1000_ANALOG_FUSE_STATUS,
> > +
> ))
> > + return;
> >
> > fine = fused &
> IGP01E1000_ANALOG_FUSE_FINE_MASK;
> > coarse = fused
> > --
> > 2.17.1
> >
> What about some error messages ?
CID 43664 (#15 of 15): Unchecked return value (CHECKED_RETURN)
6. check_return: Calling e1000_read_phy_reg without checking return value (as
is done elsewhere 44 out of 47 times).
- Zhiqiang
RE: [PATCH 3/4] arch: Kconfig: enable IRQ using select for x86 architecture
On Tue, 12 Jan 2021 at 02:05, Wasim Khan wrote: > > From: Wasim Khan > > use 'select' to enable IRQ as it does not have architecture specific > dependency. > > Signed-off-by: Wasim Khan > --- > arch/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Hou Zhiqiang
RE: [PATCH 2/4] arch: arm: update Kconfig to select IRQ when GIC_V3_ITS is enabled
On Tue, Jan 12, 2021 at 10:05:07AM +0100, Wasim Khan wrote: > From: Wasim Khan > > GIC_V3_ITS uses UCLASS_IRQ driver. Update Kconfig to select IRQ when > GIC_V3_ITS is enabled. > > Signed-off-by: Wasim Khan > --- Reviewed-by: Hou Zhiqiang
RE: [PATCH 1/4] misc: make CONFIG_IRQ selectable for all platforms
On Tue, Jan 12, 2021 at 10:05:06AM +0100, Wasim Khan wrote: > From: Wasim Khan > > UCLASS_IRQ driver is not Intel specific. Make CONFIG_IRQ selectable > for all platfroms. > > Signed-off-by: Wasim Khan > --- s/platfroms/platforms/ Regards, Zhiqiang
RE: [PATCHv2] arm64: gic-v3-its: Clear the Pending table before enabling LPIs
Hi Laurentiu,
Thanks a lot for your comments!
> -Original Message-
> From: Laurentiu Tudor
> Sent: 2021年3月5日 13:49
> To: Z.q. Hou ; u-boot@lists.denx.de
> Cc: s...@chromium.org; rayagonda.kokata...@broadcom.com; Priyanka
> Jain ; Vladimir Oltean
> Subject: Re: [PATCHv2] arm64: gic-v3-its: Clear the Pending table before
> enabling LPIs
>
> Hi Zhiqiang,
>
> On 3/5/2021 4:21 AM, Zhiqiang Hou wrote:
> > From: Hou Zhiqiang
> >
> > The GICv3 RM requires "The first 1KB of memory for the LPI Pending
> > tables must contain only zeros on initial allocation, and this must be
> > visible to the Redistributors, or else the effect is UNPREDICTABLE".
> >
> > And as the following statement, we here clear the whole Pending tables
> > instead of the first 1KB.
> > "An LPI Pending table that contains only zeros, including in the first
> > 1KB, indicates that there are no pending LPIs.
> > The first 1KB of the LPI Pending table is IMPLEMENTATION DEFINED.
> > However, if the first 1KB of the LPI Pending table and the rest of the
> > table contain only zeros, this must indicate that there are no pending
> > LPIs."
> >
> > And there isn't any pending LPI under U-Boot, so it's unnecessary to
> > load the contents of the Pending table during the enablement, then set
> > the GICR_PENDBASER.PTZ flag.
> >
> > Signed-off-by: Hou Zhiqiang
> > ---
> > V2:
> > - Clear the Pending tables using virtual address.
> > - Correct some typos in the change log.
> >
> > arch/arm/lib/gic-v3-its.c | 13 +++--
> > 1 file changed, 11 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/arm/lib/gic-v3-its.c b/arch/arm/lib/gic-v3-its.c
> > index f5a921b3d1..2dadc48a50 100644
> > --- a/arch/arm/lib/gic-v3-its.c
> > +++ b/arch/arm/lib/gic-v3-its.c
> > @@ -3,6 +3,7 @@
> > * Copyright 2019 Broadcom.
> > */
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -108,6 +109,8 @@ int gic_lpi_tables_init(void)
> > int i;
> > u64 redist_lpi_base;
> > u64 pend_base;
> > + ulong pend_tab_total_sz;
> > + void *pend_tab_va;
> >
> > if (gic_v3_its_get_gic_addr())
> > return -EINVAL;
> > @@ -160,7 +163,12 @@ int gic_lpi_tables_init(void)
> > }
> > }
> >
> > - redist_lpi_base = priv.lpi_base + LPI_PROPBASE_SZ;
>
> I don't think you want to drop this.
Yes, it's a mistake, will fix in v3.
>
> > + pend_tab_total_sz = priv.num_redist * LPI_PENDBASE_SZ;
> > + pend_tab_va = map_physmem(redist_lpi_base, pend_tab_total_sz,
> > + MAP_NOCACHE);
> > + memset(pend_tab_va, 0, pend_tab_total_sz);
> > + flush_cache((ulong)pend_tab_va, pend_tab_total_sz);
>
> Given that the memory is mapped as non-cacheable, is this flush necessary?
In theory, the flush is unnecessary with the MAP_NOCACHE flag, but on arm
platforms as the map_physmem() just does a phys_to_virt address conversion and
ignores the given flag, the flag doesn't take effect currently. To ensure the
Pending tables in main memory has been cleared before the LPI enablement of
each RD, I keep the flush here.
Thanks,
Zhiqiang
>
> ---
> Best Regards, Laurentiu
>
> > + unmap_physmem(pend_tab_va, MAP_NOCACHE);
> >
> > pend_base = priv.gicr_base + GICR_PENDBASER;
> > for (i = 0; i < priv.num_redist; i++) { @@ -168,7 +176,8 @@ int
> > gic_lpi_tables_init(void)
> >
> > val = ((redist_lpi_base + (i * LPI_PENDBASE_SZ)) |
> > GICR_PENDBASER_INNERSHAREABLE |
> > - GICR_PENDBASER_RAWAWB);
> > + GICR_PENDBASER_RAWAWB |
> > + GICR_PENDBASER_PTZ);
> >
> > writeq(val, (uintptr_t)(pend_base + offset));
> > tmp = readq((uintptr_t)(pend_base + offset));
> >
RE: [PATCHv2] pci: layerscape: Fixup PCIe EP mode DT nodes for LX2160A rev2
Hi Priyanka, > -Original Message- > From: Priyanka Jain (OSS) > Sent: 2020年10月23日 18:49 > To: Z.q. Hou ; u-boot@lists.denx.de; Wasim Khan > > Cc: Z.q. Hou > Subject: RE: [PATCHv2] pci: layerscape: Fixup PCIe EP mode DT nodes for > LX2160A rev2 > > >-Original Message- > >From: U-Boot On Behalf Of Zhiqiang Hou > >Sent: Sunday, September 27, 2020 12:48 PM > >To: u-boot@lists.denx.de; Priyanka Jain ; Wasim > >Khan > >Cc: Z.q. Hou > >Subject: [PATCHv2] pci: layerscape: Fixup PCIe EP mode DT nodes for > >LX2160A > >rev2 > > > >From: Hou Zhiqiang > > > >LX2160A rev2 uses different PCIe controller, so EP mode DT nodes also > >need to be fixed up. > > > >Signed-off-by: Hou Zhiqiang > >--- > >V2: > > - Fix a dead loop issue. > > > > V0 was already applied . Please send delta in add-on patch. > Okay, will send a fix patch. Thanks, Zhiqiang > Regards > Priyanka >
RE: [PATCHv6 01/18] phy: make phy_connect_fixed work with a null mdio bus
Hi Priyanka, > -Original Message- > From: Priyanka Jain (OSS) > Sent: 2020年9月23日 21:25 > To: Z.q. Hou ; u-boot@lists.denx.de; > bmeng...@gmail.com; olte...@gmail.com > Cc: Vladimir Oltean ; Z.q. Hou > > Subject: RE: [PATCHv6 01/18] phy: make phy_connect_fixed work with a null > mdio bus > > >-Original Message- > >From: U-Boot On Behalf Of Zhiqiang Hou > >Sent: Tuesday, September 22, 2020 2:20 PM > >To: u-boot@lists.denx.de; bmeng...@gmail.com; olte...@gmail.com; > >Priyanka Jain > >Cc: Vladimir Oltean ; Z.q. Hou > > > >Subject: [PATCHv6 01/18] phy: make phy_connect_fixed work with a null > >mdio bus > > > >From: Vladimir Oltean > > > >It is utterly pointless to require an MDIO bus pointer for a fixed PHY > >device. > >The fixed.c implementation does not require it, only phy_device_create. > >Fix that. > > > >Signed-off-by: Vladimir Oltean > >Signed-off-by: Hou Zhiqiang > >Reviewed-by: Hou Zhiqiang > >--- > Hello, > > I have already picked v5 and rebased. > This is now integrated in u-boot-mpc85xx and pull-request is generated for > next branch today. > Kindly rebase and resend the delta over that. No code change in V6, just move the #2 of V5 to the end of the patch set to avoid ls1021a build error at #2, refer to Vladimir's comments in http://patchwork.ozlabs.org/project/uboot/patch/20200716100925.10721-3-zhiqiang@nxp.com/ Thanks, Zhiqiang > > Regards > Priyanka
RE: [PATCHv5 02/18] configs: enable DM_MDIO for LS1021A-TWR and LS1021A-TSN
Hi Vladimir,
Sorry, I missed your email!
> -Original Message-
> From: Vladimir Oltean
> Sent: 2020年7月16日 23:34
> To: Z.q. Hou
> Cc: u-boot@lists.denx.de; bmeng...@gmail.com; Priyanka Jain
> ; Vladimir Oltean
> Subject: Re: [PATCHv5 02/18] configs: enable DM_MDIO for LS1021A-TWR
> and LS1021A-TSN
>
> On Thu, Jul 16, 2020 at 06:09:09PM +0800, Zhiqiang Hou wrote:
> > From: Vladimir Oltean
> >
> > The tsec driver now requires DM_MDIO when DM_ETH is enabled. To
> avoid
> > build errors, enable DM_MDIO in these boards' configs before we
> > actually add DM_MDIO support to tsec.
> >
> > Signed-off-by: Vladimir Oltean
> > Signed-off-by: Hou Zhiqiang
> > ---
>
> The series doesn't build at this patch for ls1021a family, and is broken until
> 05/18 "net: tsec: convert to use DM_MDIO when DM_ETH enabled". The
> reason is that fsl_pq_mdio_init is defined in drivers/net/fsl_mdio.c only
> when CONFIG_DM_MDIO=n.
>
> arm-none-linux-gnueabihf-ld.bfd: drivers/net/built-in.o: in function
> `tsec_probe':
> drivers/net/tsec.c:870: undefined reference to `fsl_pq_mdio_init'
> make: *** [Makefile:1762: u-boot] Error 1
>
> The build is finally fixed in 05/18 when you delete fsl_pq_mdio_init() from
> tsec.c which is not really needed.
>
> I don't think it's a good idea to break the build in between patches, it
> destroys bisectability. I think you would need to add one more patch, right
> before this one, that adds a dummy definition for this function.
> You can then remove it in the "net: tsec: convert to use DM_MDIO when
> DM_ETH enabled".
>
> Like this:
>
> diff --git a/drivers/net/fsl_mdio.c b/drivers/net/fsl_mdio.c index
> 43040d4c3f89..4128b30f7412 100644
> --- a/drivers/net/fsl_mdio.c
> +++ b/drivers/net/fsl_mdio.c
> @@ -149,6 +149,12 @@ int fsl_pq_mdio_init(bd_t *bis, struct
> fsl_pq_mdio_info *info)
> return mdio_register(bus);
> }
> #else /* CONFIG_DM_MDIO */
> +
> +int fsl_pq_mdio_init(bd_t *bis, struct fsl_pq_mdio_info *info) {
> + return 0;
> +}
> +
> #if defined(CONFIG_PHYLIB)
> static int tsec_mdio_read(struct udevice *dev, int addr, int devad, int reg)
> {
>
> This is really fixing an issue of commit 2932c5a802a9 ("net: tsec:
> fsl_mdio: add DM MDIO support"), maybe you could even add a Fixes: tag
> for that.
Instead of adding a fix patch, I'd like to move this patch to the tail of this
series.
Thanks,
Zhiqiang
>
> > V5:
> > - Pick from
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatch
> work.ozlabs.org%2Fproject%2Fuboot%2Fpatch%2F20200503185227.28731-
> 3-olteanv%40gmail.com%2Fdata=02%7C01%7CZhiqiang.Hou%40nxp.
> com%7Cd458470893954ef37a3308d8299da29b%7C686ea1d3bc2b4c6fa92c
> d99c5c301635%7C0%7C0%7C637305104294481939sdata=4zfV%2F%
> 2FjH%2Bi%2FlyyPpCI9164ntFzYVIqOchTufKwtZe0g%3Dreserved=0.
> >
> > configs/ls1021atsn_qspi_defconfig | 1 +
> > configs/ls1021atsn_sdcard_defconfig | 1 +
> > configs/ls1021atwr_nor_SECURE_BOOT_defconfig| 1 +
> > configs/ls1021atwr_nor_defconfig| 1 +
> > configs/ls1021atwr_nor_lpuart_defconfig | 1 +
> > configs/ls1021atwr_qspi_defconfig | 1 +
> > configs/ls1021atwr_sdcard_ifc_SECURE_BOOT_defconfig | 1 +
> > configs/ls1021atwr_sdcard_ifc_defconfig | 1 +
> > configs/ls1021atwr_sdcard_qspi_defconfig| 1 +
> > 9 files changed, 9 insertions(+)
> >
> > diff --git a/configs/ls1021atsn_qspi_defconfig
> > b/configs/ls1021atsn_qspi_defconfig
> > index a62e04e92a..9a659c5512 100644
> > --- a/configs/ls1021atsn_qspi_defconfig
> > +++ b/configs/ls1021atsn_qspi_defconfig
> > @@ -43,6 +43,7 @@ CONFIG_PHY_ATHEROS=y
> CONFIG_PHY_BROADCOM=y
> > CONFIG_PHY_FIXED=y CONFIG_DM_ETH=y
> > +CONFIG_DM_MDIO=y
> > CONFIG_PHY_GIGE=y
> > CONFIG_MII=y
> > CONFIG_TSEC_ENET=y
> > diff --git a/configs/ls1021atsn_sdcard_defconfig
> > b/configs/ls1021atsn_sdcard_defconfig
> > index db4f0ab796..235265bd74 100644
> > --- a/configs/ls1021atsn_sdcard_defconfig
> > +++ b/configs/ls1021atsn_sdcard_defconfig
> > @@ -54,6 +54,7 @@ CONFIG_PHY_ATHEROS=y
> CONFIG_PHY_BROADCOM=y
> > CONFIG_PHY_FIXED=y CONFIG_DM_ETH=y
> > +CONFIG_DM_MDIO=y
> > CONFIG_PHY_GIGE=y
> > CONFIG_MII=y
> > CONFIG_TSEC_ENET=y
> > diff --git a/configs/ls1021atwr_nor_SECURE_BOOT_defconfig
> > b/configs/ls1021atwr_nor_SECURE_BOOT_defconfig
> > index 0bf4aad102..8946bc1a70 100644
> > --- a/configs/ls1021atwr_nor_SECURE_BOOT_defconfig
> > +++ b/configs/ls1021
RE: [PATCH] pci: layerscape: Remove the shadow SVR definitiones
Hi Priyanka, Thanks a lot for your comments! > -Original Message- > From: Priyanka Jain > Sent: 2020年9月18日 21:53 > To: Z.q. Hou ; u-boot@lists.denx.de; Wasim Khan > > Cc: Z.q. Hou > Subject: RE: [PATCH] pci: layerscape: Remove the shadow SVR definitiones > > >-Original Message- > >From: Zhiqiang Hou > >Sent: Friday, September 18, 2020 1:53 PM > >To: u-boot@lists.denx.de; Priyanka Jain ; Wasim > >Khan > >Cc: Z.q. Hou > >Subject: [PATCH] pci: layerscape: Remove the shadow SVR definitiones > > > sp mistake: definitions I'll correct in next version. Regards, Zhiqiang > >From: Hou Zhiqiang > > > >This patch moves the SVR definitiones to a new svr.h for Layerscape > >armv7 > sp mistake: definitions > > >and armv8 platforms respectively, so that the PCIe driver can reuse them. > > > >Signed-off-by: Hou Zhiqiang > >--- > > > Regards > Priyanka
RE: [PATCHv2 00/13] powerpc: covert p1010, p1020 and p2020 RDB board to DM_ETH
Hi Vladimir, > -Original Message- > From: Vladimir Oltean > Sent: 2020年7月16日 5:22 > To: Priyanka Jain (OSS) > Cc: Z.q. Hou ; u-boot@lists.denx.de; > bmeng...@gmail.com > Subject: Re: [PATCHv2 00/13] powerpc: covert p1010, p1020 and p2020 RDB > board to DM_ETH > > Hi Priyanka, > > On Mon, Jun 08, 2020 at 09:52:57AM +, Priyanka Jain (OSS) wrote: > > >-Original Message- > > >From: U-Boot On Behalf Of Zhiqiang > Hou > > >Sent: Friday, June 5, 2020 2:25 PM > > >To: u-boot@lists.denx.de; Priyanka Jain ; > > >bmeng...@gmail.com; olte...@gmail.com > > >Cc: Z.q. Hou > > >Subject: [PATCHv2 00/13] powerpc: covert p1010, p1020 and p2020 RDB > > >board to DM_ETH > > > > > >From: Hou Zhiqiang > > > > > >Rebased this series on the top of master branch of > > >https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit > > >lab.denx.de%2Fu-data=02%7C01%7Czhiqiang.hou%40nxp.com%7 > C53a540c6 > > >1508484b1e4008d8290528d7%7C686ea1d3bc2b4c6fa92cd99c5c301635 > %7C0%7C0%7 > > >C637304449418968744sdata=3Wvg2l%2F3FeKUZHGgvgqVl2w4i3u > s9if8HbHqq > > >xBtKgU%3Dreserved=0 > > >boot/custodians/u-boot-mpc85xx.git > > > > > I have requested a rebase on 'next' branch. > > I have pushed next branch to master (mpc85xx tree) as well today. So > > you can use that now Please rebase again. > > > > >This patch set depends on: > > >https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpa > t > > >chwork.ozlabs.org%2Fproject%2Fuboot%2Flist%2F%3Fseries%3D174343 > d > > >ata=02%7C01%7Czhiqiang.hou%40nxp.com%7C53a540c61508484b1e40 > 08d8290528 > > >d7%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C6373044494 > 18968744 > > >p;sdata=cdg%2FhDCFBN7TOD6HN%2Fk1DLx51Zh69Cnujul7FLOuvf8%3D& > amp;reserv > > >ed=0 > > > > > A patch for tsec migration to DM_MDIO was already submitted by Madalin > which is now merged in mpc85xx tree. > > Let me know if that is fine or you need some additional patches from > Vladimir. > > > > > > Regards > > Priyanka > > > > > > > > I've tested Zhiqiang's patch series right now on LS1021A-TSN. It rebases > cleanly, no conflicts. It also works fine. > Zhiqiang, you just needs to pick up this patch from me, otherwise build on > LS1021A TWR and TSN boards is broken: > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatch > work.ozlabs.org%2Fproject%2Fuboot%2Fpatch%2F20200503185227.28731- > 3-olteanv%40gmail.com%2Fdata=02%7C01%7Czhiqiang.hou%40nxp. > com%7C53a540c61508484b1e4008d8290528d7%7C686ea1d3bc2b4c6fa92c > d99c5c301635%7C0%7C0%7C637304449418968744sdata=%2FC90Ru > Nv79NfiWWdAw3wFMs7yjZ9SYS1QnbvAujlT0Y%3Dreserved=0 > Please pick up this patch when resubmitting, it's easier for all patches to go > in through a single submission. I will pick up the #1 of this series also in next version, so that you won't need to submit them again. Thanks, Zhiqiang > > Thanks! > -Vladimir
RE: [PATCHv4 00/16] powerpc: covert p1010, p1020 and p2020 RDB board to DM_ETH
Hi Vladimir, Thanks a lot for your comments! > -Original Message- > From: Vladimir Oltean [mailto:olte...@gmail.com] > Sent: 2020年7月2日 1:46 > To: Z.q. Hou > Cc: u-boot ; Bin Meng ; > Priyanka Jain > Subject: Re: [PATCHv4 00/16] powerpc: covert p1010, p1020 and p2020 RDB > board to DM_ETH > > On Wed, 1 Jul 2020 at 20:11, Vladimir Oltean wrote: > > > > Hi Zhiqiang, > > > > On Wed, 1 Jul 2020 at 20:05, Zhiqiang Hou wrote: > > > > > > From: Hou Zhiqiang > > > > > > This patch set depends on: > > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpa > > > > tchwork.ozlabs.org%2Fproject%2Fuboot%2Fpatch%2F20200503185227.2873 > 1- > > > > 2-olteanv%40gmail.com%2Fdata=02%7C01%7CZhiqiang.Hou%40nxp.c > om%7 > > > > C9215a1fed74348210eb108d81de69d85%7C686ea1d3bc2b4c6fa92cd99c5c3 > 01635 > > > %7C0%7C0%7C637292223605570364sdata=s1fe6AFATwaeeUAOU > gK7vMElVZNP > > > 3L%2F62pDsdcfOE%2BY%3Dreserved=0 > > > > > > Hou Zhiqiang (16): > > > net: fsl_mdio: Change to use virtual address > > > net: fsl_mdio: Correct the MII management register block address > > > net: tsec: convert to use DM_MDIO when DM_ETH enabled > > > net: tsec: Add fixed-link PHY support > > > net: tsec: Add the compatible string "gianfar" support > > > powerpc: mpc8xxx: Don't compile cpu_eth_init() when DM_ETH > enabled > > > fsl: p1_p2_rdb: Move vsc7835 firmware uploading to > > > board_early_init_r() > > > configs: p1_p2_rdb: Add the default address of vsc7385 firmware > > > dts: powerpc: p1020rdb: Add eTSEC DT nodes > > > powerpc: p1_p2_rdb: Don't compile board_eth_init() when DM_ETH > enabled > > > configs: P1020RDB: Enable DM_ETH config > > > dts: powerpc: p1010rdb: Add eTSEC DT nodes > > > powerpc: p1010rdb: Compile legacy ethernet init function when no > > > DM_ETH > > > configs: P1010RDB: Enable DM_ETH config > > > dts: powerpc: p2020rdb: Add eTSEC DT nodes > > > configs: P2020RDB: Enable DM_ETH config > > > > > > arch/powerpc/cpu/mpc8xxx/cpu.c| 2 + > > > arch/powerpc/dts/p1010rdb-pa.dts | 1 + > > > arch/powerpc/dts/p1010rdb-pa_36b.dts | 1 + > > > arch/powerpc/dts/p1010rdb.dtsi| 50 > +++ > > > arch/powerpc/dts/p1010si-post.dtsi| 25 > > > arch/powerpc/dts/p1020-post.dtsi | 20 +- > > > arch/powerpc/dts/p1020rdb-pc.dts | 1 + > > > arch/powerpc/dts/p1020rdb-pc.dtsi | 55 > > > > arch/powerpc/dts/p1020rdb-pc_36b.dts | 1 + > > > arch/powerpc/dts/p1020rdb-pd.dts | 45 > ++ > > > arch/powerpc/dts/p2020-post.dtsi | 10 ++- > > > arch/powerpc/dts/p2020rdb-pc.dts | 1 + > > > arch/powerpc/dts/p2020rdb-pc.dtsi | 50 > +++ > > > arch/powerpc/dts/p2020rdb-pc_36b.dts | 1 + > > > arch/powerpc/dts/pq3-etsec1-0.dtsi| 28 + > > > arch/powerpc/dts/pq3-etsec1-1.dtsi| 28 + > > > arch/powerpc/dts/pq3-etsec1-2.dtsi| 28 + > > > arch/powerpc/dts/pq3-etsec1-3.dtsi| 28 + > > > arch/powerpc/dts/pq3-etsec2-0.dtsi| 35 +++ > > > arch/powerpc/dts/pq3-etsec2-1.dtsi| 35 +++ > > > arch/powerpc/dts/pq3-etsec2-2.dtsi| 35 +++ > > > arch/powerpc/dts/pq3-etsec2-grp2-0.dtsi | 16 + > > > arch/powerpc/dts/pq3-etsec2-grp2-1.dtsi | 16 + > > > arch/powerpc/dts/pq3-etsec2-grp2-2.dtsi | 16 + > > > board/freescale/p1010rdb/p1010rdb.c | 2 + > > > board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c | 37 ++- > > > configs/P1010RDB-PA_36BIT_NAND_defconfig | 2 + > > > configs/P1010RDB-PA_36BIT_NOR_defconfig | 2 + > > > configs/P1010RDB-PA_36BIT_SDCARD_defconfig| 2 + > > > configs/P1010RDB-PA_36BIT_SPIFLASH_defconfig | 2 + > > > configs/P1010RDB-PA_NAND_defconfig| 2 + > > > configs/P1010RDB-PA_NOR_defconfig | 2 + > > > configs/P1010RDB-PA_SDCARD_defconfig | 2 + > > > configs/P1010RDB-PA_SPIFLASH_defconfig| 2 + > > > configs/P1010RDB-PB_36BIT_NAND_defconfig | 2 + > > > configs/P1010RDB-PB_36BIT_NOR_defconfig | 2
RE: [PATCHv3 01/36] dm: spi: Convert Freescale ESPI driver to driver model
Hi Jagan, Thanks a lot for your review and apply! Regards, Zhiqiang > -Original Message- > From: Jagan Teki > Sent: 2020年6月13日 20:32 > To: Z.q. Hou > Cc: U-Boot-Denx ; Priyanka Jain > ; Shengzhou Liu ; Simon > Glass ; Biwen Li ; Bin Meng > ; Jiafei Pan ; Chuanhua Han > ; Xiaowei Bao > Subject: Re: [PATCHv3 01/36] dm: spi: Convert Freescale ESPI driver to driver > model > > On Thu, Jun 4, 2020 at 8:52 PM Zhiqiang Hou > wrote: > > > > From: Chuanhua Han > > > > Modify the Freescale ESPI driver to support the driver model. > > Also resolved the following problems: > > > > = WARNING == This > board does > > not use CONFIG_DM_SPI. Please update the board before v2019.04 for no > > dm conversion and v2019.07 for partially dm converted drivers. > > Failure to update can lead to driver/board removal See > > doc/driver-model/MIGRATION.txt for more info. > > > > = WARNING == This > board does > > not use CONFIG_DM_SPI_FLASH. Please update the board to use > > CONFIG_SPI_FLASH before the v2019.07 release. > > Failure to update by the deadline may result in board removal. > > See doc/driver-model/MIGRATION.txt for more info. > > > > > > Signed-off-by: Chuanhua Han > > Signed-off-by: Xiaowei Bao > > Signed-off-by: Hou Zhiqiang > > --- > > Applied to u-boot-spi/master
RE: [PATCHv3 04/15] net: tsec: Add the compatible string "gianfar" support
Hi Vladimir,
Thanks a lot for your review!
Regards,
Zhiqiang
> -Original Message-
> From: Vladimir Oltean
> Sent: 2020年6月13日 4:40
> To: Z.q. Hou
> Cc: u-boot ; Priyanka Jain ;
> Bin Meng
> Subject: Re: [PATCHv3 04/15] net: tsec: Add the compatible string "gianfar"
> support
>
> On Fri, 12 Jun 2020 at 18:23, Zhiqiang Hou wrote:
> >
> > From: Hou Zhiqiang
> >
> > Add compatible string "gianfar" support and update the
> > device-tree-bindings doc.
> >
> > Signed-off-by: Hou Zhiqiang
> > ---
>
> Reviewed-by: Vladimir Oltean
>
> > V3:
> > - Rebase the patch, no change intended.
> >
> > doc/device-tree-bindings/net/fsl-tsec-phy.txt | 2 +-
> > drivers/net/tsec.c| 16
> ++--
> > include/tsec.h| 4
> > 3 files changed, 19 insertions(+), 3 deletions(-)
> >
> > diff --git a/doc/device-tree-bindings/net/fsl-tsec-phy.txt
> > b/doc/device-tree-bindings/net/fsl-tsec-phy.txt
> > index 8e8574bc97..a44c5fd9d9 100644
> > --- a/doc/device-tree-bindings/net/fsl-tsec-phy.txt
> > +++ b/doc/device-tree-bindings/net/fsl-tsec-phy.txt
> > @@ -2,7 +2,7 @@
> >
> > Properties:
> >
> > - - compatible : Should be "fsl,etsec2"
> > + - compatible : Should be "fsl,etsec2" or "gianfar"
> >- reg : Offset and length of the register set for the device
> >- phy-handle : See ethernet.txt file in the same directory.
> >- phy-connection-type : See ethernet.txt file in the same
> > directory. This diff --git a/drivers/net/tsec.c b/drivers/net/tsec.c
> > index cb3e56d439..22658506b2 100644
> > --- a/drivers/net/tsec.c
> > +++ b/drivers/net/tsec.c
> > @@ -806,11 +806,14 @@ int tsec_probe(struct udevice *dev)
> > struct tsec_private *priv = dev_get_priv(dev);
> > struct ofnode_phandle_args phandle_args;
> > u32 tbiaddr = CONFIG_SYS_TBIPA_VALUE;
> > + struct tsec_data *data;
> > const char *phy_mode;
> > fdt_addr_t reg;
> > ofnode parent;
> > int ret;
> >
> > + data = (struct tsec_data *)dev_get_driver_data(dev);
> > +
> > pdata->iobase = (phys_addr_t)dev_read_addr(dev);
> > priv->regs = dev_remap_addr(dev);
> >
> > @@ -831,7 +834,7 @@ int tsec_probe(struct udevice *dev)
> > return -ENOENT;
> > }
> >
> > - priv->phyregs_sgmii = map_physmem(reg +
> TSEC_MDIO_REGS_OFFSET,
> > + priv->phyregs_sgmii = map_physmem(reg +
> > + data->mdio_regs_off,
> > 0,
> MAP_NOCACHE);
> > }
> >
> > @@ -883,8 +886,17 @@ static const struct eth_ops tsec_ops = {
> > .mcast = tsec_mcast_addr,
> > };
> >
> > +static struct tsec_data etsec2_data = {
> > + .mdio_regs_off = TSEC_MDIO_REGS_OFFSET, };
> > +
> > +static struct tsec_data gianfar_data = {
> > + .mdio_regs_off = 0x0,
> > +};
> > +
> > static const struct udevice_id tsec_ids[] = {
> > - { .compatible = "fsl,etsec2" },
> > + { .compatible = "fsl,etsec2", .data = (ulong)_data },
> > + { .compatible = "gianfar", .data = (ulong)_data },
> > { }
> > };
> >
> > diff --git a/include/tsec.h b/include/tsec.h index
> > b17fa957df..047dd3c373 100644
> > --- a/include/tsec.h
> > +++ b/include/tsec.h
> > @@ -394,6 +394,10 @@ struct tsec {
> >
> > #define TX_BUF_CNT 2
> >
> > +struct tsec_data {
> > + u32 mdio_regs_off;
> > +};
> > +
> > struct tsec_private {
> > struct txbd8 __iomem txbd[TX_BUF_CNT];
> > struct rxbd8 __iomem rxbd[PKTBUFSRX];
> > --
> > 2.25.1
> >
RE: [PATCHv3 03/15] net: tsec: convert to use DM_MDIO when DM_ETH enabled
Hi Vladimir,
Thanks a lot for your comments!
> -Original Message-
> From: Vladimir Oltean [mailto:olte...@gmail.com]
> Sent: 2020年6月13日 4:31
> To: Z.q. Hou
> Cc: u-boot ; Priyanka Jain ;
> Bin Meng ; Vladimir Oltean
>
> Subject: Re: [PATCHv3 03/15] net: tsec: convert to use DM_MDIO when
> DM_ETH enabled
>
> On Fri, 12 Jun 2020 at 18:23, Zhiqiang Hou wrote:
> >
> > From: Hou Zhiqiang
> >
> > For the platforms on which the eTSEC driver uses DM_ETH, convert its
> > MDIO controller code to also use DM_MDIO.
> >
> > Note that for handling the TBI PHY (the MAC PCS for SGMII), we still
> > don't register a udevice for it, since we can drive it locally and
> > there is no point in doing otherwise.
> >
> > Signed-off-by: Vladimir Oltean
> > Signed-off-by: Hou Zhiqiang
> > ---
> > V3:
> > - Draw from the tsec.c part of the Vladimir's patch below and do some
> >slightly tweaking:
> >
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatc
> >
> hwork.ozlabs.org%2Fproject%2Fuboot%2Fpatch%2F20200503185227.28731-
> 4-ol
> >
> teanv%40gmail.com%2Fdata=02%7C01%7CZhiqiang.Hou%40nxp.com
> %7Ce4ec9
> >
> e0d5ef84ddf730408d80f0f9963%7C686ea1d3bc2b4c6fa92cd99c5c301635%7
> C0%7C0
> > %7C637275906955031325sdata=muGA37v8K5glLrZJD2u63%2FFSmJ
> eNeRVCX8u%
> > 2F400xgQA%3Dreserved=0
> >
> > drivers/net/tsec.c | 46
> > +-
> > 1 file changed, 13 insertions(+), 33 deletions(-)
> >
> > diff --git a/drivers/net/tsec.c b/drivers/net/tsec.c index
> > 3d75acb6b4..cb3e56d439 100644
> > --- a/drivers/net/tsec.c
> > +++ b/drivers/net/tsec.c
> > @@ -18,6 +18,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> >
> > @@ -681,8 +682,15 @@ static int init_phy(struct tsec_private *priv)
> > if (priv->interface == PHY_INTERFACE_MODE_SGMII)
> > tsec_configure_serdes(priv);
> >
> > +#ifdef CONFIG_DM_ETH
> > + if (ofnode_valid(ofnode_find_subnode(priv->dev->node,
> "fixed-link")))
> > + phydev = phy_connect(NULL, 0, priv->dev,
> priv->interface);
> > + else
> > + phydev = dm_eth_phy_connect(priv->dev); #else
>
> You said it's better to split the fixed-link functionality into a separate
> patch,
> but then you didn't :)
Oops, I had amnesia
It will be split in next version.
Thanks,
Zhiqiang
>
> > phydev = phy_connect(priv->bus, priv->phyaddr, priv->dev,
> > priv->interface);
> > +#endif
> > if (!phydev)
> > return 0;
> >
> > @@ -787,14 +795,17 @@ int tsec_standard_init(bd_t *bis)
> > return tsec_eth_init(bis, tsec_info, ARRAY_SIZE(tsec_info));
> > } #else /* CONFIG_DM_ETH */
> > +
> > +#ifndef CONFIG_DM_MDIO
> > +#error "TSEC with DM_ETH also requires DM_MDIO"
> > +#endif
> > +
> > int tsec_probe(struct udevice *dev)
> > {
> > struct eth_pdata *pdata = dev_get_platdata(dev);
> > struct tsec_private *priv = dev_get_priv(dev);
> > - struct tsec_mii_mng __iomem *ext_phyregs_mii;
> > struct ofnode_phandle_args phandle_args;
> > u32 tbiaddr = CONFIG_SYS_TBIPA_VALUE;
> > - struct fsl_pq_mdio_info mdio_info;
> > const char *phy_mode;
> > fdt_addr_t reg;
> > ofnode parent;
> > @@ -803,31 +814,6 @@ int tsec_probe(struct udevice *dev)
> > pdata->iobase = (phys_addr_t)dev_read_addr(dev);
> > priv->regs = dev_remap_addr(dev);
> >
> > - if (dev_read_phandle_with_args(dev, "phy-handle", NULL, 0, 0,
> > - _args)) {
> > - printf("phy-handle does not exist under tsec %s\n",
> dev->name);
> > - return -ENOENT;
> > - } else {
> > - int reg = ofnode_read_u32_default(phandle_args.node,
> "reg", 0);
> > -
> > - priv->phyaddr = reg;
> > - }
> > -
> > - parent = ofnode_get_parent(phandle_args.node);
> > - if (!ofnode_valid(parent)) {
> > - printf("No parent node for PHY?\n");
> > - return -ENOENT;
> > - }
> > -
> > - reg = ofnode_get_addr_index(parent, 0);
> > - if (reg == FDT_ADDR_T_NONE) {
&g
RE: [PATCHv3 06/15] fsl: p1_p2_rdb: Move vsc7835 firmware uploading to board_early_init_r()
Hi Vladimir,
Thanks a lot for your review!
Regards,
Zhiqiang
> -Original Message-
> From: Vladimir Oltean
> Sent: 2020年6月13日 4:37
> To: Z.q. Hou
> Cc: u-boot ; Priyanka Jain ;
> Bin Meng
> Subject: Re: [PATCHv3 06/15] fsl: p1_p2_rdb: Move vsc7835 firmware
> uploading to board_early_init_r()
>
> On Fri, 12 Jun 2020 at 18:23, Zhiqiang Hou wrote:
> >
> > From: Hou Zhiqiang
> >
> > Move vsc7835 firmware uploading to board_early_init_r(), so that the
> > switch also can work in DM eTSEC driver.
> >
> > Signed-off-by: Hou Zhiqiang
> > ---
>
> For what it's worth, a DM_DSA uclass has been proposed exactly for this kind
> of stuff, but has received exactly zero review thus far:
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatch
> work.ozlabs.org%2Fproject%2Fuboot%2Fcover%2F1588700588-8587-1-git-s
> end-email-claudiu.manoil%40nxp.com%2Fdata=02%7C01%7CZhiqian
> g.Hou%40nxp.com%7Cd10d8cbe295d402a213408d80f1059f9%7C686ea1d3
> bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637275910184645214sda
> ta=0gqLyzu96SUYn1t0Rrdjj6bEnT6r8CUSSelFnW%2BRpnE%3Dreserve
> d=0
> So, given the tools we have, this is the best we can do.
>
> Reviewed-by: Vladimir Oltean
>
> > V3:
> > - Rebase the patch, no change intended.
> >
> > board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c | 35
> > +++--
> > 1 file changed, 18 insertions(+), 17 deletions(-)
> >
> > diff --git a/board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c
> > b/board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c
> > index 1353debc0e..3dd6178708 100644
> > --- a/board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c
> > +++ b/board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c
> > @@ -316,6 +316,10 @@ int board_early_init_r(void) {
> > const unsigned int flashbase = CONFIG_SYS_FLASH_BASE;
> > int flash_esel = find_tlb_idx((void *)flashbase, 1);
> > +#ifdef CONFIG_VSC7385_ENET
> > + unsigned int vscfw_addr;
> > + char *tmp;
> > +#endif
> >
> > /*
> > * Remap Boot flash region to caching-inhibited @@ -338,6
> > +342,20 @@ int board_early_init_r(void)
> > set_tlb(1, flashbase, CONFIG_SYS_FLASH_BASE_PHYS, /* tlb,
> epn, rpn */
> > MAS3_SX|MAS3_SW|MAS3_SR, MAS2_I|MAS2_G,/*
> perms, wimge */
> > 0, flash_esel, BOOKE_PAGESZ_64M, 1);/* ts, esel,
> > tsize, iprot */
> > +
> > +#ifdef CONFIG_VSC7385_ENET
> > + /* If a VSC7385 microcode image is present, then upload it. */
> > + tmp = env_get("vscfw_addr");
> > + if (tmp) {
> > + vscfw_addr = simple_strtoul(tmp, NULL, 16);
> > + printf("uploading VSC7385 microcode from %x\n",
> vscfw_addr);
> > + if (vsc7385_upload_firmware((void *)vscfw_addr,
> > +
> CONFIG_VSC7385_IMAGE_SIZE))
> > + puts("Failure uploading VSC7385
> microcode.\n");
> > + } else {
> > + puts("No address specified for VSC7385
> microcode.\n");
> > + }
> > +#endif
> > return 0;
> > }
> >
> > @@ -348,10 +366,6 @@ int board_eth_init(bd_t *bis)
> > ccsr_gur_t *gur __attribute__((unused)) =
> > (void *)(CONFIG_SYS_MPC85xx_GUTS_ADDR);
> > int num = 0;
> > -#ifdef CONFIG_VSC7385_ENET
> > - char *tmp;
> > - unsigned int vscfw_addr;
> > -#endif
> >
> > #ifdef CONFIG_TSEC1
> > SET_STD_TSEC_INFO(tsec_info[num], 1); @@ -375,19 +389,6
> @@ int
> > board_eth_init(bd_t *bis)
> > return 0;
> > }
> >
> > -#ifdef CONFIG_VSC7385_ENET
> > - /* If a VSC7385 microcode image is present, then upload it. */
> > - tmp = env_get("vscfw_addr");
> > - if (tmp) {
> > - vscfw_addr = simple_strtoul(tmp, NULL, 16);
> > - printf("uploading VSC7385 microcode from %x\n",
> vscfw_addr);
> > - if (vsc7385_upload_firmware((void *) vscfw_addr,
> > -
> CONFIG_VSC7385_IMAGE_SIZE))
> > - puts("Failure uploading VSC7385
> microcode.\n");
> > - } else
> > - puts("No address specified for VSC7385
> microcode.\n");
> > -#endif
> > -
> > mdio_info.regs = TSEC_GET_MDIO_REGS_BASE(1);
> > mdio_info.name = DEFAULT_MII_NAME;
> >
> > --
> > 2.25.1
> >
RE: [PATCHv3 01/15] net: fsl_mdio: Change to use virtual address
Hi Vladimir,
Thanks a lot for your review!
Regards,
Zhiqiang
> -Original Message-
> From: Vladimir Oltean
> Sent: 2020年6月13日 4:29
> To: Z.q. Hou
> Cc: u-boot ; Priyanka Jain ;
> Bin Meng
> Subject: Re: [PATCHv3 01/15] net: fsl_mdio: Change to use virtual address
>
> On Fri, 12 Jun 2020 at 18:23, Zhiqiang Hou wrote:
> >
> > From: Hou Zhiqiang
> >
> > Use virtual address to access the MII block registers instead of
> > physical address.
> >
> > Signed-off-by: Hou Zhiqiang
> > ---
>
> Reviewed-by: Vladimir Oltean
>
> > V3:
> > - New patch.
> >
> > drivers/net/fsl_mdio.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/fsl_mdio.c b/drivers/net/fsl_mdio.c index
> > 43040d4c3f..e52daa214d 100644
> > --- a/drivers/net/fsl_mdio.c
> > +++ b/drivers/net/fsl_mdio.c
> > @@ -213,7 +213,7 @@ static int tsec_mdio_probe(struct udevice *dev)
> > printf("dev_get_priv(dev %p) = NULL\n", dev);
> > return -1;
> > }
> > - priv->regs = (void *)(uintptr_t)dev_read_addr(dev);
> > + priv->regs = dev_remap_addr(dev);
> > debug("%s priv %p @ regs %p, pdata %p\n", __func__,
> > priv, priv->regs, pdata);
> >
> > --
> > 2.25.1
> >
RE: [PATCHv3 12/15] powerpc: p1010rdb: Compile legacy ethernet init function when no DM_ETH
Hi Vladimir,
Thanks a lot for your comments!
> -Original Message-
> From: Vladimir Oltean [mailto:olte...@gmail.com]
> Sent: 2020年6月13日 4:25
> To: Z.q. Hou
> Cc: u-boot ; Priyanka Jain ;
> Bin Meng
> Subject: Re: [PATCHv3 12/15] powerpc: p1010rdb: Compile legacy ethernet
> init function when no DM_ETH
>
> On Fri, 12 Jun 2020 at 18:23, Zhiqiang Hou wrote:
> >
> > From: Hou Zhiqiang
> >
> > The board_eth_init() is only used by legacy ethernet driver framework,
> > so do not compile it when DM_ETH config has been selected.
> >
> > Signed-off-by: Hou Zhiqiang
> > ---
>
> Ideally shouldn't all p1010rdb configs be converted to DM_ETH, and then
> board_eth_init can be deleted? What was the problem with the rest of the
> configs?
>
Now the SECBOOT defconfigs are still not converted.
Thanks,
Zhiqiang
> > V3:
> > - Rebase the patch, no change intended.
> >
> > board/freescale/p1010rdb/p1010rdb.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/board/freescale/p1010rdb/p1010rdb.c
> > b/board/freescale/p1010rdb/p1010rdb.c
> > index 66ccc0bd1e..309f4daa88 100644
> > --- a/board/freescale/p1010rdb/p1010rdb.c
> > +++ b/board/freescale/p1010rdb/p1010rdb.c
> > @@ -484,6 +484,7 @@ int checkboard(void)
> > return 0;
> > }
> >
> > +#ifndef CONFIG_DM_ETH
> > int board_eth_init(bd_t *bis)
> > {
> > #ifdef CONFIG_TSEC_ENET
> > @@ -524,6 +525,7 @@ int board_eth_init(bd_t *bis)
> >
> > return pci_eth_init(bis);
> > }
> > +#endif
> >
> > #if defined(CONFIG_OF_BOARD_SETUP)
> > void fdt_del_flexcan(void *blob)
> > --
> > 2.25.1
> >
RE: [PATCHv3 13/15] configs: P1010RDB: Enable DM_ETH config
Hi Vladimir, Thanks a lot for your comments! > -Original Message- > From: Vladimir Oltean [mailto:olte...@gmail.com] > Sent: 2020年6月13日 4:21 > To: Z.q. Hou > Cc: u-boot ; Priyanka Jain ; > Bin Meng > Subject: Re: [PATCHv3 13/15] configs: P1010RDB: Enable DM_ETH config > > On Fri, 12 Jun 2020 at 18:23, Zhiqiang Hou wrote: > > > > From: Hou Zhiqiang > > > > Enable the DM_ETH and DM_MDIO config. > > > > Signed-off-by: Hou Zhiqiang > > --- > > I think you missed some configs. There are 28 P1010RDB configs, you updated > only 16. The *SECBOOT* ones are not converted to DM_ETH in this series since I don’t know how to verify the SECBOOT. SECBOOT owner can enable the DM_ETH directly if the SECBOOT works with DM mode. Thanks, Zhiqiang > > > V3: > > - Rebase the patch, no change intended. > > > > configs/P1010RDB-PA_36BIT_NAND_defconfig | 2 ++ > > configs/P1010RDB-PA_36BIT_NOR_defconfig | 2 ++ > > configs/P1010RDB-PA_36BIT_SDCARD_defconfig | 2 ++ > > configs/P1010RDB-PA_36BIT_SPIFLASH_defconfig | 2 ++ > > configs/P1010RDB-PA_NAND_defconfig | 2 ++ > > configs/P1010RDB-PA_NOR_defconfig| 2 ++ > > configs/P1010RDB-PA_SDCARD_defconfig | 2 ++ > > configs/P1010RDB-PA_SPIFLASH_defconfig | 2 ++ > > configs/P1010RDB-PB_36BIT_NAND_defconfig | 2 ++ > > configs/P1010RDB-PB_36BIT_NOR_defconfig | 2 ++ > > configs/P1010RDB-PB_36BIT_SDCARD_defconfig | 2 ++ > > configs/P1010RDB-PB_36BIT_SPIFLASH_defconfig | 2 ++ > > configs/P1010RDB-PB_NAND_defconfig | 2 ++ > > configs/P1010RDB-PB_NOR_defconfig| 2 ++ > > configs/P1010RDB-PB_SDCARD_defconfig | 2 ++ > > configs/P1010RDB-PB_SPIFLASH_defconfig | 2 ++ > > 16 files changed, 32 insertions(+) > > > > diff --git a/configs/P1010RDB-PA_36BIT_NAND_defconfig > > b/configs/P1010RDB-PA_36BIT_NAND_defconfig > > index da04cab014..bd31e7c8fa 100644 > > --- a/configs/P1010RDB-PA_36BIT_NAND_defconfig > > +++ b/configs/P1010RDB-PA_36BIT_NAND_defconfig > > @@ -72,8 +72,10 @@ CONFIG_PHY_SMSC=y > > CONFIG_PHY_VITESSE=y > > CONFIG_PHY_GIGE=y > > CONFIG_E1000=y > > +CONFIG_DM_ETH=y > > CONFIG_MII=y > > CONFIG_TSEC_ENET=y > > +CONFIG_DM_MDIO=y > > CONFIG_DM_PCI=y > > CONFIG_DM_PCI_COMPAT=y > > CONFIG_PCIE_FSL=y > > diff --git a/configs/P1010RDB-PA_36BIT_NOR_defconfig > > b/configs/P1010RDB-PA_36BIT_NOR_defconfig > > index e6edd395e7..f5c5f0ead5 100644 > > --- a/configs/P1010RDB-PA_36BIT_NOR_defconfig > > +++ b/configs/P1010RDB-PA_36BIT_NOR_defconfig > > @@ -54,8 +54,10 @@ CONFIG_PHY_SMSC=y > > CONFIG_PHY_VITESSE=y > > CONFIG_PHY_GIGE=y > > CONFIG_E1000=y > > +CONFIG_DM_ETH=y > > CONFIG_MII=y > > CONFIG_TSEC_ENET=y > > +CONFIG_DM_MDIO=y > > CONFIG_DM_PCI=y > > CONFIG_DM_PCI_COMPAT=y > > CONFIG_PCIE_FSL=y > > diff --git a/configs/P1010RDB-PA_36BIT_SDCARD_defconfig > > b/configs/P1010RDB-PA_36BIT_SDCARD_defconfig > > index dcd606b0c2..229365a1eb 100644 > > --- a/configs/P1010RDB-PA_36BIT_SDCARD_defconfig > > +++ b/configs/P1010RDB-PA_36BIT_SDCARD_defconfig > > @@ -66,8 +66,10 @@ CONFIG_PHY_SMSC=y > > CONFIG_PHY_VITESSE=y > > CONFIG_PHY_GIGE=y > > CONFIG_E1000=y > > +CONFIG_DM_ETH=y > > CONFIG_MII=y > > CONFIG_TSEC_ENET=y > > +CONFIG_DM_MDIO=y > > CONFIG_DM_PCI=y > > CONFIG_DM_PCI_COMPAT=y > > CONFIG_PCIE_FSL=y > > diff --git a/configs/P1010RDB-PA_36BIT_SPIFLASH_defconfig > > b/configs/P1010RDB-PA_36BIT_SPIFLASH_defconfig > > index c0800c8d7d..147198fb88 100644 > > --- a/configs/P1010RDB-PA_36BIT_SPIFLASH_defconfig > > +++ b/configs/P1010RDB-PA_36BIT_SPIFLASH_defconfig > > @@ -68,8 +68,10 @@ CONFIG_PHY_SMSC=y > > CONFIG_PHY_VITESSE=y > > CONFIG_PHY_GIGE=y > > CONFIG_E1000=y > > +CONFIG_DM_ETH=y > > CONFIG_MII=y > > CONFIG_TSEC_ENET=y > > +CONFIG_DM_MDIO=y > > CONFIG_DM_PCI=y > > CONFIG_DM_PCI_COMPAT=y > > CONFIG_PCIE_FSL=y > > diff --git a/configs/P1010RDB-PA_NAND_defconfig > > b/configs/P1010RDB-PA_NAND_defconfig > > index 29ba692ca1..1f2472a338 100644 > > --- a/configs/P1010RDB-PA_NAND_defconfig > > +++ b/configs/P1010RDB-PA_NAND_defconfig > > @@ -71,8 +71,10 @@ CONFIG_PHY_SMSC=y > > CONFIG_PHY_VITESSE=y > > CONFIG_PHY_GIGE=y > > CONFIG_E1000=y > > +CONFIG_DM_ETH=y > > CONFIG_MII=y > > CONFIG_TSEC_ENET=y > > +CONFIG_DM_MDIO=y > > CONFIG_DM_PCI=y > > CONFIG_DM_PCI_
RE: [PATCHv3 15/15] configs: P2020RDB: Enable DM_ETH config
Hi Vladimir, Thanks a lot for your review! Regards, Zhiqiang > -Original Message- > From: Vladimir Oltean > Sent: 2020年6月13日 4:17 > To: Z.q. Hou > Cc: u-boot ; Priyanka Jain ; > Bin Meng > Subject: Re: [PATCHv3 15/15] configs: P2020RDB: Enable DM_ETH config > > On Fri, 12 Jun 2020 at 18:23, Zhiqiang Hou wrote: > > > > From: Hou Zhiqiang > > > > Enable the DM_ETH and DM_MDIO config. > > > > On P2020RDB, the eTSEC1 is connecting with a switch VSC7385, so also > > enable the fixed PHY support. > > > > Signed-off-by: Hou Zhiqiang > > --- > > Reviewed-by: Vladimir Oltean > > > V3: > > - Rebase the patch, no change intended. > > > > configs/P2020RDB-PC_36BIT_NAND_defconfig | 3 +++ > > configs/P2020RDB-PC_36BIT_SDCARD_defconfig | 3 +++ > > configs/P2020RDB-PC_36BIT_SPIFLASH_defconfig | 3 +++ > > configs/P2020RDB-PC_36BIT_defconfig | 3 +++ > > configs/P2020RDB-PC_NAND_defconfig | 3 +++ > > configs/P2020RDB-PC_SDCARD_defconfig | 3 +++ > > configs/P2020RDB-PC_SPIFLASH_defconfig | 3 +++ > > configs/P2020RDB-PC_defconfig| 3 +++ > > 8 files changed, 24 insertions(+) > > > > diff --git a/configs/P2020RDB-PC_36BIT_NAND_defconfig > > b/configs/P2020RDB-PC_36BIT_NAND_defconfig > > index 3e6ea64ee3..4cd689f55d 100644 > > --- a/configs/P2020RDB-PC_36BIT_NAND_defconfig > > +++ b/configs/P2020RDB-PC_36BIT_NAND_defconfig > > @@ -66,6 +66,7 @@ CONFIG_SPI_FLASH=y > > CONFIG_SF_DEFAULT_MODE=0 > > CONFIG_SF_DEFAULT_SPEED=1000 > > CONFIG_SPI_FLASH_SPANSION=y > > +CONFIG_PHY_FIXED=y > > CONFIG_PHY_ATHEROS=y > > CONFIG_PHY_BROADCOM=y > > CONFIG_PHY_DAVICOM=y > > @@ -77,8 +78,10 @@ CONFIG_PHY_SMSC=y > > CONFIG_PHY_VITESSE=y > > CONFIG_PHY_GIGE=y > > CONFIG_E1000=y > > +CONFIG_DM_ETH=y > > CONFIG_MII=y > > CONFIG_TSEC_ENET=y > > +CONFIG_DM_MDIO=y > > CONFIG_DM_PCI=y > > CONFIG_DM_PCI_COMPAT=y > > CONFIG_PCIE_FSL=y > > diff --git a/configs/P2020RDB-PC_36BIT_SDCARD_defconfig > > b/configs/P2020RDB-PC_36BIT_SDCARD_defconfig > > index 187cbee0d6..f46463a297 100644 > > --- a/configs/P2020RDB-PC_36BIT_SDCARD_defconfig > > +++ b/configs/P2020RDB-PC_36BIT_SDCARD_defconfig > > @@ -61,6 +61,7 @@ CONFIG_SPI_FLASH=y > > CONFIG_SF_DEFAULT_MODE=0 > > CONFIG_SF_DEFAULT_SPEED=1000 > > CONFIG_SPI_FLASH_SPANSION=y > > +CONFIG_PHY_FIXED=y > > CONFIG_PHY_ATHEROS=y > > CONFIG_PHY_BROADCOM=y > > CONFIG_PHY_DAVICOM=y > > @@ -72,8 +73,10 @@ CONFIG_PHY_SMSC=y > > CONFIG_PHY_VITESSE=y > > CONFIG_PHY_GIGE=y > > CONFIG_E1000=y > > +CONFIG_DM_ETH=y > > CONFIG_MII=y > > CONFIG_TSEC_ENET=y > > +CONFIG_DM_MDIO=y > > CONFIG_DM_PCI=y > > CONFIG_DM_PCI_COMPAT=y > > CONFIG_PCIE_FSL=y > > diff --git a/configs/P2020RDB-PC_36BIT_SPIFLASH_defconfig > > b/configs/P2020RDB-PC_36BIT_SPIFLASH_defconfig > > index 88c9224001..73d1be1013 100644 > > --- a/configs/P2020RDB-PC_36BIT_SPIFLASH_defconfig > > +++ b/configs/P2020RDB-PC_36BIT_SPIFLASH_defconfig > > @@ -63,6 +63,7 @@ CONFIG_SPI_FLASH=y > > CONFIG_SF_DEFAULT_MODE=0 > > CONFIG_SF_DEFAULT_SPEED=1000 > > CONFIG_SPI_FLASH_SPANSION=y > > +CONFIG_PHY_FIXED=y > > CONFIG_PHY_ATHEROS=y > > CONFIG_PHY_BROADCOM=y > > CONFIG_PHY_DAVICOM=y > > @@ -74,8 +75,10 @@ CONFIG_PHY_SMSC=y > > CONFIG_PHY_VITESSE=y > > CONFIG_PHY_GIGE=y > > CONFIG_E1000=y > > +CONFIG_DM_ETH=y > > CONFIG_MII=y > > CONFIG_TSEC_ENET=y > > +CONFIG_DM_MDIO=y > > CONFIG_DM_PCI=y > > CONFIG_DM_PCI_COMPAT=y > > CONFIG_PCIE_FSL=y > > diff --git a/configs/P2020RDB-PC_36BIT_defconfig > > b/configs/P2020RDB-PC_36BIT_defconfig > > index 88e24c30ba..21a0e85f98 100644 > > --- a/configs/P2020RDB-PC_36BIT_defconfig > > +++ b/configs/P2020RDB-PC_36BIT_defconfig > > @@ -50,6 +50,7 @@ CONFIG_SPI_FLASH=y > > CONFIG_SF_DEFAULT_MODE=0 > > CONFIG_SF_DEFAULT_SPEED=1000 > > CONFIG_SPI_FLASH_SPANSION=y > > +CONFIG_PHY_FIXED=y > > CONFIG_PHY_ATHEROS=y > > CONFIG_PHY_BROADCOM=y > > CONFIG_PHY_DAVICOM=y > > @@ -61,8 +62,10 @@ CONFIG_PHY_SMSC=y > > CONFIG_PHY_VITESSE=y > > CONFIG_PHY_GIGE=y > > CONFIG_E1000=y > > +CONFIG_DM_ETH=y > > CONFIG_MII=y > > CONFIG_TSEC_ENET=y > > +CONFIG_DM_MDIO=y > > CONFIG_DM_PCI=y > > CONFIG_DM_PCI_COMPAT=y > > CONFIG_PCIE_FSL=y > > diff --git a/configs/P2020RDB-PC_N
RE: [PATCHv3 08/15] dts: powerpc: p1020rdb: Add eTSEC DT nodes
Hi Vladimir,
Thanks a lot for your comments!
> -Original Message-
> From: Vladimir Oltean [mailto:olte...@gmail.com]
> Sent: 2020年6月13日 4:15
> To: Z.q. Hou
> Cc: u-boot ; Priyanka Jain ;
> Bin Meng
> Subject: Re: [PATCHv3 08/15] dts: powerpc: p1020rdb: Add eTSEC DT nodes
>
> On Fri, 12 Jun 2020 at 18:23, Zhiqiang Hou wrote:
> >
> > From: Hou Zhiqiang
> >
> > P1020RDB implements 3 enhanced three-speed Ethernet controllers, and
> > the connection is shown below:
> > eTSEC1: Connected to RGMII PHY VSC7385
>
> As you said in a previous patch, VSC7385 is a switch, not a PHY.
These connection info was copied from the kernel changelog without further
polish.
I'll correct it in next version.
>
> > eTSEC2: Connected to SGMII PHY VSC8221
> > eTSEC3: Connected to SGMII PHY AR8021
> >
> > Signed-off-by: Hou Zhiqiang
> > ---
> > V3:
> > - Rebase the patch, no change intended.
> >
> > arch/powerpc/dts/p1020-post.dtsi| 16 +++
> > arch/powerpc/dts/p1020rdb-pc.dts| 1 +
> > arch/powerpc/dts/p1020rdb-pc.dtsi | 55
>
> > arch/powerpc/dts/p1020rdb-pc_36b.dts| 1 +
> > arch/powerpc/dts/p1020rdb-pd.dts| 57
> +
> > arch/powerpc/dts/pq3-etsec2-0.dtsi | 35 +++
> > arch/powerpc/dts/pq3-etsec2-1.dtsi | 35 +++
> > arch/powerpc/dts/pq3-etsec2-2.dtsi | 35 +++
> > arch/powerpc/dts/pq3-etsec2-grp2-0.dtsi | 16 +++
> > arch/powerpc/dts/pq3-etsec2-grp2-1.dtsi | 16 +++
> > arch/powerpc/dts/pq3-etsec2-grp2-2.dtsi | 16 +++
> > 11 files changed, 283 insertions(+)
> > create mode 100644 arch/powerpc/dts/p1020rdb-pc.dtsi create mode
> > 100644 arch/powerpc/dts/pq3-etsec2-0.dtsi
> > create mode 100644 arch/powerpc/dts/pq3-etsec2-1.dtsi
> > create mode 100644 arch/powerpc/dts/pq3-etsec2-2.dtsi
> > create mode 100644 arch/powerpc/dts/pq3-etsec2-grp2-0.dtsi
> > create mode 100644 arch/powerpc/dts/pq3-etsec2-grp2-1.dtsi
> > create mode 100644 arch/powerpc/dts/pq3-etsec2-grp2-2.dtsi
> >
> > diff --git a/arch/powerpc/dts/p1020-post.dtsi
> > b/arch/powerpc/dts/p1020-post.dtsi
> > index 1dce8e86e9..2c0aa7a5c3 100644
> > --- a/arch/powerpc/dts/p1020-post.dtsi
> > +++ b/arch/powerpc/dts/p1020-post.dtsi
> > @@ -46,8 +46,24 @@
> >
> > /include/ "pq3-i2c-0.dtsi"
> > /include/ "pq3-i2c-1.dtsi"
> > +
> > +/include/ "pq3-etsec2-0.dtsi"
>
> Could you keep the indentation level of this include the same as the others?
I don't think it is a good style to add indentation for the /include/ lines, I
don't
know why Biwen added it for these 2, and not for others.
I can help to remove the indentation for the i2c include entries.
>
> > + enet0: enet0_grp2: ethernet@b {
>
> I don't understand why you're doing it like this (i.e. specifying the label
> here,
> and using it in pq3-etsec2-grp2-0.dtsi, vs just specifying the full path in
> pq3-etsec2-grp2-0.dtsi).
These DT nodes was copied from the Linux.
>
> > + };
> > +
> > +/include/ "pq3-etsec2-1.dtsi"
> > + enet1: enet1_grp2: ethernet@b1000 {
> > + };
> > +
> > +/include/ "pq3-etsec2-2.dtsi"
> > + enet2: enet2_grp2: ethernet@b2000 {
> > + };
> > };
> >
> > +/include/ "pq3-etsec2-grp2-0.dtsi"
> > +/include/ "pq3-etsec2-grp2-1.dtsi"
> > +/include/ "pq3-etsec2-grp2-2.dtsi"
> > +
> > /* PCIe controller base address 0x9000 */
> > {
> > compatible = "fsl,pcie-p1_p2", "fsl,pcie-fsl-qoriq"; diff
> > --git a/arch/powerpc/dts/p1020rdb-pc.dts
> > b/arch/powerpc/dts/p1020rdb-pc.dts
> > index 7ebaa619df..715330dc50 100644
> > --- a/arch/powerpc/dts/p1020rdb-pc.dts
> > +++ b/arch/powerpc/dts/p1020rdb-pc.dts
> > @@ -32,4 +32,5 @@
> > };
> > };
> >
> > +/include/ "p1020rdb-pc.dtsi"
> > /include/ "p1020-post.dtsi"
> > diff --git a/arch/powerpc/dts/p1020rdb-pc.dtsi
> > b/arch/powerpc/dts/p1020rdb-pc.dtsi
> > new file mode 100644
> > index 00..6bf424fd3f
> > --- /dev/null
> > +++ b/arch/powerpc/dts/p1020rdb-pc.dtsi
> > @@ -0,0 +1,55 @@
> > +// SPDX-License-Identifier: GPL-2.0+ OR X11
> > +/*
> > + * P1020 RDB-PC Device Tree Source stub (no addresses or top-level
> > +ranges)
> > + *
> > + * Copyright 2012 Freescale Semicondu
RE: [PATCHv2 01/36] dm: spi: Convert Freescale ESPI driver to driver model
Hi Jagan,
Thanks for your comments!
> -Original Message-
> From: Jagan Teki [mailto:ja...@amarulasolutions.com]
> Sent: 2020年6月3日 15:41
> To: Z.q. Hou
> Cc: U-Boot-Denx ; Priyanka Jain
> ; Shengzhou Liu ; Simon
> Glass ; Biwen Li ; Bin Meng
> ; Jiafei Pan ; Chuanhua Han
> ; Xiaowei Bao
> Subject: Re: [PATCHv2 01/36] dm: spi: Convert Freescale ESPI driver to driver
> model
>
> On Wed, Jun 3, 2020 at 7:33 AM Z.q. Hou wrote:
> >
> > Hi Jagan,
> >
> > Thanks a lot for your comments!
> >
> > > -Original Message-
> > > From: Jagan Teki
> > > Sent: 2020年6月3日 3:29
> > > To: Z.q. Hou
> > > Cc: U-Boot-Denx ; Priyanka Jain
> > > ; Shengzhou Liu ;
> > > Simon Glass ; Biwen Li ; Bin
> > > Meng ; Jiafei Pan ;
> Chuanhua
> > > Han ; Xiaowei Bao
> > > Subject: Re: [PATCHv2 01/36] dm: spi: Convert Freescale ESPI driver
> > > to driver model
> > >
> > > On Tue, Jun 2, 2020 at 7:10 PM Zhiqiang Hou
> > > wrote:
> > > >
> > > > From: Chuanhua Han
> > > >
> > > > Modify the Freescale ESPI driver to support the driver model.
> > > > Also resolved the following problems:
> > > >
> > > > = WARNING == This
> > > board does
> > > > not use CONFIG_DM_SPI. Please update the board before v2019.04 for
> > > > no dm conversion and v2019.07 for partially dm converted drivers.
> > > > Failure to update can lead to driver/board removal See
> > > > doc/driver-model/MIGRATION.txt for more info.
> > > >
> > > > = WARNING == This
> > > board does
> > > > not use CONFIG_DM_SPI_FLASH. Please update the board to use
> > > > CONFIG_SPI_FLASH before the v2019.07 release.
> > > > Failure to update by the deadline may result in board removal.
> > > > See doc/driver-model/MIGRATION.txt for more info.
> > > >
> > > >
> > > > Signed-off-by: Chuanhua Han
> > > > Signed-off-by: Xiaowei Bao
> > > > Signed-off-by: Hou Zhiqiang
> > > > ---
> > > > V2:
> > > > - Rebase the patch, no change intended.
> > > >
> > > > drivers/spi/fsl_espi.c | 444
> > >
> > > > include/dm/platform_data/fsl_espi.h | 16 +
> > > > 2 files changed, 337 insertions(+), 123 deletions(-) create mode
> > > > 100644 include/dm/platform_data/fsl_espi.h
> > > >
> > > > diff --git a/drivers/spi/fsl_espi.c b/drivers/spi/fsl_espi.c index
> > > > 50d194f614..5c76fd962e 100644
> > > > --- a/drivers/spi/fsl_espi.c
> > > > +++ b/drivers/spi/fsl_espi.c
> > > > @@ -3,7 +3,9 @@
> > > > * eSPI controller driver.
> > > > *
> > > > * Copyright 2010-2011 Freescale Semiconductor, Inc.
> > > > + * Copyright 2020 NXP
> > > > * Author: Mingkai Hu (mingkai...@freescale.com)
> > > > + *Chuanhua Han (chuanhua@nxp.com)
> > > > */
> > > >
> > > > #include
> > > > @@ -14,10 +16,16 @@
> > > > #include
> > > > #include
> > > > #include
> > > > +#include
> > > > +#include
> > > > +#include
> > > > +#include
> > > >
> > > > struct fsl_spi_slave {
> > > > struct spi_slave slave;
> > > > ccsr_espi_t *espi;
> > > > + u32 speed_hz;
> > > > + unsigned intcs;
> > > > unsigned intdiv16;
> > > > unsigned intpm;
> > > > int tx_timeout;
> > > > @@ -31,6 +39,9 @@ struct fsl_spi_slave { #define
> > > > to_fsl_spi_slave(s) container_of(s, struct fsl_spi_slave, slave)
> > > > #define US_PER_SECOND 100UL
> > > >
> > > > +/* default SCK frequency, unit: HZ */
> > > > +#define FSL_ESPI_DEFAULT_SCK_FREQ 1000
> > > > +
> > > > #define ESPI_MAX_CS_NUM4
> > > > #define ESPI_FIFO_WIDTH_BIT32
> > > >
> > > > @@ -65,116 +76,27 @@ struct fsl_spi_slave {
> > > >
> > > > #define ESPI_MAX_DATA_TRANSFER_L
RE: [PATCHv4 3/3] spi: Convert CONFIG_DM_SPI* to CONFIG_$(SPL_TPL_)DM_SPI*
Hi Jagan, Thanks a lot for your comments! > -Original Message- > From: Jagan Teki [mailto:ja...@amarulasolutions.com] > Sent: 2020年6月3日 15:39 > To: Z.q. Hou > Cc: Tom Rini ; U-Boot-Denx ; > Lokesh Vutla ; Andrew F Davis ; Heiko > Schocher ; Simon Glass ; Feng Li > ; Alison Wang ; Sumit Garg > ; Eugen Hristev ; > Patrick Delaunay ; Vignesh R ; > Joe Hershberger ; Stefan Roese ; > Wolfgang Denk ; Lukasz Majewski ; Miquel > Raynal ; Marek Vasut ; Bin > Meng ; Simon Goldschmidt > ; Markus Klotzbuecher > ; Baruch Siach ; > Harald Seiler ; Joel Johnson ; Anatolij > Gustschin ; Priyanka Jain ; > Madalin Bucur (OSS) ; Gervais, Francois > ; Udit Agarwal > Subject: Re: [PATCHv4 3/3] spi: Convert CONFIG_DM_SPI* to > CONFIG_$(SPL_TPL_)DM_SPI* > > On Wed, Jun 3, 2020 at 7:16 AM Z.q. Hou wrote: > > > > Hi Tom and Jagan, > > > > Thanks a lot for your comments! > > > > > -Original Message- > > > From: Tom Rini > > > Sent: 2020年6月3日 3:02 > > > To: Jagan Teki ; Z.q. Hou > > > > > > Cc: U-Boot-Denx ; Lokesh Vutla > > > ; Andrew F Davis ; Heiko Schocher > > > ; Simon Glass ; Feng Li > > > ; Alison Wang ; Sumit Garg > > > ; Eugen Hristev ; > > > Patrick Delaunay ; Vignesh R > > > ; Joe Hershberger ; Stefan > > > Roese ; Wolfgang Denk ; Lukasz Majewski > > > ; Miquel Raynal ; Marek > > > Vasut ; Bin Meng ; Simon > > > Goldschmidt ; Markus Klotzbuecher > > > ; Baruch Siach ; > > > Harald Seiler ; Joel Johnson ; > > > Anatolij Gustschin ; Priyanka Jain > > > ; Madalin Bucur (OSS) > > > ; Gervais, Francois > > > ; Udit Agarwal > > > > Subject: Re: [PATCHv4 3/3] spi: Convert CONFIG_DM_SPI* to > > > CONFIG_$(SPL_TPL_)DM_SPI* > > > > > > On Wed, Jun 03, 2020 at 12:10:30AM +0530, Jagan Teki wrote: > > > > On Tue, Jun 2, 2020 at 11:57 PM Tom Rini wrote: > > > > > > > > > > On Tue, Jun 02, 2020 at 06:59:21PM +0530, Jagan Teki wrote: > > > > > > On Tue, Jun 2, 2020 at 6:47 PM Zhiqiang Hou > > > > > > > > > wrote: > > > > > > > > > > > > > > From: Lukasz Majewski > > > > > > > > > > > > > > This change allows more fine tuning of driver model based > > > > > > > SPI support in SPL and TPL. It is now possible to explicitly > > > > > > > enable/disable the DM_SPI support in SPL and TPL via Kconfig > option. > > > > > > > > > > > > > > Before this change it was necessary to use: > > > > > > > /* SPI Flash Configs */ > > > > > > > #if defined(CONFIG_SPL_BUILD) > > > > > > > #undef CONFIG_DM_SPI > > > > > > > #undef CONFIG_DM_SPI_FLASH > > > > > > > #undef CONFIG_SPI_FLASH_MTD > > > > > > > #endif > > > > > > > > > > > > > > in the ./include/configs/.h, which is error prone and > > > > > > > shall be avoided when we strive to switch to Kconfig. > > > > > > > > > > > > > > The goal of this patch: > > > > > > > > > > > > > > Provide distinction for DM_SPI support in both U-Boot proper > > > > > > > and SPL > > > (TPL). > > > > > > > Valid use case is when U-Boot proper wants to use DM_SPI, > > > > > > > but SPL must still support non DM driver. > > > > > > > > > > > > > > Another use case is the conversion of non DM/DTS SPI driver > > > > > > > to support DM/DTS. When such driver needs to work in both > > > > > > > SPL and U-Boot proper, the distinction is needed in Kconfig > > > > > > > (also if SPL version of the driver supports OF_PLATDATA). > > > > > > > > > > > > > > In the end of the day one would have to support following > > > > > > > use cases (in single driver file - e.g. mxs_spi.c): > > > > > > > > > > > > > > - U-Boot proper driver supporting DT/DTS > > > > > > > - U-Boot proper driver without DT/DTS support (deprecated) > > > > > > > - SPL driver without DT/DTS support > > > > > > > - SPL (and TPL) driver with DT/DTS (when the SoC has enough &
RE: [PATCHv4 1/3] spi: Move DM_SPI_FLASH to Kconfig (for NXP's ls1043a)
Hi Priyanka, Thanks a lot for your comments! > -Original Message- > From: Priyanka Jain (OSS) > Sent: 2020年6月3日 15:20 > To: Z.q. Hou ; u-boot@lists.denx.de; > lokeshvu...@ti.com; a...@ti.com; h...@denx.de; s...@chromium.org; > feng.l...@nxp.com; Alison Wang ; > sumit.g...@nxp.com; eugen.hris...@microchip.com; > patrick.delau...@st.com; ja...@amarulasolutions.com; vigne...@ti.com; > joe.hershber...@ni.com; s...@denx.de; w...@denx.de; lu...@denx.de; > miquel.ray...@bootlin.com; ma...@denx.de; bmeng...@gmail.com; > simon.k.r.goldschm...@gmail.com; markus.klotzbuec...@kistler.com; > bar...@tkos.co.il; h...@denx.de; mrj...@lixil.net; ag...@denx.de; Madalin > Bucur (OSS) ; Gervais, Francois > ; Udit Agarwal > Cc: Z.q. Hou > Subject: RE: [PATCHv4 1/3] spi: Move DM_SPI_FLASH to Kconfig (for NXP's > ls1043a) > > >-Original Message- > >From: U-Boot On Behalf Of Zhiqiang Hou > >Sent: Tuesday, June 2, 2020 6:41 PM > >To: u-boot@lists.denx.de; lokeshvu...@ti.com; a...@ti.com; h...@denx.de; > >s...@chromium.org; feng.l...@nxp.com; Alison Wang > ; > >sumit.g...@nxp.com; eugen.hris...@microchip.com; > >patrick.delau...@st.com; ja...@amarulasolutions.com; vigne...@ti.com; > >joe.hershber...@ni.com; s...@denx.de; w...@denx.de; lu...@denx.de; > >miquel.ray...@bootlin.com; ma...@denx.de; bmeng...@gmail.com; > >simon.k.r.goldschm...@gmail.com; markus.klotzbuec...@kistler.com; > >bar...@tkos.co.il; h...@denx.de; mrj...@lixil.net; ag...@denx.de; > >Priyanka Jain ; Madalin Bucur (OSS) > >; Gervais, Francois > >; Udit Agarwal > >Cc: Z.q. Hou > >Subject: [PATCHv4 1/3] spi: Move DM_SPI_FLASH to Kconfig (for NXP's > >ls1043a) > > > >From: Lukasz Majewski > > > >This patch fixes issue with defining the DM_SPI_FLASH in the > >configs/include/ instead of enabling this option in Kconfig. > > > >The problem is that CONFIG_IS_ENABLED(DM_SPI_FLASH) shows false as > >there is no DM_SPI_FLASH=y in .config (but the define is set in u-boot.cfg). > > > >As a result conversion of DM_SPI_FLASH to using CONFIG_IS_ENABLED() is > >not working properly. > > > >Signed-off-by: Lukasz Majewski > >Signed-off-by: Hou Zhiqiang > >--- > >V4: > > - Rebase the patch, no change intended. > > > > arch/arm/Kconfig | 4 > > include/configs/ls1043a_common.h | 2 -- > > 2 files changed, 4 insertions(+), 2 deletions(-) > > > >diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index > >21df1c415f..28b8e9354f 100644 > >--- a/arch/arm/Kconfig > >+++ b/arch/arm/Kconfig > >@@ -1501,6 +1501,8 @@ config TARGET_LS1043AQDS > > select BOARD_LATE_INIT > > select SUPPORT_SPL > > select FSL_DDR_INTERACTIVE if !SPL > >+select FSL_DSPI if !SPL_NO_DSPI > >+select DM_SPI_FLASH if FSL_DSPI && !SPL_NO_DSPI > Since you have already added check for !SPL_NO_DSPI in previous statement, > no need to add here. Make sense, will drop the redundant condition in next version. > > imply SCSI > > imply SCSI_AHCI > > help > >@@ -1515,6 +1517,8 @@ config TARGET_LS1043ARDB > > select BOARD_EARLY_INIT_F > > select BOARD_LATE_INIT > > select SUPPORT_SPL > >+select FSL_DSPI if !SPL_NO_DSPI > >+select DM_SPI_FLASH if FSL_DSPI && !SPL_NO_DSPI > Since you have already added check for !SPL_NO_DSPI in previous statement, > no need to add here. Ditto. Thanks, Zhiqiang > > help > > Support for Freescale LS1043ARDB platform. > > > >diff --git a/include/configs/ls1043a_common.h > >b/include/configs/ls1043a_common.h > >index 985f40412c..0857b15fe0 100644 > >--- a/include/configs/ls1043a_common.h > >+++ b/include/configs/ls1043a_common.h > >@@ -176,9 +176,7 @@ > > > > /* DSPI */ > > #ifndef SPL_NO_DSPI > >-#define CONFIG_FSL_DSPI > > #ifdef CONFIG_FSL_DSPI > >-#define CONFIG_DM_SPI_FLASH > > #define CONFIG_SPI_FLASH_STMICRO/* cs0 */ > > #define CONFIG_SPI_FLASH_SST/* cs1 */ > > #define CONFIG_SPI_FLASH_EON/* cs2 */ > >-- > >2.17.1 > Thanks > Priyanka
RE: [PATCH 01/13] net: fsl_pq_mdio: Add the compatible "fsl, gianfar-mdio" support
Hi Priyanka, Thanks a lot for your comments! > -Original Message- > From: Priyanka Jain (OSS) > Sent: 2020年6月3日 14:53 > To: Z.q. Hou ; u-boot@lists.denx.de; > bmeng...@gmail.com; olte...@gmail.com > Cc: Z.q. Hou > Subject: RE: [PATCH 01/13] net: fsl_pq_mdio: Add the compatible "fsl, > gianfar-mdio" support > > >-Original Message- > >From: U-Boot On Behalf Of Zhiqiang Hou > >Sent: Tuesday, May 5, 2020 5:08 PM > >To: u-boot@lists.denx.de; bmeng...@gmail.com; olte...@gmail.com; > >Priyanka Jain > >Cc: Z.q. Hou > >Subject: [PATCH 01/13] net: fsl_pq_mdio: Add the compatible "fsl, > >gianfar- mdio" support > > > >From: Hou Zhiqiang > > > >Add compatible string "fsl,gianfar-mdio" support and update the > >device-tree- bindings doc. > > > >Signed-off-by: Hou Zhiqiang > >--- > > > Kindly rebase this series on top of > https://gitlab.denx.de/u-boot/custodians/u-boot-mpc85xx > branch:next Yes, I'll. Thanks, Zhiqiang > > Regards > Priyanka
RE: [PATCHv2 01/36] dm: spi: Convert Freescale ESPI driver to driver model
Hi Jagan,
Thanks a lot for your comments!
> -Original Message-
> From: Jagan Teki
> Sent: 2020年6月3日 3:29
> To: Z.q. Hou
> Cc: U-Boot-Denx ; Priyanka Jain
> ; Shengzhou Liu ; Simon
> Glass ; Biwen Li ; Bin Meng
> ; Jiafei Pan ; Chuanhua Han
> ; Xiaowei Bao
> Subject: Re: [PATCHv2 01/36] dm: spi: Convert Freescale ESPI driver to driver
> model
>
> On Tue, Jun 2, 2020 at 7:10 PM Zhiqiang Hou
> wrote:
> >
> > From: Chuanhua Han
> >
> > Modify the Freescale ESPI driver to support the driver model.
> > Also resolved the following problems:
> >
> > = WARNING == This
> board does
> > not use CONFIG_DM_SPI. Please update the board before v2019.04 for no
> > dm conversion and v2019.07 for partially dm converted drivers.
> > Failure to update can lead to driver/board removal See
> > doc/driver-model/MIGRATION.txt for more info.
> >
> > = WARNING == This
> board does
> > not use CONFIG_DM_SPI_FLASH. Please update the board to use
> > CONFIG_SPI_FLASH before the v2019.07 release.
> > Failure to update by the deadline may result in board removal.
> > See doc/driver-model/MIGRATION.txt for more info.
> >
> >
> > Signed-off-by: Chuanhua Han
> > Signed-off-by: Xiaowei Bao
> > Signed-off-by: Hou Zhiqiang
> > ---
> > V2:
> > - Rebase the patch, no change intended.
> >
> > drivers/spi/fsl_espi.c | 444
>
> > include/dm/platform_data/fsl_espi.h | 16 +
> > 2 files changed, 337 insertions(+), 123 deletions(-) create mode
> > 100644 include/dm/platform_data/fsl_espi.h
> >
> > diff --git a/drivers/spi/fsl_espi.c b/drivers/spi/fsl_espi.c index
> > 50d194f614..5c76fd962e 100644
> > --- a/drivers/spi/fsl_espi.c
> > +++ b/drivers/spi/fsl_espi.c
> > @@ -3,7 +3,9 @@
> > * eSPI controller driver.
> > *
> > * Copyright 2010-2011 Freescale Semiconductor, Inc.
> > + * Copyright 2020 NXP
> > * Author: Mingkai Hu (mingkai...@freescale.com)
> > + *Chuanhua Han (chuanhua@nxp.com)
> > */
> >
> > #include
> > @@ -14,10 +16,16 @@
> > #include
> > #include
> > #include
> > +#include
> > +#include
> > +#include
> > +#include
> >
> > struct fsl_spi_slave {
> > struct spi_slave slave;
> > ccsr_espi_t *espi;
> > + u32 speed_hz;
> > + unsigned intcs;
> > unsigned intdiv16;
> > unsigned intpm;
> > int tx_timeout;
> > @@ -31,6 +39,9 @@ struct fsl_spi_slave { #define to_fsl_spi_slave(s)
> > container_of(s, struct fsl_spi_slave, slave)
> > #define US_PER_SECOND 100UL
> >
> > +/* default SCK frequency, unit: HZ */
> > +#define FSL_ESPI_DEFAULT_SCK_FREQ 1000
> > +
> > #define ESPI_MAX_CS_NUM4
> > #define ESPI_FIFO_WIDTH_BIT32
> >
> > @@ -65,116 +76,27 @@ struct fsl_spi_slave {
> >
> > #define ESPI_MAX_DATA_TRANSFER_LEN 0xFFF0
> >
> > -struct spi_slave *spi_setup_slave(unsigned int bus, unsigned int cs,
> > - unsigned int max_hz, unsigned int mode)
> > -{
> > - struct fsl_spi_slave *fsl;
> > - sys_info_t sysinfo;
> > - unsigned long spibrg = 0;
> > - unsigned long spi_freq = 0;
> > - unsigned char pm = 0;
> > -
> > - if (!spi_cs_is_valid(bus, cs))
> > - return NULL;
> > -
> > - fsl = spi_alloc_slave(struct fsl_spi_slave, bus, cs);
> > - if (!fsl)
> > - return NULL;
> > -
> > - fsl->espi = (void *)(CONFIG_SYS_MPC85xx_ESPI_ADDR);
> > - fsl->mode = mode;
> > - fsl->max_transfer_length = ESPI_MAX_DATA_TRANSFER_LEN;
> > -
> > - /* Set eSPI BRG clock source */
> > - get_sys_info();
> > - spibrg = sysinfo.freq_systembus / 2;
> > - fsl->div16 = 0;
> > - if ((spibrg / max_hz) > 32) {
> > - fsl->div16 = ESPI_CSMODE_DIV16;
> > - pm = spibrg / (max_hz * 16 * 2);
> > - if (pm > 16) {
> > - pm = 16;
> > - debug("Requested speed is too low: %d
> Hz, %ld Hz "
> > - "is used.\n", m
RE: [PATCHv4 3/3] spi: Convert CONFIG_DM_SPI* to CONFIG_$(SPL_TPL_)DM_SPI*
Hi Tom and Jagan,
Thanks a lot for your comments!
> -Original Message-
> From: Tom Rini
> Sent: 2020年6月3日 3:02
> To: Jagan Teki ; Z.q. Hou
>
> Cc: U-Boot-Denx ; Lokesh Vutla
> ; Andrew F Davis ; Heiko Schocher
> ; Simon Glass ; Feng Li
> ; Alison Wang ; Sumit Garg
> ; Eugen Hristev ;
> Patrick Delaunay ; Vignesh R ;
> Joe Hershberger ; Stefan Roese ;
> Wolfgang Denk ; Lukasz Majewski ; Miquel
> Raynal ; Marek Vasut ; Bin
> Meng ; Simon Goldschmidt
> ; Markus Klotzbuecher
> ; Baruch Siach ;
> Harald Seiler ; Joel Johnson ; Anatolij
> Gustschin ; Priyanka Jain ;
> Madalin Bucur (OSS) ; Gervais, Francois
> ; Udit Agarwal
> Subject: Re: [PATCHv4 3/3] spi: Convert CONFIG_DM_SPI* to
> CONFIG_$(SPL_TPL_)DM_SPI*
>
> On Wed, Jun 03, 2020 at 12:10:30AM +0530, Jagan Teki wrote:
> > On Tue, Jun 2, 2020 at 11:57 PM Tom Rini wrote:
> > >
> > > On Tue, Jun 02, 2020 at 06:59:21PM +0530, Jagan Teki wrote:
> > > > On Tue, Jun 2, 2020 at 6:47 PM Zhiqiang Hou
> wrote:
> > > > >
> > > > > From: Lukasz Majewski
> > > > >
> > > > > This change allows more fine tuning of driver model based SPI
> > > > > support in SPL and TPL. It is now possible to explicitly
> > > > > enable/disable the DM_SPI support in SPL and TPL via Kconfig option.
> > > > >
> > > > > Before this change it was necessary to use:
> > > > > /* SPI Flash Configs */
> > > > > #if defined(CONFIG_SPL_BUILD)
> > > > > #undef CONFIG_DM_SPI
> > > > > #undef CONFIG_DM_SPI_FLASH
> > > > > #undef CONFIG_SPI_FLASH_MTD
> > > > > #endif
> > > > >
> > > > > in the ./include/configs/.h, which is error prone and
> > > > > shall be avoided when we strive to switch to Kconfig.
> > > > >
> > > > > The goal of this patch:
> > > > >
> > > > > Provide distinction for DM_SPI support in both U-Boot proper and SPL
> (TPL).
> > > > > Valid use case is when U-Boot proper wants to use DM_SPI, but
> > > > > SPL must still support non DM driver.
> > > > >
> > > > > Another use case is the conversion of non DM/DTS SPI driver to
> > > > > support DM/DTS. When such driver needs to work in both SPL and
> > > > > U-Boot proper, the distinction is needed in Kconfig (also if SPL
> > > > > version of the driver supports OF_PLATDATA).
> > > > >
> > > > > In the end of the day one would have to support following use
> > > > > cases (in single driver file - e.g. mxs_spi.c):
> > > > >
> > > > > - U-Boot proper driver supporting DT/DTS
> > > > > - U-Boot proper driver without DT/DTS support (deprecated)
> > > > > - SPL driver without DT/DTS support
> > > > > - SPL (and TPL) driver with DT/DTS (when the SoC has enough
> resources to
> > > > > run full blown DT/DTS)
> > > > > - SPL driver with DT/DTS and SPL_OF_PLATDATA (when one have
> constrained
> > > > > environment with no fitImage and OF_LIBFDT support).
> > > > >
> > > > > Some boards do require SPI support (with DM) in SPL (TPL) and
> > > > > some only have DM_SPI{_FLASH} defined to allow compiling SPL.
> > > > >
> > > > > This patch converts #ifdef CONFIG_DM_SPI* to #if
> > > > > CONFIG_IS_ENABLED(DM_SPI) and provides corresponding defines in
> Kconfig.
> > > > >
> > > > > Signed-off-by: Lukasz Majewski
> > > > > Tested-by: Adam Ford #da850-evm
> > > > > Signed-off-by: Hou Zhiqiang
> > > > > ---
> > > > > V4:
> > > > > - Rebase the patch and remove SPL_DM_SPI from target ls1046
> boards.
> > > > >
> > > > > arch/arm/Kconfig| 11
> +++
> > > > > board/l+g/vinco/vinco.c | 4 ++--
> > > > > cmd/sf.c| 4 ++--
> > > > > cmd/spi.c | 6 +++---
> > > > > common/spl/Kconfig | 20
>
> > > > > configs/am57xx_evm_defconfig| 2 ++
> > > > > configs/am57xx_hs_evm_defconfig | 2 ++
> > > > > configs/am57xx_hs_evm_usb_defconfig | 2 ++
> > > > &
RE: [RFC PATCH 3/3] net: tsec: convert fsl_pq_mdio to DM_MDIO
> -Original Message-
> From: Vladimir Oltean
> Sent: 2020年5月4日 2:52
> To: u-boot@lists.denx.de; joe.hershber...@ni.com; Priyanka Jain
>
> Cc: Z.q. Hou ; bmeng...@gmail.com; Claudiu
> Manoil ; Alexandru Marginean
>
> Subject: [RFC PATCH 3/3] net: tsec: convert fsl_pq_mdio to DM_MDIO
>
> From: Vladimir Oltean
>
> For the platforms on which the eTSEC driver uses DM_ETH, convert its MDIO
> controller code to also use DM_MDIO.
>
> Note that for handling the TBI PHY (the MAC PCS for SGMII), we still don't
> register a udevice for it, since we can drive it locally and there is no
> point in
> doing otherwise.
>
> Signed-off-by: Vladimir Oltean
> ---
> drivers/net/fsl_mdio.c | 66
> ++
> drivers/net/tsec.c | 50 ++--
> include/fsl_mdio.h | 4 +--
> 3 files changed, 78 insertions(+), 42 deletions(-)
>
> diff --git a/drivers/net/fsl_mdio.c b/drivers/net/fsl_mdio.c index
> 894b52ee66f4..284508062c8e 100644
> --- a/drivers/net/fsl_mdio.c
> +++ b/drivers/net/fsl_mdio.c
> @@ -8,9 +8,11 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> +#include
>
> void tsec_local_mdio_write(struct tsec_mii_mng __iomem *phyregs, int
> port_addr,
> int dev_addr, int regnum, int value)
> @@ -56,11 +58,8 @@ int tsec_local_mdio_read(struct tsec_mii_mng
> __iomem *phyregs, int port_addr,
> return value;
> }
>
> -static int fsl_pq_mdio_reset(struct mii_dev *bus)
> +int fsl_pq_mdio_reset(struct tsec_mii_mng __iomem *regs)
> {
> - struct tsec_mii_mng __iomem *regs =
> - (struct tsec_mii_mng __iomem *)bus->priv;
> -
> /* Reset MII (due to new addresses) */
> out_be32(>miimcfg, MIIMCFG_RESET_MGMT);
>
> @@ -72,6 +71,7 @@ static int fsl_pq_mdio_reset(struct mii_dev *bus)
> return 0;
> }
>
> +#ifndef CONFIG_DM_MDIO
> int tsec_phy_read(struct mii_dev *bus, int addr, int dev_addr, int regnum) {
> struct tsec_mii_mng __iomem *phyregs = @@ -91,6 +91,11 @@ int
> tsec_phy_write(struct mii_dev *bus, int addr, int dev_addr, int regnum,
> return 0;
> }
>
> +static int tsec_mdio_reset(struct mii_dev *bus) {
> + return fsl_pq_mdio_reset(bus->priv);
> +}
> +
> int fsl_pq_mdio_init(bd_t *bis, struct fsl_pq_mdio_info *info) {
> struct mii_dev *bus = mdio_alloc();
> @@ -102,10 +107,61 @@ int fsl_pq_mdio_init(bd_t *bis, struct
> fsl_pq_mdio_info *info)
>
> bus->read = tsec_phy_read;
> bus->write = tsec_phy_write;
> - bus->reset = fsl_pq_mdio_reset;
> + bus->reset = tsec_mdio_reset;
> strcpy(bus->name, info->name);
>
> bus->priv = (void *)info->regs;
>
> return mdio_register(bus);
> }
> +#endif
> +
> +#ifdef CONFIG_DM_MDIO
> +static int dm_fsl_pq_mdio_read(struct udevice *dev, int addr, int devad,
> +int reg)
> +{
> + struct fsl_pq_mdio_info *info = dev_get_priv(dev);
> +
> + return tsec_local_mdio_read(info->regs, addr, devad, reg); }
> +
> +static int dm_fsl_pq_mdio_write(struct udevice *dev, int addr, int devad,
> + int reg, u16 val)
> +{
> + struct fsl_pq_mdio_info *info = dev_get_priv(dev);
> +
> + tsec_local_mdio_write(info->regs, addr, devad, reg, val);
> +
> + return 0;
> +}
> +
> +static int fsl_pq_mdio_probe(struct udevice *dev) {
> + struct fsl_pq_mdio_info *info = dev_get_priv(dev);
> + fdt_addr_t reg;
> +
> + reg = devfdt_get_addr(dev);
> + info->regs = map_physmem(reg + TSEC_MDIO_REGS_OFFSET, 0,
> MAP_NOCACHE);
> +
> + return fsl_pq_mdio_reset(info->regs);
> +}
> +
> +static const struct mdio_ops fsl_pq_mdio_ops = {
> + .read = dm_fsl_pq_mdio_read,
> + .write = dm_fsl_pq_mdio_write,
> +};
> +
> +static const struct udevice_id fsl_pq_mdio_ids[] = {
> + { .compatible = "fsl,etsec2-mdio" },
> + { }
> +};
> +
> +U_BOOT_DRIVER(fsl_pq_mdio) = {
> + .name = "fsl_pq_mdio",
> + .id = UCLASS_MDIO,
> + .of_match = fsl_pq_mdio_ids,
> + .probe = fsl_pq_mdio_probe,
> + .ops= _pq_mdio_ops,
> + .priv_auto_alloc_size = sizeof(struct fsl_pq_mdio_info),
> +};
> +#endif
> diff --git a/drivers/net/tsec.c b/drivers/net/tsec.c index
> 842cddf2297a..93f151a8a6db 100644
> --- a/drivers/net/tsec.c
> +++ b/drivers/net/tsec.c
> @@ -15,6 +15,7 @@
> #inc
RE: [RFC PATCH 1/3] phy: make phy_connect_fixed work with a null mdio bus
> -Original Message-
> From: Vladimir Oltean
> Sent: 2020年5月4日 2:52
> To: u-boot@lists.denx.de; joe.hershber...@ni.com; Priyanka Jain
>
> Cc: Z.q. Hou ; bmeng...@gmail.com; Claudiu
> Manoil ; Alexandru Marginean
>
> Subject: [RFC PATCH 1/3] phy: make phy_connect_fixed work with a null mdio
> bus
>
> From: Vladimir Oltean
>
> It is utterly pointless to require an MDIO bus pointer for a fixed PHY device.
> The fixed.c implementation does not require it, only phy_device_create. Fix
> that.
>
> Signed-off-by: Vladimir Oltean
> ---
> drivers/net/phy/phy.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c index
> 9a66e62e8974..dcef1aaf2026 100644
> --- a/drivers/net/phy/phy.c
> +++ b/drivers/net/phy/phy.c
> @@ -651,7 +651,7 @@ static struct phy_device *phy_device_create(struct
> mii_dev *bus, int addr,
> dev = malloc(sizeof(*dev));
> if (!dev) {
> printf("Failed to allocate PHY device for %s:%d\n",
> -bus->name, addr);
> +bus ? bus->name : "(null bus)", addr);
> return NULL;
> }
>
> @@ -679,7 +679,7 @@ static struct phy_device *phy_device_create(struct
> mii_dev *bus, int addr,
> return NULL;
> }
>
> - if (addr >= 0 && addr < PHY_MAX_ADDR)
> + if (addr >= 0 && addr < PHY_MAX_ADDR && phy_id != PHY_FIXED_ID)
> bus->phymap[addr] = dev;
>
> return dev;
> --
> 2.17.1
Reviewed-by: Hou Zhiqiang
RE: [PATCHv2 3/3] net: tsec: Access TBI PHY through the corresponding MII
Hi Vladimir,
Thanks for your comments!
> -Original Message-
> From: Vladimir Oltean
> Sent: 2020年5月4日 0:27
> To: Z.q. Hou
> Cc: u-boot ; Joe Hershberger
> ; Bin Meng ; Priyanka Jain
>
> Subject: Re: [PATCHv2 3/3] net: tsec: Access TBI PHY through the
> corresponding MII
>
> On Sun, 3 May 2020 at 17:53, Zhiqiang Hou wrote:
> >
> > From: Hou Zhiqiang
> >
> > When an eTSEC is configured to use TBI, configuration of the TBI is
> > done through the MIIM registers for that eTSEC.
> > For example, if a TBI interface is required on eTSEC2, then the MIIM
> > registers starting at offset 0x2_5520 are used to configure it.
> >
> > Fixes: 9a1d6af55ecd ("net: tsec: Add driver model ethernet support")
> > Signed-off-by: Hou Zhiqiang
> > Reviewed-by: Vladimir Oltean
> > Tested-by: Vladimir Oltean
> > ---
>
> Looks good, thanks!
> Out of curiosity, are you also working on DM_MDIO for the tsec driver?
> Some of this code should go away when we do that conversion.
No, I'm not, I saw your patches for the DM_MDIO support.
Thanks,
Zhiqiang
>
> > V2:
> > - Added error message for getting the internal TBI PHY MII reg.
> > - Only try to get TBI PHY MII reg under the condition "tbi-handle".
> >
> > drivers/net/tsec.c | 25 +
> > 1 file changed, 21 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/net/tsec.c b/drivers/net/tsec.c index
> > 541f964d2e..842cddf229 100644
> > --- a/drivers/net/tsec.c
> > +++ b/drivers/net/tsec.c
> > @@ -789,6 +789,7 @@ int tsec_probe(struct udevice *dev) {
> > struct eth_pdata *pdata = dev_get_platdata(dev);
> > struct tsec_private *priv = dev_get_priv(dev);
> > + struct tsec_mii_mng __iomem *ext_phyregs_mii;
> > struct ofnode_phandle_args phandle_args;
> > u32 tbiaddr = CONFIG_SYS_TBIPA_VALUE;
> > struct fsl_pq_mdio_info mdio_info; @@ -822,14 +823,30 @@ int
> > tsec_probe(struct udevice *dev)
> > return -ENOENT;
> > }
> >
> > - priv->phyregs_sgmii = map_physmem(reg +
> TSEC_MDIO_REGS_OFFSET, 0,
> > - MAP_NOCACHE);
> > + ext_phyregs_mii = map_physmem(reg +
> TSEC_MDIO_REGS_OFFSET, 0,
> > + MAP_NOCACHE);
> >
> > ret = dev_read_phandle_with_args(dev, "tbi-handle", NULL, 0, 0,
> > _args);
> > - if (ret == 0)
> > + if (ret == 0) {
> > ofnode_read_u32(phandle_args.node, "reg", );
> >
> > + parent = ofnode_get_parent(phandle_args.node);
> > + if (!ofnode_valid(parent)) {
> > + printf("No parent node for TBI PHY?\n");
> > + return -ENOENT;
> > + }
> > +
> > + reg = ofnode_get_addr_index(parent, 0);
> > + if (reg == FDT_ADDR_T_NONE) {
> > + printf("No 'reg' property of MII for TBI
> PHY\n");
> > + return -ENOENT;
> > + }
> > +
> > + priv->phyregs_sgmii = map_physmem(reg +
> TSEC_MDIO_REGS_OFFSET,
> > + 0,
> MAP_NOCACHE);
> > + }
> > +
> > priv->tbiaddr = tbiaddr;
> >
> > phy_mode = dev_read_prop(dev, "phy-connection-type", NULL);
> @@
> > -846,7 +863,7 @@ int tsec_probe(struct udevice *dev)
> > if (priv->interface == PHY_INTERFACE_MODE_SGMII)
> > priv->flags |= TSEC_SGMII;
> >
> > - mdio_info.regs = priv->phyregs_sgmii;
> > + mdio_info.regs = ext_phyregs_mii;
> > mdio_info.name = (char *)dev->name;
> > ret = fsl_pq_mdio_init(NULL, _info);
> > if (ret)
> > --
> > 2.17.1
> >
>
> Regards,
> -Vladimir
RE: [PATCH 3/3] net: tsec: Access TBI PHY through the corresponding MII
Hi Vladimir,
Thanks a lot for your comments!
> -Original Message-
> From: Vladimir Oltean
> Sent: 2020年5月3日 22:07
> To: Z.q. Hou
> Cc: u-boot ; Joe Hershberger
> ; Bin Meng ; Priyanka
> Jain
> Subject: Re: [PATCH 3/3] net: tsec: Access TBI PHY through the
> corresponding MII
>
> Hi Zhiqiang,
>
> On Sun, 3 May 2020 at 16:49, Z.q. Hou wrote:
> >
> > Hi Vladimir,
> >
> > Thanks a lot for your review and test!
> >
> > > -Original Message-----
> > > From: Vladimir Oltean
> > > Sent: 2020年5月3日 19:35
> > > To: Z.q. Hou
> > > Cc: u-boot ; Joe Hershberger
> > > ; Bin Meng ;
> Priyanka
> > > Jain
> > > Subject: Re: [PATCH 3/3] net: tsec: Access TBI PHY through the
> > > corresponding MII
> > >
> > > On Sun, 3 May 2020 at 09:28, Zhiqiang Hou
> > > wrote:
> > > >
> > > > From: Hou Zhiqiang
> > > >
> > > > When an eTSEC is configured to use TBI, configuration of the TBI
> > > > is done through the MIIM registers for that eTSEC.
> > > > For example, if a TBI interface is required on eTSEC2, then the
> > > > MIIM registers starting at offset 0x2_5520 are used to configure it.
> > > >
> > > > Fixes: 9a1d6af55ecd ("net: tsec: Add driver model ethernet
> > > > support")
> > > > Signed-off-by: Hou Zhiqiang
> > > > ---
> > > > drivers/net/tsec.c | 17 ++---
> > > > 1 file changed, 14 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/drivers/net/tsec.c b/drivers/net/tsec.c index
> > > > ce41aec5cf..31056f3117 100644
> > > > --- a/drivers/net/tsec.c
> > > > +++ b/drivers/net/tsec.c
> > > > @@ -789,6 +789,7 @@ int tsec_probe(struct udevice *dev) {
> > > > struct eth_pdata *pdata = dev_get_platdata(dev);
> > > > struct tsec_private *priv = dev_get_priv(dev);
> > > > + struct tsec_mii_mng __iomem *ext_phyregs_mii;
> > > > struct ofnode_phandle_args phandle_args;
> > > > u32 tbiaddr = CONFIG_SYS_TBIPA_VALUE;
> > > > struct fsl_pq_mdio_info mdio_info; @@ -820,8 +821,8 @@
> int
> > > > tsec_probe(struct udevice *dev)
> > > > if (reg == FDT_ADDR_T_NONE)
> > > > return -ENOENT;
> > > >
> > > > - priv->phyregs_sgmii = map_physmem(reg +
> > > TSEC_MDIO_REGS_OFFSET, 0,
> > > > - MAP_NOCACHE);
> > > > + ext_phyregs_mii = map_physmem(reg +
> > > TSEC_MDIO_REGS_OFFSET, 0,
> > > > + MAP_NOCACHE);
> > > >
> > > > ret = dev_read_phandle_with_args(dev, "tbi-handle", NULL,
> > > > 0,
> > > 0,
> > > > _args);
> @@
> > > -830,6
> > > > +831,16 @@ int tsec_probe(struct udevice *dev)
> > > >
> > > > priv->tbiaddr = tbiaddr;
> > > >
> > > > + parent = ofnode_get_parent(phandle_args.node);
> > > > + if (!ofnode_valid(parent)) {
> > > > + printf("No parent node for TBI PHY?\n");
> > > > + return -ENOENT;
> > > > + }
> > > > +
> > > > + reg = ofnode_get_addr_index(parent, 0);
> > >
> > > Missing a check
> > >
> > > if (reg == FDT_ADDR_T_NONE)
> > > return -ENOENT;
> > >
> > > here?
> >
> > Yes, will fix in v2.
> >
> > Thanks,
> > Zhiqiang
>
> Actually since the TBI PHY is optional (not present on RGMII interfaces and
> such), I don't believe you should return an error, but just skip the
> phyregs_sgmii initialization.
Correct, I just realized it.
Thanks,
Zhiqiang
>
> >
> > >
> > > > + priv->phyregs_sgmii = map_physmem(reg +
> > > TSEC_MDIO_REGS_OFFSET, 0,
> > > > + MAP_NOCACHE);
> > > > +
> > > > phy_mode = dev_read_prop(dev, "phy-connection-type",
> NULL);
> > > > if (phy_mode)
> > > > pdata->phy_interface =
> > > > phy_get_interface_by_name(phy_mode);
> > > > @@ -844,7 +855,7 @@ int tsec_probe(struct udevice *dev)
> > > > if (priv->interface == PHY_INTERFACE_MODE_SGMII)
> > > > priv->flags |= TSEC_SGMII;
> > > >
> > > > - mdio_info.regs = priv->phyregs_sgmii;
> > > > + mdio_info.regs = ext_phyregs_mii;
> > > > mdio_info.name = (char *)dev->name;
> > > > ret = fsl_pq_mdio_init(NULL, _info);
> > > > if (ret)
> > > > --
> > > > 2.17.1
> > > >
> > >
> > > With that:
> > >
> > > Reviewed-by: Vladimir Oltean
> > > Tested-by: Vladimir Oltean
> > >
> > > (on LS1021A)
> > >
> > > Thanks!
> > > -Vladimir
>
> Thanks,
> -Vladimir
RE: [PATCH 2/3] net: tsec: Access eTSEC registers using virtual address
Hi Vladimir,
Thanks a lot for your review and test!
Thanks,
Zhiqiang
> -Original Message-
> From: Vladimir Oltean
> Sent: 2020年5月3日 19:36
> To: Z.q. Hou
> Cc: u-boot ; Joe Hershberger
> ; Bin Meng ; Priyanka
> Jain
> Subject: Re: [PATCH 2/3] net: tsec: Access eTSEC registers using virtual
> address
>
> Hi Zhiqiang,
>
> On Sun, 3 May 2020 at 09:28, Zhiqiang Hou
> wrote:
> >
> > From: Hou Zhiqiang
> >
> > The current code accesses eTSEC registers using physical address
> > directly, it's not correct, though no problem on current platforms. It
> > won't work on platforms, which does not support 1:1 virtual-physical
> > address map.
> >
> > Signed-off-by: Hou Zhiqiang
> > ---
>
> Reviewed-by: Vladimir Oltean
> Tested-by: Vladimir Oltean
>
> (on LS1021A)
>
> > drivers/net/tsec.c | 9 ++---
> > 1 file changed, 6 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/net/tsec.c b/drivers/net/tsec.c index
> > f85cdcb97e..ce41aec5cf 100644
> > --- a/drivers/net/tsec.c
> > +++ b/drivers/net/tsec.c
> > @@ -798,7 +798,7 @@ int tsec_probe(struct udevice *dev)
> > int ret;
> >
> > pdata->iobase = (phys_addr_t)dev_read_addr(dev);
> > - priv->regs = (struct tsec *)pdata->iobase;
> > + priv->regs = dev_remap_addr(dev);
> >
> > if (dev_read_phandle_with_args(dev, "phy-handle", NULL, 0, 0,
> >_args)) { @@
> -817,8
> > +817,11 @@ int tsec_probe(struct udevice *dev)
> > }
> >
> > reg = ofnode_get_addr_index(parent, 0);
> > - priv->phyregs_sgmii = (struct tsec_mii_mng *)
> > - (reg + TSEC_MDIO_REGS_OFFSET);
> > + if (reg == FDT_ADDR_T_NONE)
> > + return -ENOENT;
> > +
> > + priv->phyregs_sgmii = map_physmem(reg +
> TSEC_MDIO_REGS_OFFSET, 0,
> > + MAP_NOCACHE);
> >
> > ret = dev_read_phandle_with_args(dev, "tbi-handle", NULL, 0,
> 0,
> > _args);
> > --
> > 2.17.1
> >
RE: [PATCH 3/3] net: tsec: Access TBI PHY through the corresponding MII
Hi Vladimir,
Thanks a lot for your review and test!
> -Original Message-
> From: Vladimir Oltean
> Sent: 2020年5月3日 19:35
> To: Z.q. Hou
> Cc: u-boot ; Joe Hershberger
> ; Bin Meng ; Priyanka
> Jain
> Subject: Re: [PATCH 3/3] net: tsec: Access TBI PHY through the
> corresponding MII
>
> On Sun, 3 May 2020 at 09:28, Zhiqiang Hou
> wrote:
> >
> > From: Hou Zhiqiang
> >
> > When an eTSEC is configured to use TBI, configuration of the TBI is
> > done through the MIIM registers for that eTSEC.
> > For example, if a TBI interface is required on eTSEC2, then the MIIM
> > registers starting at offset 0x2_5520 are used to configure it.
> >
> > Fixes: 9a1d6af55ecd ("net: tsec: Add driver model ethernet support")
> > Signed-off-by: Hou Zhiqiang
> > ---
> > drivers/net/tsec.c | 17 ++---
> > 1 file changed, 14 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/net/tsec.c b/drivers/net/tsec.c index
> > ce41aec5cf..31056f3117 100644
> > --- a/drivers/net/tsec.c
> > +++ b/drivers/net/tsec.c
> > @@ -789,6 +789,7 @@ int tsec_probe(struct udevice *dev) {
> > struct eth_pdata *pdata = dev_get_platdata(dev);
> > struct tsec_private *priv = dev_get_priv(dev);
> > + struct tsec_mii_mng __iomem *ext_phyregs_mii;
> > struct ofnode_phandle_args phandle_args;
> > u32 tbiaddr = CONFIG_SYS_TBIPA_VALUE;
> > struct fsl_pq_mdio_info mdio_info; @@ -820,8 +821,8 @@ int
> > tsec_probe(struct udevice *dev)
> > if (reg == FDT_ADDR_T_NONE)
> > return -ENOENT;
> >
> > - priv->phyregs_sgmii = map_physmem(reg +
> TSEC_MDIO_REGS_OFFSET, 0,
> > - MAP_NOCACHE);
> > + ext_phyregs_mii = map_physmem(reg +
> TSEC_MDIO_REGS_OFFSET, 0,
> > + MAP_NOCACHE);
> >
> > ret = dev_read_phandle_with_args(dev, "tbi-handle", NULL, 0,
> 0,
> > _args); @@
> -830,6
> > +831,16 @@ int tsec_probe(struct udevice *dev)
> >
> > priv->tbiaddr = tbiaddr;
> >
> > + parent = ofnode_get_parent(phandle_args.node);
> > + if (!ofnode_valid(parent)) {
> > + printf("No parent node for TBI PHY?\n");
> > + return -ENOENT;
> > + }
> > +
> > + reg = ofnode_get_addr_index(parent, 0);
>
> Missing a check
>
> if (reg == FDT_ADDR_T_NONE)
> return -ENOENT;
>
> here?
Yes, will fix in v2.
Thanks,
Zhiqiang
>
> > + priv->phyregs_sgmii = map_physmem(reg +
> TSEC_MDIO_REGS_OFFSET, 0,
> > + MAP_NOCACHE);
> > +
> > phy_mode = dev_read_prop(dev, "phy-connection-type", NULL);
> > if (phy_mode)
> > pdata->phy_interface =
> > phy_get_interface_by_name(phy_mode);
> > @@ -844,7 +855,7 @@ int tsec_probe(struct udevice *dev)
> > if (priv->interface == PHY_INTERFACE_MODE_SGMII)
> > priv->flags |= TSEC_SGMII;
> >
> > - mdio_info.regs = priv->phyregs_sgmii;
> > + mdio_info.regs = ext_phyregs_mii;
> > mdio_info.name = (char *)dev->name;
> > ret = fsl_pq_mdio_init(NULL, _info);
> > if (ret)
> > --
> > 2.17.1
> >
>
> With that:
>
> Reviewed-by: Vladimir Oltean
> Tested-by: Vladimir Oltean
>
> (on LS1021A)
>
> Thanks!
> -Vladimir
RE: [PATCH 1/3] doc: dt-bindings: tsec: Correct the Ethernet port compatible string
Hi Vladimir,
Thanks a lot for your ack!
> -Original Message-
> From: Vladimir Oltean
> Sent: 2020年5月3日 19:13
> To: Z.q. Hou
> Cc: u-boot ; Joe Hershberger
> ; Bin Meng ; Priyanka
> Jain ; mario@gdsys.cc
> Subject: Re: [PATCH 1/3] doc: dt-bindings: tsec: Correct the Ethernet port
> compatible string
>
> On Sun, 3 May 2020 at 09:28, Zhiqiang Hou
> wrote:
> >
> > From: Hou Zhiqiang
> >
> > Change the compatible string to "fsl,etsec2" for the Ethernet ports,
> > which is used in the current driver's match table.
> >
> > Fixes: 69a00875e3db ("doc: dt-bindings: Describe Freescale TSEC
> > ethernet controller")
> > Signed-off-by: Hou Zhiqiang
> > ---
>
> Acked-by: Vladimir Oltean
>
> Although I am unclear how the G MPC8308 boards
> (arch/powerpc/dts/gdsys/mpc8308.dtsi) have ever probed their TSEC
> interfaces. Probably not based on DM, since the fsl,tsec compatible string
> has never been supported by the mainline tsec driver.
I agree with you, they seems using legacy driver. I'm working on the support
of compatible "gianfar", the MPC8308 boards can shift to the DM driver then.
Thanks,
Zhiqiang
>
> > doc/device-tree-bindings/net/fsl-tsec-phy.txt | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/doc/device-tree-bindings/net/fsl-tsec-phy.txt
> > b/doc/device-tree-bindings/net/fsl-tsec-phy.txt
> > index 59989e3b09..8e8574bc97 100644
> > --- a/doc/device-tree-bindings/net/fsl-tsec-phy.txt
> > +++ b/doc/device-tree-bindings/net/fsl-tsec-phy.txt
> > @@ -2,7 +2,7 @@
> >
> > Properties:
> >
> > - - compatible : Should be "fsl,tsec"
> > + - compatible : Should be "fsl,etsec2"
> >- reg : Offset and length of the register set for the device
> >- phy-handle : See ethernet.txt file in the same directory.
> >- phy-connection-type : See ethernet.txt file in the same
> > directory. This @@ -12,7 +12,7 @@ Properties:
> >
> > Example:
> > ethernet@24000 {
> > - compatible = "fsl,tsec";
> > + compatible = "fsl,etsec2";
> > reg = <0x24000 0x1000>;
> > phy-handle = <>;
> > phy-connection-type = "sgmii";
> > --
> > 2.17.1
> >
RE: [PATCH 9/9] pci_ep: layerscape: Add the PCIe EP mode support for lx2160a-v2
> -Original Message-
> From: Xiaowei Bao
> Sent: 2020年3月22日 19:13
> To: M.h. Lian ; Z.q. Hou
> ; Mingkai Hu ;
> bmeng...@gmail.com; yamada.masah...@socionext.com;
> u-boot@lists.denx.de
> Cc: Xiaowei Bao
> Subject: [PATCH 9/9] pci_ep: layerscape: Add the PCIe EP mode support for
> lx2160a-v2
>
> Add the PCIe EP mode support for lx2160a-v2 platform.
>
> Signed-off-by: Xiaowei Bao
> ---
> drivers/pci/pcie_layerscape.h| 9 -
> drivers/pci/pcie_layerscape_ep.c | 8 +++-
> 2 files changed, 15 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/pci/pcie_layerscape.h b/drivers/pci/pcie_layerscape.h
> index 5f5c51d..593798e 100644
> --- a/drivers/pci/pcie_layerscape.h
> +++ b/drivers/pci/pcie_layerscape.h
> @@ -100,7 +100,7 @@
>
> #define PCIE_SRIOV_VFBAR00x19C
>
> -#define PCIE_MASK_OFFSET(flag, pf) ((flag) ? 0 : (0x1000 + 0x2 * (pf)))
> +#define PCIE_MASK_OFFSET(flag, pf, off) ((flag) ? 0 : (0x1000 + (off) *
> +(pf)))
>
> /* LUT registers */
> #define PCIE_LUT_UDR(n) (0x800 + (n) * 8)
> @@ -139,6 +139,12 @@
> #define LS1021_PEXMSCPORTSR(pex_idx) (0x94 + (pex_idx) * 4)
> #define LS1021_LTSSM_STATE_SHIFT 20
>
> +/* LX2160a PF1 offset */
> +#define LX2160_PCIE_PF1_OFFSET 0x8000
> +
> +/* layerscape PF1 offset */
> +#define LS_PCIE_PF1_OFFSET 0x2
> +
> struct ls_pcie {
> void __iomem *dbi;
> void __iomem *lut;
> @@ -170,6 +176,7 @@ struct ls_pcie_ep {
> void __iomem *addr;
> u32 cfg2_flag;
> u32 sriov_flag;
> + u32 pf1_offset;
> u32 num_ib_wins;
> u32 num_ob_wins;
> u8 max_functions;
> diff --git a/drivers/pci/pcie_layerscape_ep.c
> b/drivers/pci/pcie_layerscape_ep.c
> index ebf69ee..0228863 100644
> --- a/drivers/pci/pcie_layerscape_ep.c
> +++ b/drivers/pci/pcie_layerscape_ep.c
> @@ -197,7 +197,8 @@ static void ls_pcie_setup_ep(struct ls_pcie_ep
> *pcie_ep)
> writel(0, pcie->dbi + PCIE_MISC_CONTROL_1_OFF);
>
> bar_base = pcie->dbi +
> -PCIE_MASK_OFFSET(pcie_ep->cfg2_flag, pf);
> +PCIE_MASK_OFFSET(pcie_ep->cfg2_flag, pf,
> + pcie_ep->pf1_offset);
>
> if (pcie_ep->cfg2_flag) {
> ctrl_writel(pcie,
> @@ -270,6 +271,11 @@ static int ls_pcie_ep_probe(struct udevice *dev)
>
> svr = SVR_SOC_VER(get_svr());
>
> + if (svr == SVR_LX2160A)
> + pcie_ep->pf1_offset = LX2160_PCIE_PF1_OFFSET;
> + else
> + pcie_ep->pf1_offset = LS_PCIE_PF1_OFFSET;
> +
> if (svr == SVR_LS2080A || svr == SVR_LS2085A)
> pcie_ep->cfg2_flag = 1;
> else
> --
> 2.9.5
Reviewed-by: Hou Zhiqiang
RE: [PATCH 7/9] pci_ep: layerscape: Add the SRIOV VFs of PF support
> -Original Message-
> From: Xiaowei Bao
> Sent: 2020年3月22日 19:13
> To: M.h. Lian ; Z.q. Hou
> ; Mingkai Hu ;
> bmeng...@gmail.com; yamada.masah...@socionext.com;
> u-boot@lists.denx.de
> Cc: Xiaowei Bao
> Subject: [PATCH 7/9] pci_ep: layerscape: Add the SRIOV VFs of PF support
>
> Add the INBOUND configuration for VFs of PF.
>
> Signed-off-by: Xiaowei Bao
> ---
> drivers/pci/pcie_layerscape.c| 8 +---
> drivers/pci/pcie_layerscape.h| 13 -
> drivers/pci/pcie_layerscape_ep.c | 34
> +-
> 3 files changed, 42 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/pci/pcie_layerscape.c b/drivers/pci/pcie_layerscape.c
> index 88a0e8a..c7a96ed 100644
> --- a/drivers/pci/pcie_layerscape.c
> +++ b/drivers/pci/pcie_layerscape.c
> @@ -91,7 +91,7 @@ int ls_pcie_link_up(struct ls_pcie *pcie) }
>
> void ls_pcie_atu_outbound_set(struct ls_pcie *pcie, int idx, int type,
> - u64 phys, u64 bus_addr, pci_size_t size)
> + u64 phys, u64 bus_addr, u64 size)
> {
> dbi_writel(pcie, PCIE_ATU_REGION_OUTBOUND | idx,
> PCIE_ATU_VIEWPORT);
> dbi_writel(pcie, (u32)phys, PCIE_ATU_LOWER_BASE); @@ -104,14
> +104,16 @@ void ls_pcie_atu_outbound_set(struct ls_pcie *pcie, int idx, int
> type, }
>
> /* Use bar match mode and MEM type as default */ -void
> ls_pcie_atu_inbound_set(struct ls_pcie *pcie, u32 pf, int type,
> - int idx, int bar, u64 phys)
> +void ls_pcie_atu_inbound_set(struct ls_pcie *pcie, u32 pf, u32 vf_flag,
> + int type, int idx, int bar, u64 phys)
> {
> dbi_writel(pcie, PCIE_ATU_REGION_INBOUND | idx,
> PCIE_ATU_VIEWPORT);
> dbi_writel(pcie, (u32)phys, PCIE_ATU_LOWER_TARGET);
> dbi_writel(pcie, phys >> 32, PCIE_ATU_UPPER_TARGET);
> dbi_writel(pcie, type | PCIE_ATU_FUNC_NUM(pf), PCIE_ATU_CR1);
> dbi_writel(pcie, PCIE_ATU_ENABLE | PCIE_ATU_BAR_MODE_ENABLE |
> +(vf_flag ? PCIE_ATU_FUNC_NUM_MATCH_EN : 0) |
> +(vf_flag ? PCIE_ATU_VFBAR_MATCH_MODE_EN : 0) |
> PCIE_ATU_BAR_NUM(bar), PCIE_ATU_CR2); }
>
> diff --git a/drivers/pci/pcie_layerscape.h b/drivers/pci/pcie_layerscape.h
> index dabfff3..26d0177 100644
> --- a/drivers/pci/pcie_layerscape.h
> +++ b/drivers/pci/pcie_layerscape.h
> @@ -20,7 +20,7 @@
> #endif
>
> #ifndef CONFIG_SYS_PCI_MEMORY_SIZE
> -#define CONFIG_SYS_PCI_MEMORY_SIZE (2 * 1024 * 1024 * 1024UL) /* 2G
> */
> +#define CONFIG_SYS_PCI_MEMORY_SIZE SZ_4G
> #endif
>
> #ifndef CONFIG_SYS_PCI_EP_MEMORY_BASE
> @@ -40,6 +40,7 @@
> #define PCIE_ATU_REGION_INDEX2 (0x2 << 0)
> #define PCIE_ATU_REGION_INDEX3 (0x3 << 0)
> #define PCIE_ATU_REGION_NUM 6
> +#define PCIE_ATU_REGION_NUM_SRIOV24
> #define PCIE_ATU_CR1 0x904
> #define PCIE_ATU_TYPE_MEM(0x0 << 0)
> #define PCIE_ATU_TYPE_IO (0x2 << 0)
> @@ -49,6 +50,8 @@
> #define PCIE_ATU_CR2 0x908
> #define PCIE_ATU_ENABLE (0x1 << 31)
> #define PCIE_ATU_BAR_MODE_ENABLE (0x1 << 30)
> +#define PCIE_ATU_FUNC_NUM_MATCH_EN BIT(19)
> +#define PCIE_ATU_VFBAR_MATCH_MODE_EN BIT(26)
> #define PCIE_ATU_BAR_NUM(bar)((bar) << 8)
> #define PCIE_ATU_LOWER_BASE 0x90C
> #define PCIE_ATU_UPPER_BASE 0x910
> @@ -88,7 +91,7 @@
> #define FSL_PCIE_EP_MIN_APERTURE4096 /* 4 Kbytes */
> #define PCIE_PF_NUM 2
> #define PCIE_VF_NUM 64
> -#define BAR_NUM 4
> +#define BAR_NUM 8
>
> #define PCIE_BAR0_SIZE SZ_4K
> #define PCIE_BAR1_SIZE SZ_8K
> @@ -179,9 +182,9 @@ void dbi_writel(struct ls_pcie *pcie, unsigned int
> value, unsigned int offset); unsigned int ctrl_readl(struct ls_pcie *pcie,
> unsigned int offset); void ctrl_writel(struct ls_pcie *pcie, unsigned int
> value,
> unsigned int offset); void ls_pcie_atu_outbound_set(struct ls_pcie *pcie,
> int idx, int type,
> - u64 phys, u64 bus_addr, pci_size_t size);
> -void ls_pcie_atu_inbound_set(struct ls_pcie *pcie, u32 pf, int type,
> - int idx, int bar, u64 phys);
> + u64 phys, u64 bus_addr, u64 size); void
> +ls_pcie_atu_inbound_set(struct ls_pcie *pcie, u32 pf, u32 vf_flag,
> + int type, int idx, int bar, u64 phys);
> void ls_pcie_dump_atu(struct ls_pcie *pcie); int ls_pcie_link_up(struct
> ls_pcie *pcie); void ls_pcie_dbi_ro_wr_en(struct
RE: [PATCH 8/9] pci: layerscaple: Modify the ls_pcie_dump_atu function
> -Original Message-
> From: Xiaowei Bao
> Sent: 2020年3月22日 19:13
> To: M.h. Lian ; Z.q. Hou
> ; Mingkai Hu ;
> bmeng...@gmail.com; yamada.masah...@socionext.com;
> u-boot@lists.denx.de
> Cc: Xiaowei Bao
> Subject: [PATCH 8/9] pci: layerscaple: Modify the ls_pcie_dump_atu function
>
> Modify the ls_pcie_dump_atu function, make it can print the INBOUND
> windows registers.
>
> Signed-off-by: Xiaowei Bao
> ---
> drivers/pci/pcie_layerscape.c| 25 +
> drivers/pci/pcie_layerscape.h| 2 +-
> drivers/pci/pcie_layerscape_ep.c | 3 +++
> drivers/pci/pcie_layerscape_rc.c | 2 +-
> 4 files changed, 18 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/pci/pcie_layerscape.c b/drivers/pci/pcie_layerscape.c
> index c7a96ed..4015a0d 100644
> --- a/drivers/pci/pcie_layerscape.c
> +++ b/drivers/pci/pcie_layerscape.c
> @@ -117,24 +117,25 @@ void ls_pcie_atu_inbound_set(struct ls_pcie *pcie,
> u32 pf, u32 vf_flag,
> PCIE_ATU_BAR_NUM(bar), PCIE_ATU_CR2); }
>
> -void ls_pcie_dump_atu(struct ls_pcie *pcie)
> +void ls_pcie_dump_atu(struct ls_pcie *pcie, u32 win_num, u32 type)
> {
> - int i;
> + int win_idx;
>
> - for (i = 0; i < PCIE_ATU_REGION_NUM; i++) {
> - dbi_writel(pcie, PCIE_ATU_REGION_OUTBOUND | i,
> -PCIE_ATU_VIEWPORT);
> - debug("iATU%d:\n", i);
> + for (win_idx = 0; win_idx < win_num; win_idx++) {
> + dbi_writel(pcie, type | win_idx, PCIE_ATU_VIEWPORT);
> + debug("iATU%d:\n", win_idx);
> debug("\tLOWER PHYS 0x%08x\n",
> dbi_readl(pcie, PCIE_ATU_LOWER_BASE));
> debug("\tUPPER PHYS 0x%08x\n",
> dbi_readl(pcie, PCIE_ATU_UPPER_BASE));
> - debug("\tLOWER BUS 0x%08x\n",
> - dbi_readl(pcie, PCIE_ATU_LOWER_TARGET));
> - debug("\tUPPER BUS 0x%08x\n",
> - dbi_readl(pcie, PCIE_ATU_UPPER_TARGET));
> - debug("\tLIMIT 0x%08x\n",
> - dbi_readl(pcie, PCIE_ATU_LIMIT));
> + if (type == PCIE_ATU_REGION_OUTBOUND) {
> + debug("\tLOWER BUS 0x%08x\n",
> + dbi_readl(pcie, PCIE_ATU_LOWER_TARGET));
> + debug("\tUPPER BUS 0x%08x\n",
> + dbi_readl(pcie, PCIE_ATU_UPPER_TARGET));
> + debug("\tLIMIT 0x%08x\n",
> + dbi_readl(pcie, PCIE_ATU_LIMIT));
> + }
> debug("\tCR10x%08x\n",
> dbi_readl(pcie, PCIE_ATU_CR1));
> debug("\tCR20x%08x\n",
> diff --git a/drivers/pci/pcie_layerscape.h b/drivers/pci/pcie_layerscape.h
> index 26d0177..5f5c51d 100644
> --- a/drivers/pci/pcie_layerscape.h
> +++ b/drivers/pci/pcie_layerscape.h
> @@ -185,7 +185,7 @@ void ls_pcie_atu_outbound_set(struct ls_pcie *pcie,
> int idx, int type,
> u64 phys, u64 bus_addr, u64 size); void
> ls_pcie_atu_inbound_set(struct ls_pcie *pcie, u32 pf, u32 vf_flag,
>int type, int idx, int bar, u64 phys); -void
> ls_pcie_dump_atu(struct ls_pcie *pcie);
> +void ls_pcie_dump_atu(struct ls_pcie *pcie, u32 win_num, u32 type);
> int ls_pcie_link_up(struct ls_pcie *pcie); void ls_pcie_dbi_ro_wr_en(struct
> ls_pcie *pcie); void ls_pcie_dbi_ro_wr_dis(struct ls_pcie *pcie); diff --git
> a/drivers/pci/pcie_layerscape_ep.c b/drivers/pci/pcie_layerscape_ep.c
> index 67ce36c..ebf69ee 100644
> --- a/drivers/pci/pcie_layerscape_ep.c
> +++ b/drivers/pci/pcie_layerscape_ep.c
> @@ -226,6 +226,9 @@ static void ls_pcie_setup_ep(struct ls_pcie_ep
> *pcie_ep)
> ls_pcie_ep_setup_atu(pcie_ep, 0);
> }
>
> + ls_pcie_dump_atu(pcie, PCIE_ATU_REGION_NUM_SRIOV,
> + PCIE_ATU_REGION_INBOUND);
> +
> ls_pcie_ep_enable_cfg(pcie_ep);
> }
>
> diff --git a/drivers/pci/pcie_layerscape_rc.c
> b/drivers/pci/pcie_layerscape_rc.c
> index 927722d..b045159 100644
> --- a/drivers/pci/pcie_layerscape_rc.c
> +++ b/drivers/pci/pcie_layerscape_rc.c
> @@ -114,7 +114,7 @@ static void ls_pcie_setup_atu(struct ls_pcie_rc
> *pcie_rc)
>pref->bus_start,
>pref->size);
>
> - ls_pcie_dump_atu(pcie);
> + ls_pcie_dump_atu(pcie, PCIE_ATU_REGION_NUM,
> PCIE_ATU_REGION_OUTBOUND);
> }
>
> /* Return 0 if the address is valid, -errno if not valid */
> --
> 2.9.5
Reviewed-by: Hou Zhiqiang
RE: [PATCH 6/9] pci_ep: layerscape: Add Support for ls2085a and ls2080a EP mode
> -Original Message-
> From: Xiaowei Bao
> Sent: 2020年3月22日 19:13
> To: M.h. Lian ; Z.q. Hou
> ; Mingkai Hu ;
> bmeng...@gmail.com; yamada.masah...@socionext.com;
> u-boot@lists.denx.de
> Cc: Xiaowei Bao
> Subject: [PATCH 6/9] pci_ep: layerscape: Add Support for ls2085a and
> ls2080a EP mode
>
> Due to the ls2085a and ls2080a use difference way to set the BAR size, so
> add the BAR size init code here.
>
> Signed-off-by: Xiaowei Bao
> ---
> drivers/pci/pcie_layerscape_ep.c | 18 +-
> 1 file changed, 13 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/pci/pcie_layerscape_ep.c
> b/drivers/pci/pcie_layerscape_ep.c
> index a2b18ad..cd7ea26 100644
> --- a/drivers/pci/pcie_layerscape_ep.c
> +++ b/drivers/pci/pcie_layerscape_ep.c
> @@ -172,17 +172,25 @@ static void ls_pcie_setup_ep(struct ls_pcie_ep
> *pcie_ep)
>*/
> writel(0, pcie->dbi + PCIE_MISC_CONTROL_1_OFF);
>
> + bar_base = pcie->dbi +
> +PCIE_MASK_OFFSET(pcie_ep->cfg2_flag, pf);
> +
> if (pcie_ep->cfg2_flag) {
> - for (vf = 0; vf <= PCIE_VF_NUM; vf++) {
> + ctrl_writel(pcie,
> + PCIE_LCTRL0_VAL(pf, 0),
> + PCIE_PF_VF_CTRL);
> + ls_pcie_ep_setup_bars(bar_base);
> +
> + for (vf = 1; vf <= PCIE_VF_NUM; vf++) {
> ctrl_writel(pcie,
> PCIE_LCTRL0_VAL(pf, vf),
> PCIE_PF_VF_CTRL);
> + ls_pcie_ep_setup_vf_bars(bar_base);
> }
> + } else {
> + ls_pcie_ep_setup_bars(bar_base);
> + ls_pcie_ep_setup_vf_bars(bar_base);
> }
> - bar_base = pcie->dbi +
> -PCIE_MASK_OFFSET(pcie_ep->cfg2_flag, pf);
> - ls_pcie_ep_setup_bars(bar_base);
> - ls_pcie_ep_setup_vf_bars(bar_base);
>
> ls_pcie_ep_setup_atu(pcie_ep, pf);
> }
> --
> 2.9.5
Reviewed-by: Hou Zhiqiang
RE: [PATCH 5/9] pci_ep: layerscape: Add the workaround for errata A-009460
> -Original Message-
> From: Xiaowei Bao
> Sent: 2020年3月22日 19:13
> To: M.h. Lian ; Z.q. Hou
> ; Mingkai Hu ;
> bmeng...@gmail.com; yamada.masah...@socionext.com;
> u-boot@lists.denx.de
> Cc: Xiaowei Bao
> Subject: [PATCH 5/9] pci_ep: layerscape: Add the workaround for errata
> A-009460
>
> The VF_BARn_REG register's Prefetchable and Type bit fields are overwritten
> by a write to VF's BAR Mask register.
> workaround: Before writing to the VF_BARn_MASK_REG register, write 0b to
> the PCIE_MISC_CONTROL_1_OFF register.
>
> Signed-off-by: Xiaowei Bao
> ---
> drivers/pci/pcie_layerscape_ep.c | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/pci/pcie_layerscape_ep.c
> b/drivers/pci/pcie_layerscape_ep.c
> index bec374b..a2b18ad 100644
> --- a/drivers/pci/pcie_layerscape_ep.c
> +++ b/drivers/pci/pcie_layerscape_ep.c
> @@ -163,6 +163,15 @@ static void ls_pcie_setup_ep(struct ls_pcie_ep
> *pcie_ep)
> if (PCI_EXT_CAP_ID(sriov) == PCI_EXT_CAP_ID_SRIOV) {
> pcie_ep->sriov_flag = 1;
> for (pf = 0; pf < PCIE_PF_NUM; pf++) {
> + /*
> + * The VF_BARn_REG register's Prefetchable and Type bit
> + * fields are overwritten by a write to VF's BAR Mask
> + * register. Before writing to the VF_BARn_MASK_REG
> + * register, write 0b to the PCIE_MISC_CONTROL_1_OFF
> + * register.
> + */
> + writel(0, pcie->dbi + PCIE_MISC_CONTROL_1_OFF);
> +
> if (pcie_ep->cfg2_flag) {
> for (vf = 0; vf <= PCIE_VF_NUM; vf++) {
> ctrl_writel(pcie,
> --
> 2.9.5
Reviewed-by: Hou Zhiqiang
RE: [PATCH 3/9] armv8: dts: ls1046a: Add the PCIe EP node
> -Original Message-
> From: Xiaowei Bao
> Sent: 2020年3月22日 19:13
> To: M.h. Lian ; Z.q. Hou
> ; Mingkai Hu ;
> bmeng...@gmail.com; yamada.masah...@socionext.com;
> u-boot@lists.denx.de
> Cc: Xiaowei Bao
> Subject: [PATCH 3/9] armv8: dts: ls1046a: Add the PCIe EP node
>
> Add the PCIe EP node for ls1046a.
>
> Signed-off-by: Xiaowei Bao
> ---
> arch/arm/dts/fsl-ls1046a.dtsi | 33 +
> 1 file changed, 33 insertions(+)
>
> diff --git a/arch/arm/dts/fsl-ls1046a.dtsi b/arch/arm/dts/fsl-ls1046a.dtsi
> index fdf93fd..e4b4a8e 100644
> --- a/arch/arm/dts/fsl-ls1046a.dtsi
> +++ b/arch/arm/dts/fsl-ls1046a.dtsi
> @@ -259,6 +259,17 @@
> 0x8200 0x0 0x4000 0x40 0x4000 0x0
> 0x4000>; /* non-prefetchable memory */
> };
>
> + pcie_ep@340 {
> + compatible = "fsl,ls-pcie-ep";
> + reg = <0x00 0x0340 0x0 0x8
> +0x00 0x034c 0x0 0x4
> +0x40 0x 0x8 0x>;
> + reg-names = "regs", "ctrl", "addr_space";
> + num-ib-windows = <6>;
> + num-ob-windows = <8>;
> + big-endian;
> + };
> +
> pcie@350 {
> compatible = "fsl,ls-pcie", "snps,dw-pcie";
> reg = <0x00 0x0350 0x0 0x8 /* dbi registers */
> @@ -276,6 +287,17 @@
> 0x8200 0x0 0x4000 0x48 0x4000 0x0
> 0x4000>; /* non-prefetchable memory */
> };
>
> + pcie_ep@350 {
> + compatible = "fsl,ls-pcie-ep";
> + reg = <0x00 0x0350 0x0 0x8
> +0x00 0x035c 0x0 0x4
> +0x48 0x 0x8 0x>;
> + reg-names = "regs", "ctrl", "addr_space";
> + num-ib-windows = <6>;
> + num-ob-windows = <8>;
> + big-endian;
> + };
> +
> pcie@360 {
> compatible = "fsl,ls-pcie", "snps,dw-pcie";
> reg = <0x00 0x0360 0x0 0x8 /* dbi registers */
> @@ -292,6 +314,17 @@
> 0x8200 0x0 0x4000 0x50 0x4000 0x0
> 0x4000>; /* non-prefetchable memory */
> };
>
> + pcie_ep@360 {
> + compatible = "fsl,ls-pcie-ep";
> + reg = <0x00 0x0360 0x0 0x8
> +0x00 0x036c 0x0 0x4
> +0x50 0x 0x8 0x>;
> + reg-names = "regs", "ctrl", "addr_space";
> + num-ib-windows = <6>;
> + num-ob-windows = <8>;
> + big-endian;
> + };
> +
> sata: sata@320 {
> compatible = "fsl,ls1046a-ahci";
> reg = <0x0 0x320 0x0 0x1 /* ccsr sata base */
> --
> 2.9.5
Reviewed-by: Hou Zhiqiang
RE: [PATCH 4/9] PCI_EP: layerscape: Add the multiple function supprot
> -Original Message-
> From: Xiaowei Bao
> Sent: 2020年3月22日 19:13
> To: M.h. Lian ; Z.q. Hou
> ; Mingkai Hu ;
> bmeng...@gmail.com; yamada.masah...@socionext.com;
> u-boot@lists.denx.de
> Cc: Xiaowei Bao
> Subject: [PATCH 4/9] PCI_EP: layerscape: Add the multiple function supprot
>
> Add the multiple function support for Layerscape platform, some PEXs of
> Layerscaple platform have more than one PF.
>
> Signed-off-by: Xiaowei Bao
> ---
> drivers/pci/pcie_layerscape.c| 6 +-
> drivers/pci/pcie_layerscape.h| 21 +--
> drivers/pci/pcie_layerscape_ep.c | 119
> ++-
> 3 files changed, 98 insertions(+), 48 deletions(-)
>
> diff --git a/drivers/pci/pcie_layerscape.c b/drivers/pci/pcie_layerscape.c
> index 3ca75c5..88a0e8a 100644
> --- a/drivers/pci/pcie_layerscape.c
> +++ b/drivers/pci/pcie_layerscape.c
> @@ -104,13 +104,13 @@ void ls_pcie_atu_outbound_set(struct ls_pcie
> *pcie, int idx, int type, }
>
> /* Use bar match mode and MEM type as default */ -void
> ls_pcie_atu_inbound_set(struct ls_pcie *pcie, int idx, int type,
> - int bar, u64 phys)
> +void ls_pcie_atu_inbound_set(struct ls_pcie *pcie, u32 pf, int type,
> + int idx, int bar, u64 phys)
> {
> dbi_writel(pcie, PCIE_ATU_REGION_INBOUND | idx,
> PCIE_ATU_VIEWPORT);
> dbi_writel(pcie, (u32)phys, PCIE_ATU_LOWER_TARGET);
> dbi_writel(pcie, phys >> 32, PCIE_ATU_UPPER_TARGET);
> - dbi_writel(pcie, type, PCIE_ATU_CR1);
> + dbi_writel(pcie, type | PCIE_ATU_FUNC_NUM(pf), PCIE_ATU_CR1);
> dbi_writel(pcie, PCIE_ATU_ENABLE | PCIE_ATU_BAR_MODE_ENABLE |
> PCIE_ATU_BAR_NUM(bar), PCIE_ATU_CR2); } diff --git
> a/drivers/pci/pcie_layerscape.h b/drivers/pci/pcie_layerscape.h index
> 217dcda..dabfff3 100644
> --- a/drivers/pci/pcie_layerscape.h
> +++ b/drivers/pci/pcie_layerscape.h
> @@ -9,6 +9,7 @@
> #define _PCIE_LAYERSCAPE_H_
> #include
> #include
> +#include
>
> #ifndef CONFIG_SYS_PCI_MEMORY_BUS
> #define CONFIG_SYS_PCI_MEMORY_BUS CONFIG_SYS_SDRAM_BASE @@
> -44,6 +45,7 @@
> #define PCIE_ATU_TYPE_IO (0x2 << 0)
> #define PCIE_ATU_TYPE_CFG0 (0x4 << 0)
> #define PCIE_ATU_TYPE_CFG1 (0x5 << 0)
> +#define PCIE_ATU_FUNC_NUM(pf)((pf) << 20)
> #define PCIE_ATU_CR2 0x908
> #define PCIE_ATU_ENABLE (0x1 << 31)
> #define PCIE_ATU_BAR_MODE_ENABLE (0x1 << 30)
> @@ -86,11 +88,16 @@
> #define FSL_PCIE_EP_MIN_APERTURE4096 /* 4 Kbytes */
> #define PCIE_PF_NUM 2
> #define PCIE_VF_NUM 64
> +#define BAR_NUM 4
>
> -#define PCIE_BAR0_SIZE (4 * 1024) /* 4K */
> -#define PCIE_BAR1_SIZE (8 * 1024) /* 8K for MSIX */
> -#define PCIE_BAR2_SIZE (4 * 1024) /* 4K */
> -#define PCIE_BAR4_SIZE (1 * 1024 * 1024) /* 1M */
> +#define PCIE_BAR0_SIZE SZ_4K
> +#define PCIE_BAR1_SIZE SZ_8K
> +#define PCIE_BAR2_SIZE SZ_4K
> +#define PCIE_BAR4_SIZE SZ_1M
> +
> +#define PCIE_SRIOV_VFBAR00x19C
> +
> +#define PCIE_MASK_OFFSET(flag, pf) ((flag) ? 0 : (0x1000 + 0x2 *
> +(pf)))
>
> /* LUT registers */
> #define PCIE_LUT_UDR(n) (0x800 + (n) * 8)
> @@ -158,6 +165,8 @@ struct ls_pcie_ep {
> struct ls_pcie *pcie;
> struct udevice *bus;
> void __iomem *addr;
> + u32 cfg2_flag;
> + u32 sriov_flag;
> u32 num_ib_wins;
> u32 num_ob_wins;
> u8 max_functions;
> @@ -171,8 +180,8 @@ unsigned int ctrl_readl(struct ls_pcie *pcie, unsigned
> int offset); void ctrl_writel(struct ls_pcie *pcie, unsigned int value,
> unsigned int offset); void ls_pcie_atu_outbound_set(struct ls_pcie *pcie,
> int idx, int type,
> u64 phys, u64 bus_addr, pci_size_t size); -void
> ls_pcie_atu_inbound_set(struct ls_pcie *pcie, int idx, int type,
> - int bar, u64 phys);
> +void ls_pcie_atu_inbound_set(struct ls_pcie *pcie, u32 pf, int type,
> + int idx, int bar, u64 phys);
> void ls_pcie_dump_atu(struct ls_pcie *pcie); int ls_pcie_link_up(struct
> ls_pcie *pcie); void ls_pcie_dbi_ro_wr_en(struct ls_pcie *pcie); diff --git
> a/drivers/pci/pcie_layerscape_ep.c b/drivers/pci/pcie_layerscape_ep.c
> index 8d0c99a..bec374b 100644
> --- a/drivers/pci/pcie_layerscape_ep.c
> +++ b/drivers/pci/pcie_layerscape_ep.c
> @@ -45,7 +45,7 @@ static int ls_ep_set_bar(struct udevice *dev, uint fn,
> struct pci_bar *ep_bar)
>
RE: [PATCH 2/9] pci_ep: Add the init function
> -Original Message-
> From: Xiaowei Bao
> Sent: 2020年3月22日 19:13
> To: M.h. Lian ; Z.q. Hou
> ; Mingkai Hu ;
> bmeng...@gmail.com; yamada.masah...@socionext.com;
> u-boot@lists.denx.de
> Cc: Xiaowei Bao
> Subject: [PATCH 2/9] pci_ep: Add the init function
>
> Some EP deivces need to initialize before RC scan it, e.g. NXP layerscape
> platform, so add the init function in pci_ep uclass.
>
> Signed-off-by: Xiaowei Bao
> ---
> common/board_r.c | 12
> drivers/pci_endpoint/pci_ep-uclass.c | 11 +++
> include/init.h | 1 +
> 3 files changed, 24 insertions(+)
>
> diff --git a/common/board_r.c b/common/board_r.c index
> 0bbeaa7..856b47f 100644
> --- a/common/board_r.c
> +++ b/common/board_r.c
> @@ -229,6 +229,15 @@ static int initr_unlock_ram_in_cache(void) }
> #endif
>
> +#ifdef CONFIG_PCI_ENDPOINT
> +static int initr_pci_ep(void)
> +{
> + pci_ep_init();
> +
> + return 0;
> +}
> +#endif
> +
> #ifdef CONFIG_PCI
> static int initr_pci(void)
> {
> @@ -839,6 +848,9 @@ static init_fnc_t init_sequence_r[] = { #ifdef
> CONFIG_BITBANGMII
> initr_bbmii,
> #endif
> +#ifdef CONFIG_PCI_ENDPOINT
> + initr_pci_ep,
> +#endif
> #ifdef CONFIG_CMD_NET
> INIT_FUNC_WATCHDOG_RESET
> initr_net,
> diff --git a/drivers/pci_endpoint/pci_ep-uclass.c
> b/drivers/pci_endpoint/pci_ep-uclass.c
> index 9f53a9a..38a5f08 100644
> --- a/drivers/pci_endpoint/pci_ep-uclass.c
> +++ b/drivers/pci_endpoint/pci_ep-uclass.c
> @@ -209,3 +209,14 @@ UCLASS_DRIVER(pci_ep) = {
> .name = "pci_ep",
> .flags = DM_UC_FLAG_SEQ_ALIAS,
> };
> +
> +void pci_ep_init(void)
> +{
> + struct udevice *dev;
> +
> + for (uclass_first_device_check(UCLASS_PCI_EP, );
> + dev;
> + uclass_next_device_check()) {
> + ;
> + }
> +}
> diff --git a/include/init.h b/include/init.h index 2a33a3f..fbc26a8 100644
> --- a/include/init.h
> +++ b/include/init.h
> @@ -202,6 +202,7 @@ int set_cpu_clk_info(void); int
> update_flash_size(int flash_size); int arch_early_init_r(void); void
> pci_init(void);
> +void pci_ep_init(void);
> int misc_init_r(void);
> #if defined(CONFIG_VID)
> int init_func_vid(void);
> --
> 2.9.5
Reviewed-by: Hou Zhiqiang
RE: [PATCH 1/9] pci: layerscape: Split the EP and RC driver
> -Original Message-
> From: Xiaowei Bao
> Sent: 2020年3月22日 19:13
> To: M.h. Lian ; Z.q. Hou
> ; Mingkai Hu ;
> bmeng...@gmail.com; yamada.masah...@socionext.com;
> u-boot@lists.denx.de
> Cc: Xiaowei Bao
> Subject: [PATCH 1/9] pci: layerscape: Split the EP and RC driver
>
> Split the RC and EP driver, and reimplement the EP driver base on the EP
> framework.
>
> Signed-off-by: Xiaowei Bao
> ---
> drivers/pci/Makefile| 2 +-
> drivers/pci/pcie_layerscape.c | 492
> +++-
> drivers/pci/pcie_layerscape.h | 44 +++-
> drivers/pci/pcie_layerscape_ep.c| 240 ++
> drivers/pci/pcie_layerscape_fixup.c | 79 +++---
> drivers/pci/pcie_layerscape_rc.c| 378
> +++
> 6 files changed, 734 insertions(+), 501 deletions(-) create mode 100644
> drivers/pci/pcie_layerscape_ep.c create mode 100644
> drivers/pci/pcie_layerscape_rc.c
>
> diff --git a/drivers/pci/Makefile b/drivers/pci/Makefile index
> c051ecc..440b5af 100644
> --- a/drivers/pci/Makefile
> +++ b/drivers/pci/Makefile
> @@ -33,7 +33,7 @@ obj-$(CONFIG_PCI_TEGRA) += pci_tegra.o
> obj-$(CONFIG_PCI_AARDVARK) += pci-aardvark.o
> obj-$(CONFIG_PCIE_DW_MVEBU) += pcie_dw_mvebu.o
> obj-$(CONFIG_PCIE_FSL) += pcie_fsl.o pcie_fsl_fixup.o
> -obj-$(CONFIG_PCIE_LAYERSCAPE) += pcie_layerscape.o
> +obj-$(CONFIG_PCIE_LAYERSCAPE) += pcie_layerscape.o
> pcie_layerscape_rc.o
> +pcie_layerscape_ep.o
> obj-$(CONFIG_PCIE_LAYERSCAPE) += pcie_layerscape_fixup.o
> pcie_layerscape_fixup_common.o
> obj-$(CONFIG_PCIE_LAYERSCAPE_GEN4) += pcie_layerscape_gen4.o \
> pcie_layerscape_gen4_fixup.o \
> diff --git a/drivers/pci/pcie_layerscape.c b/drivers/pci/pcie_layerscape.c
> index 2ab67d1..3ca75c5 100644
> --- a/drivers/pci/pcie_layerscape.c
> +++ b/drivers/pci/pcie_layerscape.c
> @@ -1,39 +1,32 @@
> // SPDX-License-Identifier: GPL-2.0+
> /*
> - * Copyright 2017-2019 NXP
> + * Copyright 2017-2020 NXP
> * Copyright 2014-2015 Freescale Semiconductor, Inc.
> * Layerscape PCIe driver
> */
>
> #include
> -#include
> -#include
> #include
> #include
> #include
> -#include
> -#if defined(CONFIG_FSL_LSCH2) || defined(CONFIG_FSL_LSCH3) || \
> - defined(CONFIG_ARM)
> -#include
> -#endif
> #include "pcie_layerscape.h"
>
> DECLARE_GLOBAL_DATA_PTR;
>
> LIST_HEAD(ls_pcie_list);
>
> -static unsigned int dbi_readl(struct ls_pcie *pcie, unsigned int offset)
> +unsigned int dbi_readl(struct ls_pcie *pcie, unsigned int offset)
> {
> return in_le32(pcie->dbi + offset);
> }
>
> -static void dbi_writel(struct ls_pcie *pcie, unsigned int value,
> -unsigned int offset)
> +void dbi_writel(struct ls_pcie *pcie, unsigned int value,
> + unsigned int offset)
> {
> out_le32(pcie->dbi + offset, value);
> }
>
> -static unsigned int ctrl_readl(struct ls_pcie *pcie, unsigned int offset)
> +unsigned int ctrl_readl(struct ls_pcie *pcie, unsigned int offset)
> {
> if (pcie->big_endian)
> return in_be32(pcie->ctrl + offset);
> @@ -41,8 +34,8 @@ static unsigned int ctrl_readl(struct ls_pcie *pcie,
> unsigned int offset)
> return in_le32(pcie->ctrl + offset);
> }
>
> -static void ctrl_writel(struct ls_pcie *pcie, unsigned int value,
> - unsigned int offset)
> +void ctrl_writel(struct ls_pcie *pcie, unsigned int value,
> + unsigned int offset)
> {
> if (pcie->big_endian)
> out_be32(pcie->ctrl + offset, value); @@ -50,6 +43,26 @@ static
> void ctrl_writel(struct ls_pcie *pcie, unsigned int value,
> out_le32(pcie->ctrl + offset, value); }
>
> +void ls_pcie_dbi_ro_wr_en(struct ls_pcie *pcie) {
> + u32 reg, val;
> +
> + reg = PCIE_MISC_CONTROL_1_OFF;
> + val = dbi_readl(pcie, reg);
> + val |= PCIE_DBI_RO_WR_EN;
> + dbi_writel(pcie, val, reg);
> +}
> +
> +void ls_pcie_dbi_ro_wr_dis(struct ls_pcie *pcie) {
> + u32 reg, val;
> +
> + reg = PCIE_MISC_CONTROL_1_OFF;
> + val = dbi_readl(pcie, reg);
> + val &= ~PCIE_DBI_RO_WR_EN;
> + dbi_writel(pcie, val, reg);
> +}
> +
> static int ls_pcie_ltssm(struct ls_pcie *pcie) {
> u32 state;
> @@ -66,7 +79,7 @@ static int ls_pcie_ltssm(struct ls_pcie *pcie)
> return state;
> }
>
> -static int ls_pcie_link_up(struct ls_pcie *pcie)
> +int ls_pcie_link_up(struct ls_pcie *pcie)
> {
> int ltssm;
>
> @@ -77,22 +90,8 @@ static int ls_pcie_link_up(struct ls_
RE: [PATCHv2 8/9] configs: ls1028a: Enable GIC_V3_ITS config
Hi Wasim, Thanks a lot for your review! Regards, Zhiqiang > -Original Message- > From: Wasim Khan > Sent: 2020年4月21日 16:02 > To: Z.q. Hou ; u-boot@lists.denx.de; Priyanka Jain > ; Biwen Li > Cc: Z.q. Hou > Subject: RE: [PATCHv2 8/9] configs: ls1028a: Enable GIC_V3_ITS config > > > > > -Original Message- > > From: U-Boot On Behalf Of Zhiqiang Hou > > Sent: Tuesday, March 24, 2020 1:42 PM > > To: u-boot@lists.denx.de; Priyanka Jain ; Biwen > > Li > > Cc: Z.q. Hou > > Subject: [PATCHv2 8/9] configs: ls1028a: Enable GIC_V3_ITS config > > > > From: Hou Zhiqiang > > > > Enable GIC_V3_ITS config to initialize the GIC redistributor tables. > > > > Signed-off-by: Hou Zhiqiang > > Reviewed-by: Wasim Khan > > > --- > > V2: > > - No change. > > > > configs/ls1028aqds_tfa_SECURE_BOOT_defconfig | 1 + > > configs/ls1028aqds_tfa_defconfig | 1 + > > configs/ls1028ardb_tfa_SECURE_BOOT_defconfig | 1 + > > configs/ls1028ardb_tfa_defconfig | 1 + > > 4 files changed, 4 insertions(+) > > > > diff --git a/configs/ls1028aqds_tfa_SECURE_BOOT_defconfig > > b/configs/ls1028aqds_tfa_SECURE_BOOT_defconfig > > index c5f0bd85da..92b944f426 100644 > > --- a/configs/ls1028aqds_tfa_SECURE_BOOT_defconfig > > +++ b/configs/ls1028aqds_tfa_SECURE_BOOT_defconfig > > @@ -79,3 +79,4 @@ CONFIG_WDT_SP805=y > > CONFIG_RSA=y > > CONFIG_OF_LIBFDT_OVERLAY=y > > CONFIG_EFI_LOADER_BOUNCE_BUFFER=y > > +CONFIG_GIC_V3_ITS=y > > diff --git a/configs/ls1028aqds_tfa_defconfig > > b/configs/ls1028aqds_tfa_defconfig > > index 7085be77fe..66d3ee1761 100644 > > --- a/configs/ls1028aqds_tfa_defconfig > > +++ b/configs/ls1028aqds_tfa_defconfig > > @@ -84,3 +84,4 @@ CONFIG_WDT=y > > CONFIG_WDT_SP805=y > > CONFIG_OF_LIBFDT_OVERLAY=y > > CONFIG_EFI_LOADER_BOUNCE_BUFFER=y > > +CONFIG_GIC_V3_ITS=y > > diff --git a/configs/ls1028ardb_tfa_SECURE_BOOT_defconfig > > b/configs/ls1028ardb_tfa_SECURE_BOOT_defconfig > > index 6fa14af6af..c999f3e6ef 100644 > > --- a/configs/ls1028ardb_tfa_SECURE_BOOT_defconfig > > +++ b/configs/ls1028ardb_tfa_SECURE_BOOT_defconfig > > @@ -76,3 +76,4 @@ CONFIG_WDT_SP805=y > > CONFIG_RSA=y > > CONFIG_OF_LIBFDT_OVERLAY=y > > CONFIG_EFI_LOADER_BOUNCE_BUFFER=y > > +CONFIG_GIC_V3_ITS=y > > diff --git a/configs/ls1028ardb_tfa_defconfig > > b/configs/ls1028ardb_tfa_defconfig > > index 3ef5520969..150123bc7b 100644 > > --- a/configs/ls1028ardb_tfa_defconfig > > +++ b/configs/ls1028ardb_tfa_defconfig > > @@ -86,3 +86,4 @@ CONFIG_WDT=y > > CONFIG_WDT_SP805=y > > CONFIG_OF_LIBFDT_OVERLAY=y > > CONFIG_EFI_LOADER_BOUNCE_BUFFER=y > > +CONFIG_GIC_V3_ITS=y > > -- > > 2.17.1
RE: [PATCHv2 9/9] configs: ls208xa: Enable GIC_V3_ITS config
Hi Wasim, Thanks a lot for your review! Regards, Zhiqiang > -Original Message- > From: Wasim Khan > Sent: 2020年4月21日 15:41 > To: Z.q. Hou ; u-boot@lists.denx.de; Priyanka Jain > ; Biwen Li > Cc: Z.q. Hou > Subject: RE: [PATCHv2 9/9] configs: ls208xa: Enable GIC_V3_ITS config > > > > > -Original Message- > > From: U-Boot On Behalf Of Zhiqiang Hou > > Sent: Tuesday, March 24, 2020 1:42 PM > > To: u-boot@lists.denx.de; Priyanka Jain ; Biwen > > Li > > Cc: Z.q. Hou > > Subject: [PATCHv2 9/9] configs: ls208xa: Enable GIC_V3_ITS config > > > > From: Hou Zhiqiang > > Reviewed-by: Wasim Khan > > > > > Enable GIC_V3_ITS config to initialize the GIC redistributor tables. > > > > Signed-off-by: Hou Zhiqiang > > --- > > V2: > > - No change. > > > > configs/ls2080aqds_SECURE_BOOT_defconfig | 1 + > > configs/ls2080aqds_defconfig | 1 + > > configs/ls2080aqds_nand_defconfig | 1 + > > configs/ls2080aqds_qspi_defconfig | 1 + > > configs/ls2080aqds_sdcard_defconfig | 1 + > > configs/ls2080ardb_SECURE_BOOT_defconfig | 1 + > > configs/ls2080ardb_defconfig | 1 + > > configs/ls2080ardb_nand_defconfig | 1 + > > configs/ls2081ardb_defconfig | 1 + > > configs/ls2088aqds_tfa_defconfig | 1 + > > configs/ls2088ardb_qspi_SECURE_BOOT_defconfig | 1 + > > configs/ls2088ardb_qspi_defconfig | 1 + > > configs/ls2088ardb_tfa_SECURE_BOOT_defconfig | 1 + > > configs/ls2088ardb_tfa_defconfig | 1 + > > 14 files changed, 14 insertions(+) > > > > diff --git a/configs/ls2080aqds_SECURE_BOOT_defconfig > > b/configs/ls2080aqds_SECURE_BOOT_defconfig > > index 8a792e449a..9039b252c1 100644 > > --- a/configs/ls2080aqds_SECURE_BOOT_defconfig > > +++ b/configs/ls2080aqds_SECURE_BOOT_defconfig > > @@ -62,3 +62,4 @@ CONFIG_USB_XHCI_DWC3=y CONFIG_RSA=y > > CONFIG_RSA_SOFTWARE_EXP=y > CONFIG_EFI_LOADER_BOUNCE_BUFFER=y > > +CONFIG_GIC_V3_ITS=y > > diff --git a/configs/ls2080aqds_defconfig > > b/configs/ls2080aqds_defconfig index > > bc4c218c21..b14b3ca5e7 100644 > > --- a/configs/ls2080aqds_defconfig > > +++ b/configs/ls2080aqds_defconfig > > @@ -63,3 +63,4 @@ CONFIG_DM_USB=y > > CONFIG_USB_XHCI_HCD=y > > CONFIG_USB_XHCI_DWC3=y > > CONFIG_EFI_LOADER_BOUNCE_BUFFER=y > > +CONFIG_GIC_V3_ITS=y > > diff --git a/configs/ls2080aqds_nand_defconfig > > b/configs/ls2080aqds_nand_defconfig > > index e840cbf0ef..fac2b04068 100644 > > --- a/configs/ls2080aqds_nand_defconfig > > +++ b/configs/ls2080aqds_nand_defconfig > > @@ -70,3 +70,4 @@ CONFIG_DM_USB=y > > CONFIG_USB_XHCI_HCD=y > > CONFIG_USB_XHCI_DWC3=y > > CONFIG_EFI_LOADER_BOUNCE_BUFFER=y > > +CONFIG_GIC_V3_ITS=y > > diff --git a/configs/ls2080aqds_qspi_defconfig > > b/configs/ls2080aqds_qspi_defconfig > > index 861e652f7f..343c7675e0 100644 > > --- a/configs/ls2080aqds_qspi_defconfig > > +++ b/configs/ls2080aqds_qspi_defconfig > > @@ -62,3 +62,4 @@ CONFIG_DM_USB=y > > CONFIG_USB_XHCI_HCD=y > > CONFIG_USB_XHCI_DWC3=y > > CONFIG_EFI_LOADER_BOUNCE_BUFFER=y > > +CONFIG_GIC_V3_ITS=y > > diff --git a/configs/ls2080aqds_sdcard_defconfig > > b/configs/ls2080aqds_sdcard_defconfig > > index 864e70d334..dd2862ffe0 100644 > > --- a/configs/ls2080aqds_sdcard_defconfig > > +++ b/configs/ls2080aqds_sdcard_defconfig > > @@ -69,3 +69,4 @@ CONFIG_DM_USB=y > > CONFIG_USB_XHCI_HCD=y > > CONFIG_USB_XHCI_DWC3=y > > CONFIG_EFI_LOADER_BOUNCE_BUFFER=y > > +CONFIG_GIC_V3_ITS=y > > diff --git a/configs/ls2080ardb_SECURE_BOOT_defconfig > > b/configs/ls2080ardb_SECURE_BOOT_defconfig > > index 4abfc64705..743e25f7b7 100644 > > --- a/configs/ls2080ardb_SECURE_BOOT_defconfig > > +++ b/configs/ls2080ardb_SECURE_BOOT_defconfig > > @@ -64,3 +64,4 @@ CONFIG_USB_XHCI_DWC3=y CONFIG_RSA=y > > CONFIG_RSA_SOFTWARE_EXP=y > CONFIG_EFI_LOADER_BOUNCE_BUFFER=y > > +CONFIG_GIC_V3_ITS=y > > diff --git a/configs/ls2080ardb_defconfig > > b/configs/ls2080ardb_defconfig index 0102e14ecb..e9dfc3603e 100644 > > --- a/configs/ls2080ardb_defconfig > > +++ b/configs/ls2080ardb_defconfig > > @@ -65,3 +65,4 @@ CONFIG_DM_USB=y > > CONFIG_USB_XHCI_HCD=y > > CONFIG_USB_XHCI_DWC3=y > > CONFIG_EFI_LOADER_BOUNCE_BUFFER=y > > +CONFIG_GIC_V3_ITS=y > > diff --git a/configs/ls2080ardb_nand_defconfig > > b/configs/ls2080ardb_nand_defconfig >
RE: [PATCHv2 7/9] configs: ls1088a: Enable GIC_V3_ITS config
Hi Wasim, Thanks a lot for your review! Regards, Zhiqiang > -Original Message- > From: Wasim Khan > Sent: 2020年4月21日 15:41 > To: Z.q. Hou ; u-boot@lists.denx.de; Priyanka Jain > ; Biwen Li > Cc: Z.q. Hou > Subject: RE: [PATCHv2 7/9] configs: ls1088a: Enable GIC_V3_ITS config > > > > > -Original Message- > > From: U-Boot On Behalf Of Zhiqiang Hou > > Sent: Tuesday, March 24, 2020 1:42 PM > > To: u-boot@lists.denx.de; Priyanka Jain ; Biwen > > Li > > Cc: Z.q. Hou > > Subject: [PATCHv2 7/9] configs: ls1088a: Enable GIC_V3_ITS config > > > > From: Hou Zhiqiang > > > > Enable GIC_V3_ITS config to initialize the GIC redistributor tables. > > > > Signed-off-by: Hou Zhiqiang > > Reviewed-by: Wasim Khan > > > --- > > V2: > > - No change. > > > > configs/ls1088aqds_defconfig | 1 + > > configs/ls1088aqds_qspi_SECURE_BOOT_defconfig| 1 + > > configs/ls1088aqds_qspi_defconfig| 1 + > > configs/ls1088aqds_sdcard_ifc_defconfig | 1 + > > configs/ls1088aqds_sdcard_qspi_defconfig | 1 + > > configs/ls1088aqds_tfa_defconfig | 1 + > > configs/ls1088ardb_qspi_SECURE_BOOT_defconfig| 1 + > > configs/ls1088ardb_qspi_defconfig| 1 + > > configs/ls1088ardb_sdcard_qspi_SECURE_BOOT_defconfig | 1 + > > configs/ls1088ardb_sdcard_qspi_defconfig | 1 + > > configs/ls1088ardb_tfa_SECURE_BOOT_defconfig | 1 + > > configs/ls1088ardb_tfa_defconfig | 1 + > > 12 files changed, 12 insertions(+) > > > > diff --git a/configs/ls1088aqds_defconfig > > b/configs/ls1088aqds_defconfig index > > 7713e58bbe..b1b74f9af4 100644 > > --- a/configs/ls1088aqds_defconfig > > +++ b/configs/ls1088aqds_defconfig > > @@ -59,3 +59,4 @@ CONFIG_USB_XHCI_DWC3=y > CONFIG_USB_DWC3=y > > CONFIG_USB_STORAGE=y CONFIG_USB_GADGET=y > > +CONFIG_GIC_V3_ITS=y > > diff --git a/configs/ls1088aqds_qspi_SECURE_BOOT_defconfig > > b/configs/ls1088aqds_qspi_SECURE_BOOT_defconfig > > index 242c40b8b5..943b914e01 100644 > > --- a/configs/ls1088aqds_qspi_SECURE_BOOT_defconfig > > +++ b/configs/ls1088aqds_qspi_SECURE_BOOT_defconfig > > @@ -60,3 +60,4 @@ CONFIG_USB_GADGET=y > > CONFIG_RSA=y > > CONFIG_RSA_SOFTWARE_EXP=y > > CONFIG_EFI_LOADER_BOUNCE_BUFFER=y > > +CONFIG_GIC_V3_ITS=y > > diff --git a/configs/ls1088aqds_qspi_defconfig > > b/configs/ls1088aqds_qspi_defconfig > > index 3649b06a75..490782ebfc 100644 > > --- a/configs/ls1088aqds_qspi_defconfig > > +++ b/configs/ls1088aqds_qspi_defconfig > > @@ -61,3 +61,4 @@ CONFIG_USB_XHCI_DWC3=y > CONFIG_USB_DWC3=y > > CONFIG_USB_GADGET=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y > > +CONFIG_GIC_V3_ITS=y > > diff --git a/configs/ls1088aqds_sdcard_ifc_defconfig > > b/configs/ls1088aqds_sdcard_ifc_defconfig > > index 815ea5ce4a..a4c6b27a3d 100644 > > --- a/configs/ls1088aqds_sdcard_ifc_defconfig > > +++ b/configs/ls1088aqds_sdcard_ifc_defconfig > > @@ -67,3 +67,4 @@ CONFIG_USB_XHCI_DWC3=y > CONFIG_USB_DWC3=y > > CONFIG_USB_STORAGE=y CONFIG_USB_GADGET=y > > +CONFIG_GIC_V3_ITS=y > > diff --git a/configs/ls1088aqds_sdcard_qspi_defconfig > > b/configs/ls1088aqds_sdcard_qspi_defconfig > > index 275dbf9e0e..435f704eb3 100644 > > --- a/configs/ls1088aqds_sdcard_qspi_defconfig > > +++ b/configs/ls1088aqds_sdcard_qspi_defconfig > > @@ -70,3 +70,4 @@ CONFIG_USB_XHCI_HCD=y > CONFIG_USB_XHCI_DWC3=y > > CONFIG_USB_DWC3=y CONFIG_USB_GADGET=y > > +CONFIG_GIC_V3_ITS=y > > diff --git a/configs/ls1088aqds_tfa_defconfig > > b/configs/ls1088aqds_tfa_defconfig > > index 1144cba983..5c2a699849 100644 > > --- a/configs/ls1088aqds_tfa_defconfig > > +++ b/configs/ls1088aqds_tfa_defconfig > > @@ -78,3 +78,4 @@ CONFIG_USB_XHCI_DWC3=y > CONFIG_USB_DWC3=y > > CONFIG_USB_GADGET=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y > > +CONFIG_GIC_V3_ITS=y > > diff --git a/configs/ls1088ardb_qspi_SECURE_BOOT_defconfig > > b/configs/ls1088ardb_qspi_SECURE_BOOT_defconfig > > index 3f654e2e1d..89e9a46c4f 100644 > > --- a/configs/ls1088ardb_qspi_SECURE_BOOT_defconfig > > +++ b/configs/ls1088ardb_qspi_SECURE_BOOT_defconfig > > @@ -61,3 +61,4 @@ CONFIG_USB_GADGET=y > > CONFIG_RSA=y > > CONFIG_RSA_SOFTWARE_EXP=y > > CONFIG_EFI_LOADER_BOUNCE_BUFFER=y > > +CONFIG_GIC_V3_ITS=y > > diff --git a/configs/ls1088ardb_qspi_defconfig > > b/configs/ls1088ardb_qspi_defconfig > > index 935d76b4
RE: [PATCHv2 6/9] arm64: layerscape: Move GIC RD tables initialization to CPU setup function
Hi Wasim,
Thanks a lot for your review!
Regards,
Zhiqiang
> -Original Message-
> From: Wasim Khan
> Sent: 2020年4月21日 15:40
> To: Z.q. Hou ; u-boot@lists.denx.de; Priyanka Jain
> ; Biwen Li
> Cc: Z.q. Hou
> Subject: RE: [PATCHv2 6/9] arm64: layerscape: Move GIC RD tables
> initialization to CPU setup function
>
>
>
> > -Original Message-
> > From: U-Boot On Behalf Of Zhiqiang Hou
> > Sent: Tuesday, March 24, 2020 1:42 PM
> > To: u-boot@lists.denx.de; Priyanka Jain ; Biwen
> > Li
> > Cc: Z.q. Hou
> > Subject: [PATCHv2 6/9] arm64: layerscape: Move GIC RD tables
> > initialization to CPU setup function
> >
> > From: Hou Zhiqiang
> >
> > Move GIC redistributor tables initialization to CPU setup function.
> >
> > This patch introduces a GIC redistributor tables init function, and
> > moves the function of reserving memory for GIC redistributor tables to
> > soc.c and adds a argument for the memory size to reserve, BTW rename
> > the function so that it is more readable.
> >
> > Signed-off-by: Hou Zhiqiang
>
> Reviewed-by: Wasim Khan
>
> > ---
> > V2:
> > - New patch.
> >
> > arch/arm/cpu/armv8/fsl-layerscape/fdt.c | 4 ++
> > arch/arm/cpu/armv8/fsl-layerscape/soc.c | 44
> +++
> > .../arm/include/asm/arch-fsl-layerscape/soc.h | 4 ++
> > board/freescale/lx2160a/lx2160a.c | 28
> > 4 files changed, 52 insertions(+), 28 deletions(-)
> >
> > diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> > b/arch/arm/cpu/armv8/fsl- layerscape/fdt.c index
> > 87c3e05f45..36e0a2380e 100644
> > --- a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> > +++ b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> > @@ -462,6 +462,10 @@ void ft_cpu_setup(void *blob, bd_t *bd)
> > do_fixup_by_path_u32(blob, "/sysclk", "clock-frequency",
> > CONFIG_SYS_CLK_FREQ, 1);
> >
> > +#ifdef CONFIG_GIC_V3_ITS
> > + ls_gic_rd_tables_init(blob);
> > +#endif
> > +
> > #if defined(CONFIG_PCIE_LAYERSCAPE) ||
> > defined(CONFIG_PCIE_LAYERSCAPE_GEN4)
> > ft_pci_setup(blob, bd);
> > #endif
> > diff --git a/arch/arm/cpu/armv8/fsl-layerscape/soc.c
> > b/arch/arm/cpu/armv8/fsl-layerscape/soc.c
> > index d0e10cb007..28bb1d7401 100644
> > --- a/arch/arm/cpu/armv8/fsl-layerscape/soc.c
> > +++ b/arch/arm/cpu/armv8/fsl-layerscape/soc.c
> > @@ -6,10 +6,12 @@
> >
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -17,6 +19,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #ifdef CONFIG_LAYERSCAPE_NS_ACCESS
> > #include
> > #endif
> > @@ -30,9 +33,50 @@
> > #include
> > #ifdef CONFIG_TFABOOT
> > #include
> > +#endif
> > +#if defined(CONFIG_TFABOOT) || defined(CONFIG_GIC_V3_ITS)
> > DECLARE_GLOBAL_DATA_PTR;
> > #endif
> >
> > +#ifdef CONFIG_GIC_V3_ITS
> > +#define PENDTABLE_MAX_SZ ALIGN(BIT(ITS_MAX_LPI_NRBITS), SZ_64K)
> > +#define PROPTABLE_MAX_SZ ALIGN(BIT(ITS_MAX_LPI_NRBITS) / 8,
> SZ_64K)
> > +#define GIC_LPI_SIZE ALIGN(cpu_numcores() *
> PENDTABLE_MAX_SZ
> > + \
> > + PROPTABLE_MAX_SZ, SZ_1M)
> > +static int fdt_add_resv_mem_gic_rd_tables(void *blob, u64 base,
> > +size_t
> > +size) {
> > + u32 phandle;
> > + int err;
> > + struct fdt_memory gic_rd_tables;
> > +
> > + gic_rd_tables.start = base;
> > + gic_rd_tables.end = base + size - 1;
> > + err = fdtdec_add_reserved_memory(blob, "gic-rd-tables",
> > _rd_tables,
> > +);
> > + if (err < 0)
> > + debug("%s: failed to add reserved memory: %d\n", __func__,
> > err);
> > +
> > + return err;
> > +}
> > +
> > +int ls_gic_rd_tables_init(void *blob) {
> > + u64 gic_lpi_base;
> > + int ret;
> > +
> > + gic_lpi_base = ALIGN(gd->arch.resv_ram - GIC_LPI_SIZE, SZ_64K);
> > + ret = fdt_add_resv_mem_gic_rd_tables(blob, gic_lpi_base,
> > GIC_LPI_SIZE);
> > + if (ret)
> > + return ret;
> > +
> > + ret = gic_lpi_tables_init(gic_lpi_base, cpu_numcores());
> > + if (ret)
> > + debug("%s: failed to init gic-lpi-tables\n",
RE: [PATCHv2 4/9] board: lx2160a: Make sure the RD tables address align to 64KB
Hi Wasim,
Thanks a lot for your review!
Regards,
Zhiqiang
> -Original Message-
> From: Wasim Khan
> Sent: 2020年4月21日 15:38
> To: Z.q. Hou ; u-boot@lists.denx.de; Priyanka Jain
> ; Biwen Li
> Cc: Z.q. Hou
> Subject: RE: [PATCHv2 4/9] board: lx2160a: Make sure the RD tables address
> align to 64KB
>
>
>
> > -Original Message-
> > From: U-Boot On Behalf Of Zhiqiang Hou
> > Sent: Tuesday, March 24, 2020 1:42 PM
> > To: u-boot@lists.denx.de; Priyanka Jain ; Biwen
> > Li
> > Cc: Z.q. Hou
> > Subject: [PATCHv2 4/9] board: lx2160a: Make sure the RD tables address
> > align to 64KB
> >
> > From: Hou Zhiqiang
> >
> > As the lower 16bit of the redistributor pending table is reserved for
> > describing the memory attributes, we must give a 64KB aligned address
> > to the GIC LPI initialization function.
> >
> > Signed-off-by: Hou Zhiqiang
>
>
> Reviewed-by: Wasim Khan
>
> > ---
> > V2:
> > - The #5 of v1 patchset.
> >
> > board/freescale/lx2160a/lx2160a.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/board/freescale/lx2160a/lx2160a.c
> > b/board/freescale/lx2160a/lx2160a.c
> > index 7f22110dc6..c8e962ce3d 100644
> > --- a/board/freescale/lx2160a/lx2160a.c
> > +++ b/board/freescale/lx2160a/lx2160a.c
> > @@ -17,6 +17,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -678,7 +679,7 @@ int ft_board_setup(void *blob, bd_t *bd)
> > }
> >
> > #ifdef CONFIG_GIC_V3_ITS
> > - gic_lpi_base = gd->arch.resv_ram - GIC_LPI_SIZE;
> > + gic_lpi_base = ALIGN(gd->arch.resv_ram - GIC_LPI_SIZE, SZ_64K);
> > ret = fdt_fixup_gic_lpi_memory(blob, gic_lpi_base);
> > if (!ret && gic_lpi_tables_init(gic_lpi_base, cpu_numcores()))
> > debug("%s: failed to init gic-lpi-tables\n", __func__);
> > --
> > 2.17.1
RE: [PATCHv2 5/9] fsl-layerscape: Kconfig: Select RESV_RAM config if GIC_V3_ITS is enabled
Hi Wasim, Thanks a lot for your review! Regards, Zhiqiang > -Original Message- > From: Wasim Khan > Sent: 2020年4月21日 15:35 > To: Z.q. Hou ; u-boot@lists.denx.de; Priyanka Jain > ; Biwen Li > Cc: Z.q. Hou > Subject: RE: [PATCHv2 5/9] fsl-layerscape: Kconfig: Select RESV_RAM config > if GIC_V3_ITS is enabled > > > > > -Original Message- > > From: U-Boot On Behalf Of Zhiqiang Hou > > Sent: Tuesday, March 24, 2020 1:42 PM > > To: u-boot@lists.denx.de; Priyanka Jain ; Biwen > > Li > > Cc: Z.q. Hou > > Subject: [PATCHv2 5/9] fsl-layerscape: Kconfig: Select RESV_RAM config > > if GIC_V3_ITS is enabled > > > > From: Hou Zhiqiang > > > > The GIC redistributor tables initialization depends on RESV_RAM > > config, so select RESV_RAM if GIC_V3_ITS is enabled. > > > > Signed-off-by: Hou Zhiqiang > Reviewed-by: Wasim Khan > >
RE: [PATCHv2 3/9] board: lx2160a: Don't program the GIC RD tables if failed to reserve memory
Hi Wasim,
Thanks a lot for your comments!
> -Original Message-
> From: Wasim Khan
> Sent: 2020年4月21日 15:29
> To: Z.q. Hou ; u-boot@lists.denx.de; Priyanka Jain
> ; Biwen Li
> Cc: Z.q. Hou
> Subject: RE: [PATCHv2 3/9] board: lx2160a: Don't program the GIC RD tables
> if failed to reserve memory
>
>
>
> > -Original Message-
> > From: U-Boot On Behalf Of Zhiqiang Hou
> > Sent: Tuesday, March 24, 2020 1:42 PM
> > To: u-boot@lists.denx.de; Priyanka Jain ; Biwen
> > Li
> > Cc: Z.q. Hou
> > Subject: [PATCHv2 3/9] board: lx2160a: Don't program the GIC RD tables
> > if failed to reserve memory
> >
> > From: Hou Zhiqiang
> >
> > Program the GIC redistributor tables only when succeeded to reserve
> > memory for them, otherwise kernel will lose the chance to program them
> > using allocated memory.
> >
> > Signed-off-by: Hou Zhiqiang
> > ---
> > V2:
> > - The #4 of v1 patchset.
> >
> > board/freescale/lx2160a/lx2160a.c | 6 --
> > 1 file changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/board/freescale/lx2160a/lx2160a.c
> > b/board/freescale/lx2160a/lx2160a.c
> > index 595c774b42..7f22110dc6 100644
> > --- a/board/freescale/lx2160a/lx2160a.c
> > +++ b/board/freescale/lx2160a/lx2160a.c
> > @@ -657,6 +657,7 @@ int ft_board_setup(void *blob, bd_t *bd)
> > u64 mc_memory_size = 0;
> > u16 total_memory_banks;
> > u64 gic_lpi_base;
> > + int ret;
> >
> > ft_cpu_setup(blob, bd);
> >
> > @@ -678,8 +679,9 @@ int ft_board_setup(void *blob, bd_t *bd)
> >
> > #ifdef CONFIG_GIC_V3_ITS
> > gic_lpi_base = gd->arch.resv_ram - GIC_LPI_SIZE;
> > - gic_lpi_tables_init(gic_lpi_base, cpu_numcores());
> > - fdt_fixup_gic_lpi_memory(blob, gic_lpi_base);
> > + ret = fdt_fixup_gic_lpi_memory(blob, gic_lpi_base);
> > + if (!ret && gic_lpi_tables_init(gic_lpi_base, cpu_numcores()))
> > + debug("%s: failed to init gic-lpi-tables\n", __func__);
>
> Currently till this point, fdt_fixup_gic_lpi_memory return type is void , you
> may first you need to change fdt_fixup_gic_lpi_memory() to return
> something and then you can check for the errors.
> OR, no need for this patch, as in your later patches you are already doing
> error checking .
Good catch, I lost the change of the return type of fdt_fixup_gic_lpi_memory(),
will add in v3.
Thanks,
Zhiqiang
>
> > #endif
> >
> > #ifdef CONFIG_RESV_RAM
> > --
> > 2.17.1
RE: [PATCHv2 4/9] board: lx2160a: Make sure the RD tables address align to 64KB
Hi Wasim,
Thanks a lot for your review!
Regards,
Zhiqiang
> -Original Message-
> From: Wasim Khan
> Sent: 2020年4月21日 15:38
> To: Z.q. Hou ; u-boot@lists.denx.de; Priyanka Jain
> ; Biwen Li
> Cc: Z.q. Hou
> Subject: RE: [PATCHv2 4/9] board: lx2160a: Make sure the RD tables address
> align to 64KB
>
>
>
> > -Original Message-
> > From: U-Boot On Behalf Of Zhiqiang Hou
> > Sent: Tuesday, March 24, 2020 1:42 PM
> > To: u-boot@lists.denx.de; Priyanka Jain ; Biwen
> > Li
> > Cc: Z.q. Hou
> > Subject: [PATCHv2 4/9] board: lx2160a: Make sure the RD tables address
> > align to 64KB
> >
> > From: Hou Zhiqiang
> >
> > As the lower 16bit of the redistributor pending table is reserved for
> > describing the memory attributes, we must give a 64KB aligned address
> > to the GIC LPI initialization function.
> >
> > Signed-off-by: Hou Zhiqiang
>
>
> Reviewed-by: Wasim Khan
>
> > ---
> > V2:
> > - The #5 of v1 patchset.
> >
> > board/freescale/lx2160a/lx2160a.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/board/freescale/lx2160a/lx2160a.c
> > b/board/freescale/lx2160a/lx2160a.c
> > index 7f22110dc6..c8e962ce3d 100644
> > --- a/board/freescale/lx2160a/lx2160a.c
> > +++ b/board/freescale/lx2160a/lx2160a.c
> > @@ -17,6 +17,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -678,7 +679,7 @@ int ft_board_setup(void *blob, bd_t *bd)
> > }
> >
> > #ifdef CONFIG_GIC_V3_ITS
> > - gic_lpi_base = gd->arch.resv_ram - GIC_LPI_SIZE;
> > + gic_lpi_base = ALIGN(gd->arch.resv_ram - GIC_LPI_SIZE, SZ_64K);
> > ret = fdt_fixup_gic_lpi_memory(blob, gic_lpi_base);
> > if (!ret && gic_lpi_tables_init(gic_lpi_base, cpu_numcores()))
> > debug("%s: failed to init gic-lpi-tables\n", __func__);
> > --
> > 2.17.1
RE: [PATCHv2 2/9] arm64: fsl-layerscape: Assign addr to resv_ram if enabled RESV_RAM config
Hi Wasim, Thanks a lot for your comments! > -Original Message- > From: Wasim Khan > Sent: 2020年4月21日 15:27 > To: Z.q. Hou ; u-boot@lists.denx.de; Priyanka Jain > ; Biwen Li > Cc: Z.q. Hou > Subject: RE: [PATCHv2 2/9] arm64: fsl-layerscape: Assign addr to resv_ram if > enabled RESV_RAM config > > > > > -Original Message- > > From: U-Boot On Behalf Of Zhiqiang Hou > > Sent: Tuesday, March 24, 2020 1:42 PM > > To: u-boot@lists.denx.de; Priyanka Jain ; Biwen > > Li > > Cc: Z.q. Hou > > Subject: [PATCHv2 2/9] arm64: fsl-layerscape: Assign addr to resv_ram > > if enabled RESV_RAM config > > > > From: Hou Zhiqiang > > > > The initialization of gd->arch.resv_ram pointer should depend on if > > the RESV_RAM config is enabled. > > > > Signed-off-by: Hou Zhiqiang > > --- > > V2: > > - No change. > > > > arch/arm/cpu/armv8/fsl-layerscape/cpu.c | 8 > > 1 file changed, 4 insertions(+), 4 deletions(-) > > > > diff --git a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c > > b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c > > index b443894453..1b7729c046 100644 > > --- a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c > > +++ b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c > > @@ -1379,7 +1379,7 @@ static int tfa_dram_init_banksize(void) > > if (i > 0) > > ret = 0; > > > > -#if defined(CONFIG_FSL_MC_ENET) && !defined(CONFIG_SPL_BUILD) > > +#if defined(CONFIG_RESV_RAM) && !defined(CONFIG_SPL_BUILD) > > /* Assign memory for MC */ > > #ifdef CONFIG_SYS_DDR_BLOCK3_BASE > > if (gd->bd->bi_dram[2].size >= > > @@ -1402,7 +1402,7 @@ static int tfa_dram_init_banksize(void) > > board_reserve_ram_top(gd->bd- > > >bi_dram[0].size); > > } > > } > > -#endif /* CONFIG_FSL_MC_ENET */ > > +#endif /* CONFIG_RESV_RAM */ > > > > return ret; > > } > > @@ -1465,7 +1465,7 @@ int dram_init_banksize(void) > > } > > #endif /* CONFIG_SYS_MEM_RESERVE_SECURE */ > > > > -#if defined(CONFIG_FSL_MC_ENET) && !defined(CONFIG_SPL_BUILD) > > +#if defined(CONFIG_RESV_RAM) && !defined(CONFIG_SPL_BUILD) > > /* Assign memory for MC */ > > #ifdef CONFIG_SYS_DDR_BLOCK3_BASE > > if (gd->bd->bi_dram[2].size >= > > @@ -1488,7 +1488,7 @@ int dram_init_banksize(void) > > board_reserve_ram_top(gd->bd- > > >bi_dram[0].size); > > } > > } > > -#endif /* CONFIG_FSL_MC_ENET */ > > +#endif /* CONFIG_RESV_RAM */ > > > > CONFIG_FSL_MC_ENET will select the CONFIG_RESV_RAM. What benefit we > have with this change ? > because we are reserving memory for MC in the following code, so earlier > check (with CONFIG_FSL_MC_ENET) looks good to be. No benefit, but it's not the correct logic, see the change log, so correct. Thanks, Zhiqiang > > > #ifdef CONFIG_SYS_DP_DDR_BASE_PHY > > #ifdef CONFIG_SYS_DDR_BLOCK3_BASE > > -- > > 2.17.1
RE: [PATCHv2 1/9] board: lx2160a: Add header file cpu_func.h
Hi Wasim, Thanks a lot for your comments! > -Original Message- > From: Wasim Khan > Sent: 2020年4月21日 13:41 > To: Z.q. Hou ; u-boot@lists.denx.de; Priyanka Jain > ; Biwen Li > Cc: Z.q. Hou > Subject: RE: [PATCHv2 1/9] board: lx2160a: Add header file cpu_func.h > > > > > -Original Message- > > From: U-Boot On Behalf Of Zhiqiang Hou > > Sent: Tuesday, March 24, 2020 1:42 PM > > To: u-boot@lists.denx.de; Priyanka Jain ; Biwen > > Li > > Cc: Z.q. Hou > > Subject: [PATCHv2 1/9] board: lx2160a: Add header file cpu_func.h > > > > From: Hou Zhiqiang > > > > The declaration of the function cpu_numcores() has been moved to > > cpu_func.h, so add including of the header file to avoid build error. > > > > Signed-off-by: Hou Zhiqiang > > --- > > V2: > > - No change. > > > > board/freescale/lx2160a/lx2160a.c | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/board/freescale/lx2160a/lx2160a.c > > b/board/freescale/lx2160a/lx2160a.c > > index 134ae22f85..595c774b42 100644 > > --- a/board/freescale/lx2160a/lx2160a.c > > +++ b/board/freescale/lx2160a/lx2160a.c > > @@ -5,6 +5,7 @@ > > > > #include > > #include > > +#include > > cpu_func.h is already included in board/freescale/lx2160a/lx2160a.c. > You can remove this patch. Priyanka, please drop this patch if it had been there. Thanks, Zhiqiang > > > #include > > #include #include > > -- > > 2.17.1
RE: [PATCHv2 2/9] arm64: fsl-layerscape: Assign addr to resv_ram if enabled RESV_RAM config
Hi Priyanka, Thanks a lot for your comments! > -Original Message- > From: Priyanka Jain (OSS) > Sent: 2020年4月15日 18:28 > To: Z.q. Hou ; u-boot@lists.denx.de; Biwen Li > > Cc: Z.q. Hou > Subject: RE: [PATCHv2 2/9] arm64: fsl-layerscape: Assign addr to resv_ram if > enabled RESV_RAM config > > >-Original Message- > >From: U-Boot On Behalf Of Zhiqiang Hou > >Sent: Tuesday, March 24, 2020 1:42 PM > >To: u-boot@lists.denx.de; Priyanka Jain ; Biwen > >Li > >Cc: Z.q. Hou > >Subject: [PATCHv2 2/9] arm64: fsl-layerscape: Assign addr to resv_ram > >if enabled RESV_RAM config > > > >From: Hou Zhiqiang > > > >The initialization of gd->arch.resv_ram pointer should depend on if the > >RESV_RAM config is enabled. > > > >Signed-off-by: Hou Zhiqiang > >--- > >V2: > > - No change. > > > > arch/arm/cpu/armv8/fsl-layerscape/cpu.c | 8 > > 1 file changed, 4 insertions(+), 4 deletions(-) > > > >diff --git a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c > >b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c > >index b443894453..1b7729c046 100644 > >--- a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c > >+++ b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c > >@@ -1379,7 +1379,7 @@ static int tfa_dram_init_banksize(void) > > if (i > 0) > > ret = 0; > > > >-#if defined(CONFIG_FSL_MC_ENET) && !defined(CONFIG_SPL_BUILD) > >+#if defined(CONFIG_RESV_RAM) && !defined(CONFIG_SPL_BUILD) > > /* Assign memory for MC */ > > #ifdef CONFIG_SYS_DDR_BLOCK3_BASE > > if (gd->bd->bi_dram[2].size >= > >@@ -1402,7 +1402,7 @@ static int tfa_dram_init_banksize(void) > > board_reserve_ram_top(gd->bd- > >>bi_dram[0].size); > > } > > } > >-#endif /* CONFIG_FSL_MC_ENET */ > >+#endif /* CONFIG_RESV_RAM */ > This memory block was intended to be used for MC. That’s why earlier > check was for "CONFIG_FSL_MC_ENET" > Are we planning to use this block for some other purpose as well? > Also I see "CONFIG_ RESV_RAM" getting defines later in the series. > Will MC will work if the series in applied partially? Yes, as you know this will be used for workaround of GICv3 redistributor tables one-way reset issue. The MC will not be affected, since FSL_MC_ENET selected RESV_RAM config. Thanks, Zhiqiang > > Regards > Priyanka > > return ret; > > } > >@@ -1465,7 +1465,7 @@ int dram_init_banksize(void) > > } > > #endif /* CONFIG_SYS_MEM_RESERVE_SECURE */ > > > >-#if defined(CONFIG_FSL_MC_ENET) && !defined(CONFIG_SPL_BUILD) > >+#if defined(CONFIG_RESV_RAM) && !defined(CONFIG_SPL_BUILD) > > /* Assign memory for MC */ > > #ifdef CONFIG_SYS_DDR_BLOCK3_BASE > > if (gd->bd->bi_dram[2].size >= > >@@ -1488,7 +1488,7 @@ int dram_init_banksize(void) > > board_reserve_ram_top(gd->bd- > >>bi_dram[0].size); > > } > > } > >-#endif /* CONFIG_FSL_MC_ENET */ > >+#endif /* CONFIG_RESV_RAM */ > > > > #ifdef CONFIG_SYS_DP_DDR_BASE_PHY > > #ifdef CONFIG_SYS_DDR_BLOCK3_BASE > >-- > >2.17.1
RE: [PATCH 11/12] board: fsl: ls2080a: Initialize the GIC redistributor tables
Hi Bin,
Thanks a lot for your comments!
> -Original Message-
> From: Bin Meng
> Sent: 2020年3月19日 19:57
> To: Z.q. Hou
> Cc: U-Boot Mailing List ; Priyanka Jain
>
> Subject: Re: [PATCH 11/12] board: fsl: ls2080a: Initialize the GIC
> redistributor
> tables
>
> On Thu, Mar 19, 2020 at 1:44 PM Zhiqiang Hou
> wrote:
> >
> > From: Hou Zhiqiang
> >
> > Fixup kernel DT to reserve memory for GIC redistributor tables, and
> > initialize the redistributor configuration and pending tables using
> > the reserved memory.
> >
> > Signed-off-by: Hou Zhiqiang
> > ---
> > board/freescale/ls2080aqds/ls2080aqds.c | 14 ++
> > board/freescale/ls2080ardb/ls2080ardb.c | 14 ++
> > 2 files changed, 28 insertions(+)
> >
> > diff --git a/board/freescale/ls2080aqds/ls2080aqds.c
> > b/board/freescale/ls2080aqds/ls2080aqds.c
> > index 4034bdee28..fd63e6bc76 100644
> > --- a/board/freescale/ls2080aqds/ls2080aqds.c
> > +++ b/board/freescale/ls2080aqds/ls2080aqds.c
> > @@ -3,6 +3,7 @@
> > * Copyright 2015 Freescale Semiconductor
> > */
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -12,6 +13,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -21,12 +23,14 @@
> > #include
> > #include
> > #include
> > +#include
> >
> >
> > #include "../common/qixis.h"
> > #include "ls2080aqds_qixis.h"
> > #include "../common/vid.h"
> >
> > +#define GIC_LPI_SIZE 0x20
> > #define PIN_MUX_SEL_SDHC 0x00
> > #define PIN_MUX_SEL_DSPI 0x0a
> > #define SCFG_QSPICLKCTRL_DIV_20(5 << 27)
> > @@ -323,6 +327,8 @@ int ft_board_setup(void *blob, bd_t *bd) {
> > u64 base[CONFIG_NR_DRAM_BANKS];
> > u64 size[CONFIG_NR_DRAM_BANKS];
> > + u64 gic_lpi_base;
> > + int ret;
> >
> > ft_cpu_setup(blob, bd);
> >
> > @@ -333,6 +339,14 @@ int ft_board_setup(void *blob, bd_t *bd)
> > size[1] = gd->bd->bi_dram[1].size;
> >
> > #ifdef CONFIG_RESV_RAM
> > +#ifdef CONFIG_GIC_V3_ITS
> > + gic_lpi_base = ALIGN(gd->arch.resv_ram - GIC_LPI_SIZE,
> SZ_64K);
> > + ret = fdt_add_resv_mem_gic_rd_tables(blob, gic_lpi_base,
> GIC_LPI_SIZE);
> > + if (!ret) {
> > + if (gic_lpi_tables_init(gic_lpi_base, cpu_numcores()))
> > + debug("%s: failed to init gic-lpi-tables\n",
> __func__);
> > + }
>
> Is this board-specific fix-up, or LS2080 specific? If latter, we should put
> it in
> the LS2080 SoC codes.
It's a SoC level fixup, I'll refine the series in v2.
Thanks,
Zhiqiang
>
> > +#endif
> > /* reduce size if reserved memory is within this bank */
> > if (gd->arch.resv_ram >= base[0] &&
> > gd->arch.resv_ram < base[0] + size[0]) diff --git
> > a/board/freescale/ls2080ardb/ls2080ardb.c
> > b/board/freescale/ls2080ardb/ls2080ardb.c
> > index 282aaf47fb..45e645f8de 100644
> > --- a/board/freescale/ls2080ardb/ls2080ardb.c
> > +++ b/board/freescale/ls2080ardb/ls2080ardb.c
> > @@ -4,6 +4,7 @@
> > * Copyright 2017 NXP
> > */
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -14,6 +15,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -23,6 +25,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > #ifdef CONFIG_FSL_QIXIS
> > #include "../common/qixis.h"
> > @@ -30,6 +33,7 @@
> > #endif
> > #include "../common/vid.h"
> >
> > +#define GIC_LPI_SIZE 0x20
> > #define PIN_MUX_SEL_SDHC 0x00
> > #define PIN_MUX_SEL_DSPI 0x0a
> >
> > @@ -421,6 +425,8 @@ int ft_board_setup(void *blob, bd_t *bd)
> > u64 mc_memory_base = 0;
> > u64 mc_memory_size = 0;
> > u16 total_memory_banks;
> > + u64 gic_lpi_base;
> > + int ret;
> >
> > ft_cpu_setup(blob, bd);
> >
> > @@ -441,6 +447,14 @@ int ft_board_setup(void *blob, bd_t *bd)
> > size[1] = gd->bd->bi_dram[1].size;
> >
> > #ifdef CONFIG_RESV_RAM
> > +#ifdef CONFIG_GIC_V3_ITS
> > + gic_lpi_base = ALIGN(gd->arch.resv_ram - GIC_LPI_SIZE,
> SZ_64K);
> > + ret = fdt_add_resv_mem_gic_rd_tables(blob, gic_lpi_base,
> GIC_LPI_SIZE);
> > + if (!ret) {
> > + if (gic_lpi_tables_init(gic_lpi_base, cpu_numcores()))
> > + debug("%s: failed to init gic-lpi-tables\n",
> __func__);
> > + }
>
> ditto
>
> > +#endif
> > /* reduce size if reserved memory is within this bank */
> > if (gd->arch.resv_ram >= base[0] &&
> > gd->arch.resv_ram < base[0] + size[0])
> > --
>
>
> Regards,
> Bin
[PATCH 2/2] pci: layerscape: Fix the BARs disable function
From: Hou Zhiqiang
There is not any difference for disabling BARs in RC mode
between PCIe controllers with and without SRIOV.
Fixes: 80afc63fc342 ("pci: layerscape: add pci driver based on DM")
Signed-off-by: Hou Zhiqiang
---
drivers/pci/pcie_layerscape.c | 11 ---
1 file changed, 11 deletions(-)
diff --git a/drivers/pci/pcie_layerscape.c b/drivers/pci/pcie_layerscape.c
index 96533cb2d9..d8ca7e71f8 100644
--- a/drivers/pci/pcie_layerscape.c
+++ b/drivers/pci/pcie_layerscape.c
@@ -312,17 +312,6 @@ static void ls_pcie_drop_msg_tlp(struct ls_pcie *pcie)
/* Disable all bars in RC mode */
static void ls_pcie_disable_bars(struct ls_pcie *pcie)
{
- u32 sriov;
-
- sriov = in_le32(pcie->dbi + PCIE_SRIOV);
-
- /*
-* TODO: For PCIe controller with SRIOV, the method to disable bars
-* is different and more complex, so will add later.
-*/
- if (PCI_EXT_CAP_ID(sriov) == PCI_EXT_CAP_ID_SRIOV)
- return;
-
dbi_writel(pcie, 0, PCIE_CS2_OFFSET + PCI_BASE_ADDRESS_0);
dbi_writel(pcie, 0, PCIE_CS2_OFFSET + PCI_BASE_ADDRESS_1);
dbi_writel(pcie, 0xfffe, PCIE_CS2_OFFSET + PCI_ROM_ADDRESS1);
--
2.17.1
[PATCH 0/2] pci: layerscape: Fix the BARs disable function in RC mode
From: Hou Zhiqiang The Expansion ROM BAR is not disabled by clearing the BAR_EN bit in current code, fix it. Add disabling of BARs of PCIe controller with SRIOV feature. Hou Zhiqiang (2): pci: layerscape: Fix the disabling of Expansion ROM BAR pci: layerscape: Fix the BARs disable function drivers/pci/pcie_layerscape.c | 13 + 1 file changed, 1 insertion(+), 12 deletions(-) -- 2.17.1
[PATCH 1/2] pci: layerscape: Fix the disabling of Expansion ROM BAR
From: Hou Zhiqiang
The software will still get non-zero Expansion ROM BAR size
even when the BAR_EN bit is cleared. The BAR_EN bit of
register EXP_ROM_BAR_MASK_RC is not working as expected,
so this patch changes to mask all the bits to make it.
Fixes: 80afc63fc342 ("pci: layerscape: add pci driver based on DM")
Signed-off-by: Hou Zhiqiang
---
drivers/pci/pcie_layerscape.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pci/pcie_layerscape.c b/drivers/pci/pcie_layerscape.c
index 5ad7c28773..96533cb2d9 100644
--- a/drivers/pci/pcie_layerscape.c
+++ b/drivers/pci/pcie_layerscape.c
@@ -325,7 +325,7 @@ static void ls_pcie_disable_bars(struct ls_pcie *pcie)
dbi_writel(pcie, 0, PCIE_CS2_OFFSET + PCI_BASE_ADDRESS_0);
dbi_writel(pcie, 0, PCIE_CS2_OFFSET + PCI_BASE_ADDRESS_1);
- dbi_writel(pcie, 0, PCIE_CS2_OFFSET + PCI_ROM_ADDRESS1);
+ dbi_writel(pcie, 0xfffe, PCIE_CS2_OFFSET + PCI_ROM_ADDRESS1);
}
static void ls_pcie_setup_ctrl(struct ls_pcie *pcie)
--
2.17.1
Re: [U-Boot] [PATCH] pci: layerscape: remove multiple definitions of SVR
Hi Pankaj,
> -Original Message-
> From: Pankaj Bansal
> Sent: 2019年10月14日 16:56
> To: Priyanka Jain ; Xiaowei Bao
> ; Tom Rini ; Z.q. Hou
>
> Cc: u-boot@lists.denx.de; Pankaj Bansal
> Subject: [PATCH] pci: layerscape: remove multiple definitions of SVR
>
> SVR values for various nxp SOCs are defined in asm/arch/soc.h we can use
> these values in any peripheral driver.
> we need not to redefine these values in peripheral driver, as this becomes
> difficult to manage (add or change new values)
>
> Signed-off-by: Pankaj Bansal
> ---
> drivers/pci/pcie_layerscape.c | 11 ++-
> drivers/pci/pcie_layerscape.h | 9 +
> drivers/pci/pcie_layerscape_fixup.c | 9 +
> 3 files changed, 12 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/pci/pcie_layerscape.c b/drivers/pci/pcie_layerscape.c
> index db1375a1ce..d8a7b7c865 100644
> --- a/drivers/pci/pcie_layerscape.c
> +++ b/drivers/pci/pcie_layerscape.c
> @@ -1,6 +1,6 @@
> // SPDX-License-Identifier: GPL-2.0+
> /*
> - * Copyright 2017 NXP
> + * Copyright 2017, 2019 NXP
> * Copyright 2014-2015 Freescale Semiconductor, Inc.
> * Layerscape PCIe driver
> */
> @@ -15,6 +15,7 @@
> #if defined(CONFIG_FSL_LSCH2) || defined(CONFIG_FSL_LSCH3) || \
> defined(CONFIG_ARM)
> #include
> +#include
> #endif
> #include "pcie_layerscape.h"
>
> @@ -56,7 +57,7 @@ static int ls_pcie_ltssm(struct ls_pcie *pcie)
> uint svr;
>
> svr = get_svr();
> - if (((svr >> SVR_VAR_PER_SHIFT) & SVR_LS102XA_MASK) ==
> SVR_LS102XA) {
> + if ((SVR_DEV(svr) & SVR_LS102XA_MASK) == SVR_LS102XA) {
> state = ctrl_readl(pcie, LS1021_PEXMSCPORTSR(pcie->idx));
> state = (state >> LS1021_LTSSM_STATE_SHIFT) &
> LTSSM_STATE_MASK;
> } else {
> @@ -149,7 +150,7 @@ static void ls_pcie_setup_atu(struct ls_pcie *pcie)
> uint svr;
>
> svr = get_svr();
> - if (((svr >> SVR_VAR_PER_SHIFT) & SVR_LS102XA_MASK) ==
> SVR_LS102XA) {
> + if ((SVR_DEV(svr) & SVR_LS102XA_MASK) == SVR_LS102XA) {
> offset = LS1021_PCIE_SPACE_OFFSET +
>LS1021_PCIE_SPACE_SIZE * pcie->idx;
> }
> @@ -172,7 +173,7 @@ static void ls_pcie_setup_atu(struct ls_pcie *pcie)
> idx = PCIE_ATU_REGION_INDEX1 + 1;
>
> /* Fix the pcie memory map for LS2088A series SoCs */
> - svr = (svr >> SVR_VAR_PER_SHIFT) & 0xFE;
> + svr = SVR_SOC_VER(svr);
> if (svr == SVR_LS2088A || svr == SVR_LS2084A ||
> svr == SVR_LS2048A || svr == SVR_LS2044A ||
> svr == SVR_LS2081A || svr == SVR_LS2041A) { @@ -502,7 +503,7
> @@ static int ls_pcie_probe(struct udevice *dev)
>* for LS2088A series SoCs
>*/
> svr = get_svr();
> - svr = (svr >> SVR_VAR_PER_SHIFT) & 0xFE;
> + svr = SVR_SOC_VER(svr);
> if (svr == SVR_LS2088A || svr == SVR_LS2084A ||
> svr == SVR_LS2048A || svr == SVR_LS2044A ||
> svr == SVR_LS2081A || svr == SVR_LS2041A) { diff --git
> a/drivers/pci/pcie_layerscape.h b/drivers/pci/pcie_layerscape.h index
> ddfbba6538..9a19993568 100644
> --- a/drivers/pci/pcie_layerscape.h
> +++ b/drivers/pci/pcie_layerscape.h
> @@ -1,6 +1,6 @@
> /* SPDX-License-Identifier: GPL-2.0+ */
> /*
> - * Copyright 2017 NXP
> + * Copyright 2017, 2019 NXP
> * Copyright 2014-2015 Freescale Semiconductor, Inc.
> * Layerscape PCIe driver
> */
> @@ -111,14 +111,7 @@
> #define PCIE_CS2_OFFSET 0x1000 /* For PCIe without SR-IOV */
>
> #define SVR_LS102XA 0
> -#define SVR_VAR_PER_SHIFT8
> #define SVR_LS102XA_MASK 0x700
> -#define SVR_LS2088A 0x870900
> -#define SVR_LS2084A 0x870910
> -#define SVR_LS2048A 0x870920
> -#define SVR_LS2044A 0x870930
> -#define SVR_LS2081A 0x870918
> -#define SVR_LS2041A 0x870914
Keep in mind that LS1021A (armv7) also uses this driver and it will result in
build error when removed them.
Thanks,
Zhiqiang
>
> /* LS1021a PCIE space */
> #define LS1021_PCIE_SPACE_OFFSET 0x40ULL
> diff --git a/drivers/pci/pcie_layerscape_fixup.c
> b/drivers/pci/pcie_layerscape_fixup.c
> index 089e031724..9a09852981 100644
> --- a/drivers/pci/pcie_layerscape_fixup.c
> +++ b/drivers/pci/pcie_layerscape_fixup.c
> @@ -1,6 +1,6 @@
> // SPDX-License-Identifier: GPL-2.0+
> /*
> - * Copyright 2017 NXP
> + * Copyright 2017, 2019 NXP
> * Copyright 2014-2015 Freescale Semiconductor, Inc.
> * Layerscape PCIe driver
> */
> @@ -16,6 +16,7 @@
> #ifdef CONFIG_ARM
>
Re: [U-Boot] [PATCH] pci: layerscape: Only set EP CFG READY bit
> -Original Message-
> From: Pankaj Bansal
> Sent: 2019年10月14日 19:43
> To: Priyanka Jain ; Xiaowei Bao
> ; Tom Rini ; Z.q. Hou
>
> Cc: u-boot@lists.denx.de; Pankaj Bansal
> Subject: [PATCH] pci: layerscape: Only set EP CFG READY bit
>
> As part of EP setup, we want to set the config ready bit of controller, so
> that
> RC can read the config space of EP.
> Now, when we set the config ready bit we are inadvertently clearing the
> LTSSM_EN bit in same register, which restarts the link tarining between RC
> and EP.
> Therefore, just set the desired CFG_READY bit (bit 0), while leaving the other
> bits unchanged.
>
> Signed-off-by: Pankaj Bansal
> ---
> drivers/pci/pcie_layerscape.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/pci/pcie_layerscape.c b/drivers/pci/pcie_layerscape.c
> index d8a7b7c865..bb2ec7c2ce 100644
> --- a/drivers/pci/pcie_layerscape.c
> +++ b/drivers/pci/pcie_layerscape.c
> @@ -407,7 +407,11 @@ static void ls_pcie_ep_setup_bars(void *bar_base)
>
> static void ls_pcie_ep_enable_cfg(struct ls_pcie *pcie) {
> - ctrl_writel(pcie, PCIE_CONFIG_READY, PCIE_PF_CONFIG);
> + u32 config;
> +
> + config = ctrl_readl(pcie, PCIE_PF_CONFIG);
> + config |= PCIE_CONFIG_READY;
> + ctrl_writel(pcie, config, PCIE_PF_CONFIG);
> }
>
> static void ls_pcie_setup_ep(struct ls_pcie *pcie)
> --
> 2.17.1
Reviewed-by: Hou Zhiqiang
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 0/3] pci: pcie_fsl: add support for none PCIe devices
Hi Heiko, > -Original Message- > From: Heiko Schocher > Sent: 2019年10月9日 12:37 > To: U-Boot Mailing List > Cc: Heiko Schocher ; Bin Meng ; Z.q. > Hou ; Prabhakar X > ; Z.q. Hou > Subject: [PATCH 0/3] pci: pcie_fsl: add support for none PCIe devices > > add support for devices with compatible property: > "fsl,mpc8540-pci". Unfortunately we can not change the property name, as > already defined in linux. > > This patch superseeds patch [1]: > https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpatch > work.ozlabs.org%2Fpatch%2F1132418%2Fdata=02%7C01%7CZhiqian > g.Hou%40nxp.com%7Cf3882a7d460748c51be308d74c726590%7C686ea1d3 > bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637061926547234336sda > ta=oxZBn89GDmItT5Orj1re2ASlVWa33H1BprL1Rxg%2FPDg%3Dreserv > ed=0 > > While working to integrate comments from Z.q. Hou to patch [1], I thought > it may is the better idea, to use the already existing pcie_fsl driver and > work > in support for pci devices. Please comment! > > If it is no good idea, I have also a v2 of [1] with the comments from Z.q. Hou > worked in ready to post... I don't think it is a good idea to add PCI controller support into PCIe controller driver, see the drivers/pci/fsl_pci_init.c, which support both PCI and PCIe controllers, but it is not readable :(. So I think it is better to separate the PCI driver into a new file just like you did in V1. Thanks, Zhiqiang > > Travis build: > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftravis > -ci.org%2Fhsdenx%2Fu-boot-test%2Fbuilds%2F595057579data=02%7 > C01%7CZhiqiang.Hou%40nxp.com%7Cf3882a7d460748c51be308d74c72659 > 0%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C63706192654723 > 4336sdata=3amAx0BH9zoY8MjT3GnVfmde4EJuqvYql7lO%2Fs9E15Q% > 3Dreserved=0 > (sheevaplug fails, but this is on discussion on list) > > Heiko Schocher (3): > pci: pcie_fsl: use pci_conv_size_to_32() > pci: pcie_fsl: reorder addr check function > pci: pcie_fsl: add support for "fsl,mpc8540-pci" > > drivers/pci/pcie_fsl.c | 68 +++--- > drivers/pci/pcie_fsl.h | 1 + > 2 files changed, 32 insertions(+), 37 deletions(-) > > -- > 2.21.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCHv2] armv8: ls1028a: Updated lane C configuration to PCIe2 for 0x13BB
From: Hou Zhiqiang
In SerDes protocol 0x13BB, lane C was erroneously assigned
to PCIe1, so fix it.
Fixes: 36f50b75238e ("armv8: ls1028a: Add other serdes protocal support")
Signed-off-by: Hou Zhiqiang
---
V2:
- Fixed a typo in changelog.
arch/arm/cpu/armv8/fsl-layerscape/ls1028a_serdes.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/ls1028a_serdes.c
b/arch/arm/cpu/armv8/fsl-layerscape/ls1028a_serdes.c
index 5835a3a69e..313f3f1e8a 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/ls1028a_serdes.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/ls1028a_serdes.c
@@ -24,7 +24,7 @@ static struct serdes_config serdes1_cfg_tbl[] = {
{0x, {PCIE1, PCIE1, PCIE1, PCIE1} },
{0xE031, {SXGMII1, QXGMII2, NONE, SATA1} },
{0xB991, {SXGMII1, SGMII1, SGMII2, PCIE1} },
- {0xBB31, {SXGMII1, QXGMII2, PCIE1, PCIE1} },
+ {0xBB31, {SXGMII1, QXGMII2, PCIE2, PCIE1} },
{0xCC31, {SXGMII1, QXGMII2, PCIE2, PCIE2} },
{0xBB51, {SXGMII1, QSGMII_B, PCIE2, PCIE1} },
{0xBB38, {SGMII_T1, QXGMII2, PCIE2, PCIE1} },
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] armv8: ls1028a: Updated lane C configuration to PCIe2 for 0x13BB
From: Hou Zhiqiang
In SerDes protocol 0x13BB, lane C was erroneously asigned
to PCIe1, so fix it.
Fixes: 36f50b75238e ("armv8: ls1028a: Add other serdes protocal support")
Signed-off-by: Hou Zhiqiang
---
arch/arm/cpu/armv8/fsl-layerscape/ls1028a_serdes.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/ls1028a_serdes.c
b/arch/arm/cpu/armv8/fsl-layerscape/ls1028a_serdes.c
index 5835a3a69e..313f3f1e8a 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/ls1028a_serdes.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/ls1028a_serdes.c
@@ -24,7 +24,7 @@ static struct serdes_config serdes1_cfg_tbl[] = {
{0x, {PCIE1, PCIE1, PCIE1, PCIE1} },
{0xE031, {SXGMII1, QXGMII2, NONE, SATA1} },
{0xB991, {SXGMII1, SGMII1, SGMII2, PCIE1} },
- {0xBB31, {SXGMII1, QXGMII2, PCIE1, PCIE1} },
+ {0xBB31, {SXGMII1, QXGMII2, PCIE2, PCIE1} },
{0xCC31, {SXGMII1, QXGMII2, PCIE2, PCIE2} },
{0xBB51, {SXGMII1, QSGMII_B, PCIE2, PCIE1} },
{0xBB38, {SGMII_T1, QXGMII2, PCIE2, PCIE1} },
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1] pci: add DM based mpc85xx driver
Hi Heiko, > -Original Message- > From: Heiko Schocher > Sent: 2019年8月30日 12:17 > To: Z.q. Hou > Cc: u-boot@lists.denx.de; Alexander Graf ; Andrew F. Davis > ; Xiaowei Bao ; Bin Meng > ; Eugen Hristev ; > Heinrich Schuchardt ; Horatiu Vultur > ; Krzysztof Kozlowski ; > Liviu Dudau ; Marek Vasut > ; Mario Six ; Michal Simek > ; Neil Armstrong ; > Prabhakar Kushwaha ; Ryder Lee > ; Simon Glass ; Stefan > Roese > Subject: Re: [PATCH v1] pci: add DM based mpc85xx driver > > Hello Z.q. Hou, > > Am 29.08.2019 um 10:11 schrieb Z.q. Hou: > > Hi Heiko, > > > >> -Original Message- > >> From: Heiko Schocher > >> Sent: 2019年7月16日 11:36 > >> To: u-boot@lists.denx.de > >> Cc: Heiko Schocher ; Alexander Graf ; > >> Andrew F. Davis ; Xiaowei Bao ; > Bin > >> Meng ; Eugen Hristev > >> ; Heinrich Schuchardt > >> ; Horatiu Vultur ; > >> Z.q. Hou ; Krzysztof Kozlowski > >> ; Liviu Dudau ; Marek > >> Vasut ; Mario Six ; > Michal > >> Simek ; Neil Armstrong > >> ; Prabhakar Kushwaha > >> ; Ryder Lee > ; > >> Simon Glass ; Stefan Roese > >> Subject: [PATCH v1] pci: add DM based mpc85xx driver > >> > >> add DM based PCI Configuration space access support for MPC85xx PCI > >> Bridge > > > > Seems you're converting the arch/powerpc/cpu/mpc85xx/pci.c to driver > > model, > > Yes, should have added this to commit message .. fixed. > > > but not every mpc85xx platform uses this driver, platforms mpc8536, > > 8544, > > 8548 and 8568 use the drivers/pci/fsl_pci_init.c, please take them into > account. > > Oh, wasn;t aware of this! ... I have no idea why there are 2 drivers and > where are the differences between them, nor I can test all the other > plattforms, so this seems difficult to me. > > Do you know, why there are 2 different drivers? I guess the mpc85xx/pci.c was added for the older platforms, which only integrated PCI controllers, it can't support the newer platforms, which integrated both PCI and PCIe controllers. So the fsl_pci_init.c was added. > > I made this new driver, because I work on DM support for the socrates board, > which is mpc8544 based ... !? > > May I rename this driver from pci_mpc85xx.c to pci_mpc85xx_dm.c and it > can be a base for DM support and others, who can test their changes, can > add the other variants? It's unnecessary to change the driver file name, I can help to verify on mpc8548, Let others add other mpc85xx PCI DM driver base on this. > > > Note: The platforms using arch/powerpc/cpu/mpc85xx/pci.c set up PCI > > LAWs in file arch/powerpc/cpu/mpc8xxx/law.c, while other platforms set > > up PCI LAWs in PCI driver. So I think you can move the PCI LAWs set-up > > into this DM PCI driver And remove the PCI entries from law.c. > > Yes good idea, add this in v2 for this driver. > > >> Signed-off-by: Heiko Schocher > >> > >> --- > >> Travis build, see: > >> https://travis > >> > -ci.org%2Fhsdenx%2Fu-boot-test%2Fbuilds%2F558855544data=02%7 > >> > C01%7CZhiqiang.Hou%40nxp.com%7C231ac8975b2242ea5bfb08d7099eccc > >> > 8%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C63698844995746 > >> > 0734sdata=lQcXtvh5a0G9r%2BFlXnnGQ5VgDYvcR%2FEGWpShJ324su > >> U%3Dreserved=0 > >> > >> MAINTAINERS | 5 ++ > >> drivers/pci/Kconfig | 7 ++ > >> drivers/pci/Makefile | 1 + > >> drivers/pci/pci_mpc85xx.c | 132 > >> ++ > >> 4 files changed, 145 insertions(+) > >> create mode 100644 drivers/pci/pci_mpc85xx.c > >> > >> diff --git a/MAINTAINERS b/MAINTAINERS index > e91684191f..01faa67a6d > >> 100644 > >> --- a/MAINTAINERS > >> +++ b/MAINTAINERS > >> @@ -639,6 +639,11 @@ S:Maintained > >> F: drivers/pci_endpoint/ > >> F: include/pci_ep.h > >> > >> +PCI MPC85xx > >> +M:Heiko Schocher > >> +S:Maintained > >> +F:drivers/pci/pci_mpc85xx.c > >> + > >> POWER > >> M: Jaehoon Chung > >> S: Maintained > >> diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig index > >> 3fe38f7315..88db0067b4 100644 > >> --- a/drivers/pci/Kconfig > >> +++ b/drivers/pci/Kconfig > >> @@ -68,6 +68,13 @@ config PCIE_FSL > >> PowerPC MPC85xx, MPC86xx, B series, P series and T series > SoCs. > >> This driver doe
Re: [U-Boot] [PATCH v1] pci: add DM based mpc85xx driver
Hi Heiko,
> -Original Message-
> From: Heiko Schocher
> Sent: 2019年7月16日 11:36
> To: u-boot@lists.denx.de
> Cc: Heiko Schocher ; Alexander Graf ;
> Andrew F. Davis ; Xiaowei Bao ; Bin
> Meng ; Eugen Hristev
> ; Heinrich Schuchardt
> ; Horatiu Vultur ;
> Z.q. Hou ; Krzysztof Kozlowski ;
> Liviu Dudau ; Marek Vasut
> ; Mario Six ; Michal Simek
> ; Neil Armstrong ;
> Prabhakar Kushwaha ; Ryder Lee
> ; Simon Glass ; Stefan
> Roese
> Subject: [PATCH v1] pci: add DM based mpc85xx driver
>
> add DM based PCI Configuration space access support for MPC85xx PCI
> Bridge
Seems you're converting the arch/powerpc/cpu/mpc85xx/pci.c to driver model,
but not every mpc85xx platform uses this driver, platforms mpc8536, 8544,
8548 and 8568 use the drivers/pci/fsl_pci_init.c, please take them into account.
Note: The platforms using arch/powerpc/cpu/mpc85xx/pci.c set up PCI LAWs in
file arch/powerpc/cpu/mpc8xxx/law.c, while other platforms set up PCI LAWs in
PCI driver. So I think you can move the PCI LAWs set-up into this DM PCI driver
And remove the PCI entries from law.c.
>
> Signed-off-by: Heiko Schocher
>
> ---
> Travis build, see:
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftravis
> -ci.org%2Fhsdenx%2Fu-boot-test%2Fbuilds%2F558855544data=02%7
> C01%7CZhiqiang.Hou%40nxp.com%7C231ac8975b2242ea5bfb08d7099eccc
> 8%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C63698844995746
> 0734sdata=lQcXtvh5a0G9r%2BFlXnnGQ5VgDYvcR%2FEGWpShJ324su
> U%3Dreserved=0
>
> MAINTAINERS | 5 ++
> drivers/pci/Kconfig | 7 ++
> drivers/pci/Makefile | 1 +
> drivers/pci/pci_mpc85xx.c | 132
> ++
> 4 files changed, 145 insertions(+)
> create mode 100644 drivers/pci/pci_mpc85xx.c
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index e91684191f..01faa67a6d 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -639,6 +639,11 @@ S: Maintained
> F: drivers/pci_endpoint/
> F: include/pci_ep.h
>
> +PCI MPC85xx
> +M: Heiko Schocher
> +S: Maintained
> +F: drivers/pci/pci_mpc85xx.c
> +
> POWER
> M: Jaehoon Chung
> S: Maintained
> diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig index
> 3fe38f7315..88db0067b4 100644
> --- a/drivers/pci/Kconfig
> +++ b/drivers/pci/Kconfig
> @@ -68,6 +68,13 @@ config PCIE_FSL
> PowerPC MPC85xx, MPC86xx, B series, P series and T series SoCs.
> This driver does not support SRIO_PCIE_BOOT feature.
>
> +config PCI_MPC85XX
> + bool "MPC85XX PowerPC PCI support"
> + depends on DM_PCI
> + help
> + Say Y here if you want to enable PCI controller support on FSL
> + PowerPC MPC85xx SoC.
> +
> config PCI_RCAR_GEN2
> bool "Renesas RCar Gen2 PCIe driver"
> depends on DM_PCI
> diff --git a/drivers/pci/Makefile b/drivers/pci/Makefile index
> b5ebd50c85..929f119fb3 100644
> --- a/drivers/pci/Makefile
> +++ b/drivers/pci/Makefile
> @@ -19,6 +19,7 @@ obj-$(CONFIG_PCIE_ECAM_GENERIC) +=
> pcie_ecam_generic.o
> obj-$(CONFIG_FSL_PCI_INIT) += fsl_pci_init.o
> obj-$(CONFIG_PCI_INDIRECT_BRIDGE) += pci_indirect.o
> obj-$(CONFIG_PCI_GT64120) += pci_gt64120.o
> +obj-$(CONFIG_PCI_MPC85XX) += pci_mpc85xx.o
> obj-$(CONFIG_PCI_MSC01) += pci_msc01.o
> obj-$(CONFIG_PCIE_IMX) += pcie_imx.o
> obj-$(CONFIG_FTPCI100) += pci_ftpci100.o diff --git
> a/drivers/pci/pci_mpc85xx.c b/drivers/pci/pci_mpc85xx.c new file mode
> 100644 index 00..c0d35f7f2c
> --- /dev/null
> +++ b/drivers/pci/pci_mpc85xx.c
> @@ -0,0 +1,132 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * (C) Copyright 2019
> + * Heiko Schocher, DENX Software Engineering, h...@denx.de.
> + *
> + */
> +#include
> +#include
> +#include
> +#include
> +
> +struct mpc85xx_pci_priv {
> + void __iomem*cfg_addr;
> + void __iomem*cfg_data;
> +};
> +
> +static int mpc85xx_pci_dm_read_config(struct udevice *dev, pci_dev_t bdf,
> + uint offset, ulong *value,
> + enum pci_size_t size)
> +{
> + struct mpc85xx_pci_priv *priv = dev_get_priv(dev);
> + u32 addr;
> +
> + addr = bdf | (offset & 0xfc) | ((offset & 0xf00) << 16) | 0x8000;
> + out_be32(priv->cfg_addr, addr);
> + sync();
> + *value = pci_conv_32_to_size(in_le32(priv->cfg_data), offset, size);
> +
> + return 0;
> +}
> +
> +static int mpc85xx_pci_dm_write_config(struct udevice *dev, pci_dev_t
> bdf,
> +uint offset, ulong value,
> +enu
Re: [U-Boot] [PATCHv3 1/3] dm: pcie_fsl: Convert IS_ENABLED() run-time checking to #ifdef
Hi Bin, Thanks a lot for your review! Thanks, Zhiqiang > -Original Message- > From: Bin Meng > Sent: 2019年8月27日 20:55 > To: Z.q. Hou > Cc: u-boot@lists.denx.de; Prabhakar Kushwaha > > Subject: Re: [PATCHv3 1/3] dm: pcie_fsl: Convert IS_ENABLED() run-time > checking to #ifdef > > On Tue, Aug 27, 2019 at 6:13 PM Z.q. Hou wrote: > > > > From: Hou Zhiqiang > > > > This can avoid build error: > > The macro in brackets of the IS_ENABLED(CONFIG_FOO) is only defined on > > the platforms that select the CONFIG_FOO, while it's not defined on > > platforms that do not select the CONFIG_FOO. > > > > Signed-off-by: Hou Zhiqiang > > --- > > V3: > > - New patch, also fix the build error which the #1 of v2 fixed. > > > > drivers/pci/pcie_fsl.c | 69 > > ++ > > 1 file changed, 36 insertions(+), 33 deletions(-) > > > > Reviewed-by: Bin Meng ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCHv2 42/47] powerpc: MPC8548CDS: Compile legacy PCIe routines conditionally
From: Hou Zhiqiang
Compile the legacy PCIe initialization reoutines only when
DM_PCI is not enabled.
Signed-off-by: Hou Zhiqiang
Reviewed-by: Bin Meng
---
V2:
- Rebased the patch.
board/freescale/mpc8548cds/mpc8548cds.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/board/freescale/mpc8548cds/mpc8548cds.c
b/board/freescale/mpc8548cds/mpc8548cds.c
index 7d819d8df5..2799b5b5a4 100644
--- a/board/freescale/mpc8548cds/mpc8548cds.c
+++ b/board/freescale/mpc8548cds/mpc8548cds.c
@@ -164,7 +164,7 @@ void lbc_sdram_init(void)
#endif /* enable SDRAM init */
}
-#if defined(CONFIG_PCI) || defined(CONFIG_PCI1)
+#if (defined(CONFIG_PCI) || defined(CONFIG_PCI1)) && !defined(CONFIG_DM_PCI)
/* For some reason the Tundra PCI bridge shows up on itself as a
* different device. Work around that by refusing to configure it.
*/
@@ -189,6 +189,7 @@ static struct pci_config_table
pci_mpc85xxcds_config_table[] = {
static struct pci_controller pci1_hose;
#endif /* CONFIG_PCI */
+#if !defined(CONFIG_DM_PCI)
void pci_init_board(void)
{
volatile ccsr_gur_t *gur = (void *)(CONFIG_SYS_MPC85xx_GUTS_ADDR);
@@ -268,6 +269,7 @@ void pci_init_board(void)
fsl_pcie_init_board(first_free_busno);
}
+#endif
void configure_rgmii(void)
{
@@ -349,7 +351,7 @@ int board_eth_init(bd_t *bis)
return pci_eth_init(bis);
}
-#if defined(CONFIG_OF_BOARD_SETUP)
+#if defined(CONFIG_OF_BOARD_SETUP) && !defined(CONFIG_DM_PCI)
void ft_pci_setup(void *blob, bd_t *bd)
{
FT_FSL_PCI_SETUP;
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCHv2 36/47] dm: pcie_fsl: Add P4080 PCIe support
From: Hou Zhiqiang
Add compatible string for P4080 PCIe.
Signed-off-by: Hou Zhiqiang
Reviewed-by: Bin Meng
---
V2:
- Rebased the patch.
drivers/pci/pcie_fsl.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/pci/pcie_fsl.c b/drivers/pci/pcie_fsl.c
index 9b60492fc5..30fff1ede7 100644
--- a/drivers/pci/pcie_fsl.c
+++ b/drivers/pci/pcie_fsl.c
@@ -632,6 +632,7 @@ static const struct udevice_id fsl_pcie_ids[] = {
{ .compatible = "fsl,pcie-p1_p2", .data = (ulong)_p2_data },
{ .compatible = "fsl,pcie-p2041", .data = (ulong)_data },
{ .compatible = "fsl,pcie-p3041", .data = (ulong)_data },
+ { .compatible = "fsl,pcie-p4080", .data = (ulong)_data },
{ .compatible = "fsl,pcie-t102x", .data = (ulong)_data },
{ .compatible = "fsl,pcie-t104x", .data = (ulong)_data },
{ .compatible = "fsl,pcie-t2080", .data = (ulong)_data },
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCHv2 44/47] dm: pcie_fsl: Add MPC8548 PCIe support
From: Hou Zhiqiang
Add compatible string for MPC8548 PCIe.
Signed-off-by: Hou Zhiqiang
Reviewed-by: Bin Meng
---
V2:
- Rebased the patch.
drivers/pci/pcie_fsl.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/pci/pcie_fsl.c b/drivers/pci/pcie_fsl.c
index 199cec3e9b..ab25aeee73 100644
--- a/drivers/pci/pcie_fsl.c
+++ b/drivers/pci/pcie_fsl.c
@@ -629,6 +629,7 @@ static struct fsl_pcie_data t2080_data = {
};
static const struct udevice_id fsl_pcie_ids[] = {
+ { .compatible = "fsl,pcie-mpc8548", .data = (ulong)_p2_data },
{ .compatible = "fsl,pcie-p1_p2", .data = (ulong)_p2_data },
{ .compatible = "fsl,pcie-p2041", .data = (ulong)_data },
{ .compatible = "fsl,pcie-p3041", .data = (ulong)_data },
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCHv2 27/47] powerpc: p_corenet: Compile legacy PCIe routines conditionally
From: Hou Zhiqiang
Compile the legacy PCIe initialization reoutines for P2041RDB,
P3041, P4080, P5020 and P5040 DS boards only when DM_PCI is
not enabled.
Signed-off-by: Hou Zhiqiang
Reviewed-by: Bin Meng
---
V2:
- Rebased the patch.
board/freescale/common/p_corenet/pci.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/board/freescale/common/p_corenet/pci.c
b/board/freescale/common/p_corenet/pci.c
index a2df928fc5..a6abe66dc0 100644
--- a/board/freescale/common/p_corenet/pci.c
+++ b/board/freescale/common/p_corenet/pci.c
@@ -11,6 +11,7 @@
#include
#include
+#if !defined(CONFIG_DM_PCI)
void pci_init_board(void)
{
fsl_pcie_init_board(0);
@@ -20,3 +21,4 @@ void pci_of_setup(void *blob, bd_t *bd)
{
FT_FSL_PCI_SETUP;
}
+#endif
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCHv2 39/47] dm: pcie_fsl: Add P5040 PCIe support
From: Hou Zhiqiang
Add compatible string for P5040 PCIe.
Signed-off-by: Hou Zhiqiang
Reviewed-by: Bin Meng
---
V2:
- Rebased the patch.
drivers/pci/pcie_fsl.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/pci/pcie_fsl.c b/drivers/pci/pcie_fsl.c
index 30fff1ede7..199cec3e9b 100644
--- a/drivers/pci/pcie_fsl.c
+++ b/drivers/pci/pcie_fsl.c
@@ -633,6 +633,7 @@ static const struct udevice_id fsl_pcie_ids[] = {
{ .compatible = "fsl,pcie-p2041", .data = (ulong)_data },
{ .compatible = "fsl,pcie-p3041", .data = (ulong)_data },
{ .compatible = "fsl,pcie-p4080", .data = (ulong)_data },
+ { .compatible = "fsl,pcie-p5040", .data = (ulong)_data },
{ .compatible = "fsl,pcie-t102x", .data = (ulong)_data },
{ .compatible = "fsl,pcie-t104x", .data = (ulong)_data },
{ .compatible = "fsl,pcie-t2080", .data = (ulong)_data },
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCHv2 28/47] dm: pcie_fsl: Add P2041 PCIe support
From: Hou Zhiqiang
Add compatible string for P2041 PCIe.
Signed-off-by: Hou Zhiqiang
Reviewed-by: Bin Meng
---
V2:
- Rebased the patch.
drivers/pci/pcie_fsl.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/pci/pcie_fsl.c b/drivers/pci/pcie_fsl.c
index 31cb5d25ad..687947ed85 100644
--- a/drivers/pci/pcie_fsl.c
+++ b/drivers/pci/pcie_fsl.c
@@ -616,6 +616,12 @@ static struct fsl_pcie_data p1_p2_data = {
.stride = 0x1000,
};
+static struct fsl_pcie_data p2041_data = {
+ .block_offset = 0x20,
+ .block_offset_mask = 0x3f,
+ .stride = 0x1000,
+};
+
static struct fsl_pcie_data t2080_data = {
.block_offset = 0x24,
.block_offset_mask = 0x3f,
@@ -624,6 +630,7 @@ static struct fsl_pcie_data t2080_data = {
static const struct udevice_id fsl_pcie_ids[] = {
{ .compatible = "fsl,pcie-p1_p2", .data = (ulong)_p2_data },
+ { .compatible = "fsl,pcie-p2041", .data = (ulong)_data },
{ .compatible = "fsl,pcie-t102x", .data = (ulong)_data },
{ .compatible = "fsl,pcie-t104x", .data = (ulong)_data },
{ .compatible = "fsl,pcie-t2080", .data = (ulong)_data },
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCHv2 24/47] configs: P1020RDB: Enable PCIe driver
From: Hou Zhiqiang Enable the DM PCIe driver in P1020RDB defconfig. Signed-off-by: Hou Zhiqiang Reviewed-by: Bin Meng --- V2: - Rebased the patch. configs/P1020RDB-PC_36BIT_NAND_defconfig | 4 configs/P1020RDB-PC_36BIT_SDCARD_defconfig | 4 configs/P1020RDB-PC_36BIT_SPIFLASH_defconfig | 4 configs/P1020RDB-PC_36BIT_defconfig | 4 configs/P1020RDB-PC_NAND_defconfig | 4 configs/P1020RDB-PC_SDCARD_defconfig | 4 configs/P1020RDB-PC_SPIFLASH_defconfig | 4 configs/P1020RDB-PC_defconfig| 4 configs/P1020RDB-PD_NAND_defconfig | 4 configs/P1020RDB-PD_SDCARD_defconfig | 4 configs/P1020RDB-PD_SPIFLASH_defconfig | 4 configs/P1020RDB-PD_defconfig| 4 12 files changed, 48 insertions(+) diff --git a/configs/P1020RDB-PC_36BIT_NAND_defconfig b/configs/P1020RDB-PC_36BIT_NAND_defconfig index 18032abe1f..2dfaaa7b20 100644 --- a/configs/P1020RDB-PC_36BIT_NAND_defconfig +++ b/configs/P1020RDB-PC_36BIT_NAND_defconfig @@ -58,6 +58,10 @@ CONFIG_SPI_FLASH_SPANSION=y CONFIG_PHY_MARVELL=y CONFIG_PHY_GIGE=y CONFIG_E1000=y +CONFIG_DM=y +CONFIG_DM_PCI=y +CONFIG_DM_PCI_COMPAT=y +CONFIG_PCIE_FSL=y CONFIG_MII=y CONFIG_TSEC_ENET=y CONFIG_SYS_NS16550=y diff --git a/configs/P1020RDB-PC_36BIT_SDCARD_defconfig b/configs/P1020RDB-PC_36BIT_SDCARD_defconfig index 1af8a52efb..456b7f5d1f 100644 --- a/configs/P1020RDB-PC_36BIT_SDCARD_defconfig +++ b/configs/P1020RDB-PC_36BIT_SDCARD_defconfig @@ -53,6 +53,10 @@ CONFIG_SPI_FLASH_SPANSION=y CONFIG_PHY_MARVELL=y CONFIG_PHY_GIGE=y CONFIG_E1000=y +CONFIG_DM=y +CONFIG_DM_PCI=y +CONFIG_DM_PCI_COMPAT=y +CONFIG_PCIE_FSL=y CONFIG_MII=y CONFIG_TSEC_ENET=y CONFIG_SYS_NS16550=y diff --git a/configs/P1020RDB-PC_36BIT_SPIFLASH_defconfig b/configs/P1020RDB-PC_36BIT_SPIFLASH_defconfig index cb65399b2e..5e042b3f53 100644 --- a/configs/P1020RDB-PC_36BIT_SPIFLASH_defconfig +++ b/configs/P1020RDB-PC_36BIT_SPIFLASH_defconfig @@ -54,6 +54,10 @@ CONFIG_SPI_FLASH_SPANSION=y CONFIG_PHY_MARVELL=y CONFIG_PHY_GIGE=y CONFIG_E1000=y +CONFIG_DM=y +CONFIG_DM_PCI=y +CONFIG_DM_PCI_COMPAT=y +CONFIG_PCIE_FSL=y CONFIG_MII=y CONFIG_TSEC_ENET=y CONFIG_SYS_NS16550=y diff --git a/configs/P1020RDB-PC_36BIT_defconfig b/configs/P1020RDB-PC_36BIT_defconfig index 7d7c55f28f..fea964dd53 100644 --- a/configs/P1020RDB-PC_36BIT_defconfig +++ b/configs/P1020RDB-PC_36BIT_defconfig @@ -42,6 +42,10 @@ CONFIG_SPI_FLASH_SPANSION=y CONFIG_PHY_MARVELL=y CONFIG_PHY_GIGE=y CONFIG_E1000=y +CONFIG_DM=y +CONFIG_DM_PCI=y +CONFIG_DM_PCI_COMPAT=y +CONFIG_PCIE_FSL=y CONFIG_MII=y CONFIG_TSEC_ENET=y CONFIG_SYS_NS16550=y diff --git a/configs/P1020RDB-PC_NAND_defconfig b/configs/P1020RDB-PC_NAND_defconfig index 521ddaacf1..beeaced122 100644 --- a/configs/P1020RDB-PC_NAND_defconfig +++ b/configs/P1020RDB-PC_NAND_defconfig @@ -57,6 +57,10 @@ CONFIG_SPI_FLASH_SPANSION=y CONFIG_PHY_MARVELL=y CONFIG_PHY_GIGE=y CONFIG_E1000=y +CONFIG_DM=y +CONFIG_DM_PCI=y +CONFIG_DM_PCI_COMPAT=y +CONFIG_PCIE_FSL=y CONFIG_MII=y CONFIG_TSEC_ENET=y CONFIG_SYS_NS16550=y diff --git a/configs/P1020RDB-PC_SDCARD_defconfig b/configs/P1020RDB-PC_SDCARD_defconfig index af5a3377a7..4e1e11df15 100644 --- a/configs/P1020RDB-PC_SDCARD_defconfig +++ b/configs/P1020RDB-PC_SDCARD_defconfig @@ -52,6 +52,10 @@ CONFIG_SPI_FLASH_SPANSION=y CONFIG_PHY_MARVELL=y CONFIG_PHY_GIGE=y CONFIG_E1000=y +CONFIG_DM=y +CONFIG_DM_PCI=y +CONFIG_DM_PCI_COMPAT=y +CONFIG_PCIE_FSL=y CONFIG_MII=y CONFIG_TSEC_ENET=y CONFIG_SYS_NS16550=y diff --git a/configs/P1020RDB-PC_SPIFLASH_defconfig b/configs/P1020RDB-PC_SPIFLASH_defconfig index f7a7ec4c20..6f48aa477d 100644 --- a/configs/P1020RDB-PC_SPIFLASH_defconfig +++ b/configs/P1020RDB-PC_SPIFLASH_defconfig @@ -53,6 +53,10 @@ CONFIG_SPI_FLASH_SPANSION=y CONFIG_PHY_MARVELL=y CONFIG_PHY_GIGE=y CONFIG_E1000=y +CONFIG_DM=y +CONFIG_DM_PCI=y +CONFIG_DM_PCI_COMPAT=y +CONFIG_PCIE_FSL=y CONFIG_MII=y CONFIG_TSEC_ENET=y CONFIG_SYS_NS16550=y diff --git a/configs/P1020RDB-PC_defconfig b/configs/P1020RDB-PC_defconfig index 595ff5fa2b..0a6f9742a8 100644 --- a/configs/P1020RDB-PC_defconfig +++ b/configs/P1020RDB-PC_defconfig @@ -41,6 +41,10 @@ CONFIG_SPI_FLASH_SPANSION=y CONFIG_PHY_MARVELL=y CONFIG_PHY_GIGE=y CONFIG_E1000=y +CONFIG_DM=y +CONFIG_DM_PCI=y +CONFIG_DM_PCI_COMPAT=y +CONFIG_PCIE_FSL=y CONFIG_MII=y CONFIG_TSEC_ENET=y CONFIG_SYS_NS16550=y diff --git a/configs/P1020RDB-PD_NAND_defconfig b/configs/P1020RDB-PD_NAND_defconfig index 5e60d18b36..9f7e1ef3db 100644 --- a/configs/P1020RDB-PD_NAND_defconfig +++ b/configs/P1020RDB-PD_NAND_defconfig @@ -61,6 +61,10 @@ CONFIG_SPI_FLASH_SPANSION=y CONFIG_PHY_MARVELL=y CONFIG_PHY_GIGE=y CONFIG_E1000=y +CONFIG_DM=y +CONFIG_DM_PCI=y +CONFIG_DM_PCI_COMPAT=y +CONFIG_PCIE_FSL=y CONFIG_MII=y CONFIG_TSEC_ENET=y CONFIG_SYS_NS16550=y diff --git a/configs/P1020RDB-PD_SDCARD_defconfig b/configs/P1020RDB-PD_SDCARD_defconfig index
[U-Boot] [PATCHv2 45/47] MPC8548: dts: Added PCIe DT node
From: Hou Zhiqiang
MPC8548 integrated a PCIe controllers, which is compatible with
the PCI Express™ Base Specification, Revision 1.0a, and this
patch is to add DT node for the PCIe controller.
Signed-off-by: Hou Zhiqiang
Reviewed-by: Bin Meng
---
V2:
- Rebased the patch.
arch/powerpc/dts/mpc8548-post.dtsi | 9 +
arch/powerpc/dts/mpc8548cds.dts | 6 ++
arch/powerpc/dts/mpc8548cds_36b.dts | 6 ++
3 files changed, 21 insertions(+)
diff --git a/arch/powerpc/dts/mpc8548-post.dtsi
b/arch/powerpc/dts/mpc8548-post.dtsi
index 5533a4b598..2206f2da9f 100644
--- a/arch/powerpc/dts/mpc8548-post.dtsi
+++ b/arch/powerpc/dts/mpc8548-post.dtsi
@@ -25,3 +25,12 @@
last-interrupt-source = <255>;
};
};
+
+ {
+ compatible = "fsl,pcie-mpc8548", "fsl,pcie-fsl-qoriq";
+ law_trgt_if = <2>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ device_type = "pci";
+ bus-range = <0x0 0xff>;
+};
diff --git a/arch/powerpc/dts/mpc8548cds.dts b/arch/powerpc/dts/mpc8548cds.dts
index cceea345c8..3b927bd265 100644
--- a/arch/powerpc/dts/mpc8548cds.dts
+++ b/arch/powerpc/dts/mpc8548cds.dts
@@ -18,6 +18,12 @@
soc: soc8548@e000 {
ranges = <0x0 0x0 0xe000 0x10>;
};
+
+ pcie: pcie@e000a000 {
+ reg = <0x0 0xe000a000 0x0 0x1000>; /* registers */
+ ranges = <0x0100 0x0 0x 0x0 0xe300 0x0
0x0010 /* downstream I/O */
+ 0x0200 0x0 0xa000 0x0 0xa000 0x0
0x2000>; /* non-prefetchable memory */
+ };
};
/include/ "mpc8548-post.dtsi"
diff --git a/arch/powerpc/dts/mpc8548cds_36b.dts
b/arch/powerpc/dts/mpc8548cds_36b.dts
index faff35cc36..98d7c2410b 100644
--- a/arch/powerpc/dts/mpc8548cds_36b.dts
+++ b/arch/powerpc/dts/mpc8548cds_36b.dts
@@ -18,6 +18,12 @@
soc: soc8548@fe000 {
ranges = <0x0 0xf 0xe000 0x10>;
};
+
+ pcie: pcie@fe000a000 {
+ reg = <0xf 0xe000a000 0x0 0x1000>; /* registers */
+ ranges = <0x0100 0x0 0x 0xf 0xe300 0x0
0x0010 /* downstream I/O */
+ 0x0200 0x0 0xe000 0xc 0x2000 0x0
0x2000>; /* non-prefetchable memory */
+ };
};
/include/ "mpc8548-post.dtsi"
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCHv2 37/47] P4080: dts: Added PCIe DT nodes
From: Hou Zhiqiang
P4080 integrated 3 PCIe controllers, which is compatible with
the PCI Express™ Base Specification, Revision 2.0, and this
patch is to add DT node for each PCIe controller.
Signed-off-by: Hou Zhiqiang
Reviewed-by: Bin Meng
---
V2:
- Rebased the patch.
arch/powerpc/dts/p4080.dtsi | 36
1 file changed, 36 insertions(+)
diff --git a/arch/powerpc/dts/p4080.dtsi b/arch/powerpc/dts/p4080.dtsi
index 7c8dbae442..ab766803a3 100644
--- a/arch/powerpc/dts/p4080.dtsi
+++ b/arch/powerpc/dts/p4080.dtsi
@@ -80,4 +80,40 @@
clock-frequency = <0x0>;
};
};
+
+ pcie@ffe20 {
+ compatible = "fsl,pcie-p4080", "fsl,pcie-fsl-qoriq";
+ reg = <0xf 0xfe20 0x0 0x1000>; /* registers */
+ law_trgt_if = <0>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ device_type = "pci";
+ bus-range = <0x0 0xff>;
+ ranges = <0x0100 0x0 0x 0xf 0xf800 0x0
0x0001 /* downstream I/O */
+ 0x0200 0x0 0xe000 0xc 0x 0x0
0x2000>; /* non-prefetchable memory */
+ };
+
+ pcie@ffe201000 {
+ compatible = "fsl,pcie-p4080", "fsl,pcie-fsl-qoriq";
+ reg = <0xf 0xfe201000 0x0 0x1000>; /* registers */
+ law_trgt_if = <1>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ device_type = "pci";
+ bus-range = <0x0 0xff>;
+ ranges = <0x0100 0x0 0x 0xf 0xf801 0x0
0x0001 /* downstream I/O */
+ 0x0200 0x0 0xe000 0xc 0x2000 0x0
0x2000>; /* non-prefetchable memory */
+ };
+
+ pcie@ffe202000 {
+ compatible = "fsl,pcie-p4080", "fsl,pcie-fsl-qoriq";
+ reg = <0xf 0xfe202000 0x0 0x1000>; /* registers */
+ law_trgt_if = <2>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ device_type = "pci";
+ bus-range = <0x0 0xff>;
+ ranges = <0x0100 0x0 0x 0xf 0xf802 0x0
0x0001 /* downstream I/O */
+ 0x0200 0x0 0xe000 0xc 0x4000 0x0
0x2000>; /* non-prefetchable memory */
+ };
};
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCHv2 35/47] configs: P3041DS: Enable PCIe driver
From: Hou Zhiqiang Enable the DM PCIe driver in P3041DS defconfig. Signed-off-by: Hou Zhiqiang Reviewed-by: Bin Meng --- V2: - Rebased the patch. configs/P3041DS_NAND_defconfig | 4 configs/P3041DS_SDCARD_defconfig | 4 configs/P3041DS_SPIFLASH_defconfig | 4 configs/P3041DS_defconfig | 4 4 files changed, 16 insertions(+) diff --git a/configs/P3041DS_NAND_defconfig b/configs/P3041DS_NAND_defconfig index d98feba522..2d50daad5f 100644 --- a/configs/P3041DS_NAND_defconfig +++ b/configs/P3041DS_NAND_defconfig @@ -41,6 +41,10 @@ CONFIG_SPI_FLASH_SPANSION=y CONFIG_PHYLIB=y CONFIG_PHY_GIGE=y CONFIG_E1000=y +CONFIG_DM=y +CONFIG_DM_PCI=y +CONFIG_DM_PCI_COMPAT=y +CONFIG_PCIE_FSL=y CONFIG_FMAN_ENET=y CONFIG_MII=y CONFIG_SYS_QE_FMAN_FW_IN_NAND=y diff --git a/configs/P3041DS_SDCARD_defconfig b/configs/P3041DS_SDCARD_defconfig index 7be9d882cd..b2dde80714 100644 --- a/configs/P3041DS_SDCARD_defconfig +++ b/configs/P3041DS_SDCARD_defconfig @@ -40,6 +40,10 @@ CONFIG_SPI_FLASH_SPANSION=y CONFIG_PHYLIB=y CONFIG_PHY_GIGE=y CONFIG_E1000=y +CONFIG_DM=y +CONFIG_DM_PCI=y +CONFIG_DM_PCI_COMPAT=y +CONFIG_PCIE_FSL=y CONFIG_FMAN_ENET=y CONFIG_MII=y CONFIG_SYS_QE_FMAN_FW_IN_MMC=y diff --git a/configs/P3041DS_SPIFLASH_defconfig b/configs/P3041DS_SPIFLASH_defconfig index 8d3eb0e449..602112c6ee 100644 --- a/configs/P3041DS_SPIFLASH_defconfig +++ b/configs/P3041DS_SPIFLASH_defconfig @@ -40,6 +40,10 @@ CONFIG_SPI_FLASH_SPANSION=y CONFIG_PHYLIB=y CONFIG_PHY_GIGE=y CONFIG_E1000=y +CONFIG_DM=y +CONFIG_DM_PCI=y +CONFIG_DM_PCI_COMPAT=y +CONFIG_PCIE_FSL=y CONFIG_FMAN_ENET=y CONFIG_MII=y CONFIG_SYS_QE_FMAN_FW_IN_SPIFLASH=y diff --git a/configs/P3041DS_defconfig b/configs/P3041DS_defconfig index 863a587d72..790807272d 100644 --- a/configs/P3041DS_defconfig +++ b/configs/P3041DS_defconfig @@ -39,6 +39,10 @@ CONFIG_SPI_FLASH_SPANSION=y CONFIG_PHYLIB=y CONFIG_PHY_GIGE=y CONFIG_E1000=y +CONFIG_DM=y +CONFIG_DM_PCI=y +CONFIG_DM_PCI_COMPAT=y +CONFIG_PCIE_FSL=y CONFIG_FMAN_ENET=y CONFIG_MII=y CONFIG_SYS_QE_FMAN_FW_IN_NOR=y -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCHv2 46/47] powerpc: MPC8548CDS: Disable legacy PCIe driver when DM_PCI is enabled
From: Hou Zhiqiang Disable legacy PCIe driver and unused PCIe macros when DM_PCI enabled. Signed-off-by: Hou Zhiqiang Reviewed-by: Bin Meng --- V2: - Rebased the patch. include/configs/MPC8548CDS.h | 22 ++ 1 file changed, 14 insertions(+), 8 deletions(-) diff --git a/include/configs/MPC8548CDS.h b/include/configs/MPC8548CDS.h index 4252fbeef9..4809bbdfa3 100644 --- a/include/configs/MPC8548CDS.h +++ b/include/configs/MPC8548CDS.h @@ -18,8 +18,6 @@ #define CONFIG_PCI1/* PCI controller 1 */ #define CONFIG_PCIE1 /* PCIE controller 1 (slot 1) */ #undef CONFIG_PCI2 -#define CONFIG_FSL_PCI_INIT1 /* Use common FSL init code */ -#define CONFIG_PCI_INDIRECT_BRIDGE 1 /* indirect PCI bridge support */ #define CONFIG_SYS_PCI_64BIT 1 /* enable 64-bit PCI resources */ #define CONFIG_ENV_OVERWRITE @@ -343,24 +341,18 @@ extern unsigned long get_clock_freq(void); #define CONFIG_SYS_PCI1_IO_SIZE0x0010 /* 1M */ #ifdef CONFIG_PCIE1 -#define CONFIG_SYS_PCIE1_NAME "Slot" #define CONFIG_SYS_PCIE1_MEM_VIRT 0xa000 #ifdef CONFIG_PHYS_64BIT -#define CONFIG_SYS_PCIE1_MEM_BUS 0xe000 #define CONFIG_SYS_PCIE1_MEM_PHYS 0xc2000ull #else -#define CONFIG_SYS_PCIE1_MEM_BUS 0xa000 #define CONFIG_SYS_PCIE1_MEM_PHYS 0xa000 #endif -#define CONFIG_SYS_PCIE1_MEM_SIZE 0x2000 /* 512M */ #define CONFIG_SYS_PCIE1_IO_VIRT 0xe300 -#define CONFIG_SYS_PCIE1_IO_BUS0x #ifdef CONFIG_PHYS_64BIT #define CONFIG_SYS_PCIE1_IO_PHYS0xfe300ull #else #define CONFIG_SYS_PCIE1_IO_PHYS 0xe300 #endif -#define CONFIG_SYS_PCIE1_IO_SIZE 0x0010 /* 1M */ #endif /* @@ -386,6 +378,20 @@ extern unsigned long get_clock_freq(void); #undef CONFIG_EEPRO100 #undef CONFIG_TULIP +#if !defined(CONFIG_DM_PCI) +#define CONFIG_FSL_PCI_INIT1 /* Use common FSL init code */ +#define CONFIG_PCI_INDIRECT_BRIDGE 1 +#define CONFIG_SYS_PCIE1_NAME "Slot" +#ifdef CONFIG_PHYS_64BIT +#define CONFIG_SYS_PCIE1_MEM_BUS 0xe000 +#else +#define CONFIG_SYS_PCIE1_MEM_BUS 0xa000 +#endif +#define CONFIG_SYS_PCIE1_MEM_SIZE 0x2000 /* 512M */ +#define CONFIG_SYS_PCIE1_IO_BUS0x +#define CONFIG_SYS_PCIE1_IO_SIZE 0x0010 /* 1M */ +#endif + #define CONFIG_PCI_SCAN_SHOW /* show pci devices on startup */ #endif /* CONFIG_PCI */ -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCHv2 11/47] t102x: dts: Added PCIe DT nodes
From: Hou Zhiqiang
T102x integrated 3 PCIe controllers, which is compatible with
the PCI Express™ Base Specification, Revision 2.0, and this
patch is to add DT node for each PCIe controller.
Signed-off-by: Hou Zhiqiang
Reviewed-by: Bin Meng
---
V2:
- Rebased the patch.
arch/powerpc/dts/t102x.dtsi | 36
1 file changed, 36 insertions(+)
diff --git a/arch/powerpc/dts/t102x.dtsi b/arch/powerpc/dts/t102x.dtsi
index 2393e316f8..c49fd21088 100644
--- a/arch/powerpc/dts/t102x.dtsi
+++ b/arch/powerpc/dts/t102x.dtsi
@@ -49,4 +49,40 @@
clock-frequency = <0x0>;
};
};
+
+ pcie@ffe24 {
+ compatible = "fsl,pcie-t102x", "fsl,pcie-fsl-qoriq";
+ reg = <0xf 0xfe24 0x0 0x1000>; /* registers */
+ law_trgt_if = <0>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ device_type = "pci";
+ bus-range = <0x0 0xff>;
+ ranges = <0x0100 0x0 0x 0xf 0xf800 0x0
0x0001 /* downstream I/O */
+ 0x0200 0x0 0xe000 0xc 0x 0x0
0x1000>; /* non-prefetchable memory */
+ };
+
+ pcie@ffe25 {
+ compatible = "fsl,pcie-t102x", "fsl,pcie-fsl-qoriq";
+ reg = <0xf 0xfe25 0x0 0x1000>; /* registers */
+ law_trgt_if = <1>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ device_type = "pci";
+ bus-range = <0x0 0xff>;
+ ranges = <0x0100 0x0 0x 0xf 0xf801 0x0
0x0001 /* downstream I/O */
+ 0x0200 0x0 0xe000 0xc 0x1000 0x0
0x1000>; /* non-prefetchable memory */
+ };
+
+ pcie@ffe26 {
+ compatible = "fsl,pcie-t102x", "fsl,pcie-fsl-qoriq";
+ reg = <0xf 0xfe26 0x0 0x1000>; /* registers */
+ law_trgt_if = <2>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ device_type = "pci";
+ bus-range = <0x0 0xff>;
+ ranges = <0x0100 0x0 0x 0xf 0xf802 0x0
0x0001 /* downstream I/O */
+ 0x0200 0x0 0xe000 0xc 0x2000 0x0
0x1000>; /* non-prefetchable memory */
+ };
};
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCHv2 26/47] configs: P2020RDB: Enable PCIe driver
From: Hou Zhiqiang Enable the DM PCIe driver in P2020RDB defconfig. Signed-off-by: Hou Zhiqiang Reviewed-by: Bin Meng --- V2: - Rebased the patch. configs/P2020RDB-PC_36BIT_NAND_defconfig | 4 configs/P2020RDB-PC_36BIT_SDCARD_defconfig | 4 configs/P2020RDB-PC_36BIT_SPIFLASH_defconfig | 4 configs/P2020RDB-PC_36BIT_defconfig | 4 configs/P2020RDB-PC_NAND_defconfig | 4 configs/P2020RDB-PC_SDCARD_defconfig | 4 configs/P2020RDB-PC_SPIFLASH_defconfig | 4 configs/P2020RDB-PC_defconfig| 4 8 files changed, 32 insertions(+) diff --git a/configs/P2020RDB-PC_36BIT_NAND_defconfig b/configs/P2020RDB-PC_36BIT_NAND_defconfig index c392298616..6c50b28410 100644 --- a/configs/P2020RDB-PC_36BIT_NAND_defconfig +++ b/configs/P2020RDB-PC_36BIT_NAND_defconfig @@ -63,6 +63,10 @@ CONFIG_SPI_FLASH_SPANSION=y CONFIG_PHY_MARVELL=y CONFIG_PHY_GIGE=y CONFIG_E1000=y +CONFIG_DM=y +CONFIG_DM_PCI=y +CONFIG_DM_PCI_COMPAT=y +CONFIG_PCIE_FSL=y CONFIG_MII=y CONFIG_TSEC_ENET=y CONFIG_SYS_NS16550=y diff --git a/configs/P2020RDB-PC_36BIT_SDCARD_defconfig b/configs/P2020RDB-PC_36BIT_SDCARD_defconfig index 4977016698..4ecc7a5c00 100644 --- a/configs/P2020RDB-PC_36BIT_SDCARD_defconfig +++ b/configs/P2020RDB-PC_36BIT_SDCARD_defconfig @@ -58,6 +58,10 @@ CONFIG_SPI_FLASH_SPANSION=y CONFIG_PHY_MARVELL=y CONFIG_PHY_GIGE=y CONFIG_E1000=y +CONFIG_DM=y +CONFIG_DM_PCI=y +CONFIG_DM_PCI_COMPAT=y +CONFIG_PCIE_FSL=y CONFIG_MII=y CONFIG_TSEC_ENET=y CONFIG_SYS_NS16550=y diff --git a/configs/P2020RDB-PC_36BIT_SPIFLASH_defconfig b/configs/P2020RDB-PC_36BIT_SPIFLASH_defconfig index d5e176a9af..e35f250aac 100644 --- a/configs/P2020RDB-PC_36BIT_SPIFLASH_defconfig +++ b/configs/P2020RDB-PC_36BIT_SPIFLASH_defconfig @@ -59,6 +59,10 @@ CONFIG_SPI_FLASH_SPANSION=y CONFIG_PHY_MARVELL=y CONFIG_PHY_GIGE=y CONFIG_E1000=y +CONFIG_DM=y +CONFIG_DM_PCI=y +CONFIG_DM_PCI_COMPAT=y +CONFIG_PCIE_FSL=y CONFIG_MII=y CONFIG_TSEC_ENET=y CONFIG_SYS_NS16550=y diff --git a/configs/P2020RDB-PC_36BIT_defconfig b/configs/P2020RDB-PC_36BIT_defconfig index 79f4f3c9ac..bb5c6bdb2d 100644 --- a/configs/P2020RDB-PC_36BIT_defconfig +++ b/configs/P2020RDB-PC_36BIT_defconfig @@ -47,6 +47,10 @@ CONFIG_SPI_FLASH_SPANSION=y CONFIG_PHY_MARVELL=y CONFIG_PHY_GIGE=y CONFIG_E1000=y +CONFIG_DM=y +CONFIG_DM_PCI=y +CONFIG_DM_PCI_COMPAT=y +CONFIG_PCIE_FSL=y CONFIG_MII=y CONFIG_TSEC_ENET=y CONFIG_SYS_NS16550=y diff --git a/configs/P2020RDB-PC_NAND_defconfig b/configs/P2020RDB-PC_NAND_defconfig index 5d4e9ea4df..6640e7e593 100644 --- a/configs/P2020RDB-PC_NAND_defconfig +++ b/configs/P2020RDB-PC_NAND_defconfig @@ -62,6 +62,10 @@ CONFIG_SPI_FLASH_SPANSION=y CONFIG_PHY_MARVELL=y CONFIG_PHY_GIGE=y CONFIG_E1000=y +CONFIG_DM=y +CONFIG_DM_PCI=y +CONFIG_DM_PCI_COMPAT=y +CONFIG_PCIE_FSL=y CONFIG_MII=y CONFIG_TSEC_ENET=y CONFIG_SYS_NS16550=y diff --git a/configs/P2020RDB-PC_SDCARD_defconfig b/configs/P2020RDB-PC_SDCARD_defconfig index b92ce2fc0a..898fc52330 100644 --- a/configs/P2020RDB-PC_SDCARD_defconfig +++ b/configs/P2020RDB-PC_SDCARD_defconfig @@ -57,6 +57,10 @@ CONFIG_SPI_FLASH_SPANSION=y CONFIG_PHY_MARVELL=y CONFIG_PHY_GIGE=y CONFIG_E1000=y +CONFIG_DM=y +CONFIG_DM_PCI=y +CONFIG_DM_PCI_COMPAT=y +CONFIG_PCIE_FSL=y CONFIG_MII=y CONFIG_TSEC_ENET=y CONFIG_SYS_NS16550=y diff --git a/configs/P2020RDB-PC_SPIFLASH_defconfig b/configs/P2020RDB-PC_SPIFLASH_defconfig index f80374fbae..ec23385b67 100644 --- a/configs/P2020RDB-PC_SPIFLASH_defconfig +++ b/configs/P2020RDB-PC_SPIFLASH_defconfig @@ -58,6 +58,10 @@ CONFIG_SPI_FLASH_SPANSION=y CONFIG_PHY_MARVELL=y CONFIG_PHY_GIGE=y CONFIG_E1000=y +CONFIG_DM=y +CONFIG_DM_PCI=y +CONFIG_DM_PCI_COMPAT=y +CONFIG_PCIE_FSL=y CONFIG_MII=y CONFIG_TSEC_ENET=y CONFIG_SYS_NS16550=y diff --git a/configs/P2020RDB-PC_defconfig b/configs/P2020RDB-PC_defconfig index 40004597d1..b94c67e51f 100644 --- a/configs/P2020RDB-PC_defconfig +++ b/configs/P2020RDB-PC_defconfig @@ -46,6 +46,10 @@ CONFIG_SPI_FLASH_SPANSION=y CONFIG_PHY_MARVELL=y CONFIG_PHY_GIGE=y CONFIG_E1000=y +CONFIG_DM=y +CONFIG_DM_PCI=y +CONFIG_DM_PCI_COMPAT=y +CONFIG_PCIE_FSL=y CONFIG_MII=y CONFIG_TSEC_ENET=y CONFIG_SYS_NS16550=y -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCHv2 30/47] powerpc: P2041RDB: Disable legacy PCIe driver when DM_PCI is enabled
From: Hou Zhiqiang Disable legacy PCIe driver and unused PCIe macros when DM_PCI enabled. Signed-off-by: Hou Zhiqiang Reviewed-by: Bin Meng --- V2: - Rebased the patch. include/configs/P2041RDB.h | 55 +++--- 1 file changed, 15 insertions(+), 40 deletions(-) diff --git a/include/configs/P2041RDB.h b/include/configs/P2041RDB.h index e196f3ce33..f8cfef7b2d 100644 --- a/include/configs/P2041RDB.h +++ b/include/configs/P2041RDB.h @@ -37,7 +37,6 @@ #define CONFIG_PCIE1 /* PCIE controller 1 */ #define CONFIG_PCIE2 /* PCIE controller 2 */ #define CONFIG_PCIE3 /* PCIE controller 3 */ -#define CONFIG_FSL_PCI_INIT/* Use common FSL init code */ #define CONFIG_SYS_PCI_64BIT /* enable 64-bit PCI resources */ #define CONFIG_SYS_SRIO @@ -354,60 +353,21 @@ unsigned long get_board_sys_clk(unsigned long dummy); /* controller 1, direct to uli, tgtid 3, Base address 2 */ #define CONFIG_SYS_PCIE1_MEM_VIRT 0x8000 -#ifdef CONFIG_PHYS_64BIT -#define CONFIG_SYS_PCIE1_MEM_BUS 0xe000 #define CONFIG_SYS_PCIE1_MEM_PHYS 0xcull -#else -#define CONFIG_SYS_PCIE1_MEM_BUS 0x8000 -#define CONFIG_SYS_PCIE1_MEM_PHYS 0x8000 -#endif -#define CONFIG_SYS_PCIE1_MEM_SIZE 0x2000 /* 512M */ #define CONFIG_SYS_PCIE1_IO_VIRT 0xf800 -#define CONFIG_SYS_PCIE1_IO_BUS0x -#ifdef CONFIG_PHYS_64BIT #define CONFIG_SYS_PCIE1_IO_PHYS 0xff800ull -#else -#define CONFIG_SYS_PCIE1_IO_PHYS 0xf800 -#endif -#define CONFIG_SYS_PCIE1_IO_SIZE 0x0001 /* 64k */ /* controller 2, Slot 2, tgtid 2, Base address 201000 */ #define CONFIG_SYS_PCIE2_MEM_VIRT 0xa000 -#ifdef CONFIG_PHYS_64BIT -#define CONFIG_SYS_PCIE2_MEM_BUS 0xe000 #define CONFIG_SYS_PCIE2_MEM_PHYS 0xc2000ull -#else -#define CONFIG_SYS_PCIE2_MEM_BUS 0xa000 -#define CONFIG_SYS_PCIE2_MEM_PHYS 0xa000 -#endif -#define CONFIG_SYS_PCIE2_MEM_SIZE 0x2000 /* 512M */ #define CONFIG_SYS_PCIE2_IO_VIRT 0xf801 -#define CONFIG_SYS_PCIE2_IO_BUS0x -#ifdef CONFIG_PHYS_64BIT #define CONFIG_SYS_PCIE2_IO_PHYS 0xff801ull -#else -#define CONFIG_SYS_PCIE2_IO_PHYS 0xf801 -#endif -#define CONFIG_SYS_PCIE2_IO_SIZE 0x0001 /* 64k */ /* controller 3, Slot 1, tgtid 1, Base address 202000 */ #define CONFIG_SYS_PCIE3_MEM_VIRT 0xc000 -#ifdef CONFIG_PHYS_64BIT -#define CONFIG_SYS_PCIE3_MEM_BUS 0xe000 #define CONFIG_SYS_PCIE3_MEM_PHYS 0xc4000ull -#else -#define CONFIG_SYS_PCIE3_MEM_BUS 0xc000 -#define CONFIG_SYS_PCIE3_MEM_PHYS 0xc000 -#endif -#define CONFIG_SYS_PCIE3_MEM_SIZE 0x2000 /* 512M */ #define CONFIG_SYS_PCIE3_IO_VIRT 0xf802 -#define CONFIG_SYS_PCIE3_IO_BUS0x -#ifdef CONFIG_PHYS_64BIT #define CONFIG_SYS_PCIE3_IO_PHYS 0xff802ull -#else -#define CONFIG_SYS_PCIE3_IO_PHYS 0xf802 -#endif -#define CONFIG_SYS_PCIE3_IO_SIZE 0x0001 /* 64k */ /* Qman/Bman */ #define CONFIG_SYS_BMAN_NUM_PORTALS10 @@ -483,7 +443,22 @@ unsigned long get_board_sys_clk(unsigned long dummy); #endif #ifdef CONFIG_PCI +#if !defined(CONFIG_DM_PCI) +#define CONFIG_FSL_PCI_INIT/* Use common FSL init code */ #define CONFIG_PCI_INDIRECT_BRIDGE +#define CONFIG_SYS_PCIE1_MEM_BUS 0xe000 +#define CONFIG_SYS_PCIE1_MEM_SIZE 0x2000 /* 512M */ +#define CONFIG_SYS_PCIE1_IO_BUS0x +#define CONFIG_SYS_PCIE1_IO_SIZE 0x0001 /* 64k */ +#define CONFIG_SYS_PCIE2_MEM_BUS 0xe000 +#define CONFIG_SYS_PCIE2_MEM_SIZE 0x2000 /* 512M */ +#define CONFIG_SYS_PCIE2_IO_BUS0x +#define CONFIG_SYS_PCIE2_IO_SIZE 0x0001 /* 64k */ +#define CONFIG_SYS_PCIE3_MEM_BUS 0xe000 +#define CONFIG_SYS_PCIE3_MEM_SIZE 0x2000 /* 512M */ +#define CONFIG_SYS_PCIE3_IO_BUS0x +#define CONFIG_SYS_PCIE3_IO_SIZE 0x0001 /* 64k */ +#endif #define CONFIG_PCI_SCAN_SHOW /* show pci devices on startup */ #endif /* CONFIG_PCI */ -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCHv2 41/47] configs: P5040DS: Enable PCIe driver
From: Hou Zhiqiang Enable the DM PCIe driver in P5040DS defconfig. Signed-off-by: Hou Zhiqiang Reviewed-by: Bin Meng --- V2: - Rebased the patch. configs/P5040DS_NAND_defconfig | 4 configs/P5040DS_SDCARD_defconfig | 4 configs/P5040DS_SPIFLASH_defconfig | 4 configs/P5040DS_defconfig | 4 4 files changed, 16 insertions(+) diff --git a/configs/P5040DS_NAND_defconfig b/configs/P5040DS_NAND_defconfig index b6e92036bd..64652900ed 100644 --- a/configs/P5040DS_NAND_defconfig +++ b/configs/P5040DS_NAND_defconfig @@ -42,6 +42,10 @@ CONFIG_SPI_FLASH_SPANSION=y CONFIG_PHYLIB=y CONFIG_PHY_GIGE=y CONFIG_E1000=y +CONFIG_DM=y +CONFIG_DM_PCI=y +CONFIG_DM_PCI_COMPAT=y +CONFIG_PCIE_FSL=y CONFIG_FMAN_ENET=y CONFIG_MII=y CONFIG_SYS_QE_FMAN_FW_IN_NAND=y diff --git a/configs/P5040DS_SDCARD_defconfig b/configs/P5040DS_SDCARD_defconfig index a81cea4817..e31d3e48f7 100644 --- a/configs/P5040DS_SDCARD_defconfig +++ b/configs/P5040DS_SDCARD_defconfig @@ -41,6 +41,10 @@ CONFIG_SPI_FLASH_SPANSION=y CONFIG_PHYLIB=y CONFIG_PHY_GIGE=y CONFIG_E1000=y +CONFIG_DM=y +CONFIG_DM_PCI=y +CONFIG_DM_PCI_COMPAT=y +CONFIG_PCIE_FSL=y CONFIG_FMAN_ENET=y CONFIG_MII=y CONFIG_SYS_QE_FMAN_FW_IN_MMC=y diff --git a/configs/P5040DS_SPIFLASH_defconfig b/configs/P5040DS_SPIFLASH_defconfig index 068a6f45d8..37d7b00bc4 100644 --- a/configs/P5040DS_SPIFLASH_defconfig +++ b/configs/P5040DS_SPIFLASH_defconfig @@ -41,6 +41,10 @@ CONFIG_SPI_FLASH_SPANSION=y CONFIG_PHYLIB=y CONFIG_PHY_GIGE=y CONFIG_E1000=y +CONFIG_DM=y +CONFIG_DM_PCI=y +CONFIG_DM_PCI_COMPAT=y +CONFIG_PCIE_FSL=y CONFIG_FMAN_ENET=y CONFIG_MII=y CONFIG_SYS_QE_FMAN_FW_IN_SPIFLASH=y diff --git a/configs/P5040DS_defconfig b/configs/P5040DS_defconfig index 6f9588fffd..111b4d1b83 100644 --- a/configs/P5040DS_defconfig +++ b/configs/P5040DS_defconfig @@ -40,6 +40,10 @@ CONFIG_SPI_FLASH_SPANSION=y CONFIG_PHYLIB=y CONFIG_PHY_GIGE=y CONFIG_E1000=y +CONFIG_DM=y +CONFIG_DM_PCI=y +CONFIG_DM_PCI_COMPAT=y +CONFIG_PCIE_FSL=y CONFIG_FMAN_ENET=y CONFIG_MII=y CONFIG_SYS_QE_FMAN_FW_IN_NOR=y -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCHv2 14/47] configs: T1024RDB: Enable PCIe driver
From: Hou Zhiqiang Enable the DM PCIe driver in T1024RDB defconfig. Signed-off-by: Hou Zhiqiang Reviewed-by: Bin Meng --- V2: - Rebased the patch. configs/T1024RDB_NAND_defconfig | 4 configs/T1024RDB_SDCARD_defconfig | 4 configs/T1024RDB_SPIFLASH_defconfig | 4 configs/T1024RDB_defconfig | 4 4 files changed, 16 insertions(+) diff --git a/configs/T1024RDB_NAND_defconfig b/configs/T1024RDB_NAND_defconfig index e28e5cf8b3..de71aa86a2 100644 --- a/configs/T1024RDB_NAND_defconfig +++ b/configs/T1024RDB_NAND_defconfig @@ -64,6 +64,10 @@ CONFIG_SPI_FLASH_STMICRO=y CONFIG_PHYLIB=y CONFIG_PHY_AQUANTIA=y CONFIG_E1000=y +CONFIG_DM=y +CONFIG_DM_PCI=y +CONFIG_DM_PCI_COMPAT=y +CONFIG_PCIE_FSL=y CONFIG_FMAN_ENET=y CONFIG_MII=y CONFIG_SYS_QE_FMAN_FW_IN_NAND=y diff --git a/configs/T1024RDB_SDCARD_defconfig b/configs/T1024RDB_SDCARD_defconfig index f0ee09c6d4..519819c820 100644 --- a/configs/T1024RDB_SDCARD_defconfig +++ b/configs/T1024RDB_SDCARD_defconfig @@ -61,6 +61,10 @@ CONFIG_SPI_FLASH_STMICRO=y CONFIG_PHYLIB=y CONFIG_PHY_AQUANTIA=y CONFIG_E1000=y +CONFIG_DM=y +CONFIG_DM_PCI=y +CONFIG_DM_PCI_COMPAT=y +CONFIG_PCIE_FSL=y CONFIG_FMAN_ENET=y CONFIG_MII=y CONFIG_SYS_QE_FMAN_FW_IN_MMC=y diff --git a/configs/T1024RDB_SPIFLASH_defconfig b/configs/T1024RDB_SPIFLASH_defconfig index 2905613cd6..85f18058bb 100644 --- a/configs/T1024RDB_SPIFLASH_defconfig +++ b/configs/T1024RDB_SPIFLASH_defconfig @@ -62,6 +62,10 @@ CONFIG_SPI_FLASH_STMICRO=y CONFIG_PHYLIB=y CONFIG_PHY_AQUANTIA=y CONFIG_E1000=y +CONFIG_DM=y +CONFIG_DM_PCI=y +CONFIG_DM_PCI_COMPAT=y +CONFIG_PCIE_FSL=y CONFIG_FMAN_ENET=y CONFIG_MII=y CONFIG_SYS_QE_FMAN_FW_IN_SPIFLASH=y diff --git a/configs/T1024RDB_defconfig b/configs/T1024RDB_defconfig index 3d0219f092..5a9c8bc9da 100644 --- a/configs/T1024RDB_defconfig +++ b/configs/T1024RDB_defconfig @@ -48,6 +48,10 @@ CONFIG_SPI_FLASH_STMICRO=y CONFIG_PHYLIB=y CONFIG_PHY_AQUANTIA=y CONFIG_E1000=y +CONFIG_DM=y +CONFIG_DM_PCI=y +CONFIG_DM_PCI_COMPAT=y +CONFIG_PCIE_FSL=y CONFIG_FMAN_ENET=y CONFIG_MII=y CONFIG_SYS_QE_FMAN_FW_IN_NOR=y -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
