From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v6 00/21] MBus DT binding: PCIe strikes back
Date: Sat, 6 Jul 2013 00:54:22 +0200 [thread overview]
Message-ID: <201307060054.23086.arnd@arndb.de> (raw)
In-Reply-To: <20130705220820.GA11787@obsidianresearch.com>
On Saturday 06 July 2013, Jason Gunthorpe wrote:
> This is a good try, but this coding doesn't work...
>
> Recall the long discussion that came up during the original
> development of this binding. The OF spec says this:
>
> In particular, the phys.hi fields of the child address spaces in the
> "ranges" property for PCI does not contain
> the same information as "reg" property entries within PCI nodes. The
> only information that is present in
> "ranges" phys.hi entries are the non-relocatable, prefetchable and
> the PCI address space bits for which the en-
> try applies. I.e., only the n, p and ss bits are present; the
> bbbbbbbb, ddddd, fff and rrrrrrrr fields are 0.
>
> When an address is to be mapped through a PCI bus bridge node, the
> phys.hi value of the address to be mapped
> and the child field of a "ranges" entry should be masked so that only
> the ss bits are compared. I.e., the only
> portion of phys.hi that should participate in the range determination
> is the address space indicator (the ss bits).
>
> Which forbids (0x82000800 .. ..) from being in a ranges
ah, and I thought Ezequiel was being more clever than what I had suggested
> I don't have an idea how to encode MBUS_ID in the PCI-E ranges :(
>
> Arnd? Didn't you have some idea?
The way I described it during the last review, I suggested using
the middle cell of the PCI address here. Since the PCIe port
is 32 bit only, it's otherwise unused. We can do one of two things
here:
a) put the port number in the second cell
0x82000000 1 0xe0000000 MBUS_ID(0x04, 0xe8) 0xe0000000 0 0x08000000 /* Port 0.0 MEM */
0x82000000 2 0xe0000000 MBUS_ID(0x04, 0xe9) 0xe0000000 0 0x08000000 /* Port 1.0 MEM */
b) translate the entire MBUS space here
0x82000000 0 0 0 0 0x1000000 0 /* all MBUS_IDs */
In both cases, the individual ports would have another non-empty
ranges property
a)
0x82000000 1 0xe0000000 0x82000000 0 0xe0000000 0x08000000 /* ranges for port 0.0 */
b)
0x82000000 MBUS_ID(0x04, 0xe8) 0xe0000000 0x82000000 0 0xe0000000 0 0x08000000
I left out the change I suggested in my other reply to not describe
the aperture in this node but translate the entire 4GB space.
Arnd
WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
To: Jason Gunthorpe
<jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
Cc: Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org>,
Jason Cooper <jason-NLaQJdtUoK4Be96aLqz0jA@public.gmane.org>,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org,
Maen Suleiman <maen-eYqpPyKDWXRBDgjK7y7TUQ@public.gmane.org>,
Lior Amsalem <alior-eYqpPyKDWXRBDgjK7y7TUQ@public.gmane.org>,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Sebastian Hesselbarth
<sebastian.hesselbarth-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Subject: Re: [PATCH v6 00/21] MBus DT binding: PCIe strikes back
Date: Sat, 6 Jul 2013 00:54:22 +0200 [thread overview]
Message-ID: <201307060054.23086.arnd@arndb.de> (raw)
In-Reply-To: <20130705220820.GA11787-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
On Saturday 06 July 2013, Jason Gunthorpe wrote:
> This is a good try, but this coding doesn't work...
>
> Recall the long discussion that came up during the original
> development of this binding. The OF spec says this:
>
> In particular, the phys.hi fields of the child address spaces in the
> "ranges" property for PCI does not contain
> the same information as "reg" property entries within PCI nodes. The
> only information that is present in
> "ranges" phys.hi entries are the non-relocatable, prefetchable and
> the PCI address space bits for which the en-
> try applies. I.e., only the n, p and ss bits are present; the
> bbbbbbbb, ddddd, fff and rrrrrrrr fields are 0.
>
> When an address is to be mapped through a PCI bus bridge node, the
> phys.hi value of the address to be mapped
> and the child field of a "ranges" entry should be masked so that only
> the ss bits are compared. I.e., the only
> portion of phys.hi that should participate in the range determination
> is the address space indicator (the ss bits).
>
> Which forbids (0x82000800 .. ..) from being in a ranges
ah, and I thought Ezequiel was being more clever than what I had suggested
> I don't have an idea how to encode MBUS_ID in the PCI-E ranges :(
>
> Arnd? Didn't you have some idea?
The way I described it during the last review, I suggested using
the middle cell of the PCI address here. Since the PCIe port
is 32 bit only, it's otherwise unused. We can do one of two things
here:
a) put the port number in the second cell
0x82000000 1 0xe0000000 MBUS_ID(0x04, 0xe8) 0xe0000000 0 0x08000000 /* Port 0.0 MEM */
0x82000000 2 0xe0000000 MBUS_ID(0x04, 0xe9) 0xe0000000 0 0x08000000 /* Port 1.0 MEM */
b) translate the entire MBUS space here
0x82000000 0 0 0 0 0x1000000 0 /* all MBUS_IDs */
In both cases, the individual ports would have another non-empty
ranges property
a)
0x82000000 1 0xe0000000 0x82000000 0 0xe0000000 0x08000000 /* ranges for port 0.0 */
b)
0x82000000 MBUS_ID(0x04, 0xe8) 0xe0000000 0x82000000 0 0xe0000000 0 0x08000000
I left out the change I suggested in my other reply to not describe
the aperture in this node but translate the entire 4GB space.
Arnd
next prev parent reply other threads:[~2013-07-05 22:54 UTC|newest]
Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-05 21:39 [PATCH v6 00/21] MBus DT binding: PCIe strikes back Ezequiel Garcia
2013-07-05 21:39 ` Ezequiel Garcia
2013-07-05 21:39 ` [PATCH v6 01/21] memory: mvebu-devbus: Remove address decoding window workaround Ezequiel Garcia
2013-07-05 21:39 ` Ezequiel Garcia
2013-07-05 21:39 ` [PATCH v6 02/21] bus: mvebu-mbus: Add new API for window creation Ezequiel Garcia
2013-07-05 21:39 ` Ezequiel Garcia
2013-07-05 21:39 ` [PATCH v6 03/21] ARM: kirkwood: Move to ID based MBus " Ezequiel Garcia
2013-07-05 21:39 ` Ezequiel Garcia
2013-07-05 21:39 ` [PATCH v6 04/21] ARM: mv78xx0: Move to ID based " Ezequiel Garcia
2013-07-05 21:39 ` Ezequiel Garcia
2013-07-05 21:39 ` [PATCH v6 05/21] ARM: orion5x: " Ezequiel Garcia
2013-07-05 21:39 ` Ezequiel Garcia
2013-07-05 21:39 ` [PATCH v6 06/21] ARM: dove: " Ezequiel Garcia
2013-07-05 21:39 ` Ezequiel Garcia
2013-07-05 21:39 ` [PATCH v6 07/21] bus: mvebu-mbus: Factor out initialization details Ezequiel Garcia
2013-07-05 21:39 ` Ezequiel Garcia
2013-07-05 21:39 ` [PATCH v6 08/21] bus: mvebu-mbus: Introduce device tree binding Ezequiel Garcia
2013-07-05 21:39 ` Ezequiel Garcia
2013-07-05 21:39 ` [PATCH v6 09/21] bus: mvebu-mbus: Add static window allocation to the binding Ezequiel Garcia
2013-07-05 21:39 ` Ezequiel Garcia
2013-07-05 21:39 ` [PATCH v6 10/21] pci: mvebu: Adapt to the new device tree layout Ezequiel Garcia
2013-07-05 21:39 ` Ezequiel Garcia
2013-07-05 21:39 ` [PATCH v6 11/21] bus: mvebu-mbus: Remove the no longer used name-based API Ezequiel Garcia
2013-07-05 21:39 ` Ezequiel Garcia
2013-07-05 21:39 ` [PATCH v6 12/21] bus: mvebu-mbus: Remove name -> target, attribute mapping tables Ezequiel Garcia
2013-07-05 21:39 ` Ezequiel Garcia
2013-07-05 21:39 ` [PATCH v6 13/21] bus: mvebu-mbus: Update main description Ezequiel Garcia
2013-07-05 21:39 ` Ezequiel Garcia
2013-07-05 21:39 ` [PATCH v6 14/21] bus: mvebu-mbus: Factorize Armada 370/XP data structures Ezequiel Garcia
2013-07-05 21:39 ` Ezequiel Garcia
2013-07-05 21:39 ` [PATCH v6 15/21] ARM: mvebu: Remove the harcoded BootROM window allocation Ezequiel Garcia
2013-07-05 21:39 ` Ezequiel Garcia
2013-07-05 21:39 ` [PATCH v6 16/21] ARM: mvebu: Initialize MBus using the DT binding Ezequiel Garcia
2013-07-05 21:39 ` Ezequiel Garcia
2013-07-05 21:39 ` [PATCH v6 17/21] ARM: mvebu: Use the preprocessor on Armada 370/XP device tree files Ezequiel Garcia
2013-07-05 21:39 ` Ezequiel Garcia
2013-07-05 21:39 ` [PATCH v6 18/21] ARM: mvebu: Add MBus to Armada 370/XP device tree Ezequiel Garcia
2013-07-05 21:39 ` Ezequiel Garcia
2013-07-05 21:39 ` [PATCH v6 19/21] ARM: mvebu: Add BootROM " Ezequiel Garcia
2013-07-05 21:39 ` Ezequiel Garcia
2013-07-05 21:39 ` [PATCH v6 20/21] ARM: mvebu: Relocate Armada 370/XP DeviceBus device tree nodes Ezequiel Garcia
2013-07-05 21:39 ` Ezequiel Garcia
2013-07-05 21:39 ` [PATCH v6 21/21] ARM: mvebu: Relocate Armada 370/XP PCIe " Ezequiel Garcia
2013-07-05 21:39 ` Ezequiel Garcia
2013-07-05 22:08 ` [PATCH v6 00/21] MBus DT binding: PCIe strikes back Jason Gunthorpe
2013-07-05 22:08 ` Jason Gunthorpe
2013-07-05 22:37 ` Thomas Petazzoni
2013-07-05 22:37 ` Thomas Petazzoni
2013-07-05 22:54 ` Arnd Bergmann [this message]
2013-07-05 22:54 ` Arnd Bergmann
2013-07-05 22:40 ` Arnd Bergmann
2013-07-05 22:40 ` Arnd Bergmann
2013-07-05 23:35 ` Thomas Petazzoni
2013-07-05 23:35 ` Thomas Petazzoni
2013-07-05 23:38 ` Arnd Bergmann
2013-07-05 23:38 ` Arnd Bergmann
2013-07-08 16:42 ` Jason Gunthorpe
2013-07-08 16:42 ` Jason Gunthorpe
2013-07-08 19:52 ` Ezequiel Garcia
2013-07-08 19:52 ` Ezequiel Garcia
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=201307060054.23086.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.