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.
York
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
