All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Mark Brown <broonie@kernel.org>
Cc: Ralf Baechle <ralf@linux-mips.org>,
	Kevin Cernekee <cernekee@gmail.com>,
	linux-kernel@vger.kernel.org, linux-mips@linux-mips.org,
	Johannes Berg <johannes@sipsolutions.net>,
	Simon Arlott <simon@fire.lp0.eu>
Subject: Re: [PATCH 1/2] regmap: Add explict native endian flag to DT bindings
Date: Wed, 27 Jan 2016 12:02:19 +0100	[thread overview]
Message-ID: <1568100.dTeADjCOTa@wuerfel> (raw)
In-Reply-To: <1453848410-24949-1-git-send-email-broonie@kernel.org>

On Tuesday 26 January 2016 22:46:49 Mark Brown wrote:
> -Required properties:
> -- {big,little}-endian: these are boolean properties, if absent
> -  meaning that the CPU and the Device are in the same endianness mode,
> -  these properties are for register values and all the buffers only.
> +Optional properties:
> +- {big,little,native}-endian: these are boolean properties, if absent
> +  then the implementation will choose a default based on the device
> +  being controlled.  These properties are for register values and all
> +  the buffers only.  Native endian means that the CPU and device have
> +  the same endianness.

I think the rest of the file also needs to be changed, and we need some
more explanation about native-endian, which people might think is the
right one for them when it rarely is in reality (Broadcom MIPS being
one notable exception).

How about this version below?

	Arnd


diff --git a/Documentation/devicetree/bindings/regmap/regmap.txt b/Documentation/devicetree/bindings/regmap/regmap.txt
dissimilarity index 91%
index b494f8b8ef72..0127be360fe8 100644
--- a/Documentation/devicetree/bindings/regmap/regmap.txt
+++ b/Documentation/devicetree/bindings/regmap/regmap.txt
@@ -1,47 +1,29 @@
-Device-Tree binding for regmap
-
-The endianness mode of CPU & Device scenarios:
-Index     Device     Endianness properties
----------------------------------------------------
-1         BE         'big-endian'
-2         LE         'little-endian'
-
-For one device driver, which will run in different scenarios above
-on different SoCs using the devicetree, we need one way to simplify
-this.
-
-Required properties:
-- {big,little}-endian: these are boolean properties, if absent
-  meaning that the CPU and the Device are in the same endianness mode,
-  these properties are for register values and all the buffers only.
-
-Examples:
-Scenario 1 : CPU in LE mode & device in LE mode.
-dev: dev@40031000 {
-	      compatible = "name";
-	      reg = <0x40031000 0x1000>;
-	      ...
-};
-
-Scenario 2 : CPU in LE mode & device in BE mode.
-dev: dev@40031000 {
-	      compatible = "name";
-	      reg = <0x40031000 0x1000>;
-	      ...
-	      big-endian;
-};
-
-Scenario 3 : CPU in BE mode & device in BE mode.
-dev: dev@40031000 {
-	      compatible = "name";
-	      reg = <0x40031000 0x1000>;
-	      ...
-};
-
-Scenario 4 : CPU in BE mode & device in LE mode.
-dev: dev@40031000 {
-	      compatible = "name";
-	      reg = <0x40031000 0x1000>;
-	      ...
-	      little-endian;
-};
+Devicetree binding for regmap
+
+Optional properties:
+
+   little-endian,
+   big-endian,
+   native-endian:	See common-properties.txt for a definition
+
+Note:
+Regmap defaults to little-endian register access on MMIO based
+devices, this is by far the most common setting. On CPU
+architectures that typically run big-endian operating systems
+(e.g. PowerPC), registers can be defined as big-endian and must
+be marked that way in the devicetree.
+
+On SoCs that can be operated in both big-endian and little-endian
+modes, with a single hardware switch controlling both the endianess
+of the CPU and a byteswap for MMIO registers (e.g. many Broadcom MIPS
+chips), "native-endian" is used to allow using the same device tree
+blob in both cases.
+
+Examples:
+Scenario 1 : a register set in big-endian mode.
+dev: dev@40031000 {
+	      compatible = "syscon";
+	      reg = <0x40031000 0x1000>;
+	      big-endian;
+	      ...
+};

  parent reply	other threads:[~2016-01-27 11:02 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-26 22:46 [PATCH 1/2] regmap: Add explict native endian flag to DT bindings Mark Brown
2016-01-26 22:46 ` [PATCH RFC 2/2] MIPS: dt: Explicitly specify native endian behaviour for syscon Mark Brown
2016-01-26 23:16   ` Florian Fainelli
2016-01-27  9:37     ` Ralf Baechle
2016-01-27 10:33     ` Jonas Gorski
2016-01-27 10:45       ` Johannes Berg
2016-01-27 11:10       ` Mark Brown
2016-01-27 18:51     ` Mark Brown
2016-01-27 11:02 ` Arnd Bergmann [this message]
2016-01-27 12:19   ` [PATCH 1/2] regmap: Add explict native endian flag to DT bindings Mark Brown

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=1568100.dTeADjCOTa@wuerfel \
    --to=arnd@arndb.de \
    --cc=broonie@kernel.org \
    --cc=cernekee@gmail.com \
    --cc=johannes@sipsolutions.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@linux-mips.org \
    --cc=ralf@linux-mips.org \
    --cc=simon@fire.lp0.eu \
    /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.