Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1551334 > unrolled thread

[PATCH v3 0/4] ARM: K2G: Add support for TI-SCI Generic PM Domains

Back to article view | Back to linux.kernel

Contents

  [PATCH v3 0/4] ARM: K2G: Add support for TI-SCI Generic PM Domains Dave Gerlach <d-gerlach@ti.com> - 2017-01-04 22:10 +0100
    [PATCH v3 2/4] dt-bindings: Add TI SCI PM Domains Dave Gerlach <d-gerlach@ti.com> - 2017-01-04 22:10 +0100
      Re: [PATCH v3 2/4] dt-bindings: Add TI SCI PM Domains Rob Herring <robh@kernel.org> - 2017-01-09 19:00 +0100
        Re: [PATCH v3 2/4] dt-bindings: Add TI SCI PM Domains Dave Gerlach <d-gerlach@ti.com> - 2017-01-09 19:10 +0100
          Re: [PATCH v3 2/4] dt-bindings: Add TI SCI PM Domains Rob Herring <robh@kernel.org> - 2017-01-11 22:40 +0100
            Re: [PATCH v3 2/4] dt-bindings: Add TI SCI PM Domains Dave Gerlach <d-gerlach@ti.com> - 2017-01-12 16:30 +0100
              Re: [PATCH v3 2/4] dt-bindings: Add TI SCI PM Domains Rob Herring <robh@kernel.org> - 2017-01-13 20:30 +0100
                Re: [PATCH v3 2/4] dt-bindings: Add TI SCI PM Domains Dave Gerlach <d-gerlach@ti.com> - 2017-01-13 21:30 +0100
                  Re: [PATCH v3 2/4] dt-bindings: Add TI SCI PM Domains Rob Herring <robh@kernel.org> - 2017-01-14 03:50 +0100
    Re: [PATCH v3 0/4] ARM: K2G: Add support for TI-SCI Generic PM  Domains Dave Gerlach <d-gerlach@ti.com> - 2017-01-04 23:10 +0100
    Re: [PATCH v3 0/4] ARM: K2G: Add support for TI-SCI Generic PM  Domains Santosh Shilimkar <santosh.shilimkar@oracle.com> - 2017-01-04 23:40 +0100

#1551334 — [PATCH v3 0/4] ARM: K2G: Add support for TI-SCI Generic PM Domains

Hi,
This is v3 of the series to add support for TI-SCI Generic PM Domains.
Previous versions can be found here:

v2: https://www.spinics.net/lists/kernel/msg2364612.html
v1: http://www.spinics.net/lists/arm-kernel/msg525204.html

This version is rebased on v4.10-rc2 but is the same as v2 with the
exception of patch 2 in which the devicetree binding documentation
needed to be updated to show the k2g_pds node should be a child of
the pmmc node. Apart from that, the acks provided by Ulf were added
to patches 1 and 3.

Now that the TI-SCI series has been merged [1] this series will be ready
to go in with an ack on the DT binding. Rob had raised some questions on
the necessity ti,sci-id property but I believe these were properly
addressed during the discussion of v2 so hopefully an ack is in order now.

Regards,
Dave

[1] http://www.spinics.net/lists/arm-kernel/msg536851.html

Dave Gerlach (4):
  PM / Domains: Add generic data pointer to genpd data struct
  dt-bindings: Add TI SCI PM Domains
  soc: ti: Add ti_sci_pm_domains driver
  ARM: keystone: Drop PM domain support for k2g

 .../devicetree/bindings/soc/ti/sci-pm-domain.txt   |  59 ++++++
 MAINTAINERS                                        |   3 +
 arch/arm/mach-keystone/Kconfig                     |   1 +
 arch/arm/mach-keystone/pm_domain.c                 |   4 +-
 drivers/soc/ti/Kconfig                             |  12 ++
 drivers/soc/ti/Makefile                            |   1 +
 drivers/soc/ti/ti_sci_pm_domains.c                 | 198 +++++++++++++++++++++
 include/dt-bindings/genpd/k2g.h                    |  90 ++++++++++
 include/linux/pm_domain.h                          |   1 +
 9 files changed, 368 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
 create mode 100644 drivers/soc/ti/ti_sci_pm_domains.c
 create mode 100644 include/dt-bindings/genpd/k2g.h

-- 
2.11.0

[toc] | [next] | [standalone]

#1551358 — [PATCH v3 2/4] dt-bindings: Add TI SCI PM Domains

Add a generic power domain implementation, TI SCI PM Domains, that
will hook into the genpd framework and allow the TI SCI protocol to
control device power states.

Also, provide macros representing each device index as understood
by TI SCI to be used in the device node power-domain references.
These are identifiers for the K2G devices managed by the PMMC.

Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
---
v2->v3:
	Update k2g_pds node docs to show it should be a child of pmmc node.
	In early versions a phandle was used to point to pmmc and docs still
	incorrectly showed this.

 .../devicetree/bindings/soc/ti/sci-pm-domain.txt   | 59 ++++++++++++++
 MAINTAINERS                                        |  2 +
 include/dt-bindings/genpd/k2g.h                    | 90 ++++++++++++++++++++++
 3 files changed, 151 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
 create mode 100644 include/dt-bindings/genpd/k2g.h

diff --git a/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt b/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
new file mode 100644
index 000000000000..4c9064e512cb
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
@@ -0,0 +1,59 @@
+Texas Instruments TI-SCI Generic Power Domain
+---------------------------------------------
+
+Some TI SoCs contain a system controller (like the PMMC, etc...) that is
+responsible for controlling the state of the IPs that are present.
+Communication between the host processor running an OS and the system
+controller happens through a protocol known as TI-SCI [1]. This pm domain
+implementation plugs into the generic pm domain framework and makes use of
+the TI SCI protocol power on and off each device when needed.
+
+[1] Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
+
+PM Domain Node
+==============
+The PM domain node represents the global PM domain managed by the PMMC,
+which in this case is the single implementation as documented by the generic
+PM domain bindings in Documentation/devicetree/bindings/power/power_domain.txt.
+Because this relies on the TI SCI protocol to communicate with the PMMC it
+must be a child of the pmmc node.
+
+Required Properties:
+--------------------
+- compatible: should be "ti,sci-pm-domain"
+- #power-domain-cells: Must be 0.
+
+Example (K2G):
+-------------
+	pmmc: pmmc {
+		compatible = "ti,k2g-sci";
+		...
+
+		k2g_pds: k2g_pds {
+			compatible = "ti,sci-pm-domain";
+			#power-domain-cells = <0>;
+		};
+	};
+
+PM Domain Consumers
+===================
+Hardware blocks that require SCI control over their state must provide
+a reference to the sci-pm-domain they are part of and a unique device
+specific ID that identifies the device.
+
+Required Properties:
+--------------------
+- power-domains: phandle pointing to the corresponding PM domain node.
+- ti,sci-id: index representing the device id to be passed oevr SCI to
+	     be used for device control.
+
+See dt-bindings/genpd/k2g.h for the list of valid identifiers for k2g.
+
+Example (K2G):
+--------------------
+	uart0: serial@02530c00 {
+		compatible = "ns16550a";
+		...
+		power-domains = <&k2g_pds>;
+		ti,sci-id = <K2G_DEV_UART0>;
+	};
diff --git a/MAINTAINERS b/MAINTAINERS
index cfff2c9e3d94..7e68af170dae 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -12144,6 +12144,8 @@ S:	Maintained
 F:	Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
 F:	drivers/firmware/ti_sci*
 F:	include/linux/soc/ti/ti_sci_protocol.h
