Re: [PATCH V8 3/3] OPP: Allow "opp-hz" and "opp-microvolt" to contain magic values

On 12/28/2017 10:07 AM, Viresh Kumar wrote:

On 27-12-17, 15:54, Rob Herring wrote:

quoted

On Wed, Dec 27, 2017 at 2:56 AM, Viresh Kumar [off-list ref] wrote:

quoted

On 26-12-17, 14:29, Rob Herring wrote:

quoted

On Mon, Dec 18, 2017 at 03:51:30PM +0530, Viresh Kumar wrote:

quoted

quoted

+On some platforms the exact frequency or voltage may be hidden from the OS by
+the firmware and the "opp-hz" or the "opp-microvolt" properties may contain
+magic values that represent the frequency or voltage in a firmware dependent
+way, for example an index of an array in the firmware.

I'm still not convinced this is a good idea.

You were kind-of a few days back :)

lkml.kernel.org/r/CAL_JsqK-qtAaM_Ou5NtxcWR3F_q=8rMPJUm-VqGtKhbtWe5SAQ@mail.gmail.com

Yeah, well that was before Stephen said anything.

quoted

So here is the deal:

- I proposed "domain-performance-state" property for this stuff
  initially.
- But Kevin didn't like that and proposed reusing "opp-hz" and
  "opp-microvolt", which we all agreed to multiple times..
- And we are back to the same discussion now and its painful and time
  killing for all of us.

There's bigger issues than where we put magic values as I raised in
the other patch.

quoted

TBH, I don't have too strong preferences about any of the suggestions
you guys have and I need you guys to tell me what binding changes to
do here and I will do that.

quoted

If you have firmware
partially managing things, then I think we should have platform specific
bindings or drivers.

What about the initial idea then, like "performance-state" for the
power domains ? All platforms will anyway replicate that binding only.

I don't really know. I don't really care either. I'll probably go
along with what everyone agrees to, but the only one I see any
agreement from is Ulf. Also, it is pretty vague as to what platforms
will use this. You claimed you can support QCom scenarios, but there's
really no evidence that that is true.

Well, I sent out the code few days back based on these bindings and everyone can
see how these bindings will get used now.

quoted

What I don't want to see is this
merged and then we need something more yet again in a few months for
another platform.

Sure, I get your concerns.

So what we need now is:

- Stephen to start responding and clarify all the doubts he had as being silent
  isn't helping.

- Or Rajendra to post patches which can prove that this is usable. The last time
  I had a chat with him, he confirmed that he will post patches after 4.15-rc1
  and he should have posted them by now, but he didn't :(

I would want to reiterate what I have been saying for a while, that for these patches
to be usable on any qualcomm platform completely we need support to associate
multiple power-domains to a single device which is missing today.

The last time this came up during a discussion at connect, I believe the understanding
was to get this (performance state support) merged *after* we decide how to support
multiple powerdomains per device.

What I have been testing with these patches is to move a single user (MMC, which BTW does not
have to put requests on multiple powerdomains) to use this solution on a db820c (msm8996) device.
Getting this merged now can open up issues for other devices (which can't move to this solution)
since MMC alone would put requests to pull a *common* rail up/down while others can't.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation