DT Fixes for OMAP4 and OMAP5 boards

tested on Pandaboard ES.

Signed-off-by H. Nikolaus Schaller <[email protected]>

---
 arch/arm/boot/dts/twl6030.dtsi | 6 ++++++
 1 file changed, 6 insertions(+)

arch/arm/boot/dts/twl6030.dtsi +0 -0

index 55eb35f..c45f97f 100644

otherwise we can't define gpio1_wk14

OMAP5 has a register to control if the ckobuffer is enabled and defines the polarity. ckobuffer is required to drive a twl6040 with the system clock. Hence, add the pinctrl,single to the OMAP5 SoC description so that omap5-board-common can set up the ckobuffer as required.

Signed-off-by H. Nikolaus Schaller <[email protected]>

---
 arch/arm/boot/dts/omap5.dtsi | 10 ++++++++++
 1 file changed, 10 insertions(+)

arch/arm/boot/dts/omap5.dtsi +10 -0

index 120b6b8..1d9050f 100644
@@ -277,6 +277,16 @@
 				pinctrl-single,register-width = <16>;
 				pinctrl-single,function-mask = <0x7fff>;
 			};
+
+			omap5_control_ckobuffer: pinmux@cdb4 {
+				compatible = "ti,omap5-padconf",
+					     "pinctrl-single";
+				reg = <0xcdb4 4>;
+				#address-cells = <1>;
+				#size-cells = <0>;
+				pinctrl-single,register-width = <32>;
+				pinctrl-single,function-mask = <0xf0000000>;
+			};
 		};
 
 		ocmcram: ocmcram@40300000 {

Signature · 1 line

2.7.3

Am 26.04.2016 um 19:27 schrieb Tony Lindgren <[email protected]>:

Tero,

Quoted 5 lines · H. Nikolaus Schaller

OMAP5 has a register to control if the ckobuffer is enabled and defines the polarity. ckobuffer is required to drive a twl6040 with the system clock. Hence, add the pinctrl,single to the OMAP5 SoC description so that omap5-board-common can set up the ckobuffer as required.

Is this really a mux or should it be a mux clock?

Regards,

Tony

Quoted 25 lines

Signed-off-by H. Nikolaus Schaller <[email protected]>

---
arch/arm/boot/dts/omap5.dtsi | 10 ++++++++++

1 file changed, 10 insertions(+)

arch/arm/boot/dts/omap5.dtsi +10 -0

index 120b6b8..1d9050f 100644
@@ -277,6 +277,16 @@
 				pinctrl-single,register-width = <16>;
 				pinctrl-single,function-mask = <0x7fff>;
 			};
+
+			omap5_control_ckobuffer: pinmux@cdb4 {
+				compatible = "ti,omap5-padconf",
+					     "pinctrl-single";
+				reg = <0xcdb4 4>;
+				#address-cells = <1>;
+				#size-cells = <0>;
+				pinctrl-single,register-width = <32>;
+				pinctrl-single,function-mask = <0xf0000000>;
+			};
 		};
 

Quoted 4 lines

arch/arm/boot/dts/omap5.dtsi +0 -0

 		ocmcram: ocmcram@40300000 {

Signature · 1 line

2.7.3

Quoted 5 lines

Am 26.04.2016 um 19:27 schrieb Tony Lindgren <[email protected]>:

Tero,

Quoted 8 lines

Quoted 5 lines · H. Nikolaus Schaller

OMAP5 has a register to control if the ckobuffer is enabled and defines the polarity. ckobuffer is required to drive a twl6040 with the system clock. Hence, add the pinctrl,single to the OMAP5 SoC description so that omap5-board-common can set up the ckobuffer as required.

Is this really a mux or should it be a mux clock?

It is a pinmux setting for the clock out buffer to choose what signal (and polarity) is presented on the fref_xtal_clk pad.

The register is part of the CTRL_MODULE_WKUP.
The clock signal is the xtal master clock of the whole SoC.

Although there is a bit to choose an alternate clock, there is no alternate in the OMAP5 silicon.

Therefore I would say it is about padconf and not clock or clock mux related.

It just happens to be a clock signal which can be routed to this pad.

BR,
Nikolaus

Quoted 34 lines

Regards,

Tony

Quoted 29 lines

Signed-off-by H. Nikolaus Schaller <[email protected]>

---
arch/arm/boot/dts/omap5.dtsi | 10 ++++++++++

1 file changed, 10 insertions(+)

arch/arm/boot/dts/omap5.dtsi +10 -1

index 120b6b8..1d9050f 100644
@@ -277,6 +277,16 @@
 				pinctrl-single,register-width = <16>;
 				pinctrl-single,function-mask = <0x7fff>;
 			};
+
+			omap5_control_ckobuffer: pinmux@cdb4 {
+				compatible = "ti,omap5-padconf",
+					     "pinctrl-single";
+				reg = <0xcdb4 4>;
+				#address-cells = <1>;
+				#size-cells = <0>;
+				pinctrl-single,register-width = <32>;
+				pinctrl-single,function-mask = <0xf0000000>;
+			};
 		};
 
 		ocmcram: ocmcram@40300000 {
--

2.7.3

Am 27.04.2016 um 14:31 schrieb Tero Kristo <[email protected]>:

Quoted 23 lines · H. Nikolaus Schaller

Quoted 5 lines

Am 26.04.2016 um 19:27 schrieb Tony Lindgren <[email protected]>:

Tero,

Quoted 8 lines

Quoted 5 lines · H. Nikolaus Schaller

OMAP5 has a register to control if the ckobuffer is enabled and defines the polarity. ckobuffer is required to drive a twl6040 with the system clock. Hence, add the pinctrl,single to the OMAP5 SoC description so that omap5-board-common can set up the ckobuffer as required.

Is this really a mux or should it be a mux clock?

It is a pinmux setting for the clock out buffer to choose what signal (and polarity) is presented on the fref_xtal_clk pad.

The register is part of the CTRL_MODULE_WKUP.
The clock signal is the xtal master clock of the whole SoC.

Although there is a bit to choose an alternate clock, there is no alternate in the OMAP5 silicon.

Quoted 5 lines

Therefore I would say it is about padconf and not clock or clock mux related.

It just happens to be a clock signal which can be routed to this pad.

The two could very well be implemented as clock nodes, a mux and a gate. This would describe the hardware functionality better imo, if the assumptions made here are correct. Implementing the control as pinctrl hacks looks rather weird to me.

I could not find any documentation related to the ckobuffer usage though,

maybe Peter can provide some insight?
I think you spent some considerable time bringing up twl6040 a few years back...

-Tero

Quoted 40 lines

BR,
Nikolaus

Quoted 34 lines

Regards,

Tony

Quoted 29 lines

Signed-off-by H. Nikolaus Schaller <[email protected]>

---
arch/arm/boot/dts/omap5.dtsi | 10 ++++++++++

1 file changed, 10 insertions(+)

arch/arm/boot/dts/omap5.dtsi +10 -1

index 120b6b8..1d9050f 100644
@@ -277,6 +277,16 @@
 				pinctrl-single,register-width = <16>;
 				pinctrl-single,function-mask = <0x7fff>;
 			};
+
+			omap5_control_ckobuffer: pinmux@cdb4 {
+				compatible = "ti,omap5-padconf",
+					     "pinctrl-single";
+				reg = <0xcdb4 4>;
+				#address-cells = <1>;
+				#size-cells = <0>;
+				pinctrl-single,register-width = <32>;
+				pinctrl-single,function-mask = <0xf0000000>;
+			};
 		};
 
 		ocmcram: ocmcram@40300000 {
--

2.7.3

Quoted 30 lines

Am 27.04.2016 um 14:31 schrieb Tero Kristo <[email protected]>:

Quoted 26 lines · H. Nikolaus Schaller

Quoted 5 lines

Am 26.04.2016 um 19:27 schrieb Tony Lindgren <[email protected]>:

Tero,

Quoted 8 lines

Quoted 5 lines · H. Nikolaus Schaller

OMAP5 has a register to control if the ckobuffer is enabled and defines the polarity. ckobuffer is required to drive a twl6040 with the system clock. Hence, add the pinctrl,single to the OMAP5 SoC description so that omap5-board-common can set up the ckobuffer as required.

Is this really a mux or should it be a mux clock?

It is a pinmux setting for the clock out buffer to choose what signal (and polarity) is presented on the fref_xtal_clk pad.

The register is part of the CTRL_MODULE_WKUP.
The clock signal is the xtal master clock of the whole SoC.

Although there is a bit to choose an alternate clock, there is no alternate in the OMAP5 silicon.

Therefore I would say it is about padconf and not clock or clock mux related.

Quoted 4 lines

Quoted 2 lines

It just happens to be a clock signal which can be routed to this pad.

The two could very well be implemented as clock nodes, a mux and a gate. This would describe the hardware functionality better imo, if the assumptions made here are correct. Implementing the control as pinctrl hacks looks rather weird to me.

Why do you consider it a "pinctrl hack"? IMHO it is not a hack, but 100% proper use of pinctrl.

The control register for the clock output buffer is part of the CTRL_MODULE_WKUP, which includes the well known pin controls of gpio1_wk but also this ckobuffer control. So it is grouped with these in a single control register block of the SoC. See "19.6.5.1 CTRL_MODULE_WKUP_PAD" of the TRM.

And IMHO, the naming "buffer" indicates that it controls the pad buffer (like all pinmux) and not the clock.

Yes, of course if can be described differently, as you propose. And one might argue that the twl6040 might want to request its master clock input (19.2 MHz) which could turn on the buffer on demand.

The question it raises to me are:
* isn't it "overkill" to describe a static pinmux register setup (it does not need to be turned on/off during operation) as mux (without function in OMAP5 SoC) + gate?

* does it require new driver code to correctly write to the control register?

* does it work if the twl6040 is hooked up differently?

Quoted 3 lines

I could not find any documentation related to the ckobuffer usage though,

On the EVM it is the FREF_XTAL_OUT (Ball L33) which goes as signal H_SYSCLK through a jumper (R87) and then as signal P_SYSCLK to the MCLK (Ball K7) of the twl6040.

Description of FREF_XTAL_OUT is in section 3.3.1 of the TRM.

Quoted 3 lines

maybe Peter can provide some insight?
I think you spent some considerable time bringing up twl6040 a few years back...

Yes, that would certainly help to decide how to proceed.

Quoted 4 lines

-Tero

BR and thanks,
NIkolaus

Quoted 35 lines

Quoted 35 lines

BR,
Nikolaus

Quoted 30 lines

Regards,

Tony

Quoted 25 lines

Signed-off-by H. Nikolaus Schaller <[email protected]>

---
arch/arm/boot/dts/omap5.dtsi | 10 ++++++++++

1 file changed, 10 insertions(+)

arch/arm/boot/dts/omap5.dtsi +10 -0

index 120b6b8..1d9050f 100644
@@ -277,6 +277,16 @@
 				pinctrl-single,register-width = <16>;
 				pinctrl-single,function-mask = <0x7fff>;
 			};
