All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] Documentation: dt-bindings: Add binding documentation for TI clkctrl clocks
@ 2017-01-09 23:42 Tony Lindgren
       [not found] ` <20170109234226.9449-1-tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
  0 siblings, 1 reply; 10+ messages in thread
From: Tony Lindgren @ 2017-01-09 23:42 UTC (permalink / raw)
  To: Michael Turquette, Stephen Boyd, Tero Kristo
  Cc: devicetree, linux-clk, linux-omap, Paul Walmsley, Rob Herring

Texas Instruments omap variant SoCs starting with omap4 have a clkctrl
clock controller instance for each interconnect target module. The clkctrl
controls functional and interface clocks for the module.

The clkctrl clocks are currently handled by arch/arm/mach-omap2 hwmod code.
With this binding and a related clock device driver we can start moving the
clkctrl clock handling to live in drivers/clk/ti.

For hardware reference, see omap4430 TRM "Table 3-1312. L4PER_CM2 Registers
Mapping Summary" for example. It show one instance of a clkctrl clock
controller with multiple clkctrl registers.

Note that this binding allows keeping the clockdomain related parts out of
drivers/clock. The CLKCTCTRL and DYNAMICDEP registers can be handled by
using a separate driver in drivers/soc/ti and genpd. If the clockdomain
driver needs to know it's clocks, we can just set the the clkctrl device
instances to be children of the related clockdomain device.

On omap4 CM_L3INIT_USB_HOST_HS_CLKCTRL on omap5 has eight OPTFCLKEN bits.
So we need to shift the clock index to avoid index conflict for the clock
consumer binding with the next clkctrl offset on omap4.

Cc: Paul Walmsley <paul@pwsan.com>
Cc: Rob Herring <robh@kernel.org>
Signed-off-by: Tony Lindgren <tony@atomide.com>
---

So here's what I was able to come up for the clkctr binding based on
all we've discussed so far. Can you guys please take a look and see
if it looks OK to you before we do the device driver?

Also, does anybody have better suggestions for addressing the optional
clocks in each clkctrl register?

---
 .../devicetree/bindings/clock/ti-clkctrl.txt       | 56 ++++++++++++++++++++++
 1 file changed, 56 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/ti-clkctrl.txt

diff --git a/Documentation/devicetree/bindings/clock/ti-clkctrl.txt b/Documentation/devicetree/bindings/clock/ti-clkctrl.txt
new file mode 100644
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/ti-clkctrl.txt
@@ -0,0 +1,56 @@
+Texas Instruments clkctrl clock binding
+
+Texas Instruments SoCs can have a clkctrl clock controller for each
+interconnect target module. The clkctrl clock controller manages functional
+and interface clocks for each module. Each clkctrl controller can also
+gate one or more optional functional clocks for a module. The clkctrl
+clock controller is typical for omap3 and later variants.
+
+The clock consumers can specify the index of the clkctrl clock using
+the hardware offset from the clkctrl instance register space. The optional
+functional clocks can be specified by clkctrl hardware offset plus the
+index of the optional clock. Please see the Linux clock framework binding
+at Documentation/devicetree/bindings/clock/clock-bindings.txt.
+
+Required properties :
+- compatible : shall be "ti,clkctrl"
+- #clock-cells : shall contain 1
+
+Optional properties :
+- "ti,modulemode-auto" : list of clkctrl offsets using automatic gating
+
+Example: Clock controller node:
+
+&cm_l4per {
+	cm_l4per_clkctrl: clk@20 {
+		compatible = "ti,clkctrl";
+		reg = <0x20 0x1b0>;
+		#clock-cells = 1;
+		ti,modulemode-auto = <OMAP4_GPIO2_CLKCTRL>;
+	};
+};
+
+Example: Preprocessor helper macros in dt-bindings/ti-clkctrl.h
+
+#define OMAP4_CLKCTRL_OFFSET		0x20
+
+#define OMAP_CLKCTRL_INDEX(offset)		\
+	(((offset) - OMAP4_CLKCTRL_OFFSET) << 8)
+
+#define OMAP_CLKCTRL_OPT_INDEX(offset, optclk)	\
+	(OMAP_CLKCTRL_INDEX(offset) + (optclk))
+
+#define OMAP4_GPTIMER10_CLKTRL		OMAP_CLKCTRL_INDEX(0x28)
+#define OMAP4_GPTIMER11_CLKTRL		OMAP_CLKCTRL_INDEX(0x30)
+#define OMAP4_GPTIMER2_CLKTRL		OMAP_CLKCTRL_INDEX(0x38)
+...
+#define OMAP4_GPIO2_CLKCTRL		OMAP_CLKCTRL_INDEX(0x60)
+#define OMAP4_GPIO2_CLKCTRL_DBCLK	OMAP_CLKCTRL_OPT_INDEX(0x60, 1)
+...
+
+Example: Clock consumer node for GPIO2:
+
+&gpio2 {
+       clocks = <&cm_l4per_clkctrl OMAP4_GPIO2_CLKCTRL
+		 &cm_l4per_clkctrl OMAP4_GPIO2_CLKCTRL_DBCLK>;
+};
-- 
2.11.0

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] Documentation: dt-bindings: Add binding documentation for TI clkctrl clocks
  2017-01-09 23:42 [PATCH] Documentation: dt-bindings: Add binding documentation for TI clkctrl clocks Tony Lindgren
@ 2017-01-10 15:44     ` Tony Lindgren
  0 siblings, 0 replies; 10+ messages in thread
From: Tony Lindgren @ 2017-01-10 15:44 UTC (permalink / raw)
  To: Michael Turquette, Stephen Boyd, Tero Kristo
  Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-clk-u79uwXL29TY76Z2rM5mHXA,
	linux-omap-u79uwXL29TY76Z2rM5mHXA, Paul Walmsley, Rob Herring

* Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> [170109 15:43]:
> Texas Instruments omap variant SoCs starting with omap4 have a clkctrl
> clock controller instance for each interconnect target module. The clkctrl
> controls functional and interface clocks for the module.
> 
> The clkctrl clocks are currently handled by arch/arm/mach-omap2 hwmod code.
> With this binding and a related clock device driver we can start moving the
> clkctrl clock handling to live in drivers/clk/ti.
> 
> For hardware reference, see omap4430 TRM "Table 3-1312. L4PER_CM2 Registers
> Mapping Summary" for example. It show one instance of a clkctrl clock
> controller with multiple clkctrl registers.
> 
> Note that this binding allows keeping the clockdomain related parts out of
> drivers/clock. The CLKCTCTRL and DYNAMICDEP registers can be handled by
> using a separate driver in drivers/soc/ti and genpd. If the clockdomain
> driver needs to know it's clocks, we can just set the the clkctrl device
> instances to be children of the related clockdomain device.
> 
> On omap4 CM_L3INIT_USB_HOST_HS_CLKCTRL on omap5 has eight OPTFCLKEN bits.
> So we need to shift the clock index to avoid index conflict for the clock
> consumer binding with the next clkctrl offset on omap4.
> 
> Cc: Paul Walmsley <paul-DWxLp4Yu+b8AvxtiuMwx3w@public.gmane.org>
> Cc: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Signed-off-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
> ---
> 
> So here's what I was able to come up for the clkctr binding based on
> all we've discussed so far. Can you guys please take a look and see
> if it looks OK to you before we do the device driver?
> 
> Also, does anybody have better suggestions for addressing the optional
> clocks in each clkctrl register?

The other option that might be worth considering is to make use of the
#clock-cells property. Then the index of any optional clock could be passed
in the second cell.

The third cell could be used to set the modulemode for the clock (software
controlled or hardware controlled) instead of using a custom property
at the clock controllel level.

In that case clock consume usage would look like the following using
#clock-cells = <3>:

#define OMAP4_CLKCTRL_OFFSET		0x20
#define MODULEMODE_HWCTRL		1
#define MODULEMODE_SWCTRL		2

#define OMAP_CLKCTRL_INDEX(offset)	((offset) - OMAP4_CLKCTRL_OFFSET)

#define OMAP4_GPTIMER10_CLKTRL		OMAP_CLKCTRL_INDEX(0x28)
#define OMAP4_GPTIMER11_CLKTRL		OMAP_CLKCTRL_INDEX(0x30)
#define OMAP4_GPTIMER2_CLKTRL		OMAP_CLKCTRL_INDEX(0x38)
...
#define OMAP4_GPIO2_CLKCTRL		OMAP_CLKCTRL_INDEX(0x60)
...

&gpio2 {
	clocks = <&cm_l4per_clkctrl OMAP4_GPIO2_CLKCTRL 0 MODULEMODE_HWCTRL
		  &cm_l4per_clkctrl OMAP4_GPIO2_CLKCTRL_DBCLK 1 0>;
};

Regards,

Tony


>  .../devicetree/bindings/clock/ti-clkctrl.txt       | 56 ++++++++++++++++++++++
>  1 file changed, 56 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/clock/ti-clkctrl.txt
> 
> diff --git a/Documentation/devicetree/bindings/clock/ti-clkctrl.txt b/Documentation/devicetree/bindings/clock/ti-clkctrl.txt
> new file mode 100644
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/ti-clkctrl.txt
> @@ -0,0 +1,56 @@
> +Texas Instruments clkctrl clock binding
> +
> +Texas Instruments SoCs can have a clkctrl clock controller for each
> +interconnect target module. The clkctrl clock controller manages functional
> +and interface clocks for each module. Each clkctrl controller can also
> +gate one or more optional functional clocks for a module. The clkctrl
> +clock controller is typical for omap3 and later variants.
> +
> +The clock consumers can specify the index of the clkctrl clock using
> +the hardware offset from the clkctrl instance register space. The optional
> +functional clocks can be specified by clkctrl hardware offset plus the
> +index of the optional clock. Please see the Linux clock framework binding
> +at Documentation/devicetree/bindings/clock/clock-bindings.txt.
> +
> +Required properties :
> +- compatible : shall be "ti,clkctrl"
> +- #clock-cells : shall contain 1
> +
> +Optional properties :
> +- "ti,modulemode-auto" : list of clkctrl offsets using automatic gating
> +
> +Example: Clock controller node:
> +
> +&cm_l4per {
> +	cm_l4per_clkctrl: clk@20 {
> +		compatible = "ti,clkctrl";
> +		reg = <0x20 0x1b0>;
> +		#clock-cells = 1;
> +		ti,modulemode-auto = <OMAP4_GPIO2_CLKCTRL>;
> +	};
> +};
> +
> +Example: Preprocessor helper macros in dt-bindings/ti-clkctrl.h
> +
> +#define OMAP4_CLKCTRL_OFFSET		0x20
> +
> +#define OMAP_CLKCTRL_INDEX(offset)		\
> +	(((offset) - OMAP4_CLKCTRL_OFFSET) << 8)
> +
> +#define OMAP_CLKCTRL_OPT_INDEX(offset, optclk)	\
> +	(OMAP_CLKCTRL_INDEX(offset) + (optclk))
> +
> +#define OMAP4_GPTIMER10_CLKTRL		OMAP_CLKCTRL_INDEX(0x28)
> +#define OMAP4_GPTIMER11_CLKTRL		OMAP_CLKCTRL_INDEX(0x30)
> +#define OMAP4_GPTIMER2_CLKTRL		OMAP_CLKCTRL_INDEX(0x38)
> +...
> +#define OMAP4_GPIO2_CLKCTRL		OMAP_CLKCTRL_INDEX(0x60)
> +#define OMAP4_GPIO2_CLKCTRL_DBCLK	OMAP_CLKCTRL_OPT_INDEX(0x60, 1)
> +...
> +
> +Example: Clock consumer node for GPIO2:
> +
> +&gpio2 {
> +       clocks = <&cm_l4per_clkctrl OMAP4_GPIO2_CLKCTRL
> +		 &cm_l4per_clkctrl OMAP4_GPIO2_CLKCTRL_DBCLK>;
> +};
> -- 
> 2.11.0
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] Documentation: dt-bindings: Add binding documentation for TI clkctrl clocks
@ 2017-01-10 15:44     ` Tony Lindgren
  0 siblings, 0 replies; 10+ messages in thread
From: Tony Lindgren @ 2017-01-10 15:44 UTC (permalink / raw)
  To: Michael Turquette, Stephen Boyd, Tero Kristo
  Cc: devicetree, linux-clk, linux-omap, Paul Walmsley, Rob Herring

* Tony Lindgren <tony@atomide.com> [170109 15:43]:
> Texas Instruments omap variant SoCs starting with omap4 have a clkctrl
> clock controller instance for each interconnect target module. The clkctrl
> controls functional and interface clocks for the module.
> 
> The clkctrl clocks are currently handled by arch/arm/mach-omap2 hwmod code.
> With this binding and a related clock device driver we can start moving the
> clkctrl clock handling to live in drivers/clk/ti.
> 
> For hardware reference, see omap4430 TRM "Table 3-1312. L4PER_CM2 Registers
> Mapping Summary" for example. It show one instance of a clkctrl clock
> controller with multiple clkctrl registers.
> 
> Note that this binding allows keeping the clockdomain related parts out of
> drivers/clock. The CLKCTCTRL and DYNAMICDEP registers can be handled by
> using a separate driver in drivers/soc/ti and genpd. If the clockdomain
> driver needs to know it's clocks, we can just set the the clkctrl device
> instances to be children of the related clockdomain device.
> 
> On omap4 CM_L3INIT_USB_HOST_HS_CLKCTRL on omap5 has eight OPTFCLKEN bits.
> So we need to shift the clock index to avoid index conflict for the clock
> consumer binding with the next clkctrl offset on omap4.
> 
> Cc: Paul Walmsley <paul@pwsan.com>
> Cc: Rob Herring <robh@kernel.org>
> Signed-off-by: Tony Lindgren <tony@atomide.com>
> ---
> 
> So here's what I was able to come up for the clkctr binding based on
> all we've discussed so far. Can you guys please take a look and see
> if it looks OK to you before we do the device driver?
> 
> Also, does anybody have better suggestions for addressing the optional
> clocks in each clkctrl register?

The other option that might be worth considering is to make use of the
#clock-cells property. Then the index of any optional clock could be passed
in the second cell.

The third cell could be used to set the modulemode for the clock (software
controlled or hardware controlled) instead of using a custom property
at the clock controllel level.

In that case clock consume usage would look like the following using
#clock-cells = <3>:

#define OMAP4_CLKCTRL_OFFSET		0x20
#define MODULEMODE_HWCTRL		1
#define MODULEMODE_SWCTRL		2

#define OMAP_CLKCTRL_INDEX(offset)	((offset) - OMAP4_CLKCTRL_OFFSET)

#define OMAP4_GPTIMER10_CLKTRL		OMAP_CLKCTRL_INDEX(0x28)
#define OMAP4_GPTIMER11_CLKTRL		OMAP_CLKCTRL_INDEX(0x30)
#define OMAP4_GPTIMER2_CLKTRL		OMAP_CLKCTRL_INDEX(0x38)
...
#define OMAP4_GPIO2_CLKCTRL		OMAP_CLKCTRL_INDEX(0x60)
...

&gpio2 {
	clocks = <&cm_l4per_clkctrl OMAP4_GPIO2_CLKCTRL 0 MODULEMODE_HWCTRL
		  &cm_l4per_clkctrl OMAP4_GPIO2_CLKCTRL_DBCLK 1 0>;
};

Regards,

Tony


>  .../devicetree/bindings/clock/ti-clkctrl.txt       | 56 ++++++++++++++++++++++
>  1 file changed, 56 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/clock/ti-clkctrl.txt
> 
> diff --git a/Documentation/devicetree/bindings/clock/ti-clkctrl.txt b/Documentation/devicetree/bindings/clock/ti-clkctrl.txt
> new file mode 100644
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/ti-clkctrl.txt
> @@ -0,0 +1,56 @@
> +Texas Instruments clkctrl clock binding
> +
> +Texas Instruments SoCs can have a clkctrl clock controller for each
> +interconnect target module. The clkctrl clock controller manages functional
> +and interface clocks for each module. Each clkctrl controller can also
> +gate one or more optional functional clocks for a module. The clkctrl
> +clock controller is typical for omap3 and later variants.
> +
> +The clock consumers can specify the index of the clkctrl clock using
> +the hardware offset from the clkctrl instance register space. The optional
> +functional clocks can be specified by clkctrl hardware offset plus the
> +index of the optional clock. Please see the Linux clock framework binding
> +at Documentation/devicetree/bindings/clock/clock-bindings.txt.
> +
> +Required properties :
> +- compatible : shall be "ti,clkctrl"
> +- #clock-cells : shall contain 1
> +
> +Optional properties :
> +- "ti,modulemode-auto" : list of clkctrl offsets using automatic gating
> +
> +Example: Clock controller node:
> +
> +&cm_l4per {
> +	cm_l4per_clkctrl: clk@20 {
> +		compatible = "ti,clkctrl";
> +		reg = <0x20 0x1b0>;
> +		#clock-cells = 1;
> +		ti,modulemode-auto = <OMAP4_GPIO2_CLKCTRL>;
> +	};
> +};
> +
> +Example: Preprocessor helper macros in dt-bindings/ti-clkctrl.h
> +
> +#define OMAP4_CLKCTRL_OFFSET		0x20
> +
> +#define OMAP_CLKCTRL_INDEX(offset)		\
> +	(((offset) - OMAP4_CLKCTRL_OFFSET) << 8)
> +
> +#define OMAP_CLKCTRL_OPT_INDEX(offset, optclk)	\
> +	(OMAP_CLKCTRL_INDEX(offset) + (optclk))
> +
> +#define OMAP4_GPTIMER10_CLKTRL		OMAP_CLKCTRL_INDEX(0x28)
> +#define OMAP4_GPTIMER11_CLKTRL		OMAP_CLKCTRL_INDEX(0x30)
> +#define OMAP4_GPTIMER2_CLKTRL		OMAP_CLKCTRL_INDEX(0x38)
> +...
> +#define OMAP4_GPIO2_CLKCTRL		OMAP_CLKCTRL_INDEX(0x60)
> +#define OMAP4_GPIO2_CLKCTRL_DBCLK	OMAP_CLKCTRL_OPT_INDEX(0x60, 1)
> +...
> +
> +Example: Clock consumer node for GPIO2:
> +
> +&gpio2 {
> +       clocks = <&cm_l4per_clkctrl OMAP4_GPIO2_CLKCTRL
> +		 &cm_l4per_clkctrl OMAP4_GPIO2_CLKCTRL_DBCLK>;
> +};
> -- 
> 2.11.0
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] Documentation: dt-bindings: Add binding documentation for TI clkctrl clocks
  2017-01-10 15:44     ` Tony Lindgren
