Hi! > @@ -0,0 +1,102 @@ > +Device idle states > +======================== > + > +A device are often capable of entering a low power state(s) when it becomes > +idle, hence the terminology of device idle states. Entering an idle state for a > +device helps it to avoid wasting power and reduces the leakage of current. First things first: what do these states _really_ represent? We have GPIOs in device tree, we have clock domains. What are these? Actually I don't think I like this. We should describe the hardware, not particular use case. On what hardware would you use these new bindings? > +Required properties: > +- compatible: Must contain "simple-dev, idle-state". > +- entry-latency-ns: An u32 value in nano-seconds representing the worst case > + latency required for the device to enter the idle state. > +- exit-latency-ns: An u32 value in nano-seconds representing the worst case > + wakeup latency of the device, after entry-latency-ns has > + passed. u32 nanoseconds have 4sec limit, right? So anything with spinning harddrive is out? > +== Assigning idle states to devices == > + > +Required properties: > + - dev-idle-states: A list of phandles pointing to the supported > + device idle states nodes. The list must be ordered as > + the shallower state - the earlier in the list. Does such ordering really neccessarily exist? -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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
