All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 05/11] ARM: shmobile: APE6EVM LAN9220 support
Date: Thu, 30 May 2013 13:26:26 +0000	[thread overview]
Message-ID: <201305301526.26225.arnd@arndb.de> (raw)
In-Reply-To: <Pine.LNX.4.64.1305300700150.24272@axis700.grange>

On Thursday 30 May 2013, Guennadi Liakhovetski wrote:
> Ok, I didn't write the original implementation of that bus and, therefore, 
> didn't decide how many address cells it shall use. My task was to fix it. 
> And yes, I agree, that there are 2 ways to fix the memory mapping: either 
> define ranges to map from 64-bits to 32-bits, or to change all devices on 
> the bus (currently there's only 1) to use 64-bit "reg" property and use 
> "ranges" with no arguments. Since that bus is clearly within a 32-bit 
> area, I would prefer the former solution not to have to drag 64 bits 
> around an make device nodes simpler. Can we keep this approach or are you 
> strongly against it?

I believe we should attempt to have the DT representation as close as
possible to what the hardware actually does. If this is a AHB bus
or something else that is known to be always 32 bit, I would use
a ranges property and #address-cells=<1>, but if this is a 64-bit
wide AXIv4 instance I would use #address-cells=<2> and probably
omit the ranges.

There is also the case where a device is attached to an external bus
that has 0-based addressing. In that case I would put the actual
translation into the ranges property, with all addresses that
are translated by the bus controller, such as

      lbsc {
               compatible = "simple-bus";
               #address-cells = <1>;
               #size-cells = <1>;
               ranges = <0 0x08000000 0 0x1000000>; /* 16 MB @ 128 MB */

               ethernet@0 {
			compatible = "smsc,lan9118", "smsc,lan9115";
			reg = <0 0x1000>;
			...

	Arnd

WARNING: multiple messages have this Message-ID (diff)
From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 05/11] ARM: shmobile: APE6EVM LAN9220 support
Date: Thu, 30 May 2013 15:26:26 +0200	[thread overview]
Message-ID: <201305301526.26225.arnd@arndb.de> (raw)
In-Reply-To: <Pine.LNX.4.64.1305300700150.24272@axis700.grange>

On Thursday 30 May 2013, Guennadi Liakhovetski wrote:
> Ok, I didn't write the original implementation of that bus and, therefore, 
> didn't decide how many address cells it shall use. My task was to fix it. 
> And yes, I agree, that there are 2 ways to fix the memory mapping: either 
> define ranges to map from 64-bits to 32-bits, or to change all devices on 
> the bus (currently there's only 1) to use 64-bit "reg" property and use 
> "ranges" with no arguments. Since that bus is clearly within a 32-bit 
> area, I would prefer the former solution not to have to drag 64 bits 
> around an make device nodes simpler. Can we keep this approach or are you 
> strongly against it?

I believe we should attempt to have the DT representation as close as
possible to what the hardware actually does. If this is a AHB bus
or something else that is known to be always 32 bit, I would use
a ranges property and #address-cells=<1>, but if this is a 64-bit
wide AXIv4 instance I would use #address-cells=<2> and probably
omit the ranges.

There is also the case where a device is attached to an external bus
that has 0-based addressing. In that case I would put the actual
translation into the ranges property, with all addresses that
are translated by the bus controller, such as

      lbsc {
               compatible = "simple-bus";
               #address-cells = <1>;
               #size-cells = <1>;
               ranges = <0 0x08000000 0 0x1000000>; /* 16 MB @ 128 MB */

               ethernet at 0 {
			compatible = "smsc,lan9118", "smsc,lan9115";
			reg = <0 0x1000>;
			...

	Arnd

  reply	other threads:[~2013-05-30 13:26 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-03  2:08 [GIT PULL v2] Renesas ARM SoC board updates for v3.10 #3 Simon Horman
2013-04-03  2:08 ` Simon Horman
2013-04-03  2:08 ` [PATCH 01/11] ARM: shmobile: add R-Car M1A Bock-W platform support Simon Horman
2013-04-03  2:08   ` Simon Horman
2013-04-03  2:08 ` [PATCH 02/11] ARM: shmobile: kzm9g-reference: add ethernet support Simon Horman
2013-04-03  2:08   ` Simon Horman
2013-04-03  2:08 ` [PATCH 03/11] ARM: shmobile: APE6EVM base support Simon Horman
2013-04-03  2:08   ` Simon Horman
2013-04-03  2:08 ` [PATCH 04/11] ARM: shmobile: APE6EVM PFC support Simon Horman
2013-04-03  2:08   ` Simon Horman
2013-04-03  2:08 ` [PATCH 05/11] ARM: shmobile: APE6EVM LAN9220 support Simon Horman
2013-04-03  2:08   ` Simon Horman
2013-05-17 13:00   ` Guennadi Liakhovetski
2013-05-17 13:00     ` Guennadi Liakhovetski
2013-05-22 14:32     ` Simon Horman
2013-05-22 14:32       ` Simon Horman
2013-05-22 17:22       ` Guennadi Liakhovetski
2013-05-22 17:22         ` Guennadi Liakhovetski
2013-05-25  1:01         ` Simon Horman
2013-05-25  1:01           ` Simon Horman
2013-05-28  2:45         ` Olof Johansson
2013-05-28  2:45           ` Olof Johansson
2013-05-29  6:26           ` Guennadi Liakhovetski
2013-05-29  6:26             ` Guennadi Liakhovetski
2013-05-30  4:39             ` Olof Johansson
2013-05-30  4:39               ` Olof Johansson
2013-05-30  5:33               ` Guennadi Liakhovetski
2013-05-30  5:33                 ` Guennadi Liakhovetski
2013-05-30 13:26                 ` Arnd Bergmann [this message]
2013-05-30 13:26                   ` Arnd Bergmann
2013-04-03  2:08 ` [PATCH 06/11] ARM: shmobile: Initial r8a7790 Lager board support Simon Horman
2013-04-03  2:08   ` Simon Horman
2013-04-03  2:08 ` [PATCH 07/11] ARM: shmobile: mackerel: SDHI resources do not have to be numbered Simon Horman
2013-04-03  2:08   ` Simon Horman
2013-04-03  2:08 ` [PATCH 08/11] ARM: shmobile: mackerel: remove OCR masks, where regulators are used Simon Horman
2013-04-03  2:08   ` Simon Horman
2013-04-03  2:08 ` [PATCH 09/11] ARM: shmobile: mackerel: switch SDHI and MMCIF interfaces to slot-gpio Simon Horman
2013-04-03  2:08   ` Simon Horman
2013-04-03  2:08 ` [PATCH 10/11] ARM: shmobile: mackerel: add interrupt names for SDHI0 Simon Horman
2013-04-03  2:08   ` Simon Horman
2013-04-03  2:08 ` [PATCH 11/11] ARM: shmobile: mackerel: clean up MMCIF vs. SDHI1 selection Simon Horman
2013-04-03  2:08   ` Simon Horman
2013-04-03  6:30 ` [GIT PULL v2] Renesas ARM SoC board updates for v3.10 #3 Olof Johansson
2013-04-03  6:30   ` Olof Johansson
2013-04-04  3:33   ` Simon Horman
2013-04-04  3:33     ` Simon Horman
  -- strict thread matches above, loose matches on Subject: below --
2013-04-02  5:11 Simon Horman
2013-04-02  5:11 ` [PATCH 05/11] ARM: shmobile: APE6EVM LAN9220 support Simon Horman
2013-04-02  5:11   ` Simon Horman

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