From patchwork Thu Aug 25 19:51:41 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Lina Iyer X-Patchwork-Id: 74705 Delivered-To: patch@linaro.org Received: by 10.140.29.52 with SMTP id a49csp1012244qga; Thu, 25 Aug 2016 12:52:38 -0700 (PDT) X-Received: by 10.98.73.131 with SMTP id r3mr19403624pfi.112.1472154757624; Thu, 25 Aug 2016 12:52:37 -0700 (PDT) Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id pj6si16923845pac.250.2016.08.25.12.52.37; Thu, 25 Aug 2016 12:52:37 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-pm-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=neutral (body hash did not verify) header.i=@linaro.org; spf=pass (google.com: best guess record for domain of linux-pm-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-pm-owner@vger.kernel.org; dmarc=fail (p=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757057AbcHYTwe (ORCPT + 14 others); Thu, 25 Aug 2016 15:52:34 -0400 Received: from mail-pa0-f45.google.com ([209.85.220.45]:33627 "EHLO mail-pa0-f45.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756875AbcHYTw0 (ORCPT ); Thu, 25 Aug 2016 15:52:26 -0400 Received: by mail-pa0-f45.google.com with SMTP id ti13so19689820pac.0 for ; Thu, 25 Aug 2016 12:52:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=91y2xiSaIH8mHCdkE7TEB06kh1lqQlJpGwOOZGDufR0=; b=E8D90h/pHlfqG67x9l7Ze1+WOIc+DouhWor8UeNKcsawv0OtgC2xdUZtzZuDoIrb3N vEX3H6v8C4u8AgExMU07/tADymmBAsvXpZA0AkbudTKGIrun9kV577Mqw0G+bSe4+vwW S/xdqDqNg/o6Ny6IXEIwlPzIhSqrOtavwqmlc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=91y2xiSaIH8mHCdkE7TEB06kh1lqQlJpGwOOZGDufR0=; b=HWqKcqH4tQrU/MNAKwMFWlX+hPaCX/fQkY0xAyn9wy05FBylkK2Ht4ZGRg14eYDLHT reJLK7Czo4NN0CrH6UY91+queNx91R0AzJNNiaDgDmGTwwOQHmnUCzvqKfakV5S6/j/F xK3CwVSRkw3GU5unTjH+uumrEUgb9Az7RcJJPDM1th0PuKkPdW2p23cm3a9SP87LlzFo coIphUATOyK0LY+u9zJhdwBM9JLXInyrBo9lItpk1eKwFuVRjPJGTfbvzpAGiYJ/hL7h neeqAxz6MY+au+zFbPCaaDqx2fQb0M0RP9kzLlEJ+7i3al5H2z6eZ6zg+UsezQ1zaBYv ZLDQ== X-Gm-Message-State: AE9vXwOx2UojNh3glp/hokI7Yo6ua7AGPbHMO7AZOcgighWfAR4SCdWwgYUJyWWR8hSBjoUZ X-Received: by 10.66.42.228 with SMTP id r4mr291645pal.24.1472154740989; Thu, 25 Aug 2016 12:52:20 -0700 (PDT) Received: from ubuntu.localdomain (i-global254.qualcomm.com. [199.106.103.254]) by smtp.gmail.com with ESMTPSA id i62sm22783375pfg.62.2016.08.25.12.52.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 25 Aug 2016 12:52:20 -0700 (PDT) From: Lina Iyer To: ulf.hansson@linaro.org, khilman@kernel.org, rjw@rjwysocki.net, linux-pm@vger.kernel.org, linux-arm-kernel@lists.infradead.org Cc: andy.gross@linaro.org, sboyd@codeaurora.org, linux-arm-msm@vger.kernel.org, brendan.jackman@arm.com, lorenzo.pieralisi@arm.com, sudeep.holla@arm.com, Juri.Lelli@arm.com, Lina Iyer Subject: [PATCH v4 11/16] doc / cpu_domains: Describe CPU PM domains setup and governor Date: Thu, 25 Aug 2016 13:51:41 -0600 Message-Id: <1472154706-40119-12-git-send-email-lina.iyer@linaro.org> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1472154706-40119-1-git-send-email-lina.iyer@linaro.org> References: <1472154706-40119-1-git-send-email-lina.iyer@linaro.org> Sender: linux-pm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org 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 --- Documentation/power/cpu_domains.txt | 109 ++++++++++++++++++++++++++++++++++++ 1 file changed, 109 insertions(+) create mode 100644 Documentation/power/cpu_domains.txt -- 2.7.4 -- To unsubscribe from this list: send the line "unsubscribe linux-pm" 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..6a39a64 --- /dev/null +++ b/Documentation/power/cpu_domains.txt @@ -0,0 +1,109 @@ +CPU PM domains +============== + +Newer CPUs are grouped in SoCs as clusters. A cluster in addition to the CPUs +may have caches, floating point units and other architecture specific power +controller that share 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. In a cluster architecture, common resources +that are shared by a 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 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 a 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. + + +PSCI based CPU PM Domains +------------------------- + +ARM PSCI v1.0 supports PM domains for CPU clusters like in big.Little +architecture. It is supported as part of the OS-Initiated (OSI) mode of the +PSCI firmware. Since the control of domains is abstracted in the firmware, +Linux does not need even a driver to control these domains. The complexity of +determining the idle state of the PM domain is handled by the CPU PM domains. + +Every PSCI CPU PM domain idle state has a unique PSCI state id. The state id +is read from the DT and specified using the arm,psci-suspend-param property. +This makes it easy for big.Little SoCs to just specify the PM domain idle +states for the CPU along with the psci-suspend-param and everything else is +handled by the PSCI fimrware drivers and the firmware. + + +DT definitions for PSCI CPU PM Domains +-------------------------------------- + +A PM domain's idle state can be defined in DT, the description of which is +available in [1]. PSCI based CPU PM domains may define their idle states as +part of the psci node. The additional parameter arm,psci-suspend-param is used +to indicate to the firmwware the addition cluster state that would be achieved +after the last CPU makes the PSCI call to suspend the CPU. The description of +PSCI domain states is available in [2]. + +[1]. Documentation/devicetree/bindings/arm/idle-states.txt +[2]. Documentation/devicetree/bindings/arm/psci.txt