+F:	Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
+F:	include/dt-bindings/genpd/k2g.h
 
 THANKO'S RAREMONO AM/FM/SW RADIO RECEIVER USB DRIVER
 M:	Hans Verkuil <hverkuil@xs4all.nl>
diff --git a/include/dt-bindings/genpd/k2g.h b/include/dt-bindings/genpd/k2g.h
new file mode 100644
index 000000000000..91ad827e0ca1
--- /dev/null
+++ b/include/dt-bindings/genpd/k2g.h
@@ -0,0 +1,90 @@
+/*
+ * TI K2G SoC Device definitions
+ *
+ * Copyright (C) 2015-2016 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef _DT_BINDINGS_GENPD_K2G_H
+#define _DT_BINDINGS_GENPD_K2G_H
+
+/* Documented in http://processors.wiki.ti.com/index.php/TISCI */
+
+#define K2G_DEV_PMMC0			0x0000
+#define K2G_DEV_MLB0			0x0001
+#define K2G_DEV_DSS0			0x0002
+#define K2G_DEV_MCBSP0			0x0003
+#define K2G_DEV_MCASP0			0x0004
+#define K2G_DEV_MCASP1			0x0005
+#define K2G_DEV_MCASP2			0x0006
+#define K2G_DEV_DCAN0			0x0008
+#define K2G_DEV_DCAN1			0x0009
+#define K2G_DEV_EMIF0			0x000a
+#define K2G_DEV_MMCHS0			0x000b
+#define K2G_DEV_MMCHS1			0x000c
+#define K2G_DEV_GPMC0			0x000d
+#define K2G_DEV_ELM0			0x000e
+#define K2G_DEV_SPI0			0x0010
+#define K2G_DEV_SPI1			0x0011
+#define K2G_DEV_SPI2			0x0012
+#define K2G_DEV_SPI3			0x0013
+#define K2G_DEV_ICSS0			0x0014
+#define K2G_DEV_ICSS1			0x0015
+#define K2G_DEV_USB0			0x0016
+#define K2G_DEV_USB1			0x0017
+#define K2G_DEV_NSS0			0x0018
+#define K2G_DEV_PCIE0			0x0019
+#define K2G_DEV_GPIO0			0x001b
+#define K2G_DEV_GPIO1			0x001c
+#define K2G_DEV_TIMER64_0		0x001d
+#define K2G_DEV_TIMER64_1		0x001e
+#define K2G_DEV_TIMER64_2		0x001f
+#define K2G_DEV_TIMER64_3		0x0020
+#define K2G_DEV_TIMER64_4		0x0021
+#define K2G_DEV_TIMER64_5		0x0022
+#define K2G_DEV_TIMER64_6		0x0023
+#define K2G_DEV_MSGMGR0			0x0025
+#define K2G_DEV_BOOTCFG0		0x0026
+#define K2G_DEV_ARM_BOOTROM0		0x0027
+#define K2G_DEV_DSP_BOOTROM0		0x0029
+#define K2G_DEV_DEBUGSS0		0x002b
+#define K2G_DEV_UART0			0x002c
+#define K2G_DEV_UART1			0x002d
+#define K2G_DEV_UART2			0x002e
+#define K2G_DEV_EHRPWM0			0x002f
+#define K2G_DEV_EHRPWM1			0x0030
+#define K2G_DEV_EHRPWM2			0x0031
+#define K2G_DEV_EHRPWM3			0x0032
+#define K2G_DEV_EHRPWM4			0x0033
+#define K2G_DEV_EHRPWM5			0x0034
+#define K2G_DEV_EQEP0			0x0035
+#define K2G_DEV_EQEP1			0x0036
+#define K2G_DEV_EQEP2			0x0037
+#define K2G_DEV_ECAP0			0x0038
+#define K2G_DEV_ECAP1			0x0039
+#define K2G_DEV_I2C0			0x003a
+#define K2G_DEV_I2C1			0x003b
+#define K2G_DEV_I2C2			0x003c
+#define K2G_DEV_EDMA0			0x003f
+#define K2G_DEV_SEMAPHORE0		0x0040
+#define K2G_DEV_INTC0			0x0041
+#define K2G_DEV_GIC0			0x0042
+#define K2G_DEV_QSPI0			0x0043
+#define K2G_DEV_ARM_64B_COUNTER0	0x0044
+#define K2G_DEV_TETRIS0			0x0045
+#define K2G_DEV_CGEM0			0x0046
+#define K2G_DEV_MSMC0			0x0047
+#define K2G_DEV_CBASS0			0x0049
+#define K2G_DEV_BOARD0			0x004c
+#define K2G_DEV_EDMA1			0x004f
+
+#endif
-- 
2.11.0

[toc] | [prev] | [next] | [standalone]

#1554557 — Re: [PATCH v3 2/4] dt-bindings: Add TI SCI PM Domains

On Wed, Jan 04, 2017 at 02:55:34PM -0600, Dave Gerlach wrote:
> Add a generic power domain implementation, TI SCI PM Domains, that
> will hook into the genpd framework and allow the TI SCI protocol to
> control device power states.
> 
> Also, provide macros representing each device index as understood
> by TI SCI to be used in the device node power-domain references.
> These are identifiers for the K2G devices managed by the PMMC.
> 
> Signed-off-by: Nishanth Menon <nm@ti.com>
> Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
> ---
> v2->v3:
> 	Update k2g_pds node docs to show it should be a child of pmmc node.
> 	In early versions a phandle was used to point to pmmc and docs still
> 	incorrectly showed this.
> 
>  .../devicetree/bindings/soc/ti/sci-pm-domain.txt   | 59 ++++++++++++++
>  MAINTAINERS                                        |  2 +
>  include/dt-bindings/genpd/k2g.h                    | 90 ++++++++++++++++++++++
>  3 files changed, 151 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>  create mode 100644 include/dt-bindings/genpd/k2g.h
> 
> diff --git a/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt b/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
> new file mode 100644
> index 000000000000..4c9064e512cb
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
> @@ -0,0 +1,59 @@
> +Texas Instruments TI-SCI Generic Power Domain
> +---------------------------------------------
> +
> +Some TI SoCs contain a system controller (like the PMMC, etc...) that is
> +responsible for controlling the state of the IPs that are present.
> +Communication between the host processor running an OS and the system
> +controller happens through a protocol known as TI-SCI [1]. This pm domain
> +implementation plugs into the generic pm domain framework and makes use of
> +the TI SCI protocol power on and off each device when needed.
> +
> +[1] Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
> +
> +PM Domain Node
> +==============
> +The PM domain node represents the global PM domain managed by the PMMC,
> +which in this case is the single implementation as documented by the generic
> +PM domain bindings in Documentation/devicetree/bindings/power/power_domain.txt.
> +Because this relies on the TI SCI protocol to communicate with the PMMC it
> +must be a child of the pmmc node.
> +
> +Required Properties:
> +--------------------
> +- compatible: should be "ti,sci-pm-domain"
> +- #power-domain-cells: Must be 0.
> +
> +Example (K2G):
> +-------------
> +	pmmc: pmmc {
> +		compatible = "ti,k2g-sci";
> +		...
> +
> +		k2g_pds: k2g_pds {
> +			compatible = "ti,sci-pm-domain";
> +			#power-domain-cells = <0>;
> +		};
> +	};
> +
> +PM Domain Consumers
> +===================
> +Hardware blocks that require SCI control over their state must provide
> +a reference to the sci-pm-domain they are part of and a unique device
> +specific ID that identifies the device.
> +
> +Required Properties:
> +--------------------
> +- power-domains: phandle pointing to the corresponding PM domain node.
> +- ti,sci-id: index representing the device id to be passed oevr SCI to
> +	     be used for device control.

As I've already stated before, this goes in power-domain cells. When you 
have a single thing (i.e. node) that controls multiple things, then you 
you need to specify the ID for each of them in phandle args. This is how 
irqs, gpio, clocks, *everything* in DT works.

Rob

[toc] | [prev] | [next] | [standalone]

#1554563 — Re: [PATCH v3 2/4] dt-bindings: Add TI SCI PM Domains

Rob,
On 01/09/2017 11:50 AM, Rob Herring wrote:
> On Wed, Jan 04, 2017 at 02:55:34PM -0600, Dave Gerlach wrote:
>> Add a generic power domain implementation, TI SCI PM Domains, that
>> will hook into the genpd framework and allow the TI SCI protocol to
>> control device power states.
>>
>> Also, provide macros representing each device index as understood
>> by TI SCI to be used in the device node power-domain references.
>> These are identifiers for the K2G devices managed by the PMMC.
>>
>> Signed-off-by: Nishanth Menon <nm@ti.com>
>> Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
>> ---
>> v2->v3:
>> 	Update k2g_pds node docs to show it should be a child of pmmc node.
>> 	In early versions a phandle was used to point to pmmc and docs still
>> 	incorrectly showed this.
>>
>>  .../devicetree/bindings/soc/ti/sci-pm-domain.txt   | 59 ++++++++++++++
>>  MAINTAINERS                                        |  2 +
>>  include/dt-bindings/genpd/k2g.h                    | 90 ++++++++++++++++++++++
>>  3 files changed, 151 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>>  create mode 100644 include/dt-bindings/genpd/k2g.h
>>
>> diff --git a/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt b/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>> new file mode 100644
>> index 000000000000..4c9064e512cb
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>> @@ -0,0 +1,59 @@
>> +Texas Instruments TI-SCI Generic Power Domain
>> +---------------------------------------------
>> +
>> +Some TI SoCs contain a system controller (like the PMMC, etc...) that is
>> +responsible for controlling the state of the IPs that are present.
>> +Communication between the host processor running an OS and the system
>> +controller happens through a protocol known as TI-SCI [1]. This pm domain
>> +implementation plugs into the generic pm domain framework and makes use of
>> +the TI SCI protocol power on and off each device when needed.
>> +
>> +[1] Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
>> +
>> +PM Domain Node
>> +==============
>> +The PM domain node represents the global PM domain managed by the PMMC,
>> +which in this case is the single implementation as documented by the generic
>> +PM domain bindings in Documentation/devicetree/bindings/power/power_domain.txt.
>> +Because this relies on the TI SCI protocol to communicate with the PMMC it
>> +must be a child of the pmmc node.
>> +
>> +Required Properties:
>> +--------------------
>> +- compatible: should be "ti,sci-pm-domain"
>> +- #power-domain-cells: Must be 0.
>> +
>> +Example (K2G):
>> +-------------
>> +	pmmc: pmmc {
>> +		compatible = "ti,k2g-sci";
>> +		...
>> +
>> +		k2g_pds: k2g_pds {
>> +			compatible = "ti,sci-pm-domain";
>> +			#power-domain-cells = <0>;
>> +		};
>> +	};
>> +
>> +PM Domain Consumers
>> +===================
>> +Hardware blocks that require SCI control over their state must provide
>> +a reference to the sci-pm-domain they are part of and a unique device
>> +specific ID that identifies the device.
>> +
>> +Required Properties:
>> +--------------------
>> +- power-domains: phandle pointing to the corresponding PM domain node.
>> +- ti,sci-id: index representing the device id to be passed oevr SCI to
>> +	     be used for device control.
>
> As I've already stated before, this goes in power-domain cells. When you
> have a single thing (i.e. node) that controls multiple things, then you
> you need to specify the ID for each of them in phandle args. This is how
> irqs, gpio, clocks, *everything* in DT works.

You think the reasoning for doing it this way provided by both Ulf and 
myself on v2 [1] is not valid then?

 From Ulf:

To me, the TI SCI ID, is similar to a "conid" for any another "device
resource" (like clock, pinctrl, regulator etc) which we can describe
in DT and assign to a device node. The only difference here, is that
we don't have common API to fetch the resource (like clk_get(),
regulator_get()), but instead we fetches the device's resource from
SoC specific code, via genpd's device ->attach() callback.

 From me:

Yes, you've pretty much hit it on the head. It is not an index into a 
list of genpds but rather identifies the device *within* a single genpd. 
It is a property specific to each device that resides in a ti-sci-genpd, 
not a mapping describing which genpd the device belongs to. The generic 
power domain binding is concerned with mapping the device to a specific 
genpd, which is does fine for us, but we have a sub mapping for devices 
that exist inside a genpd which, we must describe as well, hence the 
ti,sci-id.


So to summarize, the genpd framework does interpret the phandle arg as 
an index into multiple genpds, just as you've said other frameworks do, 
but this is not what I am trying to do, we have multiple devices within 
this *single* genpd, hence the need for the ti,sci-id property.

Regards,
Dave

[1] https://patchwork.kernel.org/patch/9385371/

>
> Rob
>

[toc] | [prev] | [next] | [standalone]

#1556950 — Re: [PATCH v3 2/4] dt-bindings: Add TI SCI PM Domains

On Mon, Jan 9, 2017 at 11:57 AM, Dave Gerlach <d-gerlach@ti.com> wrote:
> Rob,
>
> On 01/09/2017 11:50 AM, Rob Herring wrote:
>>
>> On Wed, Jan 04, 2017 at 02:55:34PM -0600, Dave Gerlach wrote:
>>>
>>> Add a generic power domain implementation, TI SCI PM Domains, that
>>> will hook into the genpd framework and allow the TI SCI protocol to
>>> control device power states.
>>>
>>> Also, provide macros representing each device index as understood
>>> by TI SCI to be used in the device node power-domain references.
>>> These are identifiers for the K2G devices managed by the PMMC.
>>>
>>> Signed-off-by: Nishanth Menon <nm@ti.com>
>>> Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
>>> ---
>>> v2->v3:
>>>         Update k2g_pds node docs to show it should be a child of pmmc
>>> node.
>>>         In early versions a phandle was used to point to pmmc and docs
>>> still
>>>         incorrectly showed this.
>>>
>>>  .../devicetree/bindings/soc/ti/sci-pm-domain.txt   | 59 ++++++++++++++
>>>  MAINTAINERS                                        |  2 +
>>>  include/dt-bindings/genpd/k2g.h                    | 90
>>> ++++++++++++++++++++++
>>>  3 files changed, 151 insertions(+)
>>>  create mode 100644
>>> Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>>>  create mode 100644 include/dt-bindings/genpd/k2g.h
>>>
>>> diff --git a/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>>> b/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>>> new file mode 100644
>>> index 000000000000..4c9064e512cb
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>>> @@ -0,0 +1,59 @@
>>> +Texas Instruments TI-SCI Generic Power Domain
>>> +---------------------------------------------
>>> +
>>> +Some TI SoCs contain a system controller (like the PMMC, etc...) that is
>>> +responsible for controlling the state of the IPs that are present.
>>> +Communication between the host processor running an OS and the system
>>> +controller happens through a protocol known as TI-SCI [1]. This pm
>>> domain
>>> +implementation plugs into the generic pm domain framework and makes use
>>> of
>>> +the TI SCI protocol power on and off each device when needed.
>>> +
>>> +[1] Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
>>> +
>>> +PM Domain Node
>>> +==============
>>> +The PM domain node represents the global PM domain managed by the PMMC,
>>> +which in this case is the single implementation as documented by the
>>> generic
>>> +PM domain bindings in
>>> Documentation/devicetree/bindings/power/power_domain.txt.
>>> +Because this relies on the TI SCI protocol to communicate with the PMMC
>>> it
>>> +must be a child of the pmmc node.
>>> +
>>> +Required Properties:
>>> +--------------------
>>> +- compatible: should be "ti,sci-pm-domain"
>>> +- #power-domain-cells: Must be 0.
>>> +
>>> +Example (K2G):
>>> +-------------
>>> +       pmmc: pmmc {
>>> +               compatible = "ti,k2g-sci";
>>> +               ...
>>> +
>>> +               k2g_pds: k2g_pds {
>>> +                       compatible = "ti,sci-pm-domain";
>>> +                       #power-domain-cells = <0>;
>>> +               };
>>> +       };
>>> +
>>> +PM Domain Consumers
>>> +===================
>>> +Hardware blocks that require SCI control over their state must provide
>>> +a reference to the sci-pm-domain they are part of and a unique device
>>> +specific ID that identifies the device.
>>> +
>>> +Required Properties:
>>> +--------------------
>>> +- power-domains: phandle pointing to the corresponding PM domain node.
>>> +- ti,sci-id: index representing the device id to be passed oevr SCI to
>>> +            be used for device control.
>>
>>
>> As I've already stated before, this goes in power-domain cells. When you
>> have a single thing (i.e. node) that controls multiple things, then you
>> you need to specify the ID for each of them in phandle args. This is how
>> irqs, gpio, clocks, *everything* in DT works.
>
>
> You think the reasoning for doing it this way provided by both Ulf and
> myself on v2 [1] is not valid then?
>
> From Ulf:
>
> To me, the TI SCI ID, is similar to a "conid" for any another "device
> resource" (like clock, pinctrl, regulator etc) which we can describe
> in DT and assign to a device node. The only difference here, is that
> we don't have common API to fetch the resource (like clk_get(),
> regulator_get()), but instead we fetches the device's resource from
> SoC specific code, via genpd's device ->attach() callback.

Sorry, but that sounds like a kernel problem to me and has nothing to
do with DT bindings.

> From me:
>
> Yes, you've pretty much hit it on the head. It is not an index into a list
> of genpds but rather identifies the device *within* a single genpd. It is a
> property specific to each device that resides in a ti-sci-genpd, not a
> mapping describing which genpd the device belongs to. The generic power
> domain binding is concerned with mapping the device to a specific genpd,
> which is does fine for us, but we have a sub mapping for devices that exist
> inside a genpd which, we must describe as well, hence the ti,sci-id.
>
>
> So to summarize, the genpd framework does interpret the phandle arg as an
> index into multiple genpds, just as you've said other frameworks do, but
> this is not what I am trying to do, we have multiple devices within this
> *single* genpd, hence the need for the ti,sci-id property.

Fix the genpd framework rather than work around it in DT.

Rob

[toc] | [prev] | [next] | [standalone]

#1557508 — Re: [PATCH v3 2/4] dt-bindings: Add TI SCI PM Domains

Rob,
On 01/11/2017 03:34 PM, Rob Herring wrote:
> On Mon, Jan 9, 2017 at 11:57 AM, Dave Gerlach <d-gerlach@ti.com> wrote:
>> Rob,
>>
>> On 01/09/2017 11:50 AM, Rob Herring wrote:
>>>
>>> On Wed, Jan 04, 2017 at 02:55:34PM -0600, Dave Gerlach wrote:
>>>>
>>>> Add a generic power domain implementation, TI SCI PM Domains, that
>>>> will hook into the genpd framework and allow the TI SCI protocol to
>>>> control device power states.
>>>>
>>>> Also, provide macros representing each device index as understood
>>>> by TI SCI to be used in the device node power-domain references.
>>>> These are identifiers for the K2G devices managed by the PMMC.
>>>>
>>>> Signed-off-by: Nishanth Menon <nm@ti.com>
>>>> Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
>>>> ---
>>>> v2->v3:
>>>>         Update k2g_pds node docs to show it should be a child of pmmc
>>>> node.
>>>>         In early versions a phandle was used to point to pmmc and docs
>>>> still
>>>>         incorrectly showed this.
>>>>
>>>>  .../devicetree/bindings/soc/ti/sci-pm-domain.txt   | 59 ++++++++++++++
>>>>  MAINTAINERS                                        |  2 +
>>>>  include/dt-bindings/genpd/k2g.h                    | 90
>>>> ++++++++++++++++++++++
>>>>  3 files changed, 151 insertions(+)
>>>>  create mode 100644
>>>> Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>>>>  create mode 100644 include/dt-bindings/genpd/k2g.h
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>>>> b/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>>>> new file mode 100644
>>>> index 000000000000..4c9064e512cb
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>>>> @@ -0,0 +1,59 @@
>>>> +Texas Instruments TI-SCI Generic Power Domain
>>>> +---------------------------------------------
>>>> +
>>>> +Some TI SoCs contain a system controller (like the PMMC, etc...) that is
>>>> +responsible for controlling the state of the IPs that are present.
>>>> +Communication between the host processor running an OS and the system
>>>> +controller happens through a protocol known as TI-SCI [1]. This pm
>>>> domain
>>>> +implementation plugs into the generic pm domain framework and makes use
>>>> of
>>>> +the TI SCI protocol power on and off each device when needed.
>>>> +
>>>> +[1] Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
>>>> +
>>>> +PM Domain Node
>>>> +==============
>>>> +The PM domain node represents the global PM domain managed by the PMMC,
>>>> +which in this case is the single implementation as documented by the
>>>> generic
>>>> +PM domain bindings in
>>>> Documentation/devicetree/bindings/power/power_domain.txt.
>>>> +Because this relies on the TI SCI protocol to communicate with the PMMC
>>>> it
>>>> +must be a child of the pmmc node.
>>>> +
>>>> +Required Properties:
>>>> +--------------------
>>>> +- compatible: should be "ti,sci-pm-domain"
>>>> +- #power-domain-cells: Must be 0.
>>>> +
>>>> +Example (K2G):
>>>> +-------------
>>>> +       pmmc: pmmc {
>>>> +               compatible = "ti,k2g-sci";
>>>> +               ...
>>>> +
>>>> +               k2g_pds: k2g_pds {
>>>> +                       compatible = "ti,sci-pm-domain";
>>>> +                       #power-domain-cells = <0>;
>>>> +               };
>>>> +       };
>>>> +
>>>> +PM Domain Consumers
>>>> +===================
>>>> +Hardware blocks that require SCI control over their state must provide
>>>> +a reference to the sci-pm-domain they are part of and a unique device
>>>> +specific ID that identifies the device.
>>>> +
>>>> +Required Properties:
>>>> +--------------------
>>>> +- power-domains: phandle pointing to the corresponding PM domain node.
>>>> +- ti,sci-id: index representing the device id to be passed oevr SCI to
>>>> +            be used for device control.
>>>
>>>
>>> As I've already stated before, this goes in power-domain cells. When you
>>> have a single thing (i.e. node) that controls multiple things, then you
>>> you need to specify the ID for each of them in phandle args. This is how
>>> irqs, gpio, clocks, *everything* in DT works.
>>
>>
>> You think the reasoning for doing it this way provided by both Ulf and
>> myself on v2 [1] is not valid then?
>>
>> From Ulf:
>>
>> To me, the TI SCI ID, is similar to a "conid" for any another "device
>> resource" (like clock, pinctrl, regulator etc) which we can describe
>> in DT and assign to a device node. The only difference here, is that
>> we don't have common API to fetch the resource (like clk_get(),
>> regulator_get()), but instead we fetches the device's resource from
>> SoC specific code, via genpd's device ->attach() callback.
>
> Sorry, but that sounds like a kernel problem to me and has nothing to
> do with DT bindings.
>
>> From me:
>>
>> Yes, you've pretty much hit it on the head. It is not an index into a list
>> of genpds but rather identifies the device *within* a single genpd. It is a
>> property specific to each device that resides in a ti-sci-genpd, not a
>> mapping describing which genpd the device belongs to. The generic power
>> domain binding is concerned with mapping the device to a specific genpd,
>> which is does fine for us, but we have a sub mapping for devices that exist
>> inside a genpd which, we must describe as well, hence the ti,sci-id.
>>
>>
>> So to summarize, the genpd framework does interpret the phandle arg as an
>> index into multiple genpds, just as you've said other frameworks do, but
>> this is not what I am trying to do, we have multiple devices within this
>> *single* genpd, hence the need for the ti,sci-id property.
>
> Fix the genpd framework rather than work around it in DT.

I still disagree that this has nothing to do with DT bindings, as the 
current DT binding represents something different already. I am trying 
to extend it to give me additional information needed for our platforms. 
Are you saying that we should break what the current DT binding already 
represents to mean something else?

Regards,
Dave

>
> Rob
>

[toc] | [prev] | [next] | [standalone]

#1558700 — Re: [PATCH v3 2/4] dt-bindings: Add TI SCI PM Domains

On Thu, Jan 12, 2017 at 9:27 AM, Dave Gerlach <d-gerlach@ti.com> wrote:
> Rob,
>
> On 01/11/2017 03:34 PM, Rob Herring wrote:
>>
>> On Mon, Jan 9, 2017 at 11:57 AM, Dave Gerlach <d-gerlach@ti.com> wrote:
>>>
>>> Rob,
>>>
>>> On 01/09/2017 11:50 AM, Rob Herring wrote:
>>>>
>>>>
>>>> On Wed, Jan 04, 2017 at 02:55:34PM -0600, Dave Gerlach wrote:
>>>>>
>>>>>
>>>>> Add a generic power domain implementation, TI SCI PM Domains, that
>>>>> will hook into the genpd framework and allow the TI SCI protocol to
>>>>> control device power states.
>>>>>
>>>>> Also, provide macros representing each device index as understood
>>>>> by TI SCI to be used in the device node power-domain references.
>>>>> These are identifiers for the K2G devices managed by the PMMC.
>>>>>
>>>>> Signed-off-by: Nishanth Menon <nm@ti.com>
>>>>> Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
>>>>> ---
>>>>> v2->v3:
>>>>>         Update k2g_pds node docs to show it should be a child of pmmc
>>>>> node.
>>>>>         In early versions a phandle was used to point to pmmc and docs
>>>>> still
>>>>>         incorrectly showed this.
>>>>>
>>>>>  .../devicetree/bindings/soc/ti/sci-pm-domain.txt   | 59 ++++++++++++++
>>>>>  MAINTAINERS                                        |  2 +
>>>>>  include/dt-bindings/genpd/k2g.h                    | 90
>>>>> ++++++++++++++++++++++
>>>>>  3 files changed, 151 insertions(+)
>>>>>  create mode 100644
>>>>> Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>>>>>  create mode 100644 include/dt-bindings/genpd/k2g.h
>>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>>>>> b/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>>>>> new file mode 100644
>>>>> index 000000000000..4c9064e512cb
>>>>> --- /dev/null
>>>>> +++ b/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>>>>> @@ -0,0 +1,59 @@
>>>>> +Texas Instruments TI-SCI Generic Power Domain
>>>>> +---------------------------------------------
>>>>> +
>>>>> +Some TI SoCs contain a system controller (like the PMMC, etc...) that
>>>>> is
>>>>> +responsible for controlling the state of the IPs that are present.
>>>>> +Communication between the host processor running an OS and the system
>>>>> +controller happens through a protocol known as TI-SCI [1]. This pm
>>>>> domain
>>>>> +implementation plugs into the generic pm domain framework and makes
>>>>> use
>>>>> of
>>>>> +the TI SCI protocol power on and off each device when needed.
>>>>> +
>>>>> +[1] Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
>>>>> +
>>>>> +PM Domain Node
>>>>> +==============
>>>>> +The PM domain node represents the global PM domain managed by the
>>>>> PMMC,
>>>>> +which in this case is the single implementation as documented by the
>>>>> generic
>>>>> +PM domain bindings in
>>>>> Documentation/devicetree/bindings/power/power_domain.txt.
>>>>> +Because this relies on the TI SCI protocol to communicate with the
>>>>> PMMC
>>>>> it
>>>>> +must be a child of the pmmc node.
>>>>> +
>>>>> +Required Properties:
>>>>> +--------------------
>>>>> +- compatible: should be "ti,sci-pm-domain"
>>>>> +- #power-domain-cells: Must be 0.
>>>>> +
>>>>> +Example (K2G):
>>>>> +-------------
>>>>> +       pmmc: pmmc {
>>>>> +               compatible = "ti,k2g-sci";
>>>>> +               ...
>>>>> +
>>>>> +               k2g_pds: k2g_pds {
>>>>> +                       compatible = "ti,sci-pm-domain";
>>>>> +                       #power-domain-cells = <0>;
>>>>> +               };
>>>>> +       };
>>>>> +
>>>>> +PM Domain Consumers
>>>>> +===================
>>>>> +Hardware blocks that require SCI control over their state must provide
>>>>> +a reference to the sci-pm-domain they are part of and a unique device
>>>>> +specific ID that identifies the device.
>>>>> +
>>>>> +Required Properties:
>>>>> +--------------------
>>>>> +- power-domains: phandle pointing to the corresponding PM domain node.
>>>>> +- ti,sci-id: index representing the device id to be passed oevr SCI to
>>>>> +            be used for device control.
>>>>
>>>>
>>>>
>>>> As I've already stated before, this goes in power-domain cells. When you
>>>> have a single thing (i.e. node) that controls multiple things, then you
>>>> you need to specify the ID for each of them in phandle args. This is how
>>>> irqs, gpio, clocks, *everything* in DT works.
>>>
>>>
>>>
>>> You think the reasoning for doing it this way provided by both Ulf and
>>> myself on v2 [1] is not valid then?
>>>
>>> From Ulf:
>>>
>>> To me, the TI SCI ID, is similar to a "conid" for any another "device
>>> resource" (like clock, pinctrl, regulator etc) which we can describe
>>> in DT and assign to a device node. The only difference here, is that
>>> we don't have common API to fetch the resource (like clk_get(),
>>> regulator_get()), but instead we fetches the device's resource from
>>> SoC specific code, via genpd's device ->attach() callback.
>>
>>
>> Sorry, but that sounds like a kernel problem to me and has nothing to
>> do with DT bindings.
>>
>>> From me:
>>>
>>> Yes, you've pretty much hit it on the head. It is not an index into a
>>> list
>>> of genpds but rather identifies the device *within* a single genpd. It is
>>> a
>>> property specific to each device that resides in a ti-sci-genpd, not a
>>> mapping describing which genpd the device belongs to. The generic power
>>> domain binding is concerned with mapping the device to a specific genpd,
>>> which is does fine for us, but we have a sub mapping for devices that
>>> exist
>>> inside a genpd which, we must describe as well, hence the ti,sci-id.
>>>
>>>
>>> So to summarize, the genpd framework does interpret the phandle arg as an
>>> index into multiple genpds, just as you've said other frameworks do, but
>>> this is not what I am trying to do, we have multiple devices within this
>>> *single* genpd, hence the need for the ti,sci-id property.
>>
>>
>> Fix the genpd framework rather than work around it in DT.
>
>
> I still disagree that this has nothing to do with DT bindings, as the
> current DT binding represents something different already. I am trying to
> extend it to give me additional information needed for our platforms. Are
> you saying that we should break what the current DT binding already
> represents to mean something else?

No idea because what's the current binding? From the patch, looks like
a new binding to me.

Rob

[toc] | [prev] | [next] | [standalone]

#1558737 — Re: [PATCH v3 2/4] dt-bindings: Add TI SCI PM Domains

On 01/13/2017 01:25 PM, Rob Herring wrote:
> On Thu, Jan 12, 2017 at 9:27 AM, Dave Gerlach <d-gerlach@ti.com> wrote:
>> Rob,
>>
>> On 01/11/2017 03:34 PM, Rob Herring wrote:
>>>
>>> On Mon, Jan 9, 2017 at 11:57 AM, Dave Gerlach <d-gerlach@ti.com> wrote:
>>>>
>>>> Rob,
>>>>
>>>> On 01/09/2017 11:50 AM, Rob Herring wrote:
>>>>>
>>>>>
>>>>> On Wed, Jan 04, 2017 at 02:55:34PM -0600, Dave Gerlach wrote:
>>>>>>
>>>>>>
>>>>>> Add a generic power domain implementation, TI SCI PM Domains, that
>>>>>> will hook into the genpd framework and allow the TI SCI protocol to
>>>>>> control device power states.
>>>>>>
>>>>>> Also, provide macros representing each device index as understood
>>>>>> by TI SCI to be used in the device node power-domain references.
>>>>>> These are identifiers for the K2G devices managed by the PMMC.
>>>>>>
>>>>>> Signed-off-by: Nishanth Menon <nm@ti.com>
>>>>>> Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
>>>>>> ---
>>>>>> v2->v3:
>>>>>>         Update k2g_pds node docs to show it should be a child of pmmc
>>>>>> node.
>>>>>>         In early versions a phandle was used to point to pmmc and docs
>>>>>> still
>>>>>>         incorrectly showed this.
>>>>>>
>>>>>>  .../devicetree/bindings/soc/ti/sci-pm-domain.txt   | 59 ++++++++++++++
>>>>>>  MAINTAINERS                                        |  2 +
>>>>>>  include/dt-bindings/genpd/k2g.h                    | 90
>>>>>> ++++++++++++++++++++++
>>>>>>  3 files changed, 151 insertions(+)
>>>>>>  create mode 100644
>>>>>> Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>>>>>>  create mode 100644 include/dt-bindings/genpd/k2g.h
>>>>>>
>>>>>> diff --git a/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>>>>>> b/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>>>>>> new file mode 100644
>>>>>> index 000000000000..4c9064e512cb
>>>>>> --- /dev/null
>>>>>> +++ b/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>>>>>> @@ -0,0 +1,59 @@
>>>>>> +Texas Instruments TI-SCI Generic Power Domain
>>>>>> +---------------------------------------------
>>>>>> +
>>>>>> +Some TI SoCs contain a system controller (like the PMMC, etc...) that
>>>>>> is
>>>>>> +responsible for controlling the state of the IPs that are present.
>>>>>> +Communication between the host processor running an OS and the system
>>>>>> +controller happens through a protocol known as TI-SCI [1]. This pm
>>>>>> domain
>>>>>> +implementation plugs into the generic pm domain framework and makes
>>>>>> use
>>>>>> of
>>>>>> +the TI SCI protocol power on and off each device when needed.
>>>>>> +
>>>>>> +[1] Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
>>>>>> +
>>>>>> +PM Domain Node
>>>>>> +==============
>>>>>> +The PM domain node represents the global PM domain managed by the
>>>>>> PMMC,
>>>>>> +which in this case is the single implementation as documented by the
>>>>>> generic
>>>>>> +PM domain bindings in
>>>>>> Documentation/devicetree/bindings/power/power_domain.txt.
>>>>>> +Because this relies on the TI SCI protocol to communicate with the
>>>>>> PMMC
>>>>>> it
>>>>>> +must be a child of the pmmc node.
>>>>>> +
>>>>>> +Required Properties:
>>>>>> +--------------------
>>>>>> +- compatible: should be "ti,sci-pm-domain"
>>>>>> +- #power-domain-cells: Must be 0.
>>>>>> +
>>>>>> +Example (K2G):
>>>>>> +-------------
>>>>>> +       pmmc: pmmc {
>>>>>> +               compatible = "ti,k2g-sci";
>>>>>> +               ...
>>>>>> +
>>>>>> +               k2g_pds: k2g_pds {
>>>>>> +                       compatible = "ti,sci-pm-domain";
>>>>>> +                       #power-domain-cells = <0>;
>>>>>> +               };
>>>>>> +       };
>>>>>> +
>>>>>> +PM Domain Consumers
>>>>>> +===================
>>>>>> +Hardware blocks that require SCI control over their state must provide
>>>>>> +a reference to the sci-pm-domain they are part of and a unique device
>>>>>> +specific ID that identifies the device.
>>>>>> +
>>>>>> +Required Properties:
>>>>>> +--------------------
>>>>>> +- power-domains: phandle pointing to the corresponding PM domain node.
>>>>>> +- ti,sci-id: index representing the device id to be passed oevr SCI to
>>>>>> +            be used for device control.
>>>>>
>>>>>
>>>>>
>>>>> As I've already stated before, this goes in power-domain cells. When you
>>>>> have a single thing (i.e. node) that controls multiple things, then you
>>>>> you need to specify the ID for each of them in phandle args. This is how
>>>>> irqs, gpio, clocks, *everything* in DT works.
>>>>
>>>>
>>>>
>>>> You think the reasoning for doing it this way provided by both Ulf and
>>>> myself on v2 [1] is not valid then?
>>>>
>>>> From Ulf:
>>>>
>>>> To me, the TI SCI ID, is similar to a "conid" for any another "device
>>>> resource" (like clock, pinctrl, regulator etc) which we can describe
>>>> in DT and assign to a device node. The only difference here, is that
>>>> we don't have common API to fetch the resource (like clk_get(),
>>>> regulator_get()), but instead we fetches the device's resource from
>>>> SoC specific code, via genpd's device ->attach() callback.
>>>
>>>
>>> Sorry, but that sounds like a kernel problem to me and has nothing to
>>> do with DT bindings.
>>>
>>>> From me:
>>>>
>>>> Yes, you've pretty much hit it on the head. It is not an index into a
>>>> list
>>>> of genpds but rather identifies the device *within* a single genpd. It is
>>>> a
>>>> property specific to each device that resides in a ti-sci-genpd, not a
>>>> mapping describing which genpd the device belongs to. The generic power
>>>> domain binding is concerned with mapping the device to a specific genpd,
>>>> which is does fine for us, but we have a sub mapping for devices that
>>>> exist
>>>> inside a genpd which, we must describe as well, hence the ti,sci-id.
>>>>
>>>>
>>>> So to summarize, the genpd framework does interpret the phandle arg as an
>>>> index into multiple genpds, just as you've said other frameworks do, but
>>>> this is not what I am trying to do, we have multiple devices within this
>>>> *single* genpd, hence the need for the ti,sci-id property.
>>>
>>>
>>> Fix the genpd framework rather than work around it in DT.
>>
>>
>> I still disagree that this has nothing to do with DT bindings, as the
>> current DT binding represents something different already. I am trying to
>> extend it to give me additional information needed for our platforms. Are
>> you saying that we should break what the current DT binding already
>> represents to mean something else?
>
> No idea because what's the current binding? From the patch, looks like
> a new binding to me.

