[PATCH] PM: HIBERNATION: add resume_wait param to support MMC-like devices as resume file

[PATCH] PM: HIBERNATION: add resume_wait param to support MMC-like devices as resume file

[Barry Song]

From: Barry Song <baohua.song@csr.com>

Some devices like mmc are async detected very slow. For example,
drivers/mmc/host/sdhci.c launchs a 200ms delayed work to detect
mmc partitions then add disk.

we do have wait_for_device_probe and scsi_complete_async_scans
before calling swsusp_check, but it is not enough to wait mmc.

This patch adds resumewait kernel param just like rootwait so
that we have enough time to wait mmc ready. The differene is
here we wait for resume partition but rootwait waits for rootfs
partition.

This patch will make swsusp support many embedded products
without scsi devices but devices like mmc.

This was tested on one ARM platform with Frank Hofmann's patch.

Signed-off-by: Barry Song <Baohua.Song@csr.com>
---
 kernel/power/hibernate.c |   16 ++++++++++++++++
 1 files changed, 16 insertions(+), 0 deletions(-)

diff --git a/kernel/power/hibernate.c b/kernel/power/hibernate.c
index 8f7b1db..9f4b4f3 100644
--- a/kernel/power/hibernate.c
+++ b/kernel/power/hibernate.c
@@ -14,6 +14,7 @@
 #include <linux/reboot.h>
 #include <linux/string.h>
 #include <linux/device.h>
+#include <linux/async.h>
 #include <linux/kmod.h>
 #include <linux/delay.h>
 #include <linux/fs.h>
@@ -31,6 +32,7 @@
 
 static int nocompress = 0;
 static int noresume = 0;
+static int resume_wait = 0;
 static char resume_file[256] = CONFIG_PM_STD_PARTITION;
 dev_t swsusp_resume_device;
 sector_t swsusp_resume_block;
@@ -732,6 +734,13 @@ static int software_resume(void)
 		 * to wait for this to finish.
 		 */
 		wait_for_device_probe();
+
+		if (resume_wait) {
+			while ((swsusp_resume_device = name_to_dev_t(resume_file)) == 0)
+				msleep(10);
+			async_synchronize_full();
+		}
+
 		/*
 		 * We can't depend on SCSI devices being available after loading
 		 * one of their modules until scsi_complete_async_scans() is
@@ -1060,7 +1069,14 @@ static int __init noresume_setup(char *str)
 	return 1;
 }
 
+static int __init resumewait_setup(char *str)
+{
+	resume_wait = 1;
+	return 1;
+}
+
 __setup("noresume", noresume_setup);
 __setup("resume_offset=", resume_offset_setup);
 __setup("resume=", resume_setup);
 __setup("hibernate=", hibernate_setup);
+__setup("resumewait", resumewait_setup);
-- 
1.7.1



Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
More information can be found at www.csr.com. Follow CSR on Twitter at http://twitter.com/CSR_PLC and read our blog at www.csr.com/blog

[PATCH] PM: HIBERNATION: add resume_wait param to support MMC-like devices as resume file

[Barry Song]

From: Barry Song <baohua.song@csr.com>

Some devices like mmc are async detected very slow. For example,
drivers/mmc/host/sdhci.c launchs a 200ms delayed work to detect
mmc partitions then add disk.

we do have wait_for_device_probe and scsi_complete_async_scans
before calling swsusp_check, but it is not enough to wait mmc.

This patch adds resumewait kernel param just like rootwait so
that we have enough time to wait mmc ready. The differene is
here we wait for resume partition but rootwait waits for rootfs
partition.

This patch will make swsusp support many embedded products
without scsi devices but devices like mmc.

This was tested on one ARM platform with Frank Hofmann's patch.

Signed-off-by: Barry Song <Baohua.Song@csr.com>
---
 kernel/power/hibernate.c |   16 ++++++++++++++++
 1 files changed, 16 insertions(+), 0 deletions(-)

diff --git a/kernel/power/hibernate.c b/kernel/power/hibernate.c
index 8f7b1db..9f4b4f3 100644
--- a/kernel/power/hibernate.c
+++ b/kernel/power/hibernate.c
@@ -14,6 +14,7 @@
 #include <linux/reboot.h>
 #include <linux/string.h>
 #include <linux/device.h>
+#include <linux/async.h>
 #include <linux/kmod.h>
 #include <linux/delay.h>
 #include <linux/fs.h>
@@ -31,6 +32,7 @@
 
 static int nocompress = 0;
 static int noresume = 0;
+static int resume_wait = 0;
 static char resume_file[256] = CONFIG_PM_STD_PARTITION;
 dev_t swsusp_resume_device;
 sector_t swsusp_resume_block;
@@ -732,6 +734,13 @@ static int software_resume(void)
 		 * to wait for this to finish.
 		 */
 		wait_for_device_probe();
