linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: jgunthorpe@obsidianresearch.com (Jason Gunthorpe)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM: dts: ventana: fix eth1 pci dev node
Date: Tue, 18 Mar 2014 14:15:19 -0600	[thread overview]
Message-ID: <20140318201519.GA8637@obsidianresearch.com> (raw)
In-Reply-To: <CAJ+vNU2Av-n1-efbFbXNvO4SmoobL_WpQKApFRS1Zjy0egLLzw@mail.gmail.com>

On Tue, Mar 18, 2014 at 01:02:55PM -0700, Tim Harvey wrote:
> > Is this whole bridge/switch hierarchy binding documented somewhere
> > or is this just something that work for you?
> 
> I'm not sure where its 'best' documented, but it is the way the
> kernel works.

It is documented in the 'PCI Bus Binding to Open Firware'
publication from IEEE.

> >> +             pcie at 0,0 {
> >> +                     /* 01:00.0 PCIe switch */
> >> +                     #address-cells = <3>;
> >> +                     #size-cells = <2>;
> >> +                     device_type = "pci";
> >> +                     reg = <0x0 0 0 0 0>;
> >> +
> >> +                     pcie at 8,0 {
> >
> > What's the naming schema for all these pcie nodes?  Generally, we should
> > have the numbers encoded in the node name coming from the address cells
> > in 'reg' property.

The 'reg' property for PCI encodes the device and function number, and
the suffix in the device path is of the form @DEVICE,FUNCTION (see
2.2.1.3 of the spec)

So device=8, function=0 is @8,0 and reg = 0x4000.

> I was hoping there was a way to reference PCI nodes by BDF values as
> I'm simply trying to define a marvell,sky2 device at 08:00.0.  I found
> that the kernel's OF parsing code for PCI requires you to nest the
> nodes to match the bus hierarchy.  In order to map a dt node to a PCI
> device, the bus the device is on must have a dt node itself, which is
> what creates the need for the nesting.  Note that the bus topology
> here rc -> P2P bridge -> GigE.

Right, otherwise the kernel and firmware would have to agree on bus
numbering. With nesting it only has to agree on the device numbering,
which is a fixed property of PCI.

> >> +                             /* 02:08.0 PCIe switch port */
> >> +                             #address-cells = <3>;
> >> +                             #size-cells = <2>;
> >> +                             device_type = "pci";
> >> +                             reg = <0x4000 0 0 0 0>;
> >> +                             eth1: pcie at 0,0 {
> >> +                                     /* 08:00.0 GigE */
> >> +                                     #address-cells = <3>;
> >> +                                     #size-cells = <2>;
> >> +                                     device_type = "pci";
> >> +                                     reg = <0x0 0 0 0 0>;
> >> +                                     compatible = "marvell,sky2";
> >> +                             };

Don't forget your interrupts and interrupt-map - every DT nodes need
to describe how its interrupts are routed.

Jason

  reply	other threads:[~2014-03-18 20:15 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-13 21:44 [PATCH] ARM: dts: ventana: fix eth1 pci dev node Tim Harvey
2014-03-14 13:28 ` Shawn Guo
2014-03-18 20:02   ` Tim Harvey
2014-03-18 20:15     ` Jason Gunthorpe [this message]
2014-03-22  6:25       ` Shawn Guo

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=20140318201519.GA8637@obsidianresearch.com \
    --to=jgunthorpe@obsidianresearch.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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).