From patchwork Fri Feb 12 20:50:34 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Lina Iyer X-Patchwork-Id: 8297521 Return-Path: X-Original-To: patchwork-linux-arm@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id A315BC02AA for ; Fri, 12 Feb 2016 20:55:26 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 8A75920459 for ; Fri, 12 Feb 2016 20:55:25 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.9]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 954F220444 for ; Fri, 12 Feb 2016 20:55:24 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1aUKir-0008SF-KH; Fri, 12 Feb 2016 20:53:49 +0000 Received: from mail-pf0-x229.google.com ([2607:f8b0:400e:c00::229]) by bombadil.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1aUKgy-0006XF-Oy for linux-arm-kernel@lists.infradead.org; Fri, 12 Feb 2016 20:51:56 +0000 Received: by mail-pf0-x229.google.com with SMTP id q63so52950393pfb.0 for ; Fri, 12 Feb 2016 12:51:36 -0800 (PST) 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=dx1DmwK4S3EeHF1Se/q5h5HrocG+wwZKozEpuqsWtXk=; b=Sw0eef+rfm5Wwpja4sP81Z+2CV/hB7ETMqla5gxDImNOZlBZP4zLPHH0rkbR2lshQt Zr76Cxh7s92IDJ3mhvWkTBjR4TxKGQ6dhDr7NZ3N6ivf4NC9mbBGSdFSLu/2UZbDmxgZ k49ebDCDVAQagIivqAGMoEDiWJUnOo8w/CXkA= 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=dx1DmwK4S3EeHF1Se/q5h5HrocG+wwZKozEpuqsWtXk=; b=fLaWJMRAVGXd8YL3b9Xyj2N7VWPIjumkPNmYZNJcRTja/mFP3Ukq3cGoih64LQUjGh dgkHqROEMrYUYLIFl0saNTQQ6PrEol6lrCBdM4Qv8xTfh8XKSluEiLhaPG0ac5EpM/vd RkfeVoTIvsIMtq5E0Y2LqhEtx8XCD3aJVPnhWsEkJSPuCK+QgLsHJTkzP0dC62oKiVSL sJR6e9dnwBK0zzu4YvfyIgk5Uwa+J+V95yOMouRc+2sMAgrajPdlVSqRYxTT4jnUZI9/ Eba3uJF/OzkErvYGvEpvhwR+WGmH9Kv3GzuwuPi11+OW0J+2P3fCAh94t866MD7fUE3k nMuw== X-Gm-Message-State: AG10YORaEK8d/LkOolL1MIbTIj6NjAmo7y0pSHVnVUMOVR0kRYN9vkYw0oj3WkZQDIWxFXyR X-Received: by 10.98.16.69 with SMTP id y66mr5147176pfi.86.1455310296376; Fri, 12 Feb 2016 12:51:36 -0800 (PST) Received: from ubuntu.localdomain ([172.56.8.98]) by smtp.gmail.com with ESMTPSA id x12sm21401070pfi.88.2016.02.12.12.51.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 12 Feb 2016 12:51:35 -0800 (PST) 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 Subject: [RFC v2 08/12] Documentation / cpu_domains: Describe CPU PM domains setup and governor Date: Fri, 12 Feb 2016 13:50:34 -0700 Message-Id: <1455310238-8963-9-git-send-email-lina.iyer@linaro.org> X-Mailer: git-send-email 2.1.4 In-Reply-To: <1455310238-8963-1-git-send-email-lina.iyer@linaro.org> References: <1455310238-8963-1-git-send-email-lina.iyer@linaro.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20160212_125153_127262_A3BAFBEE X-CRM114-Status: GOOD ( 21.30 ) X-Spam-Score: -2.7 (--) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: k.kozlowski@samsung.com, lorenzo.pieralisi@arm.com, ahaslam@baylibre.com, linux-arm-msm@vger.kernel.org, sboyd@codeaurora.org, msivasub@codeaurora.org, geert@linux-m68k.org, Lina Iyer , agross@codeaurora.org, mtitinger@baylibre.com MIME-Version: 1.0 Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_MED,RP_MATCHES_RCVD,T_DKIM_INVALID,UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP 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 --- 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 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.