@ 2017-01-13 16:36         ` Rob Herring
  -1 siblings, 0 replies; 10+ messages in thread
From: Rob Herring @ 2017-01-13 16:36 UTC (permalink / raw)
  To: Tony Lindgren
  Cc: Michael Turquette, Stephen Boyd, Tero Kristo,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-clk-u79uwXL29TY76Z2rM5mHXA,
	linux-omap-u79uwXL29TY76Z2rM5mHXA, Paul Walmsley

On Tue, Jan 10, 2017 at 07:44:01AM -0800, Tony Lindgren wrote:
> * Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> [170109 15:43]:
> > Texas Instruments omap variant SoCs starting with omap4 have a clkctrl
> > clock controller instance for each interconnect target module. The clkctrl
> > controls functional and interface clocks for the module.
> > 
> > The clkctrl clocks are currently handled by arch/arm/mach-omap2 hwmod code.
> > With this binding and a related clock device driver we can start moving the
> > clkctrl clock handling to live in drivers/clk/ti.
> > 
> > For hardware reference, see omap4430 TRM "Table 3-1312. L4PER_CM2 Registers
> > Mapping Summary" for example. It show one instance of a clkctrl clock
> > controller with multiple clkctrl registers.
> > 
> > Note that this binding allows keeping the clockdomain related parts out of
> > drivers/clock. The CLKCTCTRL and DYNAMICDEP registers can be handled by
> > using a separate driver in drivers/soc/ti and genpd. If the clockdomain
> > driver needs to know it's clocks, we can just set the the clkctrl device
> > instances to be children of the related clockdomain device.
> > 
> > On omap4 CM_L3INIT_USB_HOST_HS_CLKCTRL on omap5 has eight OPTFCLKEN bits.
> > So we need to shift the clock index to avoid index conflict for the clock
> > consumer binding with the next clkctrl offset on omap4.
> > 
> > Cc: Paul Walmsley <paul-DWxLp4Yu+b8AvxtiuMwx3w@public.gmane.org>
> > Cc: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> > Signed-off-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
> > ---
> > 
> > So here's what I was able to come up for the clkctr binding based on
> > all we've discussed so far. Can you guys please take a look and see
> > if it looks OK to you before we do the device driver?
> > 
> > Also, does anybody have better suggestions for addressing the optional
> > clocks in each clkctrl register?
> 
> The other option that might be worth considering is to make use of the
> #clock-cells property. Then the index of any optional clock could be passed
> in the second cell.
> 
> The third cell could be used to set the modulemode for the clock (software
> controlled or hardware controlled) instead of using a custom property
> at the clock controllel level.

I guess I prefer this way. Or you could do a mixture of both proposals 
with 2 cells. The first being the clock id and the 2nd flags. 

What's the max optional clocks in theory? B picked from the current 
worst case seems a bit worrying. Why not 16? Upper half is offset, lower 
half is index. 

> In that case clock consume usage would look like the following using
> #clock-cells = <3>:
> 
> #define OMAP4_CLKCTRL_OFFSET		0x20
> #define MODULEMODE_HWCTRL		1
> #define MODULEMODE_SWCTRL		2

Can you make one of these 0 instead or is both being set valid?

> 
> #define OMAP_CLKCTRL_INDEX(offset)	((offset) - OMAP4_CLKCTRL_OFFSET)
> 
> #define OMAP4_GPTIMER10_CLKTRL		OMAP_CLKCTRL_INDEX(0x28)
> #define OMAP4_GPTIMER11_CLKTRL		OMAP_CLKCTRL_INDEX(0x30)
> #define OMAP4_GPTIMER2_CLKTRL		OMAP_CLKCTRL_INDEX(0x38)
> ...
> #define OMAP4_GPIO2_CLKCTRL		OMAP_CLKCTRL_INDEX(0x60)
> ...
> 
> &gpio2 {
> 	clocks = <&cm_l4per_clkctrl OMAP4_GPIO2_CLKCTRL 0 MODULEMODE_HWCTRL
> 		  &cm_l4per_clkctrl OMAP4_GPIO2_CLKCTRL_DBCLK 1 0>;

Drop the _DBCLK here, right?

Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] Documentation: dt-bindings: Add binding documentation for TI clkctrl clocks
@ 2017-01-13 16:36         ` Rob Herring
  0 siblings, 0 replies; 10+ messages in thread
From: Rob Herring @ 2017-01-13 16:36 UTC (permalink / raw)
  To: Tony Lindgren
  Cc: Michael Turquette, Stephen Boyd, Tero Kristo, devicetree,
	linux-clk, linux-omap, Paul Walmsley

On Tue, Jan 10, 2017 at 07:44:01AM -0800, Tony Lindgren wrote:
> * Tony Lindgren <tony@atomide.com> [170109 15:43]:
> > Texas Instruments omap variant SoCs starting with omap4 have a clkctrl
> > clock controller instance for each interconnect target module. The clkctrl
> > controls functional and interface clocks for the module.
> > 
> > The clkctrl clocks are currently handled by arch/arm/mach-omap2 hwmod code.
> > With this binding and a related clock device driver we can start moving the
> > clkctrl clock handling to live in drivers/clk/ti.
> > 
> > For hardware reference, see omap4430 TRM "Table 3-1312. L4PER_CM2 Registers
> > Mapping Summary" for example. It show one instance of a clkctrl clock
> > controller with multiple clkctrl registers.
> > 
> > Note that this binding allows keeping the clockdomain related parts out of
> > drivers/clock. The CLKCTCTRL and DYNAMICDEP registers can be handled by
> > using a separate driver in drivers/soc/ti and genpd. If the clockdomain
> > driver needs to know it's clocks, we can just set the the clkctrl device
> > instances to be children of the related clockdomain device.
> > 
> > On omap4 CM_L3INIT_USB_HOST_HS_CLKCTRL on omap5 has eight OPTFCLKEN bits.
> > So we need to shift the clock index to avoid index conflict for the clock
> > consumer binding with the next clkctrl offset on omap4.
> > 
> > Cc: Paul Walmsley <paul@pwsan.com>
> > Cc: Rob Herring <robh@kernel.org>
> > Signed-off-by: Tony Lindgren <tony@atomide.com>
> > ---
> > 
> > So here's what I was able to come up for the clkctr binding based on
> > all we've discussed so far. Can you guys please take a look and see
> > if it looks OK to you before we do the device driver?
> > 
> > Also, does anybody have better suggestions for addressing the optional
> > clocks in each clkctrl register?
> 
> The other option that might be worth considering is to make use of the
> #clock-cells property. Then the index of any optional clock could be passed
> in the second cell.
> 
> The third cell could be used to set the modulemode for the clock (software
> controlled or hardware controlled) instead of using a custom property
> at the clock controllel level.

I guess I prefer this way. Or you could do a mixture of both proposals 
with 2 cells. The first being the clock id and the 2nd flags. 

What's the max optional clocks in theory? B picked from the current 
worst case seems a bit worrying. Why not 16? Upper half is offset, lower 
half is index. 

> In that case clock consume usage would look like the following using
> #clock-cells = <3>:
> 
> #define OMAP4_CLKCTRL_OFFSET		0x20
> #define MODULEMODE_HWCTRL		1
> #define MODULEMODE_SWCTRL		2

Can you make one of these 0 instead or is both being set valid?

> 
> #define OMAP_CLKCTRL_INDEX(offset)	((offset) - OMAP4_CLKCTRL_OFFSET)
> 
> #define OMAP4_GPTIMER10_CLKTRL		OMAP_CLKCTRL_INDEX(0x28)
> #define OMAP4_GPTIMER11_CLKTRL		OMAP_CLKCTRL_INDEX(0x30)
> #define OMAP4_GPTIMER2_CLKTRL		OMAP_CLKCTRL_INDEX(0x38)
> ...
> #define OMAP4_GPIO2_CLKCTRL		OMAP_CLKCTRL_INDEX(0x60)
> ...
> 
> &gpio2 {
> 	clocks = <&cm_l4per_clkctrl OMAP4_GPIO2_CLKCTRL 0 MODULEMODE_HWCTRL
> 		  &cm_l4per_clkctrl OMAP4_GPIO2_CLKCTRL_DBCLK 1 0>;

Drop the _DBCLK here, right?

Rob

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] Documentation: dt-bindings: Add binding documentation for TI clkctrl clocks
  2017-01-13 16:36         ` Rob Herring
@ 2017-01-13 17:13           ` Tony Lindgren
  -1 siblings, 0 replies; 10+ messages in thread
