Oliver Neukum wrote:
In those devices it's ludicrous to think about any system state
other than "partially suspended" as the design center. And in
the same vein, it's rather nonsensical to have a "PM core" which
makes those systems even harder to build.
But we have this problem only if we have several low power state
which are able to change power state without waking up.
Sure, like a power or clock line getting turned off. Piece'o'cake.
These are a minority. If you design for low power the prefered
state is off, which you cannot go lower from.
Right, but there might be five different types of "power" switch
to turn off. You can save power by turning more of them off ...
but some of them affect more than one device.
In which case, let that bluetooth driver cope with its PM quirks.
Don't try to make the PM core code know about them all.
We want one for worst case, don't we? Designing with exception
planned up front is IMHO bad.
Exactly why I say it's wrong to make the PM core know about
the quirks of some random blue thing.
- Dave
-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
