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=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS 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 4F346C47082 for ; Thu, 3 Jun 2021 13:50:01 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 34839613E9 for ; Thu, 3 Jun 2021 13:50:01 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230428AbhFCNvo (ORCPT ); Thu, 3 Jun 2021 09:51:44 -0400 Received: from mail-ua1-f51.google.com ([209.85.222.51]:33706 "EHLO mail-ua1-f51.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230099AbhFCNvo (ORCPT ); Thu, 3 Jun 2021 09:51:44 -0400 Received: by mail-ua1-f51.google.com with SMTP id l12so3360759uai.0 for ; Thu, 03 Jun 2021 06:49:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2UjUIW9zbfUZ4RwOyiLkvVO/eF05W329MyzzFPGAFB4=; b=c44tayuwS2u8SQTEybCZAoA5xeWfvrXFKtD564C4jJwGB3LaCJpSsEtBNEMceN0G4x jW5niwBZvJjlupvPzD8zRa7VTqtAk4psSC0Iu/YBoZqCi42lxExp+oxniv/hRb+xOv6z 76JcqI57DEpdlB7LFMgJxEL7ybPXqISHaBGY+O26Skt2Xl+JwpmpK+qS+lV1uGP4RiZg u5jdnki9BSJ/j5U/4yfaL/rHRzDRgubs68Simzrh2pytp5kDf4iGMfnT4R7rW3oSdDJJ dBWUIiZLJVJ+JX1Ea5OTd4EBt8on4u3QjLovQmzeroAkGOMKD7+yHceXHBN6cEgc8kzl Tx3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2UjUIW9zbfUZ4RwOyiLkvVO/eF05W329MyzzFPGAFB4=; b=aXAZl199N/DLTMwu0mTxctBdB7UiulUulvj5EVk94Ipk2/FAADlkdhBtujMiMaUdk+ FFt23qe3Z2YdAkvEvULzyTFqS7SnQj18hg3jKSwhHlZpAqTItYNKl2k6qTI/mS0njwwX YmxIGXvqQ5dyLSCNPHQfRjbiD7txc/ORKsrO/wFEyPqFB5IlpwcY2aWPyDFDdfp0p+43 JmV1MIEboH3C05r/HAew4MVc3rKxq1ImJsDQ7C5TrHOWWFEueNvtcuFT7r8ye4fnlmvA tyIvE59qoXbi5UWsxTRjVPqrPJBNmTOdfXHKZqvcIiSd/a+TJgKVPqs3IozKklmbCn1w BpHw== X-Gm-Message-State: AOAM531Ub/N+5TKhg+TypomQCNl9Po87K4l5vyWVooe7P6fGacDIeue3 P9bm9h9Lu3FzosJcQXSRVqjWCbf5jXrwUVOZu+SnHnWnc/R0xw== X-Google-Smtp-Source: ABdhPJwXOmWBpw9TxY14OndWy9w9S1xWe5445oPP85ttLd+bbAgHrOOP7FzQCKwlHmMSuw2tXjl+JGJ8Kk8oe8fUYoc= X-Received: by 2002:ab0:d8f:: with SMTP id i15mr24663046uak.104.1622728126477; Thu, 03 Jun 2021 06:48:46 -0700 (PDT) MIME-Version: 1.0 References: <20210603093438.138705-1-ulf.hansson@linaro.org> <20210603093438.138705-5-ulf.hansson@linaro.org> <20210603111529.GB4257@sirena.org.uk> In-Reply-To: <20210603111529.GB4257@sirena.org.uk> From: Ulf Hansson Date: Thu, 3 Jun 2021 15:48:10 +0200 Message-ID: Subject: Re: [PATCH v2 4/4] PM: domains: Drop/restore performance state votes for devices at system PM To: Mark Brown Cc: "Rafael J . Wysocki" , Viresh Kumar , Dmitry Baryshkov , Linux PM , Dmitry Osipenko , Jonathan Hunter , Thierry Reding , Roja Rani Yarubandi , Bjorn Andersson , Vincent Guittot , Stephen Boyd , Stephan Gerhold , Linux Kernel Mailing List , Rajendra Nayak Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org On Thu, 3 Jun 2021 at 13:15, Mark Brown wrote: > > On Thu, Jun 03, 2021 at 12:20:57PM +0200, Ulf Hansson wrote: > > On Thu, 3 Jun 2021 at 11:34, Ulf Hansson wrote: > > > > Recent changes in genpd drops and restore performance state votes for > > > devices during runtime PM. > > > After a second thought, it looks like we maybe should defer to apply > > this final patch of the series. At least until we figured out how to > > address the below issue: > > > So, I noticed that we have things like "regulator-fixed-domain", that > > uses "required-opps" to enable/disable a regulator through the > > dev_pm_set_performance_state() interface. We likely don't want to drop > > the performance state internally in genpd when genpd_suspend_noirq() > > gets called, for the corresponding struct device for the regulator. > > > I guess if genpd should drop performance states like $subject patch > > suggest, we need some kind of additional coordination, that allows a > > subsystem/driver to inform genpd when it should avoid it. Or something > > along those lines. > > I'm not sure what you're looking for from me here - was there a concrete > question or somehing? Nope, not really, sorry if that was not clear. I just wanted to loop you in, as to make sure that we don't change something at the PM domain level, which may not fit well with the regulator implementation. Kind regards Uffe