From: Tony Lindgren @ 2017-01-13 17:13 UTC (permalink / raw)
  To: Rob Herring
  Cc: Michael Turquette, Stephen Boyd, Tero Kristo,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-clk-u79uwXL29TY76Z2rM5mHXA,
	linux-omap-u79uwXL29TY76Z2rM5mHXA, Paul Walmsley

* Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> [170113 08:37]:
> On Tue, Jan 10, 2017 at 07:44:01AM -0800, Tony Lindgren wrote:
> > * Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> [170109 15:43]:
> > > Texas Instruments omap variant SoCs starting with omap4 have a clkctrl
> > > clock controller instance for each interconnect target module. The clkctrl
> > > controls functional and interface clocks for the module.
> > > 
> > > The clkctrl clocks are currently handled by arch/arm/mach-omap2 hwmod code.
> > > With this binding and a related clock device driver we can start moving the
> > > clkctrl clock handling to live in drivers/clk/ti.
> > > 
> > > For hardware reference, see omap4430 TRM "Table 3-1312. L4PER_CM2 Registers
> > > Mapping Summary" for example. It show one instance of a clkctrl clock
> > > controller with multiple clkctrl registers.
> > > 
> > > Note that this binding allows keeping the clockdomain related parts out of
> > > drivers/clock. The CLKCTCTRL and DYNAMICDEP registers can be handled by
> > > using a separate driver in drivers/soc/ti and genpd. If the clockdomain
> > > driver needs to know it's clocks, we can just set the the clkctrl device
> > > instances to be children of the related clockdomain device.
> > > 
> > > On omap4 CM_L3INIT_USB_HOST_HS_CLKCTRL on omap5 has eight OPTFCLKEN bits.
> > > So we need to shift the clock index to avoid index conflict for the clock
> > > consumer binding with the next clkctrl offset on omap4.
> > > 
> > > Cc: Paul Walmsley <paul-DWxLp4Yu+b8AvxtiuMwx3w@public.gmane.org>
> > > Cc: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> > > Signed-off-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
> > > ---
> > > 
> > > So here's what I was able to come up for the clkctr binding based on
> > > all we've discussed so far. Can you guys please take a look and see
> > > if it looks OK to you before we do the device driver?
> > > 
> > > Also, does anybody have better suggestions for addressing the optional
> > > clocks in each clkctrl register?
> > 
> > The other option that might be worth considering is to make use of the
> > #clock-cells property. Then the index of any optional clock could be passed
> > in the second cell.
> > 
> > The third cell could be used to set the modulemode for the clock (software
> > controlled or hardware controlled) instead of using a custom property
> > at the clock controllel level.
> 
> I guess I prefer this way. Or you could do a mixture of both proposals 
> with 2 cells. The first being the clock id and the 2nd flags. 

OK. I don't think we can do it with two cells with using real hardware
offsets for the clocks though. So in that case I'd prefer the three
cell binding as below.

> What's the max optional clocks in theory? B picked from the current 
> worst case seems a bit worrying. Why not 16? Upper half is offset, lower 
> half is index. 

It seems the max is "stuff it into whatever bits are available" in the
register :)  And I just noticed omap5 CM_L3INIT_USB_HOST_HS_CLKCTRL has 10
optional clocks, not 8. So yeah let's assume it could be even more.

> > In that case clock consume usage would look like the following using
> > #clock-cells = <3>:
> > 
> > #define OMAP4_CLKCTRL_OFFSET		0x20
> > #define MODULEMODE_HWCTRL		1
> > #define MODULEMODE_SWCTRL		2
> 
> Can you make one of these 0 instead or is both being set valid?

For MODULEMODE clock 0 means disabed. HWCTRL and SWCTRL are flags for
enabled mode.

So clock index 0 would be the MODULEMODE clock, index 1 first optional clock
and so on. The index could be also be the offset in the actual register
if you prefer that.

