[PATCHv5,09/10] DTS: ARM: OMAP3-N900: Add SSI support

Commit Message

Sebastian Reichel May 10, 2014, 4:37 p.m. UTC

Add SSI device tree data for OMAP3 and Nokia N900.

Signed-off-by: Sebastian Reichel <[e-mail]>
Reviewed-by: Pavel Machek <[e-mail]>
Tested-By: Ivaylo Dimitrov <[e-mail]>
---
 arch/arm/boot/dts/omap3-n900.dts | 24 +++++++++++++++++++++
 arch/arm/boot/dts/omap3.dtsi     | 45 ++++++++++++++++++++++++++++++++++++++++
 arch/arm/boot/dts/omap34xx.dtsi  | 11 ++++++++++
 arch/arm/boot/dts/omap36xx.dtsi  | 11 ++++++++++
 4 files changed, 91 insertions(+)

Comments

Tony Lindgren May 14, 2014, 9:55 p.m. UTC | #1

* Sebastian Reichel <[e-mail]> [140510 09:40]:
> Add SSI device tree data for OMAP3 and Nokia N900.

Picking this patch into omap-for-v3.16/dt thanks.

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Tony Lindgren May 20, 2014, 12:35 a.m. UTC | #2

* Tony Lindgren <[e-mail]> [140514 14:57]:
> * Sebastian Reichel <[e-mail]> [140510 09:40]:
> > Add SSI device tree data for OMAP3 and Nokia N900.
> 
> Picking this patch into omap-for-v3.16/dt thanks.

Just noticed that this patch seems to somehow break idle
modes on n900, so dropping both dts changes for now.

Basically the n900 debug LEDs won't ever go off with
these two dts patches enabled, even without the modem
drivers loaded. I did not dig deeper, but it's probably
something related to hwmod using this data for some
settings.

Sorry did not notice it earlier as I did not have the
PM regression fix patches merged with my testing branch.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Sebastian Reichel May 21, 2014, 6:25 p.m. UTC | #3

Hi,

On Mon, May 19, 2014 at 05:35:39PM -0700, Tony Lindgren wrote:
> * Tony Lindgren <[e-mail]> [140514 14:57]:
> > * Sebastian Reichel <[e-mail]> [140510 09:40]:
> > > Add SSI device tree data for OMAP3 and Nokia N900.
> > 
> > Picking this patch into omap-for-v3.16/dt thanks.
> 
> Just noticed that this patch seems to somehow break idle
> modes on n900, so dropping both dts changes for now.
> 
> Basically the n900 debug LEDs won't ever go off with
> these two dts patches enabled, even without the modem
> drivers loaded. I did not dig deeper, but it's probably
> something related to hwmod using this data for some
> settings.

Is hwmod data interpreted at all without the DT entries?
The hwmod data may be wrong. The information from commit
398917ce161e10d3c66afaefdb89c73c64c4b02d was simply
interpolated from all information I found. The OMAP3
public TRM does not contain *any* information about the
ssi IP-Core.

> Sorry did not notice it earlier as I did not have the
> PM regression fix patches merged with my testing branch.

