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=-3.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,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 28AD9C55179 for ; Thu, 5 Nov 2020 12:53:19 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id D625220867 for ; Thu, 5 Nov 2020 12:53:18 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="y6DX4cMU" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730535AbgKEMxR (ORCPT ); Thu, 5 Nov 2020 07:53:17 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57598 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730270AbgKEMxQ (ORCPT ); Thu, 5 Nov 2020 07:53:16 -0500 Received: from mail-ua1-x941.google.com (mail-ua1-x941.google.com [IPv6:2607:f8b0:4864:20::941]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7BF44C0613D3 for ; Thu, 5 Nov 2020 04:53:16 -0800 (PST) Received: by mail-ua1-x941.google.com with SMTP id t15so474838ual.6 for ; Thu, 05 Nov 2020 04:53:16 -0800 (PST) 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; bh=L6TCLuc1aSDhvBsEh/oyOKoJFVXSTFCOXAYW2AUTtHo=; b=y6DX4cMUVCgpxUKuGqoEligLjI7mP0FgyJ97c7sIUUHZxJlTwtRRakXekgH7YsuigB Na2QU2xZN4x2PfpN6omerSdhzPwwGn9bDYKeR2k6MuBaUl4m5dH4WWWTdnhpeJeXb0wO XSZFej4dNy5nb1iC9xr8tfwJeCBjFjlTzg4qI2DAs6FEDqJOv7dGIgx54zxdVZ6kpJNY qEEM8136+KYXcHo4ba8akOcRfEEQa2WPh8DybrHFK+sabZgBhMR36tCVRG83K7vH1cW2 +tAvD7+11Tiw9WmdBdchM838Ksuv8W7UHq8LoeYHHVZz9EZWz0CY4hFIKH9bgfZDnoHM MkFw== 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=L6TCLuc1aSDhvBsEh/oyOKoJFVXSTFCOXAYW2AUTtHo=; b=g1NuPgp7vMsHkpJ/7bgRRozq4qR+vqy4AUam6sB8zfmw1uHJKEb4vAocpGn8aVbHge 7/sbU6tT4sMQKNTd0DtLXpjxQRk40nOuyzVnM3l+3fw+nv1XVGBAG38iiOhMA0zUIB/E a729o53xVhXzAPVkDfvAGUlOa7TuMcHRE3Xru/2pAR6Z1YUGIkHpp9x1HfzKmYeyAVK1 653VXr30hu1LcbqLmcqLBITFjCi/b9gqi/MYgmEEX/6uujM5Q89kUxzQAtc0mwbrvgyI AN0ismGRZpOxlBqcn5+7nN9/3EEOCfIHaLgoOv+BbUTyp+8laRdbX3FwGp3L4bcVsZaO JqBw== X-Gm-Message-State: AOAM530m2KHXnX93eF++w001RFkvuOL9LXNpuuyaighi3PRlIA3IGMig a0R6D5oQduB1vOz9SplBcoU+bBv8uegBq93+hklRaw== X-Google-Smtp-Source: ABdhPJycxdGkrda5dU9htxc/OSwm7s+GQAoBTPW1YXOO/bE03Yfcq+QBohkR+LMOwjYHynIUz7nEwPk/k/ZMFVtVBnc= X-Received: by 2002:a9f:2f15:: with SMTP id x21mr833961uaj.104.1604580795669; Thu, 05 Nov 2020 04:53:15 -0800 (PST) MIME-Version: 1.0 References: <20201104234427.26477-1-digetx@gmail.com> <20201105100603.skrirm7uke4s2xyl@vireshk-i7> <20201105104009.oo4dc6a2gdcwduhk@vireshk-i7> <20201105111301.2hxfx2tnmf2saakp@vireshk-i7> In-Reply-To: <20201105111301.2hxfx2tnmf2saakp@vireshk-i7> From: Ulf Hansson Date: Thu, 5 Nov 2020 13:52:39 +0100 Message-ID: Subject: Re: [PATCH v1 00/30] Introduce core voltage scaling for NVIDIA Tegra20/30 SoCs To: Viresh Kumar Cc: Dmitry Osipenko , Thierry Reding , Jonathan Hunter , Alan Stern , Peter Chen , Mark Brown , Liam Girdwood , Adrian Hunter , Krzysztof Kozlowski , Greg Kroah-Hartman , Lee Jones , =?UTF-8?Q?Uwe_Kleine=2DK=C3=B6nig?= , Mauro Carvalho Chehab , Rob Herring , Marek Szyprowski , Peter Geis , Nicolas Chauvet , linux-samsung-soc , driverdevel , Linux USB List , linux-pwm@vger.kernel.org, "linux-mmc@vger.kernel.org" , Linux Kernel Mailing List , DTML , dri-devel , Linux Media Mailing List , linux-tegra Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On Thu, 5 Nov 2020 at 12:13, Viresh Kumar wrote: > > On 05-11-20, 11:56, Ulf Hansson wrote: > > On Thu, 5 Nov 2020 at 11:40, Viresh Kumar wrote: > > > Btw, how do we identify if it is a power domain or a regulator ? > > To be honest, I was a bit afraid and embarrassed to ask this question, > and was hoping people to make fun of me in return :) > > > Good question. It's not a crystal clear line in between them, I think. > > And I was relieved after reading this :) > > > A power domain to me, means that some part of a silicon (a group of > > controllers or just a single piece, for example) needs some kind of > > resource (typically a power rail) to be enabled to be functional, to > > start with. > > Isn't this what a part of regulator does as well ? i.e. > enabling/disabling of the regulator or power to a group of > controllers. It could, but it shouldn't. > > Over that the regulator does voltage/current scaling as well, which > normally the power domains don't do (though we did that in > performance-state case). > > > If there are operating points involved, that's also a > > clear indication to me, that it's not a regular regulator. > > Is there any example of that? I hope by OPP you meant both freq and > voltage here. I am not sure if I know of a case where a power domain > handles both of them. It may be both voltage and frequency - but in some cases only voltage. >From HW point of view, many ARM legacy platforms have power domains that work like this. As you know, the DVFS case has in many years not been solved in a generic way, but mostly via platform specific hacks. The worst ones are probably those hacking clock drivers (which myself also have contributed to). Have a look at clk_prcmu_opp_prepare(), for example, which is used by the UX500 platform. Another option has been to use the devfreq framework, but it has limitations in regards to this too. That said, I am hoping that people start moving towards the deploying/implementing DVFS through the power-domain approach, together with the OPPs. Maybe there are still some pieces missing from an infrastructure point of view, but that should become more evident as more starts using it. > > > Maybe we should try to specify this more exactly in some > > documentation, somewhere. > > I think yes, it is very much required. And in absence of that I think, > many (or most) of the platforms that also need to scale the voltage > would have modeled their hardware as a regulator and not a PM domain. > > What I always thought was: > > - Module that can just enable/disable power to a block of SoC is a > power domain. > > - Module that can enable/disable as well as scale voltage is a > regulator. > > And so I thought that this patchset has done the right thing. This > changed a bit with the qcom stuff where the IP to be configured was in > control of RPM and not Linux and so we couldn't add it as a regulator. > If it was controlled by Linux, it would have been a regulator in > kernel for sure :) In my view, DT bindings have consistently been pushed back during the year, if they have tried to model power domains as regulator supplies from consumer device nodes. Hence, people have tried other things, as I mentioned above. I definitely agree that we need to update some documentations, explaining things more exactly. Additionally, it seems like a talk at some conferences should make sense, as a way to spread the word. Kind regards Uffe