All of lore.kernel.org
 help / color / mirror / Atom feed
From: viresh.kumar@linaro.org (Viresh Kumar)
To: linux-arm-kernel@lists.infradead.org
Subject: smp_twd fix for adapting to cpu frequency change
Date: Fri, 15 May 2015 08:54:36 +0530	[thread overview]
Message-ID: <20150515032436.GF6348@linux> (raw)
In-Reply-To: <20150514144856.GA2067@n2100.arm.linux.org.uk>

On 14-05-15, 15:48, Russell King - ARM Linux wrote:
> This is not correct.
> 
> int __clockevents_update_freq(struct clock_event_device *dev, u32 freq)
> {
>         clockevents_config(dev, freq);
> 
>         if (dev->state == CLOCK_EVT_STATE_ONESHOT)
>                 return clockevents_program_event(dev, dev->next_event, false);
> 
>         if (dev->state == CLOCK_EVT_STATE_PERIODIC)
>                 return __clockevents_set_state(dev, CLOCK_EVT_STATE_PERIODIC);
> 
> The last two lines re-set the mode to periodic, which cause the ->set_mode
> (or its replacement) to be called.  When the driver's ->set_mode method is
> called, it is supposed to write the periodic timeout to the hardware.
> 
> So, this has the side effect of updating the hardware with the new timeout
> value.
> 
> The downside to this is that if you keep changing the clock rate before
> the TWD expires, you'll never see an interrupt from it, as you'll always
> re-start a new period from the beginning on every clock frequency change.

Ahh, this was correct when it was discussed earlier.

Commit fe79a9ba1196 ("clockevents: Adjust timer interval when
frequency changes"), fixed this in clockevents core.

-- 
viresh

      reply	other threads:[~2015-05-15  3:24 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-03 11:15 smp_twd fix for adapting to cpu frequency change shiraz hashim
2012-05-08 11:33 ` Linus Walleij
2012-05-08 11:40   ` Thomas Gleixner
2012-05-11  9:21   ` Shiraz Hashim
2012-05-11 12:46     ` Linus Walleij
2015-05-14 14:44   ` Viresh Kumar
2015-05-14 14:48     ` Russell King - ARM Linux
2015-05-15  3:24       ` Viresh Kumar [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150515032436.GF6348@linux \
    --to=viresh.kumar@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.