From patchwork Thu Aug 25 08:42:40 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Alex Shi X-Patchwork-Id: 9298951 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 2216560757 for ; Thu, 25 Aug 2016 08:44:34 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 12B7429204 for ; Thu, 25 Aug 2016 08:44:34 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 0746F2921F; Thu, 25 Aug 2016 08:44:34 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=2.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI,T_DKIM_INVALID autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 0E77929204 for ; Thu, 25 Aug 2016 08:44:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933610AbcHYInl (ORCPT ); Thu, 25 Aug 2016 04:43:41 -0400 Received: from mail-pf0-f175.google.com ([209.85.192.175]:33077 "EHLO mail-pf0-f175.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933613AbcHYInk (ORCPT ); Thu, 25 Aug 2016 04:43:40 -0400 Received: by mail-pf0-f175.google.com with SMTP id y134so15863645pfg.0 for ; Thu, 25 Aug 2016 01:42:51 -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=AuL9a6xxvnRFjG7lrEyZ6Jte8WiYfTglIIpEgo4/y9E=; b=gXuIM44JucqReY4rkJKDpyBQbkX5Hb/uaDmg0viwCcTdxPfujlkJnUOi0vhGiYe9qy JITGpuE1tBDSMfFXykT38IeasCeYdUiak2gCfEzE06HwVEdS1PvwCqCN4B/d1E1bSUV7 3GAqIEFwQdKiKUxayK+nw+2F5s1lqPFQ/da3M= 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=AuL9a6xxvnRFjG7lrEyZ6Jte8WiYfTglIIpEgo4/y9E=; b=BgayH7c5XSwT7F8DMCRBrC5ThoOj2Uw0NQAooAHLy0/XNi2rJg9f4qm4zbMIAebAT0 nnQ4ofuyFaGFAywL5WBvEl2NHnRwNwP54O1hoDPeK3lLVjDmS8m4UacWBXSWYvcmXUki ckclrM2g+IjAfN42Bu+ixmWwne3aqhdAWdgdPcuPJbPuOd5xh7blTvnL6oZWY5iYxNMv yKTCQmSK6dZGjpJrLY03WMNzEb1BEhIIBixSe0ZEivdcTUrsg/YOnH4zmLE8pPt9jSd1 ERfEp8T3GO5sL8vo4g99/JcoJGTVkl38W4fSeR/jF3OeCRc7ShVQ9KRTH7iRB7asMEbh d+SQ== X-Gm-Message-State: AE9vXwO/zcdY5DXkTkXnPoro6iigmFF6iF25Am8hYZazwhFt5nZUPVqA1Je3cmncJiYE2/Bi X-Received: by 10.98.65.81 with SMTP id o78mr14004601pfa.48.1472114571533; Thu, 25 Aug 2016 01:42:51 -0700 (PDT) Received: from localhost.localdomain ([139.59.249.186]) by smtp.gmail.com with ESMTPSA id h66sm19016433pfe.58.2016.08.25.01.42.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 25 Aug 2016 01:42:51 -0700 (PDT) From: Alex Shi To: Greg Kroah-Hartman , linux-kernel@vger.kernel.org (open list) Cc: linux-pm@vger.kernel.org, Ulf Hansson , Daniel Lezcano Subject: [PATCH 2/4] cpu: expose pm_qos_resume_latency for each cpu Date: Thu, 25 Aug 2016 16:42:40 +0800 Message-Id: <1472114562-2736-2-git-send-email-alex.shi@linaro.org> X-Mailer: git-send-email 2.8.1.101.g72d917a In-Reply-To: <1472114562-2736-1-git-send-email-alex.shi@linaro.org> References: <1472114562-2736-1-git-send-email-alex.shi@linaro.org> Sender: linux-pm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP 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 To: linux-kernel@vger.kernel.org To: Greg Kroah-Hartman Cc: linux-pm@vger.kernel.org Cc: Ulf Hansson Cc: Daniel Lezcano --- drivers/base/cpu.c | 3 +++ 1 file changed, 3 insertions(+) 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; }