Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp1508108pxb; Fri, 22 Oct 2021 02:17:00 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyv9wl2Sa5Ti4xNc7vraxaqT7MgQhpImc1Nt4EQd4Kl8UQ4YpIUXsk5ksesALMFW0X2RDtG X-Received: by 2002:a17:90b:380d:: with SMTP id mq13mr12975949pjb.131.1634894220632; Fri, 22 Oct 2021 02:17:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1634894220; cv=none; d=google.com; s=arc-20160816; b=AaUad6AackIOZ0jgxNBLPfZHttUECj8lezc76Rj6Nfrq1qb1yqmphKyIINiGK5C660 msRrlPBb0Ne9W5DM35CLGiM5LvoEf8EKdIlpptS3TDCBeZ9921ogH4j4e6jSyizpWJI3 CLnbyztUUhOBpfdjMGZyQdbinKmhFPMRxewM3yNFeEo2Y1ilKmwwUf4X0YVeT/sde4Ow cHbTw6wMuORw9S43SobXmmep3v0eaQEAyvOQWffWFGWsKBmPx6lDsppwE02GFdrprJrk PI2qBgslqyQq04lz5r45UqPnPrYSbftw7KLa9pjWGrODL1FT2ZD4HgJrXq58RLHhTsWx W/FA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject:dmarc-filter:sender:dkim-signature; bh=uQr8BvZjWmmKxBH750LS9eoWoqnWOCF3cqNu/hoRFm4=; b=c8x83RaY8RE16PueuimlGk9Att4vfuxsxZ037SG9Voi85wiVBjReM1Hwo0w68/WBCG b634oPnQj7kowWpb1HHEq+ZmkPboj/5IARkRZ0Sf0dJub35ZVqaN00mzY89GfGpzs8kI KMTIF+l421xwqPjJ4mVX4LbZaQSqVb7DjnLSTXW+cNNziwMXU0ouQjCBj2YF0zkx0/tX VJXAckUqfqV6sOelXG/92NQFBLdpFqxrXXUWw0rdrZ1y5JZw5Gsm9MouZbm/jR1cKAf8 VkDWwC6GLake0aDwagibv/UDkco1L3VGyrwuCeOVe+Vv/OofjrgTme1IlfAZAYm2OWCJ 1BGw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@mg.codeaurora.org header.s=smtp header.b=kYPI9j5M; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id l19si11444493pfu.149.2021.10.22.02.16.47; Fri, 22 Oct 2021 02:17:00 -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=@mg.codeaurora.org header.s=smtp header.b=kYPI9j5M; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232514AbhJVJRi (ORCPT + 99 others); Fri, 22 Oct 2021 05:17:38 -0400 Received: from so254-9.mailgun.net ([198.61.254.9]:54314 "EHLO so254-9.mailgun.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232527AbhJVJRh (ORCPT ); Fri, 22 Oct 2021 05:17:37 -0400 DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=mg.codeaurora.org; q=dns/txt; s=smtp; t=1634894120; h=Content-Transfer-Encoding: Content-Type: In-Reply-To: MIME-Version: Date: Message-ID: From: References: Cc: To: Subject: Sender; bh=uQr8BvZjWmmKxBH750LS9eoWoqnWOCF3cqNu/hoRFm4=; b=kYPI9j5Mqi1ijfdAk6OlFKxiakauBX7sQHSuIgNeuO12nXCfiALiSK1JGCwJVhjcKL1E67wh OCDs1/+rj09nD0bWSCx3i4HC2PEDtZo4+JldnA0xc6zh+dCPWcP5mP23WJBvbdPAo7zRUbXg Zexjp85Mov0z3n4o5aG8A2iXYAI= X-Mailgun-Sending-Ip: 198.61.254.9 X-Mailgun-Sid: WyI0MWYwYSIsICJsaW51eC1rZXJuZWxAdmdlci5rZXJuZWwub3JnIiwgImJlOWU0YSJd Received: from smtp.codeaurora.org (ec2-35-166-182-171.us-west-2.compute.amazonaws.com [35.166.182.171]) by smtp-out-n06.prod.us-east-1.postgun.com with SMTP id 6172812314914866fa7834c1 (version=TLS1.2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256); Fri, 22 Oct 2021 09:15:15 GMT Sender: mkshah=codeaurora.org@mg.codeaurora.org Received: by smtp.codeaurora.org (Postfix, from userid 1001) id DF800C43619; Fri, 22 Oct 2021 09:15:14 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-caf-mail-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.6 required=2.0 tests=ALL_TRUSTED,BAYES_00, NICE_REPLY_A,SPF_FAIL,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from [192.168.43.137] (unknown [27.61.247.193]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mkshah) by smtp.codeaurora.org (Postfix) with ESMTPSA id 3E390C4338F; Fri, 22 Oct 2021 09:15:09 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 smtp.codeaurora.org 3E390C4338F 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=codeaurora.org Subject: Re: [PATCH 2/2] PM: sleep: Fix runtime PM based cpuidle support To: Ulf Hansson , "Rafael J. Wysocki" Cc: Daniel Lezcano , Linux PM , Peter Zijlstra , Vincent Guittot , Len Brown , Bjorn Andersson , Linux ARM , Linux Kernel Mailing List References: <20210929144451.113334-1-ulf.hansson@linaro.org> <20210929144451.113334-3-ulf.hansson@linaro.org> From: Maulik Shah Message-ID: <28b0c55c-aa3e-8956-7be3-594e7b340107@codeaurora.org> Date: Fri, 22 Oct 2021 14:45:06 +0530 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On 10/22/2021 1:26 AM, 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. > > In any case, I will try this out, thanks for the suggestion! > > Kind regards > Uffe This may not work given that CPUs may re-enter idle after call to wake_up_all_idle_cpus() is finished. say a case where, 1. wake_up_all_idle_cpus() is called first then 2. __device_suspend_late() does __pm_runtime_disable() for all CPU devices. inbetween 1 and 2, CPUs may have entered idle again and would have done pm_runtime_put_sync_suspend() while entering idle from cpuidle-psci. I was thinking if PM-QoS may be of help here, before runtime PM is disabled, if QoS is taken with less value (say 1us) then all CPUs will wake up to serve the QoS and then stay in simple WFI() due to QoS and won't do any runtime put/get, which serve similar to cpuidle_pause() + default idle call. if QoS can be somehow taken from cpuidle-psci driver registering for suspend ops? it won't effect other archs/idle drivers. Thanks, Maulik > -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation