From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_GIT autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 85701C43457 for ; Mon, 12 Oct 2020 22:34:37 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 3D4F420797 for ; Mon, 12 Oct 2020 22:34:37 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=mg.codeaurora.org header.i=@mg.codeaurora.org header.b="nKlTYei0" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2390300AbgJLWeg (ORCPT ); Mon, 12 Oct 2020 18:34:36 -0400 Received: from m42-4.mailgun.net ([69.72.42.4]:35118 "EHLO m42-4.mailgun.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2390051AbgJLWef (ORCPT ); Mon, 12 Oct 2020 18:34:35 -0400 DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=mg.codeaurora.org; q=dns/txt; s=smtp; t=1602542074; h=Content-Transfer-Encoding: MIME-Version: Message-Id: Date: Subject: Cc: To: From: Sender; bh=sflyGCGy5TB2ukNP2ZHfV/JvTdRpoIj2ZM6HWG0GHas=; b=nKlTYei09C3APms0ig0Pb/bHtd0fw0/Fhk/SDDd8yg0NBV9peewaeC3dYZ4aY60MV9e4OEyT xYp89txJoQSdF7s6lkUHLKaZxBTrFV95soqsjHQY4NcQ1WnCLfnEBGaLc9PhiJRJO7D8l4Yw KKQcF8mqmDWZpFLzPX+OnSAefTA= X-Mailgun-Sending-Ip: 69.72.42.4 X-Mailgun-Sid: WyI1MzIzYiIsICJsaW51eC1hcm0tbXNtQHZnZXIua2VybmVsLm9yZyIsICJiZTllNGEiXQ== Received: from smtp.codeaurora.org (ec2-35-166-182-171.us-west-2.compute.amazonaws.com [35.166.182.171]) by smtp-out-n03.prod.us-east-1.postgun.com with SMTP id 5f84d9fa4f8cc67c31ef755e (version=TLS1.2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256); Mon, 12 Oct 2020 22:34:34 GMT Sender: ilina=codeaurora.org@mg.codeaurora.org Received: by smtp.codeaurora.org (Postfix, from userid 1001) id 65119C43395; Mon, 12 Oct 2020 22:34:33 +0000 (UTC) Received: from codeaurora.org (i-global254.qualcomm.com [199.106.103.254]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: ilina) by smtp.codeaurora.org (Postfix) with ESMTPSA id 386C6C433FF; Mon, 12 Oct 2020 22:34:32 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org 386C6C433FF Authentication-Results: aws-us-west-2-caf-mail-1.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: aws-us-west-2-caf-mail-1.web.codeaurora.org; spf=fail smtp.mailfrom=ilina@codeaurora.org From: Lina Iyer To: rjw@rjwysocki.net, ulf.hansson@linaro.org, linux-pm@vger.kernel.org Cc: linux-arm-msm@vger.kernel.org, Lina Iyer Subject: [PATCH 0/2] Better domain idle from device wakeup patterns Date: Mon, 12 Oct 2020 16:33:58 -0600 Message-Id: <20201012223400.23609-1-ilina@codeaurora.org> X-Mailer: git-send-email 2.28.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-arm-msm@vger.kernel.org Changes since RFC [1]: - Organized the code to make it cleaner - Fixed some issues with idle state determination - Add documentation and update commit text Hello, I was looking for an option to do better power management for some domains where the devices enter runtime PM in a predictable fashion. For example a display device that sends a vsync interrupt every 16 ms for a 60 Hz panel. These interrupts are not timer interrupts but tend to interrupt periodically to service the workflow and the devices and domains may go back to idle soon after. Two domains are affected by this - the device's PM domain and the CPU PM domain. As a first step, I am looking to solve for the device's PM domain idle state (and hopefully solve for the CPU PM domains subsequently). The PM domain could have multiple idle states and/or the enter/exit latencies could be high. In either case, it may not always be beneficial to power off the domain, only to turn it back on before satisfying the idle state residency. When the wakeup is known for the device, we could use that to determine the worthiness of entering a domain idle state. Only the device can tell us when the future event would be and that could change as the usecase changes. Like, when the panel refresh rate increases to 120 Hz. If this information was made available to runtime PM, we could use that in the domain governor to determine a suitable idle state. This is the idea behind these patches. Would appreciate your thoughts on this. Thanks, Lina [1]. https://lore.kernel.org/linux-pm/010101746eccb270-05beb27f-e1e4-40eb-92da-ad1bb48feb41-000000@us-west-2.amazonses.com/T/ Lina Iyer (2): PM / runtime: register device's next wakeup PM / Domains: use device's next wakeup to determine domain idle state Documentation/power/runtime_pm.rst | 21 +++++++ drivers/base/power/domain_governor.c | 83 ++++++++++++++++++++++++++-- drivers/base/power/runtime.c | 31 +++++++++++ include/linux/pm.h | 2 + include/linux/pm_domain.h | 1 + include/linux/pm_runtime.h | 1 + 6 files changed, 134 insertions(+), 5 deletions(-) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project