On 07/18/14 17:14, John Stultz wrote:
> On 07/18/2014 04:24 PM, Stephen Boyd wrote:
>> On 07/18/14 15:42, John Stultz wrote:
>>> If its a regression (and needs -stable backports) it needs to go in via
>>> tip/timers/urgent, and not via the regular merge window.
>>>
>>> Whats the additional risk
On 07/18/14 17:14, John Stultz wrote:
On 07/18/2014 04:24 PM, Stephen Boyd wrote:
On 07/18/14 15:42, John Stultz wrote:
If its a regression (and needs -stable backports) it needs to go in via
tip/timers/urgent, and not via the regular merge window.
Whats the additional risk -stable wise for
On 07/18/2014 04:24 PM, Stephen Boyd wrote:
> On 07/18/14 15:42, John Stultz wrote:
>> If its a regression (and needs -stable backports) it needs to go in via
>> tip/timers/urgent, and not via the regular merge window.
>>
>> Whats the additional risk -stable wise for canceling the timer during
>>
On 07/18/14 15:42, John Stultz wrote:
> If its a regression (and needs -stable backports) it needs to go in via
> tip/timers/urgent, and not via the regular merge window.
>
> Whats the additional risk -stable wise for canceling the timer during
> suspend and starting it back up during resume?
>
On 07/18/2014 03:38 PM, Stephen Boyd wrote:
> On 07/18/14 15:25, John Stultz wrote:
>> On 07/18/2014 03:09 PM, Stephen Boyd wrote:
>>> During suspend we call sched_clock_poll() to update the epoch and
>>> accumulated time and reprogram the sched_clock_timer to fire
>>> before the next wrap-around
On 07/18/14 15:25, John Stultz wrote:
> On 07/18/2014 03:09 PM, Stephen Boyd wrote:
>> During suspend we call sched_clock_poll() to update the epoch and
>> accumulated time and reprogram the sched_clock_timer to fire
>> before the next wrap-around time. Unfortunately,
>> sched_clock_poll() doesn't
On 07/18/2014 03:09 PM, Stephen Boyd wrote:
> During suspend we call sched_clock_poll() to update the epoch and
> accumulated time and reprogram the sched_clock_timer to fire
> before the next wrap-around time. Unfortunately,
> sched_clock_poll() doesn't restart the timer, instead it relies
> on
On 07/18/2014 03:09 PM, Stephen Boyd wrote:
During suspend we call sched_clock_poll() to update the epoch and
accumulated time and reprogram the sched_clock_timer to fire
before the next wrap-around time. Unfortunately,
sched_clock_poll() doesn't restart the timer, instead it relies
on the
On 07/18/14 15:25, John Stultz wrote:
On 07/18/2014 03:09 PM, Stephen Boyd wrote:
During suspend we call sched_clock_poll() to update the epoch and
accumulated time and reprogram the sched_clock_timer to fire
before the next wrap-around time. Unfortunately,
sched_clock_poll() doesn't restart
On 07/18/2014 03:38 PM, Stephen Boyd wrote:
On 07/18/14 15:25, John Stultz wrote:
On 07/18/2014 03:09 PM, Stephen Boyd wrote:
During suspend we call sched_clock_poll() to update the epoch and
accumulated time and reprogram the sched_clock_timer to fire
before the next wrap-around time.
On 07/18/14 15:42, John Stultz wrote:
If its a regression (and needs -stable backports) it needs to go in via
tip/timers/urgent, and not via the regular merge window.
Whats the additional risk -stable wise for canceling the timer during
suspend and starting it back up during resume?
I'd say
On 07/18/2014 04:24 PM, Stephen Boyd wrote:
On 07/18/14 15:42, John Stultz wrote:
If its a regression (and needs -stable backports) it needs to go in via
tip/timers/urgent, and not via the regular merge window.
Whats the additional risk -stable wise for canceling the timer during
suspend and
12 matches
Mail list logo