Hi,
On Saturday, 17 February 2007 12:40, Pavel Machek wrote:
> Hi!
>
> > > > +PM support: Since Linux is used on many portable and desktop
> > > > systems, your
> > > > + driver is likely to be used on such a system and
> > > > therefore it
> > > > + should support basic power management by implementing,
> > > > if
> > > > + necessary, the .suspend and .resume methods used during
> > > > the
> > > > + system-wide suspend and resume transitions. You should
> > > > verify
> > > > + that your driver correctly handles the suspend and
> > > > resume, but
> > > > + if you are unable to ensure that, please at least
> > > > define the
> > > > + .suspend method returning the -ENOSYS ("Function not
> > > > + implemented") error.
> > >
> > > Perhaps pointer to Documentation/power/drivers-testing.txt would be
> > > useful here?
> >
> > Okay, maybe something like this:
> >
> > "Please see Documentation/power/drivers-testing.txt for the driver testing
> > instructions."
> >
> > as the last sentence?
>
> Looks ok. (BTW you have my ACK).
Thanks.
> > > > +Unfortunately, to effectively test the support for the system-wide
> > > > suspend and
> > > > +resume transitions in a driver, it is necessary to suspend and resume
> > > > a fully
> > > > +functional system with this driver loaded. Moreover, that should be
> > > > done many
> > > > +times, preferably many times in a row, and separately for the suspend
> > > > to disk
> > > > +(STD) and the suspend to RAM (STR) transitions, because each of these
> > > > cases
> > > > +involves different ordering of operations and different interactions
> > > > with the
> > > > +machine's BIOS.
> > >
> > > Hmm, actually it is nice to mix STR + STD, too... and not sure if
> > > "many" is right word... It sounds scary :-).
> >
> > "a couple of"?
>
> Sounds good.
> > > > +II. Testing the driver
> > > > +
> > > > +Once you have resolved the suspend/resume-related problems with your
> > > > test system
> > > > +without the new driver, you are ready to test it:
> > > > +
> > > > +1. Build the driver as a module, load it and try the STD in the test
> > > > mode
> > > > +(cf. 1a)).
> > > > +
> > > > +2. Compile the driver directly into the kernel and try the STD in the
> > > > test mode
> > > > +(cf. 1a)).
> > > > +
> > > > +3. Build the driver as a module, load it and attempt to suspend to
> > > > disk in the
> > > > +"reboot", "shutdown" and "platform" modes (cf. 1).
> > > > +
> > > > +4. Compile the driver directly into the kernel and attempt to suspend
> > > > to disk in
> > > > +the "reboot", "shutdown" and "platform" modes (cf. 1).
> > > > +
> > > > +5. Build the driver as a module, load it and attempt to run s2ram (cf.
> > > > 2).
> > > > +
> > > > +6. Compile the driver directly into the kernel and attempt to run
> > > > s2ram (cf. 2).
> > > > +
> > > > +Each of the above tests should be repeated several times and if any of
> > > > them
> > > > +fails, the driver cannot be regarded as suspend/resume-safe.
> > >
> > > Maybe reorder the tests so that poor submitter will not have to do 3
> > > kernel compiles?
> >
> > I thought he would figure out that there's more efficient way. ;-)
>
> He probably will... but it reads strangely.
>
> 5. Build the driver as a module, load it and attempt to run s2ram. Then
> repeat with driver build-in?
>
> Hmm, and maybe driver loaded/build in is not a difference for s2ram?
Good point. :-)
Greetings,
Rafael
-
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/
