[PATCH 4/4] devicetree: bindings: qcom,mmcc: Document GDSC binding

[PATCH 4/4] devicetree: bindings: qcom,mmcc: Document GDSC binding

[Stephen Boyd]

Document the GDSC nodes present within the multimedia clock
controller.

Cc: <devicetree@vger.kernel.org>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
---
 .../devicetree/bindings/clock/qcom,mmcc.txt        | 42 ++++++++++++++++++++++
 1 file changed, 42 insertions(+)

diff --git a/Documentation/devicetree/bindings/clock/qcom,mmcc.txt b/Documentation/devicetree/bindings/clock/qcom,mmcc.txt
index d572e9964c54..695f86ad94ea 100644
--- a/Documentation/devicetree/bindings/clock/qcom,mmcc.txt
+++ b/Documentation/devicetree/bindings/clock/qcom,mmcc.txt
@@ -19,3 +19,45 @@ Example:
 		#clock-cells = <1>;
 		#reset-cells = <1>;
 	};
+
+Qualcomm Global Distributed Switch Controller (GDSC) Binding
+------------------------------------------------------------
+
+The GDSC is responsible for safely collapsing and restoring power to
+peripheral cores on chipsets like msm8974 for power savings.
+
+Required properties:
+ - regulator-name:  A string used as a descriptive name for regulator outputs
+
+Optional properties:
+ - parent-supply:   phandle to the parent supply/regulator node
+ - qcom,retain-mem:  Presence denotes a hardware requirement to leave the
+		     forced core memory retention signals in the core's clock
+		     branch control registers asserted.
+ - qcom,retain-periph: Presence denotes a hardware requirement to leave the
+		     forced periph memory retention signal in the core's clock
+		     branch control registers asserted.
+ - qcom,skip-logic-collapse: Presence denotes a requirement to leave power to
+                             the core's logic enabled.
+ - qcom,support-hw-trigger: Presence denotes a hardware feature to switch
+			    on/off this regulator based on internal HW signals
+			    to save more power.
+
+Example:
+	clock-controller@4000000 {
+		compatible = "qcom,mmcc-msm8974";
+		reg = <0x4000000 0x1000>;
+		#clock-cells = <1>;
+		#reset-cells = <1>;
+
+		regulators {
+			gdsc_oxili_gx: gdsc_oxili_gx {
+				regulator-name = "gdsc_oxili_gx";
+				parent-supply = <&pm8841_s4>;
+				qcom,retain-mem;
+				qcom,retain-periph;
+				qcom,skip-logic-collapse;
+				qcom,support-hw-trigger;
+			};
+		};
+	};
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

Re: [PATCH 4/4] devicetree: bindings: qcom, mmcc: Document GDSC binding

[Mike Turquette]

Quoting Stephen Boyd (2014-04-04 11:45:36)
> +Example:
> +       clock-controller@4000000 {
> +               compatible = "qcom,mmcc-msm8974";
> +               reg = <0x4000000 0x1000>;
> +               #clock-cells = <1>;
> +               #reset-cells = <1>;
> +
> +               regulators {
> +                       gdsc_oxili_gx: gdsc_oxili_gx {
> +                               regulator-name = "gdsc_oxili_gx";

Hi Stephen,

It makes sense to model the gdsc's as regulators. It also makes sense to
nest them within the clock-controller node, assuming that matches the
register manual for your part.

However, does it make sense to put this new code under drivers/clk/qcom?
I don't see a compelling reason. How about breaking the registers out
into a header for easier reuse?

Regards,
Mike

> +                               parent-supply = <&pm8841_s4>;
> +                               qcom,retain-mem;
> +                               qcom,retain-periph;
> +                               qcom,skip-logic-collapse;
> +                               qcom,support-hw-trigger;
> +                       };
> +               };
> +       };
> -- 
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> hosted by The Linux Foundation
> 

Re: [PATCH 4/4] devicetree: bindings: qcom,mmcc: Document GDSC binding

[Stephen Boyd]

On 04/29, Mike Turquette wrote:
> Quoting Stephen Boyd (2014-04-04 11:45:36)
> > +Example:
> > +       clock-controller@4000000 {
> > +               compatible = "qcom,mmcc-msm8974";
> > +               reg = <0x4000000 0x1000>;
> > +               #clock-cells = <1>;
> > +               #reset-cells = <1>;
> > +
> > +               regulators {
> > +                       gdsc_oxili_gx: gdsc_oxili_gx {
> > +                               regulator-name = "gdsc_oxili_gx";
> 
> Hi Stephen,
> 
> It makes sense to model the gdsc's as regulators. It also makes sense to
> nest them within the clock-controller node, assuming that matches the
> register manual for your part.
> 
> However, does it make sense to put this new code under drivers/clk/qcom?
> I don't see a compelling reason. How about breaking the registers out
> into a header for easier reuse?

What registers are we talking about? I put this under
drivers/clk/qcom because it's one device that happens to have all
these different driver subsystems in it (clocks, reset, gdsc).

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation