linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: arm: mvebu: Add basic address decoding support for Marvell 370/XP
Date: Sat, 4 Aug 2012 16:50:50 +0000	[thread overview]
Message-ID: <201208041650.51427.arnd@arndb.de> (raw)
In-Reply-To: <20120804182730.1ef77f23@skate>

On Saturday 04 August 2012, Thomas Petazzoni wrote:
> Well, we could do something like:
> 
> addr-decoding at d0020000 {
>         compatible = "marvell,armada-addr-decoding-controller";
>         reg = <0xd0020000 0x258>;
> 
>         window at 0 {
>                 /* Window number */
>                 cell-index = <0>;                             
> 
>                 /* Physical address and size at which the device will be mapped. */
>                 reg = <0xfff00000 0x100000>;
> 
>                 /* Which device is being mapped. Can either have 1
>                    integer (for "big" devices) or 2 integers (for devices
>                    in the "Device Bus") */
>                 marvell,target = <0x1 0x1d>;
> 
>                 /* Optional. Remapping address */
>                 marvell,remap = <...>;
>         };
> 
>         window at 12 {
>                 cell-index = <12>;
>                 reg = <0x... 0x....>;
>                 marvell,target = <0x4>;
>         };
> };
> 
> This is just a rough draft, just written in the mail, I haven't even
> tried writing code that would work with it, but it should be relatively
> easy to do.
> 
> Would that make sense? Of course, suggestions welcome, I'm not an
> expert on how to decide what is the best DT encoding for such data.

The point that I'm wondering about is where the physical address
comes from. This one is not describing the hardware at all, and the OS
is free to pick any other address, so why would be put that particular
one into the device tree?

Maybe you can find a way to better represent the actual address hierarchy
in a way that shows the remapping. I don't understand how the remapping
works, but I think what we would need for this is an intermediate
large address space and a ranges property that translate the large
addresses into bus addresses, but with the option of the driver for that
intermediate bus overriding the mapping.

remapped-bus at d0020000 {
	compatible = "marvell,armada-addr-decoding-controller";
	reg = <0xd0020000 0x258>;
	#address-cells = <3>;
	#size-cells = <1>;
	ranges = <0x1 0x1d 0x0     /* device 1 address */
		  0xfff00000	   /* host address */
		  0x100000>	   /* length */
		 <02 0x1e 0x0	   /* device 2 address */
		  0xffe00000	   /* host address */
		  0x100000>	   /* length */

	device at 1.1d.0 {
		compatible = "some-device";
		reg = <0x1 0x1d 0x0 0x5000>
	};
};


	Arnd

      reply	other threads:[~2012-08-04 16:50 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-03 13:10 arm: mvebu: Add basic address decoding support for Marvell 370/XP Thomas Petazzoni
2012-08-03 13:10 ` [PATCH 1/4] arm: plat-orion: introduce PLAT_ORION_LEGACY hidden config option Thomas Petazzoni
2012-08-03 13:26   ` Gregory CLEMENT
2012-08-03 13:10 ` [PATCH 2/4] arm: plat-orion: make bridge_virt_base non-const to support DT use case Thomas Petazzoni
2012-08-03 13:27   ` Gregory CLEMENT
2012-08-03 13:41   ` Arnd Bergmann
2012-08-03 13:48     ` Thomas Petazzoni
2012-08-03 13:10 ` [PATCH 3/4] arm: mvebu: add basic address decoding support to Armada 370/XP Thomas Petazzoni
2012-08-03 13:28   ` Gregory CLEMENT
2012-08-03 13:10 ` [PATCH 4/4] arm: mvebu: add address decoding controller to the DT Thomas Petazzoni
2012-08-03 13:29   ` Gregory CLEMENT
2012-08-03 14:23 ` arm: mvebu: Add basic address decoding support for Marvell 370/XP Arnd Bergmann
2012-08-04 16:27   ` Thomas Petazzoni
2012-08-04 16:50     ` Arnd Bergmann [this message]

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=201208041650.51427.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 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).