From patchwork Mon Aug 22 04:49:07 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Alex Shi X-Patchwork-Id: 74385 Delivered-To: patch@linaro.org Received: by 10.140.29.52 with SMTP id a49csp1376538qga; Sun, 21 Aug 2016 21:49:17 -0700 (PDT) X-Received: by 10.66.162.4 with SMTP id xw4mr38324371pab.97.1471841357727; Sun, 21 Aug 2016 21:49:17 -0700 (PDT) Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g9si20639818pfk.211.2016.08.21.21.49.17; Sun, 21 Aug 2016 21:49:17 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753155AbcHVEtN (ORCPT + 27 others); Mon, 22 Aug 2016 00:49:13 -0400 Received: from mail-pf0-f170.google.com ([209.85.192.170]:35577 "EHLO mail-pf0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751198AbcHVEtM (ORCPT ); Mon, 22 Aug 2016 00:49:12 -0400 Received: by mail-pf0-f170.google.com with SMTP id x72so28138350pfd.2 for ; Sun, 21 Aug 2016 21:49:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=subject:cc:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=oyQ6HxyLBFhtVaOh0UfYqGM1Ww2I4yhzVPFFdWbXQr8=; b=B6okBD9qDcnczErWsAb5d7FCvWBk9bjapApt/YmxZyU4LVVzVBX+OgYu4mo39jxEWE u/vOY8lv/YkzkOWCyV0HLIt4gUYeqhA0Nrgq9W/fjrhV+tat3EB/iG9e37lxpMLV4+/6 7kVxXcA8SpnNXfSC7KMtjiN2IWH6vBx8ioMQ4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=oyQ6HxyLBFhtVaOh0UfYqGM1Ww2I4yhzVPFFdWbXQr8=; b=mMmSUnudKxIoAEpysC6DrvN6GOe2FXoKBh5B84X3Cv4tBloF8prolhFjcRostfxRhz Zt58k+pUfEFpCQ2WdjnaNopsGzwZsbClLHGHLvRSNNRqd6oPjUkAOpfDqIuX59giEqXM 0yazQby2N0qSS2gDcAAv0fQBTpPOhSGQt6miyulKj6+CvILd3oGfCTAL/n3D6fpfrn63 xUIwM6zxm/VrokycZR6MR6xdyoAZjI2t4qU1SAQziYAM1mUlczDzQVY4uq3vhw0P6BRD W+45zb/1TLZLHWZhiEAL/3f1xME/ysGyc6VZfBetS7CxplKfT1+h59eVcpZLW5prTLgn sCPQ== X-Gm-Message-State: AEkoouvcFt4HJcMFMjB1ivIrHYWzL7EDVfxnxnpm02CTUF3aPlJUu8OrtYdszek9HY7jqml6 X-Received: by 10.98.17.83 with SMTP id z80mr39522576pfi.38.1471841351470; Sun, 21 Aug 2016 21:49:11 -0700 (PDT) Received: from [192.168.0.100] ([139.59.249.186]) by smtp.googlemail.com with ESMTPSA id 15sm23467260pfz.36.2016.08.21.21.49.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 21 Aug 2016 21:49:10 -0700 (PDT) Subject: Re: [PATCH 2/4] cpu: expose pm_qos_resume_latency for each cpu Cc: Daniel Lezcano , Greg Kroah-Hartman , open list References: <1471595114-1688-1-git-send-email-alex.shi@linaro.org> <1471595114-1688-2-git-send-email-alex.shi@linaro.org> From: Alex Shi Message-ID: <57BA8443.2080108@linaro.org> Date: Mon, 22 Aug 2016 12:49:07 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <1471595114-1688-2-git-send-email-alex.shi@linaro.org> To: unlisted-recipients:; (no To-header on input) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Add a pr_debug for failure output. >From dc5111ed3974f994a9f1d88fdd8dc813359a3b6c Mon Sep 17 00:00:00 2001 From: Alex Shi Date: Tue, 16 Aug 2016 15:29:01 +0800 Subject: [PATCH 2/4] cpu: expose pm_qos_resume_latency for each cpu The cpu-dma PM QoS constraint impacts all the cpus in the system. There is no way to let the user to choose a PM QoS constraint per cpu. The following patch exposes to the userspace a per cpu based sysfs file in order to let the userspace to change the value of the PM QoS latency constraint. This change is inoperative in its form and the cpuidle governors have to take into account the per cpu latency constraint in addition to the global cpu-dma latency constraint in order to operate properly. BTW The pm_qos_resume_latency usage defined in Documentation/ABI/testing/sysfs-devices-power The /sys/devices/.../power/pm_qos_resume_latency_us attribute contains the PM QoS resume latency limit for the given device, which is the maximum allowed time it can take to resume the device, after it has been suspended at run time, from a resume request to the moment the device will be ready to process I/O, in microseconds. If it is equal to 0, however, this means that the PM QoS resume latency may be arbitrary. Signed-off-by: Alex Shi --- drivers/base/cpu.c | 3 +++ 1 file changed, 3 insertions(+) -- 2.8.1.101.g72d917a diff --git a/drivers/base/cpu.c b/drivers/base/cpu.c index 4c28e1a..ba11e23 100644 --- a/drivers/base/cpu.c +++ b/drivers/base/cpu.c @@ -17,6 +17,7 @@ #include #include #include +#include #include "base.h" @@ -376,6 +377,8 @@ int register_cpu(struct cpu *cpu, int num) per_cpu(cpu_sys_devices, num) = &cpu->dev; register_cpu_under_node(num, cpu_to_node(num)); + if (dev_pm_qos_expose_latency_limit(&cpu->dev, 0)) + pr_debug("CPU%d: add resume latency failed\n", num); return 0; }