[PATCHv2 0/3] add DT endianness binding support

[PATCHv2 0/3] add DT endianness binding support

[Xiubo Li]

Change in V2:
- Namespace the properties using the prefix sring.
- Add one binding ducomentation off regmap.

Xiubo Li (3):
  dt/bindings: Add the DT binding documentation for endianness
  regmap: Add the DT binding documentation for endianness
  regmap: add DT endianness binding support.

 .../devicetree/bindings/endianness/endianness.txt  | 55 +++++++++++++
 .../bindings/regmap/regmap-endianness.txt          | 48 +++++++++++
 drivers/base/regmap/regmap.c                       | 96 +++++++++++++++++++---
 3 files changed, 188 insertions(+), 11 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/endianness/endianness.txt
 create mode 100644 Documentation/devicetree/bindings/regmap/regmap-endianness.txt

-- 
1.8.4

[PATCHv2 1/3] dt/bindings: Add the DT binding documentation for endianness

[Xiubo Li]

Signed-off-by: Xiubo Li <Li.Xiubo@freescale.com>
---
 .../devicetree/bindings/endianness/endianness.txt  | 55 ++++++++++++++++++++++
 1 file changed, 55 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/endianness/endianness.txt

diff --git a/Documentation/devicetree/bindings/endianness/endianness.txt b/Documentation/devicetree/bindings/endianness/endianness.txt
new file mode 100644
index 0000000..64f1d5e
--- /dev/null
+++ b/Documentation/devicetree/bindings/endianness/endianness.txt
@@ -0,0 +1,55 @@
+Device-Tree binding for device endianness
+
+The endianness mode of CPU & Device scenarios:
+  Index    CPU      Device
+  ------------------------
+  1        LE         LE
+  2        LE         BE
+  3        BE         BE
+  4        BE         LE
+
+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:
+- [prefix]-endian: this is one string property and must be one
+  of 'be', 'le' and 'native' if it is present.
+
+The endianness mode:
+  'le' : device is in little endian mode,
+  'be' : device is in big endian mode,
+  'native' : device is in the same endian mode with the CPU.
+
+Examples:
+Scenario 1 : CPU in LE mode & device in LE mode.
+dev: dev@40031000 {
+	      compatible = "name";
+	      reg = <0x40031000 0x1000>;
+	      ...
+	      [prefix]-endian = 'native';
+};
+
+Scenario 2 : CPU in LE mode & device in BE mode.
+dev: dev@40031000 {
+	      compatible = "name";
+	      reg = <0x40031000 0x1000>;
+	      ...
+	      [prefix]-endian = 'be';
+};
+
+Scenario 3 : CPU in BE mode & device in BE mode.
+dev: dev@40031000 {
+	      compatible = "name";
+	      reg = <0x40031000 0x1000>;
+	      ...
+	      [prefix]-endian = 'native';
+};
+
+Scenario 4 : CPU in BE mode & device in LE mode.
+dev: dev@40031000 {
+	      compatible = "name";
+	      reg = <0x40031000 0x1000>;
+	      ...
+	      [prefix]-endian = 'le';
+};
-- 
1.8.4

[PATCHv2 2/3] regmap: Add the DT binding documentation for endianness

[Xiubo Li]

Signed-off-by: Xiubo Li <Li.Xiubo@freescale.com>
---
 .../bindings/regmap/regmap-endianness.txt          | 48 ++++++++++++++++++++++
 1 file changed, 48 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/regmap/regmap-endianness.txt

diff --git a/Documentation/devicetree/bindings/regmap/regmap-endianness.txt b/Documentation/devicetree/bindings/regmap/regmap-endianness.txt
new file mode 100644
index 0000000..1d838c5
--- /dev/null
+++ b/Documentation/devicetree/bindings/regmap/regmap-endianness.txt
@@ -0,0 +1,48 @@
+Device-Tree bindings for regmap endianness
+
+Required properties:
+- regmap-reg-endian: register endianness, see ../endianness/endianness.txt
+  for detail.
+- regmap-val-endian: value endianness, see ../endianness/endianness.txt for
+  detail.
+
+The Endianness flags supported by regmap:
+DT properties           Macros
+----------------------------------------
+    'le'          REGMAP_ENDIAN_LITTLE
+    'be'          REGMAP_ENDIAN_BIG
+    'native'      REGMAP_ENDIAN_NATIVE
+    Absent        REGMAP_ENDIAN_DEFAULT
+
+Examples for using the regmap-mmio:
+Scenario 1 : CPU in LE mode & device in LE mode.
+dev: dev@40031000 {
+	      compatible = "name";
+	      reg = <0x40031000 0x1000>;
+	      ...
+	      regmap-val-endian = 'native'; or just absent.
+};
+
+Scenario 2 : CPU in LE mode & device in BE mode.
+dev: dev@40031000 {
+	      compatible = "name";
+	      reg = <0x40031000 0x1000>;
+	      ...
+	      regmap-val-endian = 'be';
+};
+
+Scenario 3 : CPU in BE mode & device in BE mode.
+dev: dev@40031000 {
+	      compatible = "name";
+	      reg = <0x40031000 0x1000>;
+	      ...
+	      regmap-val-endian = 'native'; or just absent.
+};
+
+Scenario 4 : CPU in BE mode & device in LE mode.
+dev: dev@40031000 {
+	      compatible = "name";
+	      reg = <0x40031000 0x1000>;
+	      ...
+	      regmap-val-endian = 'le';
+};
-- 
1.8.4

[PATCHv2 3/3] regmap: add DT endianness binding support.

[Xiubo Li]

For many drivers which will support rich endianness of CPU<-->Dev
need define DT properties by itself without the binding support.

The value endianness using regmap-mmio, for example:
Index    CPU       Device     Endianess flag for DT property
------------------------------------------------------------
1        LE        LE         -
2        LE        BE         'big-endian'
3        BE        BE         -
4        BE        LE         'little-endian'

============

Here add DT endianness binding support will define two string
properties of the register and value endiannesses:

'regmap-reg-endian' and 'regmap-val-endian'.

And the value of them will be:
'le' : REGMAP_ENDIAN_LITTLE
'be' : REGMAP_ENDIAN_BIG
'native' : REGMAP_ENDIAN_NATIVE
Absent : REGMAP_ENDIAN_DEFAULT

The value endianness for regmap-mmio, for example:
Index    CPU       Device     Endianess flag for DT property
------------------------------------------------------------
1        LE        LE         'native' or absent
2        LE        BE         'be'
3        BE        BE         'native' or absent
4        BE        LE         'le'

Please see the following documetation for detail usage:
    Documentation/devicetree/bindings/regmap/regmap-endianness.txt

Signed-off-by: Xiubo Li <Li.Xiubo@freescale.com>
---
 drivers/base/regmap/regmap.c | 96 +++++++++++++++++++++++++++++++++++++++-----
 1 file changed, 85 insertions(+), 11 deletions(-)

diff --git a/drivers/base/regmap/regmap.c b/drivers/base/regmap/regmap.c
index 8e8cea1..cfc9302 100644
--- a/drivers/base/regmap/regmap.c
+++ b/drivers/base/regmap/regmap.c
@@ -15,6 +15,7 @@
 #include <linux/export.h>
 #include <linux/mutex.h>
 #include <linux/err.h>
+#include <linux/of.h>
 #include <linux/rbtree.h>
 #include <linux/sched.h>
 