> > #define OMAP_CLKCTRL_INDEX(offset)	((offset) - OMAP4_CLKCTRL_OFFSET)
> > 
> > #define OMAP4_GPTIMER10_CLKTRL		OMAP_CLKCTRL_INDEX(0x28)
> > #define OMAP4_GPTIMER11_CLKTRL		OMAP_CLKCTRL_INDEX(0x30)
> > #define OMAP4_GPTIMER2_CLKTRL		OMAP_CLKCTRL_INDEX(0x38)
> > ...
> > #define OMAP4_GPIO2_CLKCTRL		OMAP_CLKCTRL_INDEX(0x60)
> > ...
> > 
> > &gpio2 {
> > 	clocks = <&cm_l4per_clkctrl OMAP4_GPIO2_CLKCTRL 0 MODULEMODE_HWCTRL
> > 		  &cm_l4per_clkctrl OMAP4_GPIO2_CLKCTRL_DBCLK 1 0>;
> 
> Drop the _DBCLK here, right?

Ah sorry yeah this should be:

&gpio2 {
	clocks = <&cm_l4per_clkctrl OMAP4_GPIO2_CLKCTRL 0 MODULEMODE_HWCTRL
		  &cm_l4per_clkctrl OMAP4_GPIO2_CLKCTRL 1 0>;
};

or if using actual bit offsets within the register instead of optional
clock instance count:

&gpio2 {
	clocks = <&cm_l4per_clkctrl OMAP4_GPIO2_CLKCTRL 0 MODULEMODE_HWCTRL
		  &cm_l4per_clkctrl OMAP4_GPIO2_CLKCTRL 8 0>;
};

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] Documentation: dt-bindings: Add binding documentation for TI clkctrl clocks
@ 2017-01-13 17:13           ` Tony Lindgren
  0 siblings, 0 replies; 10+ messages in thread
From: Tony Lindgren @ 2017-01-13 17:13 UTC (permalink / raw)
  To: Rob Herring
  Cc: Michael Turquette, Stephen Boyd, Tero Kristo, devicetree,
	linux-clk, linux-omap, Paul Walmsley

* Rob Herring <robh@kernel.org> [170113 08:37]:
> On Tue, Jan 10, 2017 at 07:44:01AM -0800, Tony Lindgren wrote:
> > * Tony Lindgren <tony@atomide.com> [170109 15:43]:
> > > Texas Instruments omap variant SoCs starting with omap4 have a clkctrl
> > > clock controller instance for each interconnect target module. The clkctrl
> > > controls functional and interface clocks for the module.
> > > 
> > > The clkctrl clocks are currently handled by arch/arm/mach-omap2 hwmod code.
> > > With this binding and a related clock device driver we can start moving the
> > > clkctrl clock handling to live in drivers/clk/ti.
> > > 
> > > For hardware reference, see omap4430 TRM "Table 3-1312. L4PER_CM2 Registers
> > > Mapping Summary" for example. It show one instance of a clkctrl clock
> > > controller with multiple clkctrl registers.
> > > 
> > > Note that this binding allows keeping the clockdomain related parts out of
> > > drivers/clock. The CLKCTCTRL and DYNAMICDEP registers can be handled by
> > > using a separate driver in drivers/soc/ti and genpd. If the clockdomain
> > > driver needs to know it's clocks, we can just set the the clkctrl device
> > > instances to be children of the related clockdomain device.
> > > 
> > > On omap4 CM_L3INIT_USB_HOST_HS_CLKCTRL on omap5 has eight OPTFCLKEN bits.
> > > So we need to shift the clock index to avoid index conflict for the clock
> > > consumer binding with the next clkctrl offset on omap4.
> > > 
> > > Cc: Paul Walmsley <paul@pwsan.com>
> > > Cc: Rob Herring <robh@kernel.org>
> > > Signed-off-by: Tony Lindgren <tony@atomide.com>
> > > ---
> > > 
> > > So here's what I was able to come up for the clkctr binding based on
> > > all we've discussed so far. Can you guys please take a look and see
> > > if it looks OK to you before we do the device driver?
> > > 
> > > Also, does anybody have better suggestions for addressing the optional
> > > clocks in each clkctrl register?
> > 
> > The other option that might be worth considering is to make use of the
> > #clock-cells property. Then the index of any optional clock could be passed
> > in the second cell.
> > 
> > The third cell could be used to set the modulemode for the clock (software
> > controlled or hardware controlled) instead of using a custom property
> > at the clock controllel level.
> 
> I guess I prefer this way. Or you could do a mixture of both proposals 
> with 2 cells. The first being the clock id and the 2nd flags. 

OK. I don't think we can do it with two cells with using real hardware
offsets for the clocks though. So in that case I'd prefer the three
cell binding as below.

> What's the max optional clocks in theory? B picked from the current 
> worst case seems a bit worrying. Why not 16? Upper half is offset, lower 
> half is index. 

It seems the max is "stuff it into whatever bits are available" in the
register :)  And I just noticed omap5 CM_L3INIT_USB_HOST_HS_CLKCTRL has 10
optional clocks, not 8. So yeah let's assume it could be even more.

> > In that case clock consume usage would look like the following using
> > #clock-cells = <3>:
> > 
> > #define OMAP4_CLKCTRL_OFFSET		0x20
> > #define MODULEMODE_HWCTRL		1
> > #define MODULEMODE_SWCTRL		2
> 
> Can you make one of these 0 instead or is both being set valid?

For MODULEMODE clock 0 means disabed. HWCTRL and SWCTRL are flags for
enabled mode.

So clock index 0 would be the MODULEMODE clock, index 1 first optional clock
and so on. The index could be also be the offset in the actual register
if you prefer that.

> > #define OMAP_CLKCTRL_INDEX(offset)	((offset) - OMAP4_CLKCTRL_OFFSET)
> > 
> > #define OMAP4_GPTIMER10_CLKTRL		OMAP_CLKCTRL_INDEX(0x28)
> > #define OMAP4_GPTIMER11_CLKTRL		OMAP_CLKCTRL_INDEX(0x30)
> > #define OMAP4_GPTIMER2_CLKTRL		OMAP_CLKCTRL_INDEX(0x38)
> > ...
> > #define OMAP4_GPIO2_CLKCTRL		OMAP_CLKCTRL_INDEX(0x60)
> > ...
> > 
> > &gpio2 {
> > 	clocks = <&cm_l4per_clkctrl OMAP4_GPIO2_CLKCTRL 0 MODULEMODE_HWCTRL
> > 		  &cm_l4per_clkctrl OMAP4_GPIO2_CLKCTRL_DBCLK 1 0>;
> 
> Drop the _DBCLK here, right?

Ah sorry yeah this should be:

&gpio2 {
	clocks = <&cm_l4per_clkctrl OMAP4_GPIO2_CLKCTRL 0 MODULEMODE_HWCTRL
		  &cm_l4per_clkctrl OMAP4_GPIO2_CLKCTRL 1 0>;
};

or if using actual bit offsets within the register instead of optional
clock instance count:

&gpio2 {
	clocks = <&cm_l4per_clkctrl OMAP4_GPIO2_CLKCTRL 0 MODULEMODE_HWCTRL
		  &cm_l4per_clkctrl OMAP4_GPIO2_CLKCTRL 8 0>;
};

Regards,

Tony

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] Documentation: dt-bindings: Add binding documentation for TI clkctrl clocks
  2017-01-09 23:42 [PATCH] Documentation: dt-bindings: Add binding documentation for TI clkctrl clocks Tony Lindgren
@ 2017-01-16 15:19     ` Tero Kristo
  0 siblings, 0 replies; 10+ messages in thread
From: Tero Kristo @ 2017-01-16 15:19 UTC (permalink / raw)
  To: Tony Lindgren, Michael Turquette, Stephen Boyd
  Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-clk-u79uwXL29TY76Z2rM5mHXA,
	linux-omap-u79uwXL29TY76Z2rM5mHXA, Paul Walmsley, Rob Herring

On 10/01/17 01:42, Tony Lindgren wrote:
> Texas Instruments omap variant SoCs starting with omap4 have a clkctrl
> clock controller instance for each interconnect target module. The clkctrl
> controls functional and interface clocks for the module.
>
> The clkctrl clocks are currently handled by arch/arm/mach-omap2 hwmod code.
> With this binding and a related clock device driver we can start moving the
> clkctrl clock handling to live in drivers/clk/ti.
>
> For hardware reference, see omap4430 TRM "Table 3-1312. L4PER_CM2 Registers
> Mapping Summary" for example. It show one instance of a clkctrl clock
> controller with multiple clkctrl registers.
>
> Note that this binding allows keeping the clockdomain related parts out of
> drivers/clock. The CLKCTCTRL and DYNAMICDEP registers can be handled by
> using a separate driver in drivers/soc/ti and genpd. If the clockdomain
> driver needs to know it's clocks, we can just set the the clkctrl device
> instances to be children of the related clockdomain device.
>
> On omap4 CM_L3INIT_USB_HOST_HS_CLKCTRL on omap5 has eight OPTFCLKEN bits.
> So we need to shift the clock index to avoid index conflict for the clock
> consumer binding with the next clkctrl offset on omap4.
>
> Cc: Paul Walmsley <paul-DWxLp4Yu+b8AvxtiuMwx3w@public.gmane.org>
> Cc: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Signed-off-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
> ---
>
> So here's what I was able to come up for the clkctr binding based on
> all we've discussed so far. Can you guys please take a look and see
> if it looks OK to you before we do the device driver?
>
> Also, does anybody have better suggestions for addressing the optional
> clocks in each clkctrl register?
>
> ---
>  .../devicetree/bindings/clock/ti-clkctrl.txt       | 56 ++++++++++++++++++++++
>  1 file changed, 56 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/clock/ti-clkctrl.txt
>
> diff --git a/Documentation/devicetree/bindings/clock/ti-clkctrl.txt b/Documentation/devicetree/bindings/clock/ti-clkctrl.txt
> new file mode 100644
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/ti-clkctrl.txt
> @@ -0,0 +1,56 @@
> +Texas Instruments clkctrl clock binding
> +
> +Texas Instruments SoCs can have a clkctrl clock controller for each
> +interconnect target module. The clkctrl clock controller manages functional
> +and interface clocks for each module. Each clkctrl controller can also
> +gate one or more optional functional clocks for a module. The clkctrl
> +clock controller is typical for omap3 and later variants.
> +
> +The clock consumers can specify the index of the clkctrl clock using
> +the hardware offset from the clkctrl instance register space. The optional
> +functional clocks can be specified by clkctrl hardware offset plus the
> +index of the optional clock. Please see the Linux clock framework binding
> +at Documentation/devicetree/bindings/clock/clock-bindings.txt.
> +
> +Required properties :
> +- compatible : shall be "ti,clkctrl"
> +- #clock-cells : shall contain 1
> +
> +Optional properties :
> +- "ti,modulemode-auto" : list of clkctrl offsets using automatic gating
> +
> +Example: Clock controller node:
> +
> +&cm_l4per {
> +	cm_l4per_clkctrl: clk@20 {
> +		compatible = "ti,clkctrl";
> +		reg = <0x20 0x1b0>;
> +		#clock-cells = 1;
> +		ti,modulemode-auto = <OMAP4_GPIO2_CLKCTRL>;
> +	};
> +};

