From patchwork Fri Aug 30 15:02:59 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Geert Uytterhoeven X-Patchwork-Id: 1155955 Return-Path: X-Original-To: incoming-dt@patchwork.ozlabs.org Delivered-To: patchwork-incoming-dt@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=vger.kernel.org (client-ip=209.132.180.67; helo=vger.kernel.org; envelope-from=devicetree-owner@vger.kernel.org; receiver=) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=glider.be Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 46KjQq5G14z9sBp for ; Sat, 31 Aug 2019 01:03:15 +1000 (AEST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727809AbfH3PDM (ORCPT ); Fri, 30 Aug 2019 11:03:12 -0400 Received: from andre.telenet-ops.be ([195.130.132.53]:54142 "EHLO andre.telenet-ops.be" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728192AbfH3PDL (ORCPT ); Fri, 30 Aug 2019 11:03:11 -0400 Received: from ramsan ([84.194.98.4]) by andre.telenet-ops.be with bizsmtp id vT382000705gfCL01T38d4; Fri, 30 Aug 2019 17:03:09 +0200 Received: from rox.of.borg ([192.168.97.57]) by ramsan with esmtp (Exim 4.90_1) (envelope-from ) id 1i3iQe-0003gk-65; Fri, 30 Aug 2019 17:03:08 +0200 Received: from geert by rox.of.borg with local (Exim 4.90_1) (envelope-from ) id 1i3iQe-0005ML-52; Fri, 30 Aug 2019 17:03:08 +0200 From: Geert Uytterhoeven To: Lorenzo Pieralisi , Catalin Marinas , Amit Kucheria , Rob Herring , Mark Rutland Cc: Daniel Lezcano , Nicolas Pitre , Sebastian Capella , devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, Geert Uytterhoeven Subject: [PATCH 2/5] dt-bindings: arm: idle-states: Correct references to wake-up delay Date: Fri, 30 Aug 2019 17:02:59 +0200 Message-Id: <20190830150302.20551-3-geert+renesas@glider.be> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20190830150302.20551-1-geert+renesas@glider.be> References: <20190830150302.20551-1-geert+renesas@glider.be> Sender: devicetree-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org The paragraph explains the use of wakup-delay, as defined above. Signed-off-by: Geert Uytterhoeven --- Documentation/devicetree/bindings/arm/idle-states.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/arm/idle-states.txt b/Documentation/devicetree/bindings/arm/idle-states.txt index 610b16c28d99c3ef..6e651b7e62c328be 100644 --- a/Documentation/devicetree/bindings/arm/idle-states.txt +++ b/Documentation/devicetree/bindings/arm/idle-states.txt @@ -99,8 +99,8 @@ of an idle state, e.g.: wakeup-delay = exit-latency + max(entry-latency - (now - entry-timestamp), 0) In other words, the scheduler can make its scheduling decision by selecting -(e.g. waking-up) the CPU with the shortest wake-up latency. -The wake-up latency must take into account the entry latency if that period +(e.g. waking-up) the CPU with the shortest wake-up delay. +The wake-up delay must take into account the entry latency if that period has not expired. The abortable nature of the PREP period can be ignored if it cannot be relied upon (e.g. the PREP deadline may occur much sooner than the worst case since it depends on the CPU operating conditions, i.e. caches