diff mbox

[v4,1/7] Documentation: Add device tree bindings for Freescale i.MX GPC

Message ID 1392737687-25003-2-git-send-email-p.zabel@pengutronix.de
State Superseded, archived
Headers show

Commit Message

Philipp Zabel Feb. 18, 2014, 3:34 p.m. UTC
The i.MX6 contains a power controller that controls power gating and
sequencing for the SoC's power domains.

Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
---
Changes since v3:
 - Updated documentation to use fsl,power-domain property name
   and pu-power-domain as node name.
 - Removed address-cells/size-cells
---
 .../devicetree/bindings/power/fsl,imx-gpc.txt      | 58 ++++++++++++++++++++++
 1 file changed, 58 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/power/fsl,imx-gpc.txt

Comments

Arnd Bergmann Feb. 18, 2014, 6:10 p.m. UTC | #1
On Tuesday 18 February 2014 16:34:41 Philipp Zabel wrote:
> +
> +Example of a device that is part of a power domain:
> +
> +       vpu: vpu@02040000 {
> +               reg = <0x02040000 0x3c000>;
> +               /* ... */
> +               fsl,power-domain = <&pd_pu>;
> +               /* ... */
> +       };
> +

I'm really not too happy about platforms starting to add random
bindings for power domains. Unfortunately I didn't catch exynos
doing this first, but I don't want to see another platform like
that.

Can we please come up with a proper generic power domain binding
first and then add platform specific users?

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Philipp Zabel Feb. 19, 2014, 9:30 a.m. UTC | #2
Hi Arnd,

[adding Samsung guys into the loop]

Am Dienstag, den 18.02.2014, 19:10 +0100 schrieb Arnd Bergmann:
> On Tuesday 18 February 2014 16:34:41 Philipp Zabel wrote:
> > +
> > +Example of a device that is part of a power domain:
> > +
> > +       vpu: vpu@02040000 {
> > +               reg = <0x02040000 0x3c000>;
> > +               /* ... */
> > +               fsl,power-domain = <&pd_pu>;
> > +               /* ... */
> > +       };
> > +
> 
> I'm really not too happy about platforms starting to add random
> bindings for power domains. Unfortunately I didn't catch exynos
> doing this first, but I don't want to see another platform like
> that.
> 
> Can we please come up with a proper generic power domain binding
> first and then add platform specific users?

what is the process here? I've seen the samsung bindings and copied the
pattern. I guess the Exynos bindings are set in stone, and the i.MX
power domains can be handled using the same bindings.

regards
Philipp

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Arnd Bergmann Feb. 19, 2014, 2:38 p.m. UTC | #3
On Wednesday 19 February 2014, Philipp Zabel wrote:

> Am Dienstag, den 18.02.2014, 19:10 +0100 schrieb Arnd Bergmann:
> > On Tuesday 18 February 2014 16:34:41 Philipp Zabel wrote:
> > > +
> > > +Example of a device that is part of a power domain:
> > > +
> > > +       vpu: vpu@02040000 {
> > > +               reg = <0x02040000 0x3c000>;
> > > +               /* ... */
> > > +               fsl,power-domain = <&pd_pu>;
> > > +               /* ... */
> > > +       };
> > > +
> > 
> > I'm really not too happy about platforms starting to add random
> > bindings for power domains. Unfortunately I didn't catch exynos
> > doing this first, but I don't want to see another platform like
> > that.
> > 
> > Can we please come up with a proper generic power domain binding
> > first and then add platform specific users?
> 
> what is the process here? I've seen the samsung bindings and copied the
> pattern. I guess the Exynos bindings are set in stone, and the i.MX
> power domains can be handled using the same bindings.

* First of all, get the pm domain maintainers into the loop, then make
  sure all other users of pm domains are aware of what you are doing.

* Come up with a way to describe a pm_domain in a sufficiently generic
  way. It's possible you just need a phandle, but experience on other
  subsystems suggests that it helps to allow arguments, as we do for
  clocks, dmas, mailboxes, etc.

* Draft a generic binding that can work on all platforms

* Implement support for the generic binding in the platform independent
  code.

* Add a specific binding for your hardware.

* Implement support for your hardware binding on top of the generic
  code.

