Received: by 2002:a05:6a10:16a7:0:0:0:0 with SMTP id gp39csp460966pxb; Thu, 5 Nov 2020 04:57:07 -0800 (PST) X-Google-Smtp-Source: ABdhPJzi1XjGAIK3SNXm8mfs4M51p8xINRWBNLIvhNZZT1LxShMJ8OmwVZqp9W+cEqZaMxQxqPD2 X-Received: by 2002:a17:906:12c1:: with SMTP id l1mr2031227ejb.528.1604581027616; Thu, 05 Nov 2020 04:57:07 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1604581027; cv=none; d=google.com; s=arc-20160816; b=nVMTdkaQvIuAskC1/avgRCbv+lRPCOG/uvO7jd20ziJOoG+9/0dqtSxJpmojOjbCpI En2LMGnLyIunMHiMDDw1YEcheV6/UP7wxSNVQ3cX0DpESNBFVbSdTehAb6pZzQXqQ+j4 7j5/dL8kEYIZ/h3WCtMqRw3lFlDzFD0zIoQZJZ7/NCqVNl/g0sMxo7INKdwWv8wyEPhq JkunnDzLaEPSMN6aH/aiwZajB7ooaTPhmI4/E/qGLDeHJEzt96k3hei4Q+EGrMMkvx5w NJDoT2bJOZP1gsgz3ll6OavuF3bMtyqlmJk4jL9nYPomflAjrnGvoWRWypqBtffjGBXZ s4xA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=L6TCLuc1aSDhvBsEh/oyOKoJFVXSTFCOXAYW2AUTtHo=; b=qhgY4/cVb4cCJncwzJVGZAUaeKeZAmF1PalPcmJ02hkpcMJjERpx27K6Hs878UwCJt ofWfr6hZq4ZFk9HL9k5Yk4hQrlifxxMLHSu7T6khZoDy3WiO090qdWT8WS23j8Ii02m/ Te/xnuTaM+33AqLOMd8GLJc8xcMIlNzt4a2/GA0+a0xz0CeBaqR85vb+ZHH+zOJ1GXmc oLGaR60oZL/5btZ7GOyDaEl49zFckln9SQel5DBPXKD9YCglXtCPV78wUGlfyAAL4KRv MMSVAxwbGszlTHTUrqjVu6jDT9UlKpIREGZhv204gMIESnnNz2X/6fQSzcufG2Wkjipx VXhg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=y6DX4cMU; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id b20si1035803edv.300.2020.11.05.04.56.44; Thu, 05 Nov 2020 04:57:07 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=y6DX4cMU; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730617AbgKEMxT (ORCPT + 99 others); Thu, 5 Nov 2020 07:53:19 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57596 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730270AbgKEMxS (ORCPT ); Thu, 5 Nov 2020 07:53:18 -0500 Received: from mail-ua1-x943.google.com (mail-ua1-x943.google.com [IPv6:2607:f8b0:4864:20::943]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7BD89C0613D2 for ; Thu, 5 Nov 2020 04:53:16 -0800 (PST) Received: by mail-ua1-x943.google.com with SMTP id v16so281593uat.9 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=DpLVNb6FhHhCvVDGBjR3LwoBzEmr+prBUaOH0wjt+yQMp6ViIIIqrB1skOkFzjPmNo m4j4wsj6e4n9IHC6AtI7Y0mjxe0nNNkcLqRR4ETIv1hyLbIFdiaxJwMbB5xfnmHQpjiP nSM7TU83bODK4lmj4CL5NY1ZaN7kk5vTeQTwXzA1gKUg/HP3BFhfBO77T6Gto4CRxESi VVggJAA6UZyxtaNl1aos71wYterWpht8VSfEj2q9fHmStW5tEEkSfx9hEG3hD8BPw9/n CBoHxMRBjNbWwL8hRClozjLlS2qdngV20ipJCUKXZyOfjmBOuAuvtb9iJCYtFGMQpAPp W5xQ== X-Gm-Message-State: AOAM532L53NK3i4ME0eZ++EAZIj/MpNzunA7CGMgHOuV4bbsLVIYpNHy FBzbDLHdbCHA5BkPv3RAfyw9pCiJz9BmfKGU2LIBVQ== 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: linux-kernel@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