From: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
To: Grant Likely <grant.likely@secretlab.ca>
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: Fri, 30 Nov 2012 17:49:48 -0700 [thread overview]
Message-ID: <20121201004948.GA3185@obsidianresearch.com> (raw)
In-Reply-To: <20121130094806.0D6D73E070C@localhost>
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.
> 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";
ranges = <5dw ranges>;
soc_device { // Internal device
assigned-address = <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.
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",'
So.. how would you like this to look?
Jason
next prev parent reply other threads:[~2012-12-01 0:49 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 [this message]
2012-12-03 14:27 ` Grant Likely
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=20121201004948.GA3185@obsidianresearch.com \
--to=jgunthorpe@obsidianresearch.com \
--cc=devicetree-discuss@lists.ozlabs.org \
--cc=grant.likely@secretlab.ca \
--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.