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.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 9B874C4742C for ; Thu, 5 Nov 2020 10:06:12 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 3997E2078E for ; Thu, 5 Nov 2020 10:06:12 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="AwkPgeKN" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726874AbgKEKGI (ORCPT ); Thu, 5 Nov 2020 05:06:08 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59792 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726729AbgKEKGH (ORCPT ); Thu, 5 Nov 2020 05:06:07 -0500 Received: from mail-pf1-x442.google.com (mail-pf1-x442.google.com [IPv6:2607:f8b0:4864:20::442]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3B49CC0613D6 for ; Thu, 5 Nov 2020 02:06:07 -0800 (PST) Received: by mail-pf1-x442.google.com with SMTP id y7so33070pfq.11 for ; Thu, 05 Nov 2020 02:06:07 -0800 (PST) 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:in-reply-to:user-agent; bh=eGW1ILzr61LRI7Nn5j3Px4Z853itoyrKaaACPPuanD8=; b=AwkPgeKN8JxD5DofrhKKvVmK4cvSq6debaCUoSYPEqvE49cn04nt/Ohj9eefgHf9TL aIx6rKXj0///p0JGjzTLdfu2hmMAvQApkss/uH/gSZkh61VO6pZ2ylsM9Il/53KW7LGl IUDWHNviUCd6hnxXLRNUeX3Y6HNhSHtWwbsLSi36WRlNoTuyeXeVCGre4buS3NdKlXZ1 C93L+wYAB2E1lwHrDLcQqvzcXv151CIyLt/YY5KfH9h0bSL8R2KSSrdlcms3OAEXEAQn s+1SmPefG0RRF/HzCmYyPjNZRXZ/yeV4tDx9EOD1LS9Yd2qnGpLlBgdhBvWMqnBFNCh+ Memw== 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:in-reply-to:user-agent; bh=eGW1ILzr61LRI7Nn5j3Px4Z853itoyrKaaACPPuanD8=; b=DbWhMMpNB2xHCbPnyxjW8GlphFubAfROU6earo8cjxj6FmBglTwwEkUS3akbHIufB+ Nk1Y2W32e9W0xghsbYhXTdfzMcPT6qzGsYD+L1TGIt6Y+VoB2GHAJFUV9u9mJmwEXvwO xCfw9Y/dVQwszcIoOujUMfZlYjXlR2oVe988BoLDmDUqswLwhawg3wfYfeNbVG8n/PfV xrUoIUn/mR02IE5H6mTBt3Xwejr/jsaR1pfg49RgdEN9XyL+Vi1hCCxaqBkbRLxgYkpF P1ZgPQ1hO9OoNQNgF8iRHM3BuJ59caJ/l4xM79UMpq8azBwFwdG7/qqlMZiqsEeNCQn9 ip2A== X-Gm-Message-State: AOAM532CiA33ChTFh5ZzC5Q9OdfF1z/R8xBxYO06AgVIeCXqzHrdZXkl Vy6YEdNo+GF514cVbDGC/djjPA== X-Google-Smtp-Source: ABdhPJx+19aSHb7auOFJLKtzrXZ1adaxUM3Bi1xOIxWA6Q/xzn6rrIYE3T8B5dM0UQjbWyOAIsn6/Q== X-Received: by 2002:a17:90b:ec9:: with SMTP id gz9mr1700784pjb.105.1604570766580; Thu, 05 Nov 2020 02:06:06 -0800 (PST) Received: from localhost ([122.172.12.172]) by smtp.gmail.com with ESMTPSA id s22sm1813783pfu.119.2020.11.05.02.06.05 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Nov 2020 02:06:05 -0800 (PST) Date: Thu, 5 Nov 2020 15:36:03 +0530 From: Viresh Kumar To: Ulf Hansson Cc: Dmitry Osipenko , Thierry Reding , Jonathan Hunter , Alan Stern , Peter Chen , Mark Brown , Liam Girdwood , Adrian Hunter , Krzysztof Kozlowski , Greg Kroah-Hartman , Lee Jones , Uwe =?utf-8?Q?Kleine-K=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 Subject: Re: [PATCH v1 00/30] Introduce core voltage scaling for NVIDIA Tegra20/30 SoCs Message-ID: <20201105100603.skrirm7uke4s2xyl@vireshk-i7> References: <20201104234427.26477-1-digetx@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180716-391-311a52 Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On 05-11-20, 10:45, Ulf Hansson wrote: > + Viresh Thanks Ulf. I found a bug in OPP core because you cc'd me here :) > On Thu, 5 Nov 2020 at 00:44, Dmitry Osipenko wrote: > I need some more time to review this, but just a quick check found a > few potential issues... > > The "core-supply", that you specify as a regulator for each > controller's device node, is not the way we describe power domains. Maybe I misunderstood your comment here, but there are two ways of scaling the voltage of a device depending on if it is a regulator (and can be modeled as one in the kernel) or a power domain. In case of Qcom earlier (when we added the performance-state stuff), the eventual hardware was out of kernel's control and we didn't wanted (allowed) to model it as a virtual regulator just to pass the votes to the RPM. And so we did what we did. But if the hardware (where the voltage is required to be changed) is indeed a regulator and is modeled as one, then what Dmitry has done looks okay. i.e. add a supply in the device's node and microvolt property in the DT entries. -- viresh