+
+		if (resume_wait) {
+			while ((swsusp_resume_device = name_to_dev_t(resume_file)) == 0)
+				msleep(10);
+			async_synchronize_full();
+		}
+
 		/*
 		 * We can't depend on SCSI devices being available after loading
 		 * one of their modules until scsi_complete_async_scans() is
@@ -1060,7 +1069,14 @@ static int __init noresume_setup(char *str)
 	return 1;
 }
 
+static int __init resumewait_setup(char *str)
+{
+	resume_wait = 1;
+	return 1;
+}
+
 __setup("noresume", noresume_setup);
 __setup("resume_offset=", resume_offset_setup);
 __setup("resume=", resume_setup);
 __setup("hibernate=", hibernate_setup);
+__setup("resumewait", resumewait_setup);
-- 
1.7.1



Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
More information can be found at www.csr.com. Follow CSR on Twitter at http://twitter.com/CSR_PLC and read our blog at www.csr.com/blog

[PATCH] PM: HIBERNATION: add resume_wait param to support MMC-like devices as resume file

[Barry Song]

From: Barry Song <baohua.song@csr.com>

Some devices like mmc are async detected very slow. For example,
drivers/mmc/host/sdhci.c launchs a 200ms delayed work to detect
mmc partitions then add disk.

we do have wait_for_device_probe and scsi_complete_async_scans
before calling swsusp_check, but it is not enough to wait mmc.

This patch adds resumewait kernel param just like rootwait so
that we have enough time to wait mmc ready. The differene is
here we wait for resume partition but rootwait waits for rootfs
partition.

This patch will make swsusp support many embedded products
without scsi devices but devices like mmc.

This was tested on one ARM platform with Frank Hofmann's patch.

Signed-off-by: Barry Song <Baohua.Song@csr.com>
---
 kernel/power/hibernate.c |   16 ++++++++++++++++
 1 files changed, 16 insertions(+), 0 deletions(-)

diff --git a/kernel/power/hibernate.c b/kernel/power/hibernate.c
index 8f7b1db..9f4b4f3 100644
--- a/kernel/power/hibernate.c
+++ b/kernel/power/hibernate.c
@@ -14,6 +14,7 @@
 #include <linux/reboot.h>
 #include <linux/string.h>
 #include <linux/device.h>
+#include <linux/async.h>
 #include <linux/kmod.h>
 #include <linux/delay.h>
 #include <linux/fs.h>
@@ -31,6 +32,7 @@
 
 static int nocompress = 0;
 static int noresume = 0;
+static int resume_wait = 0;
 static char resume_file[256] = CONFIG_PM_STD_PARTITION;
 dev_t swsusp_resume_device;
 sector_t swsusp_resume_block;
@@ -732,6 +734,13 @@ static int software_resume(void)
 		 * to wait for this to finish.
 		 */
 		wait_for_device_probe();