Yes, ti,sci-id is a new binding. I am referring to the current meaning 
of the "power-domains" binding, which is where you are asking this 
property to be added, in "power-domains" cells. This is documented here 
[1] in the kernel, although looking at it I must admit it is not very clear.

The power-domains cell represents an offset into an array of power 
domains, if you choose to use it. That's what the genpd framework is 
hard coded to interpret it as. This is correct, as it is an index into a 
static list of power domains, used to identify which power domain a 
device belongs to, which is exactly what the genpd framework itself is 
concerned with. This is already how it is used in the kernel today.

My ti,sci-id is not an index into a list of power domains, so it should 
not go in the power-domains cells and go against what the power-domains 
binding says that the cell expects. We have one single power domain, and 
the new ti,sci-id binding is not something the genpd framework itself is 
concerned with as it's our property to identify a device inside a power 
domain, not to identify which power domain it is associated with.

Regards,
Dave

[1] Documentation/devicetree/bindings/power/power_domain.txt

>
> Rob
>

[toc] | [prev] | [next] | [standalone]

#1558827 — Re: [PATCH v3 2/4] dt-bindings: Add TI SCI PM Domains

On Fri, Jan 13, 2017 at 2:28 PM, Dave Gerlach <d-gerlach@ti.com> wrote:
> On 01/13/2017 01:25 PM, Rob Herring wrote:
>>
>> On Thu, Jan 12, 2017 at 9:27 AM, Dave Gerlach <d-gerlach@ti.com> wrote:
>>>
>>> Rob,
>>>
>>> On 01/11/2017 03:34 PM, Rob Herring wrote:
>>>>
>>>>
>>>> On Mon, Jan 9, 2017 at 11:57 AM, Dave Gerlach <d-gerlach@ti.com> wrote:
>>>>>
>>>>>
>>>>> Rob,
>>>>>
>>>>> On 01/09/2017 11:50 AM, Rob Herring wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, Jan 04, 2017 at 02:55:34PM -0600, Dave Gerlach wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Add a generic power domain implementation, TI SCI PM Domains, that
>>>>>>> will hook into the genpd framework and allow the TI SCI protocol to
>>>>>>> control device power states.
>>>>>>>
>>>>>>> Also, provide macros representing each device index as understood
>>>>>>> by TI SCI to be used in the device node power-domain references.
>>>>>>> These are identifiers for the K2G devices managed by the PMMC.
>>>>>>>
>>>>>>> Signed-off-by: Nishanth Menon <nm@ti.com>
>>>>>>> Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
>>>>>>> ---
>>>>>>> v2->v3:
>>>>>>>         Update k2g_pds node docs to show it should be a child of pmmc
>>>>>>> node.
>>>>>>>         In early versions a phandle was used to point to pmmc and
>>>>>>> docs
>>>>>>> still
>>>>>>>         incorrectly showed this.
>>>>>>>
>>>>>>>  .../devicetree/bindings/soc/ti/sci-pm-domain.txt   | 59
>>>>>>> ++++++++++++++
>>>>>>>  MAINTAINERS                                        |  2 +
>>>>>>>  include/dt-bindings/genpd/k2g.h                    | 90
>>>>>>> ++++++++++++++++++++++
>>>>>>>  3 files changed, 151 insertions(+)
>>>>>>>  create mode 100644
>>>>>>> Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>>>>>>>  create mode 100644 include/dt-bindings/genpd/k2g.h
>>>>>>>
>>>>>>> diff --git
>>>>>>> a/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>>>>>>> b/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>>>>>>> new file mode 100644
>>>>>>> index 000000000000..4c9064e512cb
>>>>>>> --- /dev/null
>>>>>>> +++ b/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>>>>>>> @@ -0,0 +1,59 @@
>>>>>>> +Texas Instruments TI-SCI Generic Power Domain
>>>>>>> +---------------------------------------------
>>>>>>> +
>>>>>>> +Some TI SoCs contain a system controller (like the PMMC, etc...)
>>>>>>> that
>>>>>>> is
>>>>>>> +responsible for controlling the state of the IPs that are present.
>>>>>>> +Communication between the host processor running an OS and the
>>>>>>> system
>>>>>>> +controller happens through a protocol known as TI-SCI [1]. This pm
>>>>>>> domain
>>>>>>> +implementation plugs into the generic pm domain framework and makes
>>>>>>> use
>>>>>>> of
>>>>>>> +the TI SCI protocol power on and off each device when needed.
>>>>>>> +
>>>>>>> +[1] Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
>>>>>>> +
>>>>>>> +PM Domain Node
>>>>>>> +==============
>>>>>>> +The PM domain node represents the global PM domain managed by the
>>>>>>> PMMC,
>>>>>>> +which in this case is the single implementation as documented by the
>>>>>>> generic
>>>>>>> +PM domain bindings in
>>>>>>> Documentation/devicetree/bindings/power/power_domain.txt.
>>>>>>> +Because this relies on the TI SCI protocol to communicate with the
>>>>>>> PMMC
>>>>>>> it
>>>>>>> +must be a child of the pmmc node.
>>>>>>> +
>>>>>>> +Required Properties:
>>>>>>> +--------------------
>>>>>>> +- compatible: should be "ti,sci-pm-domain"
>>>>>>> +- #power-domain-cells: Must be 0.
>>>>>>> +
>>>>>>> +Example (K2G):
>>>>>>> +-------------
>>>>>>> +       pmmc: pmmc {
>>>>>>> +               compatible = "ti,k2g-sci";
>>>>>>> +               ...
>>>>>>> +
>>>>>>> +               k2g_pds: k2g_pds {
>>>>>>> +                       compatible = "ti,sci-pm-domain";
>>>>>>> +                       #power-domain-cells = <0>;
>>>>>>> +               };
>>>>>>> +       };
>>>>>>> +
>>>>>>> +PM Domain Consumers
>>>>>>> +===================
>>>>>>> +Hardware blocks that require SCI control over their state must
>>>>>>> provide
>>>>>>> +a reference to the sci-pm-domain they are part of and a unique
>>>>>>> device
>>>>>>> +specific ID that identifies the device.
>>>>>>> +
>>>>>>> +Required Properties:
>>>>>>> +--------------------
>>>>>>> +- power-domains: phandle pointing to the corresponding PM domain
>>>>>>> node.
>>>>>>> +- ti,sci-id: index representing the device id to be passed oevr SCI
>>>>>>> to
>>>>>>> +            be used for device control.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> As I've already stated before, this goes in power-domain cells. When
>>>>>> you
>>>>>> have a single thing (i.e. node) that controls multiple things, then
>>>>>> you
>>>>>> you need to specify the ID for each of them in phandle args. This is
>>>>>> how
>>>>>> irqs, gpio, clocks, *everything* in DT works.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> You think the reasoning for doing it this way provided by both Ulf and
>>>>> myself on v2 [1] is not valid then?
>>>>>
>>>>> From Ulf:
>>>>>
>>>>> To me, the TI SCI ID, is similar to a "conid" for any another "device
>>>>> resource" (like clock, pinctrl, regulator etc) which we can describe
>>>>> in DT and assign to a device node. The only difference here, is that
>>>>> we don't have common API to fetch the resource (like clk_get(),
>>>>> regulator_get()), but instead we fetches the device's resource from
>>>>> SoC specific code, via genpd's device ->attach() callback.
>>>>
>>>>
>>>>
>>>> Sorry, but that sounds like a kernel problem to me and has nothing to
>>>> do with DT bindings.
>>>>
>>>>> From me:
>>>>>
>>>>> Yes, you've pretty much hit it on the head. It is not an index into a
>>>>> list
>>>>> of genpds but rather identifies the device *within* a single genpd. It
>>>>> is
>>>>> a
>>>>> property specific to each device that resides in a ti-sci-genpd, not a
>>>>> mapping describing which genpd the device belongs to. The generic power
>>>>> domain binding is concerned with mapping the device to a specific
>>>>> genpd,
>>>>> which is does fine for us, but we have a sub mapping for devices that
>>>>> exist
>>>>> inside a genpd which, we must describe as well, hence the ti,sci-id.
>>>>>
>>>>>
>>>>> So to summarize, the genpd framework does interpret the phandle arg as
>>>>> an
>>>>> index into multiple genpds, just as you've said other frameworks do,
>>>>> but
>>>>> this is not what I am trying to do, we have multiple devices within
>>>>> this
>>>>> *single* genpd, hence the need for the ti,sci-id property.
>>>>
>>>>
>>>>
>>>> Fix the genpd framework rather than work around it in DT.
>>>
>>>
>>>
>>> I still disagree that this has nothing to do with DT bindings, as the
>>> current DT binding represents something different already. I am trying to
>>> extend it to give me additional information needed for our platforms. Are
>>> you saying that we should break what the current DT binding already
>>> represents to mean something else?
>>
>>
>> No idea because what's the current binding? From the patch, looks like
>> a new binding to me.
>
>
> Yes, ti,sci-id is a new binding. I am referring to the current meaning of
> the "power-domains" binding, which is where you are asking this property to
> be added, in "power-domains" cells. This is documented here [1] in the
> kernel, although looking at it I must admit it is not very clear.
>
> The power-domains cell represents an offset into an array of power domains,
> if you choose to use it. That's what the genpd framework is hard coded to
> interpret it as. This is correct, as it is an index into a static list of
> power domains, used to identify which power domain a device belongs to,
> which is exactly what the genpd framework itself is concerned with. This is
> already how it is used in the kernel today.

