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=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS 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 F3114C00144 for ; Thu, 19 Aug 2021 14:55:56 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id DDBEB600CC for ; Thu, 19 Aug 2021 14:55:56 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240670AbhHSO4c (ORCPT ); Thu, 19 Aug 2021 10:56:32 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49558 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240653AbhHSO4b (ORCPT ); Thu, 19 Aug 2021 10:56:31 -0400 Received: from mail-vs1-xe2d.google.com (mail-vs1-xe2d.google.com [IPv6:2607:f8b0:4864:20::e2d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B9556C06179A for ; Thu, 19 Aug 2021 07:55:54 -0700 (PDT) Received: by mail-vs1-xe2d.google.com with SMTP id k24so4177962vsg.9 for ; Thu, 19 Aug 2021 07:55:54 -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=mm8paTdT0zaztfhC5Y4WPaOBPl8kLHQHgl7pXYxX3h4=; b=qeDfX1TvtXFpaue7XSJcQGoXvoEPk6keQ3SefhHQYD/RQYSwXL/h7/nJ1tE1n2ZgGf hgNQdBuev8q9YdqAn31QqEn+hl0Fw8o/I7j+pKewMg7BSKDExUMcgAG5ffW6TnVBaweA awPBlmbVNdD0YyJLl/fecYVhU7UH2GjQaH+G3BKTeEFH67xcFXuuVoODzKyHu4OljnuW y3YyyagNQ7/VVdr8UoQMvH7lyjCnnH9zaDfJmZrMJYrsb5yu8bZTEWP6ZCkq4ndYtqKT KiXhZrvSOf9kLkVqOyobXMYfdScN3zuV6Y2fafpateAUvd8nG8k5/FLAhRgrUffP4ZSX UqPQ== 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:content-transfer-encoding; bh=mm8paTdT0zaztfhC5Y4WPaOBPl8kLHQHgl7pXYxX3h4=; b=m7Mub9JzOp842FkBjCIn7JLjCZj4AY3QO1cqmq0hvsQE6yUL1vMXwleKiYeVpqCIKM EhB6NyzVTBZAVdc7WxmEK6MjJUSiHsvfMKlG1QEjtbxn0FwW9yDVUA0cZ48XlQWbw3Vr is6cCxqC0HRD4ZgbUrUP2VzoO0pOEEyur6vsR15HKw6T4kCP0UaS2abYP1lYGkI/iEJA V1+uJDy2orioK26kqCajlhDXmeRklj/ep2/TSsYiYVVVVARr6USLgwYuPpjnCnIu+/83 wG/6pD96oYG1Nhjvuu/HDWRDUg8jhW1vS5PxkJcWVBqBEH0fD2D8tGrmlWILNmppW+AN cwPQ== X-Gm-Message-State: AOAM5314BmrC9hYQr2lC9fkXpqdb4fhFVWB4jc2jsW+sYq0gs2iI2RcD v6jHzxUPArTphg801GDNXVX3PbRGnRuQXJSR/aaHnQ== X-Google-Smtp-Source: ABdhPJy9lhlHe3ZkjkK69gRHTqfsYZUpyU/u1QO9GNutRCvh27kC0oDOl0UN2vIh0G0BbPGuh3RFsxVqGIQ9yFmBme8= X-Received: by 2002:a67:f6d8:: with SMTP id v24mr12929204vso.48.1629384953702; Thu, 19 Aug 2021 07:55:53 -0700 (PDT) MIME-Version: 1.0 References: <20210818045307.4brb6cafkh3adjth@vireshk-i7> <080469b3-612b-3a34-86e5-7037a64de2fe@gmail.com> <20210818055849.ybfajzu75ecpdrbn@vireshk-i7> <20210818062723.dqamssfkf7lf7cf7@vireshk-i7> <20210818091417.dvlnsxlgybdsn76x@vireshk-i7> <20210819061617.r4kuqxafjstrv3kt@vireshk-i7> In-Reply-To: <20210819061617.r4kuqxafjstrv3kt@vireshk-i7> From: Ulf Hansson Date: Thu, 19 Aug 2021 16:55:16 +0200 Message-ID: Subject: Re: [PATCH v8 01/34] opp: Add dev_pm_opp_sync() helper To: Viresh Kumar Cc: Dmitry Osipenko , Thierry Reding , Jonathan Hunter , Viresh Kumar , Stephen Boyd , Peter De Schrijver , Mikko Perttunen , Peter Chen , Mark Brown , Lee Jones , =?UTF-8?Q?Uwe_Kleine=2DK=C3=B6nig?= , Nishanth Menon , Vignesh Raghavendra , Richard Weinberger , Miquel Raynal , Lucas Stach , Stefan Agner , Adrian Hunter , Mauro Carvalho Chehab , Rob Herring , Michael Turquette , Linux Kernel Mailing List , linux-tegra , Linux PM , Linux USB List , linux-staging@lists.linux.dev, linux-spi@vger.kernel.org, linux-pwm@vger.kernel.org, linux-mtd@lists.infradead.org, linux-mmc , Linux Media Mailing List , dri-devel , DTML , linux-clk Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-pwm@vger.kernel.org On Thu, 19 Aug 2021 at 08:17, Viresh Kumar wrote: > > On 18-08-21, 18:55, Dmitry Osipenko wrote: > > 18.08.2021 12:41, Ulf Hansson =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > > > > Either way gives the equal result. The new callback allows to remove th= e > > boilerplate dev_pm_opp_set_rate(clk_get_rate() code from the rpm-resume > > of consumer devices, that's it. > > It may not be equal, as dev_pm_opp_set_rate() may do additional stuff, > now or in a later implementation. Currently it only does > regulator_enable() as a special case, but it can be clk_enable() as > well. Also, this tries to solve the problem in a tricky/hacky way, > while all you wanted was to make the genpd aware of what the > performance state should be. > > Your driver can break tomorrow if we started to do more stuff from > this API at another time. > > > > dev_pm_opp_set_rate() is best called from consumer drivers, as they > > > need to be in control. > > >> What we need here is just configure. So something like this then: > > The intent wasn't to use dev_pm_opp_set_rate() from > > __genpd_dev_pm_attach(), but to set genpd->rpm_pstate in accordance to > > the h/w configuration. > > Right. > > > On Tegra we have a chain of PDs and it's not trivial to convert the > > device's OPP into pstate because only the parent domain can translate > > the required OPP. > > The driver should just be required to make a call, and OPP/genpd core > should return it a value. This is already done today while setting the > pstate for a device. The same frameworks must be able to supply a > value to be used for the device. Right, that sounds reasonable. We already have pm_genpd_opp_to_performance_state() which translates an OPP to a performance state. This function invokes the ->opp_to_performance_state() for a genpd. Maybe we need to allow a genpd to not have ->opp_to_performance_state() callback assigned though, but continue up in the hierarchy to see if the parent has the callback assigned, to make this work for Tegra? Perhaps we should add an API dev_pm_genpd_opp_to_performance_state(), allowing us to pass the device instead of the genpd. But that's a minor thing. Finally, the precondition to use the above, is to first get a handle to an OPP table. This is where I am struggling to find a generic solution, because I guess that would be platform or even consumer driver specific for how to do this. And at what point should we do this? > > > Viresh, please take a look at what I did in [1]. Maybe it could be done > > in another way. > > I looked into this and looked like too much trouble. The > implementation needs to be simple. I am not sure I understand all the > problems you faced while doing that, would be better to start with a > simpler implementation of get_performance_state() kind of API for > genpd, after the domain is attached and its OPP table is initialized. > > Note, that the OPP table isn't required to be fully initialized for > the device at this point, we can parse the DT as well if needed be. Sure, but as I indicated above, you need some kind of input data to figure out what OPP table to pick, before you can translate that into a performance state. Is that always the clock rate, for example? Perhaps, we should start with adding a dev_pm_opp_get_from_rate() or what do you think? Do you have other suggestions? > > -- > viresh Kind regards Uffe