So, in this example, what would cm_l4per be? Is it a clockdomain? Or is 
it just an arbitrary interconnect instance, and the clockdomain would 
also be a separate node under cm_l4per?

Shall we add power-domains = <&cm_l4per_clkdm>; entry under the 
cm_l4per_clkctrl in this example? (My thinking is that we will represent 
both OMAP clock and power domains as generic power domains within kernel 
/ DT.)

-Tero

> +
> +Example: Preprocessor helper macros in dt-bindings/ti-clkctrl.h
> +
> +#define OMAP4_CLKCTRL_OFFSET		0x20
> +
> +#define OMAP_CLKCTRL_INDEX(offset)		\
> +	(((offset) - OMAP4_CLKCTRL_OFFSET) << 8)
> +
> +#define OMAP_CLKCTRL_OPT_INDEX(offset, optclk)	\
> +	(OMAP_CLKCTRL_INDEX(offset) + (optclk))
> +
> +#define OMAP4_GPTIMER10_CLKTRL		OMAP_CLKCTRL_INDEX(0x28)
> +#define OMAP4_GPTIMER11_CLKTRL		OMAP_CLKCTRL_INDEX(0x30)
> +#define OMAP4_GPTIMER2_CLKTRL		OMAP_CLKCTRL_INDEX(0x38)
> +...
> +#define OMAP4_GPIO2_CLKCTRL		OMAP_CLKCTRL_INDEX(0x60)
> +#define OMAP4_GPIO2_CLKCTRL_DBCLK	OMAP_CLKCTRL_OPT_INDEX(0x60, 1)
> +...
> +
> +Example: Clock consumer node for GPIO2:
> +
> +&gpio2 {
> +       clocks = <&cm_l4per_clkctrl OMAP4_GPIO2_CLKCTRL
> +		 &cm_l4per_clkctrl OMAP4_GPIO2_CLKCTRL_DBCLK>;
> +};
>

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] Documentation: dt-bindings: Add binding documentation for TI clkctrl clocks
@ 2017-01-16 15:19     ` Tero Kristo
  0 siblings, 0 replies; 10+ messages in thread
From: Tero Kristo @ 2017-01-16 15:19 UTC (permalink / raw)
  To: Tony Lindgren, Michael Turquette, Stephen Boyd
  Cc: devicetree, linux-clk, linux-omap, Paul Walmsley, Rob Herring

On 10/01/17 01:42, Tony Lindgren wrote:
> Texas Instruments omap variant SoCs starting with omap4 have a clkctrl
> clock controller instance for each interconnect target module. The clkctrl
> controls functional and interface clocks for the module.
>
> The clkctrl clocks are currently handled by arch/arm/mach-omap2 hwmod code.
> With this binding and a related clock device driver we can start moving the
> clkctrl clock handling to live in drivers/clk/ti.
>
> For hardware reference, see omap4430 TRM "Table 3-1312. L4PER_CM2 Registers
> Mapping Summary" for example. It show one instance of a clkctrl clock
> controller with multiple clkctrl registers.
>
> Note that this binding allows keeping the clockdomain related parts out of
> drivers/clock. The CLKCTCTRL and DYNAMICDEP registers can be handled by
> using a separate driver in drivers/soc/ti and genpd. If the clockdomain
> driver needs to know it's clocks, we can just set the the clkctrl device
> instances to be children of the related clockdomain device.
>
> On omap4 CM_L3INIT_USB_HOST_HS_CLKCTRL on omap5 has eight OPTFCLKEN bits.
> So we need to shift the clock index to avoid index conflict for the clock
> consumer binding with the next clkctrl offset on omap4.
>
> Cc: Paul Walmsley <paul@pwsan.com>
> Cc: Rob Herring <robh@kernel.org>
> Signed-off-by: Tony Lindgren <tony@atomide.com>
> ---
>
> So here's what I was able to come up for the clkctr binding based on
> all we've discussed so far. Can you guys please take a look and see
> if it looks OK to you before we do the device driver?
>
> Also, does anybody have better suggestions for addressing the optional
> clocks in each clkctrl register?
>
> ---
>  .../devicetree/bindings/clock/ti-clkctrl.txt       | 56 ++++++++++++++++++++++
>  1 file changed, 56 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/clock/ti-clkctrl.txt
>
> diff --git a/Documentation/devicetree/bindings/clock/ti-clkctrl.txt b/Documentation/devicetree/bindings/clock/ti-clkctrl.txt
> new file mode 100644
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/ti-clkctrl.txt
> @@ -0,0 +1,56 @@
> +Texas Instruments clkctrl clock binding
> +
> +Texas Instruments SoCs can have a clkctrl clock controller for each
> +interconnect target module. The clkctrl clock controller manages functional
> +and interface clocks for each module. Each clkctrl controller can also
> +gate one or more optional functional clocks for a module. The clkctrl
> +clock controller is typical for omap3 and later variants.
> +
> +The clock consumers can specify the index of the clkctrl clock using
> +the hardware offset from the clkctrl instance register space. The optional
> +functional clocks can be specified by clkctrl hardware offset plus the
> +index of the optional clock. Please see the Linux clock framework binding
> +at Documentation/devicetree/bindings/clock/clock-bindings.txt.
> +
> +Required properties :
> +- compatible : shall be "ti,clkctrl"
> +- #clock-cells : shall contain 1
> +
> +Optional properties :
> +- "ti,modulemode-auto" : list of clkctrl offsets using automatic gating
> +
> +Example: Clock controller node:
> +
> +&cm_l4per {
> +	cm_l4per_clkctrl: clk@20 {
> +		compatible = "ti,clkctrl";
> +		reg = <0x20 0x1b0>;
> +		#clock-cells = 1;
> +		ti,modulemode-auto = <OMAP4_GPIO2_CLKCTRL>;
> +	};
> +};

So, in this example, what would cm_l4per be? Is it a clockdomain? Or is 
it just an arbitrary interconnect instance, and the clockdomain would 
also be a separate node under cm_l4per?

Shall we add power-domains = <&cm_l4per_clkdm>; entry under the 
cm_l4per_clkctrl in this example? (My thinking is that we will represent 
both OMAP clock and power domains as generic power domains within kernel 
/ DT.)

-Tero

> +
> +Example: Preprocessor helper macros in dt-bindings/ti-clkctrl.h
> +
> +#define OMAP4_CLKCTRL_OFFSET		0x20
> +
> +#define OMAP_CLKCTRL_INDEX(offset)		\
> +	(((offset) - OMAP4_CLKCTRL_OFFSET) << 8)
> +
> +#define OMAP_CLKCTRL_OPT_INDEX(offset, optclk)	\
> +	(OMAP_CLKCTRL_INDEX(offset) + (optclk))
> +
> +#define OMAP4_GPTIMER10_CLKTRL		OMAP_CLKCTRL_INDEX(0x28)
> +#define OMAP4_GPTIMER11_CLKTRL		OMAP_CLKCTRL_INDEX(0x30)
> +#define OMAP4_GPTIMER2_CLKTRL		OMAP_CLKCTRL_INDEX(0x38)
> +...
> +#define OMAP4_GPIO2_CLKCTRL		OMAP_CLKCTRL_INDEX(0x60)
> +#define OMAP4_GPIO2_CLKCTRL_DBCLK	OMAP_CLKCTRL_OPT_INDEX(0x60, 1)
> +...
> +
> +Example: Clock consumer node for GPIO2:
> +
> +&gpio2 {
> +       clocks = <&cm_l4per_clkctrl OMAP4_GPIO2_CLKCTRL
> +		 &cm_l4per_clkctrl OMAP4_GPIO2_CLKCTRL_DBCLK>;
> +};
>

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] Documentation: dt-bindings: Add binding documentation for TI clkctrl clocks
  2017-01-16 15:19     ` Tero Kristo
  (?)