+
+			omap5_control_ckobuffer: pinmux@cdb4 {
+				compatible = "ti,omap5-padconf",
+					     "pinctrl-single";
+				reg = <0xcdb4 4>;
+				#address-cells = <1>;
+				#size-cells = <0>;
+				pinctrl-single,register-width = <32>;
+				pinctrl-single,function-mask = <0xf0000000>;
+			};
 		};
 

Quoted 6 lines

Quoted 5 lines

Quoted 4 lines

Quoted 4 lines

arch/arm/boot/dts/omap5.dtsi +0 -1

 		ocmcram: ocmcram@40300000 {
--

2.7.3

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

Quoted 38 lines · H. Nikolaus Schaller

Quoted 37 lines

Am 27.04.2016 um 14:31 schrieb Tero Kristo <[email protected]>:

Quoted 20 lines · H. Nikolaus Schaller

Quoted 5 lines

Am 26.04.2016 um 19:27 schrieb Tony Lindgren <[email protected]>:

Tero,

Quoted 8 lines

Quoted 5 lines · H. Nikolaus Schaller

OMAP5 has a register to control if the ckobuffer is enabled and defines the polarity. ckobuffer is required to drive a twl6040 with the system clock. Hence, add the pinctrl,single to the OMAP5 SoC description so that omap5-board-common can set up the ckobuffer as required.

Is this really a mux or should it be a mux clock?

It is a pinmux setting for the clock out buffer to choose what signal (and polarity) is presented on the fref_xtal_clk pad.

The register is part of the CTRL_MODULE_WKUP.
The clock signal is the xtal master clock of the whole SoC.

Quoted 8 lines

Although there is a bit to choose an alternate clock, there is no alternate in the OMAP5 silicon.

Therefore I would say it is about padconf and not clock or clock mux related.

It just happens to be a clock signal which can be routed to this pad.

The two could very well be implemented as clock nodes, a mux and a gate. This would describe the hardware functionality better imo, if the assumptions made here are correct. Implementing the control as pinctrl hacks looks rather weird to me.

Quoted 2 lines

Why do you consider it a "pinctrl hack"? IMHO it is not a hack, but 100% proper use of pinctrl.

It is just the level of abstraction we are talking about here. If it is a clock we are controlling, we should rather control it as a clock (higher level abstraction), not a pin.

Am 27.04.2016 um 16:23 schrieb Peter Ujfalusi <[email protected]>:

Quoted 39 lines · Tero Kristo

Quoted 38 lines · H. Nikolaus Schaller

Quoted 37 lines

Am 27.04.2016 um 14:31 schrieb Tero Kristo <[email protected]>:

Quoted 20 lines · H. Nikolaus Schaller

Quoted 5 lines

Am 26.04.2016 um 19:27 schrieb Tony Lindgren <[email protected]>:

Tero,

Quoted 8 lines

Quoted 5 lines · H. Nikolaus Schaller

OMAP5 has a register to control if the ckobuffer is enabled and defines the polarity. ckobuffer is required to drive a twl6040 with the system clock. Hence, add the pinctrl,single to the OMAP5 SoC description so that omap5-board-common can set up the ckobuffer as required.

Is this really a mux or should it be a mux clock?

It is a pinmux setting for the clock out buffer to choose what signal (and polarity) is presented on the fref_xtal_clk pad.

The register is part of the CTRL_MODULE_WKUP.
The clock signal is the xtal master clock of the whole SoC.

Quoted 8 lines

Although there is a bit to choose an alternate clock, there is no alternate in the OMAP5 silicon.

Therefore I would say it is about padconf and not clock or clock mux related.

It just happens to be a clock signal which can be routed to this pad.

The two could very well be implemented as clock nodes, a mux and a gate. This would describe the hardware functionality better imo, if the assumptions made here are correct. Implementing the control as pinctrl hacks looks rather weird to me.

Quoted 6 lines

Quoted 2 lines

Why do you consider it a "pinctrl hack"? IMHO it is not a hack, but 100% proper use of pinctrl.

It is just the level of abstraction we are talking about here. If it is a clock we are controlling, we should rather control it as a clock (higher level abstraction), not a pin.

I second this. I think it is better to have a simple gate clock and handle only CONTROL_CKOBUFFER:CKOBUFFER_CLK_EN (bit 28) only as the other bits does not have real use.

Then we can add clk API support for this. On most OMAP4 devices the clock is always on,

so the board DTS file need to provide a dummy clock, or we can make the high precision clock also as optional (on panda both OMAP4 and twl6040 uses the same reference clock).

HI,

Quoted 49 lines

Am 27.04.2016 um 16:23 schrieb Peter Ujfalusi <[email protected]>:

Quoted 39 lines · Tero Kristo

Quoted 38 lines · H. Nikolaus Schaller

Quoted 37 lines

Am 27.04.2016 um 14:31 schrieb Tero Kristo <[email protected]>:

Quoted 20 lines · H. Nikolaus Schaller

Quoted 5 lines

Am 26.04.2016 um 19:27 schrieb Tony Lindgren <[email protected]>:

Tero,

Quoted 8 lines

Quoted 5 lines · H. Nikolaus Schaller

OMAP5 has a register to control if the ckobuffer is enabled and defines the polarity. ckobuffer is required to drive a twl6040 with the system clock. Hence, add the pinctrl,single to the OMAP5 SoC description so that omap5-board-common can set up the ckobuffer as required.

Is this really a mux or should it be a mux clock?

It is a pinmux setting for the clock out buffer to choose what signal (and polarity) is presented on the fref_xtal_clk pad.

The register is part of the CTRL_MODULE_WKUP.
The clock signal is the xtal master clock of the whole SoC.

Quoted 8 lines

Although there is a bit to choose an alternate clock, there is no alternate in the OMAP5 silicon.

Therefore I would say it is about padconf and not clock or clock mux related.

It just happens to be a clock signal which can be routed to this pad.

The two could very well be implemented as clock nodes, a mux and a gate. This would describe the hardware functionality better imo, if the assumptions made here are correct. Implementing the control as pinctrl hacks looks rather weird to me.

Quoted 6 lines

Quoted 2 lines

Why do you consider it a "pinctrl hack"? IMHO it is not a hack, but 100% proper use of pinctrl.

It is just the level of abstraction we are talking about here. If it is a clock we are controlling, we should rather control it as a clock (higher level abstraction), not a pin.

Quoted 6 lines

I second this. I think it is better to have a simple gate clock and handle only CONTROL_CKOBUFFER:CKOBUFFER_CLK_EN (bit 28) only as the other bits does not have real use.

Then we can add clk API support for this. On most OMAP4 devices the clock is always on,

this is why I am raising the question if we really want to control it on the omap5 or just turn it on for all omap5 boards like the omap4 appears to do... I.e. if turning the pin on as a pinctrl is IMHO sufficient for all practical purposes.

Quoted 3 lines

so the board DTS file need to provide a dummy clock, or we can make the high precision clock also as optional (on panda both OMAP4 and twl6040 uses the same reference clock).

Hm. It looks as if implementing this (and clock gating) is beyond my experiences. But I am happy to test a proposal on our omap5 board.

BR and thanks,
Nikolaus

Am 28.04.2016 um 10:03 schrieb Tero Kristo <[email protected]>:

Quoted 66 lines · H. Nikolaus Schaller

HI,

Quoted 49 lines

Am 27.04.2016 um 16:23 schrieb Peter Ujfalusi <[email protected]>:

Quoted 39 lines · Tero Kristo

Quoted 38 lines · H. Nikolaus Schaller

Quoted 37 lines

Am 27.04.2016 um 14:31 schrieb Tero Kristo <[email protected]>:

Quoted 20 lines · H. Nikolaus Schaller

Quoted 5 lines

Am 26.04.2016 um 19:27 schrieb Tony Lindgren <[email protected]>:

Tero,

Quoted 8 lines

Quoted 5 lines · H. Nikolaus Schaller

OMAP5 has a register to control if the ckobuffer is enabled and defines the polarity. ckobuffer is required to drive a twl6040 with the system clock. Hence, add the pinctrl,single to the OMAP5 SoC description so that omap5-board-common can set up the ckobuffer as required.

Is this really a mux or should it be a mux clock?

It is a pinmux setting for the clock out buffer to choose what signal (and polarity) is presented on the fref_xtal_clk pad.

The register is part of the CTRL_MODULE_WKUP.
The clock signal is the xtal master clock of the whole SoC.

Quoted 8 lines

Although there is a bit to choose an alternate clock, there is no alternate in the OMAP5 silicon.

Therefore I would say it is about padconf and not clock or clock mux related.

It just happens to be a clock signal which can be routed to this pad.

The two could very well be implemented as clock nodes, a mux and a gate. This would describe the hardware functionality better imo, if the assumptions made here are correct. Implementing the control as pinctrl hacks looks rather weird to me.

Quoted 6 lines

Quoted 2 lines

Why do you consider it a "pinctrl hack"? IMHO it is not a hack, but 100% proper use of pinctrl.

It is just the level of abstraction we are talking about here. If it is a clock we are controlling, we should rather control it as a clock (higher level abstraction), not a pin.

Quoted 6 lines

I second this. I think it is better to have a simple gate clock and handle only CONTROL_CKOBUFFER:CKOBUFFER_CLK_EN (bit 28) only as the other bits does not have real use.

Then we can add clk API support for this. On most OMAP4 devices the clock is always on,

this is why I am raising the question if we really want to control it on the omap5 or just turn it on for all omap5 boards like the omap4 appears to do... I.e. if turning the pin on as a pinctrl is IMHO sufficient for all practical purposes.

Quoted 3 lines

so the board DTS file need to provide a dummy clock, or we can make the high precision clock also as optional (on panda both OMAP4 and twl6040 uses the same reference clock).

Quoted 5 lines

Hm. It looks as if implementing this (and clock gating) is beyond my experiences. But I am happy to test a proposal on our omap5 board.

BR and thanks,
Nikolaus

See the inline patch, this implements the fref_xtal_ck. I had to add some kernel code also to cope with the new SCM area, but the same area can now be accessed via syscon also if needed.

From: Tero Kristo <[email protected]>
Date: Thu, 28 Apr 2016 11:00:57 +0300
Subject: [PATCH] ARM: omap5: add support for fref_xtal_ck

Signed-off-by Tero Kristo <[email protected]>

---

arch/arm/boot/dts/omap5.dtsi           | 22 ++++++++++++++++++++++
arch/arm/boot/dts/omap54xx-clocks.dtsi | 10 ++++++++++
arch/arm/mach-omap2/control.c          | 20 ++++++++++++++++----
include/linux/clk/ti.h                 |  1 +
4 files changed, 49 insertions(+), 4 deletions(-)

arch/arm/boot/dts/omap5.dtsi +22 -0

index 38805eb..bdc6528 100644
@@ -277,6 +277,28 @@
 				pinctrl-single,register-width = <16>;
 				pinctrl-single,function-mask = <0x7fff>;
 			};
