> -----Original Message-----
> From: york sun
> Sent: Tuesday, March 08, 2016 11:30 AM
> To: Stuart Yoder <stuart.yo...@nxp.com>; u-boot@lists.denx.de
> Cc: Prabhakar Kushwaha <prabhakar.kushw...@nxp.com>; Yang-Leo Li
> <leoyang...@nxp.com>
> Subject: Re: [PATCH 4/7 v4] pci/layerscape: add support for LUT
>
> On 03/08/2016 07:56 AM, Stuart Yoder wrote:
> > From: Stuart Yoder <stuart.yo...@nxp.com>
> >
> > The per-PCI controller LUT (Look-Up-Table) is a 32-entry table
> > that maps PCI requester IDs (bus/dev/fun) to a stream ID.
> >
> > This patch implements infrastructure to enable LUT initialization:
> > -define registers offsets
> > -add an index to 'struct ls_pcie' to track next available slot in LUT
> > -add function to allocate the next available entry index
> > -add function to program a LUT entry
> >
> > Signed-off-by: Stuart Yoder <stuart.yo...@nxp.com>
> > ---
> > -v4: put new support under LS2 #ifdef
> >
> > .../include/asm/arch-fsl-layerscape/immap_lsch3.h | 4 +++
> > drivers/pci/pcie_layerscape.c | 30
> > ++++++++++++++++++++
> > 2 files changed, 34 insertions(+)
> >
> > diff --git a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
> b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
> > index 91f3ce8..d04e336 100644
> > --- a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
> > +++ b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
> > @@ -86,6 +86,10 @@
> > #define PCIE_LUT_BASE 0x80000
> > #define PCIE_LUT_LCTRL0 0x7F8
> > #define PCIE_LUT_DBG 0x7FC
> > +#define PCIE_LUT_UDR(n) (0x800 + (n) * 8)
> > +#define PCIE_LUT_LDR(n) (0x804 + (n) * 8)
> > +#define PCIE_LUT_ENABLE (1 << 31)
> > +#define PCIE_LUT_ENTRY_COUNT 32
> >
> > /* Device Configuration */
> > #define DCFG_BASE 0x01e00000
> > diff --git a/drivers/pci/pcie_layerscape.c b/drivers/pci/pcie_layerscape.c
> > index bb29222..8435446 100644
> > --- a/drivers/pci/pcie_layerscape.c
> > +++ b/drivers/pci/pcie_layerscape.c
> > @@ -93,6 +93,7 @@ struct ls_pcie {
> > void __iomem *dbi;
> > void __iomem *va_cfg0;
> > void __iomem *va_cfg1;
> > + int next_lut_index;
> > struct pci_controller hose;
> > };
> >
> > @@ -482,6 +483,34 @@ static void ls_pcie_setup_ep(struct ls_pcie *pcie,
> > struct
> ls_pcie_info *info)
> > }
> > }
> >
> > +#if defined(CONFIG_LS2080A) || defined(CONFIG_LS2085A)
>
> Would CONFIG_FSL_LSCH3 serve this purpose better? We will have other SoC in
> the
> same family.
Maybe, I'm open to a common define if we can easily get agreement.
I see at least 7 other references to:
defined(CONFIG_LS2080A) || defined(CONFIG_LS2085A)
I'd rather not see agreement on a common #define get mixed
up in this patch series which is focused on enabling
MSIs. But, perhaps we need to agree on a name and
then clean all the common platform references up.
I'm not sure I like FSL_LSCH3. A while back we changed the
name of a u-boot directory that had "ch3" in it and changed to:
"fsl-layerscape". So, I thought we were moving in the direction
of removing references to "ch3".
In Linux we use CONFIG_ARCH_LAYERSCAPE to refer to the ARMv8
family of SoCs. While LAYERSCAPE is not ideal, it may be
better than CH3 which is a reference to an internal name
that no one outside of NXP will ever understand.
My vote would be CONFIG_LAYERSCAPE.
Stuart
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
