Re: [PATCH V2 1/2] PM / Domains: Introduce domain-performance-states binding

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 06-01-17, 15:42, Rajendra Nayak wrote:
> 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)

I thought about it as multiple power domains available for a device,
and the device will be in a single domain out of those at a time. So
perhaps it is about the problem you mentioned.

> 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@12350000 {
> +		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?

So the way I proposed this earlier is that every device will have a
single power domain for it. In your case that power domain will
represent gdscs. Idle state and performance state request will go to
that level and then its up to the gdscs domain specific code to choose
the right domain and its performance state. The parent domain shall
then pass on the performance state to the next level power domain
controlled by the M3 core.

For example a device can have I power domain for idle state management
and A power domain for active state management. The device will also
have a M power domain which represents the gdscs. M can choose I or A
as its parent. The power domain A (and similar power domains for all
other devices) will have a parent power domain P. Now P is controlled
or configured via the M3. Will that make sense ?

-- 
viresh
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]
  Powered by Linux