+
+			omap5_scm_wkup_pad_conf: omap5_scm_wkup_pad_conf@cda0 {
+				compatible = "ti,omap5-scm-wkup-pad-conf",
+					     "simple-bus";
+				reg = <0xcda0 0x60>;
+				#address-cells = <1>;
+				#size-cells = <1>;
+				ranges = <0 0xcda0 0x60>;
+
+				scm_wkup_pad_conf: scm_conf@0 {
+					compatible = "syscon", "simple-bus";
+					reg = <0x0 0x60>;
+					#address-cells = <1>;
+					#size-cells = <1>;
+					ranges = <0 0x0 0x60>;
+
+					scm_wkup_pad_conf_clocks: clocks@0 {
+						#address-cells = <1>;
+						#size-cells = <0>;
+					};
+				};
+			};
 		};
 
 		ocmcram: ocmcram@40300000 {

arch/arm/boot/dts/omap54xx-clocks.dtsi +10 -0

index 83b425f..f970dac 100644
@@ -1388,3 +1388,13 @@
 		reg = <0x021c>;
 	};
 };
+
+&scm_wkup_pad_conf_clocks {
+	fref_xtal_ck: fref_xtal_ck {
+		#clocks-cells = <0>;
+		compatible = "ti,gate-clock";
+		clocks = <&sys_clkin>;
+		ti,bit-shift = <28>;
+		reg = <0x14>;
+	};
+};

arch/arm/mach-omap2/control.c +16 -4

index 1662071..5956641 100644
@@ -623,6 +623,7 @@ void __init omap3_ctrl_init(void)
 
 struct control_init_data {
 	int index;
+	void __iomem *mem;
 	s16 offset;
 };
 

@@ -635,6 +636,10 @@ static const struct control_init_data omap2_ctrl_data = {
 	.offset = -OMAP2_CONTROL_GENERAL,
 };
 
+static const struct control_init_data ctrl_aux_data = {
+	.index = TI_CLKM_CTRL_AUX,
+};
+
 static const struct of_device_id omap_scrm_dt_match_table[] = {
 	{ .compatible = "ti,am3-scm", .data = &ctrl_data },
 	{ .compatible = "ti,am4-scm", .data = &ctrl_data },

@@ -644,6 +649,7 @@ static const struct of_device_id omap_scrm_dt_match_table[] = {
 	{ .compatible = "ti,dm816-scrm", .data = &ctrl_data },
 	{ .compatible = "ti,omap4-scm-core", .data = &ctrl_data },
 	{ .compatible = "ti,omap5-scm-core", .data = &ctrl_data },
+	{ .compatible = "ti,omap5-scm-wkup-pad-conf", .data = &ctrl_aux_data },
 	{ .compatible = "ti,dra7-scm-core", .data = &ctrl_data },
 	{ }
 };

@@ -660,15 +666,21 @@ int __init omap2_control_base_init(void)
 	struct device_node *np;
 	const struct of_device_id *match;
 	struct control_init_data *data;
+	void __iomem *mem;
 
 	for_each_matching_node_and_match(np, omap_scrm_dt_match_table, &match) {
 		data = (struct control_init_data *)match->data;
 
-		omap2_ctrl_base = of_iomap(np, 0);
-		if (!omap2_ctrl_base)
+		mem = of_iomap(np, 0);
+		if (!mem)
 			return -ENOMEM;
 
-		omap2_ctrl_offset = data->offset;
+		if (data->index == TI_CLKM_CTRL) {
+			omap2_ctrl_base = mem;
+			omap2_ctrl_offset = data->offset;
+		}
+
+		data->mem = mem;
 	}
 
 	return 0;

@@ -713,7 +725,7 @@ int __init omap_control_init(void)
 		} else {
 			/* No scm_conf found, direct access */
 			ret = omap2_clk_provider_init(np, data->index, NULL,
-						      omap2_ctrl_base);
+						      data->mem);
 			if (ret)
 				return ret;
 		}

include/linux/clk/ti.h +1 -0

index dc5164a..be25aa8 100644
@@ -195,6 +195,7 @@ enum {
 	TI_CLKM_PRM,
 	TI_CLKM_SCRM,
 	TI_CLKM_CTRL,
+	TI_CLKM_CTRL_AUX,
 	TI_CLKM_PLLSS,
 	CLK_MAX_MEMMAPS
 };

Hi Tero,

Quoted 72 lines

Am 28.04.2016 um 10:03 schrieb Tero Kristo <[email protected]>:

Quoted 69 lines · H. Nikolaus Schaller

HI,

Quoted 49 lines

Am 27.04.2016 um 16:23 schrieb Peter Ujfalusi <[email protected]>:

Quoted 39 lines · Tero Kristo

Quoted 38 lines · H. Nikolaus Schaller

Quoted 37 lines

Am 27.04.2016 um 14:31 schrieb Tero Kristo <[email protected]>:

Quoted 20 lines · H. Nikolaus Schaller

Quoted 5 lines

Am 26.04.2016 um 19:27 schrieb Tony Lindgren <[email protected]>:

Tero,

Quoted 8 lines

Quoted 5 lines · H. Nikolaus Schaller

OMAP5 has a register to control if the ckobuffer is enabled and defines the polarity. ckobuffer is required to drive a twl6040 with the system clock. Hence, add the pinctrl,single to the OMAP5 SoC description so that omap5-board-common can set up the ckobuffer as required.

Is this really a mux or should it be a mux clock?

It is a pinmux setting for the clock out buffer to choose what signal (and polarity) is presented on the fref_xtal_clk pad.

The register is part of the CTRL_MODULE_WKUP.
The clock signal is the xtal master clock of the whole SoC.

Quoted 8 lines

Although there is a bit to choose an alternate clock, there is no alternate in the OMAP5 silicon.

Therefore I would say it is about padconf and not clock or clock mux related.

It just happens to be a clock signal which can be routed to this pad.

The two could very well be implemented as clock nodes, a mux and a gate. This would describe the hardware functionality better imo, if the assumptions made here are correct. Implementing the control as pinctrl hacks looks rather weird to me.

Quoted 6 lines

Quoted 2 lines

Why do you consider it a "pinctrl hack"? IMHO it is not a hack, but 100% proper use of pinctrl.

It is just the level of abstraction we are talking about here. If it is a clock we are controlling, we should rather control it as a clock (higher level abstraction), not a pin.

Quoted 6 lines

I second this. I think it is better to have a simple gate clock and handle only CONTROL_CKOBUFFER:CKOBUFFER_CLK_EN (bit 28) only as the other bits does not have real use.

Then we can add clk API support for this. On most OMAP4 devices the clock is always on,

this is why I am raising the question if we really want to control it on the omap5 or just turn it on for all omap5 boards like the omap4 appears to do... I.e. if turning the pin on as a pinctrl is IMHO sufficient for all practical purposes.

Quoted 3 lines

so the board DTS file need to provide a dummy clock, or we can make the high precision clock also as optional (on panda both OMAP4 and twl6040 uses the same reference clock).

Hm. It looks as if implementing this (and clock gating) is beyond my experiences. But I am happy to test a proposal on our omap5 board.

Quoted 4 lines

Quoted 2 lines

BR and thanks,
Nikolaus

See the inline patch, this implements the fref_xtal_ck. I had to add some kernel code also to cope with the new SCM area, but the same area can now be accessed via syscon also if needed.

Looks interesting, although quite complex to enable a single SoC pad at boot time...

Will asap study how it works and test. And of course report results.

Thanks and BR,
Nikolaus

Quoted 141 lines

From: Tero Kristo <[email protected]>
Date: Thu, 28 Apr 2016 11:00:57 +0300
Subject: [PATCH] ARM: omap5: add support for fref_xtal_ck

Signed-off-by Tero Kristo <[email protected]>

---

