Re: [patch] pm: fix runtime powermanagement's /sys interface

Pavel Machek
2006-01-06T04:24:22Z

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

> > > 1.) most sound cards have more than two states. (once again latency over
> > > power savings trade offs)
> >
> > What is the latency in typical "most sound card" case?
>
> ACPI requires within 100ms for D1 and D2. D3 can be longer.

Spec is useless here. 1usec is <100msec. Do you know any
soundcard that takes >10msec from D3?
>
> > > 4.) IDE hard drives and other storage media have "sleep", "suspend",
> > > etc.
> >
> > Yep; but spindown takes 5 seconds, so if you need to reset ide bus or
> > not to get it back is driver detail. Plus notice how power consuption
> > in sleep and suspend is almost same; motor not running is big deal
> > there. Ouch and hdparm already handles these.
>
> 5 seconds is more of an upper bound. My laptop hardrive can do spindown
> and spinup in around 1 second. hdparm doesn't handle the deeper suspend
> case (it can enter but not recover). Kernel level support is required.

...but this has very little to do with framework we are trying to
build.
(and no support is needed for hdparm -y).

> > > 6.) many video cards implement D1 and D2 as you've already seen. This
> > > is often more a matter of "we only know how to restore from such and such
> > > states"
> >
> > Excatly, so "on"/"off" is enough for them.
>
> Not really. The ACPI spec suggests latency requirements for each state.
> If we had better drivers, we might enter a lower latency video card
> state when the screen is blanked that's not quite an "off" state.

Backlight takes ages, anyway.

--
Thanks, Sharp!