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=-3.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED 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 B6A57C63697 for ; Thu, 19 Nov 2020 17:46:45 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 433A8246CA for ; Thu, 19 Nov 2020 17:46:45 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=mg.codeaurora.org header.i=@mg.codeaurora.org header.b="YCvra0UO" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729730AbgKSRqo (ORCPT ); Thu, 19 Nov 2020 12:46:44 -0500 Received: from z5.mailgun.us ([104.130.96.5]:17855 "EHLO z5.mailgun.us" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729344AbgKSRqo (ORCPT ); Thu, 19 Nov 2020 12:46:44 -0500 DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=mg.codeaurora.org; q=dns/txt; s=smtp; t=1605808004; h=In-Reply-To: Content-Type: MIME-Version: References: Message-ID: Subject: Cc: To: From: Date: Sender; bh=Rbk83JLyKBowqtyi3Q2SenfF02fWJYKIxfSgAfJdQos=; b=YCvra0UO7TZvRCYqJjkUhS60kyl4iJlhVt20DQQcrEJm674+Ua65aa8VIPIDJVs1Mxxy8M+s gEsz71hHlQnEOHsJMediKFsoM16MXWEU/j9mBlaKW1/9bZ4Knm+XZq4Z7JWnuvK3MbFm8vcP 88SIBu/0y/3D0ocdXY8RbIqJ6Rc= X-Mailgun-Sending-Ip: 104.130.96.5 X-Mailgun-Sid: WyI5ZDFmMiIsICJsaW51eC1wbUB2Z2VyLmtlcm5lbC5vcmciLCAiYmU5ZTRhIl0= Received: from smtp.codeaurora.org (ec2-35-166-182-171.us-west-2.compute.amazonaws.com [35.166.182.171]) by smtp-out-n05.prod.us-east-1.postgun.com with SMTP id 5fb6af837f0cfa6a16e37591 (version=TLS1.2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256); Thu, 19 Nov 2020 17:46:43 GMT Sender: ilina=codeaurora.org@mg.codeaurora.org Received: by smtp.codeaurora.org (Postfix, from userid 1001) id 30969C43461; Thu, 19 Nov 2020 17:46:43 +0000 (UTC) Received: from localhost (i-global254.qualcomm.com [199.106.103.254]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: ilina) by smtp.codeaurora.org (Postfix) with ESMTPSA id 4A729C433C6; Thu, 19 Nov 2020 17:46:42 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org 4A729C433C6 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 Date: Thu, 19 Nov 2020 10:46:41 -0700 From: Lina Iyer To: Ulf Hansson Cc: "Rafael J. Wysocki" , Linux PM , linux-arm-msm Subject: Re: [PATCH v5 2/2] PM / Domains: use device's next wakeup to determine domain idle state Message-ID: References: <20201106164811.3698-1-ilina@codeaurora.org> <20201106164811.3698-3-ilina@codeaurora.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org On Thu, Nov 19 2020 at 02:57 -0700, Ulf Hansson wrote: >On Mon, 16 Nov 2020 at 16:57, Lina Iyer wrote: >> >> On Fri, Nov 13 2020 at 03:34 -0700, Ulf Hansson wrote: >> >On Wed, 11 Nov 2020 at 17:51, Lina Iyer wrote: >> >> >> >> On Tue, Nov 10 2020 at 03:02 -0700, Ulf Hansson wrote: >> >> >On Mon, 9 Nov 2020 at 18:41, Lina Iyer wrote: >> >> >> >> >> >> On Mon, Nov 09 2020 at 08:27 -0700, Ulf Hansson wrote: >> >> >> >On Fri, 6 Nov 2020 at 17:48, Lina Iyer wrote: >> [...] >> >> >> >> >For example, there's no point doing the above, if the domain doesn't >> >> >> >specify residency values for its idle states. >> >> >> > >> >> >> We would still need to ensure that the next wakeup is after the >> >> >> power_off_latency, if specified. >> >> > >> >> >Good point! Although, I would rather avoid adding the overhead, unless >> >> >the residency is specified. Do you see a problem with this approach? >> >> > >> >> Hmmm, no strong objections. However, we still need to run through the >> >> states to make sure the residency is not set and have a variable track >> >> that. >> > >> >Right. >> > >> >The important part is that we can do that once and not for every call >> >to the governor. >> > >> >> The devices wouldn't know that and would still continue to set the >> >> next wakeup, unless we find a way to let them know we are not using this >> >> feature for the domain. >> > >> >Right. >> > >> >To allow the driver to know, we could respond with an error code from >> >the new dev_pm_genpd_set_performance_state() API (from patch1), in >> >case the genpd+governor doesn't support it. >> > >> It would an unnecessary work everytime a next wakeup is being set to >> iterate through the available states and figure out if the residency has >> been set or not. We could probably hold that result in a variable when >> we setup the genpd states. Expect the next_wake to be set from a >> critical path or an interrupt handler, so we have to be quick. > >Yes, that's the idea I had in mind. > >Maybe it's not feasible, let's see. However, for sure I am looking at >decreasing overhead, not to increase. :-) > Wondering what do you think about a genpd flag for this purpose? The flag may be set when the genpd is initialized with idle states that have residency specified. In the governor, we could skip this path completely, if the flag is not set. --Lina >> >> >Would that be okay? Otherwise we will have to add a separate genpd >> >API, asking explicitly if the "next wakeup" feature is supported. >> > >> Would like to avoid that as much as possible. > >Okay, good. > >Kind regards >Uffe