All of lore.kernel.org
 help / color / mirror / Atom feed
From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: mvebu-mbus: defining a DT binding
Date: Fri, 5 Apr 2013 21:49:33 +0200	[thread overview]
Message-ID: <201304052149.33533.arnd@arndb.de> (raw)
In-Reply-To: <20130405174845.GD3598@obsidianresearch.com>

On Friday 05 April 2013, Jason Gunthorpe wrote:
> 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 :)

I did not say anything about assigning the phys_addr_t range of
the port in DT, quite the contrary. What I meant is to describe
how a bus address on any of the PCIe ports is wired to the
mbus, which is really a 4GB space per port.

> 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.

Not what I meant.

> 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.

I mean something like

/ {
	#address-cells = <1>;
	#size-cells = <1>;

	mbus {
		#address-cells = <2>;
		#size-cells = <1>;

		/* ignore the specific encoding here */

		ranges = <0x1 0 0xd0000000 0x100000>, /* internal regs */
			 <0xa 0xc0000000 0xc0000000 0x10000> /* PCI port a,
							already assigned */


		internal-bus {
			#address-cells = <1>;
			#size-cells = <0>;
			ranges = <0x1 0 0 0x100000>;
	
			...
		};


		pcie {
			#address-cells = <3>;
			#size-cells = <2>;

			ranges = <0x82000800 0 0 0xa 0 0x1 0>, # port a
				 <0x82001000 0 0 0xb 0 0x1 0>, # port b
				 <0x82001800 0 0 0xc 0 0x1 0>, # port c
				 <0x82002000 0 0 0xd 0 0x1 0>, # port d
				 <0x82002800 0 0 0xe 0 0x1 0>; # port e

			pci { /* port a at device 000800*/
				/* only decodes range 0xc0000000 to 0xc0010000 */
				ranges = <0x82000800 0 0xc0000000 0x82000800 0 0xc0000000 0 0x10000>;
			};
			pci { /* port b at device 001000 */
				/* or just translate everything, to be more sloppy ;-) */
				ranges;
			};
		};
	};
};

	Arnd

  reply	other threads:[~2013-04-05 19:49 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
2013-04-05 19:49             ` Arnd Bergmann [this message]
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=201304052149.33533.arnd@arndb.de \
    --to=arnd@arndb.de \
    --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 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.