> -----Original Message-----
> From: york sun
> Sent: Tuesday, March 08, 2016 1:46 PM
> 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 11:36 AM, Stuart Yoder wrote:
> >
> >
> >> -----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.
> >
>
> We already have CONFIG_FSL_LSCH3 and CONFIG_FSL_LSCH2 in U-Boot. My concern is
> not the name. If you see your change fits CONFIG_FSL_LSCH3, you can go ahead
> to
> use it. Or if it only applies to CONFIG_LS2080A and CONFIG_LS2085A, you can
> keep
> your change. With aother LSCH3 SoC around the corner, I am trying to save you
> the trouble to fix it when that comes.
Sure, makes sense...I'll change to use the existing CH3 define. I suspect
that the existing references to defined(CONFIG_LS2080A) ||
defined(CONFIG_LS2085A)
should probably change at some point.
Stuart
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
