Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751266AbdLZUYN (ORCPT ); Tue, 26 Dec 2017 15:24:13 -0500 Received: from mail.kernel.org ([198.145.29.99]:47606 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750822AbdLZUYL (ORCPT ); Tue, 26 Dec 2017 15:24:11 -0500 DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A4C0921920 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=robh+dt@kernel.org X-Google-Smtp-Source: ACJfBouHGiCZS/fPTfN044XQB2T6b5OOm1kBHJEyulZyNT957MbaUjxoOnOwe9ONk+C9YZTDDx5lmhhwhjW3BvRL7vk= MIME-Version: 1.0 In-Reply-To: <20171130065907.GI11413@vireshk-i7> References: <23ba51eaa6b52117458165dccc00a95cf8e86e1d.1509453284.git.viresh.kumar@linaro.org> <20171101214333.GG30645@codeaurora.org> <20171102045155.GX4240@vireshk-i7> <20171102071533.GM30645@codeaurora.org> <20171102090033.GZ4240@vireshk-i7> <20171130005029.GC19419@codeaurora.org> <20171130065907.GI11413@vireshk-i7> From: Rob Herring Date: Tue, 26 Dec 2017 14:23:49 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC V7 2/2] OPP: Allow "opp-hz" and "opp-microvolt" to contain magic values To: Viresh Kumar Cc: Stephen Boyd , Ulf Hansson , Kevin Hilman , Viresh Kumar , Nishanth Menon , Rafael Wysocki , "linux-pm@vger.kernel.org" , Vincent Guittot , Rajendra Nayak , Sudeep Holla , "devicetree@vger.kernel.org" , "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3422 Lines: 90 On Thu, Nov 30, 2017 at 12:59 AM, Viresh Kumar wrote: > On 29-11-17, 16:50, Stephen Boyd wrote: >> Sorry it still makes zero sense to me. It seems that we're trying >> to make the OPP table parsing generic just for the sake of code >> brevity. > > Not just the code but bindings as well to make sure we don't add a new > property (similar to earlier ones) for every platform that wants to > use performance states. > >> Is this the goal? From a DT writer perspective it seems >> confusing to say that opp-microvolt is sometimes a microvolt and >> sometimes not a microvolt. > > Well it would still represent the voltage but not in microvolt units > as the platform guys decided to hide those values from kernel and > handle them directly in firmware. > >> Why can't the SoC specific genpd >> driver parse something like "qcom,corner" instead out of the >> node? > > Sure we can, but that means that a new property will be required for > the next platform. > > I did it this way as Kevin (and Rob) suggested NOT to add another > property but use the earlier ones as we aren't passing anything new > here, just that the units of the property are different. For another > SoC, we may want to hide both freq and voltage values from kernel and > pass firmware dependent values. Should we add two new properties for > that SoC then ? > >> BTW, I don't believe I have a use-case where I want to express >> power domain OPP tables. > > I do remember that you once said [1] that you may want to pass the > real voltage values as well via DT. And so I thought that you can pass > performance-state (corner) in opp-hz and real voltage values in > opp-microvolt. > >> I have many devices that all have >> different frequencies that are all tied into the same power >> domain. This binding makes it look like we can only have one >> frequency per domain which won't work. > > No, that isn't the case. Looks like we have some confusion here. Let > me try with a simple example: > > foo: foo-power-domain@09000000 { > compatible = "foo,genpd"; > #power-domain-cells = <0>; > operating-points-v2 = <&domain_opp_table>; > }; > > cpu0: cpu@0 { > compatible = "arm,cortex-a53", "arm,armv8"; > ... > operating-points-v2 = <&cpu_opp_table>; > power-domains = <&foo>; > }; > > > domain_opp_table: domain_opp_table { > compatible = "operating-points-v2"; > > domain_opp_1: opp00 { > opp-hz = /bits/ 64 <1>; /* These are corners AKA perf states */ > }; > domain_opp_2: opp01 { > opp-hz = /bits/ 64 <2>; > }; > domain_opp_3: opp02 { > opp-hz = /bits/ 64 <3>; > }; > }; > > cpu_opp_table: cpu_opp_table { > compatible = "operating-points-v2"; > opp-shared; > > opp00 { > opp-hz = /bits/ 64 <208000000>; > clock-latency-ns = <500000>; > power-domain-opp = <&domain_opp_1>; What is this? opp00 here is not a device. One OPP should not point to another. "power-domain-opp" is only supposed to appear in devices alongside power-domains properties. Rob