[PATCH v2] ARM:MXS: Initial support for the Crystalfontz CFA-10036

Hi everyone,

This is the second version for the initial support for the
Crystalfontz CFA-10036 module.

The module basically has a iMX28 SoC, plus a micro-SD slot, 3 pins to
access the DUART, a USB OTG port, a OLED screen using the Solomon
SSD1307 controller over I2C and a 200-pins SODIMM port to plug an
expansion board.

Support for this board and the additional devices will come
eventually.

For now, only the DUART and the MMC controller are used.

What changed from v1:
  * MMC now works thanks to Shawn Guo
  * Removed the board file
  * Moved alternate muxing options for the imx28 to the DTSI

Thanks,
Maxime

Signed-off-by: Maxime Ripard <redacted>
---
 arch/arm/boot/dts/imx28.dtsi |   19 ++++++++++++++++++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/imx28.dtsi b/arch/arm/boot/dts/imx28.dtsi
index 4634cb8..babc604 100644
--- a/arch/arm/boot/dts/imx28.dtsi
+++ b/arch/arm/boot/dts/imx28.dtsi

@@ -159,7 +159,7 @@
 					#interrupt-cells = <2>;
 				};
 
-				duart_pins_a: duart at 0 {
+				duart_pins_a: duart-a at 0 {
 					reg = <0>;
 					fsl,pinmux-ids = <0x3102 0x3112>;
 					fsl,drive-strength = <0>;

@@ -167,6 +167,14 @@
 					fsl,pull-up = <0>;
 				};
 
+				duart_pins_b: duart-b at 0 {
+					reg = <0>;
+					fsl,pinmux-ids = <0x3022 0x3032>;
+					fsl,drive-strength = <0>;
+					fsl,voltage = <1>;
+					fsl,pull-up = <0>;
+				};
+
 				mac0_pins_a: mac0 at 0 {
 					reg = <0>;
 					fsl,pinmux-ids = <0x4000 0x4010 0x4020

@@ -196,6 +204,15 @@
 					fsl,pull-up = <1>;
 				};
 
+				mmc0_4bit_pins_a: mmc0-4bit at 0 {
+					reg = <0>;
+					fsl,pinmux-ids = <0x2000 0x2010 0x2020
+						0x2030 0x2080 0x2090 0x20a0>;
+					fsl,drive-strength = <1>;
+					fsl,voltage = <1>;
+					fsl,pull-up = <1>;
+				};
+
 				mmc0_cd_cfg: mmc0-cd-cfg {
 					fsl,pinmux-ids = <0x2090>;
 					fsl,pull-up = <0>;

-- 
1.7.9.5

Signed-off-by: Maxime Ripard <redacted>

Cc: Brian Lily <redacted>
---
 arch/arm/boot/dts/cfa10036.dts |   43 ++++++++++++++++++++++++++++++++++++++++
 1 file changed, 43 insertions(+)
 create mode 100644 arch/arm/boot/dts/cfa10036.dts

diff --git a/arch/arm/boot/dts/cfa10036.dts b/arch/arm/boot/dts/cfa10036.dts
new file mode 100644
index 0000000..28b9326
--- /dev/null
+++ b/arch/arm/boot/dts/cfa10036.dts

@@ -0,0 +1,43 @@
+/*
+ * Copyright 2012 Free Electrons
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+/dts-v1/;
+/include/ "imx28.dtsi"
+
+/ {
+	model = "Crystalfontz CFA-10036 Board";
+	compatible = "crystalfontz,cfa10036", "fsl,imx28";
+
+	memory {
+		reg = <0x40000000 0x08000000>;
+	};
+
+	apb at 80000000 {
+		apbh at 80000000 {
+			ssp0: ssp at 80010000 {
+				compatible = "fsl,imx28-mmc";
+				pinctrl-names = "default";
+				pinctrl-0 = <&mmc0_4bit_pins_a
+					&mmc0_cd_cfg &mmc0_sck_cfg>;
+				bus-width = <4>;
+				status = "okay";
+			};
+		};
+
+		apbx at 80040000 {
+			duart: serial at 80074000 {
+				pinctrl-names = "default";
+				pinctrl-0 = <&duart_pins_b>;
+				status = "okay";
+			};
+		};
+	};
+};

-- 
1.7.9.5

Suggested subject prefix "ARM: dts: imx28: ..."

On Fri, Jun 22, 2012 at 11:14:53AM +0200, Maxime Ripard wrote:

Leave this line unchanged ...

... and have the new mux option for duart like

				duart_pins_b: duart at 1 {
					reg = <1>;

then, pinctrl system will be able to report there are 2 pin groups for
function "duart" in debugfs.

Regards,
Shawn

On Fri, Jun 22, 2012 at 11:14:54AM +0200, Maxime Ripard wrote:

I would like to maintain a explicit list of in-tree boards that imx28
DT machine supports, so please have the compatible string added into
imx28_dt_compat.

Regards,
Shawn

+
+	memory {
+		reg = <0x40000000 0x08000000>;
+	};
+
+	apb at 80000000 {
+		apbh at 80000000 {
+			ssp0: ssp at 80010000 {
+				compatible = "fsl,imx28-mmc";
+				pinctrl-names = "default";
+				pinctrl-0 = <&mmc0_4bit_pins_a
+					&mmc0_cd_cfg &mmc0_sck_cfg>;
+				bus-width = <4>;
+				status = "okay";
+			};
+		};
+
+		apbx at 80040000 {
+			duart: serial at 80074000 {
+				pinctrl-names = "default";
+				pinctrl-0 = <&duart_pins_b>;
+				status = "okay";
+			};
+		};
+	};
+};
-- 
1.7.9.5

Hello Shawn,

Le Mon, 25 Jun 2012 23:50:49 +0800,
Shawn Guo [off-list ref] a ?crit :

then, pinctrl system will be able to report there are 2 pin groups for
function "duart" in debugfs.

Ah nice, this explains why the mxs pinctrl driver creates a separate
group for each pinctrl DT subnode, but only creates a new function when
the name changes.

However, how would the mxs pinctrl driver handle the following case:

	pinctrl {
		duart_pins_a: duart at 0 {
			...
		}
		something_pins: something at 0 {
			...
		}
		duart_pins_b: duart at 1 {
			...
		}
	}

Reading the driver code, I have the feeling that the logic that creates
the functions will only work if the different groups for a given
function are given as consecutive subnodes in the DT. Is this correct?

Regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

Hi,

Le 25/06/2012 17:50, Shawn Guo a ?crit :

Suggested subject prefix "ARM: dts: imx28: ..."

Ok.

On Fri, Jun 22, 2012 at 11:14:53AM +0200, Maxime Ripard wrote:

quoted

Signed-off-by: Maxime Ripard <redacted>
---
 arch/arm/boot/dts/imx28.dtsi |   19 ++++++++++++++++++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/imx28.dtsi b/arch/arm/boot/dts/imx28.dtsi
index 4634cb8..babc604 100644
--- a/arch/arm/boot/dts/imx28.dtsi
+++ b/arch/arm/boot/dts/imx28.dtsi

@@ -159,7 +159,7 @@
 					#interrupt-cells = <2>;
 				};
 
-				duart_pins_a: duart at 0 {
+				duart_pins_a: duart-a at 0 {

Leave this line unchanged ...

quoted

 					reg = <0>;
 					fsl,pinmux-ids = <0x3102 0x3112>;
 					fsl,drive-strength = <0>;

@@ -167,6 +167,14 @@
 					fsl,pull-up = <0>;
 				};
 
+				duart_pins_b: duart-b at 0 {
+					reg = <0>;

... and have the new mux option for duart like

				duart_pins_b: duart at 1 {
					reg = <1>;

then, pinctrl system will be able to report there are 2 pin groups for
function "duart" in debugfs.

Ok.

I have two questions here though.

First, I'm worrying a bit about the fact that the duart_pins_b is
actually the first pin groups in the muxing selection register by index,
before duart_pins_a. It's a bit confusing, but it would imply that we
would need to rename duart_pins_a to duart_pins_b, and change all the
references to it as well, but I can definitely send a patch for it. What
is your opinion ?

Secondly, why do we need to change the reg field as well ?

Thanks,
Maxime

-- 
Maxime Ripard, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

On Tue, Jun 26, 2012 at 11:02:02AM +0200, Thomas Petazzoni wrote:

Hello Shawn,

Le Mon, 25 Jun 2012 23:50:49 +0800,
Shawn Guo [off-list ref] a ?crit :

quoted

then, pinctrl system will be able to report there are 2 pin groups for
function "duart" in debugfs.

Ah nice, this explains why the mxs pinctrl driver creates a separate
group for each pinctrl DT subnode, but only creates a new function when
the name changes.

However, how would the mxs pinctrl driver handle the following case:

	pinctrl {
		duart_pins_a: duart at 0 {
			...
		}
		something_pins: something at 0 {
			...
		}
		duart_pins_b: duart at 1 {
			...
		}
	}

Reading the driver code, I have the feeling that the logic that creates
the functions will only work if the different groups for a given
function are given as consecutive subnodes in the DT. Is this correct?

That's correct.  We really need to put the pin groups for the same
function together and have then sorted in "reg" value.

-- 
Regards,
Shawn

On Tue, Jun 26, 2012 at 11:42:44AM +0200, Maxime Ripard wrote:

I have two questions here though.

First, I'm worrying a bit about the fact that the duart_pins_b is
actually the first pin groups in the muxing selection register by index,
before duart_pins_a. It's a bit confusing, but it would imply that we
would need to rename duart_pins_a to duart_pins_b, and change all the
references to it as well, but I can definitely send a patch for it. What
is your opinion ?

The numbering of mux options for a function is not meant to match the
register index in any case.  Actually, it's no way to match.  For
example, if pin pair <0x3102 0x3032> is used on one board, how would
you number it?  (Well, the example is odd but it's possible.)

Secondly, why do we need to change the reg field as well ?

We need to use the same node name "duart" for pin groups that are
mux-ed on duart function.  "reg" value is used to distinguish the node
name, as the "reg" value is required to be part of node name.

-- 
Regards,
Shawn