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=-4.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,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 EB1FDC55178 for ; Thu, 5 Nov 2020 17:42:34 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 8B6F820709 for ; Thu, 5 Nov 2020 17:42:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1604598154; bh=RsDQV1h3v+QR+nJVsOOAKQRY7siph12863Hmx7NzMy4=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-ID:From; b=ceDiRxQP86p2YZsxZItTK8QZv1xAURArZJS1ToWbQmSo/Jt72feee+HboFz5iPhlh E7z9Et7mtvo6kuvDdD6E0bgOar4nMErxQQ0QKEXxefkpTedUpy9e4juK3s0xPp9g4S Yf2tAPSqhWlVtFYo4mk3mQ4Or0N9M0rgs9vEvrAI= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731731AbgKERmd (ORCPT ); Thu, 5 Nov 2020 12:42:33 -0500 Received: from mail-oi1-f195.google.com ([209.85.167.195]:36562 "EHLO mail-oi1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726214AbgKERmd (ORCPT ); Thu, 5 Nov 2020 12:42:33 -0500 Received: by mail-oi1-f195.google.com with SMTP id d9so2530863oib.3; Thu, 05 Nov 2020 09:42:32 -0800 (PST) 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=RsDQV1h3v+QR+nJVsOOAKQRY7siph12863Hmx7NzMy4=; b=jCMxFvfOKHrSyhxnzrtw4IWrQp3H82JSgITimRpV+OVBzDpixbpPyZkueE0yO2S9YT 6fgZnC0djuykU70M0AlqeRBgksZGFkrsV2FRG4inLGgDsY2mvlfvOgrCxIBu0oZlAOxi aP1qCV63WteMPJRCgs9clpQD6xKRYkYhhbzHoTvJGLOVb+HpuXQhSL2RP79lVR0CoRM2 8CIJ3/6wy7vEJ2jbtimTCgWCxgGcXuSvLXhVeUc7J8fnqntH0CRgvslfYJLQNDxIXBUm Nya+oTPrryzroG5gBS8NTComKY3ow8PpEKUVHk8kfUCbxqjrnsTn/7fOkb7x+abUKJp5 NCLw== X-Gm-Message-State: AOAM530OIhQv6E6br6zLi3g7arodr1CeE3GrWuzi5XEogpfEGvzTIhLi jcOnuo/KeQBd2Fhpu6NlcUrnz27QeBBy6Zw1FtQ3uiCr X-Google-Smtp-Source: ABdhPJxFMtYdKzx2PpH20eL8m0AO+NQuRxEz8f/hfqFfPFW+kP9XJQbsjdnbm126mHFRwytDq2Or7OZhFLuDEkrBWh8= X-Received: by 2002:aca:30d7:: with SMTP id w206mr347615oiw.69.1604598152198; Thu, 05 Nov 2020 09:42:32 -0800 (PST) MIME-Version: 1.0 References: <20201007001934.18606-1-stanimir.varbanov@linaro.org> In-Reply-To: From: "Rafael J. Wysocki" Date: Thu, 5 Nov 2020 18:42:20 +0100 Message-ID: Subject: Re: [PATCH] PM: runtime: Use pmruntime sync variant to put suppliers To: Stanimir Varbanov Cc: "Rafael J. Wysocki" , Linux PM , Linux Kernel Mailing List , "Rafael J . Wysocki" Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Oct 8, 2020 at 3:08 AM Stanimir Varbanov wrote: > > Hi Rafael, > > On 10/7/20 5:37 PM, Rafael J. Wysocki wrote: > > On Wed, Oct 7, 2020 at 2:20 AM Stanimir Varbanov > > wrote: > >> > >> Calling pm_runtime_put_sync over a device with suppliers with device > >> link flags PM_RUNTIME | RPM_ACTIVE it is observed that the supplier > >> is not put (turned off) at the end, but instead put asynchronously. > > > > Yes, that's by design. > > > >> In some case This could lead to issues for the callers which expects > >> that the pmruntime sync variants should also put the suppliers > >> synchronously. > > > > Why would anyone expect that to happen? > > It is logical to me that when I call pm_runtime_put_sync the device and > its suppliers are put synchronously. If I want to put device and its > suppliers asynchronously I'd use pm_runtime_put. Is that wrong assumption? The handling of suppliers is analogous to the handling of parents and the parents are suspended asynchronously when a child suspends. The difference between _put() and _put_sync() only applies to the device passed in as the argument. > >> Also the opposite rpm_get_suppliers is already using pmruntime _sync > >> variant of the API. > > > > Yes, it does, because that is necessary. > > > >> Correct this by changing pmruntime_put to pmruntime_put_sync in > >> rpm_put_suppliers. > > > > It is not a correction, but a change in behavior without good enough > > rationale, as it stands. > > In my driver case I want to deal with a recovery of a crash in remote > processor (the remote processor is used to control and program hardware > blocks and also to communicate with host processor through shared > memory). To restart the remote processor I have to disable clocks and > turn off few power domains (one of the power domains is made a supplier > of my main device) in order to complete the cold-boot. PM-runtime doesn't guarantee you the behavior that you'd like to see here. > The problem I'm facing with this design is that when I call > runtime_put_sync (to disable device's clocks and turn off power domain) > the clocks are disabled (part of pmruntime_suspend callback) but the > pmdomain (the device supplier) is not turned synchronously. I workaround > this by checking the supplier device via pm_runtime_active() until it > becomes inactive and the continue with rest of the steps. This is not a use case for PM-runtime at all. PM-runtime is all about going low-power opportunistically, whereas you want to enforce power down. > From my point of view this check for supplier activity should be part of > pmruntime API. But the API is not what you should be using for this purpose in the first place.