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=-7.3 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,USER_AGENT_SANE_1 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 077A1C43216 for ; Thu, 19 Aug 2021 06:17:32 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id DB6D86112E for ; Thu, 19 Aug 2021 06:17:31 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230447AbhHSGSG (ORCPT ); Thu, 19 Aug 2021 02:18:06 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41452 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230263AbhHSGSF (ORCPT ); Thu, 19 Aug 2021 02:18:05 -0400 Received: from mail-pj1-x1029.google.com (mail-pj1-x1029.google.com [IPv6:2607:f8b0:4864:20::1029]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B94B5C06179A for ; Wed, 18 Aug 2021 23:17:29 -0700 (PDT) Received: by mail-pj1-x1029.google.com with SMTP id mq2-20020a17090b3802b0290178911d298bso4055628pjb.1 for ; Wed, 18 Aug 2021 23:17:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=Z7TQEkkTOfvT3y1VcK9cbeGmLxLBDuWce4oY9e31CIQ=; b=n8Z7pceL3Q1hHrYhRGbE2Ft6ysYoV2T29GwsgsIk5zym7iZcje0CXVg1jI36aNnFP1 wEt31EiA2dUBQwlv5rK6Pb4jBRjUZnVnX9lq3yYWlZnsAiqoC84b2+sIg5qRcoOEikt2 Bl5OLXFHBLycojOK68FIhPW3b2fskqhF3vr/eyYOYKdL7QspG0UOJAgIVnJ/rUe4LZFr 9Mx+8O2v0d2rHrH3yazUPQGMQQQiYdzhDIVBgB1HMOdlKqueyQlS0Pa++oE7KDNseaKY ZqQcskpZ4qIHBPun+Nz8BNcPrFRsCGUIgrdD9AWMNWaoX41LuxEow35zOBfD0rRFPHfn o2nQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=Z7TQEkkTOfvT3y1VcK9cbeGmLxLBDuWce4oY9e31CIQ=; b=R+gjGbq60BEsvZYoah9iYyQa89kLfo7XhCEjfUIzv69UjQujdgf0Hak7ml5QrQieJY xzUqJ8erxxKW1NDj5gPEeQfSh2yoJlyQ+UjTT7kJn+bWIeBWXhDEWnN4gTDhFTEA/EBa 9j+eXYow5Fvb6CLFhop+QbMJPZK514Ynoq/tGB85uBi1MkBRhLAt4yeL0nPy2Caeb4dY oFKxUJiiJLx7DSuf4wVKHbTO1PvC1gAr5J3Sa4UP520nC586+IVtv9k6H9i8Mb3Gt4Y5 7jerv9yFKVXk9qfN6IsLFDLxO5qjwQswDqvvbfWn/2PaZqeMZAu8CdgM8MZZSkQbt3xh SFow== X-Gm-Message-State: AOAM530MBMFtI7iNujnJDiGkgpTWhWkNgJ7XVeBUtgqZNszS3grk9uU4 iuGi0L5XP9zcBGFbEuccv84C3w== X-Google-Smtp-Source: ABdhPJwi8ECnFjz7ftlBUkQP1U01xvcbaFwYmCvSxRCVadF/ZCBCreA9Xq0KVJGpteNV1tSqbtF8Eg== X-Received: by 2002:a17:90a:ce88:: with SMTP id g8mr13456163pju.116.1629353849006; Wed, 18 Aug 2021 23:17:29 -0700 (PDT) Received: from localhost ([122.172.201.85]) by smtp.gmail.com with ESMTPSA id r18sm2222724pgk.54.2021.08.18.23.16.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 18 Aug 2021 23:16:53 -0700 (PDT) Date: Thu, 19 Aug 2021 11:46:17 +0530 From: Viresh Kumar To: Dmitry Osipenko Cc: Ulf Hansson , Thierry Reding , Jonathan Hunter , Viresh Kumar , Stephen Boyd , Peter De Schrijver , Mikko Perttunen , Peter Chen , Mark Brown , Lee Jones , Uwe =?utf-8?Q?Kleine-K=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 Subject: Re: [PATCH v8 01/34] opp: Add dev_pm_opp_sync() helper Message-ID: <20210819061617.r4kuqxafjstrv3kt@vireshk-i7> References: <20210818045307.4brb6cafkh3adjth@vireshk-i7> <080469b3-612b-3a34-86e5-7037a64de2fe@gmail.com> <20210818055849.ybfajzu75ecpdrbn@vireshk-i7> <20210818062723.dqamssfkf7lf7cf7@vireshk-i7> <20210818091417.dvlnsxlgybdsn76x@vireshk-i7> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: NeoMutt/20180716-391-311a52 Precedence: bulk List-ID: X-Mailing-List: linux-pwm@vger.kernel.org On 18-08-21, 18:55, Dmitry Osipenko wrote: > 18.08.2021 12:41, Ulf Hansson пишет: > > Either way gives the equal result. The new callback allows to remove the > 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. > 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. -- viresh