On Fri, Aug 26, 2016 at 12:24:33PM +0200, Ulf Hansson wrote: > A device may be capable of entering a low power state when it becomes > idle, which should avoid the device from wasting power. > > Unfortunate entering a such low power state for a device may often also > come with a cost. This because when a new request is about to be served, > the device must first to be woken up from its low power state. As that may > take a while, the request may suffer from an initial latency. > > These so called device idle states are characteristics of the hardware, so > let's define some DT bindings to enable us to describe them. > > Signed-off-by: Ulf Hansson <ulf.hansson@xxxxxxxxxx> > --- > > Similar DT bindings has been suggested earlier [1], although Rob raised > primarily two conserns in that approach. > > *) The bindings was probably not future proof, some more flexibility was needed. > > **) As the bindings also relates to idles states for PM domains, it seemed > reasonable to discuss them at the same time. As there is an ongoing discussion > for that right now [2], I took the opportunity to bring up the discussion for > device idles states again. > Hi Ulf, There was some previous discussion of whether device idle state bindings are necessary. It was proposed that rather than adding a whole new binding, we could just use the power domain idle state binding from [2]. We suggested that any device that has an idle state is, by definition, in a power domain of its own: rather than add a device-idle-states property to that device, we just put it in a power domain with a domain-idle-states property. When I say "by definition", I of course mean "by the definition of 'power domain' that's most convenient to my argument", but I think that definition is also the one that's most useful for solving our problem. Sudeep posted some examples in [3] (in the thread for [2]). Before we discuss device idle state bindings, could we finish discussing that idea so that everyone agrees on whether they're actually needed? It might be worth having that discussion in replies to [3] so that we can use Sudeep's examples. The 5th example in his mail is the most interesting. > [1] > http://www.spinics.net/lists/devicetree/msg120515.html > > [2] > http://www.spinics.net/lists/arm-kernel/msg522023.html [3] http://www.spinics.net/lists/arm-kernel/msg526162.html ^ Message-ID: <9b2ed5d3-c071-8828-5a22-1ab6f3753d74@xxxxxxx> 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
