Re: [RFC] dynamic device power management proposal

[Pavel Machek <pavel@ucw.cz>]

Hi!

> > > Runtime device power management or dynamic device power management
> > > (dpm).
> > > 
> > > Why dpm: 
> > >      1. put an idle device into low power state to save power 
> > >      2. speed up S3/S4. In resume time, we could resume devices only as
> > >         the devices are used. In suspend time, we could skip suspended
> > >         devices. (suspend/resume a device equals to change device state)
> 
> Today on system suspend we suspend all devices.
> Today on system resume, we resume all devices.

That's not how it works.

On system suspend, we _tell_ all devices to suspend

If device driver auto-suspended, it will of course not do anything. I
believe we want to keep it designed like that.

> Instead I think we should focus on exporting the appropriate APIs
> so that a management application with platform specific knowledge can
> efficiently get the kernel/drivers to implement its policies.

Please... pick one driver for whatever hardware you like... MMC card
reader in x60? And add runtime suspend/resume to that.

You'll probably find out that no new APIs are needed.

> > > My proposal: 
> > >      1. device’s power parameters. If a device’s power state depends on
> > >         several parameters, we can map different parameters combining
> > >          to a single index, which looks like ACPI Dx state. In this way,
> > >         dpm framework and policy have a generic interface to get/set
> > >         device’s state. Each state exports some info, including this
> > >         state’s power consumption/latency. Device driver can export
> > >         extra info to policy, dpm framework doesn’t handle the extra
> > >         info, but policy can. 
> 
> I don't think it is realistic for devices to export power numbers to user-space.
> Sure, it would be great, I just don't think it is realistic.
> 
> Latencies?  maybe.

Not sure about latencies. So open() on soundcard takes few miliseconds
more... userspace will not even notice.

> In general, no API has a chance until somebody actually tries it out
> and programs to it.

Yes... please.

> > >      3. detect if a device is idle. The idea is each device has a busy
> > >         timestamp. Every time the driver wants to handle the device,
> > >         driver will update the timestamp. Policy can poll the timestamp
> > >         to determine if the device is idle. 
> > 
> > That's not how the USB implementation works.  Although a timestamp like 
> > the one you describe is going to be added.
> 
> I sort of like this idea -- it seems that it is low overhead.
> Of course it requires every device driver to be changed.
> Instead we could maybe hook the generic driver entry points
> and do this in the framework -- dunno if that is viable.

No, you can't get around changing all the drivers.

Generic entry points are for _system_ suspend, and if you try to abuse
them for runtime PM, you'll have to audit/change all the drivers.

> > (This is cutting-edge stuff, not all present even in the development
> > trees.  But we're getting there.)
> > 
> > The API design is documented, so far as it exists, by the kerneldoc in 
> > drivers/usb/core/driver.c.
> 
> This is the "intelligent device driver" model -- the driver actually has a clue
> and can do the work internally.  Probably we need some combination of this
> plus the simple timeout/user-policy-manager for dumber drivers if we are to
> cover the whole system.

You simply turn dumber drivers to more inteligent ones for devices you
care about. As I explained above, you have to touch the drivers
anyway.

Maybe some helpers to make that job easier are possible...
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html