| Message ID | 1472207073-4901-1-git-send-email-ulf.hansson@linaro.org |
|---|---|
| State | Changes Requested, archived |
| Headers | show |
Hi! > @@ -0,0 +1,102 @@ > +Device idle states > +======================== > + > +A device are often capable of entering a low power state(s) when it becomes > +idle, hence the terminology of device idle states. Entering an idle state for a > +device helps it to avoid wasting power and reduces the leakage of current. First things first: what do these states _really_ represent? We have GPIOs in device tree, we have clock domains. What are these? Actually I don't think I like this. We should describe the hardware, not particular use case. On what hardware would you use these new bindings? > +Required properties: > +- compatible: Must contain "simple-dev, idle-state". > +- entry-latency-ns: An u32 value in nano-seconds representing the worst case > + latency required for the device to enter the idle state. > +- exit-latency-ns: An u32 value in nano-seconds representing the worst case > + wakeup latency of the device, after entry-latency-ns has > + passed. u32 nanoseconds have 4sec limit, right? So anything with spinning harddrive is out? > +== Assigning idle states to devices == > + > +Required properties: > + - dev-idle-states: A list of phandles pointing to the supported > + device idle states nodes. The list must be ordered as > + the shallower state - the earlier in the list. Does such ordering really neccessarily exist?
On Fri, Aug 26, 2016 at 12:24 PM, Ulf Hansson <ulf.hansson@linaro.org> wrote: > --- /dev/null > +++ b/Documentation/devicetree/bindings/power/device-idle-states.txt > @@ -0,0 +1,102 @@ > +Required properties: > +- compatible: Must contain "simple-dev, idle-state". Bogus space after the comma. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 26 August 2016 at 15:58, Pavel Machek <pavel@ucw.cz> wrote: > Hi! > >> @@ -0,0 +1,102 @@ >> +Device idle states >> +======================== >> + >> +A device are often capable of entering a low power state(s) when it becomes >> +idle, hence the terminology of device idle states. Entering an idle state for a >> +device helps it to avoid wasting power and reduces the leakage of current. > > First things first: what do these states _really_ represent? We have > GPIOs in device tree, we have clock domains. What are these? On most ARM SoCs which I am familiar of and which isn't using ACPI, these kind of resources may can be considered as "power resources" connected to a generic device. Although it's of course highly dependent on the SoC. Other typical resources are clocks, pinctrls, regulators etc. To enter a low power state, these devices may not explicitly have to change some internal logic, but instead relies on external "power resources " to be put into low power mode. I guess one could compare this to what can be described in the ACPI's Device Power Management. > > Actually I don't think I like this. We should describe the hardware, > not particular use case. I am not describing use cases, but I am trying invent a generic binding that describes a generic device's idle states. At least to me, this is characteristics of the HW. Rob requested a flexible future proof binding, but perhaps you think this became too generic/flexible? > > On what hardware would you use these new bindings? Lot's of ARM SoCs, especially those that don't use ACPI. > >> +Required properties: >> +- compatible: Must contain "simple-dev, idle-state". >> +- entry-latency-ns: An u32 value in nano-seconds representing the worst case >> + latency required for the device to enter the idle state. >> +- exit-latency-ns: An u32 value in nano-seconds representing the worst case >> + wakeup latency of the device, after entry-latency-ns has >> + passed. > > u32 nanoseconds have 4sec limit, right? So anything with spinning > harddrive is out? In most cases 4 sec is probably good enough. We could increase it to u64 or we could have another compatible string for those idle states types that requires this. > >> +== Assigning idle states to devices == >> + >> +Required properties: >> + - dev-idle-states: A list of phandles pointing to the supported >> + device idle states nodes. The list must be ordered as >> + the shallower state - the earlier in the list. > > Does such ordering really neccessarily exist? On several devices that I am aware of yes. Although, again this SoC/device specific. If this becomes a problem for some devices, we can assign them another compatible string used deal with those idle state types. Kind regards Uffe -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon 2016-08-29 11:34:34, Ulf Hansson wrote: > On 26 August 2016 at 15:58, Pavel Machek <pavel@ucw.cz> wrote: > > Hi! > > > >> @@ -0,0 +1,102 @@ > >> +Device idle states > >> +======================== > >> + > >> +A device are often capable of entering a low power state(s) when it becomes > >> +idle, hence the terminology of device idle states. Entering an idle state for a > >> +device helps it to avoid wasting power and reduces the leakage of current. > > > > First things first: what do these states _really_ represent? We have > > GPIOs in device tree, we have clock domains. What are these? > > On most ARM SoCs which I am familiar of and which isn't using ACPI, > these kind of resources may can be considered as "power resources" > connected to a generic device. Although it's of course highly > dependent on the SoC. Other typical resources are clocks, pinctrls, > regulators etc. > > To enter a low power state, these devices may not explicitly have to > change some internal logic, but instead relies on external "power > resources " to be put into low power mode. > > I guess one could compare this to what can be described in the ACPI's > Device Power Management. If they are clocks, describe them as clocks, DT supports that. If they are regulators, describe them as regulators. We don't want to have "we have these magic somethings here". We want to know whether it is clock, regulator, or what. > > Actually I don't think I like this. We should describe the hardware, > > not particular use case. > > I am not describing use cases, but I am trying invent a generic > binding that describes a generic device's idle states. At least to me, > this is characteristics of the HW. > > Rob requested a flexible future proof binding, but perhaps you think > this became too generic/flexible? I believe this is no longer describing hardware. Best regards, Pavel
On 29 August 2016 at 12:40, Pavel Machek <pavel@ucw.cz> wrote: > On Mon 2016-08-29 11:34:34, Ulf Hansson wrote: >> On 26 August 2016 at 15:58, Pavel Machek <pavel@ucw.cz> wrote: >> > Hi! >> > >> >> @@ -0,0 +1,102 @@ >> >> +Device idle states >> >> +======================== >> >> + >> >> +A device are often capable of entering a low power state(s) when it becomes >> >> +idle, hence the terminology of device idle states. Entering an idle state for a >> >> +device helps it to avoid wasting power and reduces the leakage of current. >> > >> > First things first: what do these states _really_ represent? We have >> > GPIOs in device tree, we have clock domains. What are these? >> >> On most ARM SoCs which I am familiar of and which isn't using ACPI, >> these kind of resources may can be considered as "power resources" >> connected to a generic device. Although it's of course highly >> dependent on the SoC. Other typical resources are clocks, pinctrls, >> regulators etc. >> >> To enter a low power state, these devices may not explicitly have to >> change some internal logic, but instead relies on external "power >> resources " to be put into low power mode. >> >> I guess one could compare this to what can be described in the ACPI's >> Device Power Management. > > If they are clocks, describe them as clocks, DT supports that. If they > are regulators, describe them as regulators. > > We don't want to have "we have these magic somethings here". We want > to know whether it is clock, regulator, or what. This isn't something that will *replace* clocks etc. If those resources are needed, of course those needs to be described. What is missing in DT, and what I suggest to add, is to be able to describe the actual idle states of a device and the HW characteristics related to that. In this RFC, I picked the most common properties that I could think of, which ought to be latencies for enter and wakeup from a low power state. And... we also have devices that have internal logics that must be changed to enter and wakeup from a low power state. For example WLAN circuits, PCI devices, etc. So this isn't all about clocks/regulators etc, but devices in general. [...] Kind regards Uffe -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon 2016-08-29 13:55:56, Ulf Hansson wrote: > On 29 August 2016 at 12:40, Pavel Machek <pavel@ucw.cz> wrote: > > On Mon 2016-08-29 11:34:34, Ulf Hansson wrote: > >> On 26 August 2016 at 15:58, Pavel Machek <pavel@ucw.cz> wrote: > >> > Hi! > >> > > >> >> @@ -0,0 +1,102 @@ > >> >> +Device idle states > >> >> +======================== > >> >> + > >> >> +A device are often capable of entering a low power state(s) when it becomes > >> >> +idle, hence the terminology of device idle states. Entering an idle state for a > >> >> +device helps it to avoid wasting power and reduces the leakage of current. > >> > > >> > First things first: what do these states _really_ represent? We have > >> > GPIOs in device tree, we have clock domains. What are these? > >> > >> On most ARM SoCs which I am familiar of and which isn't using ACPI, > >> these kind of resources may can be considered as "power resources" > >> connected to a generic device. Although it's of course highly > >> dependent on the SoC. Other typical resources are clocks, pinctrls, > >> regulators etc. > >> > >> To enter a low power state, these devices may not explicitly have to > >> change some internal logic, but instead relies on external "power > >> resources " to be put into low power mode. > >> > >> I guess one could compare this to what can be described in the ACPI's > >> Device Power Management. > > > > If they are clocks, describe them as clocks, DT supports that. If they > > are regulators, describe them as regulators. > > > > We don't want to have "we have these magic somethings here". We want > > to know whether it is clock, regulator, or what. > > This isn't something that will *replace* clocks etc. If those > resources are needed, of course those needs to be described. > > What is missing in DT, and what I suggest to add, is to be able to > describe the actual idle states of a device and the HW characteristics > related to that. What is "actual idle state"? That's what i'm asking. You told me it is clocks, now you are telling me it is not. > And... we also have devices that have internal logics that must be > changed to enter and wakeup from a low power state. For example WLAN > circuits, PCI devices, etc. So this isn't all about clocks/regulators > etc, but devices in general. Again. What is this describing? If you have device that has internal logic, the driver needs to know how to drive the device, and this binding is not needed. We are not describing "this x86 cpu has eax register inside it, and it takes 12 nanoseconds to read it". Real world example would help here. Pavel
On Fri, Aug 26, 2016 at 12:24:33PM +0200, Ulf Hansson wrote: > A device may be capable of entering a low power state when it becomes > idle, which should avoid the device from wasting power. > > Unfortunate entering a such low power state for a device may often also > come with a cost. This because when a new request is about to be served, > the device must first to be woken up from its low power state. As that may > take a while, the request may suffer from an initial latency. > > These so called device idle states are characteristics of the hardware, so > let's define some DT bindings to enable us to describe them. > > Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> > --- > > Similar DT bindings has been suggested earlier [1], although Rob raised > primarily two conserns in that approach. > > *) The bindings was probably not future proof, some more flexibility was needed. > > **) As the bindings also relates to idles states for PM domains, it seemed > reasonable to discuss them at the same time. As there is an ongoing discussion > for that right now [2], I took the opportunity to bring up the discussion for > device idles states again. > Hi Ulf, There was some previous discussion of whether device idle state bindings are necessary. It was proposed that rather than adding a whole new binding, we could just use the power domain idle state binding from [2]. We suggested that any device that has an idle state is, by definition, in a power domain of its own: rather than add a device-idle-states property to that device, we just put it in a power domain with a domain-idle-states property. When I say "by definition", I of course mean "by the definition of 'power domain' that's most convenient to my argument", but I think that definition is also the one that's most useful for solving our problem. Sudeep posted some examples in [3] (in the thread for [2]). Before we discuss device idle state bindings, could we finish discussing that idea so that everyone agrees on whether they're actually needed? It might be worth having that discussion in replies to [3] so that we can use Sudeep's examples. The 5th example in his mail is the most interesting. > [1] > http://www.spinics.net/lists/devicetree/msg120515.html > > [2] > http://www.spinics.net/lists/arm-kernel/msg522023.html [3] http://www.spinics.net/lists/arm-kernel/msg526162.html ^ Message-ID: <9b2ed5d3-c071-8828-5a22-1ab6f3753d74@arm.com> Cheers, Brendan -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 31 August 2016 at 12:16, Brendan Jackman <brendan.jackman@arm.com> wrote: > On Fri, Aug 26, 2016 at 12:24:33PM +0200, Ulf Hansson wrote: >> A device may be capable of entering a low power state when it becomes >> idle, which should avoid the device from wasting power. >> >> Unfortunate entering a such low power state for a device may often also >> come with a cost. This because when a new request is about to be served, >> the device must first to be woken up from its low power state. As that may >> take a while, the request may suffer from an initial latency. >> >> These so called device idle states are characteristics of the hardware, so >> let's define some DT bindings to enable us to describe them. >> >> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> >> --- >> >> Similar DT bindings has been suggested earlier [1], although Rob raised >> primarily two conserns in that approach. >> >> *) The bindings was probably not future proof, some more flexibility was needed. >> >> **) As the bindings also relates to idles states for PM domains, it seemed >> reasonable to discuss them at the same time. As there is an ongoing discussion >> for that right now [2], I took the opportunity to bring up the discussion for >> device idles states again. >> > > Hi Ulf, > > There was some previous discussion of whether device idle state bindings are > necessary. It was proposed that rather than adding a whole new binding, we could > just use the power domain idle state binding from [2]. We suggested that any > device that has an idle state is, by definition, in a power domain of its own: > rather than add a device-idle-states property to that device, we just put it in > a power domain with a domain-idle-states property. Yes, we can do that software wise, but is that really a proper description of the HW!? > > When I say "by definition", I of course mean "by the definition of 'power > domain' that's most convenient to my argument", but I think that definition is > also the one that's most useful for solving our problem. > > Sudeep posted some examples in [3] (in the thread for [2]). > > Before we discuss device idle state bindings, could we finish discussing that > idea so that everyone agrees on whether they're actually needed? It might be > worth having that discussion in replies to [3] so that we can use Sudeep's > examples. The 5th example in his mail is the most interesting. Sure, I will get back to that thread. Although as Rob told me earlier, he wanted to discuss the dev PM QoS (device idle states) DT bindings together with the PM domain idle states DT bindings. So, that's why I brought this up at this point. Perhaps we can get some input from Rob on how he thinks we should proceed!? > >> [1] >> http://www.spinics.net/lists/devicetree/msg120515.html >> >> [2] >> http://www.spinics.net/lists/arm-kernel/msg522023.html > > [3] > http://www.spinics.net/lists/arm-kernel/msg526162.html > ^ Message-ID: <9b2ed5d3-c071-8828-5a22-1ab6f3753d74@arm.com> > > Cheers, > Brendan Kind regards Uffe -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi, (I know I suggested switching to the other thread but I just want to explain my reasoning here!) On Wed, Aug 31, 2016 at 04:19:41PM +0200, Ulf Hansson wrote: > On 31 August 2016 at 12:16, Brendan Jackman <brendan.jackman@arm.com> wrote: [...] > > There was some previous discussion of whether device idle state bindings are > > necessary. It was proposed that rather than adding a whole new binding, we could > > just use the power domain idle state binding from [2]. We suggested that any > > device that has an idle state is, by definition, in a power domain of its own: > > rather than add a device-idle-states property to that device, we just put it in > > a power domain with a domain-idle-states property. > > Yes, we can do that software wise, but is that really a proper > description of the HW!? > It's probably not what SoC docs would explicitly list under "power domains" but I think "set of components that are bound by a common power state" is a reasonable definition for a power domain. I think (?) your objection is that a device could have idle states that it controls by itself and does not switch "off", for example in the case of a device that has an idle state where it gates its clock but does not cut voltage, or WFI in an ARM CPU. My thinking is: just because the transitions into those power states isn't triggered by a separate power controller, I don't think that means no "power domain" exists. Perhaps that's a glitch in my vocabulary. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/Documentation/devicetree/bindings/power/device-idle-states.txt b/Documentation/devicetree/bindings/power/device-idle-states.txt new file mode 100644 index 0000000..222fafb --- /dev/null +++ b/Documentation/devicetree/bindings/power/device-idle-states.txt @@ -0,0 +1,102 @@ +Device idle states +======================== + +A device are often capable of entering a low power state(s) when it becomes +idle, hence the terminology of device idle states. Entering an idle state for a +device helps it to avoid wasting power and reduces the leakage of current. + +However, entering an idle state for a device may unfortunate often also come +with a cost, as it could introduce a wakeup latency when a new request needs to +be served using the device. + +Devices may support more than one idle state, where each state could have its +own specific characteristic on how it impacts power saving, wakeup latency etc. + +These DT bindings can be used to describe these device idle states, but also to +assign the supported idle states to devices. + + +== Device idle states container node == + +The device idle states are defined within a device-idle-states node, which +provides a container where the device idle states must be listed as device tree +nodes. + + +== Device idle states nodes == + +To be able to distinguish between different types of device idle states, a +compatible string is assigned to each type. Currently one type is described, +but this can be extended to more types if needed. + +Each device idle state node represents a device idle state description and must +be defined as a child of the device idle states container node. + + +== The simple device idle state type == + +For most of the simple devices this type of device idle state, is sufficient to +be able to describe the device's idle states. The supported properties can be +extended if needed, although a more complex idle state is probably better +described by using another type/compatible. + +Required properties: +- compatible: Must contain "simple-dev, idle-state". +- entry-latency-ns: An u32 value in nano-seconds representing the worst case + latency required for the device to enter the idle state. +- exit-latency-ns: An u32 value in nano-seconds representing the worst case + wakeup latency of the device, after entry-latency-ns has + passed. + +Optional properties: +- idle-state-name: A string used as a descriptive name for the idle state. + + +== Assigning idle states to devices == + +Required properties: + - dev-idle-states: A list of phandles pointing to the supported + device idle states nodes. The list must be ordered as + the shallower state - the earlier in the list. + + +== Examples == + + device-idle-states { + RETENTION_0: dev-retention-0 { + compatible = "simple-dev,idle-state"; + entry-latency-ns = <300>; + exit-latency-ns = <1000>; + }; + + SLEEP_0: dev-sleep-0 { + compatible = "simple-dev,idle-state"; + entry-latency-us = <3000>; + exit-latency-us = <10000>; + }; + + SLEEP_1: dev-sleep-1 { + compatible = "simple-dev,idle-state"; + entry-latency-us = <50000>; + exit-latency-us = <100000>; + }; + }; + + leaky-device@12340000 { + compatible = "foo,i-leak-current"; + reg = <0x12340000 0x1000>; + dev-idle-states = <&SLEEP_0>; + }; + + leaky-device@23450000 { + compatible = "foo,i-leak-current"; + reg = <0x23450000 0x1000>; + dev-idle-states = <&RETENTION_0>, <&SLEEP_0>; + }; + + leaky-device@34560000 { + compatible = "foo,i-leak-current"; + reg = <0x34560000 0x1000>; + dev-idle-states = <&SLEEP_1>; + }; +
A device may be capable of entering a low power state when it becomes idle, which should avoid the device from wasting power. Unfortunate entering a such low power state for a device may often also come with a cost. This because when a new request is about to be served, the device must first to be woken up from its low power state. As that may take a while, the request may suffer from an initial latency. These so called device idle states are characteristics of the hardware, so let's define some DT bindings to enable us to describe them. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> --- Similar DT bindings has been suggested earlier [1], although Rob raised primarily two conserns in that approach. *) The bindings was probably not future proof, some more flexibility was needed. **) As the bindings also relates to idles states for PM domains, it seemed reasonable to discuss them at the same time. As there is an ongoing discussion for that right now [2], I took the opportunity to bring up the discussion for device idles states again. [1] http://www.spinics.net/lists/devicetree/msg120515.html [2] http://www.spinics.net/lists/arm-kernel/msg522023.html --- .../bindings/power/device-idle-states.txt | 102 +++++++++++++++++++++ 1 file changed, 102 insertions(+) create mode 100644 Documentation/devicetree/bindings/power/device-idle-states.txt