From: Grant Likely <grant.likely@secretlab.ca>
To: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Cc: linux-kernel@vger.kernel.org,
devicetree-discuss@lists.ozlabs.org,
Rob Herring <rob.herring@calxeda.com>
Subject: Re: [PATCH] of: When constructing the bus id consider assigned-addresses as well
Date: Mon, 03 Dec 2012 14:27:11 +0000 [thread overview]
Message-ID: <20121203142711.591853E0A4C@localhost> (raw)
In-Reply-To: <20121201004948.GA3185@obsidianresearch.com>
On Fri, 30 Nov 2012 17:49:48 -0700, Jason Gunthorpe <jgunthorpe@obsidianresearch.com> wrote:
> On Fri, Nov 30, 2012 at 09:48:05AM +0000, Grant Likely wrote:
>
> > > If you attempt to stick a 'reg' in a block nested below a
> > > 'device_type="pci"' the kernel throws lots of error messsages and
> > > generates bad address mappings.
> >
> > Have you added the appropriate #address-cells and #size-cells to the pci
> > device node to go back to a non-pci addressing mode?
> > assigned-addresses
>
> Switching away from the 5 dword address format is not ideal
> because then there is no way to specify the resource region (prefetch,
> io, mmio) and mmio would have to be assumed.
You don't need to switch away from using 5 cells if that works best for
you, but I'd be surprised if it was the ideal representation. I would
expect you to use a representation that makes sense for the internal bus
architecture of the device. If if exactly matches the PCI address, then
go ahead with 5 cells, but if it is one or more 32bit busses, then use 1
or 2 for #address-cells and 1 for #size-cells.
>
> > only makes sense in the pci-device node itself. reg should work for all
> > nodes below that, and if it doesn't then it is a bug that we need to
> > fix.
>
> Okay.. but how should the DTS be constructed?
>
pcie_bus { // The PCI-E bus
device_type = "pci";
ranges = <5dw ranges>;
#address-cells = <3>;
#size-cells = <2>;
soc_bridge { // The PCI-E device
device_type = "pci";
// These are important to set up the address format in the child
// nodes
#address-cells = <3>;
#size-cells = <2>;
// Translation from PCI bus space to local bus space.
ranges = <5dw ranges>;
soc_device { // Internal device
reg = <5dw regs>
};
};
};
>
> This is what I have now, the soc_bridge PCI-E device is DTS modeled as
> a PCI bridge - it has a ranges with its memory location, and the
> children nodes are relative to those ranges. This would not be typical
> for a non-bridge PCI-E device.
Now, if the children of soc_bridge really are PCI devices (and not just
plain-vanilla memory mapped IP cores like I assume above), then they
shouldn't be registered in the kernel as platform_devices at all. In
that case register them as PCI devices and the existing PCI
infrastructure should do the naming correctly.
> The reason for the 'assigned-address' requirement with the current
> kernel code is the device_type=pci on soc_bridge. This makes
> of_match_bus(parent) for soc_device return the PCI structure, which
> has '.addresses = "assigned-addresses",'
If the soc_devices are getting triggered on that and they shouldn't be,
then we need a mechanism in the soc_bridge node to kick out of that
behavoir for its children.
g.
prev parent reply other threads:[~2012-12-03 14:27 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-21 21:02 [PATCH] of: When constructing the bus id consider assigned-addresses as well Jason Gunthorpe
2012-11-26 14:03 ` Grant Likely
2012-11-26 18:20 ` Jason Gunthorpe
2012-11-29 16:26 ` Grant Likely
2012-11-29 19:38 ` Jason Gunthorpe
2012-11-30 9:48 ` Grant Likely
2012-12-01 0:49 ` Jason Gunthorpe
2012-12-03 14:27 ` Grant Likely [this message]
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=20121203142711.591853E0A4C@localhost \
--to=grant.likely@secretlab.ca \
--cc=devicetree-discuss@lists.ozlabs.org \
--cc=jgunthorpe@obsidianresearch.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rob.herring@calxeda.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.