All of lore.kernel.org
 help / color / mirror / Atom feed
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: Support a PCI device that is compatible with 'simple-bus'
Date: Fri, 14 Dec 2012 14:58:14 -0700	[thread overview]
Message-ID: <20121214215814.GA14149@obsidianresearch.com> (raw)
In-Reply-To: <20121214202629.BD40C3E0BDD@localhost>

On Fri, Dec 14, 2012 at 08:26:29PM +0000, Grant Likely wrote:

> > > 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.
> > 
> > Is this what you were thinking?
> 
> Not really. I see what you're trying to do, but doing it this way forces
> all children of PCI nodes to use the PCI addressing space. Others have
> had simple children of PCI devices and didn't use the PCI address layout
> at all. Those users would break with this approach.

Yes, that's right.

If you drop 'device_type=pci' from the PCI device (keep it on the host
bridge), then you can setup a ranges down to a smaller width and
things seem to work OK. That must be what other users are doing.

However, you can't stay at address-cells=3 for the children. That
doesn't work.

So, if you have separate PCI regions, like MMIO and prefetch it looks
like this works OK:

 pci_device@0 {
   ranges =
        // MMIO region, BAR 0
       <0x20000000 0x00000000  0x02000000 0x00000000 0x00000000  0x0 0x8000000
        // Prefetch region, BAR 1
        0x40000000 0x00000000  0x42000000 0x00000000 0x00000000  0x0 0x8000000>;

   #size-cells = <1>;
   #address-cells = <2>;
   sub {
     // MMIO region at BAR 0 offset 0x2000
     reg = <0x20000000 0x00002000 0x1000>;
   }
   sub2 {
     // Prefetch region at BAR 1 offset 0x4000
     reg = <0x40000000 0x00004000 0x1000>;
   }
 }

Which is weird, but OK..

This is good enough for my application.. fixing up address-cells=3 to
work generally seems pretty complicated at first blush?

> However, if you want to pass a unity mapping from the PCI device to the
> a child of it, it should be sufficient to use an empty 'ranges;'
> property in the PCI device node instead of listing out the ranges that
> you want to translate.

It isn't a unity mapping - the children see address 0 as being the
start of a BAR. The DTS has three levels of translation:

- platform device child - 0 is the start of a BAR in the pci device
- pci device - 0 is the start of the host bridge memory window for the
  BAR's type
- pci controller - 0 is the start of physical memory

Thanks,
Jason

  reply	other threads:[~2012-12-14 21:58 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-10 21:51 [PATCH] of: Support a PCI device that is compatible with 'simple-bus' Jason Gunthorpe
2012-12-14 20:26 ` Grant Likely
2012-12-14 21:58   ` Jason Gunthorpe [this message]
     [not found]     ` <20121214215814.GA14149-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2012-12-19 12:54       ` Grant Likely
2012-12-19 12:54         ` Grant Likely
2012-12-19 19:18         ` Jason Gunthorpe
2012-12-19 19:18           ` Jason Gunthorpe
2013-03-04  2:55           ` 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=20121214215814.GA14149@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.