All of lore.kernel.org
 help / color / mirror / Atom feed
From: Viresh Kumar <viresh.kumar@linaro.org>
To: Rob Herring <robh@kernel.org>, Stephen Boyd <sboyd@codeaurora.org>
Cc: Ulf Hansson <ulf.hansson@linaro.org>,
	Kevin Hilman <khilman@kernel.org>,
	Viresh Kumar <vireshk@kernel.org>, Nishanth Menon <nm@ti.com>,
	Rafael Wysocki <rjw@rjwysocki.net>,
	linux-pm@vger.kernel.org,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Rajendra Nayak <rnayak@codeaurora.org>,
	Sudeep Holla <sudeep.holla@arm.com>,
	"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
	<devicetree@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH V8 3/3] OPP: Allow "opp-hz" and "opp-microvolt" to contain magic values
Date: Wed, 10 Jan 2018 11:07:26 +0530	[thread overview]
Message-ID: <20180110053726.GA3626@vireshk-i7> (raw)
In-Reply-To: <20180110025454.GG21040@codeaurora.org>

On 09-01-18, 18:54, Stephen Boyd wrote:
> My read of Kevin's comments lead me to think he's saying that a
> generic 'domain-performance-state' property is worse than putting
> the numbers directly inside of the opp table with a comment above
> it. Now that's all fine, but now that we have required-opps
> binding we sort of have the domain-performance-state property
> again, but it's a phandle instead of a raw state number.
> 
> So we have
> 
> 	required-opps = <&perf_state>;
> 
> but what was proposed before was
> 
> 	domain-performance-state = <1>;
> 
> or Kevin's 
> 
> 	opp-table = <100000 1>;

His concern was also on what will we do if "frequency" or other OPP
properties aren't known tomorrow by the kernel but the firmware? In
Qcom case, its just the voltage (corner) today, but it can very well
be other properties tomorrow. Are we going to add more platform
specific bindings then ? And this is the main reason why I have been
aligned towards using something like this patch.

If we drop the magic-values idea and hence this patch, then we can
either add a "domain-performance-state" property, which will only be
used by the power domains or leave it for the platforms to add
something like "qcom,corner".

All we are doing here is putting a voltage (corner) value, unknown to
the kernel, in a new property instead of "opp-microvolt". But the
above question still remains, what about other properties that may
need magic values in future.

Honestly speaking, I am not sure what's the right thing to do here. I
will do whatever you and Rob incline for.

-- 
viresh

  reply	other threads:[~2018-01-10  5:37 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-18 10:21 [PATCH V8 0/3] OPP: Allow OPP table to be used for power-domains Viresh Kumar
2017-12-18 10:21 ` Viresh Kumar
2017-12-18 10:21 ` [PATCH V8 1/3] " Viresh Kumar
2017-12-21 22:06   ` Rob Herring
2017-12-21 22:06     ` Rob Herring
2017-12-18 10:21 ` [PATCH V8 2/3] OPP: Introduce "required-opp" property Viresh Kumar
2017-12-18 10:21   ` Viresh Kumar
2017-12-20  8:23   ` Ulf Hansson
2017-12-20  8:26     ` Viresh Kumar
2017-12-21 22:26   ` Rob Herring
2017-12-21 22:26     ` Rob Herring
2017-12-22  5:28   ` Viresh Kumar
2017-12-18 10:21 ` [PATCH V8 3/3] OPP: Allow "opp-hz" and "opp-microvolt" to contain magic values Viresh Kumar
2017-12-26 20:29   ` Rob Herring
2017-12-26 20:29     ` Rob Herring
2017-12-27  8:56     ` Viresh Kumar
2017-12-27  8:56       ` Viresh Kumar
2017-12-27 21:54       ` Rob Herring
2017-12-27 21:54         ` Rob Herring
2017-12-28  4:37         ` Viresh Kumar
2017-12-28  4:37           ` Viresh Kumar
2017-12-29  0:32           ` Stephen Boyd
2017-12-29  0:32             ` Stephen Boyd
2017-12-29  4:58             ` Viresh Kumar
2017-12-29  4:58               ` Viresh Kumar
2018-01-05 22:19               ` Stephen Boyd
2018-01-05 22:19                 ` Stephen Boyd
2018-01-08  4:16                 ` Viresh Kumar
2018-01-08  4:16                   ` Viresh Kumar
2018-01-10  2:54                   ` Stephen Boyd
2018-01-10  2:54                     ` Stephen Boyd
2018-01-10  5:37                     ` Viresh Kumar [this message]
2018-01-10  5:37                       ` Viresh Kumar
2018-01-13  0:46                       ` Stephen Boyd
2018-01-13  0:46                         ` Stephen Boyd
2018-01-02  6:05           ` Rajendra Nayak
2018-01-02  6:05             ` Rajendra Nayak
2018-01-02  6:33             ` Viresh Kumar
2018-01-02  6:33               ` Viresh Kumar
2018-01-03  7:20 ` [PATCH V8 0/3] OPP: Allow OPP table to be used for power-domains Viresh Kumar
2018-01-03  7:20   ` Viresh Kumar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180110053726.GA3626@vireshk-i7 \
    --to=viresh.kumar@linaro.org \
    --cc=devicetree@vger.kernel.org \
    --cc=khilman@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=nm@ti.com \
    --cc=rjw@rjwysocki.net \
    --cc=rnayak@codeaurora.org \
    --cc=robh@kernel.org \
    --cc=sboyd@codeaurora.org \
    --cc=sudeep.holla@arm.com \
    --cc=ulf.hansson@linaro.org \
    --cc=vincent.guittot@linaro.org \
    --cc=vireshk@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.