arch/arm/boot/dts/omap5.dtsi           | 22 ++++++++++++++++++++++
arch/arm/boot/dts/omap54xx-clocks.dtsi | 10 ++++++++++
arch/arm/mach-omap2/control.c          | 20 ++++++++++++++++----
include/linux/clk/ti.h                 |  1 +
4 files changed, 49 insertions(+), 4 deletions(-)

arch/arm/boot/dts/omap5.dtsi +22 -0

index 38805eb..bdc6528 100644
@@ -277,6 +277,28 @@
 				pinctrl-single,register-width = <16>;
 				pinctrl-single,function-mask = <0x7fff>;
 			};
+
+			omap5_scm_wkup_pad_conf: omap5_scm_wkup_pad_conf@cda0 {
+				compatible = "ti,omap5-scm-wkup-pad-conf",
+					     "simple-bus";
+				reg = <0xcda0 0x60>;
+				#address-cells = <1>;
+				#size-cells = <1>;
+				ranges = <0 0xcda0 0x60>;
+
+				scm_wkup_pad_conf: scm_conf@0 {
+					compatible = "syscon", "simple-bus";
+					reg = <0x0 0x60>;
+					#address-cells = <1>;
+					#size-cells = <1>;
+					ranges = <0 0x0 0x60>;
+
+					scm_wkup_pad_conf_clocks: clocks@0 {
+						#address-cells = <1>;
+						#size-cells = <0>;
+					};
+				};
+			};
 		};
 
 		ocmcram: ocmcram@40300000 {

arch/arm/boot/dts/omap54xx-clocks.dtsi +10 -0

index 83b425f..f970dac 100644
@@ -1388,3 +1388,13 @@
 		reg = <0x021c>;
 	};
 };
+
+&scm_wkup_pad_conf_clocks {
+	fref_xtal_ck: fref_xtal_ck {
+		#clocks-cells = <0>;
+		compatible = "ti,gate-clock";
+		clocks = <&sys_clkin>;
+		ti,bit-shift = <28>;
+		reg = <0x14>;
+	};
+};

arch/arm/mach-omap2/control.c +16 -4

index 1662071..5956641 100644
@@ -623,6 +623,7 @@ void __init omap3_ctrl_init(void)
 
 struct control_init_data {
 	int index;
+	void __iomem *mem;
 	s16 offset;
 };
 

@@ -635,6 +636,10 @@ static const struct control_init_data omap2_ctrl_data = {
 	.offset = -OMAP2_CONTROL_GENERAL,
 };
 
+static const struct control_init_data ctrl_aux_data = {
+	.index = TI_CLKM_CTRL_AUX,
+};
+
 static const struct of_device_id omap_scrm_dt_match_table[] = {
 	{ .compatible = "ti,am3-scm", .data = &ctrl_data },
 	{ .compatible = "ti,am4-scm", .data = &ctrl_data },

@@ -644,6 +649,7 @@ static const struct of_device_id omap_scrm_dt_match_table[] = {
 	{ .compatible = "ti,dm816-scrm", .data = &ctrl_data },
 	{ .compatible = "ti,omap4-scm-core", .data = &ctrl_data },
 	{ .compatible = "ti,omap5-scm-core", .data = &ctrl_data },
+	{ .compatible = "ti,omap5-scm-wkup-pad-conf", .data = &ctrl_aux_data },
 	{ .compatible = "ti,dra7-scm-core", .data = &ctrl_data },
 	{ }
 };

@@ -660,15 +666,21 @@ int __init omap2_control_base_init(void)
 	struct device_node *np;
 	const struct of_device_id *match;
 	struct control_init_data *data;
+	void __iomem *mem;
 
 	for_each_matching_node_and_match(np, omap_scrm_dt_match_table, &match) {
 		data = (struct control_init_data *)match->data;
 
-		omap2_ctrl_base = of_iomap(np, 0);
-		if (!omap2_ctrl_base)
+		mem = of_iomap(np, 0);
+		if (!mem)
 			return -ENOMEM;
 
-		omap2_ctrl_offset = data->offset;
+		if (data->index == TI_CLKM_CTRL) {
+			omap2_ctrl_base = mem;
+			omap2_ctrl_offset = data->offset;
+		}
+
+		data->mem = mem;
 	}
 
 	return 0;

@@ -713,7 +725,7 @@ int __init omap_control_init(void)
 		} else {
 			/* No scm_conf found, direct access */
 			ret = omap2_clk_provider_init(np, data->index, NULL,
-						      omap2_ctrl_base);
+						      data->mem);
 			if (ret)
 				return ret;
 		}

include/linux/clk/ti.h +1 -0

index dc5164a..be25aa8 100644
@@ -195,6 +195,7 @@ enum {
 	TI_CLKM_PRM,
 	TI_CLKM_SCRM,
 	TI_CLKM_CTRL,
+	TI_CLKM_CTRL_AUX,
 	TI_CLKM_PLLSS,
 	CLK_MAX_MEMMAPS
 };

Am 28.04.2016 um 15:23 schrieb Tero Kristo <[email protected]>:

Quoted 79 lines · H. Nikolaus Schaller

Hi Tero,

Quoted 76 lines

Am 28.04.2016 um 10:03 schrieb Tero Kristo <[email protected]>:

Quoted 66 lines · H. Nikolaus Schaller

HI,

Quoted 49 lines

Am 27.04.2016 um 16:23 schrieb Peter Ujfalusi <[email protected]>:

Quoted 39 lines · Tero Kristo

Quoted 38 lines · H. Nikolaus Schaller

Quoted 37 lines

Am 27.04.2016 um 14:31 schrieb Tero Kristo <[email protected]>:

Quoted 20 lines · H. Nikolaus Schaller

Quoted 5 lines

Am 26.04.2016 um 19:27 schrieb Tony Lindgren <[email protected]>:

Tero,

Quoted 8 lines

Quoted 5 lines · H. Nikolaus Schaller

OMAP5 has a register to control if the ckobuffer is enabled and defines the polarity. ckobuffer is required to drive a twl6040 with the system clock. Hence, add the pinctrl,single to the OMAP5 SoC description so that omap5-board-common can set up the ckobuffer as required.

Is this really a mux or should it be a mux clock?

It is a pinmux setting for the clock out buffer to choose what signal (and polarity) is presented on the fref_xtal_clk pad.

The register is part of the CTRL_MODULE_WKUP.
The clock signal is the xtal master clock of the whole SoC.

Quoted 8 lines

Although there is a bit to choose an alternate clock, there is no alternate in the OMAP5 silicon.

Therefore I would say it is about padconf and not clock or clock mux related.

It just happens to be a clock signal which can be routed to this pad.

The two could very well be implemented as clock nodes, a mux and a gate. This would describe the hardware functionality better imo, if the assumptions made here are correct. Implementing the control as pinctrl hacks looks rather weird to me.

Quoted 6 lines

Quoted 2 lines

Why do you consider it a "pinctrl hack"? IMHO it is not a hack, but 100% proper use of pinctrl.

It is just the level of abstraction we are talking about here. If it is a clock we are controlling, we should rather control it as a clock (higher level abstraction), not a pin.

Quoted 6 lines

I second this. I think it is better to have a simple gate clock and handle only CONTROL_CKOBUFFER:CKOBUFFER_CLK_EN (bit 28) only as the other bits does not have real use.

Then we can add clk API support for this. On most OMAP4 devices the clock is always on,

this is why I am raising the question if we really want to control it on the omap5 or just turn it on for all omap5 boards like the omap4 appears to do... I.e. if turning the pin on as a pinctrl is IMHO sufficient for all practical purposes.

Quoted 3 lines

so the board DTS file need to provide a dummy clock, or we can make the high precision clock also as optional (on panda both OMAP4 and twl6040 uses the same reference clock).

Quoted 5 lines

Hm. It looks as if implementing this (and clock gating) is beyond my experiences. But I am happy to test a proposal on our omap5 board.

BR and thanks,
Nikolaus

See the inline patch, this implements the fref_xtal_ck. I had to add some kernel code also to cope with the new SCM area, but the same area can now be accessed via syscon also if needed.

Quoted 1 line

Looks interesting, although quite complex to enable a single SoC pad at boot time...

Yea it gives plenty of other things for you also. syscon, integration with clock framework, etc.

Quoted 2 lines

Will asap study how it works and test. And of course report results.

Thanks, Tero.

Quoted 146 lines

Thanks and BR,
Nikolaus

Quoted 141 lines

From: Tero Kristo <[email protected]>
Date: Thu, 28 Apr 2016 11:00:57 +0300
Subject: [PATCH] ARM: omap5: add support for fref_xtal_ck

Signed-off-by Tero Kristo <[email protected]>

---

arch/arm/boot/dts/omap5.dtsi           | 22 ++++++++++++++++++++++
arch/arm/boot/dts/omap54xx-clocks.dtsi | 10 ++++++++++
arch/arm/mach-omap2/control.c          | 20 ++++++++++++++++----
include/linux/clk/ti.h                 |  1 +
4 files changed, 49 insertions(+), 4 deletions(-)

arch/arm/boot/dts/omap5.dtsi +22 -0

index 38805eb..bdc6528 100644
@@ -277,6 +277,28 @@
 				pinctrl-single,register-width = <16>;
 				pinctrl-single,function-mask = <0x7fff>;
 			};
+
+			omap5_scm_wkup_pad_conf: omap5_scm_wkup_pad_conf@cda0 {
+				compatible = "ti,omap5-scm-wkup-pad-conf",
+					     "simple-bus";
+				reg = <0xcda0 0x60>;
+				#address-cells = <1>;
+				#size-cells = <1>;
+				ranges = <0 0xcda0 0x60>;
+
+				scm_wkup_pad_conf: scm_conf@0 {
+					compatible = "syscon", "simple-bus";
+					reg = <0x0 0x60>;
+					#address-cells = <1>;
+					#size-cells = <1>;
+					ranges = <0 0x0 0x60>;
+
+					scm_wkup_pad_conf_clocks: clocks@0 {
+						#address-cells = <1>;
+						#size-cells = <0>;
+					};
+				};
+			};
 		};
 
 		ocmcram: ocmcram@40300000 {

arch/arm/boot/dts/omap54xx-clocks.dtsi +10 -0

index 83b425f..f970dac 100644
@@ -1388,3 +1388,13 @@
 		reg = <0x021c>;
 	};
 };