I hoped to see working modem in 3.16, which will probably
be used for the next Debian stable :(

-- Sebastian

Tony Lindgren May 21, 2014, 6:43 p.m. UTC | #4

* Sebastian Reichel <[e-mail]> [140521 11:26]:
> Hi,
> 
> On Mon, May 19, 2014 at 05:35:39PM -0700, Tony Lindgren wrote:
> > * Tony Lindgren <[e-mail]> [140514 14:57]:
> > > * Sebastian Reichel <[e-mail]> [140510 09:40]:
> > > > Add SSI device tree data for OMAP3 and Nokia N900.
> > > 
> > > Picking this patch into omap-for-v3.16/dt thanks.
> > 
> > Just noticed that this patch seems to somehow break idle
> > modes on n900, so dropping both dts changes for now.
> > 
> > Basically the n900 debug LEDs won't ever go off with
> > these two dts patches enabled, even without the modem
> > drivers loaded. I did not dig deeper, but it's probably
> > something related to hwmod using this data for some
> > settings.
> 
> Is hwmod data interpreted at all without the DT entries?

Yes for autoidling unused devices. We parse that with
omap_device_build_from_dt().

> The hwmod data may be wrong. The information from commit
> 398917ce161e10d3c66afaefdb89c73c64c4b02d was simply
> interpolated from all information I found. The OMAP3
> public TRM does not contain *any* information about the
> ssi IP-Core.

It's probably something with the sysc or idlemodes that
keeps things from idling. Maybe wrong address? Or wrong
flags? I'm pretty sure it was the first .dts patch out of
these two as the second one alone did not apply.
 
> > Sorry did not notice it earlier as I did not have the
> > PM regression fix patches merged with my testing branch.
> 
> I hoped to see working modem in 3.16, which will probably
> be used for the next Debian stable :(

That would indeed be nice, let's try to debug it as we
still have few days. I'm finally able to test for PM
regressions with DT patches, too bad we did not have
that earlier because of multiple issues.

Anyways, this dts issue should not prevent merging the
driver changes, I'm all for that!

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Sebastian Reichel May 21, 2014, 8:09 p.m. UTC | #5

Hi,

On Wed, May 21, 2014 at 11:43:19AM -0700, Tony Lindgren wrote:
> > > Just noticed that this patch seems to somehow break idle
> > > modes on n900, so dropping both dts changes for now.
> > > 
> > > Basically the n900 debug LEDs won't ever go off with
> > > these two dts patches enabled, even without the modem
> > > drivers loaded. I did not dig deeper, but it's probably
> > > something related to hwmod using this data for some
> > > settings.
> > 
> > Is hwmod data interpreted at all without the DT entries?
> 
> Yes for autoidling unused devices. We parse that with
> omap_device_build_from_dt().

That function seems to parse DT stuff. What I meant was
not without the *driver*, but without the *DT entry*.

I think the hwmod entries are completly ignored until there
is a DT device?

> > The hwmod data may be wrong. The information from commit
> > 398917ce161e10d3c66afaefdb89c73c64c4b02d was simply
> > interpolated from all information I found. The OMAP3
> > public TRM does not contain *any* information about the
> > ssi IP-Core.
> 
> It's probably something with the sysc or idlemodes that
> keeps things from idling. Maybe wrong address? Or wrong
> flags? I'm pretty sure it was the first .dts patch out of
> these two as the second one alone did not apply.
>  
> > > Sorry did not notice it earlier as I did not have the
> > > PM regression fix patches merged with my testing branch.
> > 
> > I hoped to see working modem in 3.16, which will probably
> > be used for the next Debian stable :(
> 
> That would indeed be nice, let's try to debug it as we
> still have few days.

I will have a look at it now.

> I'm finally able to test for PM regressions with DT patches,
> too > bad we did not have that earlier because of multiple issues.

Yes. More time would have been nice.

> Anyways, this dts issue should not prevent merging the
> driver changes, I'm all for that!

Of course, driver changes are unrelated. They are already
in linux-next btw.

-- Sebastian

Tony Lindgren May 21, 2014, 9:09 p.m. UTC | #6

* Sebastian Reichel <[e-mail]> [140521 13:10]:
> Hi,
> 
> On Wed, May 21, 2014 at 11:43:19AM -0700, Tony Lindgren wrote:
> > > > Just noticed that this patch seems to somehow break idle
> > > > modes on n900, so dropping both dts changes for now.
> > > > 
> > > > Basically the n900 debug LEDs won't ever go off with
> > > > these two dts patches enabled, even without the modem
> > > > drivers loaded. I did not dig deeper, but it's probably
> > > > something related to hwmod using this data for some
> > > > settings.
> > > 
> > > Is hwmod data interpreted at all without the DT entries?
> > 
> > Yes for autoidling unused devices. We parse that with
> > omap_device_build_from_dt().
> 
> That function seems to parse DT stuff. What I meant was
> not without the *driver*, but without the *DT entry*.
> 
> I think the hwmod entries are completly ignored until there
> is a DT device?

Yes for device tree based booting. They get initialized
based on the ti,hwmods property. Posted a suggested fix,
you've probably seen it by now :)

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Patch

diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts
index 1a57b61..ef8b241 100644
--- a/arch/arm/boot/dts/omap3-n900.dts
+++ b/arch/arm/boot/dts/omap3-n900.dts
@@ -173,6 +173,19 @@ 
 			0x0da (PIN_OUTPUT | MUX_MODE1)   /* dss_data23.sdi_clkn */
 		>;
 	};
+
+	ssi_pins: pinmux_ssi {
+		pinctrl-single,pins = <
+			0x150 (PIN_INPUT_PULLUP | MUX_MODE1)	/* ssi1_rdy_tx */
+			0x14e (PIN_OUTPUT | MUX_MODE1)		/* ssi1_flag_tx */
+			0x152 (PIN_INPUT | WAKEUP_EN | MUX_MODE4) /* ssi1_wake_tx (cawake) */
+			0x14c (PIN_OUTPUT | MUX_MODE1)		/* ssi1_dat_tx */
+			0x154 (PIN_INPUT | MUX_MODE1)		/* ssi1_dat_rx */
+			0x156 (PIN_INPUT | MUX_MODE1)		/* ssi1_flag_rx */
+			0x158 (PIN_OUTPUT | MUX_MODE1)		/* ssi1_rdy_rx */
+			0x15a (PIN_OUTPUT | MUX_MODE1)		/* ssi1_wake */
+		>;
+	};
 };
 
 &i2c1 {
@@ -662,3 +675,14 @@ 
 		};
 	};
 };
