Devicetree
 help / color / mirror / Atom feed
From: Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>
To: Rafal Jaworowski <raj-nYOzD4b6Jr9Wk0Htik3J/w@public.gmane.org>
Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
Subject: Re: PCI bus node location
Date: Wed, 11 Nov 2009 22:54:32 -0700	[thread overview]
Message-ID: <fa686aa40911112154w1b86a124ja709e540ca66363c@mail.gmail.com> (raw)
In-Reply-To: <839C8AA0-A8B5-434E-9175-16D2B84D74BD-nYOzD4b6Jr9Wk0Htik3J/w@public.gmane.org>

On Tue, Nov 10, 2009 at 9:55 AM, Rafal Jaworowski <raj-nYOzD4b6Jr9Wk0Htik3J/w@public.gmane.org> wrote:
>
> On 2009-11-10, at 04:12, David Gibson wrote:
>> 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 :-)?
>
> Is the 'soc' node going to be named something less confusing then?
>
>> Note also that 4xx chips, unlike the Freescale ones do have the PCI
>> host bridge under the plb node (which represents the main bus on the
>> SoC).
>
> Yea, I noticed, which made me even more confused, so thanks again for
> clarifications.

The whole point of the IMMR node is to group things that are
relocatable together.  It was chosen as a matter of convenience, but
it would be absolutely valid to eliminate the IMMR node entirely just
make all the internal devices peers of the root node.  Except for a
few bugs that would probably be exposed, the current kernel would
parse that device tree just fine.

So, while the expressed ideal is to describe the exact bus topology,
the reality is that there are many reasons why the .dts hierarchy will
not match the physical hierarchy exactly (ie. omitting nodes for
transparent bridges which software has no control over, or adding
nodes to group logically related devices together, or as with
Freescale PCI moving the nodes out entirely because adding all the PCI
ranges to the IMMR node seems 'wrong').  However, it still works
because there are well established conventions, and device drivers
generally stick to the published device binding without making
assumptions about the node layout.  As long as common code parses
'reg' and 'ranges' correctly, then the whole system works.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

  parent reply	other threads:[~2009-11-12  5:54 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-09 19:20 PCI bus node location Rafal Jaworowski
     [not found] ` <B7D31A24-3361-4B80-81C4-5A815F09D42F-nYOzD4b6Jr9Wk0Htik3J/w@public.gmane.org>
2009-11-10  2:36   ` Grant Likely
     [not found]     ` <fa686aa40911091836s2a6b763aq14ece296cd7368db-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2009-11-10  3:12       ` David Gibson
     [not found]         ` <20091110031218.GG26042-787xzQ0H9iRg7VrjXcPTGA@public.gmane.org>
2009-11-10 16:55           ` Rafal Jaworowski
     [not found]             ` <839C8AA0-A8B5-434E-9175-16D2B84D74BD-nYOzD4b6Jr9Wk0Htik3J/w@public.gmane.org>
2009-11-10 23:44               ` David Gibson
     [not found]                 ` <20091110234412.GA3235-787xzQ0H9iRg7VrjXcPTGA@public.gmane.org>
2009-11-11 14:17                   ` Rafal Jaworowski
     [not found]                     ` <C75E76CB-73F3-4448-B643-364304ABB364-nYOzD4b6Jr9Wk0Htik3J/w@public.gmane.org>
2009-11-12  2:08                       ` David Gibson
2009-11-12  5:54               ` Grant Likely [this message]
2009-11-10 16:26       ` Rafal Jaworowski
     [not found]         ` <A3A4CAD4-BE74-4CD4-BFFA-FE616DF38811-nYOzD4b6Jr9Wk0Htik3J/w@public.gmane.org>
2009-11-11  0:05           ` David Gibson
     [not found]             ` <20091111000540.GB3235-787xzQ0H9iRg7VrjXcPTGA@public.gmane.org>
2009-11-11 14:16               ` Rafal Jaworowski
     [not found]                 ` <8239D9E6-E390-4DED-81C1-77FACF05C1D4-nYOzD4b6Jr9Wk0Htik3J/w@public.gmane.org>
2009-11-11 17:06                   ` Scott Wood
2009-11-12  2:03                   ` David Gibson
     [not found]                     ` <20091112020343.GK3235-787xzQ0H9iRg7VrjXcPTGA@public.gmane.org>
2009-11-12  8:00                       ` Grant Likely
2009-11-12  7:30                   ` 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=fa686aa40911112154w1b86a124ja709e540ca66363c@mail.gmail.com \
    --to=grant.likely-s3s/wqlpoipyb63q8fvjnq@public.gmane.org \
    --cc=devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org \
    --cc=raj-nYOzD4b6Jr9Wk0Htik3J/w@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox