| Message ID | 20161019203347.17893-3-d-gerlach@ti.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Dave Gerlach <d-gerlach@ti.com> 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@ti.com> > Signed-off-by: Dave Gerlach <d-gerlach@ti.com> > --- > .../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 > + 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>; Kevin
Hi, On 10/21/2016 01:48 PM, Kevin Hilman wrote: > Dave Gerlach <d-gerlach@ti.com> 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@ti.com> >> Signed-off-by: Dave Gerlach <d-gerlach@ti.com> >> --- >> .../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. Regards, Dave [1] http://www.spinics.net/lists/arm-kernel/msg524151.html > > Kevin >
Dave Gerlach <d-gerlach@ti.com> writes: > Hi, > On 10/21/2016 01:48 PM, Kevin Hilman wrote: >> Dave Gerlach <d-gerlach@ti.com> 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@ti.com> >>> Signed-off-by: Dave Gerlach <d-gerlach@ti.com> >>> --- >>> .../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
On Mon, Oct 24, 2016 at 12:00 PM, Kevin Hilman <khilman@baylibre.com> wrote: > Dave Gerlach <d-gerlach@ti.com> writes: > >> Hi, >> On 10/21/2016 01:48 PM, Kevin Hilman wrote: >>> Dave Gerlach <d-gerlach@ti.com> 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@ti.com> >>>> Signed-off-by: Dave Gerlach <d-gerlach@ti.com> >>>> --- >>>> .../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? ... Exactly. ti,sci-id is a NAK for me. >>> >>>> +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. I have no idea what any of this means. All sounds like driver architecture, not anything to do with bindings. > > Ah, right. I remember now. This approach allows you to use a single > genpd as discussed earlier. > > Makes sense now, suggestion retracted. IIRC, the bindings in Jon's case had a node for each domain and didn't need any additional property. Rob
On Wed, Oct 19, 2016 at 03:33:45PM -0500, 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> > --- > .../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 { > + compatible = "ti,sci-pm-domain"; > + #power-domain-cells = <0>; > + ti,sci = <&pmmc>; > +}; Why not just make the PMMC node be the power-domain provider itself? If not that, then make this a child node of it. The same comment applies to all the SCI functions, but I guess I've already acked some of them. I really don't like reviewing all these TI SCI bindings one by one. Each one on its own seems fine, but I don't see the full picture. Rob
On 27/10/16 01:04, Rob Herring wrote: > On Wed, Oct 19, 2016 at 03:33:45PM -0500, 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> >> --- >> .../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 { >> + compatible = "ti,sci-pm-domain"; >> + #power-domain-cells = <0>; >> + ti,sci = <&pmmc>; >> +}; > > Why not just make the PMMC node be the power-domain provider itself? If > not that, then make this a child node of it. The same comment applies to > all the SCI functions, but I guess I've already acked some of them. This seems to be a bug in this documentation actually. ti,sci handle is no longer supported, and all the sci stuff must be under the parent sci node. > > I really don't like reviewing all these TI SCI bindings one by one. Each > one on its own seems fine, but I don't see the full picture. The full picture is represented under the documentation for the main protocol support itself. See this patch: https://patchwork.kernel.org/patch/9383281/ Copy pasted here as ref: Example (K2G): ------------- pmmc: pmmc { compatible = "ti,k2g-sci"; ... my_clk_node: clk_node { ... ... }; my_pd_node: pd_node { ... ... }; };
+Jon On 10/26/2016 04:59 PM, Rob Herring wrote: > On Mon, Oct 24, 2016 at 12:00 PM, Kevin Hilman <khilman@baylibre.com> wrote: >> Dave Gerlach <d-gerlach@ti.com> writes: >> >>> Hi, >>> On 10/21/2016 01:48 PM, Kevin Hilman wrote: >>>> Dave Gerlach <d-gerlach@ti.com> 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@ti.com> >>>>> Signed-off-by: Dave Gerlach <d-gerlach@ti.com> >>>>> --- >>>>> .../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? ... > > Exactly. ti,sci-id is a NAK for me. I was told not to use the onecell during v1 discussion. I agree this would be ideal but I cannot due to what the bindings represent, the phandle parameter is an index into a list of genpds, whereas we need an actual ID number we can use and I do not have the ability to get that from the phandle. @Ulf/Jon, is there any hope of bringing back custom xlate functions for genpd providers? I don't have a good background on why it was even removed. I can maintain a single genpd for all devices but I need a way to parse this ID, whether it's from a separate property or a phandle. It is locked now to indexing into a list of genpds but I need additional per device information for devices bound to a genpd and I need either a custom parameter or the ability to parse the phandle myself. > >>>> >>>>> +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. > > I have no idea what any of this means. All sounds like driver > architecture, not anything to do with bindings. This was a response to Kevin, not part of binding description. > >> >> Ah, right. I remember now. This approach allows you to use a single >> genpd as discussed earlier. >> >> Makes sense now, suggestion retracted. > > IIRC, the bindings in Jon's case had a node for each domain and didn't > need any additional property. Yes but we only have one domain and index into it, not into a list of domains, so the additional property is solving a different problem. Regards, Dave > > Rob >
On 10/27/2016 04:02 AM, Tero Kristo wrote: > On 27/10/16 01:04, Rob Herring wrote: >> On Wed, Oct 19, 2016 at 03:33:45PM -0500, 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> >>> --- >>> .../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 { >>> + compatible = "ti,sci-pm-domain"; >>> + #power-domain-cells = <0>; >>> + ti,sci = <&pmmc>; >>> +}; >> >> Why not just make the PMMC node be the power-domain provider itself? If >> not that, then make this a child node of it. The same comment applies to >> all the SCI functions, but I guess I've already acked some of them. > > This seems to be a bug in this documentation actually. ti,sci handle is no > longer supported, and all the sci stuff must be under the parent sci node. > >> >> I really don't like reviewing all these TI SCI bindings one by one. Each >> one on its own seems fine, but I don't see the full picture. > > The full picture is represented under the documentation for the main protocol > support itself. See this patch: > > https://patchwork.kernel.org/patch/9383281/ > > Copy pasted here as ref: > > Example (K2G): > ------------- > pmmc: pmmc { > compatible = "ti,k2g-sci"; > ... > > my_clk_node: clk_node { > ... > ... > }; > > my_pd_node: pd_node { > ... > ... > }; > }; > > Yes my bad I will fix this in V3 once we straighten out the ID portion of the binding. Regards, Dave
Rob, Ulf, Jon, On 10/27/2016 08:15 AM, Dave Gerlach wrote: > +Jon > On 10/26/2016 04:59 PM, Rob Herring wrote: >> On Mon, Oct 24, 2016 at 12:00 PM, Kevin Hilman <khilman@baylibre.com> wrote: >>> Dave Gerlach <d-gerlach@ti.com> writes: >>> >>>> Hi, >>>> On 10/21/2016 01:48 PM, Kevin Hilman wrote: >>>>> Dave Gerlach <d-gerlach@ti.com> 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@ti.com> >>>>>> Signed-off-by: Dave Gerlach <d-gerlach@ti.com> >>>>>> --- >>>>>> .../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? ... >> >> Exactly. ti,sci-id is a NAK for me. > > I was told not to use the onecell during v1 discussion. I agree this would be > ideal but I cannot due to what the bindings represent, the phandle parameter is > an index into a list of genpds, whereas we need an actual ID number we can use > and I do not have the ability to get that from the phandle. > > @Ulf/Jon, is there any hope of bringing back custom xlate functions for genpd > providers? I don't have a good background on why it was even removed. I can > maintain a single genpd for all devices but I need a way to parse this ID, > whether it's from a separate property or a phandle. It is locked now to indexing > into a list of genpds but I need additional per device information for devices > bound to a genpd and I need either a custom parameter or the ability to parse > the phandle myself. > Any comments here? The meaning of the phandle onecell is fixed in the genpd framework so I'm not sure how we want to move forward with this, I need to pass a power domain ID to the genpd driver, and if this shouldn't be a new property I'm not sure what direction we should take. Regards, Dave >> >>>>> >>>>>> +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. >> >> I have no idea what any of this means. All sounds like driver >> architecture, not anything to do with bindings. > > This was a response to Kevin, not part of binding description. > >> >>> >>> Ah, right. I remember now. This approach allows you to use a single >>> genpd as discussed earlier. >>> >>> Makes sense now, suggestion retracted. >> >> IIRC, the bindings in Jon's case had a node for each domain and didn't >> need any additional property. > > Yes but we only have one domain and index into it, not into a list of domains, > so the additional property is solving a different problem. > > Regards, > Dave > >> >> Rob >> >
On 10 November 2016 at 20:56, Dave Gerlach <d-gerlach@ti.com> wrote: > Rob, Ulf, Jon, > > On 10/27/2016 08:15 AM, Dave Gerlach wrote: >> >> +Jon >> On 10/26/2016 04:59 PM, Rob Herring wrote: >>> >>> On Mon, Oct 24, 2016 at 12:00 PM, Kevin Hilman <khilman@baylibre.com> >>> wrote: >>>> >>>> Dave Gerlach <d-gerlach@ti.com> writes: >>>> >>>>> Hi, >>>>> On 10/21/2016 01:48 PM, Kevin Hilman wrote: >>>>>> >>>>>> Dave Gerlach <d-gerlach@ti.com> 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@ti.com> >>>>>>> Signed-off-by: Dave Gerlach <d-gerlach@ti.com> >>>>>>> --- >>>>>>> .../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? >>>>>> ... >>> >>> >>> Exactly. ti,sci-id is a NAK for me. >> >> >> I was told not to use the onecell during v1 discussion. I agree this would >> be >> ideal but I cannot due to what the bindings represent, the phandle >> parameter is >> an index into a list of genpds, whereas we need an actual ID number we can >> use >> and I do not have the ability to get that from the phandle. >> >> @Ulf/Jon, is there any hope of bringing back custom xlate functions for >> genpd >> providers? I don't have a good background on why it was even removed. I >> can >> maintain a single genpd for all devices but I need a way to parse this ID, >> whether it's from a separate property or a phandle. It is locked now to >> indexing >> into a list of genpds but I need additional per device information for >> devices >> bound to a genpd and I need either a custom parameter or the ability to >> parse >> the phandle myself. >> > > Any comments here? The meaning of the phandle onecell is fixed in the genpd > framework so I'm not sure how we want to move forward with this, I need to > pass a power domain ID to the genpd driver, and if this shouldn't be a new > property I'm not sure what direction we should take. > > Regards, > Dave > > >>> >>>>>> >>>>>>> +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. >>> >>> >>> I have no idea what any of this means. All sounds like driver >>> architecture, not anything to do with bindings. >> >> >> This was a response to Kevin, not part of binding description. >> >>> >>>> >>>> Ah, right. I remember now. This approach allows you to use a single >>>> genpd as discussed earlier. >>>> >>>> Makes sense now, suggestion retracted. >>> >>> >>> IIRC, the bindings in Jon's case had a node for each domain and didn't >>> need any additional property. >> >> >> Yes but we only have one domain and index into it, not into a list of >> domains, Exactly. And this my main point as well. We are not talking about a domain property but a device property. >> so the additional property is solving a different problem. Yes. Perhaps you could try to elaborate about what the TI SCI ID really represents for the device, as to help Rob understand the bigger picture? 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. Hope that helps. Kind regards Uffe
Hi, On 11/11/2016 06:34 AM, Ulf Hansson wrote: > On 10 November 2016 at 20:56, Dave Gerlach <d-gerlach@ti.com> wrote: >> Rob, Ulf, Jon, >> >> On 10/27/2016 08:15 AM, Dave Gerlach wrote: >>> >>> +Jon >>> On 10/26/2016 04:59 PM, Rob Herring wrote: >>>> >>>> On Mon, Oct 24, 2016 at 12:00 PM, Kevin Hilman <khilman@baylibre.com> >>>> wrote: >>>>> >>>>> Dave Gerlach <d-gerlach@ti.com> writes: >>>>> >>>>>> Hi, >>>>>> On 10/21/2016 01:48 PM, Kevin Hilman wrote: >>>>>>> >>>>>>> Dave Gerlach <d-gerlach@ti.com> 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@ti.com> >>>>>>>> Signed-off-by: Dave Gerlach <d-gerlach@ti.com> >>>>>>>> --- >>>>>>>> .../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? >>>>>>> ... >>>> >>>> >>>> Exactly. ti,sci-id is a NAK for me. >>> >>> >>> I was told not to use the onecell during v1 discussion. I agree this would >>> be >>> ideal but I cannot due to what the bindings represent, the phandle >>> parameter is >>> an index into a list of genpds, whereas we need an actual ID number we can >>> use >>> and I do not have the ability to get that from the phandle. >>> >>> @Ulf/Jon, is there any hope of bringing back custom xlate functions for >>> genpd >>> providers? I don't have a good background on why it was even removed. I >>> can >>> maintain a single genpd for all devices but I need a way to parse this ID, >>> whether it's from a separate property or a phandle. It is locked now to >>> indexing >>> into a list of genpds but I need additional per device information for >>> devices >>> bound to a genpd and I need either a custom parameter or the ability to >>> parse >>> the phandle myself. >>> >> >> Any comments here? The meaning of the phandle onecell is fixed in the genpd >> framework so I'm not sure how we want to move forward with this, I need to >> pass a power domain ID to the genpd driver, and if this shouldn't be a new >> property I'm not sure what direction we should take. >> >> Regards, >> Dave >> >> >>>> >>>>>>> >>>>>>>> +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. >>>> >>>> >>>> I have no idea what any of this means. All sounds like driver >>>> architecture, not anything to do with bindings. >>> >>> >>> This was a response to Kevin, not part of binding description. >>> >>>> >>>>> >>>>> Ah, right. I remember now. This approach allows you to use a single >>>>> genpd as discussed earlier. >>>>> >>>>> Makes sense now, suggestion retracted. >>>> >>>> >>>> IIRC, the bindings in Jon's case had a node for each domain and didn't >>>> need any additional property. >>> >>> >>> Yes but we only have one domain and index into it, not into a list of >>> domains, > > Exactly. And this my main point as well. We are not talking about a > domain property but a device property. > >>> so the additional property is solving a different problem. > > Yes. > > Perhaps you could try to elaborate about what the TI SCI ID really > represents for the device, as to help Rob understand the bigger > picture? > > 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. Thanks for the response. 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. Regards, Dave > > Hope that helps. > > Kind regards > Uffe >
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 { + 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. + +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>; +}; diff --git a/MAINTAINERS b/MAINTAINERS index 467b29fafaca..d894873c2bff 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -11892,6 +11892,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