Strictly speaking, the cells are purely for the interpretation of the
phandle they are associated with. If some controller wants to have 20
cells, then it could assuming a good reason. The reality is we tend to
align the meaning of the cells. If genpd is interpreting the cells and
not letting the driver for the power domain controller interpret them,
then still, genpd needs to be fixed.

IIRC, initially it was said genpd required 0 cells, hence my confusion.

> My ti,sci-id is not an index into a list of power domains, so it should not
> go in the power-domains cells and go against what the power-domains binding
> says that the cell expects. We have one single power domain, and the new
> ti,sci-id binding is not something the genpd framework itself is concerned
> with as it's our property to identify a device inside a power domain, not to
> identify which power domain it is associated with.

What is the id used for? I can understand why you need to know what
power domain a device is in (as power-domains identifies), but not
what devices are in a power domain.

Rob

[toc] | [prev] | [next] | [standalone]

#1551437 — Re: [PATCH v3 0/4] ARM: K2G: Add support for TI-SCI Generic PM Domains

Santosh,
On 01/04/2017 03:54 PM, Santosh Shilimkar wrote:
> On 1/4/2017 12:55 PM, Dave Gerlach wrote:
>> Hi,
>> This is v3 of the series to add support for TI-SCI Generic PM Domains.
>> Previous versions can be found here:
>>
>> v2: https://www.spinics.net/lists/kernel/msg2364612.html
>> v1: http://www.spinics.net/lists/arm-kernel/msg525204.html
>>
>> This version is rebased on v4.10-rc2 but is the same as v2 with the
>> exception of patch 2 in which the devicetree binding documentation
>> needed to be updated to show the k2g_pds node should be a child of
>> the pmmc node. Apart from that, the acks provided by Ulf were added
>> to patches 1 and 3.
>>
>> Now that the TI-SCI series has been merged [1] this series will be ready
>> to go in with an ack on the DT binding. Rob had raised some questions on
>> the necessity ti,sci-id property but I believe these were properly
>> addressed during the discussion of v2 so hopefully an ack is in order
>> now.
>>
> How do you plan to merge this series with below patch ?
>
>>   PM / Domains: Add generic data pointer to genpd data struct
> I think this one goes via Rafael's tree. If you want me to merge this
> along with other patches then will need his ack.
>
> Other way is to get that merged first via Rafael's tree and then
> the remainder series.

I'd be happy with it going in through your tree with an ack to avoid any 
delay but I'd say it's Rafael's call as it is a patch to the genpd core, 
even though at this point I am the only user.

Regards,
Dave

>
> Regards,
> Santosh

[toc] | [prev] | [next] | [standalone]

#1551455 — Re: [PATCH v3 0/4] ARM: K2G: Add support for TI-SCI Generic PM Domains

On 1/4/2017 12:55 PM, Dave Gerlach wrote:
> Hi,
> This is v3 of the series to add support for TI-SCI Generic PM Domains.
> Previous versions can be found here:
>
> v2: https://www.spinics.net/lists/kernel/msg2364612.html
> v1: http://www.spinics.net/lists/arm-kernel/msg525204.html
>
> This version is rebased on v4.10-rc2 but is the same as v2 with the
> exception of patch 2 in which the devicetree binding documentation
> needed to be updated to show the k2g_pds node should be a child of
> the pmmc node. Apart from that, the acks provided by Ulf were added
> to patches 1 and 3.
>
> Now that the TI-SCI series has been merged [1] this series will be ready
> to go in with an ack on the DT binding. Rob had raised some questions on
> the necessity ti,sci-id property but I believe these were properly
> addressed during the discussion of v2 so hopefully an ack is in order now.
>
How do you plan to merge this series with below patch ?

>   PM / Domains: Add generic data pointer to genpd data struct
I think this one goes via Rafael's tree. If you want me to merge this
along with other patches then will need his ack.

Other way is to get that merged first via Rafael's tree and then
the remainder series.

Regards,
Santosh

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web