[Pm-utils] [PATCH 8/8] pm-utils 1.2.3 proposed patches

[Dan Nicholson]

On Sat, Nov 29, 2008 at 11:44 AM, Victor Lowther
<victor.lowther at gmail.com> wrote:
> On Sat, 2008-11-29 at 10:51 -0800, Dan Nicholson wrote:
>> On Sat, Nov 29, 2008 at 8:51 AM, Victor Lowther
>> <victor.lowther at gmail.com> wrote:
>> > Document NEED_CLOCK_SYNC
>> >
>> > ---
>> >  README.debugging |    6 ++++++
>> >  1 files changed, 6 insertions(+), 0 deletions(-)
>> >
>> > diff --git a/README.debugging b/README.debugging
>> > index 76be415..47c756a 100644
>> > --- a/README.debugging
>> > +++ b/README.debugging
>> > @@ -21,6 +21,12 @@ End-user customization and debugging:
>> >   environment variable to have that module removed when the system
>> >   suspends and reloaded when the system wakes up.
>> >
>> > +* If your clock drifts across a sleep/wake cycle, you can use
>> > +  NEED_CLOCK_SYNC="true" to force pm-utils to synchronize clocks.
>> > +  This is a change in the default behaviour of pm-utils -- 1.2.2.1 and earlier
>> > +  always synchronized clocks, but doing so is slow and most hardware stays in
>> > +  sync without assistance.
>> > +
>> >  * To find out what parameters can be passed to pm-suspend and friends, run them
>> >   with '--help' as the first parameter as root.  This will print out the
>> >   options that it supports and which hooks or modules handle those options.
>>
>> Yay! Could we also consider adding a config variable to handle
>> alsactl? On my laptop (and hopefully most), the state doesn't change
>> across suspend/resume. I guess we probably need to talk to some ALSA
>> guru, though.
>
> The way I understand it, talking to ALSA gurus requires special
> incantations.

Well, I'll try sending a mail to alsa-devel and see if anything happens.

> Do these changes help with the speed of pm-suspend vs. without on your
> system?  Would be able to apply the profiling patches to see a before
> and after on your machine?

I didn't profile, but I imagine my results are roughly the same as
yours. I guess this is more a matter of correctness: lets not
workaround things that the kernel should be (and probably already is)
doing.

--
Dan