+
+		if (resume_wait) {
+			while ((swsusp_resume_device = name_to_dev_t(resume_file)) == 0)
+				msleep(10);
+			async_synchronize_full();
+		}
+
 		/*
 		 * We can't depend on SCSI devices being available after loading
 		 * one of their modules until scsi_complete_async_scans() is
@@ -1060,7 +1069,14 @@ static int __init noresume_setup(char *str)
 	return 1;
 }
 
+static int __init resumewait_setup(char *str)
+{
+	resume_wait = 1;
+	return 1;
+}
+
 __setup("noresume", noresume_setup);
 __setup("resume_offset=", resume_offset_setup);
 __setup("resume=", resume_setup);
 __setup("hibernate=", hibernate_setup);
+__setup("resumewait", resumewait_setup);
-- 
1.7.1



Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
More information can be found at www.csr.com. Follow CSR on Twitter at http://twitter.com/CSR_PLC and read our blog at www.csr.com/blog

Re: [PATCH] PM: HIBERNATION: add resume_wait param to support MMC-like devices as resume file

[Valdis.Kletnieks]

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

On Thu, 29 Sep 2011 02:29:08 PDT, Barry Song said:

> This patch adds resumewait kernel param just like rootwait so
> that we have enough time to wait mmc ready. The differene is
> here we wait for resume partition but rootwait waits for rootfs
> partition.

OK, seems a reasonable idea...

> kernel/power/hibernate.c |   16 ++++++++++++++++
> 1 files changed, 16 insertions(+), 0 deletions(-)

We have a __setup() parameter, this patch appears to be missing
a hunk for Documentation/kernel-parameters.txt?

Fix that issue, and you can stick this on there:

Reviewed-by: Valdis Kletnieks <valdis.kletnieks@vt.edu>

[-- Attachment #2: Type: application/pgp-signature, Size: 227 bytes --]

Re: [PATCH] PM: HIBERNATION: add resume_wait param to support MMC-like devices as resume file

[Valdis.Kletnieks]

[-- Attachment #1.1: Type: text/plain, Size: 614 bytes --]

On Thu, 29 Sep 2011 02:29:08 PDT, Barry Song said:

> This patch adds resumewait kernel param just like rootwait so
> that we have enough time to wait mmc ready. The differene is
> here we wait for resume partition but rootwait waits for rootfs
> partition.

OK, seems a reasonable idea...

> kernel/power/hibernate.c |   16 ++++++++++++++++
> 1 files changed, 16 insertions(+), 0 deletions(-)

We have a __setup() parameter, this patch appears to be missing
a hunk for Documentation/kernel-parameters.txt?

Fix that issue, and you can stick this on there:

Reviewed-by: Valdis Kletnieks <valdis.kletnieks@vt.edu>

[-- Attachment #1.2: Type: application/pgp-signature, Size: 227 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH] PM: HIBERNATION: add resume_wait param to support MMC-like devices as resume file

[Valdis.Kletnieks at vt.edu]

On Thu, 29 Sep 2011 02:29:08 PDT, Barry Song said:

> This patch adds resumewait kernel param just like rootwait so
> that we have enough time to wait mmc ready. The differene is
> here we wait for resume partition but rootwait waits for rootfs
> partition.

OK, seems a reasonable idea...

> kernel/power/hibernate.c |   16 ++++++++++++++++
> 1 files changed, 16 insertions(+), 0 deletions(-)

We have a __setup() parameter, this patch appears to be missing
a hunk for Documentation/kernel-parameters.txt?

Fix that issue, and you can stick this on there:

Reviewed-by: Valdis Kletnieks <valdis.kletnieks@vt.edu>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20110929/d6c2e289/attachment.sig>

Re: [PATCH] PM: HIBERNATION: add resume_wait param to support MMC-like devices as resume file

[Barry Song]

hi Valdis,

2011/9/29  <Valdis.Kletnieks@vt.edu>:
> On Thu, 29 Sep 2011 02:29:08 PDT, Barry Song said:
>
>> This patch adds resumewait kernel param just like rootwait so
>> that we have enough time to wait mmc ready. The differene is
>> here we wait for resume partition but rootwait waits for rootfs
>> partition.
>
> OK, seems a reasonable idea...
>
>> kernel/power/hibernate.c |   16 ++++++++++++++++
>> 1 files changed, 16 insertions(+), 0 deletions(-)
>
> We have a __setup() parameter, this patch appears to be missing
> a hunk for Documentation/kernel-parameters.txt?
>
> Fix that issue, and you can stick this on there:
>
> Reviewed-by: Valdis Kletnieks <valdis.kletnieks@vt.edu>

thanks. i'll add the document in v2.

-barry

[PATCH] PM: HIBERNATION: add resume_wait param to support MMC-like devices as resume file

[Barry Song]

hi Valdis,

2011/9/29  <Valdis.Kletnieks@vt.edu>:
> On Thu, 29 Sep 2011 02:29:08 PDT, Barry Song said:
>
>> This patch adds resumewait kernel param just like rootwait so
>> that we have enough time to wait mmc ready. The differene is
>> here we wait for resume partition but rootwait waits for rootfs
>> partition.
>
> OK, seems a reasonable idea...
>
>> kernel/power/hibernate.c | ? 16 ++++++++++++++++
>> 1 files changed, 16 insertions(+), 0 deletions(-)
>
> We have a __setup() parameter, this patch appears to be missing
> a hunk for Documentation/kernel-parameters.txt?
>
> Fix that issue, and you can stick this on there:
>
> Reviewed-by: Valdis Kletnieks <valdis.kletnieks@vt.edu>

thanks. i'll add the document in v2.

-barry

Re: [PATCH] PM: HIBERNATION: add resume_wait param to support MMC-like devices as resume file

[Luca Tettamanti]

On Thu, Sep 29, 2011 at 11:29 AM, Barry Song <Barry.Song@csr.com> wrote:
> From: Barry Song <baohua.song@csr.com>
>
> Some devices like mmc are async detected very slow. For example,
> drivers/mmc/host/sdhci.c launchs a 200ms delayed work to detect
> mmc partitions then add disk.
>
> we do have wait_for_device_probe and scsi_complete_async_scans
> before calling swsusp_check, but it is not enough to wait mmc.
>
> This patch adds resumewait kernel param just like rootwait so
> that we have enough time to wait mmc ready. The differene is
> here we wait for resume partition but rootwait waits for rootfs
> partition.

I assume that such a device would need "rootwait" to boot in the first
place; why don't you "overload" the param to also enable waiting in
the resume path?

Luca

[PATCH] PM: HIBERNATION: add resume_wait param to support MMC-like devices as resume file

[Luca Tettamanti]

On Thu, Sep 29, 2011 at 11:29 AM, Barry Song <Barry.Song@csr.com> wrote:
> From: Barry Song <baohua.song@csr.com>
>
> Some devices like mmc are async detected very slow. For example,
> drivers/mmc/host/sdhci.c launchs a 200ms delayed work to detect
> mmc partitions then add disk.
>
> we do have wait_for_device_probe and scsi_complete_async_scans
> before calling swsusp_check, but it is not enough to wait mmc.
>
> This patch adds resumewait kernel param just like rootwait so
> that we have enough time to wait mmc ready. The differene is
> here we wait for resume partition but rootwait waits for rootfs
> partition.

I assume that such a device would need "rootwait" to boot in the first
place; why don't you "overload" the param to also enable waiting in
the resume path?

Luca

Re: [PATCH] PM: HIBERNATION: add resume_wait param to support MMC-like devices as resume file

[Luca Tettamanti]

On Thu, Sep 29, 2011 at 5:47 PM, Luca Tettamanti <kronos.it@gmail.com> wrote:
> On Thu, Sep 29, 2011 at 11:29 AM, Barry Song <Barry.Song@csr.com> wrote:
>> From: Barry Song <baohua.song@csr.com>
>>
>> Some devices like mmc are async detected very slow. For example,
>> drivers/mmc/host/sdhci.c launchs a 200ms delayed work to detect
>> mmc partitions then add disk.
>>
>> we do have wait_for_device_probe and scsi_complete_async_scans
>> before calling swsusp_check, but it is not enough to wait mmc.
>>
>> This patch adds resumewait kernel param just like rootwait so
>> that we have enough time to wait mmc ready. The differene is
>> here we wait for resume partition but rootwait waits for rootfs
>> partition.
>
> I assume that such a device would need "rootwait" to boot in the first
> place; why don't you "overload" the param to also enable waiting in
> the resume path?

And in case that makes sense, it might be worthwhile to refactor a
common helper to be also used in do_mounts.c, e.g.
dev_t wait_for_device(char *name)

L

[PATCH] PM: HIBERNATION: add resume_wait param to support MMC-like devices as resume file

[Luca Tettamanti]

On Thu, Sep 29, 2011 at 5:47 PM, Luca Tettamanti <kronos.it@gmail.com> wrote:
> On Thu, Sep 29, 2011 at 11:29 AM, Barry Song <Barry.Song@csr.com> wrote:
>> From: Barry Song <baohua.song@csr.com>
>>
>> Some devices like mmc are async detected very slow. For example,
>> drivers/mmc/host/sdhci.c launchs a 200ms delayed work to detect
>> mmc partitions then add disk.
>>
>> we do have wait_for_device_probe and scsi_complete_async_scans
>> before calling swsusp_check, but it is not enough to wait mmc.
>>
>> This patch adds resumewait kernel param just like rootwait so
>> that we have enough time to wait mmc ready. The differene is
>> here we wait for resume partition but rootwait waits for rootfs
>> partition.
>
> I assume that such a device would need "rootwait" to boot in the first
> place; why don't you "overload" the param to also enable waiting in
> the resume path?

And in case that makes sense, it might be worthwhile to refactor a
common helper to be also used in do_mounts.c, e.g.
dev_t wait_for_device(char *name)

L

Re: [PATCH] PM: HIBERNATION: add resume_wait param to support MMC-like devices as resume file

[Barry Song]

2011/9/29 Luca Tettamanti <kronos.it@gmail.com>:
> On Thu, Sep 29, 2011 at 11:29 AM, Barry Song <Barry.Song@csr.com> wrote:
>> From: Barry Song <baohua.song@csr.com>
>>
>> Some devices like mmc are async detected very slow. For example,
>> drivers/mmc/host/sdhci.c launchs a 200ms delayed work to detect
>> mmc partitions then add disk.
>>
>> we do have wait_for_device_probe and scsi_complete_async_scans
>> before calling swsusp_check, but it is not enough to wait mmc.
>>
>> This patch adds resumewait kernel param just like rootwait so
>> that we have enough time to wait mmc ready. The differene is
>> here we wait for resume partition but rootwait waits for rootfs
>> partition.
>
> I assume that such a device would need "rootwait" to boot in the first
> place; why don't you "overload" the param to also enable waiting in
> the resume path?

not real. for an embedded product, the type of the rootfs, the place
of the rootfs  and the way to mount rootfs are pretty flexible.
even though both rootfs and resume file use mmc, they will be in
different partitions at least. so i don't think rootwait can overload
resumewait.


>
> Luca
>
-barry

[PATCH] PM: HIBERNATION: add resume_wait param to support MMC-like devices as resume file

[Barry Song]

2011/9/29 Luca Tettamanti <kronos.it@gmail.com>:
> On Thu, Sep 29, 2011 at 11:29 AM, Barry Song <Barry.Song@csr.com> wrote:
>> From: Barry Song <baohua.song@csr.com>
>>
>> Some devices like mmc are async detected very slow. For example,
>> drivers/mmc/host/sdhci.c launchs a 200ms delayed work to detect
>> mmc partitions then add disk.
>>
>> we do have wait_for_device_probe and scsi_complete_async_scans
>> before calling swsusp_check, but it is not enough to wait mmc.
>>
>> This patch adds resumewait kernel param just like rootwait so
>> that we have enough time to wait mmc ready. The differene is
>> here we wait for resume partition but rootwait waits for rootfs
>> partition.
>
> I assume that such a device would need "rootwait" to boot in the first
> place; why don't you "overload" the param to also enable waiting in
> the resume path?

not real. for an embedded product, the type of the rootfs, the place
of the rootfs  and the way to mount rootfs are pretty flexible.
even though both rootfs and resume file use mmc, they will be in
different partitions at least. so i don't think rootwait can overload
resumewait.


>
> Luca
>
-barry

Re: [PATCH] PM: HIBERNATION: add resume_wait param to support MMC-like devices as resume file

[Barry Song]

2011/9/29 Luca Tettamanti <kronos.it@gmail.com>:
> On Thu, Sep 29, 2011 at 5:47 PM, Luca Tettamanti <kronos.it@gmail.com> wrote:
>> On Thu, Sep 29, 2011 at 11:29 AM, Barry Song <Barry.Song@csr.com> wrote:
>>> From: Barry Song <baohua.song@csr.com>
>>>
>>> Some devices like mmc are async detected very slow. For example,
>>> drivers/mmc/host/sdhci.c launchs a 200ms delayed work to detect
>>> mmc partitions then add disk.
>>>
>>> we do have wait_for_device_probe and scsi_complete_async_scans
>>> before calling swsusp_check, but it is not enough to wait mmc.
>>>
>>> This patch adds resumewait kernel param just like rootwait so
>>> that we have enough time to wait mmc ready. The differene is
>>> here we wait for resume partition but rootwait waits for rootfs
>>> partition.
>>
>> I assume that such a device would need "rootwait" to boot in the first
>> place; why don't you "overload" the param to also enable waiting in
>> the resume path?
>
> And in case that makes sense, it might be worthwhile to refactor a
> common helper to be also used in do_mounts.c, e.g.
> dev_t wait_for_device(char *name)

it is ok until we have many cases which wait for devices by polling.
but there are only two by the moment.
here i don't see it is worthwhile since the current codes are short
and clear enough.

>
> L

-barry

[PATCH] PM: HIBERNATION: add resume_wait param to support MMC-like devices as resume file

[Barry Song]

2011/9/29 Luca Tettamanti <kronos.it@gmail.com>:
> On Thu, Sep 29, 2011 at 5:47 PM, Luca Tettamanti <kronos.it@gmail.com> wrote:
>> On Thu, Sep 29, 2011 at 11:29 AM, Barry Song <Barry.Song@csr.com> wrote:
>>> From: Barry Song <baohua.song@csr.com>
>>>
>>> Some devices like mmc are async detected very slow. For example,
>>> drivers/mmc/host/sdhci.c launchs a 200ms delayed work to detect
>>> mmc partitions then add disk.
>>>
>>> we do have wait_for_device_probe and scsi_complete_async_scans
>>> before calling swsusp_check, but it is not enough to wait mmc.
>>>
>>> This patch adds resumewait kernel param just like rootwait so
>>> that we have enough time to wait mmc ready. The differene is
>>> here we wait for resume partition but rootwait waits for rootfs
>>> partition.
>>
>> I assume that such a device would need "rootwait" to boot in the first
>> place; why don't you "overload" the param to also enable waiting in
>> the resume path?
>
> And in case that makes sense, it might be worthwhile to refactor a
> common helper to be also used in do_mounts.c, e.g.
> dev_t wait_for_device(char *name)

it is ok until we have many cases which wait for devices by polling.
but there are only two by the moment.
here i don't see it is worthwhile since the current codes are short
and clear enough.

>
> L

-barry

Re: [PATCH] PM: HIBERNATION: add resume_wait param to support MMC-like devices as resume file

[Rafael J. Wysocki]

On Thursday, September 29, 2011, Barry Song wrote:
> hi Valdis,
> 
> 2011/9/29  <Valdis.Kletnieks@vt.edu>:
> > On Thu, 29 Sep 2011 02:29:08 PDT, Barry Song said:
> >
> >> This patch adds resumewait kernel param just like rootwait so
> >> that we have enough time to wait mmc ready. The differene is
> >> here we wait for resume partition but rootwait waits for rootfs
> >> partition.
> >
> > OK, seems a reasonable idea...
> >
> >> kernel/power/hibernate.c |   16 ++++++++++++++++
> >> 1 files changed, 16 insertions(+), 0 deletions(-)
> >
> > We have a __setup() parameter, this patch appears to be missing
> > a hunk for Documentation/kernel-parameters.txt?
> >
> > Fix that issue, and you can stick this on there:
> >
> > Reviewed-by: Valdis Kletnieks <valdis.kletnieks@vt.edu>
> 
> thanks. i'll add the document in v2.

I can't find the v2.  Have you posted it already?

Rafael

[PATCH] PM: HIBERNATION: add resume_wait param to support MMC-like devices as resume file

[Rafael J. Wysocki]

On Thursday, September 29, 2011, Barry Song wrote:
> hi Valdis,
> 
> 2011/9/29  <Valdis.Kletnieks@vt.edu>:
> > On Thu, 29 Sep 2011 02:29:08 PDT, Barry Song said:
> >
> >> This patch adds resumewait kernel param just like rootwait so
> >> that we have enough time to wait mmc ready. The differene is
> >> here we wait for resume partition but rootwait waits for rootfs
> >> partition.
> >
> > OK, seems a reasonable idea...
> >
> >> kernel/power/hibernate.c |   16 ++++++++++++++++
> >> 1 files changed, 16 insertions(+), 0 deletions(-)
> >
> > We have a __setup() parameter, this patch appears to be missing
> > a hunk for Documentation/kernel-parameters.txt?
> >
> > Fix that issue, and you can stick this on there:
> >
> > Reviewed-by: Valdis Kletnieks <valdis.kletnieks@vt.edu>
> 
> thanks. i'll add the document in v2.

I can't find the v2.  Have you posted it already?

Rafael

Re: [PATCH] PM: HIBERNATION: add resume_wait param to support MMC-like devices as resume file

[Pavel Machek]

> 2011/9/29 Luca Tettamanti <kronos.it@gmail.com>:
> > On Thu, Sep 29, 2011 at 11:29 AM, Barry Song <Barry.Song@csr.com> wrote:
> >> From: Barry Song <baohua.song@csr.com>
> >>
> >> Some devices like mmc are async detected very slow. For example,
> >> drivers/mmc/host/sdhci.c launchs a 200ms delayed work to detect
> >> mmc partitions then add disk.
> >>
> >> we do have wait_for_device_probe and scsi_complete_async_scans
> >> before calling swsusp_check, but it is not enough to wait mmc.
> >>
> >> This patch adds resumewait kernel param just like rootwait so
> >> that we have enough time to wait mmc ready. The differene is
> >> here we wait for resume partition but rootwait waits for rootfs
> >> partition.
> >
> > I assume that such a device would need "rootwait" to boot in the first
> > place; why don't you "overload" the param to also enable waiting in
> > the resume path?
> 
> not real. for an embedded product, the type of the rootfs, the place
> of the rootfs  and the way to mount rootfs are pretty flexible.
> even though both rootfs and resume file use mmc, they will be in
> different partitions at least. so i don't think rootwait can overload
> resumewait.

It would be good to at least model it the same way. rootdelay allows
you to specify time, which is important for USB devices...

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCH] PM: HIBERNATION: add resume_wait param to support MMC-like devices as resume file

[Pavel Machek]

> 2011/9/29 Luca Tettamanti <kronos.it@gmail.com>:
> > On Thu, Sep 29, 2011 at 11:29 AM, Barry Song <Barry.Song@csr.com> wrote:
> >> From: Barry Song <baohua.song@csr.com>
> >>
> >> Some devices like mmc are async detected very slow. For example,
> >> drivers/mmc/host/sdhci.c launchs a 200ms delayed work to detect
> >> mmc partitions then add disk.
> >>
> >> we do have wait_for_device_probe and scsi_complete_async_scans
> >> before calling swsusp_check, but it is not enough to wait mmc.
> >>
> >> This patch adds resumewait kernel param just like rootwait so
> >> that we have enough time to wait mmc ready. The differene is
> >> here we wait for resume partition but rootwait waits for rootfs
> >> partition.
> >
> > I assume that such a device would need "rootwait" to boot in the first
> > place; why don't you "overload" the param to also enable waiting in
> > the resume path?
> 
> not real. for an embedded product, the type of the rootfs, the place
> of the rootfs  and the way to mount rootfs are pretty flexible.
> even though both rootfs and resume file use mmc, they will be in
> different partitions at least. so i don't think rootwait can overload
> resumewait.

It would be good to at least model it the same way. rootdelay allows
you to specify time, which is important for USB devices...

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[PATCH] PM: HIBERNATION: add resume_wait param to support MMC-like devices as resume file

[Pavel Machek]

> 2011/9/29 Luca Tettamanti <kronos.it@gmail.com>:
> > On Thu, Sep 29, 2011 at 11:29 AM, Barry Song <Barry.Song@csr.com> wrote:
> >> From: Barry Song <baohua.song@csr.com>
> >>
> >> Some devices like mmc are async detected very slow. For example,
> >> drivers/mmc/host/sdhci.c launchs a 200ms delayed work to detect
> >> mmc partitions then add disk.
> >>
> >> we do have wait_for_device_probe and scsi_complete_async_scans
> >> before calling swsusp_check, but it is not enough to wait mmc.
> >>
> >> This patch adds resumewait kernel param just like rootwait so
> >> that we have enough time to wait mmc ready. The differene is
> >> here we wait for resume partition but rootwait waits for rootfs
> >> partition.
> >
> > I assume that such a device would need "rootwait" to boot in the first
> > place; why don't you "overload" the param to also enable waiting in
> > the resume path?
> 
> not real. for an embedded product, the type of the rootfs, the place
> of the rootfs  and the way to mount rootfs are pretty flexible.
> even though both rootfs and resume file use mmc, they will be in
> different partitions at least. so i don't think rootwait can overload
> resumewait.

It would be good to at least model it the same way. rootdelay allows
you to specify time, which is important for USB devices...

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCH] PM: HIBERNATION: add resume_wait param to support MMC-like devices as resume file

[Barry Song]

2011/10/7 Pavel Machek <pavel@ucw.cz>:
>> 2011/9/29 Luca Tettamanti <kronos.it@gmail.com>:
>> > On Thu, Sep 29, 2011 at 11:29 AM, Barry Song <Barry.Song@csr.com> wrote:
>> >> From: Barry Song <baohua.song@csr.com>
>> >>
>> >> Some devices like mmc are async detected very slow. For example,
>> >> drivers/mmc/host/sdhci.c launchs a 200ms delayed work to detect
>> >> mmc partitions then add disk.
>> >>
>> >> we do have wait_for_device_probe and scsi_complete_async_scans
>> >> before calling swsusp_check, but it is not enough to wait mmc.
>> >>
>> >> This patch adds resumewait kernel param just like rootwait so
>> >> that we have enough time to wait mmc ready. The differene is
>> >> here we wait for resume partition but rootwait waits for rootfs
>> >> partition.
>> >
>> > I assume that such a device would need "rootwait" to boot in the first
>> > place; why don't you "overload" the param to also enable waiting in
>> > the resume path?
>>
>> not real. for an embedded product, the type of the rootfs, the place
>> of the rootfs  and the way to mount rootfs are pretty flexible.
>> even though both rootfs and resume file use mmc, they will be in
>> different partitions at least. so i don't think rootwait can overload
>> resumewait.
>
> It would be good to at least model it the same way. rootdelay allows
> you to specify time, which is important for USB devices...

actually i considered resumedelay before i sent this resumewait patch.
now resumedelay is not an indispensable feature to my application and
most other systems since they are able to wait for the swap devices
ready by resumewait.
but of course we can have the resumedelay param as well just like
rootdelay. since Rafael has applied this resumedelay patch,  i can
treat resumedelay as one new seperate patch.

>
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
>
-barry

[PATCH] PM: HIBERNATION: add resume_wait param to support MMC-like devices as resume file

[Barry Song]

2011/10/7 Pavel Machek <pavel@ucw.cz>:
>> 2011/9/29 Luca Tettamanti <kronos.it@gmail.com>:
>> > On Thu, Sep 29, 2011 at 11:29 AM, Barry Song <Barry.Song@csr.com> wrote:
>> >> From: Barry Song <baohua.song@csr.com>
>> >>
>> >> Some devices like mmc are async detected very slow. For example,
>> >> drivers/mmc/host/sdhci.c launchs a 200ms delayed work to detect
>> >> mmc partitions then add disk.
>> >>
>> >> we do have wait_for_device_probe and scsi_complete_async_scans
>> >> before calling swsusp_check, but it is not enough to wait mmc.
>> >>
>> >> This patch adds resumewait kernel param just like rootwait so
>> >> that we have enough time to wait mmc ready. The differene is
>> >> here we wait for resume partition but rootwait waits for rootfs
>> >> partition.
>> >
>> > I assume that such a device would need "rootwait" to boot in the first
>> > place; why don't you "overload" the param to also enable waiting in
>> > the resume path?
>>
>> not real. for an embedded product, the type of the rootfs, the place
>> of the rootfs ?and the way to mount rootfs are pretty flexible.
>> even though both rootfs and resume file use mmc, they will be in
>> different partitions at least. so i don't think rootwait can overload
>> resumewait.
>
> It would be good to at least model it the same way. rootdelay allows
> you to specify time, which is important for USB devices...

actually i considered resumedelay before i sent this resumewait patch.
now resumedelay is not an indispensable feature to my application and
most other systems since they are able to wait for the swap devices
ready by resumewait.
but of course we can have the resumedelay param as well just like
rootdelay. since Rafael has applied this resumedelay patch,  i can
treat resumedelay as one new seperate patch.

>
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
>
-barry

Re: [PATCH] PM: HIBERNATION: add resume_wait param to support MMC-like devices as resume file

[Barry Song]

2011/10/7 Barry Song <21cnbao@gmail.com>:
> 2011/10/7 Pavel Machek <pavel@ucw.cz>:
>>> 2011/9/29 Luca Tettamanti <kronos.it@gmail.com>:
>>> > On Thu, Sep 29, 2011 at 11:29 AM, Barry Song <Barry.Song@csr.com> wrote:
>>> >> From: Barry Song <baohua.song@csr.com>
>>> >>
>>> >> Some devices like mmc are async detected very slow. For example,
>>> >> drivers/mmc/host/sdhci.c launchs a 200ms delayed work to detect
>>> >> mmc partitions then add disk.
>>> >>
>>> >> we do have wait_for_device_probe and scsi_complete_async_scans
>>> >> before calling swsusp_check, but it is not enough to wait mmc.
>>> >>
>>> >> This patch adds resumewait kernel param just like rootwait so
>>> >> that we have enough time to wait mmc ready. The differene is
>>> >> here we wait for resume partition but rootwait waits for rootfs
>>> >> partition.
>>> >
>>> > I assume that such a device would need "rootwait" to boot in the first
>>> > place; why don't you "overload" the param to also enable waiting in
>>> > the resume path?
>>>
>>> not real. for an embedded product, the type of the rootfs, the place
>>> of the rootfs  and the way to mount rootfs are pretty flexible.
>>> even though both rootfs and resume file use mmc, they will be in
>>> different partitions at least. so i don't think rootwait can overload
>>> resumewait.
>>
>> It would be good to at least model it the same way. rootdelay allows
>> you to specify time, which is important for USB devices...
>
> actually i considered resumedelay before i sent this resumewait patch.
> now resumedelay is not an indispensable feature to my application and
> most other systems since they are able to wait for the swap devices
> ready by resumewait.
> but of course we can have the resumedelay param as well just like
> rootdelay. since Rafael has applied this resumedelay patch,  i can

 sorry for typo.  -> since Rafael has applied this *resumewait* patch

> treat resumedelay as one new seperate patch.
>
>>
>> --
>> (english) http://www.livejournal.com/~pavelmachek
>> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
>>
> -barry
>

[PATCH] PM: HIBERNATION: add resume_wait param to support MMC-like devices as resume file

[Barry Song]

2011/10/7 Barry Song <21cnbao@gmail.com>:
> 2011/10/7 Pavel Machek <pavel@ucw.cz>:
>>> 2011/9/29 Luca Tettamanti <kronos.it@gmail.com>:
>>> > On Thu, Sep 29, 2011 at 11:29 AM, Barry Song <Barry.Song@csr.com> wrote:
>>> >> From: Barry Song <baohua.song@csr.com>
>>> >>
>>> >> Some devices like mmc are async detected very slow. For example,
>>> >> drivers/mmc/host/sdhci.c launchs a 200ms delayed work to detect
>>> >> mmc partitions then add disk.
>>> >>
>>> >> we do have wait_for_device_probe and scsi_complete_async_scans
>>> >> before calling swsusp_check, but it is not enough to wait mmc.
>>> >>
>>> >> This patch adds resumewait kernel param just like rootwait so
>>> >> that we have enough time to wait mmc ready. The differene is
>>> >> here we wait for resume partition but rootwait waits for rootfs
>>> >> partition.
>>> >
>>> > I assume that such a device would need "rootwait" to boot in the first
>>> > place; why don't you "overload" the param to also enable waiting in
>>> > the resume path?
>>>
>>> not real. for an embedded product, the type of the rootfs, the place
>>> of the rootfs ?and the way to mount rootfs are pretty flexible.
>>> even though both rootfs and resume file use mmc, they will be in
>>> different partitions at least. so i don't think rootwait can overload
>>> resumewait.
>>
>> It would be good to at least model it the same way. rootdelay allows
>> you to specify time, which is important for USB devices...
>
> actually i considered resumedelay before i sent this resumewait patch.
> now resumedelay is not an indispensable feature to my application and
> most other systems since they are able to wait for the swap devices
> ready by resumewait.
> but of course we can have the resumedelay param as well just like
> rootdelay. since Rafael has applied this resumedelay patch, ?i can

 sorry for typo.  -> since Rafael has applied this *resumewait* patch

> treat resumedelay as one new seperate patch.
>
>>
>> --
>> (english) http://www.livejournal.com/~pavelmachek
>> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
>>
> -barry
>