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.0 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,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 98789C56201 for ; Fri, 6 Nov 2020 08:35:33 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 2AECF21D46 for ; Fri, 6 Nov 2020 08:35:33 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="AwkPgeKN" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2AECF21D46 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linaro.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 532346EA9F; Fri, 6 Nov 2020 08:35:00 +0000 (UTC) Received: from mail-pf1-x442.google.com (mail-pf1-x442.google.com [IPv6:2607:f8b0:4864:20::442]) by gabe.freedesktop.org (Postfix) with ESMTPS id 278E96E188 for ; Thu, 5 Nov 2020 10:06:07 +0000 (UTC) Received: by mail-pf1-x442.google.com with SMTP id z3so1089369pfz.6 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=F/qojaJSt4RHm8OJ8T8/bRzxsBKxMOXRZiYGGJEb3jOvDnwjl8Ydybn2VlNXioZ3Bs TMP9ZTNVvy8Z+RO4uY35FL+4ulgrgapsXuaRSYhA2CiWnEnN7DyDj1vndyauCjwifp/M O9CAV3l9M2wd1Q7ICXSnUEKdq7+WgKsa+U1w+8MLTFD6b+aXm1vJHA2DZQ5BmvhTdAGo UL2qk737pMCZgXj9MxFSr9epkBGN8SoPiHIooMp1kskQeBeKxiQV+7XU8pWBLqCDt+fu PBeb1ywCSlWxE2DcB6UorK+UpBus/oJ1p0mllMzZenxReOGJFctN0rSVKvTlf9VXjFZH Mccw== X-Gm-Message-State: AOAM5311Yj/c85YYmVeXBvQcJN+bUuwcyzJUBs4WJ0JQo9+revJco4h4 ozPs6Y4zO9Xw7uhv1+4gF8e8sQ== 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 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-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180716-391-311a52 X-Mailman-Approved-At: Fri, 06 Nov 2020 08:34:42 +0000 X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Peter Chen , DTML , dri-devel , Adrian Hunter , Thierry Reding , Dmitry Osipenko , Lee Jones , Marek Szyprowski , driverdevel , linux-samsung-soc , Nicolas Chauvet , Krzysztof Kozlowski , Jonathan Hunter , Alan Stern , Uwe =?utf-8?Q?Kleine-K=C3=B6nig?= , Linux Media Mailing List , linux-pwm@vger.kernel.org, Mark Brown , linux-tegra , Mauro Carvalho Chehab , Greg Kroah-Hartman , Linux USB List , "linux-mmc@vger.kernel.org" , Liam Girdwood , Linux Kernel Mailing List , Rob Herring , Peter Geis Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" 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 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel