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

[york sun]

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.

York