On 29 August 2016 at 12:40, Pavel Machek <pavel@xxxxxx> wrote: > On Mon 2016-08-29 11:34:34, Ulf Hansson wrote: >> 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. > > If they are clocks, describe them as clocks, DT supports that. If they > are regulators, describe them as regulators. > > We don't want to have "we have these magic somethings here". We want > to know whether it is clock, regulator, or what. This isn't something that will *replace* clocks etc. If those resources are needed, of course those needs to be described. What is missing in DT, and what I suggest to add, is to be able to describe the actual idle states of a device and the HW characteristics related to that. In this RFC, I picked the most common properties that I could think of, which ought to be latencies for enter and wakeup from a low power state. And... we also have devices that have internal logics that must be changed to enter and wakeup from a low power state. For example WLAN circuits, PCI devices, etc. So this isn't all about clocks/regulators etc, but devices in general. [...] 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
