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

[Rajendra Nayak]

On 12/28/2017 10:07 AM, Viresh Kumar wrote:
> On 27-12-17, 15:54, Rob Herring wrote:
>> On Wed, Dec 27, 2017 at 2:56 AM, Viresh Kumar <viresh.kumar@xxxxxxxxxx> wrote:
>>> On 26-12-17, 14:29, Rob Herring wrote:
>>>> On Mon, Dec 18, 2017 at 03:51:30PM +0530, Viresh Kumar wrote:
>>>
>>>>> +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@xxxxxxxxxxxxxx
>>
>> Yeah, well that was before Stephen said anything.
>>
>>> 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.
>>
>>> 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.
>>>
>>>> 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.
> 
>> 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