Dave Gerlach <d-gerlach@xxxxxx> writes: > Hi, > On 10/21/2016 01:48 PM, Kevin Hilman wrote: >> Dave Gerlach <d-gerlach@xxxxxx> writes: >> >>> 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@xxxxxx> >>> Signed-off-by: Dave Gerlach <d-gerlach@xxxxxx> >>> --- >>> .../devicetree/bindings/soc/ti/sci-pm-domain.txt | 54 +++++++++++++ >>> MAINTAINERS | 2 + >>> include/dt-bindings/genpd/k2g.h | 90 ++++++++++++++++++++++ >>> 3 files changed, 146 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..32f38a349656 >>> --- /dev/null >>> +++ b/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt >>> @@ -0,0 +1,54 @@ >>> +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. >>> + >>> +Required Properties: >>> +-------------------- >>> +- compatible: should be "ti,sci-pm-domain" >>> +- #power-domain-cells: Must be 0. >>> +- ti,sci: Phandle to the TI SCI device to use for managing the devices. >>> >>> +Example: >>> +-------------------- >>> +k2g_pds: k2g_pds { >> >> should use generic name like "power-contoller", e.g. k2g_pds: power-controller > > Ok, that makes more sense. > >> >>> + compatible = "ti,sci-pm-domain"; >>> + #power-domain-cells = <0>; >>> + ti,sci = <&pmmc>; >>> +}; >>> + >>> +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. >> >> This ID doesn't look right. >> >> Why not use #power-domain-cells = <1> and pass the index in the DT? ... >> >>> +See dt-bindings/genpd/k2g.h for the list of valid identifiers for k2g. >>> + >>> +Example: >>> +-------------------- >>> +uart0: serial@02530c00 { >>> + compatible = "ns16550a"; >>> + ... >>> + power-domains = <&k2g_pds>; >>> + ti,sci-id = <K2G_DEV_UART0>; >> >> ... like this: >> >> power-domains = <&k2g_pds K2G_DEV_UART0>; > > That's how I did it in version one actually. I was able to define my > own xlate function to parse the phandle and get that index, but Ulf > pointed me to this series by Jon Hunter [1] that simplified genpd > providers and dropped the concept of adding your own xlate. This locks > the onecell approach to using a fixed static array of genpds that get > indexed into (without passing the index to the provider, just the > genpd that's looked up), which doesn't fit our usecase, as we don't > want a 1 to 1 genpd to device mapping based on the comments provided > in v1. Now we just use the genpd device attach/detach hooks to parse > the sci-id and then use it in the genpd device start/stop hooks. Ah, right. I remember now. This approach allows you to use a single genpd as discussed earlier. Makes sense now, suggestion retracted. Kevin -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html