+
+&ssi_port1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&ssi_pins>;
+
+	ti,ssi-cawake-gpio = <&gpio5 23 GPIO_ACTIVE_HIGH>; /* 151 */
+};
+
+&ssi_port2 {
+	status = "disabled";
+};
\ No newline at end of file
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index acb9019..b8cd2d7 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -757,6 +757,51 @@ 
 				clock-names = "fck";
 			};
 		};
+
+		ssi: ssi-controller@48058000 {
+			compatible = "ti,omap3-ssi";
+			ti,hwmods = "ssi";
+
+			status = "disabled";
+
+			reg = <0x48058000 0x1000>,
+			      <0x48059000 0x1000>;
+			reg-names = "sys",
+				    "gdd";
+
+			interrupts = <71>;
+			interrupt-names = "gdd_mpu";
+
+			#address-cells = <1>;
+			#size-cells = <1>;
+			ranges;
+
+			ssi_port1: ssi-port@4805a000 {
+				compatible = "ti,omap3-ssi-port";
+
+				reg = <0x4805a000 0x800>,
+				      <0x4805a800 0x800>;
+				reg-names = "tx",
+					    "rx";
+
+				interrupt-parent = <&intc>;
+				interrupts = <67>,
+					     <68>;
+			};
+
+			ssi_port2: ssi-port@4805b000 {
+				compatible = "ti,omap3-ssi-port";
+
+				reg = <0x4805b000 0x800>,
+				      <0x4805b800 0x800>;
+				reg-names = "tx",
+					    "rx";
+
+				interrupt-parent = <&intc>;
+				interrupts = <69>,
+					     <70>;
+			};
+		};
 	};
 };
 
diff --git a/arch/arm/boot/dts/omap34xx.dtsi b/arch/arm/boot/dts/omap34xx.dtsi
index 2e92360..3819c1e 100644
--- a/arch/arm/boot/dts/omap34xx.dtsi
+++ b/arch/arm/boot/dts/omap34xx.dtsi
@@ -40,6 +40,17 @@ 
 	};
 };
 
+&ssi {
+	status = "ok";
+
+	clocks = <&ssi_ssr_fck>,
+		 <&ssi_sst_fck>,
+		 <&ssi_ick>;
+	clock-names = "ssi_ssr_fck",
+		      "ssi_sst_fck",
+		      "ssi_ick";
+};
+
 /include/ "omap34xx-omap36xx-clocks.dtsi"
 /include/ "omap36xx-omap3430es2plus-clocks.dtsi"
 /include/ "omap36xx-am35xx-omap3430es2plus-clocks.dtsi"
diff --git a/arch/arm/boot/dts/omap36xx.dtsi b/arch/arm/boot/dts/omap36xx.dtsi
index 22cf464..541704a 100644
--- a/arch/arm/boot/dts/omap36xx.dtsi
+++ b/arch/arm/boot/dts/omap36xx.dtsi
@@ -78,6 +78,17 @@ 
 	clock-names = "fck", "tv_dac_clk";
 };
 
+&ssi {
+	status = "ok";
+
+	clocks = <&ssi_ssr_fck>,
+		 <&ssi_sst_fck>,
+		 <&ssi_ick>;
+	clock-names = "ssi_ssr_fck",
+		      "ssi_sst_fck",
+		      "ssi_ick";
+};
+
 /include/ "omap34xx-omap36xx-clocks.dtsi"
 /include/ "omap36xx-omap3430es2plus-clocks.dtsi"
 /include/ "omap36xx-am35xx-omap3430es2plus-clocks.dtsi"