Re: [PATCH 1/2] PM: use dpm_run_callback in device_prepare
On Fri, 2013-06-07 at 18:15 -0700, Greg KH wrote: > On Sat, Jun 08, 2013 at 08:43:55AM +0800, Yanmin Zhang wrote: > > On Fri, 2013-06-07 at 10:37 -0700, Greg KH wrote: > > > On Fri, Jun 07, 2013 at 04:20:31PM +0800, shuox@intel.com wrote: > > > > From: ShuoX Liu > > > > > > > > dpm_run_callback could show more debug info around prepare stage. > > > > > > Why? Who needs this? What problem does it solve? > > > > > > Without answers to this, why would you expect us to accept such a > > > change? > > It's to provide more debug info and developers can quickly find what > > prepare/complete callback consumes too much time. > > What exact debug info is this providing, and why wouldn't you say all of > this in the original changelog information? Thanks for the reminder. Below are examples, after applying the patches. We can see clearly how much time every device prepare callback consumes. [ 600.384779] sr 1:0:0:0: preparing bus suspend [ 600.384780] call 1:0:0:0+ returned 0 after 2 usecs [ 600.384785] calling 2-1+ @ 2556, parent: usb2 [ 600.384788] usb 2-1: preparing type suspend [ 600.384789] call 2-1+ returned 0 after 2 usecs [ 600.384794] calling 1-1.1+ @ 2556, parent: 1-1 [ 600.384797] usb 1-1.1: preparing type suspend [ 600.384799] call 1-1.1+ returned 0 after 2 usecs [ 600.384802] calling 1-1.3+ @ 2556, parent: 1-1 [ 600.384804] usb 1-1.3: preparing type suspend [ 600.384805] call 1-1.3+ returned 0 after 2 usecs [ 600.384809] calling 1-1.4+ @ 2556, parent: 1-1 [ 600.384811] usb 1-1.4: preparing type suspend [ 600.384813] call 1-1.4+ returned 0 after 2 usecs [ 600.384816] calling 1-1.5+ @ 2556, parent: 1-1 [ 600.384819] usb 1-1.5: preparing type suspend, may wakeup [ 600.384820] call 1-1.5+ returned 0 after 2 usecs [ 600.384823] calling 1-1.4.1+ @ 2556, parent: 1-1.4 [ 600.384825] usb 1-1.4.1: preparing type suspend [ 600.384827] call 1-1.4.1+ returned 0 after 2 usecs [ 600.384829] calling 1-1.4.2+ @ 2556, parent: 1-1.4 [ 600.384831] usb 1-1.4.2: preparing type suspend [ 600.384833] call 1-1.4.2+ returned 0 after 2 usecs [ 600.384865] PM: prepare suspend of devices complete after 0.471 msecs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] PM: use dpm_run_callback in device_prepare
On Sat, Jun 08, 2013 at 08:43:55AM +0800, Yanmin Zhang wrote:
> On Fri, 2013-06-07 at 10:37 -0700, Greg KH wrote:
> > On Fri, Jun 07, 2013 at 04:20:31PM +0800, shuox@intel.com wrote:
> > > From: ShuoX Liu
> > >
> > > dpm_run_callback could show more debug info around prepare stage.
> >
> > Why? Who needs this? What problem does it solve?
> >
> > Without answers to this, why would you expect us to accept such a
> > change?
> It's to provide more debug info and developers can quickly find what
> prepare/complete callback consumes too much time.
What exact debug info is this providing, and why wouldn't you say all of
this in the original changelog information?
{hint}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] PM: use dpm_run_callback in device_prepare
On Fri, 2013-06-07 at 10:37 -0700, Greg KH wrote: > On Fri, Jun 07, 2013 at 04:20:31PM +0800, shuox@intel.com wrote: > > From: ShuoX Liu > > > > dpm_run_callback could show more debug info around prepare stage. > > Why? Who needs this? What problem does it solve? > > Without answers to this, why would you expect us to accept such a > change? It's to provide more debug info and developers can quickly find what prepare/complete callback consumes too much time. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] PM: use dpm_run_callback in device_prepare
On Fri, Jun 07, 2013 at 04:20:31PM +0800, shuox@intel.com wrote: > From: ShuoX Liu > > dpm_run_callback could show more debug info around prepare stage. Why? Who needs this? What problem does it solve? Without answers to this, why would you expect us to accept such a change? greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] PM: use dpm_run_callback in device_prepare
From: ShuoX Liu
dpm_run_callback could show more debug info around prepare stage.
Signed-off-by: Zhang Yanmin
Signed-off-by: Liu ShuoX
---
drivers/base/power/main.c |9 -
1 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
index 5a9b656..cb89323 100644
--- a/drivers/base/power/main.c
+++ b/drivers/base/power/main.c
@@ -1223,7 +1223,7 @@ int dpm_suspend(pm_message_t state)
*/
static int device_prepare(struct device *dev, pm_message_t state)
{
- int (*callback)(struct device *) = NULL;
+ pm_callback_t callback = NULL;
char *info = NULL;
int error = 0;
@@ -1261,10 +1261,7 @@ static int device_prepare(struct device *dev,
pm_message_t state)
callback = dev->driver->pm->prepare;
}
- if (callback) {
- error = callback(dev);
- suspend_report_result(callback, error);
- }
+ error = dpm_run_callback(callback, dev, state, info);
device_unlock(dev);
@@ -1280,6 +1277,7 @@ static int device_prepare(struct device *dev,
pm_message_t state)
int dpm_prepare(pm_message_t state)
{
int error = 0;
+ ktime_t starttime = ktime_get();
might_sleep();
@@ -1311,6 +1309,7 @@ int dpm_prepare(pm_message_t state)
put_device(dev);
}
mutex_unlock(_list_mtx);
+ dpm_show_time(starttime, state, "prepare");
return error;
}
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] PM: use dpm_run_callback in device_prepare
On Fri, Jun 07, 2013 at 04:20:31PM +0800, shuox@intel.com wrote: From: ShuoX Liu shuox@intel.com dpm_run_callback could show more debug info around prepare stage. Why? Who needs this? What problem does it solve? Without answers to this, why would you expect us to accept such a change? greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] PM: use dpm_run_callback in device_prepare
On Fri, 2013-06-07 at 10:37 -0700, Greg KH wrote: On Fri, Jun 07, 2013 at 04:20:31PM +0800, shuox@intel.com wrote: From: ShuoX Liu shuox@intel.com dpm_run_callback could show more debug info around prepare stage. Why? Who needs this? What problem does it solve? Without answers to this, why would you expect us to accept such a change? It's to provide more debug info and developers can quickly find what prepare/complete callback consumes too much time. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] PM: use dpm_run_callback in device_prepare
On Sat, Jun 08, 2013 at 08:43:55AM +0800, Yanmin Zhang wrote:
On Fri, 2013-06-07 at 10:37 -0700, Greg KH wrote:
On Fri, Jun 07, 2013 at 04:20:31PM +0800, shuox@intel.com wrote:
From: ShuoX Liu shuox@intel.com
dpm_run_callback could show more debug info around prepare stage.
Why? Who needs this? What problem does it solve?
Without answers to this, why would you expect us to accept such a
change?
It's to provide more debug info and developers can quickly find what
prepare/complete callback consumes too much time.
What exact debug info is this providing, and why wouldn't you say all of
this in the original changelog information?
{hint}
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] PM: use dpm_run_callback in device_prepare
On Fri, 2013-06-07 at 18:15 -0700, Greg KH wrote: On Sat, Jun 08, 2013 at 08:43:55AM +0800, Yanmin Zhang wrote: On Fri, 2013-06-07 at 10:37 -0700, Greg KH wrote: On Fri, Jun 07, 2013 at 04:20:31PM +0800, shuox@intel.com wrote: From: ShuoX Liu shuox@intel.com dpm_run_callback could show more debug info around prepare stage. Why? Who needs this? What problem does it solve? Without answers to this, why would you expect us to accept such a change? It's to provide more debug info and developers can quickly find what prepare/complete callback consumes too much time. What exact debug info is this providing, and why wouldn't you say all of this in the original changelog information? Thanks for the reminder. Below are examples, after applying the patches. We can see clearly how much time every device prepare callback consumes. [ 600.384779] sr 1:0:0:0: preparing bus suspend [ 600.384780] call 1:0:0:0+ returned 0 after 2 usecs [ 600.384785] calling 2-1+ @ 2556, parent: usb2 [ 600.384788] usb 2-1: preparing type suspend [ 600.384789] call 2-1+ returned 0 after 2 usecs [ 600.384794] calling 1-1.1+ @ 2556, parent: 1-1 [ 600.384797] usb 1-1.1: preparing type suspend [ 600.384799] call 1-1.1+ returned 0 after 2 usecs [ 600.384802] calling 1-1.3+ @ 2556, parent: 1-1 [ 600.384804] usb 1-1.3: preparing type suspend [ 600.384805] call 1-1.3+ returned 0 after 2 usecs [ 600.384809] calling 1-1.4+ @ 2556, parent: 1-1 [ 600.384811] usb 1-1.4: preparing type suspend [ 600.384813] call 1-1.4+ returned 0 after 2 usecs [ 600.384816] calling 1-1.5+ @ 2556, parent: 1-1 [ 600.384819] usb 1-1.5: preparing type suspend, may wakeup [ 600.384820] call 1-1.5+ returned 0 after 2 usecs [ 600.384823] calling 1-1.4.1+ @ 2556, parent: 1-1.4 [ 600.384825] usb 1-1.4.1: preparing type suspend [ 600.384827] call 1-1.4.1+ returned 0 after 2 usecs [ 600.384829] calling 1-1.4.2+ @ 2556, parent: 1-1.4 [ 600.384831] usb 1-1.4.2: preparing type suspend [ 600.384833] call 1-1.4.2+ returned 0 after 2 usecs [ 600.384865] PM: prepare suspend of devices complete after 0.471 msecs -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] PM: use dpm_run_callback in device_prepare
From: ShuoX Liu shuox@intel.com
dpm_run_callback could show more debug info around prepare stage.
Signed-off-by: Zhang Yanmin yanmin.zh...@intel.com
Signed-off-by: Liu ShuoX shuox@intel.com
---
drivers/base/power/main.c |9 -
1 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
index 5a9b656..cb89323 100644
--- a/drivers/base/power/main.c
+++ b/drivers/base/power/main.c
@@ -1223,7 +1223,7 @@ int dpm_suspend(pm_message_t state)
*/
static int device_prepare(struct device *dev, pm_message_t state)
{
- int (*callback)(struct device *) = NULL;
+ pm_callback_t callback = NULL;
char *info = NULL;
int error = 0;
@@ -1261,10 +1261,7 @@ static int device_prepare(struct device *dev,
pm_message_t state)
callback = dev-driver-pm-prepare;
}
- if (callback) {
- error = callback(dev);
- suspend_report_result(callback, error);
- }
+ error = dpm_run_callback(callback, dev, state, info);
device_unlock(dev);
@@ -1280,6 +1277,7 @@ static int device_prepare(struct device *dev,
pm_message_t state)
int dpm_prepare(pm_message_t state)
{
int error = 0;
+ ktime_t starttime = ktime_get();
might_sleep();
@@ -1311,6 +1309,7 @@ int dpm_prepare(pm_message_t state)
put_device(dev);
}
mutex_unlock(dpm_list_mtx);
+ dpm_show_time(starttime, state, prepare);
return error;
}
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
