From: Michal Simek <monstr@monstr.eu>
To: Rob Herring <robherring2@gmail.com>
Cc: linux-pci@vger.kernel.org, devicetree-discuss@lists.ozlabs.org,
Thierry Reding <thierry.reding@avionic-design.de>,
Rob Herring <rob.herring@calxeda.com>,
linuxppc-dev <linuxppc-dev@lists.ozlabs.org>
Subject: Re: pci and pcie device-tree binding - range No cells
Date: Mon, 10 Dec 2012 17:11:38 +0100 [thread overview]
Message-ID: <50C609BA.8020008@monstr.eu> (raw)
In-Reply-To: <50C6078A.8080408@gmail.com>
On 12/10/2012 05:02 PM, Rob Herring wrote:
> On 12/10/2012 09:37 AM, Michal Simek wrote:
>> On 12/10/2012 04:21 PM, Rob Herring wrote:
>>> On 12/10/2012 09:05 AM, Michal Simek wrote:
>>>> On 12/10/2012 03:26 PM, Rob Herring wrote:
>>>>> On 12/10/2012 06:20 AM, Michal Simek wrote:
>>>>>> Hi Grant and others,
>>>>>>
>>>>>> I have a question regarding number of cells in ranges property
>>>>>> for pci and pcie nodes.
>>>>>>
>>>>>> Linux pci/pcie powerpc DTSes contain 7 cells (xpedite5370.dts,
>>>>>> sequoia.dts, etc)
>>>>>> but also 6 cells format too (mpc832x_mds.dts)
>>>>>>
>>>>>> Here is shown 6 cells ranges format and describe
>>>>>> http://devicetree.org/Device_Tree_Usage#PCI_Host_Bridge
>>>>>>
>>>>>> And also in documentation in the linux
>>>>>> Documentation/devicetree/bindings/pci/83xx-512x-pci.txt
>>>>>>
>>>>>> Both format uses:
>>>>>> #size-cells = <2>;
>>>>>> #address-cells = <3>;
>>>>>>
>>>>>> What is valid format?
>>>>>
>>>>> Both. 7 cells are valid when the host (parent) bus is 64-bit and 6
>>>>> cells
>>>>> are valid when the host bus is 32-bit. The ranges property is <<child
>>>>> address> <parent address> <size>>. The parent address #address-cells is
>>>>> taken from the parent node.
>>>>
>>>> Ok. Got it.
>>>>
>>>> Here is what we use on zynq and microblaze - both 32bit which should be
>>>> fine.
>>>>
>>>> ps7_axi_interconnect_0: axi@0 {
>>>> #address-cells = <1>;
>>>> #size-cells = <1>;
>>>> axi_pcie_0: axi-pcie@50000000 {
>>>> #address-cells = <3>;
>>>> #size-cells = <2>;
>>>> compatible = "xlnx,axi-pcie-1.05.a";
>>>> ranges = < 0x02000000 0 0x60000000 0x60000000 0
>>>> 0x10000000 >;
>>>> ...
>>>> }
>>>> }
>>>>
>>>> What I am wondering is pci_process_bridge_OF_ranges() at
>>>> arch/powerpc/kernel/pci-common.c
>>>> where there are used some hardcoded values which should be probably
>>>> loaded from device-tree.
>>>>
>>>> For example:
>>>> 683 int np = pna + 5;
>>>> ...
>>>> 702 pci_addr = of_read_number(ranges + 1, 2);
>>>> 703 cpu_addr = of_translate_address(dev, ranges + 3);
>>>> 704 size = of_read_number(ranges + pna + 3, 2);
>>>
>>> These would always be correct whether you have 6 or 7 cells. pna is the
>>> parent bus address cells size. The pci address is fixed at 3 cells.
>>
>> Sorry for my pci ignorance (have never got hw for mb/zynq)
>> I just want to get better overview how we should we our drivers to be
>> compatible.
>>
>> Does it mean that pci is supposed be always 64 bit wide?
>> And there is no option to have just 32bit values.
>
> That's what the DT documentation says.
>
> BTW, you can use 2 cells even if you only have a 32-bit bus.
ok - no problem with that. Just want to be sure about it.
>>>> Unfortunately we have copied it to microblaze.
>>>
>>> I look at the PCI DT code in powerpc and see a whole bunch of code that
>>> seems like it should be common. The different per arch pci structs
>>> complicates that. No one has really gotten to looking at PCI DT on ARM
>>> yet except you and Thierry for Tegra. We definitely don't want to create
>>> a 3rd copy. Starting the process of moving it to something like
>>> drivers/pci/pci-of.c would be great.
>>
>> We have done pcie working on zynq and the same pcie host is working on
>> Microblaze too.
>> There are just small differences. That's why I have sent another email
>> ("Sharing PCIE driver between Microblaze and Arm zynq") to find out
>> proper location.
>
> Yes, I've followed the thread. There are lots of areas for consolidation
> with PCIe hosts both across architectures and within ARM. There are
> multiple people using DW PCIe IP although not upstream yet that I'm
> aware of.
Your suggestions are really appreciate.
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian
next prev parent reply other threads:[~2012-12-10 16:11 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-10 12:20 pci and pcie device-tree binding - range No cells Michal Simek
2012-12-10 14:26 ` Rob Herring
2012-12-10 15:05 ` Michal Simek
2012-12-10 15:21 ` Rob Herring
2012-12-10 15:37 ` Michal Simek
2012-12-10 15:52 ` David Laight
2012-12-10 16:05 ` Michal Simek
2012-12-10 17:15 ` Thomas Petazzoni
2012-12-10 23:24 ` Rob Herring
2012-12-12 16:16 ` Thomas Petazzoni
2012-12-12 17:22 ` Grant Likely
2012-12-12 17:29 ` Rob Herring
2012-12-10 16:02 ` Rob Herring
2012-12-10 16:11 ` Michal Simek [this message]
2012-12-10 21:43 ` Grant Likely
2012-12-10 22:38 ` Benjamin Herrenschmidt
2012-12-10 23:11 ` Mitch Bradley
2012-12-10 21:41 ` Grant Likely
2012-12-12 10:37 ` Michal Simek
2012-12-12 10:49 ` Grant Likely
[not found] ` <CAPcvp5EJH-Q6wd7my+V+FUVE1=hzwMN-yOfHiukGvDmkcoRcsQ@mail.gmail.com>
2012-12-12 12:19 ` Andrew Murray
2012-12-12 13:34 ` Thierry Reding
2012-12-12 16:44 ` Andrew Murray
2012-12-12 16:55 ` Michal Simek
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=50C609BA.8020008@monstr.eu \
--to=monstr@monstr.eu \
--cc=devicetree-discuss@lists.ozlabs.org \
--cc=linux-pci@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=rob.herring@calxeda.com \
--cc=robherring2@gmail.com \
--cc=thierry.reding@avionic-design.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).