PCI bus node location
Rafal Jaworowski
raj at semihalf.com
Thu Nov 12 01:17:52 EST 2009
On 2009-11-11, at 00:44, David Gibson wrote:
> On Tue, Nov 10, 2009 at 05:55:33PM +0100, Rafal Jaworowski wrote:
>> On 2009-11-10, at 04:12, David Gibson wrote:
>>> On Mon, Nov 09, 2009 at 07:36:57PM -0700, Grant Likely wrote:
>>>> On Mon, Nov 9, 2009 at 12:20 PM, Rafal Jaworowski
> [snip]
>>> Right.
>>>
>>> Under the new scheme, the "soc" node is really a historical
>>> misnomer -
>>> it represents just the things within the IMMR, not everything on the
>>> SoC. A number of chips also have the localbus controller as a
>>> separate node, likewise within the SoC but not within the IMMR, so
>>> not
>>> a child of the soc node.
>>
>> Hm, how do we know whether something belongs under the IMMR/CCSR
>> node or not (even though it physically sits there :-)?
>
> Well, the basic criterion is whether its registers are relocated with
> the rest of the IMMR. Which would cover the PCI control registers, of
> course, but they're not there for the reasons given. Yes, it's kind
> of nasty.
It seems like the soc/simple-bus node is currently a rather arbitrary
subset of peripherals available through SOC internal registers range.
My concern is that without clear grouping criteria this is quite
confusing.
>> Is the 'soc' node going to be named something less confusing then?
>
> I think it should, but it's difficult to change because u-boot has
> dependencies on it. I think there are a few newer trees where it's
> named IMMR.
So is device_type = "soc" deprecated now for new trees, and for this
kind of a bus node the only legit differentiator is the compatible =
"simple-bus" prop?
BTW: in ePAPR examples there is device_type = "simple-bus" in a 8572
soc node, is this a bug or a leftover?
Rafal
More information about the devicetree-discuss
mailing list