All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
To: Tim Harvey <tharvey-UMMOYl/HMS+akBO8gow8eQ@public.gmane.org>
Cc: Shawn Guo <shawn.guo-KZfg59tc24xl57MIdRCFDg@public.gmane.org>,
	"devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Shawn Guo <shawn.guo-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
	"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
	<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>
Subject: Re: [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-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

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@0,0 {
> >> +                     /* 01:00.0 PCIe switch */
> >> +                     #address-cells = <3>;
> >> +                     #size-cells = <2>;
> >> +                     device_type = "pci";
> >> +                     reg = <0x0 0 0 0 0>;
> >> +
> >> +                     pcie@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@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
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
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

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

Thread overview: 10+ 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-13 21:44 ` Tim Harvey
     [not found] ` <1394747064-4106-1-git-send-email-tharvey-UMMOYl/HMS+akBO8gow8eQ@public.gmane.org>
2014-03-14 13:28   ` Shawn Guo
2014-03-14 13:28     ` Shawn Guo
     [not found]     ` <20140314132805.GD813-rvtDTF3kK1ictlrPMvKcciBecyulp+rMXqFh9Ls21Oc@public.gmane.org>
2014-03-18 20:02       ` Tim Harvey
2014-03-18 20:02         ` Tim Harvey
     [not found]         ` <CAJ+vNU2Av-n1-efbFbXNvO4SmoobL_WpQKApFRS1Zjy0egLLzw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-03-18 20:15           ` Jason Gunthorpe [this message]
2014-03-18 20:15             ` Jason Gunthorpe
     [not found]             ` <20140318201519.GA8637-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2014-03-22  6:25               ` Shawn Guo
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-epgobjl8dl3ta4ec/59zmfatqe2ktcn/@public.gmane.org \
    --cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=shawn.guo-KZfg59tc24xl57MIdRCFDg@public.gmane.org \
    --cc=shawn.guo-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
    --cc=tharvey-UMMOYl/HMS+akBO8gow8eQ@public.gmane.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 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.