lists.openwall.net   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  linux-cve-announce  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:   Fri, 06 Jan 2017 15:42:53 +0530
From:   Rajendra Nayak <rnayak@...eaurora.org>
To:     Viresh Kumar <viresh.kumar@...aro.org>
CC:     Rafael Wysocki <rjw@...ysocki.net>, linaro-kernel@...ts.linaro.org,
        linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org,
        Stephen Boyd <sboyd@...eaurora.org>,
        Nishanth Menon <nm@...com>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Kevin Hilman <khilman@...libre.com>,
        Ulf Hansson <ulf.hansson@...aro.org>,
        Lina Iyer <lina.iyer@...aro.org>, devicetree@...r.kernel.org
Subject: Re: [PATCH V2 1/2] PM / Domains: Introduce domain-performance-states
 binding



On 01/06/2017 02:57 PM, Viresh Kumar wrote:
> On 06-01-17, 14:16, Rajendra Nayak wrote:
>>
>> On 12/12/2016 04:26 PM, Viresh Kumar wrote:
>>> Some platforms have the capability to configure the performance state of
>>> their Power Domains. The performance levels are represented by positive
>>> integer values, a lower value represents lower performance state.
>>>
>>> The power-domains until now were only concentrating on the idle state
>>> management of the device and this needs to change in order to reuse the
>>> infrastructure of power domains for active state management.
>>>
>>> This patch adds binding to describe the performance states of a power
>>> domain.
>>
>> The bindings would also need to take into account the fact that a device
>> could (and is quite often the case with qcom platforms) have 2 separate
>> powerdomains, one for idle state management and another to manage active
>> states. I guess the below bindings assume that there's just one.
> 
> I have answered a similar question here..
> 
> https://marc.info/?l=linux-kernel&m=148067565219477&w=2

I read through that discussion, and I thought that was to do we
handling multiple powerdomains with performance states
(or in other words multiple voltage rails controlled by the M3)

What I was pointing to, was that devices quite often (again on qcom
platforms) have a power-switch (gdscs as we call it) which are modeled
as powerdomains (which have nothing to do with taking to the M3 core),
and with the proposed bindings one or more voltage rails controlled by the M3
also as powerdomains associated with a device and the bindings have just one
power-domains property in the device node, which runtime PM would use
to power_on/off the device and OPP core would use to set the performance
state?

+	leaky-device@...50000 {
+		compatible = "foo,i-leak-current";
+		reg = <0x12350000 0x1000>;
+		power-domains = <&power 0>;
+		domain-performance-state = <&domain_perf_state2>;
+	};

Lets say leaky-device needs to switch on/off a gdsc and also send a
value to M3 to set a minimum performance state (so M3 configures the
voltage rails accordingly) how would it work?

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