On 26 August 2016 at 15:58, Pavel Machek <pavel@xxxxxx> wrote: > 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? On most ARM SoCs which I am familiar of and which isn't using ACPI, these kind of resources may can be considered as "power resources" connected to a generic device. Although it's of course highly dependent on the SoC. Other typical resources are clocks, pinctrls, regulators etc. To enter a low power state, these devices may not explicitly have to change some internal logic, but instead relies on external "power resources " to be put into low power mode. I guess one could compare this to what can be described in the ACPI's Device Power Management. > > Actually I don't think I like this. We should describe the hardware, > not particular use case. I am not describing use cases, but I am trying invent a generic binding that describes a generic device's idle states. At least to me, this is characteristics of the HW. Rob requested a flexible future proof binding, but perhaps you think this became too generic/flexible? > > On what hardware would you use these new bindings? Lot's of ARM SoCs, especially those that don't use ACPI. > >> +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? In most cases 4 sec is probably good enough. We could increase it to u64 or we could have another compatible string for those idle states types that requires this. > >> +== 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? On several devices that I am aware of yes. Although, again this SoC/device specific. If this becomes a problem for some devices, we can assign them another compatible string used deal with those idle state types. Kind regards Uffe -- 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
