From patchwork Fri Aug 26 10:24:33 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ulf Hansson X-Patchwork-Id: 74779 Delivered-To: patches@linaro.org Received: by 10.140.29.52 with SMTP id a49csp251308qga; Fri, 26 Aug 2016 03:24:48 -0700 (PDT) X-Received: by 10.46.33.217 with SMTP id h86mr677071lji.39.1472207088762; Fri, 26 Aug 2016 03:24:48 -0700 (PDT) Return-Path: Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com. [2a00:1450:4010:c07::235]) by mx.google.com with ESMTPS id 10si8130205lfc.334.2016.08.26.03.24.48 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 26 Aug 2016 03:24:48 -0700 (PDT) Received-SPF: pass (google.com: domain of ulf.hansson@linaro.org designates 2a00:1450:4010:c07::235 as permitted sender) client-ip=2a00:1450:4010:c07::235; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org; spf=pass (google.com: domain of ulf.hansson@linaro.org designates 2a00:1450:4010:c07::235 as permitted sender) smtp.mailfrom=ulf.hansson@linaro.org; dmarc=pass (p=NONE dis=NONE) header.from=linaro.org Received: by mail-lf0-x235.google.com with SMTP id f93so53567960lfi.2 for ; Fri, 26 Aug 2016 03:24:48 -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; bh=GypvMendPmVukz1mb7DzJYMBayH31aZf8hAEHehpSj8=; b=aj68jmabppmf/vDUmLsI3BjhS460gamcFKY1Fyy1eYzIi5UbhdluBCa8zOy0SbOgmC 14QMfOtdNsa0zr/zKzo+003ezXiyjQvCBkIdyX5Y8lNRPD/Ez7ksEwcdlnM08XNDLPPV W4SxUQR8oyBIVn9uM11TXyTZzMjkNXw6ZkR3E= 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; bh=GypvMendPmVukz1mb7DzJYMBayH31aZf8hAEHehpSj8=; b=FLcd7rdcUxBGVL3HrJ8TMkF3K2BSwQYGQMGcq5JSMcNj2wz2epSb5VjxE9f3uCHLIP XcQmVMxqyUuQnUoja21IAAaMWppHFTvfOWBOVg83DoIi8DAwzqxdy0TjYnGSFNMYhQ0s WV95IPMwQRm1RS6F1Ee6h3WvXASh9TJN7llUEzVlmniv6eVD+Vt9nLhza6gX8jyD8ese uc02HoO3COn492YKf7Soo1LYN3mJMSsUFXCqbY86CzQBr1h6+QMB2lYRG6BJngQ1Rnx0 t0NoN6LS09UdFFtluUiVmPJYHvbmS/8A/fIlKf1QJaaxJumfOdkND7tA2Lmakjv1UpKH RKsg== X-Gm-Message-State: AE9vXwP8vPBaj8J03UmeAP+ZPXWeza9lDUv2FTRUZWVBrUY1P/zaeWCb66eTnKGmcVRTzoh7aH8= X-Received: by 10.46.0.204 with SMTP id e73mr730960lji.56.1472207088243; Fri, 26 Aug 2016 03:24:48 -0700 (PDT) Return-Path: Received: from localhost.localdomain (h-155-4-130-67.na.cust.bahnhof.se. [155.4.130.67]) by smtp.gmail.com with ESMTPSA id g88sm3803447ljg.26.2016.08.26.03.24.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 26 Aug 2016 03:24:46 -0700 (PDT) From: Ulf Hansson To: Kevin Hilman , Lina Iyer , Ulf Hansson , Rob Herring , Sudeep Holla , Lorenzo Pieralisi , Brendan Jackman , Daniel Lezcano , devicetree@vger.kernel.org Cc: "Rafael J. Wysocki" , Len Brown , Pavel Machek , Geert Uytterhoeven , Axel Haslam , linux-pm@vger.kernel.org Subject: [RFC/PATCH] dt: bindings: Define bindings for device idle states Date: Fri, 26 Aug 2016 12:24:33 +0200 Message-Id: <1472207073-4901-1-git-send-email-ulf.hansson@linaro.org> X-Mailer: git-send-email 1.9.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 --- 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 -- 1.9.1 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>; + }; +