linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: jgunthorpe@obsidianresearch.com (Jason Gunthorpe)
To: linux-arm-kernel@lists.infradead.org
Subject: mvebu-mbus: defining a DT binding
Date: Fri, 5 Apr 2013 11:48:45 -0600	[thread overview]
Message-ID: <20130405174845.GD3598@obsidianresearch.com> (raw)
In-Reply-To: <201304051928.14119.arnd@arndb.de>

On Fri, Apr 05, 2013 at 07:28:13PM +0200, Arnd Bergmann wrote:

> > The Linux PCI core requires a single host bridge aperture, that is
> > what the ranges indicate. It is up to the PCI core to select the
> > address window(s) the PEX will use. When it does this it tells the PCI
> > driver, which tells the MBUS driver, which ultimately creates the
> > window. The address selection must be slaved to the PCI core, the MBUS
> > driver cannot operate autonomously.
> > 
> > This is an unavoidable consequence of merging all the PEX's into a
> > single root complex. If you recall this was required to support the 10
> > PEX case. Cross port address assignment is necessary to avoid address
> > space exhaustion.
> 
> Right, I remembered that already and wrote above that we need to leave
> a single phys_addr_t range for all the PCIe ranges after assigning
> everything else. However, I think the DT representation should still
> reflect what the hardware looks like, meaning that the ranges property
> of the root complex can have one static range for each port, translating
> the 4GB address space of the port to the 4GB mbus window.

The DT representation reflects what the HW looks like 'from the view
point of the PCI-E specification' - which is appropriate since it is a
'device_type=pci' node and has special OF specifications governing its
behaviour.

PCI-E, and the OF PCI bindings want each port to be allocatable within
a 'host aperture', dynamically, based on need. Trying to statically
assign each port's address space in the DT is really struggling
against that :)

Further, there just isn't enough address space to do it. Example:

A system has 3GiB of low RAM, and should support a single VGA card
with a 256MiB BAR - plugged into any PEX port. It has about 512MiB of
low address space to allocate to the PCI host aperture and 10 ports.

It simply cannot be done statically. The kernel must go through all
the PEX's, find the VGA card, allocate 256MiB to that one PEX and then
allocate much smaller amounts to all others.

So, given all of this - can you write out an example PCI controller
DT binding that uses target id in ranges?

This is why I suggested to include the PEX target IDs as meta-data in
the PEX nodes, rather than trying to encode them in ranges.

Jason

  reply	other threads:[~2013-04-05 17:48 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-05 13:02 mvebu-mbus: defining a DT binding Thomas Petazzoni
2013-04-05 13:17 ` Arnd Bergmann
2013-04-05 13:51   ` Thomas Petazzoni
2013-04-05 14:36     ` Arnd Bergmann
2013-04-05 17:07       ` Jason Gunthorpe
2013-04-05 17:28         ` Arnd Bergmann
2013-04-05 17:48           ` Jason Gunthorpe [this message]
2013-04-05 19:49             ` Arnd Bergmann
2013-04-05 20:36               ` Jason Gunthorpe
2013-04-05 21:01                 ` Arnd Bergmann
2013-04-05 21:21                   ` Jason Gunthorpe
2013-04-06  8:39                     ` Arnd Bergmann
2013-04-08 17:03                       ` Jason Gunthorpe
2013-04-05 16:27 ` Jason Gunthorpe
2013-04-05 16:58   ` Arnd Bergmann
2013-04-05 17:29     ` Jason Gunthorpe

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=20130405174845.GD3598@obsidianresearch.com \
    --to=jgunthorpe@obsidianresearch.com \
    --cc=linux-arm-kernel@lists.infradead.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;
as well as URLs for NNTP newsgroup(s).