Hi Rafael,
Thank you very much for your comments and feedback
I have planned to drop this one now. Before I close, I would just
share few more comments and idea behind this.
Before queueing next suspend, we track wakeup event counts
consistently for drivers registered to wakeup events, to know
Hi Rafael,
Thank you very much for your comments and feedback
I have planned to drop this one now. Before I close, I would just
share few more comments and idea behind this.
Before queueing next suspend, we track wakeup event counts
consistently for drivers registered to wakeup events, to know
On Tuesday, July 14, 2015 09:34:08 AM Nitish Ambastha wrote:
> On Tue, Jul 14, 2015 at 5:13 AM, Rafael J. Wysocki wrote:
> > On Tuesday, July 14, 2015 01:38:02 AM Nitish Ambastha wrote:
> >> Prevent tight loop for suspend-resume when some
> >> devices failed to suspend
> >
> > This *still*
On Tuesday, July 14, 2015 09:34:08 AM Nitish Ambastha wrote:
On Tue, Jul 14, 2015 at 5:13 AM, Rafael J. Wysocki r...@rjwysocki.net wrote:
On Tuesday, July 14, 2015 01:38:02 AM Nitish Ambastha wrote:
Prevent tight loop for suspend-resume when some
devices failed to suspend
This *still*
On Tue, Jul 14, 2015 at 5:13 AM, Rafael J. Wysocki wrote:
> On Tuesday, July 14, 2015 01:38:02 AM Nitish Ambastha wrote:
>> Prevent tight loop for suspend-resume when some
>> devices failed to suspend
>
> This *still* doesn't explain what problem you're *really* trying to address.
>
> Even if a
On Tuesday, July 14, 2015 01:38:02 AM Nitish Ambastha wrote:
> Prevent tight loop for suspend-resume when some
> devices failed to suspend
This *still* doesn't explain what problem you're *really* trying to address.
Even if a driver returns an error code from one of its suspend callbacks,
you
I have uploaded a new patch as per comments
Since some drivers failed to suspend, and is/are not registered to
wakeup sources fwk, we cannot keep trying suspend based on wakeup
event count. It looks valid to me to wait before queuing another
suspend request tightly
Please let me know if this is
Prevent tight loop for suspend-resume when some
devices failed to suspend
If some devices failed to suspend, we monitor this
error in try_to_suspend(). pm_suspend() is already
an 'int' returning function, how about checking return
from pm_suspend() before queueing suspend again?
For devices which
On Tue, Jul 14, 2015 at 5:13 AM, Rafael J. Wysocki r...@rjwysocki.net wrote:
On Tuesday, July 14, 2015 01:38:02 AM Nitish Ambastha wrote:
Prevent tight loop for suspend-resume when some
devices failed to suspend
This *still* doesn't explain what problem you're *really* trying to address.
Prevent tight loop for suspend-resume when some
devices failed to suspend
If some devices failed to suspend, we monitor this
error in try_to_suspend(). pm_suspend() is already
an 'int' returning function, how about checking return
from pm_suspend() before queueing suspend again?
For devices which
I have uploaded a new patch as per comments
Since some drivers failed to suspend, and is/are not registered to
wakeup sources fwk, we cannot keep trying suspend based on wakeup
event count. It looks valid to me to wait before queuing another
suspend request tightly
Please let me know if this is
On Tuesday, July 14, 2015 01:38:02 AM Nitish Ambastha wrote:
Prevent tight loop for suspend-resume when some
devices failed to suspend
This *still* doesn't explain what problem you're *really* trying to address.
Even if a driver returns an error code from one of its suspend callbacks,
you
12 matches
Mail list logo
