>>> >> Yes, you are right, I disagree with the definition of a domain around a >> device. 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 >> 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 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 existing cases. > > 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. > >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. Kind regards Uffe -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
