On Sat, 7 Jan 2006, Adam Belay wrote:
> In short I'm suggesting the following:
>
> 1.) Every bus and device has its own unique PM mechanisms and specifications.
> Representing this in a single unified model of any sort is nearly impossible.
> Therefore, it may be best to allow each bus to define its own PM
> infustructure and sysfs files (perhaps in a way similar to Pat's recent
> patch).
Bus and/or driver. However even though the mechanisms and specifications
are all different, that doesn't mean the user interfaces have to be
different. Using simple character string names (like Pat did and like I
did several months ago) should be general enough to work everywhere.
Similarly, the sysfs files themselves should be uniform (even if their
contents aren't). The core should provide the user interface mechanism
and infrastructure, while leaving it up to the bus and the device drivers
to interpret the meanings of the strings.
> 2.) Device drivers on the other hand exist at a more abstract level and,
> as a result, we have greater flexability and more options. Therefore, I
> think this is an excellent place to define power states and driver core PM
> infustructure.
It's a good place to define and implement power states. But the driver
core PM infrastructure obviously should be defined and implemented in the
core, not in the drivers.
> 3.) System suspend and runtime power management are not even close to
> similar. Trying to use the same ->suspend and ->resume API is
> ridiculious because it prevents intermediate power states and doesn't
> properly perpare devices and device classes for a runtime environment.
> Therefore, I'm in favor of a seperate interface tailored specifically for
> runtime power management.
Personally I don't care much one way or another. The APIs can be kept
separate or overlapped somehow; it doesn't really matter. Just so long as
it's done the same way in all drivers and in the core.
> 4.) If we're going to make any meaningful progress, we need to also
> focus on device classes and class orriented power policy. For example,
> the "net" device class should provide infustructure and helper functions
> for runtime power management of that flavor. This might include some
> generic "net" PM sysfs files.
Can you think of device classes other than "net" requiring this special
approach? Network interfaces already get special treatment in some ways
(for example, they don't have entries in /dev). This could just be
another form of special treatment for them.
Alan Stern
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
