[PATCH v5 02/16] dt/bindings: Update binding for PM domain idle states
ulf.hansson at linaro.org
Wed Sep 14 04:37:10 PDT 2016
>> Yes, you are right, I disagree with the definition of a domain around a
To fill in, I agree with Lina (and Kevin).
>From my point of view, a domain is per definition containing resources
which are shared among devices. Having one device per domain, does in
general not make sense.
> OK, great.
>> However, as long as you don't force SoC's to define devices in
>> the CPU PM domain to have their own virtual domains, I have no problem.
>> You are welcome to define it the way you want for Juno or any other
> I don't think that's true; the bindings have to work the same way for
> all platforms. If for Juno we put CPU idle state phandles in a
> domain-idle-states property for per-CPU domains then, with the current
> implementation, the CPU-level idle states would be duplicated between
> cpuidle and the CPU PM domains.
>> I don't want that to be the forced and expected out of all
>> SoCs. All I am saying here is that the current implementation would
>> handle your case as well.
> The current implementation certainly does cover the work I want to
> do. The suggestion of per-device power domains for devices/CPUs with
> their own idle states is simply intended to minimise the binding design,
> since we'd no longer need cpu-idle-states or device-idle-states
> (the latter was proposed elsewhere).
I see your point, but IMHO that would be to simplify the description
of the hardware. And I don't think it's sufficient to cover all
> I am fine with the bindings as they are implemented currently so long
> - The binding doc makes clear how idle state phandles should be split
> between cpu-idle-states and domain-idle-states. It should make it
> obvious that no phandle should ever appear in both properties. It
> would even be worth briefly going over the backward-compatibility
> implications (e.g. what happens with old-kernel/new-DT and
> new-kernel/old-DT combos if a platform has OSI and PC support and we
> move cluster-level idle state phandles out of cpu-idle-states and into
> - We have a reason against the definition of power domains as "a set of
> devices bound by a common power (including idle) state", since that
> definition would simplify the bindings. In my view, "nobody thinks
> that's what a power domain is" _is_ a compelling reason, so if others
> on the list get involved I'm convinced. I think I speak for Sudeep
> here too.
>From a CPU point of view, I think it may very well be considered as
any other device. Yes, we have treated them in a specific manner
regarding the idle state definitions we currently have - and we can
continue to do that.
Although, in the long run, I think we needs something more flexible
that can be used for domains and devices.
More information about the linux-arm-kernel