All of lore.kernel.org
 help / color / mirror / Atom feed
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: Thu, 13 Nov 2014 18:52:17 +0800	[thread overview]
Message-ID: <54648D61.6050704@freescale.com> (raw)
In-Reply-To: <1415874015.2420.5.camel@pengutronix.de>

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.
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.

Thanks,
Minghuan



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: Thu, 13 Nov 2014 18:52:17 +0800	[thread overview]
Message-ID: <54648D61.6050704@freescale.com> (raw)
In-Reply-To: <1415874015.2420.5.camel@pengutronix.de>

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.
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.

Thanks,
Minghuan

  reply	other threads:[~2014-11-13 10:51 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 [this message]
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
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=54648D61.6050704@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.