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 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D081BC4321E for ; Fri, 1 Oct 2021 14:55:53 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id AFD0D61A0A for ; Fri, 1 Oct 2021 14:55:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1354683AbhJAO5g (ORCPT ); Fri, 1 Oct 2021 10:57:36 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60094 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1353560AbhJAO5d (ORCPT ); Fri, 1 Oct 2021 10:57:33 -0400 Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 50231C06177C for ; Fri, 1 Oct 2021 07:55:49 -0700 (PDT) Received: by mail-lf1-x130.google.com with SMTP id i25so39796306lfg.6 for ; Fri, 01 Oct 2021 07:55:49 -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:content-transfer-encoding; bh=HF8DBMItzWWxaU367RAPSYKUXH5BnlS9jAZczRe4ePU=; b=aqXBI8UqLDWeTuVHGIBErjDsxio9yrdPfisehV9T9mJJk+ppF2b/RSy8QKzqoblHaJ hktrYJaeXtvLqskrzNnGhVJzexc6aEdc98fBbQvK69Gb12EAMd3ESJqlkrS5oD7OvNgG P97muReS34kLGu9NjHY+j5dwj2WyCWNHYTaed7xbvTrI2JzTGDs8qi8N0Qw7LkdjcWZX LXXkcViUSEK9vm+haTULi+cNSHJvU7ahpKWlcRMN7cX+R5RpA0/f3OUd7Bkg7+NCE+Fi 1p1K49QgqzjgYEL1VL7M/h/E3btzs6Z5y5Av95Pp0dtJLF67v2p4aNsixGXoHBfrryKU UTgw== 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:content-transfer-encoding; bh=HF8DBMItzWWxaU367RAPSYKUXH5BnlS9jAZczRe4ePU=; b=UOh+on5RI+b3TmDNf+2+sioGIrQagsskvNvkwFXrjku9c6MzSvyNMo2bBQemkXzkzl 4yjVEbYk3rQCy48tHKZKR/YeS+EGmJC+Mn1Fhzdn7yWq7w51YESYDmHXEnIp9epNjI/f dVqrFF5CB28tJlpefzlkRZ6zHcBMuWrORrf9TnOJNvOhKTVTe2FLefQTo+WXzA4ytzNz tMv+LCPNNSPTPvzAI1fE6pkYpIzg65qRUIK3GRnYXF+WyvJLhW2zFzhLX0ugwsN8U0xB rrfaI2dUgxr9TnAe64i8V7U1dF32hUeurraAfFHoNg6GmBiiX3u3+kXh3CE61ehSC6ES 9uCw== X-Gm-Message-State: AOAM533vyVmRnhhIBUauvpQPtQIcA1U24hfH4PqXDXTKb6/NpUHELeqK VsDKeegwJhB4z170y2PpvYLMlBYUQf2NDah0PBL0mA== X-Google-Smtp-Source: ABdhPJy2ug8Cm3POxLOQxU+SWQ8ZDieYeZsYoVZxo62Idbb6vc9hck4xUmbalsRsefa0nQdQjDMqTs5I8HVxPDG4gAE= X-Received: by 2002:a05:6512:3095:: with SMTP id z21mr5935006lfd.167.1633100147608; Fri, 01 Oct 2021 07:55:47 -0700 (PDT) MIME-Version: 1.0 References: <20210926224058.1252-1-digetx@gmail.com> <20210926224058.1252-14-digetx@gmail.com> In-Reply-To: From: Ulf Hansson Date: Fri, 1 Oct 2021 16:55:11 +0200 Message-ID: Subject: Re: [PATCH v13 13/35] drm/tegra: gr2d: Support generic power domain and runtime PM To: Dmitry Osipenko Cc: Thierry Reding , Jonathan Hunter , Viresh Kumar , Stephen Boyd , Peter De Schrijver , Mikko Perttunen , Peter Chen , Lee Jones , =?UTF-8?Q?Uwe_Kleine=2DK=C3=B6nig?= , Nishanth Menon , Adrian Hunter , Michael Turquette , Linux Kernel Mailing List , linux-tegra , Linux PM , Linux USB List , linux-staging@lists.linux.dev, linux-pwm@vger.kernel.org, linux-mmc , dri-devel , DTML , linux-clk , Mark Brown , Vignesh Raghavendra , Richard Weinberger , Miquel Raynal , Lucas Stach , Stefan Agner , Mauro Carvalho Chehab , David Heidelberg Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 1 Oct 2021 at 16:29, Dmitry Osipenko wrote: > > 01.10.2021 16:39, Ulf Hansson =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > > On Mon, 27 Sept 2021 at 00:42, Dmitry Osipenko wrote= : > >> > >> Add runtime power management and support generic power domains. > >> > >> Tested-by: Peter Geis # Ouya T30 > >> Tested-by: Paul Fertser # PAZ00 T20 > >> Tested-by: Nicolas Chauvet # PAZ00 T20 and TK1 T12= 4 > >> Tested-by: Matt Merhar # Ouya T30 > >> Signed-off-by: Dmitry Osipenko > >> --- > >> drivers/gpu/drm/tegra/gr2d.c | 155 +++++++++++++++++++++++++++++++++-= - > > > > [...] > > > >> static int gr2d_remove(struct platform_device *pdev) > >> @@ -259,15 +312,101 @@ static int gr2d_remove(struct platform_device *= pdev) > >> return err; > >> } > >> > >> + pm_runtime_dont_use_autosuspend(&pdev->dev); > >> + pm_runtime_disable(&pdev->dev); > > > > There is no guarantee that the ->runtime_suspend() has been invoked > > here, which means that clock may be left prepared/enabled beyond this > > point. > > > > I suggest you call pm_runtime_force_suspend(), instead of > > pm_runtime_disable(), to make sure that gets done. > > The pm_runtime_disable() performs the final synchronization, please see [= 1]. > > [1] > https://elixir.bootlin.com/linux/v5.15-rc3/source/drivers/base/power/runt= ime.c#L1412 pm_runtime_disable() end up calling _pm_runtime_barrier(), which calls cancel_work_sync() if dev->power.request_pending has been set. If the work that was punted to the pm_wq in rpm_idle() has not been started yet, we end up just canceling it. In other words, there are no guarantees it runs to completion. Moreover, use space may have bumped the usage count via sysfs for the device (pm_runtime_forbid()) to keep the device runtime resumed. > > Calling pm_runtime_force_suspend() isn't correct because each 'enable' > must have the corresponding 'disable'. Hence there is no problem here. pm_runtime_force_suspend() calls pm_runtime_disable(), so I think that should be fine. No? Kind regards Uffe