+
+&scm_wkup_pad_conf_clocks {
+	fref_xtal_ck: fref_xtal_ck {
+		#clocks-cells = <0>;
+		compatible = "ti,gate-clock";
+		clocks = <&sys_clkin>;
+		ti,bit-shift = <28>;
+		reg = <0x14>;
+	};
+};

arch/arm/mach-omap2/control.c +16 -4

index 1662071..5956641 100644
@@ -623,6 +623,7 @@ void __init omap3_ctrl_init(void)
 
 struct control_init_data {
 	int index;
+	void __iomem *mem;
 	s16 offset;
 };
 

@@ -635,6 +636,10 @@ static const struct control_init_data omap2_ctrl_data = {
 	.offset = -OMAP2_CONTROL_GENERAL,
 };
 
+static const struct control_init_data ctrl_aux_data = {
+	.index = TI_CLKM_CTRL_AUX,
+};
+
 static const struct of_device_id omap_scrm_dt_match_table[] = {
 	{ .compatible = "ti,am3-scm", .data = &ctrl_data },
 	{ .compatible = "ti,am4-scm", .data = &ctrl_data },

@@ -644,6 +649,7 @@ static const struct of_device_id omap_scrm_dt_match_table[] = {
 	{ .compatible = "ti,dm816-scrm", .data = &ctrl_data },
 	{ .compatible = "ti,omap4-scm-core", .data = &ctrl_data },
 	{ .compatible = "ti,omap5-scm-core", .data = &ctrl_data },
+	{ .compatible = "ti,omap5-scm-wkup-pad-conf", .data = &ctrl_aux_data },
 	{ .compatible = "ti,dra7-scm-core", .data = &ctrl_data },
 	{ }
 };

@@ -660,15 +666,21 @@ int __init omap2_control_base_init(void)
 	struct device_node *np;
 	const struct of_device_id *match;
 	struct control_init_data *data;
+	void __iomem *mem;
 
 	for_each_matching_node_and_match(np, omap_scrm_dt_match_table, &match) {
 		data = (struct control_init_data *)match->data;
 
-		omap2_ctrl_base = of_iomap(np, 0);
-		if (!omap2_ctrl_base)
+		mem = of_iomap(np, 0);
+		if (!mem)
 			return -ENOMEM;
 
-		omap2_ctrl_offset = data->offset;
+		if (data->index == TI_CLKM_CTRL) {
+			omap2_ctrl_base = mem;
+			omap2_ctrl_offset = data->offset;
+		}
+
+		data->mem = mem;
 	}
 
 	return 0;

@@ -713,7 +725,7 @@ int __init omap_control_init(void)
 		} else {
 			/* No scm_conf found, direct access */
 			ret = omap2_clk_provider_init(np, data->index, NULL,
-						      omap2_ctrl_base);
+						      data->mem);
 			if (ret)
 				return ret;
 		}

include/linux/clk/ti.h +1 -0

index dc5164a..be25aa8 100644
@@ -195,6 +195,7 @@ enum {
 	TI_CLKM_PRM,
 	TI_CLKM_SCRM,
 	TI_CLKM_CTRL,
+	TI_CLKM_CTRL_AUX,
 	TI_CLKM_PLLSS,
 	CLK_MAX_MEMMAPS
 };

Hi,

Quoted 82 lines

Am 28.04.2016 um 15:23 schrieb Tero Kristo <[email protected]>:

Quoted 79 lines · H. Nikolaus Schaller

Hi Tero,

Quoted 76 lines

Am 28.04.2016 um 10:03 schrieb Tero Kristo <[email protected]>:

Quoted 66 lines · H. Nikolaus Schaller

HI,

Quoted 49 lines

Am 27.04.2016 um 16:23 schrieb Peter Ujfalusi <[email protected]>:

Quoted 39 lines · Tero Kristo

Quoted 38 lines · H. Nikolaus Schaller

Quoted 37 lines

Am 27.04.2016 um 14:31 schrieb Tero Kristo <[email protected]>:

Quoted 20 lines · H. Nikolaus Schaller

Quoted 5 lines

Am 26.04.2016 um 19:27 schrieb Tony Lindgren <[email protected]>:

Tero,

Quoted 8 lines

Quoted 5 lines · H. Nikolaus Schaller

OMAP5 has a register to control if the ckobuffer is enabled and defines the polarity. ckobuffer is required to drive a twl6040 with the system clock. Hence, add the pinctrl,single to the OMAP5 SoC description so that omap5-board-common can set up the ckobuffer as required.

Is this really a mux or should it be a mux clock?

It is a pinmux setting for the clock out buffer to choose what signal (and polarity) is presented on the fref_xtal_clk pad.

The register is part of the CTRL_MODULE_WKUP.
The clock signal is the xtal master clock of the whole SoC.

Quoted 8 lines

Although there is a bit to choose an alternate clock, there is no alternate in the OMAP5 silicon.

Therefore I would say it is about padconf and not clock or clock mux related.

It just happens to be a clock signal which can be routed to this pad.

The two could very well be implemented as clock nodes, a mux and a gate. This would describe the hardware functionality better imo, if the assumptions made here are correct. Implementing the control as pinctrl hacks looks rather weird to me.

Quoted 6 lines

Quoted 2 lines

Why do you consider it a "pinctrl hack"? IMHO it is not a hack, but 100% proper use of pinctrl.

It is just the level of abstraction we are talking about here. If it is a clock we are controlling, we should rather control it as a clock (higher level abstraction), not a pin.

Quoted 6 lines

I second this. I think it is better to have a simple gate clock and handle only CONTROL_CKOBUFFER:CKOBUFFER_CLK_EN (bit 28) only as the other bits does not have real use.

Then we can add clk API support for this. On most OMAP4 devices the clock is always on,

this is why I am raising the question if we really want to control it on the omap5 or just turn it on for all omap5 boards like the omap4 appears to do... I.e. if turning the pin on as a pinctrl is IMHO sufficient for all practical purposes.

Quoted 3 lines

so the board DTS file need to provide a dummy clock, or we can make the high precision clock also as optional (on panda both OMAP4 and twl6040 uses the same reference clock).

Quoted 5 lines

Hm. It looks as if implementing this (and clock gating) is beyond my experiences. But I am happy to test a proposal on our omap5 board.

BR and thanks,
Nikolaus

See the inline patch, this implements the fref_xtal_ck. I had to add some kernel code also to cope with the new SCM area, but the same area can now be accessed via syscon also if needed.

Quoted 156 lines

Quoted 1 line

Looks interesting, although quite complex to enable a single SoC pad at boot time...

Yea it gives plenty of other things for you also. syscon, integration with clock framework, etc.

Quoted 2 lines

Will asap study how it works and test. And of course report results.

Thanks, Tero.

Quoted 146 lines

Thanks and BR,
Nikolaus

Quoted 141 lines

From: Tero Kristo <[email protected]>
Date: Thu, 28 Apr 2016 11:00:57 +0300
Subject: [PATCH] ARM: omap5: add support for fref_xtal_ck

Signed-off-by Tero Kristo <[email protected]>

---

arch/arm/boot/dts/omap5.dtsi           | 22 ++++++++++++++++++++++
arch/arm/boot/dts/omap54xx-clocks.dtsi | 10 ++++++++++
arch/arm/mach-omap2/control.c          | 20 ++++++++++++++++----
include/linux/clk/ti.h                 |  1 +
4 files changed, 49 insertions(+), 4 deletions(-)

arch/arm/boot/dts/omap5.dtsi +22 -0

index 38805eb..bdc6528 100644
@@ -277,6 +277,28 @@
 				pinctrl-single,register-width = <16>;
 				pinctrl-single,function-mask = <0x7fff>;
 			};
+
+			omap5_scm_wkup_pad_conf: omap5_scm_wkup_pad_conf@cda0 {
+				compatible = "ti,omap5-scm-wkup-pad-conf",
+					     "simple-bus";
+				reg = <0xcda0 0x60>;
+				#address-cells = <1>;
+				#size-cells = <1>;
+				ranges = <0 0xcda0 0x60>;
+
+				scm_wkup_pad_conf: scm_conf@0 {
+					compatible = "syscon", "simple-bus";
+					reg = <0x0 0x60>;
+					#address-cells = <1>;
+					#size-cells = <1>;
+					ranges = <0 0x0 0x60>;
+
+					scm_wkup_pad_conf_clocks: clocks@0 {
+						#address-cells = <1>;
+						#size-cells = <0>;
+					};
+				};
+			};
 		};
 
 		ocmcram: ocmcram@40300000 {

arch/arm/boot/dts/omap54xx-clocks.dtsi +10 -0

index 83b425f..f970dac 100644
@@ -1388,3 +1388,13 @@
 		reg = <0x021c>;
 	};
 };
+
+&scm_wkup_pad_conf_clocks {
+	fref_xtal_ck: fref_xtal_ck {
+		#clocks-cells = <0>;
+		compatible = "ti,gate-clock";
+		clocks = <&sys_clkin>;
+		ti,bit-shift = <28>;
+		reg = <0x14>;
+	};
+};

arch/arm/mach-omap2/control.c +16 -4

index 1662071..5956641 100644
@@ -623,6 +623,7 @@ void __init omap3_ctrl_init(void)
 
 struct control_init_data {
 	int index;
+	void __iomem *mem;
 	s16 offset;
 };
 

@@ -635,6 +636,10 @@ static const struct control_init_data omap2_ctrl_data = {
 	.offset = -OMAP2_CONTROL_GENERAL,
 };
 
+static const struct control_init_data ctrl_aux_data = {
+	.index = TI_CLKM_CTRL_AUX,
+};
+
 static const struct of_device_id omap_scrm_dt_match_table[] = {
 	{ .compatible = "ti,am3-scm", .data = &ctrl_data },
 	{ .compatible = "ti,am4-scm", .data = &ctrl_data },

@@ -644,6 +649,7 @@ static const struct of_device_id omap_scrm_dt_match_table[] = {
 	{ .compatible = "ti,dm816-scrm", .data = &ctrl_data },
 	{ .compatible = "ti,omap4-scm-core", .data = &ctrl_data },
 	{ .compatible = "ti,omap5-scm-core", .data = &ctrl_data },
+	{ .compatible = "ti,omap5-scm-wkup-pad-conf", .data = &ctrl_aux_data },
 	{ .compatible = "ti,dra7-scm-core", .data = &ctrl_data },
 	{ }
 };

@@ -660,15 +666,21 @@ int __init omap2_control_base_init(void)
 	struct device_node *np;
 	const struct of_device_id *match;
 	struct control_init_data *data;
+	void __iomem *mem;
 
 	for_each_matching_node_and_match(np, omap_scrm_dt_match_table, &match) {
 		data = (struct control_init_data *)match->data;
 
-		omap2_ctrl_base = of_iomap(np, 0);
-		if (!omap2_ctrl_base)
+		mem = of_iomap(np, 0);
+		if (!mem)
 			return -ENOMEM;
 
-		omap2_ctrl_offset = data->offset;
+		if (data->index == TI_CLKM_CTRL) {
+			omap2_ctrl_base = mem;
+			omap2_ctrl_offset = data->offset;
+		}
+
+		data->mem = mem;
 	}
 
 	return 0;

@@ -713,7 +725,7 @@ int __init omap_control_init(void)
 		} else {
 			/* No scm_conf found, direct access */
 			ret = omap2_clk_provider_init(np, data->index, NULL,
-						      omap2_ctrl_base);
+						      data->mem);
 			if (ret)
 				return ret;
 		}

include/linux/clk/ti.h +1 -0

index dc5164a..be25aa8 100644
@@ -195,6 +195,7 @@ enum {
 	TI_CLKM_PRM,
 	TI_CLKM_SCRM,
 	TI_CLKM_CTRL,
+	TI_CLKM_CTRL_AUX,
 	TI_CLKM_PLLSS,
 	CLK_MAX_MEMMAPS
 };

finally I found some time to apply your patches. Sorry for the long time.

Unfortunately, it does not work. Neither on omap5evm nor on our omap5 hardware. I get no sound on the twl6040 - just white noise (which can be controlled in level through amixer so it is created on the digital input side of the twl6040).

So I think your patch is missing a detail compared to my simple solution.

BR,
Nikolaus

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

Quoted 262 lines · H. Nikolaus Schaller

Hi,

Quoted 94 lines

Am 28.04.2016 um 15:23 schrieb Tero Kristo <[email protected]>:

Quoted 84 lines · H. Nikolaus Schaller

Hi Tero,

Quoted 82 lines

Am 28.04.2016 um 10:03 schrieb Tero Kristo <[email protected]>:

Quoted 78 lines · H. Nikolaus Schaller

HI,

Quoted 51 lines

Am 27.04.2016 um 16:23 schrieb Peter Ujfalusi <[email protected]>:

Quoted 40 lines · Tero Kristo

Quoted 39 lines · H. Nikolaus Schaller

Quoted 38 lines

Am 27.04.2016 um 14:31 schrieb Tero Kristo <[email protected]>:

Quoted 20 lines · H. Nikolaus Schaller

Quoted 5 lines

Am 26.04.2016 um 19:27 schrieb Tony Lindgren <[email protected]>:

Tero,

Quoted 8 lines

Quoted 5 lines · H. Nikolaus Schaller

OMAP5 has a register to control if the ckobuffer is enabled
and defines the polarity. ckobuffer is required to drive a twl6040
with the system clock. Hence, add the pinctrl,single to the
OMAP5 SoC description so that omap5-board-common can
set up the ckobuffer as required.

Is this really a mux or should it be a mux clock?

It is a pinmux setting for the clock out buffer to choose what signal (and polarity) is presented on the fref_xtal_clk pad.

The register is part of the CTRL_MODULE_WKUP.
The clock signal is the xtal master clock of the whole SoC.

Quoted 8 lines

Although there is a bit to choose an alternate clock, there is no alternate in the OMAP5 silicon.

Therefore I would say it is about padconf and not clock or clock mux related.

It just happens to be a clock signal which can be routed to this pad.

The two could very well be implemented as clock nodes, a mux and a gate.
This would describe the hardware functionality better imo, if the assumptions made here are correct. Implementing the control as pinctrl hacks looks rather weird to me.

Quoted 7 lines

Quoted 2 lines

Why do you consider it a "pinctrl hack"? IMHO it is not a hack, but 100% proper use of pinctrl.

It is just the level of abstraction we are talking about here. If it is a clock we are controlling, we should rather control it as a clock (higher level
abstraction), not a pin.

Quoted 8 lines

I second this. I think it is better to have a simple gate clock and handle only CONTROL_CKOBUFFER:CKOBUFFER_CLK_EN (bit 28) only as the other bits does
not have real use.

Then we can add clk API support for this. On most OMAP4 devices the clock is
always on,

this is why I am raising the question if we really want to control it on the omap5 or just
turn it on for all omap5 boards like the omap4 appears to do... I.e. if turning the pin on
as a pinctrl is IMHO sufficient for all practical purposes.

Quoted 3 lines

so the board DTS file need to provide a dummy clock, or we can make the high precision clock also as optional (on panda both OMAP4 and twl6040 uses the same reference clock).

Hm. It looks as if implementing this (and clock gating) is beyond my experiences.
But I am happy to test a proposal on our omap5 board.

BR and thanks,
Nikolaus

Quoted 6 lines

Quoted 3 lines

See the inline patch, this implements the fref_xtal_ck. I had to add some kernel code also to cope with the new SCM area, but the same area can now be accessed via syscon also if needed.

Looks interesting, although quite complex to enable a single SoC pad at boot time...

Quoted 158 lines

Yea it gives plenty of other things for you also. syscon, integration with clock framework, etc.

Quoted 2 lines

Will asap study how it works and test. And of course report results.

Thanks, Tero.

Quoted 149 lines

Thanks and BR,
Nikolaus

Quoted 144 lines

From: Tero Kristo <[email protected]>
Date: Thu, 28 Apr 2016 11:00:57 +0300
Subject: [PATCH] ARM: omap5: add support for fref_xtal_ck

Signed-off-by Tero Kristo <[email protected]>

---

arch/arm/boot/dts/omap5.dtsi           | 22 ++++++++++++++++++++++
arch/arm/boot/dts/omap54xx-clocks.dtsi | 10 ++++++++++
arch/arm/mach-omap2/control.c          | 20 ++++++++++++++++----
include/linux/clk/ti.h                 |  1 +
4 files changed, 49 insertions(+), 4 deletions(-)

arch/arm/boot/dts/omap5.dtsi +22 -0

index 38805eb..bdc6528 100644
@@ -277,6 +277,28 @@
                pinctrl-single,register-width = <16>;
                pinctrl-single,function-mask = <0x7fff>;
            };
+
+            omap5_scm_wkup_pad_conf: omap5_scm_wkup_pad_conf@cda0 {
+                compatible = "ti,omap5-scm-wkup-pad-conf",
+                         "simple-bus";
+                reg = <0xcda0 0x60>;
+                #address-cells = <1>;
+                #size-cells = <1>;
+                ranges = <0 0xcda0 0x60>;
+
+                scm_wkup_pad_conf: scm_conf@0 {
+                    compatible = "syscon", "simple-bus";
+                    reg = <0x0 0x60>;
+                    #address-cells = <1>;
+                    #size-cells = <1>;
+                    ranges = <0 0x0 0x60>;
+
+                    scm_wkup_pad_conf_clocks: clocks@0 {
+                        #address-cells = <1>;
+                        #size-cells = <0>;
+                    };
+                };
+            };
        };
 
        ocmcram: ocmcram@40300000 {

arch/arm/boot/dts/omap54xx-clocks.dtsi +10 -0

index 83b425f..f970dac 100644
@@ -1388,3 +1388,13 @@
        reg = <0x021c>;
    };
 };
+
+&scm_wkup_pad_conf_clocks {
+    fref_xtal_ck: fref_xtal_ck {
+        #clocks-cells = <0>;
+        compatible = "ti,gate-clock";
+        clocks = <&sys_clkin>;
+        ti,bit-shift = <28>;
+        reg = <0x14>;
+    };
+};

arch/arm/mach-omap2/control.c +5 -0

index 1662071..5956641 100644
@@ -623,6 +623,7 @@ void __init omap3_ctrl_init(void)
 
 struct control_init_data {
    int index;
+    void __iomem *mem;
    s16 offset;
 };
 

@@ -635,6 +636,10 @@ static const struct control_init_data
 omap2_ctrl_data = {
    .offset = -OMAP2_CONTROL_GENERAL,
 };
 
