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. > > 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? I believe this is no longer describing hardware. Best regards, Pavel -- (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
