The hrtimer callback pcsp_do_timer() prepares rearming of the timer with
hrtimer_forward(). hrtimer_forward() is intended to provide a mechanism to
forward the expiry time of the hrtimer by a multiple of the period argument
so that the expiry time greater than the time provided in the 'now'
argument.
pcsp_do_timer() invokes hrtimer_forward() with the current timer expiry
time as 'now' argument. That's providing a periodic timer expiry, but is
not really robust when the timer callback is delayed so that the resulting
new expiry time is already in the past which causes the callback to be
invoked immediately again. If the timer is delayed then the back to back
invocation is not really making it better than skipping the missed
periods. Sound is distorted in any case.
Use hrtimer_forward_now() which ensures that the next expiry is in the
future. This prevents hogging the CPU in the timer expiry code and allows
later on to remove hrtimer_forward() from the public interfaces.
Signed-off-by: Thomas Gleixner <[email protected]>
Cc: [email protected]
Cc: Takashi Iwai <[email protected]>
Cc: Jaroslav Kysela <[email protected]>
---
sound/drivers/pcsp/pcsp_lib.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/sound/drivers/pcsp/pcsp_lib.c
+++ b/sound/drivers/pcsp/pcsp_lib.c
@@ -143,7 +143,7 @@ enum hrtimer_restart pcsp_do_timer(struc
if (pointer_update)
pcsp_pointer_update(chip);
- hrtimer_forward(handle, hrtimer_get_expires(handle), ns_to_ktime(ns));
+ hrtimer_forward_now(handle, ns_to_ktime(ns));
return HRTIMER_RESTART;
}
On Thu, 23 Sep 2021 18:04:25 +0200,
Thomas Gleixner wrote:
>
> The hrtimer callback pcsp_do_timer() prepares rearming of the timer with
> hrtimer_forward(). hrtimer_forward() is intended to provide a mechanism to
> forward the expiry time of the hrtimer by a multiple of the period argument
> so that the expiry time greater than the time provided in the 'now'
> argument.
>
> pcsp_do_timer() invokes hrtimer_forward() with the current timer expiry
> time as 'now' argument. That's providing a periodic timer expiry, but is
> not really robust when the timer callback is delayed so that the resulting
> new expiry time is already in the past which causes the callback to be
> invoked immediately again. If the timer is delayed then the back to back
> invocation is not really making it better than skipping the missed
> periods. Sound is distorted in any case.
>
> Use hrtimer_forward_now() which ensures that the next expiry is in the
> future. This prevents hogging the CPU in the timer expiry code and allows
> later on to remove hrtimer_forward() from the public interfaces.
>
> Signed-off-by: Thomas Gleixner <[email protected]>
> Cc: [email protected]
> Cc: Takashi Iwai <[email protected]>
> Cc: Jaroslav Kysela <[email protected]>
Thanks, applied now to sound git tree.
Takashi