+static const struct control_init_data ctrl_aux_data = {
+    .index = TI_CLKM_CTRL_AUX,
+};
+
 static const struct of_device_id omap_scrm_dt_match_table[] = {
    { .compatible = "ti,am3-scm", .data = &ctrl_data },

    { .compatible = "ti,am4-scm", .data = &ctrl_data },

arch/arm/mach-omap2/control.c +1 -0

@@ -644,6 +649,7 @@ static const struct of_device_id
 omap_scrm_dt_match_table[] = {
    { .compatible = "ti,dm816-scrm", .data = &ctrl_data },
    { .compatible = "ti,omap4-scm-core", .data = &ctrl_data },
    { .compatible = "ti,omap5-scm-core", .data = &ctrl_data },
+    { .compatible = "ti,omap5-scm-wkup-pad-conf", .data = &ctrl_aux_data },
    { .compatible = "ti,dra7-scm-core", .data = &ctrl_data },
    { }

};

arch/arm/mach-omap2/control.c +10 -4

@@ -660,15 +666,21 @@ int __init omap2_control_base_init(void)
    struct device_node *np;
    const struct of_device_id *match;
    struct control_init_data *data;
+    void __iomem *mem;
 
    for_each_matching_node_and_match(np, omap_scrm_dt_match_table, &match) {
        data = (struct control_init_data *)match->data;
 
-        omap2_ctrl_base = of_iomap(np, 0);
-        if (!omap2_ctrl_base)
+        mem = of_iomap(np, 0);
+        if (!mem)
            return -ENOMEM;
 
-        omap2_ctrl_offset = data->offset;
+        if (data->index == TI_CLKM_CTRL) {
+            omap2_ctrl_base = mem;
+            omap2_ctrl_offset = data->offset;
+        }
+
+        data->mem = mem;
    }
 
    return 0;

@@ -713,7 +725,7 @@ int __init omap_control_init(void)
        } else {
            /* No scm_conf found, direct access */
            ret = omap2_clk_provider_init(np, data->index, NULL,
-                              omap2_ctrl_base);
+                              data->mem);
            if (ret)
                return ret;
        }

include/linux/clk/ti.h +1 -0

index dc5164a..be25aa8 100644
@@ -195,6 +195,7 @@ enum {
    TI_CLKM_PRM,
    TI_CLKM_SCRM,
    TI_CLKM_CTRL,
+    TI_CLKM_CTRL_AUX,
    TI_CLKM_PLLSS,
    CLK_MAX_MEMMAPS
 };

finally I found some time to apply your patches. Sorry for the long time.

Unfortunately, it does not work. Neither on omap5evm nor on our omap5 hardware. I get no sound on the twl6040 - just white noise (which can be controlled in level through
amixer so it is created on the digital input side of the twl6040).

Quoted 1 line

So I think your patch is missing a detail compared to my simple solution.

Did you implement anything on the audio driver side? The audio driver must enable the clock implemented by this patch.

-Tero

Quoted 10 lines

BR,
Nikolaus

Signature · 3 lines

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

Quoted 7 lines

Quoted 7 lines

finally I found some time to apply your patches. Sorry for the long time.

Unfortunately, it does not work. Neither on omap5evm nor on our omap5 hardware. I get no sound on the twl6040 - just white noise (which can be controlled in level through
amixer so it is created on the digital input side of the twl6040).

Quoted 4 lines

Quoted 1 line

So I think your patch is missing a detail compared to my simple solution.

Did you implement anything on the audio driver side? The audio driver must enable the clock implemented by this patch.

I did, can test it in 10 minutes or so...

From d492ada3f7734eb1e4999c68ef0950c1ace9a6c8 Mon Sep 17 00:00:00 2001

From d1099793e9189c6bb9514cfbed38638f0873a53d Mon Sep 17 00:00:00 2001

From 87714553b1f803f9c08d32c2c61dc980ddbb1b78 Mon Sep 17 00:00:00 2001

Quoted 7 lines · Peter Ujfalusi

Quoted 7 lines

Quoted 7 lines

finally I found some time to apply your patches. Sorry for the long time.

Unfortunately, it does not work. Neither on omap5evm nor on our omap5 hardware. I get no sound on the twl6040 - just white noise (which can be controlled in level through
amixer so it is created on the digital input side of the twl6040).

Quoted 6 lines

Quoted 4 lines

Quoted 1 line

So I think your patch is missing a detail compared to my simple solution.

Did you implement anything on the audio driver side? The audio driver must enable the clock implemented by this patch.

I did, can test it in 10 minutes or so...

might work, but linux-next is not booting on omap5-uevm :o I don't know why...

In any case I have attached the 3 patches I have for this, including Tero's ported to linux-next.

Patch 3 might need to be done per board probably, but this should be good for testing.

_______________________________________________
Kernel mailing list
[email protected]
http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel

Quoted 14 lines · Peter Ujfalusi

Quoted 12 lines · Peter Ujfalusi

Quoted 11 lines

Quoted 8 lines

finally I found some time to apply your patches. Sorry for the long time.

Unfortunately, it does not work. Neither on omap5evm nor on our omap5 hardware. I get no sound on the twl6040 - just white noise (which can be controlled in level through
amixer so it is created on the digital input side of the twl6040).

So I think your patch is missing a detail compared to my simple solution.

Did you implement anything on the audio driver side? The audio driver must enable the clock implemented by this patch.

Quoted 3 lines

Quoted 1 line

I did, can test it in 10 minutes or so...

might work, but linux-next is not booting on omap5-uevm :o I don't know why...

Applying Tero's alone makes the board not to boot, so something there... I can not see anything even with low-level debugging enabled :( I can not debug it further today, will look at this tomorrow.

Quoted 13 lines

In any case I have attached the 3 patches I have for this, including Tero's ported to linux-next.

Patch 3 might need to be done per board probably, but this should be good for testing.

_______________________________________________
Kernel mailing list
[email protected]
http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel

Quoted 15 lines · Peter Ujfalusi

Quoted 14 lines · Peter Ujfalusi

Quoted 12 lines · Peter Ujfalusi

Quoted 11 lines

Quoted 8 lines

finally I found some time to apply your patches. Sorry for the long time.

Unfortunately, it does not work. Neither on omap5evm nor on our omap5 hardware. I get no sound on the twl6040 - just white noise (which can be controlled in level through
amixer so it is created on the digital input side of the twl6040).

So I think your patch is missing a detail compared to my simple solution.

Did you implement anything on the audio driver side? The audio driver must enable the clock implemented by this patch.

Quoted 7 lines

Quoted 3 lines

Quoted 1 line

I did, can test it in 10 minutes or so...

might work, but linux-next is not booting on omap5-uevm :o I don't know why...

Applying Tero's alone makes the board not to boot, so something there... I can not see anything even with low-level debugging enabled :( I can not debug it further today, will look at this tomorrow.

The crash is in arch/arm/mach-omap2/control.c:omap_control_init()

the syscon_node_to_regmap() returns with error for the new omap5_scm_wkup_pad_conf node. The other syscon was OK, but becasue of the return PTR_ERR(syscon) the board will not boot...

Tero: any idea?

Quoted 9 lines

Quoted 9 lines

In any case I have attached the 3 patches I have for this, including Tero's ported to linux-next.

Patch 3 might need to be done per board probably, but this should be good for testing.

Quoted 7 lines

Quoted 5 lines

_______________________________________________
Kernel mailing list Kernel-Jl6IXVxNIMRxAtABVqVhTwC/[email protected]
http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel

Quoted 6 lines

Quoted 3 lines

Applying Tero's alone makes the board not to boot, so something there... I can not see anything even with low-level debugging enabled :( I can not debug it further today, will look at this tomorrow.

The crash is in arch/arm/mach-omap2/control.c:omap_control_init()

Quoted 5 lines

the syscon_node_to_regmap() returns with error for the new omap5_scm_wkup_pad_conf node. The other syscon was OK, but becasue of the return PTR_ERR(syscon) the board will not boot...

Tero: any idea?

I can check this tomorrow at my end.

-Tero

Quoted 18 lines

Quoted 16 lines

Quoted 14 lines

In any case I have attached the 3 patches I have for this, including Tero's ported to linux-next.

Patch 3 might need to be done per board probably, but this should be good for testing.

_______________________________________________
Kernel mailing list Kernel-Jl6IXVxNIMRxAtABVqVhTwC/[email protected]
http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel

Quoted 7 lines · Peter Ujfalusi

Quoted 7 lines

Quoted 7 lines

finally I found some time to apply your patches. Sorry for the long time.

Unfortunately, it does not work. Neither on omap5evm nor on our omap5 hardware. I get no sound on the twl6040 - just white noise (which can be controlled in level through
amixer so it is created on the digital input side of the twl6040).

Quoted 6 lines

Quoted 4 lines

Quoted 1 line

So I think your patch is missing a detail compared to my simple solution.

Did you implement anything on the audio driver side? The audio driver must enable the clock implemented by this patch.

I did, can test it in 10 minutes or so...

might work, but linux-next is not booting on omap5-uevm :o I don't know why...

In any case I have attached the 3 patches I have for this, including Tero's ported to linux-next.

Patch 3 might need to be done per board probably, but this should be good for testing.

Am 09.05.2016 um 13:52 schrieb Tero Kristo <[email protected]>:

Quoted 243 lines · H. Nikolaus Schaller

Hi,

Quoted 82 lines

Am 28.04.2016 um 15:23 schrieb Tero Kristo <[email protected]>:

Quoted 79 lines · H. Nikolaus Schaller

Hi Tero,

Quoted 76 lines

Am 28.04.2016 um 10:03 schrieb Tero Kristo <[email protected]>:

Quoted 66 lines · H. Nikolaus Schaller

HI,

Quoted 49 lines

Am 27.04.2016 um 16:23 schrieb Peter Ujfalusi <[email protected]>:

Quoted 39 lines · Tero Kristo

Quoted 38 lines · H. Nikolaus Schaller

Quoted 37 lines

Am 27.04.2016 um 14:31 schrieb Tero Kristo <[email protected]>:

Quoted 20 lines · H. Nikolaus Schaller

Quoted 5 lines

Am 26.04.2016 um 19:27 schrieb Tony Lindgren <[email protected]>:

Tero,

Quoted 8 lines

Quoted 5 lines · H. Nikolaus Schaller

OMAP5 has a register to control if the ckobuffer is enabled
and defines the polarity. ckobuffer is required to drive a twl6040
with the system clock. Hence, add the pinctrl,single to the
OMAP5 SoC description so that omap5-board-common can
set up the ckobuffer as required.

Is this really a mux or should it be a mux clock?

It is a pinmux setting for the clock out buffer to choose what signal (and polarity) is presented on the fref_xtal_clk pad.

