Re: [linux-pm] [RFC][PATCH] PM: Document requirements for basic PM support in drivers
On Wednesday, 14 February 2007 16:41, Igor Stoppa wrote:
> On Tue, 2007-02-13 at 10:47 +1100, ext Nigel Cunningham wrote:
> > Hi.
> >
> > On Tue, 2007-02-13 at 00:23 +0100, Rafael J. Wysocki wrote:
> > > Hi,
> > >
> > > Here's my attempt to document the requirements with respect to the basic
> > > PM
> > > support in drivers and the testing of that. Comments welcome.
> > >
> > > Greetings,
> > > Rafael
> > >
> > > ---
> > > Documentation/SubmittingDrivers | 10 ++
> > > Documentation/power/drivers-testing.txt | 119
> > >
> > > 2 files changed, 129 insertions(+)
> > >
> > > Index: linux-2.6.20-git4/Documentation/SubmittingDrivers
> > > ===
> > > --- linux-2.6.20-git4.orig/Documentation/SubmittingDrivers
> > > +++ linux-2.6.20-git4/Documentation/SubmittingDrivers
> > > @@ -87,6 +87,16 @@ Clarity: It helps if anyone can see how
> > > driver that intentionally obfuscates how the hardware works
> > > it will go in the bitbucket.
> > >
> > > +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.
> > > +
> > > Control: In general if there is active maintainance of a driver by
> > > the author then patches will be redirected to them unless
> > > they are totally obvious and without need of checking.
> > > Index: linux-2.6.20-git4/Documentation/power/drivers-testing.txt
> > > ===
> > > --- /dev/null
> > > +++ linux-2.6.20-git4/Documentation/power/drivers-testing.txt
> > > @@ -0,0 +1,119 @@
> > > +Testing suspend and resume support in drivers
> > > + (C) 2007 Rafael J. Wysocki <[EMAIL PROTECTED]>
> > > +
> > > +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.
> > > +
> > > +Of course, for this purpose the test system has to be known to suspend
> > > and
> > > +resume without the driver being tested. Thus, if possible, you should
> > > first
> > > +resolve all suspend/resume-related problems in the test system before
> > > you start
> > > +testing the new driver.
> > > +
> > > +I. Preparing the test system
> > > +
> > > +1. To verify that the STD works, you can try to suspend in the "reboot"
> > > mode:
> > > +
> > > +# echo reboot > /sys/power/disk
> > > +# echo disk > /sys/power/state
> > > +
> > > +and the system should suspend, reboot, resume and get back to the
> > > command prompt
> > > +where you have started the transition. If that happens, the STD is most
> > > likely
> > > +to work correctly, but you can repeat the test a couple of times in a
> > > row for
> > > +confidence. You should also test the "platform" and "shutdown" modes of
> >
> > I would say "you need to repeat the test at least a couple of times...",
> > perhaps adding something along the lines of "This is necessary because
> > some problems only show up on a second attempt at suspending and
> > resuming a driver. You can think of it as the driver coming back 'dazed
> > and confused' after the first cycle, and only being properly killed by
> > the second attempt."
>
> "at least a couple of times" sounds very optimistic :-D
Usually two times are enough to trigger the problem in such cases.
> >
> > > +suspend:
> > > +
> > > +# echo platform > /sys/power/disk
> > > +# echo disk > /sys/power/state
> > > +
> > > +or
> > > +
> > > +# echo shutdown > /sys/power/disk
> > > +# echo disk > /sys/power/state
> > > +
> > > +in which cases you will have to press the power button to make the system
> > > +resume. If that works, you are ready to test the STD with the new driver
> > > +loaded. Otherwise, you have to identify what is wrong.
> > > +
> > > +a) To verify if there are any drivers that cause problems you can run
> > > the STD
> > > +in the test mode:
> > > +
> > > +# echo test > /sys/power/disk
> > > +#
Re: [linux-pm] [RFC][PATCH] PM: Document requirements for basic PM support in drivers
On Tue, 2007-02-13 at 10:47 +1100, ext Nigel Cunningham wrote:
> Hi.
>
> On Tue, 2007-02-13 at 00:23 +0100, Rafael J. Wysocki wrote:
> > Hi,
> >
> > Here's my attempt to document the requirements with respect to the basic PM
> > support in drivers and the testing of that. Comments welcome.
> >
> > Greetings,
> > Rafael
> >
> > ---
> > Documentation/SubmittingDrivers | 10 ++
> > Documentation/power/drivers-testing.txt | 119
> >
> > 2 files changed, 129 insertions(+)
> >
> > Index: linux-2.6.20-git4/Documentation/SubmittingDrivers
> > ===
> > --- linux-2.6.20-git4.orig/Documentation/SubmittingDrivers
> > +++ linux-2.6.20-git4/Documentation/SubmittingDrivers
> > @@ -87,6 +87,16 @@ Clarity: It helps if anyone can see how
> > driver that intentionally obfuscates how the hardware works
> > it will go in the bitbucket.
> >
> > +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.
> > +
> > Control: In general if there is active maintainance of a driver by
> > the author then patches will be redirected to them unless
> > they are totally obvious and without need of checking.
> > Index: linux-2.6.20-git4/Documentation/power/drivers-testing.txt
> > ===
> > --- /dev/null
> > +++ linux-2.6.20-git4/Documentation/power/drivers-testing.txt
> > @@ -0,0 +1,119 @@
> > +Testing suspend and resume support in drivers
> > + (C) 2007 Rafael J. Wysocki <[EMAIL PROTECTED]>
> > +
> > +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.
> > +
> > +Of course, for this purpose the test system has to be known to suspend and
> > +resume without the driver being tested. Thus, if possible, you should
> > first
> > +resolve all suspend/resume-related problems in the test system before you
> > start
> > +testing the new driver.
> > +
> > +I. Preparing the test system
> > +
> > +1. To verify that the STD works, you can try to suspend in the "reboot"
> > mode:
> > +
> > +# echo reboot > /sys/power/disk
> > +# echo disk > /sys/power/state
> > +
> > +and the system should suspend, reboot, resume and get back to the command
> > prompt
> > +where you have started the transition. If that happens, the STD is most
> > likely
> > +to work correctly, but you can repeat the test a couple of times in a row
> > for
> > +confidence. You should also test the "platform" and "shutdown" modes of
>
> I would say "you need to repeat the test at least a couple of times...",
> perhaps adding something along the lines of "This is necessary because
> some problems only show up on a second attempt at suspending and
> resuming a driver. You can think of it as the driver coming back 'dazed
> and confused' after the first cycle, and only being properly killed by
> the second attempt."
"at least a couple of times" sounds very optimistic :-D
>
> > +suspend:
> > +
> > +# echo platform > /sys/power/disk
> > +# echo disk > /sys/power/state
> > +
> > +or
> > +
> > +# echo shutdown > /sys/power/disk
> > +# echo disk > /sys/power/state
> > +
> > +in which cases you will have to press the power button to make the system
> > +resume. If that works, you are ready to test the STD with the new driver
> > +loaded. Otherwise, you have to identify what is wrong.
> > +
> > +a) To verify if there are any drivers that cause problems you can run the
> > STD
> > +in the test mode:
> > +
> > +# echo test > /sys/power/disk
> > +# echo disk > /sys/power/state
> > +
> > +in which case the system should freeze tasks, suspend devices, disable
> > nonboot
> > +CPUs (if any), wait for 5 seconds, enable nonboot CPUs, resume devices,
> > thaw
> > +tasks and return to your command prompt. If that fails, most likely there
> > is
> > +a driver that fails to either suspend or
Re: [linux-pm] [RFC][PATCH] PM: Document requirements for basic PM support in drivers
On Tue, 2007-02-13 at 10:47 +1100, ext Nigel Cunningham wrote: Hi. On Tue, 2007-02-13 at 00:23 +0100, Rafael J. Wysocki wrote: Hi, Here's my attempt to document the requirements with respect to the basic PM support in drivers and the testing of that. Comments welcome. Greetings, Rafael --- Documentation/SubmittingDrivers | 10 ++ Documentation/power/drivers-testing.txt | 119 2 files changed, 129 insertions(+) Index: linux-2.6.20-git4/Documentation/SubmittingDrivers === --- linux-2.6.20-git4.orig/Documentation/SubmittingDrivers +++ linux-2.6.20-git4/Documentation/SubmittingDrivers @@ -87,6 +87,16 @@ Clarity: It helps if anyone can see how driver that intentionally obfuscates how the hardware works it will go in the bitbucket. +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. + Control: In general if there is active maintainance of a driver by the author then patches will be redirected to them unless they are totally obvious and without need of checking. Index: linux-2.6.20-git4/Documentation/power/drivers-testing.txt === --- /dev/null +++ linux-2.6.20-git4/Documentation/power/drivers-testing.txt @@ -0,0 +1,119 @@ +Testing suspend and resume support in drivers + (C) 2007 Rafael J. Wysocki [EMAIL PROTECTED] + +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. + +Of course, for this purpose the test system has to be known to suspend and +resume without the driver being tested. Thus, if possible, you should first +resolve all suspend/resume-related problems in the test system before you start +testing the new driver. + +I. Preparing the test system + +1. To verify that the STD works, you can try to suspend in the reboot mode: + +# echo reboot /sys/power/disk +# echo disk /sys/power/state + +and the system should suspend, reboot, resume and get back to the command prompt +where you have started the transition. If that happens, the STD is most likely +to work correctly, but you can repeat the test a couple of times in a row for +confidence. You should also test the platform and shutdown modes of I would say you need to repeat the test at least a couple of times..., perhaps adding something along the lines of This is necessary because some problems only show up on a second attempt at suspending and resuming a driver. You can think of it as the driver coming back 'dazed and confused' after the first cycle, and only being properly killed by the second attempt. at least a couple of times sounds very optimistic :-D +suspend: + +# echo platform /sys/power/disk +# echo disk /sys/power/state + +or + +# echo shutdown /sys/power/disk +# echo disk /sys/power/state + +in which cases you will have to press the power button to make the system +resume. If that works, you are ready to test the STD with the new driver +loaded. Otherwise, you have to identify what is wrong. + +a) To verify if there are any drivers that cause problems you can run the STD +in the test mode: + +# echo test /sys/power/disk +# echo disk /sys/power/state + +in which case the system should freeze tasks, suspend devices, disable nonboot +CPUs (if any), wait for 5 seconds, enable nonboot CPUs, resume devices, thaw +tasks and return to your command prompt. If that fails, most likely there is +a driver that fails to either suspend or resume (in the latter case the system +may hang or be unstable after the test, so please take that into consideration). +To find this driver, you can carry out a binary search according to the rules: +- if the test fails, unload a half of
Re: [linux-pm] [RFC][PATCH] PM: Document requirements for basic PM support in drivers
On Wednesday, 14 February 2007 16:41, Igor Stoppa wrote: On Tue, 2007-02-13 at 10:47 +1100, ext Nigel Cunningham wrote: Hi. On Tue, 2007-02-13 at 00:23 +0100, Rafael J. Wysocki wrote: Hi, Here's my attempt to document the requirements with respect to the basic PM support in drivers and the testing of that. Comments welcome. Greetings, Rafael --- Documentation/SubmittingDrivers | 10 ++ Documentation/power/drivers-testing.txt | 119 2 files changed, 129 insertions(+) Index: linux-2.6.20-git4/Documentation/SubmittingDrivers === --- linux-2.6.20-git4.orig/Documentation/SubmittingDrivers +++ linux-2.6.20-git4/Documentation/SubmittingDrivers @@ -87,6 +87,16 @@ Clarity: It helps if anyone can see how driver that intentionally obfuscates how the hardware works it will go in the bitbucket. +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. + Control: In general if there is active maintainance of a driver by the author then patches will be redirected to them unless they are totally obvious and without need of checking. Index: linux-2.6.20-git4/Documentation/power/drivers-testing.txt === --- /dev/null +++ linux-2.6.20-git4/Documentation/power/drivers-testing.txt @@ -0,0 +1,119 @@ +Testing suspend and resume support in drivers + (C) 2007 Rafael J. Wysocki [EMAIL PROTECTED] + +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. + +Of course, for this purpose the test system has to be known to suspend and +resume without the driver being tested. Thus, if possible, you should first +resolve all suspend/resume-related problems in the test system before you start +testing the new driver. + +I. Preparing the test system + +1. To verify that the STD works, you can try to suspend in the reboot mode: + +# echo reboot /sys/power/disk +# echo disk /sys/power/state + +and the system should suspend, reboot, resume and get back to the command prompt +where you have started the transition. If that happens, the STD is most likely +to work correctly, but you can repeat the test a couple of times in a row for +confidence. You should also test the platform and shutdown modes of I would say you need to repeat the test at least a couple of times..., perhaps adding something along the lines of This is necessary because some problems only show up on a second attempt at suspending and resuming a driver. You can think of it as the driver coming back 'dazed and confused' after the first cycle, and only being properly killed by the second attempt. at least a couple of times sounds very optimistic :-D Usually two times are enough to trigger the problem in such cases. +suspend: + +# echo platform /sys/power/disk +# echo disk /sys/power/state + +or + +# echo shutdown /sys/power/disk +# echo disk /sys/power/state + +in which cases you will have to press the power button to make the system +resume. If that works, you are ready to test the STD with the new driver +loaded. Otherwise, you have to identify what is wrong. + +a) To verify if there are any drivers that cause problems you can run the STD +in the test mode: + +# echo test /sys/power/disk +# echo disk /sys/power/state + +in which case the system should freeze tasks, suspend devices, disable nonboot +CPUs (if any), wait for 5 seconds, enable nonboot CPUs, resume devices, thaw +tasks and return to your command prompt. If that fails, most likely there is +a driver that fails to either suspend or resume (in the