@ 2017-01-16 17:07     ` Tony Lindgren
  -1 siblings, 0 replies; 10+ messages in thread
From: Tony Lindgren @ 2017-01-16 17:07 UTC (permalink / raw)
  To: Tero Kristo
  Cc: Michael Turquette, Stephen Boyd, devicetree, linux-clk,
	linux-omap, Paul Walmsley, Rob Herring

* Tero Kristo <t-kristo@ti.com> [170116 07:20]:
> On 10/01/17 01:42, Tony Lindgren wrote:
> > +Example: Clock controller node:
> > +
> > +&cm_l4per {
> > +	cm_l4per_clkctrl: clk@20 {
> > +		compatible = "ti,clkctrl";
> > +		reg = <0x20 0x1b0>;
> > +		#clock-cells = 1;
> > +		ti,modulemode-auto = <OMAP4_GPIO2_CLKCTRL>;
> > +	};
> > +};
> 
> So, in this example, what would cm_l4per be? Is it a clockdomain? Or is it
> just an arbitrary interconnect instance, and the clockdomain would also be a
> separate node under cm_l4per?

Good question. It's not a clockdomain, those are the CLKSTCTRL registers.
And for example "3.11.33.1 CORE_CM2 Register Summary" for core_cm2 has
multiple clockdomains under it.

Looking at the interconnect target module for cm2, it's range is from
0x4a008000 - 0x4a009fff as listed in "Table 2-3. L4_CFG Memory Space
Mapping". So that's the cm2 parent module, and whatever we can clearly
set up as separate devices under that will make things easier to
understand.

The various device instances under cm2 can be seen in "3.11.29 CM2
Instance Summary".

So how about the following would describe that hardware using the
#clock-cells = <3> as discussed:

&cm2 {	/* 0x4a008000 */
	compatible = "ti,interconnect-socket-cm", "simple-pm-bus";
	reg = <0 0x2000>;
	ranges;
	...

	ckgen_cm2: cm@100 {
		reg = <0x100 0x100>;
		compatible = <"ti,clockmanager", "simple-pm-bus">;
		ranges;
		...
	};

	always_on_cm2: cm@600 {
		reg = <0x100 0x100>;
		compatible = <"ti,clockmanager", "simple-pm-bus">;
		ranges;
		...
	};

	...

	l4per: cm@1400 {
		reg = <0x1400 0x200>;
		compatible = <"ti,clockmanager", "simple-pm-bus">;
		ranges;
		...

		/* drivers/soc/ti/clockdomain.c */
		cm_l4per@0 {
			compatible = "ti,clockdomain";
			reg = <0 0x200>;
			ranges;
			...

			/* drivers/clk/ti/clkctrl.c */
			cm_l4per_clkctrl: clk@20 {
				compatible = "ti,clkctrl";
				reg = <0x20 0x1b0>;
				#clock-cells = <3>;
			};

			...

		}

		...
	};

	...
};

Then on am335x we need to set the ranges at the "ti,clockmanager" level
as the registers are partially sorted and most of the CLKSTCTRL registers
are at the beginning for all the clockdomains. With the ranges we can
have each clkctrl instance be a child of the related clockdomain.

> Shall we add power-domains = <&cm_l4per_clkdm>; entry under the
> cm_l4per_clkctrl in this example? (My thinking is that we will represent
> both OMAP clock and power domains as generic power domains within kernel /
> DT.)

Yeah it seems we can represent both the clock and power domains with just
a single "power-domains" property.

To me it seems the "power-domains" property would then belong to the
"ti,clockdomain" node above. As the clkctrl clock instances are children
of each clockdomain then "simple-pm-bus" should automatically manage
PM runtime usecount for each clockdomain.

Regards,

Tony

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2017-01-16 17:07 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-01-09 23:42 [PATCH] Documentation: dt-bindings: Add binding documentation for TI clkctrl clocks Tony Lindgren
     [not found] ` <20170109234226.9449-1-tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
2017-01-10 15:44   ` Tony Lindgren
2017-01-10 15:44     ` Tony Lindgren
     [not found]     ` <20170110154400.GT2630-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
2017-01-13 16:36       ` Rob Herring
2017-01-13 16:36         ` Rob Herring
2017-01-13 17:13         ` Tony Lindgren
2017-01-13 17:13           ` Tony Lindgren
2017-01-16 15:19   ` Tero Kristo
2017-01-16 15:19     ` Tero Kristo
2017-01-16 17:07     ` Tony Lindgren

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.