Linux MIPS Architecture development
 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox