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: Mon, 9 Nov 2009 19:36:57 -0700	[thread overview]
Message-ID: <fa686aa40911091836s2a6b763aq14ece296cd7368db@mail.gmail.com> (raw)
In-Reply-To: <B7D31A24-3361-4B80-81C4-5A815F09D42F-nYOzD4b6Jr9Wk0Htik3J/w@public.gmane.org>

On Mon, Nov 9, 2009 at 12:20 PM, Rafal Jaworowski <raj-nYOzD4b6Jr9Wk0Htik3J/w@public.gmane.org> wrote:
> Hi,
> I have a couple of questions regarding host/PCI bridges nodes location:
>
> - What is the reason most of the DTS definitions have the host/PCI bridges
> hanging off the root node, even though they are most often really part of
> the soc?
> - Is this is some OF heritage (I couldn't find anything explicit about it in
> the original PCI bindings docs)?
> - Is this convention enforced in FDT, or could PCI bus nodes be children of
> the soc node as well?

It was a solution to an engineering problem.  The PCI control
registers are indeed within the IMMR region, and when we first started
doing PowerPC FDT board ports, the PCI node was a child of the SoC
node.  However, since PCI is also bridge with its own address space
translation, having it live in the SoC node causes difficulties.
Specifically, all of the entries in the PCI node ranges property would
need similar counterparts in the SoC node ranges property; a scheme
that doesn't reflect well the actual behaviour of the IMMR region.

Two alternate solutions were proposed.  One was to split the PCI node
into a PCI bridge node which describes the translations, and a PCI
control node which describes how to access the PCI bridge registers.
Some sort of linkage (probably a phandle) would be needed to relate
the two.  The second was to simply move the PCI node out to be a
parent of the root.  The second option was the one chosen because it
was the path of least resistance.  It may not be the most 'correct'
solution, but it has worked out quite well in practice.  There is
nothing in the PCI or FDT infrastructure code that enforces this
convention.  In fact, if the appropriate ranges properties were added
back to the IMMR node, then the PCI node could become a child of the
IMMR node without any code changes (but it still wouldn't be a 100%
'correct' description of the hardware).

See also this commit:

commit 1b3c5cdab49a605f0e048e1ccbf4cc61a2626485
Author: Kumar Gala <galak-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
Date:   Wed Sep 12 18:23:46 2007 -0500

    [POWERPC] Move PCI nodes to be sibilings with SOC nodes

    Updated the device trees to have the PCI nodes be at the same level as
    the SOC node.  This is to make it so that the SOC nodes children address
    space is just on chip registers and not other bus memory as well.

    Also, for PCIe nodes added a P2P bridge to handle the virtual P2P bridge
    that exists in the PHB.

    Signed-off-by: Kumar Gala <galak-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>

Cheers,
g.

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

  parent reply	other threads:[~2009-11-10  2:36 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 [this message]
     [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
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=fa686aa40911091836s2a6b763aq14ece296cd7368db@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