Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp965146pxb; Thu, 21 Oct 2021 12:59:27 -0700 (PDT) X-Google-Smtp-Source: ABdhPJymkiFNizJR6/dNo1oLUVeyxuby/KRPM+ZOmdPh+822ZFcTPYDNvxYlUVwlcV3yM0vAbnGB X-Received: by 2002:a05:6a00:a:b0:44d:249e:18ca with SMTP id h10-20020a056a00000a00b0044d249e18camr8128734pfk.46.1634846367220; Thu, 21 Oct 2021 12:59:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1634846367; cv=none; d=google.com; s=arc-20160816; b=J6o0hPNoAdlogNLjAgIa5HqTiiB6PxeJAJsy95fc/xsOrrbM7awi3BoY0gLfYiOXsM b5r3b8m+Eup4hmIK6IdGoESvfQAnGuEqSwGVNwilMCRyIS7HgFFC1Y/K/ymJ9czz3Ink LLRdy0wPoR+gNcySw6IBypw2nl/VMQwBbpOLS/+MUGHqYXb7iEEEBmeNXhI3/t29hJ6D sIY7O383NUl2OR3A2ilr/rZOnlRZtvxp7i5ngbrpp6rF9Euc9aWLo7ZJINIpA/4E2Y+y uHExmld2sRPXwFZRSCfUYxmXhwkXIH6Y+IIHFUNv6aPKiy+erC1p7wjeDKGn0oBpzdUX BnNQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=XyhoHE7sxv5I2EpYeVeJH0GIKfhcQY389jVe4IVPrso=; b=u1x3wgDyedo95QKJKwHkty196SjTMLpc2Pu3YorLVSzGKY8TMtLIn2vpYSNsU5dmXo aBfNPblq1rY2MCcc8abkLkhsABTrMHx5tag69ebVtw+BDssVi6PAZKdr5Fk3pJ9z3zgP 3M7R+JQ8wIYSxrV+ey8++W1OLDdBJHW3BPruGehOQRH+go/jPNDwW6IPvkXPjIFE1kXq 6i5pMNVAnpEIuCiL4GJqKHyV9WqhPaB6OqH8XzWsNBPlumPN+FeYnD3niHKEcL5jswiA lsOp8CLtZ/u0CboI+vUoqY70bc2bX+o4gm4ls1FPZcWe3rg/vhnFDRX3bTvSz+i4/fDZ E36Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=fajWtGHo; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id c21si8106049pls.149.2021.10.21.12.59.13; Thu, 21 Oct 2021 12:59:27 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=fajWtGHo; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231784AbhJUT7H (ORCPT + 99 others); Thu, 21 Oct 2021 15:59:07 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59220 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230272AbhJUT7H (ORCPT ); Thu, 21 Oct 2021 15:59:07 -0400 Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8A207C061764 for ; Thu, 21 Oct 2021 12:56:50 -0700 (PDT) Received: by mail-lj1-x22d.google.com with SMTP id q16so1317220ljg.3 for ; Thu, 21 Oct 2021 12:56:50 -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=XyhoHE7sxv5I2EpYeVeJH0GIKfhcQY389jVe4IVPrso=; b=fajWtGHos8khUlCJgvpdSRJD5xpYLZ79Lr2JBHTNmtUKS3cX8ZlnEwgx+1S9+b91Jx xIAREn1mxSFn3lWZ8eC1aaNnhKsBHvyNNoQ+ZiUYwMiFj7eI7DtbGZLrFQ02vjk/za3F n5tzxDxUgWk3TS0NL82gfmIRApn3g95CzMW5kDKCbySKWOQVGOt9dhMfgoFxouk8s7BQ qkozvuudgympgQiVJIv24nCREM9G4TUwGTPzhIHPk+OC0PFpvTzF1opal3pOXlKjd6dN odykl9GddCEXRQKtJkeeWO6tu8RB2ORt7/STAWx3OSx7MEjRK8DsroWwXJT31GCjIQTN zE5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=XyhoHE7sxv5I2EpYeVeJH0GIKfhcQY389jVe4IVPrso=; b=2ti+LcXSGnRTWEws7FWzDE6Y5QL9U8oF9T3gm9u404H1HE9VHppmHpHzz8muXtAo8i 9UUblobtHRGNN5FZRwMh6DPTij8Isfx+onWDI1s0gASoMUyZFQnNWRt69fTEW2RsMcV0 vZssAfODsjNW9IQy8X2wcDFilVIpND6YTIJz7yW+QZ4+rc18Qkm68GrPZ0w1NkDiCFtk 0omFjha5fF2Qz3rcD4swPZ9gCEnh7JCjnpsIFBFVIUrozEVgPPCki7C0g4IrXhUPsRUw gCYgHUgGvKusHNnmn3cONSw916X44oS4qWhU2l8t1CmcPd87ZrQZfRV3TAYX0DhrekCK 2qJw== X-Gm-Message-State: AOAM532C/iPDpS4f4nJicRPRhZ+kub7KRy6mKJIlrSjYLdu1//jbTFTV XbMeR7XCCS5XMe/oqukF+w7ZXWFawz7/FdayVgGeeQ== X-Received: by 2002:a2e:874d:: with SMTP id q13mr8133479ljj.16.1634846208850; Thu, 21 Oct 2021 12:56:48 -0700 (PDT) MIME-Version: 1.0 References: <20210929144451.113334-1-ulf.hansson@linaro.org> <20210929144451.113334-3-ulf.hansson@linaro.org> In-Reply-To: From: Ulf Hansson Date: Thu, 21 Oct 2021 21:56:12 +0200 Message-ID: Subject: Re: [PATCH 2/2] PM: sleep: Fix runtime PM based cpuidle support To: "Rafael J. Wysocki" Cc: Daniel Lezcano , Linux PM , Maulik Shah , Peter Zijlstra , Vincent Guittot , Len Brown , Bjorn Andersson , Linux ARM , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 21 Oct 2021 at 21:02, Rafael J. Wysocki wrote: > > On Thu, Oct 21, 2021 at 8:12 PM Ulf Hansson wrote: > > > > On Thu, 21 Oct 2021 at 18:33, Rafael J. Wysocki wrote: > > > > > > On Thu, Oct 21, 2021 at 6:17 PM Ulf Hansson wrote: > > [cut] > > > > So in theory you could check the pm_runtime_put_sync_suspend() return > > > value and fall back to something like WFI if that's an error code. > > > > I have already tried that, but it simply got too complicated. The main > > issue was that runtime PM could become disabled for the device in the > > middle of executing the ->enter() callback. > > So IIUC the problem is that you cannot resume after suspending in that case. > > IOW, you need to guarantee that if the suspend is successful, the > resume also will take place, but if the suspend fails, you basically > don't care. Exactly. > > > For example, if pm_runtime_get_sync() fails, I still need to make sure > > the reference counting in genpd becomes correct - and I can't do that > > using dev_pm_genpd_resume(). That's because it's not designed to be > > called in this "unknown" suspend phase, but should be called after the > > noirq phase and be properly balanced with dev_pm_genpd_suspend(). > > > > In other words, the error path didn't work out for me. > > It should be sufficient to call wake_up_all_idle_cpus() in the suspend > path before dpm_suspend_late(), because system suspend acquires a > PM-runtime reference on every device. IOW, it won't let any devices > runtime-suspend, so if your power domain devices are resumed in that > path, they will never suspend again in it and the > pm_runtime_put_sync_suspend() in __psci_enter_domain_idle_state() > becomes a reference counter management call which works regardless of > whether or not PM runtime is disabled. That sounds like a great idea, this should work too! Then the question is, how to make that call to wake_up_all_idle_cpus() to become optional - or only invoked for the cpuidle drivers that need it. In any case, I will try this out, thanks for the suggestion! Kind regards Uffe