* Peter Zijlstra wrote:
> On Thu, Apr 02, 2015 at 07:20:50PM +0530, Viresh Kumar wrote:
> > > Or am I completely missing something?
> >
> > So yes, if we would have done that in tick_program_event(), it would have
> > been a single place for doing this change..
> >
> > But, when Thomas ranted
On Thu, Apr 02, 2015 at 07:20:50PM +0530, Viresh Kumar wrote:
> > Or am I completely missing something?
>
> So yes, if we would have done that in tick_program_event(), it would have
> been a single place for doing this change..
>
> But, when Thomas ranted [1] at me on this earlier, he said:
>
>
On 2 April 2015 at 19:04, Peter Zijlstra wrote:
> On Fri, Mar 27, 2015 at 10:44:28PM +0530, Viresh Kumar wrote:
>> +++ b/kernel/time/hrtimer.c
>> @@ -566,6 +566,7 @@ static int hrtimer_reprogram(struct hrtimer *timer,
>> {
>> + /* Switchback to ONESHOT state */
>> + if (unlikely(dev->st
On Fri, Mar 27, 2015 at 10:44:28PM +0530, Viresh Kumar wrote:
> Only hrtimer_reprogram() is responsible for programming the clockevent device
> for next event, if the clockevent device is stopped earlier. And updating that
> alone is sufficient here.
> +++ b/kernel/time/hrtimer.c
> @@ -566,6 +566,
On 03/27/2015 10:44 PM, Viresh Kumar wrote:
> Next commit would update clockevents core to switch clockevent devices to
> ONESHOT_STOPPED state to avoid getting spurious interrupts on a tickless CPU.
>
> Before programming the clockevent device for next event, we must switch its
> state to ONESHOT
Next commit would update clockevents core to switch clockevent devices to
ONESHOT_STOPPED state to avoid getting spurious interrupts on a tickless CPU.
Before programming the clockevent device for next event, we must switch its
state to ONESHOT.
Switch state back to ONESHOT from ONESHOT_STOPPED a
6 matches
Mail list logo
