Re: RE: on-ness

[David Brownell <david-b@pacbell.net>]

[-- Attachment #1: Type: text/plain, Size: 2859 bytes --]

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


[-- Attachment #2: Type: text/plain, Size: 0 bytes --]