lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 13 Apr 2017 14:43:38 +0100
From:   Sudeep Holla <>
To:     Viresh Kumar <>
Cc:     Sudeep Holla <>,
        Rafael Wysocki <>,,
        Kevin Hilman <>,
        Viresh Kumar <>, Nishanth Menon <>,
        Stephen Boyd <>,,,,
        Vincent Guittot <>,,,,
Subject: Re: [PATCH V4 1/9] PM / OPP: Allow OPP table to be used for

On 13/04/17 06:50, Viresh Kumar wrote:
> On 12-04-17, 18:05, Sudeep Holla wrote:
>> On 20/03/17 09:32, Viresh Kumar wrote:


>> Thinking more about this above example, I think you need more
>> explanation. So in the above case you have cpu with clock controller,
>> power-domain and the OPP table info, I can think of few things that need
>> to be explicit:
>> 1. How does the precedence look like ?
> Just think of the power-domain as a regulator here. If we are
> increasing frequency of the device, power-domain needs to be
> programmed first followed by the clock.

Interesting. My understand of power domain and in particular power
domain performance was that it would control both. The abstract number
you introduce would hide clocks and regulators.

But if the concept treats it just as yet another regulator, we do we
need these at all. Why don't we relate this performance to regulator
values and be done with it ?

Sorry if I am missing to understand something here. I would look this as
replacement for both clocks and regulators, something similar to ACPI
CPPC. If not, it looks unnecessary to me with the information I have got
so far.

>> 2. Since power-domains with OPP table control the performance state, do
> They control performance state of the domains, not the devices.
>>    we ignore clock and operating-points-v2 in the above case completely?
> No. They are separate.

Understood now, but still trying to understand the complexity introduced

>> 3. Will the power-domain drive the OPP ?
> power-domain will driver its own state using its own OPP table.
> Devices may fine tune within those states.

I fail to understand here. This makes me think this power domain is same
as regulators as you pointed out earlier. So, we do we need all these
extra things. I was hoping this to be something like ACPI CPPC that hide
away clock and regulators.


Powered by blists - more mailing lists