On Thursday 27 April 2006 7:12 am, Scott E. Preece wrote: > > Let me recast the question a little. > > Quite aside from the utility of having names that are meaningful to a > human reader unfamiliar with a particular device, is the problem of > supporting a system-level power policy on top of devices that have > different device-level power states. Related: handling the interactions between system and device power states. System states commonly constrain device states, e.g. by rules like "clocks X, Y, and Z are unavailable in system states B and C". I have an API proposal for that particular problem, but there are similar ones in other areas, like the available power. (Maybe some of the supplies have less power available -- or none! -- or switch to lower voltage modes.) > So, is the sum of this conversation to this point that it simply isn't > possible to come up with a set of names and attributes that are > meaningful across devices? Possible is one thing; you can always define an ever-growing set of attributes. But would it be useful ... or a nightmare to manage, when scaling over all platforms that Linux handles? I lean towards the latter. > Or might it be possible to map the set of > special conditions (like the "NoSoftReset" below) to a common vocabulary > that a device could expose to power management and that a generic, > cross-platform power management facility could map to system states and > transitions? There will be some common features, sure, but I'm skeptical about the notion of a generic cross-platform wunderfacility. And there are other options. My current favorite is still to expose device-specific power states purely for test/debug, and expect the kernel to handle everything correctly. (We do need a better notion of drivers interacting with a system-wide power manager. Currently there IS no such notion, and it's a huge hole.) > In my domain (consumer devices) it's not such a big deal, because we > pick the devices and can write code [albeit with some effort that we > would rather not expend] to control each device appropriately in the > context of the system's projected use cases. However, even in our domain > we're beginning to need to deal with USB OTG devices being added, and it > would be useful to be able to handle them at least somewhat > intelligently based on attributes that they expose. Heh. OTG, yes. I've put some thought into that. There happen to be a few different models to consider ... for example, sometimes there are separate controllers for host and peripheral roles, as well as an OTG controller coupled to a transceiver (maybe external/interchangeable); and sometimes it's all integrated (e.g. host vs peripheral is just different modes working with the same FIFO/SIE silicon). Again, I don't see any need to expose a userspace API for those. - Dave
