On Tue, Sep 13 2016 at 20:38, Lina Iyer wrote: > On Tue, Sep 13 2016 at 11:50 -0600, Brendan Jackman wrote: >> >>On Mon, Sep 12 2016 at 18:09, Sudeep Holla wrote: >>> On 12/09/16 17:16, Lina Iyer wrote: >>>> On Mon, Sep 12 2016 at 09:19 -0600, Brendan Jackman wrote: >>>>> >>>>> Hi Lina, >>>>> >>>>> Sorry for the delay here, Sudeep and I were both been on holiday last >>>>> week. >>>>> >>>>> On Fri, Sep 02 2016 at 21:16, Lina Iyer wrote: >>>>>> On Fri, Sep 02 2016 at 07:21 -0700, Sudeep Holla wrote: >>>>> [...] >>>>>>> This version is *not very descriptive*. Also the discussion we had >>>>>>> on v3 >>>>>>> version has not yet concluded IMO. So can I take that we agreed on what >>>>>>> was proposed there or not ? >>>>>>> >>>>>> Sorry, this example is not very descriptive. Pls. check the 8916 dtsi >>>>>> for the new changes in the following patches. Let me know if that makes >>>>>> sense. >>> >>> Please add all possible use-cases in the bindings. Though one can refer >>> the usage examples, it might not cover all usage descriptions. It helps >>> preventing people from defining their own when they don't see examples. >>> Again DT bindings are like specifications, it should be descriptive >>> especially this kind of generic ones. >>> >>>>> >>>>> The not-yet-concluded discussion Sudeep is referring to is at [1]. >>>>> >>>>> In that thread we initially proposed the idea of, instead of splitting >>>>> state phandles between cpu-idle-states and domain-idle-states, putting >>>>> CPUs in their own domains and using domain-idle-states for _all_ >>>>> phandles, deprecating cpu-idle-states. I've brought this up in other >>>>> threads [2] but discussion keeps petering out, and neither this example >>>>> nor the 8916 dtsi in this patch series reflect the idea. >>>>> >>>> Brendan, while your idea is good and will work for CPUs, I do not expect >>>> other domains and possibly CPU domains on some architectures to follow >>>> this model. There is nothing that prevents you from doing this today, >> >>As I understand it your opposition to this approach is this: >> >>There may be devices/CPUs which have idle states which do not constitute >>"power off". If we put those devices in their own power domain for the >>purpose of putting their (non-power-off) idle state phandles in >>domain-idle-states, we are "lying" because no true power domain exists >>there. >> >>Am I correct that that's your opposition? >> >>If so, it seems we essentially disagree on the definition of a power >>domain, i.e. you define it as a set of devices that are powered on/off >>together while I define it as a set of devices whose power states >>(including idle states, not just on/off) are tied together. I said >>something similar on another thread [1] which died out. >> >>Do you agree that this is basically where we disagree, or am I missing >>something else? >> >>[2] http://www.spinics.net/lists/devicetree/msg141050.html >> > Yes, you are right, I disagree with the definition of a domain around a > device. 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 > platform. 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 am fine with the bindings as they are implemented currently so long as: - 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 domai-idle-states). - 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. Cheers, Brendan -- 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
