From: Lian Minghuan-B31939 <B31939@freescale.com>
To: Lucas Stach <l.stach@pengutronix.de>
Cc: Srikanth Thokala <sriku.linux@gmail.com>,
Minghuan Lian <Minghuan.Lian@freescale.com>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
Zang Roy-R61911 <r61911@freescale.com>,
Hu Mingkai-B21284 <B21284@freescale.com>,
"Bjorn Helgaas" <bhelgaas@google.com>
Subject: Re: [PATCH v2] PCI: designware: Add support 4 ATUs assignment
Date: Fri, 14 Nov 2014 16:47:25 +0800 [thread overview]
Message-ID: <5465C19D.3060801@freescale.com> (raw)
In-Reply-To: <1415876988.2420.7.camel@pengutronix.de>
Hi Lucas and all,
On 2014年11月13日 19:09, Lucas Stach wrote:
> Am Donnerstag, den 13.11.2014, 18:52 +0800 schrieb Lian Minghuan-B31939:
>> Hi Lucas,
>>
>> On 2014年11月13日 18:20, Lucas Stach wrote:
>>> Am Donnerstag, den 13.11.2014, 18:02 +0800 schrieb Lian Minghuan-B31939:
>>>> Hi Lucas,
>>>>
>>>> Please see my comments inline.
>>>>
>>>> Thanks,
>>>> Minghuan
>>>>
>>>> On 2014年11月13日 00:32, Lucas Stach wrote:
>>>>> Am Mittwoch, den 12.11.2014, 21:53 +0530 schrieb Srikanth Thokala:
>>>>>> Hi Minghuan,
>>> [...]
>>>
>>>>> Using a smaller type complicates the DT for little to no benefit. I
>>>>> think it's ok to use u32 here, which is a common standard for integer
>>>>> values in DT.
>>>>>
>>>>> Though this discussion lead me to the question if we even need to have
>>>>> this property in the DT at all. Isn't this a property that is fixed for
>>>>> a specific silicon implementation of the DW core? In that case we could
>>>>> just infer the number of ATUs from the DT compatible, so this should
>>>>> probably just be added to struct pcie_port and properly initialized by
>>>>> the SoC glue drivers.
>>>> [Minghuan] As far as I know, exynos implements only 2 ATUs, this is why
>>>> pcie-designware only supports 2 ATU. iMX implements 4 ATUs and LS1021A
>>>> implements 6 ATUs.
>>>>
>>> Right so we don't need an additional property in the DT at all. The
>>> number of ATUs is fixed for a specific core compatible and can be passed
>>> in by the respective exynos, imx and ls1021 glue drivers.
>>>
>>> You may ask the Keystone and Spear maintainers to get the correct number
>>> of ATUs for those implementations.
>>>
>>> Regards,
>>> Lucas
>> [Minghuan] Yes. This a way that specific core driver passes the ATU
>> number to
>> pci-designware. But I perfer to adding dts node for the following reasons:
>> 1. ATU number is hardware attribute, so it can be added to DTS.
> But it is a duplication of information that can be inferred from the DT
> compatible alone, which is usually frowned upon.
>
> Also in contrast to the num-lanes property I don't see a use-case to
> reduce the number of used ATUs in a specific system, so num-atus is
> basically fixed for a specific implementation.
[Minghuan] 4ATUs provides better support for multiple-function and
SR-IOV PCIe devices.
Can anyone tell me if there is the company will increase ATUs number?
If yes, we should avoid the following code:
if (of_device_is_compatible(pcie->dev->of_node, "xxx,r1-pcie"))
atu_num = 2;
if (of_device_is_compatible(pcie->dev->of_node, "xxx,r2-pcie"))
atu_num = 4;
>> 2. That pci-designware common code parses the 'num-atus' can avoid every
>> specific controller driver to define and pass num-atus, so can reduce
>> code size and simplify the specific controller driver implementation.
>>
> I don't think the code reduction matters here and the simplification is
> minimal.
>
> Regards,
> Lucas
>
WARNING: multiple messages have this Message-ID (diff)
From: B31939@freescale.com (Lian Minghuan-B31939)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2] PCI: designware: Add support 4 ATUs assignment
Date: Fri, 14 Nov 2014 16:47:25 +0800 [thread overview]
Message-ID: <5465C19D.3060801@freescale.com> (raw)
In-Reply-To: <1415876988.2420.7.camel@pengutronix.de>
Hi Lucas and all,
On 2014?11?13? 19:09, Lucas Stach wrote:
> Am Donnerstag, den 13.11.2014, 18:52 +0800 schrieb Lian Minghuan-B31939:
>> Hi Lucas,
>>
>> On 2014?11?13? 18:20, Lucas Stach wrote:
>>> Am Donnerstag, den 13.11.2014, 18:02 +0800 schrieb Lian Minghuan-B31939:
>>>> Hi Lucas,
>>>>
>>>> Please see my comments inline.
>>>>
>>>> Thanks,
>>>> Minghuan
>>>>
>>>> On 2014?11?13? 00:32, Lucas Stach wrote:
>>>>> Am Mittwoch, den 12.11.2014, 21:53 +0530 schrieb Srikanth Thokala:
>>>>>> Hi Minghuan,
>>> [...]
>>>
>>>>> Using a smaller type complicates the DT for little to no benefit. I
>>>>> think it's ok to use u32 here, which is a common standard for integer
>>>>> values in DT.
>>>>>
>>>>> Though this discussion lead me to the question if we even need to have
>>>>> this property in the DT at all. Isn't this a property that is fixed for
>>>>> a specific silicon implementation of the DW core? In that case we could
>>>>> just infer the number of ATUs from the DT compatible, so this should
>>>>> probably just be added to struct pcie_port and properly initialized by
>>>>> the SoC glue drivers.
>>>> [Minghuan] As far as I know, exynos implements only 2 ATUs, this is why
>>>> pcie-designware only supports 2 ATU. iMX implements 4 ATUs and LS1021A
>>>> implements 6 ATUs.
>>>>
>>> Right so we don't need an additional property in the DT at all. The
>>> number of ATUs is fixed for a specific core compatible and can be passed
>>> in by the respective exynos, imx and ls1021 glue drivers.
>>>
>>> You may ask the Keystone and Spear maintainers to get the correct number
>>> of ATUs for those implementations.
>>>
>>> Regards,
>>> Lucas
>> [Minghuan] Yes. This a way that specific core driver passes the ATU
>> number to
>> pci-designware. But I perfer to adding dts node for the following reasons:
>> 1. ATU number is hardware attribute, so it can be added to DTS.
> But it is a duplication of information that can be inferred from the DT
> compatible alone, which is usually frowned upon.
>
> Also in contrast to the num-lanes property I don't see a use-case to
> reduce the number of used ATUs in a specific system, so num-atus is
> basically fixed for a specific implementation.
[Minghuan] 4ATUs provides better support for multiple-function and
SR-IOV PCIe devices.
Can anyone tell me if there is the company will increase ATUs number?
If yes, we should avoid the following code:
if (of_device_is_compatible(pcie->dev->of_node, "xxx,r1-pcie"))
atu_num = 2;
if (of_device_is_compatible(pcie->dev->of_node, "xxx,r2-pcie"))
atu_num = 4;
>> 2. That pci-designware common code parses the 'num-atus' can avoid every
>> specific controller driver to define and pass num-atus, so can reduce
>> code size and simplify the specific controller driver implementation.
>>
> I don't think the code reduction matters here and the simplification is
> minimal.
>
> Regards,
> Lucas
>
next prev parent reply other threads:[~2014-11-14 8:46 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-11 5:07 [PATCH v2] PCI: designware: Add support 4 ATUs assignment Minghuan Lian
2014-11-11 5:07 ` Minghuan Lian
2014-11-12 6:22 ` Srikanth Thokala
2014-11-12 6:22 ` Srikanth Thokala
2014-11-12 7:14 ` Lian Minghuan-B31939
2014-11-12 7:14 ` Lian Minghuan-B31939
2014-11-12 9:01 ` Srikanth Thokala
2014-11-12 9:01 ` Srikanth Thokala
2014-11-12 10:09 ` Lian Minghuan-B31939
2014-11-12 10:09 ` Lian Minghuan-B31939
2014-11-12 16:23 ` Srikanth Thokala
2014-11-12 16:23 ` Srikanth Thokala
2014-11-12 16:32 ` Lucas Stach
2014-11-12 16:32 ` Lucas Stach
2014-11-13 10:02 ` Lian Minghuan-B31939
2014-11-13 10:02 ` Lian Minghuan-B31939
2014-11-13 10:20 ` Lucas Stach
2014-11-13 10:20 ` Lucas Stach
2014-11-13 10:52 ` Lian Minghuan-B31939
2014-11-13 10:52 ` Lian Minghuan-B31939
2014-11-13 11:09 ` Lucas Stach
2014-11-13 11:09 ` Lucas Stach
2014-11-14 8:47 ` Lian Minghuan-B31939 [this message]
2014-11-14 8:47 ` Lian Minghuan-B31939
2014-11-14 10:02 ` Lucas Stach
2014-11-14 10:02 ` Lucas Stach
2014-11-14 11:30 ` Mingkai.Hu
2014-11-14 11:30 ` Mingkai.Hu at freescale.com
2014-11-14 11:42 ` Lucas Stach
2014-11-14 11:42 ` Lucas Stach
2014-11-17 2:58 ` Lian Minghuan-B31939
2014-11-17 2:58 ` Lian Minghuan-B31939
2014-11-17 10:25 ` Lucas Stach
2014-11-17 10:25 ` Lucas Stach
2014-11-14 9:36 ` Lian Minghuan-B31939
2014-11-14 9:36 ` Lian Minghuan-B31939
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5465C19D.3060801@freescale.com \
--to=b31939@freescale.com \
--cc=B21284@freescale.com \
--cc=Minghuan.Lian@freescale.com \
--cc=bhelgaas@google.com \
--cc=l.stach@pengutronix.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-pci@vger.kernel.org \
--cc=r61911@freescale.com \
--cc=sriku.linux@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.