| Message ID | 1455310238-8963-9-git-send-email-lina.iyer@linaro.org (mailing list archive) |
|---|---|
| State | RFC |
| Delegated to: | Andy Gross |
| Headers | show |
On 02/12, Lina Iyer wrote: > diff --git a/Documentation/power/cpu_domains.txt b/Documentation/power/cpu_domains.txt > new file mode 100644 > index 0000000..5fdc66d > --- /dev/null > +++ b/Documentation/power/cpu_domains.txt > @@ -0,0 +1,79 @@ > +CPU PM domains > +============== > + > +Newer CPUs are grouped in SoCs as clusters. A cluster in addition to the CPUs > +may have caches, VFP and architecture specific power controller that share the caches, floating point units, and other architecture specific hardware that share resources when any of the CPUs are active. > +resources when any of the CPUs are active. When the CPUs are in idle, some of > +these cluster components may also idle. A cluster may also be nested inside > +another cluster that provides common coherency interfaces to share data > +between the clusters. The organization of such clusters and CPU may be > +descibed in DT, since they are SoC specific. > + > +CPUIdle framework enables the CPUs to determine the sleep time and enter low > +power state to save power during periods of idle. CPUs in a cluster may enter > +and exit idle state independently of each other. During the time when all the > +CPUs are in idle state, the cluster may safely put some of the shared > +resources in their idle state. The time between the last CPU to enter idle and > +the first CPU to wake up is the time available for the cluster to enter its > +idle state. > + > +When SoCs power down the CPU during cpuidle, they generally have supplemental > +hardware that can handshake with the CPU with a signal that indicates that the > +CPU has stopped execution. The hardware is also responsible for warm booting > +the CPU on receiving an interrupt. With cluster architecture, common resources In a cluster architecture, > +that are shared by the cluster may also be powered down by an external shared by a cluster > +microcontroller or a processor. The microcontroller may be programmed in > +advance to put the hardware blocks in a low power state, when the last active > +CPU sends the idle signal. When the signal is received, the microcontroller > +may trigger the hardware blocks to enter their low power state. When an > +interrupt to wakeup the processor is received, the microcontroller is > +responsible for bringing up the hardware blocks to its active state, before > +waking up the CPU. The timelines for such operations should be in the > +acceptable range for the for CPU idle to get power benefits. acceptable range for CPU idle to get power benefits. > + > +CPU PM Domain Setup > +------------------- > + > +PM domains are represented in the DT as domain consumers and providers. A ^ extra space here > +device may have a domain provider and a domain provider may support multiple > +domain consumers. Domains like clusters, may also be nested inside one > +another. A domain that has no active consumer, may be powered off and any > +resuming consumer would trigger the domain back to active. Parent domains may > +be powered off when the child domains are powered off. The CPU cluster can be > +fashioned as a PM domain. When the CPU devices are powered off, the PM domain > +may be powered off. > + > +Device idle is reference counted by runtime PM. When there is no active need > +for the device, runtime PM invokes callbacks to suspend the parent domain. > +Generic PM domain (genpd) handles the hierarchy of devices, domains and the > +reference counting of objects leading to last man down and first man up in the > +domain. The CPU domains helper functions defines PM domains for each CPU > +cluster and attaches the CPU devices to the respective PM domains. > + > +Platform drivers may use the following API to register their CPU PM domains. > + > +of_setup_cpu_pd() - > +Provides a single step registration of the CPU PM domain and attach CPUs to > +the genpd. Platform drivers may additionally register callbacks for power_on > +and power_off operations for the PM domain. > + > +of_setup_cpu_pd_single() - > +Define PM domain for a single CPU and attach the CPU to its domain. > + > + > +CPU PM Domain governor > +---------------------- > + > +CPUs have an unique ability to determine their next wakeup. CPUs may wake up a unique > +for known timer interrupts and unknown interrupts from idle. Prediction > +algorithms and heuristic based algorithms like the Menu governor for cpuidle > +can determine the next wakeup of the CPU. However, determining the wakeup > +across a group of CPUs is a tough problem to solve. > +
On Fri, Feb 26 2016 at 12:43 -0700, Stephen Boyd wrote: >On 02/12, Lina Iyer wrote: >> diff --git a/Documentation/power/cpu_domains.txt b/Documentation/power/cpu_domains.txt >> new file mode 100644 >> index 0000000..5fdc66d >> --- /dev/null >> +++ b/Documentation/power/cpu_domains.txt >> @@ -0,0 +1,79 @@ >> +CPU PM domains >> +============== >> + >> +Newer CPUs are grouped in SoCs as clusters. A cluster in addition to the CPUs >> +may have caches, VFP and architecture specific power controller that share the > >caches, floating point units, and other architecture specific >hardware that share resources when any of the CPUs are active. > All comments addressed. Thanks, Lina >> +resources when any of the CPUs are active. When the CPUs are in idle, some of >> +these cluster components may also idle. A cluster may also be nested inside >> +another cluster that provides common coherency interfaces to share data >> +between the clusters. The organization of such clusters and CPU may be >> +descibed in DT, since they are SoC specific. >> + >> +CPUIdle framework enables the CPUs to determine the sleep time and enter low >> +power state to save power during periods of idle. CPUs in a cluster may enter >> +and exit idle state independently of each other. During the time when all the >> +CPUs are in idle state, the cluster may safely put some of the shared >> +resources in their idle state. The time between the last CPU to enter idle and >> +the first CPU to wake up is the time available for the cluster to enter its >> +idle state. >> + >> +When SoCs power down the CPU during cpuidle, they generally have supplemental >> +hardware that can handshake with the CPU with a signal that indicates that the >> +CPU has stopped execution. The hardware is also responsible for warm booting >> +the CPU on receiving an interrupt. With cluster architecture, common resources > >In a cluster architecture, > >> +that are shared by the cluster may also be powered down by an external > >shared by a cluster > >> +microcontroller or a processor. The microcontroller may be programmed in >> +advance to put the hardware blocks in a low power state, when the last active >> +CPU sends the idle signal. When the signal is received, the microcontroller >> +may trigger the hardware blocks to enter their low power state. When an >> +interrupt to wakeup the processor is received, the microcontroller is >> +responsible for bringing up the hardware blocks to its active state, before >> +waking up the CPU. The timelines for such operations should be in the >> +acceptable range for the for CPU idle to get power benefits. > >acceptable range for CPU idle to get power benefits. > >> + >> +CPU PM Domain Setup >> +------------------- >> + >> +PM domains are represented in the DT as domain consumers and providers. A > > ^ extra space here > >> +device may have a domain provider and a domain provider may support multiple >> +domain consumers. Domains like clusters, may also be nested inside one >> +another. A domain that has no active consumer, may be powered off and any >> +resuming consumer would trigger the domain back to active. Parent domains may >> +be powered off when the child domains are powered off. The CPU cluster can be >> +fashioned as a PM domain. When the CPU devices are powered off, the PM domain >> +may be powered off. >> + >> +Device idle is reference counted by runtime PM. When there is no active need >> +for the device, runtime PM invokes callbacks to suspend the parent domain. >> +Generic PM domain (genpd) handles the hierarchy of devices, domains and the >> +reference counting of objects leading to last man down and first man up in the >> +domain. The CPU domains helper functions defines PM domains for each CPU >> +cluster and attaches the CPU devices to the respective PM domains. >> + >> +Platform drivers may use the following API to register their CPU PM domains. >> + >> +of_setup_cpu_pd() - >> +Provides a single step registration of the CPU PM domain and attach CPUs to >> +the genpd. Platform drivers may additionally register callbacks for power_on >> +and power_off operations for the PM domain. >> + >> +of_setup_cpu_pd_single() - >> +Define PM domain for a single CPU and attach the CPU to its domain. >> + >> + >> +CPU PM Domain governor >> +---------------------- >> + >> +CPUs have an unique ability to determine their next wakeup. CPUs may wake up > >a unique > >> +for known timer interrupts and unknown interrupts from idle. Prediction >> +algorithms and heuristic based algorithms like the Menu governor for cpuidle >> +can determine the next wakeup of the CPU. However, determining the wakeup >> +across a group of CPUs is a tough problem to solve. >> + > >-- >Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, >a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" 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/power/cpu_domains.txt b/Documentation/power/cpu_domains.txt new file mode 100644 index 0000000..5fdc66d --- /dev/null +++ b/Documentation/power/cpu_domains.txt @@ -0,0 +1,79 @@ +CPU PM domains +============== + +Newer CPUs are grouped in SoCs as clusters. A cluster in addition to the CPUs +may have caches, VFP and architecture specific power controller that share the +resources when any of the CPUs are active. When the CPUs are in idle, some of +these cluster components may also idle. A cluster may also be nested inside +another cluster that provides common coherency interfaces to share data +between the clusters. The organization of such clusters and CPU may be +descibed in DT, since they are SoC specific. + +CPUIdle framework enables the CPUs to determine the sleep time and enter low +power state to save power during periods of idle. CPUs in a cluster may enter +and exit idle state independently of each other. During the time when all the +CPUs are in idle state, the cluster may safely put some of the shared +resources in their idle state. The time between the last CPU to enter idle and +the first CPU to wake up is the time available for the cluster to enter its +idle state. + +When SoCs power down the CPU during cpuidle, they generally have supplemental +hardware that can handshake with the CPU with a signal that indicates that the +CPU has stopped execution. The hardware is also responsible for warm booting +the CPU on receiving an interrupt. With cluster architecture, common resources +that are shared by the cluster may also be powered down by an external +microcontroller or a processor. The microcontroller may be programmed in +advance to put the hardware blocks in a low power state, when the last active +CPU sends the idle signal. When the signal is received, the microcontroller +may trigger the hardware blocks to enter their low power state. When an +interrupt to wakeup the processor is received, the microcontroller is +responsible for bringing up the hardware blocks to its active state, before +waking up the CPU. The timelines for such operations should be in the +acceptable range for the for CPU idle to get power benefits. + +CPU PM Domain Setup +------------------- + +PM domains are represented in the DT as domain consumers and providers. A +device may have a domain provider and a domain provider may support multiple +domain consumers. Domains like clusters, may also be nested inside one +another. A domain that has no active consumer, may be powered off and any +resuming consumer would trigger the domain back to active. Parent domains may +be powered off when the child domains are powered off. The CPU cluster can be +fashioned as a PM domain. When the CPU devices are powered off, the PM domain +may be powered off. + +Device idle is reference counted by runtime PM. When there is no active need +for the device, runtime PM invokes callbacks to suspend the parent domain. +Generic PM domain (genpd) handles the hierarchy of devices, domains and the +reference counting of objects leading to last man down and first man up in the +domain. The CPU domains helper functions defines PM domains for each CPU +cluster and attaches the CPU devices to the respective PM domains. + +Platform drivers may use the following API to register their CPU PM domains. + +of_setup_cpu_pd() - +Provides a single step registration of the CPU PM domain and attach CPUs to +the genpd. Platform drivers may additionally register callbacks for power_on +and power_off operations for the PM domain. + +of_setup_cpu_pd_single() - +Define PM domain for a single CPU and attach the CPU to its domain. + + +CPU PM Domain governor +---------------------- + +CPUs have an unique ability to determine their next wakeup. CPUs may wake up +for known timer interrupts and unknown interrupts from idle. Prediction +algorithms and heuristic based algorithms like the Menu governor for cpuidle +can determine the next wakeup of the CPU. However, determining the wakeup +across a group of CPUs is a tough problem to solve. + +A simplistic approach would be to resort to known wakeups of the CPUs in +determining the next wakeup of any CPU in the cluster. The CPU PM domain +governor does just that. By looking into the tick device of the CPUs, the +governor can determine the sleep time between the last CPU and the first +scheduled wakeup of any CPU in that domain. This combined with the PM QoS +requirement for CPU_DMA_LATENCY can be used to determine the deepest possible +idle state of the CPU domain.
A generic CPU PM domain functionality is provided by drivers/base/power/cpu_domains.c. This document describes the generic usecase of CPU's PM domains, the setup of such domains and a CPU specific genpd governor. Signed-off-by: Lina Iyer <lina.iyer@linaro.org> --- Changes since RFC v1 - - a patch of its own - updated documentation Documentation/power/cpu_domains.txt | 79 +++++++++++++++++++++++++++++++++++++ 1 file changed, 79 insertions(+) create mode 100644 Documentation/power/cpu_domains.txt