Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp1642249pxb; Fri, 22 Oct 2021 05:07:37 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyvKF4S2mv51um0XCUeflIOYWRyCkBXp9Ti/l+jVk3nKQzHv26qtW9U1QMqwid8uLIkPYzB X-Received: by 2002:adf:ca10:: with SMTP id o16mr14837961wrh.212.1634904457440; Fri, 22 Oct 2021 05:07:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1634904457; cv=none; d=google.com; s=arc-20160816; b=dp+074xBcyg2w6f2tZngUcvklz86mZ6M+eIppDPHf8tqOAX0cK0iTJamiSBFDnxoXy PdGokxV0hYGqEp1GMldPiCxDVUN5rSRUe4pqzKVPzUKre1lEo3ewSgpr4Izbl/i/Vl6j JDmUeJb34S4vQ5dj8P2Q2q8sIQcUOOOcAK8IDcef7M65MQgSX9txHhjF8q2iGUjRL0ro 2WYpRowyKHM9ToTXsg3T2k2NLDitAbDidcEsYpJkbRO2geRNq3wU9+6htxxh/UfSGlgr mDJ+mWvdX7Lko0Sshu84yyTvjI/tPYnj9Hbti3x+pleCKLdmag7wEGHiIojm49HPnxkT Q2tw== 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; bh=vb9ybLLtVGcasBUj4S63VDy6H8luqutt3xdc3pcVq78=; b=GlxKlnmeqT/ZbTbFYB/yPDPXuFQGYs8G/oVSAhIty2Q/iPOG3s0+0xllqRvThLmAAL QCKx67TCjZaR5yDxUgRwsR/tppmZH1d32aIg4Ea2WvBzjKCf62eMhiNcAHbvV/wbfRRI RFq+pqmxH5Vi9Sypl9qAs3FXnFehiYkGqzwR0V+JP//SuzpemPfVnb9aIguR3SUjARBn 1qier++llstPOONYSUutW7K7a/5nF0wOL57VLjkBnjuCXhLGwr2H1zcI8S/I3a21xzfR 84qGHGztbI1213Ps7r4l2ClCcAHfWUIo7Lec2rwwq9bC6ycmaf4jR7bozItce4Rf+TAO jz7A== ARC-Authentication-Results: i=1; mx.google.com; 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=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id b6si13154415edu.126.2021.10.22.05.07.08; Fri, 22 Oct 2021 05:07:37 -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; 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=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230361AbhJVMFD (ORCPT + 99 others); Fri, 22 Oct 2021 08:05:03 -0400 Received: from mail-oo1-f48.google.com ([209.85.161.48]:43996 "EHLO mail-oo1-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229842AbhJVMFA (ORCPT ); Fri, 22 Oct 2021 08:05:00 -0400 Received: by mail-oo1-f48.google.com with SMTP id w9-20020a4adec9000000b002b696945457so1023536oou.10; Fri, 22 Oct 2021 05:02:43 -0700 (PDT) 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=vb9ybLLtVGcasBUj4S63VDy6H8luqutt3xdc3pcVq78=; b=UEpZtu21xQtqkFTmMcZWibEgJLgSS/fh8FRHJ/kSBQcU1CCbuFt8Myv6NbO2xP+ZEX LqUGDeeXROQWhF++JKuXwZ4DsP6PNIGJcByvSq3LUZESQIhYbBJYOEDSsZEBBZZ0yA4f 728i8Ftj6+rCq93yUl9zxUFTh67/5Np3TPiVb/0GS89Y1jIUyVQBXwoEQfvKS1uOPRJD PWkwlr5S6BUrhSqHkehL79wuSrXJHUO3/qSx+xqFF1aGcnYEP66ZhPMbzTf9yUlQJ9AF 3IdaECHmd5LNXNfq6kfiek2gY759s8dhzdysKN5alW5XFnofZprtXXy1lB3RcC3+xb4s PSqQ== X-Gm-Message-State: AOAM531R4gLAdG77YfqB2FfoDIu7aGyUS9NbrXhGrle6lD1dQguUiCSY elshwB+hxfUQc3bGPajCyx5s/NbSp9jyyWMn1iE= X-Received: by 2002:a05:6820:54e:: with SMTP id n14mr8926037ooj.89.1634904163022; Fri, 22 Oct 2021 05:02:43 -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: "Rafael J. Wysocki" Date: Fri, 22 Oct 2021 14:02:26 +0200 Message-ID: Subject: Re: [PATCH 2/2] PM: sleep: Fix runtime PM based cpuidle support To: Ulf Hansson Cc: "Rafael J. Wysocki" , 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 Fri, Oct 22, 2021 at 12:18 PM Ulf Hansson wrote: > > On Thu, 21 Oct 2021 at 21:56, Ulf Hansson wrote: > > > > 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. It need not be optional. For suspend-to-idle it doesn't matter, because all CPUs will be woken up from idle shortly anyway. For other suspend variants this doesn't matter, because all secondary CPUs will be taken offline shortly and the primary CPU will call into the platform "sleep" handler. > > > > In any case, I will try this out, thanks for the suggestion! > > I now recall that I have already tried this, but unfortunately it doesn't work. > > The problem is that the dev->power.syscore flag is set for the device, > which makes device_prepare() to bail out early and skip calling > pm_runtime_get_noresume(). This needs to be fixed, then.