The register is part of the CTRL_MODULE_WKUP.
The clock signal is the xtal master clock of the whole SoC.

Quoted 8 lines

Although there is a bit to choose an alternate clock, there is no alternate in the OMAP5 silicon.

Therefore I would say it is about padconf and not clock or clock mux related.

It just happens to be a clock signal which can be routed to this pad.

The two could very well be implemented as clock nodes, a mux and a gate. This would describe the hardware functionality better imo, if the assumptions made here are correct. Implementing the control as pinctrl hacks looks rather weird to me.

Quoted 6 lines

Quoted 2 lines

Why do you consider it a "pinctrl hack"? IMHO it is not a hack, but 100% proper use of pinctrl.

It is just the level of abstraction we are talking about here. If it is a clock we are controlling, we should rather control it as a clock (higher level abstraction), not a pin.

Quoted 6 lines

I second this. I think it is better to have a simple gate clock and handle only CONTROL_CKOBUFFER:CKOBUFFER_CLK_EN (bit 28) only as the other bits does not have real use.

Then we can add clk API support for this. On most OMAP4 devices the clock is always on,

this is why I am raising the question if we really want to control it on the omap5 or just turn it on for all omap5 boards like the omap4 appears to do... I.e. if turning the pin on as a pinctrl is IMHO sufficient for all practical purposes.

Quoted 3 lines

so the board DTS file need to provide a dummy clock, or we can make the high precision clock also as optional (on panda both OMAP4 and twl6040 uses the same reference clock).

Quoted 5 lines

Hm. It looks as if implementing this (and clock gating) is beyond my experiences. But I am happy to test a proposal on our omap5 board.

BR and thanks,
Nikolaus

See the inline patch, this implements the fref_xtal_ck. I had to add some kernel code also to cope with the new SCM area, but the same area can now be accessed via syscon also if needed.

Quoted 156 lines

Quoted 1 line

Looks interesting, although quite complex to enable a single SoC pad at boot time...

Yea it gives plenty of other things for you also. syscon, integration with clock framework, etc.

Quoted 2 lines

Will asap study how it works and test. And of course report results.

Thanks, Tero.

Quoted 146 lines

Thanks and BR,
Nikolaus

Quoted 141 lines

From: Tero Kristo <[email protected]>
Date: Thu, 28 Apr 2016 11:00:57 +0300
Subject: [PATCH] ARM: omap5: add support for fref_xtal_ck

Signed-off-by Tero Kristo <[email protected]>

---

arch/arm/boot/dts/omap5.dtsi           | 22 ++++++++++++++++++++++
arch/arm/boot/dts/omap54xx-clocks.dtsi | 10 ++++++++++
arch/arm/mach-omap2/control.c          | 20 ++++++++++++++++----
include/linux/clk/ti.h                 |  1 +
4 files changed, 49 insertions(+), 4 deletions(-)

arch/arm/boot/dts/omap5.dtsi +22 -0

index 38805eb..bdc6528 100644
@@ -277,6 +277,28 @@
 				pinctrl-single,register-width = <16>;
 				pinctrl-single,function-mask = <0x7fff>;
 			};
+
+			omap5_scm_wkup_pad_conf: omap5_scm_wkup_pad_conf@cda0 {
+				compatible = "ti,omap5-scm-wkup-pad-conf",
+					     "simple-bus";
+				reg = <0xcda0 0x60>;
+				#address-cells = <1>;
+				#size-cells = <1>;
+				ranges = <0 0xcda0 0x60>;
+
+				scm_wkup_pad_conf: scm_conf@0 {
+					compatible = "syscon", "simple-bus";
+					reg = <0x0 0x60>;
+					#address-cells = <1>;
+					#size-cells = <1>;
+					ranges = <0 0x0 0x60>;
+
+					scm_wkup_pad_conf_clocks: clocks@0 {
+						#address-cells = <1>;
+						#size-cells = <0>;
+					};
+				};
+			};
 		};
 
 		ocmcram: ocmcram@40300000 {

arch/arm/boot/dts/omap54xx-clocks.dtsi +10 -0

index 83b425f..f970dac 100644
@@ -1388,3 +1388,13 @@
 		reg = <0x021c>;
 	};
 };
+
+&scm_wkup_pad_conf_clocks {
+	fref_xtal_ck: fref_xtal_ck {
+		#clocks-cells = <0>;
+		compatible = "ti,gate-clock";
+		clocks = <&sys_clkin>;
+		ti,bit-shift = <28>;
+		reg = <0x14>;
+	};
+};

arch/arm/mach-omap2/control.c +16 -4

index 1662071..5956641 100644
@@ -623,6 +623,7 @@ void __init omap3_ctrl_init(void)
 
 struct control_init_data {
 	int index;
+	void __iomem *mem;
 	s16 offset;
 };
 

@@ -635,6 +636,10 @@ static const struct control_init_data omap2_ctrl_data = {
 	.offset = -OMAP2_CONTROL_GENERAL,
 };
 
+static const struct control_init_data ctrl_aux_data = {
+	.index = TI_CLKM_CTRL_AUX,
+};
+
 static const struct of_device_id omap_scrm_dt_match_table[] = {
 	{ .compatible = "ti,am3-scm", .data = &ctrl_data },
 	{ .compatible = "ti,am4-scm", .data = &ctrl_data },

@@ -644,6 +649,7 @@ static const struct of_device_id omap_scrm_dt_match_table[] = {
 	{ .compatible = "ti,dm816-scrm", .data = &ctrl_data },
 	{ .compatible = "ti,omap4-scm-core", .data = &ctrl_data },
 	{ .compatible = "ti,omap5-scm-core", .data = &ctrl_data },
+	{ .compatible = "ti,omap5-scm-wkup-pad-conf", .data = &ctrl_aux_data },
 	{ .compatible = "ti,dra7-scm-core", .data = &ctrl_data },
 	{ }
 };

@@ -660,15 +666,21 @@ int __init omap2_control_base_init(void)
 	struct device_node *np;
 	const struct of_device_id *match;
 	struct control_init_data *data;
+	void __iomem *mem;
 
 	for_each_matching_node_and_match(np, omap_scrm_dt_match_table, &match) {
 		data = (struct control_init_data *)match->data;
 
-		omap2_ctrl_base = of_iomap(np, 0);
-		if (!omap2_ctrl_base)
+		mem = of_iomap(np, 0);
+		if (!mem)
 			return -ENOMEM;
 
-		omap2_ctrl_offset = data->offset;
+		if (data->index == TI_CLKM_CTRL) {
+			omap2_ctrl_base = mem;
+			omap2_ctrl_offset = data->offset;
+		}
+
+		data->mem = mem;
 	}
 
 	return 0;

@@ -713,7 +725,7 @@ int __init omap_control_init(void)
 		} else {
 			/* No scm_conf found, direct access */
 			ret = omap2_clk_provider_init(np, data->index, NULL,
-						      omap2_ctrl_base);
+						      data->mem);
 			if (ret)
 				return ret;
 		}

include/linux/clk/ti.h +1 -0

index dc5164a..be25aa8 100644
@@ -195,6 +195,7 @@ enum {
 	TI_CLKM_PRM,
 	TI_CLKM_SCRM,
 	TI_CLKM_CTRL,
+	TI_CLKM_CTRL_AUX,
 	TI_CLKM_PLLSS,
 	CLK_MAX_MEMMAPS
 };

finally I found some time to apply your patches. Sorry for the long time.

Quoted 5 lines

Unfortunately, it does not work. Neither on omap5evm nor on our omap5 hardware. I get no sound on the twl6040 - just white noise (which can be controlled in level through amixer so it is created on the digital input side of the twl6040).

So I think your patch is missing a detail compared to my simple solution.

Did you implement anything on the audio driver side? The audio driver must enable the clock implemented by this patch.

Am 18.04.2016 um 20:20 schrieb H. Nikolaus Schaller <[email protected]>:

This patch series adds DT nodes for:
* twl6030 gpadc for omap4 based boards (Pandaboard ES)
* twl6037 gpadc for omap5 based board (OMAP5EVM)
* omap5-board-common: ckobuffer (needed for high quality twl6040 audio)
* fix range problem with omap5 pinmux

H. Nikolaus Schaller (5):
ARM: dts: twl6030: describe gpadc
ARM: dts: omap5-board-common: describe gpadc for Palmas
ARM: dts: omap5: fix range of permitted wakeup pinmux registers
ARM: dts: omap5: describe control for ckobuffer
ARM: dts: omap5-board-common: set up ckobuffer for twl6040

arch/arm/boot/dts/omap5-board-common.dtsi | 24 ++++++++++++++++++++++++
arch/arm/boot/dts/omap5.dtsi              | 12 +++++++++++-
arch/arm/boot/dts/twl6030.dtsi            |  6 ++++++
3 files changed, 41 insertions(+), 1 deletion(-)

Signature · 1 line

2.7.3

ping.

Quoted 20 lines

Am 18.04.2016 um 20:20 schrieb H. Nikolaus Schaller <[email protected]>:

This patch series adds DT nodes for:
* twl6030 gpadc for omap4 based boards (Pandaboard ES)
* twl6037 gpadc for omap5 based board (OMAP5EVM)
* omap5-board-common: ckobuffer (needed for high quality twl6040 audio)
* fix range problem with omap5 pinmux

H. Nikolaus Schaller (5):
ARM: dts: twl6030: describe gpadc
ARM: dts: omap5-board-common: describe gpadc for Palmas
ARM: dts: omap5: fix range of permitted wakeup pinmux registers
ARM: dts: omap5: describe control for ckobuffer
ARM: dts: omap5-board-common: set up ckobuffer for twl6040

arch/arm/boot/dts/omap5-board-common.dtsi | 24 ++++++++++++++++++++++++
arch/arm/boot/dts/omap5.dtsi              | 12 +++++++++++-
arch/arm/boot/dts/twl6030.dtsi            |  6 ++++++
3 files changed, 41 insertions(+), 1 deletion(-)