@@ -423,6 +424,81 @@ static void regmap_range_exit(struct regmap *map)
 }
 
 /**
+ * of_regmap_endian_get_by_name() - Parse and lookup the endianness referenced
+ * by a device node
+ * @np: pointer to clock consumer node
+ * @name: name of consumer's endianness input
+ *
+ * This function parses the device endianness property, and uses them to
+ * determine the endianness of the registers and values.
+ */
+static int of_regmap_endian_get_by_name(struct device_node *np,
+					const char *endian_name,
+					enum regmap_endian *out_endian)
+{
+	const char *endianness;
+	int ret;
+
+	if (!out_endian)
+		return -EINVAL;
+
+	/* Set the default endianness */
+	*out_endian = REGMAP_ENDIAN_DEFAULT;
+
+	/* Absent or being to use the flag from config of the drivers */
+	if (!of_find_property(np, endian_name, NULL))
+		return 0;
+
+	ret = of_property_read_string(np, endian_name, &endianness);
+	if (ret)
+		return ret;
+
+	if (!strcmp("le", endianness))
+		*out_endian = REGMAP_ENDIAN_LITTLE;
+	else if (!strcmp("be", endianness))
+		*out_endian = REGMAP_ENDIAN_BIG;
+	else if (!strcmp("native", endianness))
+		*out_endian = REGMAP_ENDIAN_NATIVE;
+
+	return 0;
+}
+
+static int of_regmap_get_endian(struct device *dev,
+				const struct regmap_bus *bus,
+				const struct regmap_config *config,
+				const char *endian_name,
+				enum regmap_endian *out_endian)
+{
+	int ret;
+
+	if (!out_endian)
+		return -EINVAL;
+
+	if (dev) {
+		ret = of_regmap_endian_get_by_name(dev->of_node, endian_name,
+						   out_endian);
+		if (ret < 0)
+			return ret;
+	}
+
+	if (*out_endian != REGMAP_ENDIAN_DEFAULT)
+		return 0;
+
+	/*
+	 * Parsing the endianness from driver's config
+	 * or bus, this is to be compatible with the
+	 * none DT and the old drivers.
+	 */
+	*out_endian = config->reg_format_endian;
+	if (*out_endian == REGMAP_ENDIAN_DEFAULT)
+		*out_endian = bus->reg_format_endian_default;
+	if (*out_endian == REGMAP_ENDIAN_DEFAULT)
+		*out_endian = REGMAP_ENDIAN_BIG;
+
+	return 0;
+}
+
+/**
  * regmap_init(): Initialise register map
  *
  * @dev: Device that will be interacted with
@@ -518,17 +594,15 @@ struct regmap *regmap_init(struct device *dev,
 		map->reg_read  = _regmap_bus_read;
 	}
 
-	reg_endian = config->reg_format_endian;
-	if (reg_endian == REGMAP_ENDIAN_DEFAULT)
-		reg_endian = bus->reg_format_endian_default;
-	if (reg_endian == REGMAP_ENDIAN_DEFAULT)
-		reg_endian = REGMAP_ENDIAN_BIG;
-
-	val_endian = config->val_format_endian;
-	if (val_endian == REGMAP_ENDIAN_DEFAULT)
-		val_endian = bus->val_format_endian_default;
-	if (val_endian == REGMAP_ENDIAN_DEFAULT)
-		val_endian = REGMAP_ENDIAN_BIG;
+	ret = of_regmap_get_endian(dev, bus, config, "regmap-reg-endian",
+				   &reg_endian);
+	if (ret)
+		return ERR_PTR(ret);
+
+	ret = of_regmap_get_endian(dev, bus, config, "regmap-val-endian",
+				   &val_endian);
+	if (ret)
+		return ERR_PTR(ret);
 
 	switch (config->reg_bits + map->reg_shift) {
 	case 2:
-- 
1.8.4

Re: [PATCHv2 1/3] dt/bindings: Add the DT binding documentation for endianness

[Mark Rutland]

On Wed, Apr 23, 2014 at 07:46:33AM +0100, Xiubo Li wrote:
> Signed-off-by: Xiubo Li <Li.Xiubo@freescale.com>
> ---
>  .../devicetree/bindings/endianness/endianness.txt  | 55 ++++++++++++++++++++++
>  1 file changed, 55 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/endianness/endianness.txt
> 
> diff --git a/Documentation/devicetree/bindings/endianness/endianness.txt b/Documentation/devicetree/bindings/endianness/endianness.txt
> new file mode 100644
> index 0000000..64f1d5e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/endianness/endianness.txt
> @@ -0,0 +1,55 @@
> +Device-Tree binding for device endianness
> +
> +The endianness mode of CPU & Device scenarios:
> +  Index    CPU      Device
> +  ------------------------
> +  1        LE         LE
> +  2        LE         BE
> +  3        BE         BE
> +  4        BE         LE
> +
> +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:
> +- [prefix]-endian: this is one string property and must be one
> +  of 'be', 'le' and 'native' if it is present.

What exactly is the prefix?

This file name and file heading implies this is a common endianness
binding, which it is not. There are many existing bindings that have
mechanisms for describing the endianness of components, and they have
settled on a different pattern.

We already have many bindings with {big,little}-endian{,-*} boolean
properties. It would be better to take that common case and document
that as the standard way of doing things rather than inventing a
completely different mechanism.

> +The endianness mode:
> +  'le' : device is in little endian mode,
> +  'be' : device is in big endian mode,
> +  'native' : device is in the same endian mode with the CPU.

What exactly do you mean by native? A device which always matches the
endianness of the CPU even if it changes? How common is that?

> +
> +Examples:
> +Scenario 1 : CPU in LE mode & device in LE mode.
> +dev: dev@40031000 {
> +	      compatible = "name";
> +	      reg = <0x40031000 0x1000>;
> +	      ...
> +	      [prefix]-endian = 'native';
> +};

If the device is LE, then surely we should describe the device as LE.
The kernel knows what endianness it is, might choose to change the CPU
endianness, but regardless can do the right thing. Telling it a device
is native is useless unless the device changes endianness with the CPU.

> +
> +Scenario 2 : CPU in LE mode & device in BE mode.
> +dev: dev@40031000 {
> +	      compatible = "name";
> +	      reg = <0x40031000 0x1000>;
> +	      ...
> +	      [prefix]-endian = 'be';
> +};
> +
> +Scenario 3 : CPU in BE mode & device in BE mode.
> +dev: dev@40031000 {
> +	      compatible = "name";
> +	      reg = <0x40031000 0x1000>;
> +	      ...
> +	      [prefix]-endian = 'native';
> +};

Likewise.

Thanks,
Mark.

Re: [PATCHv2 2/3] regmap: Add the DT binding documentation for endianness

[Mark Rutland]

On Wed, Apr 23, 2014 at 07:46:34AM +0100, Xiubo Li wrote:
> Signed-off-by: Xiubo Li <Li.Xiubo@freescale.com>
> ---
>  .../bindings/regmap/regmap-endianness.txt          | 48 ++++++++++++++++++++++
>  1 file changed, 48 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/regmap/regmap-endianness.txt
> 
> diff --git a/Documentation/devicetree/bindings/regmap/regmap-endianness.txt b/Documentation/devicetree/bindings/regmap/regmap-endianness.txt
> new file mode 100644
> index 0000000..1d838c5
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/regmap/regmap-endianness.txt
> @@ -0,0 +1,48 @@
> +Device-Tree bindings for regmap endianness

As regmap is a Linux internal detail, I don't see why it needs to leak
into bindings.

> +Required properties:
> +- regmap-reg-endian: register endianness, see ../endianness/endianness.txt
> +  for detail.
> +- regmap-val-endian: value endianness, see ../endianness/endianness.txt for

I'm not familiar with regmap. What is the difference between register
and value endianness?

> +  detail.
> +
> +The Endianness flags supported by regmap:
> +DT properties           Macros
> +----------------------------------------
> +    'le'          REGMAP_ENDIAN_LITTLE
> +    'be'          REGMAP_ENDIAN_BIG
> +    'native'      REGMAP_ENDIAN_NATIVE
> +    Absent        REGMAP_ENDIAN_DEFAULT

As mentinoned earlier, I think we should stick to the common convention
of device-specific {big,little}-endian{,-*} boolean properties. The
common case might just be a simple big-endian property, with LE assumed
(or the inverse with a little-endian property).

Cheers,
Mark.

RE: [PATCHv2 2/3] regmap: Add the DT binding documentation for endianness

[Li.Xiubo]

> Subject: Re: [PATCHv2 2/3] regmap: Add the DT binding documentation for
> endianness
> 
> On Wed, Apr 23, 2014 at 07:46:34AM +0100, Xiubo Li wrote:
> > Signed-off-by: Xiubo Li <Li.Xiubo@freescale.com>
> > ---
> >  .../bindings/regmap/regmap-endianness.txt          | 48
> ++++++++++++++++++++++
> >  1 file changed, 48 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/regmap/regmap-
> endianness.txt
> >
> > diff --git a/Documentation/devicetree/bindings/regmap/regmap-endianness.txt
> b/Documentation/devicetree/bindings/regmap/regmap-endianness.txt
> > new file mode 100644
> > index 0000000..1d838c5
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/regmap/regmap-endianness.txt
> > @@ -0,0 +1,48 @@
> > +Device-Tree bindings for regmap endianness
> 
> As regmap is a Linux internal detail, I don't see why it needs to leak
> into bindings.
> 
> > +Required properties:
> > +- regmap-reg-endian: register endianness, see ../endianness/endianness.txt
> > +  for detail.
> > +- regmap-val-endian: value endianness, see ../endianness/endianness.txt for
> 
> I'm not familiar with regmap. What is the difference between register
> and value endianness?
>

Sorry for late, I'm very busy these days.

The register endianness here is used for the I2C and SPI protocol, which will
Send the register address(which maybe 8-bit or 16-bit) before its values.
 
BRs
Xiubo

RE: [PATCHv2 1/3] dt/bindings: Add the DT binding documentation for endianness

[Li.Xiubo]

> > diff --git a/Documentation/devicetree/bindings/endianness/endianness.txt
> b/Documentation/devicetree/bindings/endianness/endianness.txt
> > new file mode 100644
> > index 0000000..64f1d5e
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/endianness/endianness.txt
> > @@ -0,0 +1,55 @@
> > +Device-Tree binding for device endianness
> > +
> > +The endianness mode of CPU & Device scenarios:
> > +  Index    CPU      Device
> > +  ------------------------
> > +  1        LE         LE
> > +  2        LE         BE
> > +  3        BE         BE
> > +  4        BE         LE
> > +
> > +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:
> > +- [prefix]-endian: this is one string property and must be one
> > +  of 'be', 'le' and 'native' if it is present.
> 
> What exactly is the prefix?
> 
> This file name and file heading implies this is a common endianness
> binding, which it is not. There are many existing bindings that have
> mechanisms for describing the endianness of components, and they have
> settled on a different pattern.
> 
> We already have many bindings with {big,little}-endian{,-*} boolean
> properties. It would be better to take that common case and document
> that as the standard way of doing things rather than inventing a
> completely different mechanism.
> 

Well, yes, I'll follow your advice.


> > +The endianness mode:
> > +  'le' : device is in little endian mode,
> > +  'be' : device is in big endian mode,
> > +  'native' : device is in the same endian mode with the CPU.
> 
> What exactly do you mean by native? A device which always matches the
> endianness of the CPU even if it changes? How common is that?
> 

It's originally based the regmap, and the 'native' is make no sense here,
I'll reconstruct this.


> > +
> > +Examples:
> > +Scenario 1 : CPU in LE mode & device in LE mode.
> > +dev: dev@40031000 {
> > +	      compatible = "name";
> > +	      reg = <0x40031000 0x1000>;
> > +	      ...
> > +	      [prefix]-endian = 'native';
> > +};
> 
> If the device is LE, then surely we should describe the device as LE.
> The kernel knows what endianness it is, might choose to change the CPU
> endianness, but regardless can do the right thing. Telling it a device
> is native is useless unless the device changes endianness with the CPU.
> 

Yes, you are right.

> > +
> > +Scenario 2 : CPU in LE mode & device in BE mode.
> > +dev: dev@40031000 {
> > +	      compatible = "name";
> > +	      reg = <0x40031000 0x1000>;
> > +	      ...
> > +	      [prefix]-endian = 'be';
> > +};
> > +
> > +Scenario 3 : CPU in BE mode & device in BE mode.
> > +dev: dev@40031000 {
> > +	      compatible = "name";
> > +	      reg = <0x40031000 0x1000>;
> > +	      ...
> > +	      [prefix]-endian = 'native';
> > +};
> 
> Likewise.
> 
> Thanks,
> Mark.
> 

RE: [PATCHv2 2/3] regmap: Add the DT binding documentation for endianness

[Li.Xiubo]

> -----Original Message-----
> From: Mark Brown [mailto:broonie@kernel.org]
> Sent: Tuesday, April 15, 2014 5:10 AM
> To: Xiubo Li-B47053
> Cc: linux-doc@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCHv2 2/3] regmap: Add the DT binding documentation for
> endianness
> 
> On Thu, Apr 03, 2014 at 07:04:00AM +0000, Li.Xiubo@freescale.com wrote:
> 
> > > Generally just not
> > > mentioning regmap is better for a binding definition, the binding should
> > > be usable by all OSs and not just Linux.
> 
> > How about move the endianness OF parsing to the driver/of/ ?
> > Is this will be better ?
> 
> Where the code is is sensible enough, it's an issue about how the
> binding documentation was written rather than about the code.

Sorry for late.

Well, I will try to enhance this.

Thanks,

BRs
Xiubo

Re: [PATCHv2 2/3] regmap: Add the DT binding documentation for endianness

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 438 bytes --]

On Thu, Apr 03, 2014 at 07:04:00AM +0000, Li.Xiubo@freescale.com wrote:

> > Generally just not
> > mentioning regmap is better for a binding definition, the binding should
> > be usable by all OSs and not just Linux.

> How about move the endianness OF parsing to the driver/of/ ?
> Is this will be better ?

Where the code is is sensible enough, it's an issue about how the
binding documentation was written rather than about the code.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

RE: [PATCHv2 2/3] regmap: Add the DT binding documentation for endianness

[Li.Xiubo]

> Subject: Re: [PATCHv2 2/3] regmap: Add the DT binding documentation for
> endianness
> 
> On Wed, Apr 02, 2014 at 06:09:08PM +0800, Xiubo Li wrote:
> 
> > +sai2: sai@40031000 {
> > +	      compatible = "fsl,vf610-sai";
> > +	      reg = <0x40031000 0x1000>;
> > +	      ...
> > +	      val-endian = 'LE';
> > +};
> 
> This is mostly OK as a binding (though it should be CCed to the DT list
> and maintiners as all DT bindings should) except using upper case
> doesn't really seem idiomatic for DT - lower case is more normal - 

I will your advices.


> and I
> don't think we can make these properties mandatory in themselves.
> Individual bindings would need to make them mandatory.  It's also odd to
> have a mandatory property which may be absent!

Well, yes, It is.

The absent one is just to compatible with the old drivers.



> 
> It'd probably be better if the binding defined what the default
> endianess was too, or just didn't say what happens in cases where
> nothing is specified, the latter seems better.  

I will think it over carefully.


> Generally just not
> mentioning regmap is better for a binding definition, the binding should
> be usable by all OSs and not just Linux.

How about move the endianness OF parsing to the driver/of/ ?
Is this will be better ?

Thanks,

BRs
Xiubo

Re: [PATCHv2 2/3] regmap: Add the DT binding documentation for endianness

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 919 bytes --]

On Wed, Apr 02, 2014 at 06:09:08PM +0800, Xiubo Li wrote:

> +sai2: sai@40031000 {
> +	      compatible = "fsl,vf610-sai";
> +	      reg = <0x40031000 0x1000>;
> +	      ...
> +	      val-endian = 'LE';
> +};

This is mostly OK as a binding (though it should be CCed to the DT list
and maintiners as all DT bindings should) except using upper case
doesn't really seem idiomatic for DT - lower case is more normal - and I
don't think we can make these properties mandatory in themselves.
Individual bindings would need to make them mandatory.  It's also odd to
have a mandatory property which may be absent!

It'd probably be better if the binding defined what the default
endianess was too, or just didn't say what happens in cases where
nothing is specified, the latter seems better.  Generally just not
mentioning regmap is better for a binding definition, the binding should
be usable by all OSs and not just Linux.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[PATCHv2 2/3] regmap: Add the DT binding documentation for endianness

[Xiubo Li]

Signed-off-by: Xiubo Li <Li.Xiubo@freescale.com>
---
 .../bindings/regmap/regmap-endianness.txt          | 49 ++++++++++++++++++++++
 1 file changed, 49 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/regmap/regmap-endianness.txt

diff --git a/Documentation/devicetree/bindings/regmap/regmap-endianness.txt b/Documentation/devicetree/bindings/regmap/regmap-endianness.txt
new file mode 100644
index 0000000..045d347
--- /dev/null
+++ b/Documentation/devicetree/bindings/regmap/regmap-endianness.txt
@@ -0,0 +1,49 @@
+Device-Tree bindings for regmap endianness
+
+Required properties:
+- reg-endian: Register endianness, this string property could be absent
+  as default endianness, or must be one of 'BE', 'LE' and 'NT'.
+- val-endian: Value endianness, this string property could be absent as
+  default endianness, or must be one of 'BE', 'LE' and 'NT'.
+
+The Endianness flags supported by regmap:
+
+DT properties           Macros
+----------------------------------------
+    'LE'          REGMAP_ENDIAN_LITTLE
+    'BE'          REGMAP_ENDIAN_BIG
+    'NT'          REGMAP_ENDIAN_NATIVE
+    Absent        REGMAP_ENDIAN_DEFAULT
+
+Examples:
+Case 1 : CPU in LE mode & SAI device in BE mode, using mmio.
+sai2: sai@40031000 {
+	      compatible = "fsl,vf610-sai";
+	      reg = <0x40031000 0x1000>;
+	      ...
+	      val-endian = 'BE';
+};
+
+Case 2 : CPU in BE mode & SAI device in LE mode, using mmio.
+sai2: sai@40031000 {
+	      compatible = "fsl,vf610-sai";
+	      reg = <0x40031000 0x1000>;
+	      ...
+	      val-endian = 'LE';
+};
+
+Case 3 : CPU in LE mode & SAI device in LE mode, using mmio.
+sai2: sai@40031000 {
+	      compatible = "fsl,vf610-sai";
+	      reg = <0x40031000 0x1000>;
+	      ...
+	      val-endian = 'NT'; or just absent.
+};
+
+Case 4 : CPU in BE mode & SAI device in BE mode, using mmio.
+sai2: sai@40031000 {
+	      compatible = "fsl,vf610-sai";
+	      reg = <0x40031000 0x1000>;
+	      ...
+	      val-endian = 'NT'; or just absent.
+};
-- 
1.8.4