On Fri, 6 Oct 2006, Oliver Neukum wrote:
> Am Donnerstag, 5. Oktober 2006 23:45 schrieb Alan Stern:
> > On Thu, 5 Oct 2006, Oliver Neukum wrote:
> >
> > > I have a few observations, but no solution either:
> > > - if root tells a device to suspend, it shall do so
> >
> > Probably everyone will agree on that.
>
> But should it stay suspended until explictely resumed? Do we have
> consensus on that?
If remote wakeup is disabled, the device will remain suspended until
something tells it to wake up.
> > > - there should be a common API for all devices
> >
> > It would be nice, wouldn't it? But we _already_ have several vastly
> > different power-management APIs. Consider for example DPMI and IDE
> > spindown.
>
> No reason to make matters worse.
Yes, there is. Consider that in many cases (think especially of embedded
platforms) devices have more than 2 power states, on or suspended. That's
true even for PCI and ATA. Each sort of bus has its own set of possible
power states, and it's hopeless to try and unify them.
> > > - there's no direct connection between power save and open()
> >
> > Why shouldn't a device always be put into a power-saving mode whenever it
> > isn't open? Agreed, you might want to reduce its power usage at times
> > even when it is open...
>
> That and you are putting the latency/power choice into kernel space.
> I've seen GPS recievers that need 30 seconds to get a fix. Autosuspend
> needs to be in kernel space. But that doesn't mean that it is sufficient
> as a mechanism nor that it doesn't need parameters supplied from
> user space.
Like I said, drivers need to make their own individual choices.
Suspending during "close" may not always be best for all devices. But for
many it is acceptable and a lot better than nothing.
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]