* Get everyone involved to Ack the generic binding and implementation.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Tomasz Figa Feb. 19, 2014, 2:51 p.m. UTC | #4
On 19.02.2014 15:38, Arnd Bergmann wrote:
> On Wednesday 19 February 2014, Philipp Zabel wrote:
>
>> Am Dienstag, den 18.02.2014, 19:10 +0100 schrieb Arnd Bergmann:
>>> On Tuesday 18 February 2014 16:34:41 Philipp Zabel wrote:
>>>> +
>>>> +Example of a device that is part of a power domain:
>>>> +
>>>> +       vpu: vpu@02040000 {
>>>> +               reg = <0x02040000 0x3c000>;
>>>> +               /* ... */
>>>> +               fsl,power-domain = <&pd_pu>;
>>>> +               /* ... */
>>>> +       };
>>>> +
>>>
>>> I'm really not too happy about platforms starting to add random
>>> bindings for power domains. Unfortunately I didn't catch exynos
>>> doing this first, but I don't want to see another platform like
>>> that.
>>>
>>> Can we please come up with a proper generic power domain binding
>>> first and then add platform specific users?
>>
>> what is the process here? I've seen the samsung bindings and copied the
>> pattern. I guess the Exynos bindings are set in stone, and the i.MX
>> power domains can be handled using the same bindings.
>
> * First of all, get the pm domain maintainers into the loop, then make
>    sure all other users of pm domains are aware of what you are doing.
>
> * Come up with a way to describe a pm_domain in a sufficiently generic
>    way. It's possible you just need a phandle, but experience on other
>    subsystems suggests that it helps to allow arguments, as we do for
>    clocks, dmas, mailboxes, etc.
>
> * Draft a generic binding that can work on all platforms
>
> * Implement support for the generic binding in the platform independent
>    code.
>
> * Add a specific binding for your hardware.
>
> * Implement support for your hardware binding on top of the generic
>    code.
>
> * Get everyone involved to Ack the generic binding and implementation.
>
> 	Arnd
>

Just wanted to share a link with you. ;)

http://www.spinics.net/lists/devicetree/msg18051.html

Best regards,
Tomasz
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Arnd Bergmann Feb. 19, 2014, 2:56 p.m. UTC | #5
On Wednesday 19 February 2014 15:51:21 Tomasz Figa wrote:
> 
> Just wanted to share a link with you. 
> 
> http://www.spinics.net/lists/devicetree/msg18051.html

Excellent, thanks for the heads-up.

Philipp, please review that patch and see if you can build on top of that
for your work.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Philipp Zabel Feb. 19, 2014, 4 p.m. UTC | #6
Am Mittwoch, den 19.02.2014, 15:56 +0100 schrieb Arnd Bergmann:
> On Wednesday 19 February 2014 15:51:21 Tomasz Figa wrote:
> > 
> > Just wanted to share a link with you. 
> > 
> > http://www.spinics.net/lists/devicetree/msg18051.html
> 
> Excellent, thanks for the heads-up.
> 
> Philipp, please review that patch and see if you can build on top of that
> for your work.

Thanks, I'll do that.

regards
Philipp

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

Patch

diff --git a/Documentation/devicetree/bindings/power/fsl,imx-gpc.txt b/Documentation/devicetree/bindings/power/fsl,imx-gpc.txt
new file mode 100644
index 0000000..05927a7
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/fsl,imx-gpc.txt
@@ -0,0 +1,58 @@ 
+Freescale i.MX General Power Controller
+=======================================
+
+The i.MX6Q General Power Control (GPC) block contains DVFS load tracking
+counters and Power Gating Control (PGC) for the CPU and PU (GPU/VPU) power
+domains.
+
+Required properties:
+- compatible: Should be "fsl,imx6q-gpc"
+- reg: should be register base and length as documented in the
+  datasheet
+- interrupts: Should contain GPC interrupt request 1
+- pu-supply: Link to the LDO regulator powering the PU power domain
+
+The gpc node should contain a 'pu-power-domain' subnode that serves as a
+phandle target for devices belonging to the PU power domain:
+
+Power domains controlled by a PGC register set
+==============================================
+
+Required properties:
+- compatible: Should be "fsl,imx6q-power-domain"
+- reg: should be register base and length as documented in the
+  datasheet
+
+Specifying power domain for IP modules
+======================================
+
+IP cores belonging to a power domain should contain a 'power-domain' property
+that is a phandle pointing to the power-domain subnode of the gpc device node.
+
+Required properties:
+- fsl,power-domain: A phandle pointing to the power-domain device tree node
+
+
+Example:
+
+	gpc: gpc@020dc000 {
+		compatible = "fsl,imx6q-gpc";
+		reg = <0x020dc000 0x4000>;
+		interrupts = <0 89 0x04 0 90 0x04>;
+		pu-supply = <&reg_pu>;
+
+		pd_pu: pu-power-domain@020dc260 {
+			compatible = "fsl,imx6q-power-domain";
+			reg = <0x020dc260 0x10>;
+		};
+	};
+
+Example of a device that is part of a power domain:
+
+	vpu: vpu@02040000 {
+		reg = <0x02040000 0x3c000>;
+		/* ... */
+		fsl,power-domain = <&pd_pu>;
+		/* ... */
+	};
+