On Fri, Apr 21, 2006 at 08:27:32AM -0700, David Brownell wrote: > > > The only issue I see with numbers is that they imply order, > > > and it may be that some operating points might not have > > > such a strict order. > > In my observation, "strict order" would be the exception not > the rule. There are often three or four orthogonal factors, > and they don't naturally fit any two-dimensional linear order. We need to distinguish two aspects here -- the "whole system states", which in fact create a multi-dimensional problem, and one specific attribute of one specific device. The performance level of one specific networking device, for example. Or its sleep state. Or, if you can describe sub-aspects of a networking device, the performance level or the sleep state of that sub-device. So each strict-order parameter has its own file (that's why the RFC mentioned three files for CPUs in the ACPI-model, for performance, idle and throttling; different CPUs in different, especially embedded surroundings may require additional files). > > Yes, inventing good names may be tricky in some cases, but in other > > cases names are very natural (arm has sleep, deep sleep and big sleep, > > iirc).... And we can always fall back to state0..state5. > > Well, OMAP is one implementation that uses ARM, and it certainly has > "deep sleep" and "big sleep". But other ARM based SOCs provide very > different power abstractions (consider "slow clock mode", "idle", > "frozen", "standby", "stop", "sleep") and may use the same names to > indicate different things. System state names are system specific. Well, the big problem with names and anything "system specific" is that it makes _abstractions_ harder. It makes userspace's life harder, as it needs to know what "idle" means on a specific system, instead. > If ACPI wants to use names like "ACPI_S0".."ACPI_S5", that's fine; > but Linux should not inflict such an approach on systems that don't > use ACPI. Developers might find it handy to contrast one SOC's > "deep sleep" to "ACPI_S3" (or to "deep sleep" on another SOC), but > it won't be an exact match; square peg, round hole. Here you're talking about "system states" instead of "device states" again. Dominik
