[U-Boot] [PATCH 4/7 v4] pci/layerscape: add support for LUT

[Stuart Yoder]

> -----Original Message-----
> From: york sun
> Sent: Tuesday, March 08, 2016 1:46 PM
> To: Stuart Yoder <stuart.yoder at nxp.com>; u-boot at lists.denx.de
> Cc: Prabhakar Kushwaha <prabhakar.kushwaha at nxp.com>; Yang-Leo Li <leoyang.li at 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.yoder at nxp.com>; u-boot at lists.denx.de
> >> Cc: Prabhakar Kushwaha <prabhakar.kushwaha at nxp.com>; Yang-Leo Li <leoyang.li at 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.yoder at 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.yoder at 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