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
next prev 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: linkBe 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.