[PATCH] watchdog: s3c2410_wdt: Only register for cpufreq on CPU_FREQ_S3C24XX

Tomasz Figa tomasz.figa at gmail.com
Mon Nov 25 18:31:30 EST 2013


On Monday 25 of November 2013 15:28:29 Doug Anderson wrote:
> Guenter,
> 
> On Mon, Nov 25, 2013 at 3:23 PM, Guenter Roeck <linux at roeck-us.net> wrote:
> > On 11/25/2013 02:55 PM, Doug Anderson wrote:
> >>
> >> On modern SoCs the watchdog timer is parented on a clock that doesn't
> >> change every time we have a cpufreq change.  That means we don't need
> >> to constantly adjust the watchdog timer, so avoid registering for and
> >> dealing with cpufreq transitions unless we've actually got
> >> CPU_FREQ_S3C24XX defined.
> >>
> >> Note that this is more than just an optimization.  The s3c2410
> >> watchdog driver actually pats the watchdog on every CPU frequency
> >> change.  On modern systems these happen many times per second (even in
> >> a system where "nothing" is happening).  That effectively makes any
> >> userspace watchdog program useless (the watchdog is constantly patted
> >> by the kernel).  If we need CPU_FREQ_S3C24XX defined on a
> >> multiplatform kernel we'll need to make sure that kernel supports
> >> common clock and change this to user common clock framework.
> >>
> >> Signed-off-by: Doug Anderson <dianders at chromium.org>
> >> ---
> >>   drivers/watchdog/s3c2410_wdt.c | 2 +-
> >>   1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/watchdog/s3c2410_wdt.c
> >> b/drivers/watchdog/s3c2410_wdt.c
> >> index 7d8fd04..4980f84 100644
> >> --- a/drivers/watchdog/s3c2410_wdt.c
> >> +++ b/drivers/watchdog/s3c2410_wdt.c
> >> @@ -264,7 +264,7 @@ static irqreturn_t s3c2410wdt_irq(int irqno, void
> >> *param)
> >>         return IRQ_HANDLED;
> >>   }
> >>
> >> -#ifdef CONFIG_CPU_FREQ
> >> +#ifdef CONFIG_CPU_FREQ_S3C24XX
> >>
> > Where is the CPU_FREQ_S3C24XX configuration option defined ? I don't see it
> > in the current upstream kernel, so it appears that this depends on some
> > out-of-tree changes.
> 
> Whoops!  I guess I just trusted another patch and didn't dig.  I was
> basing this on https://patchwork.kernel.org/patch/3023421/
> 
> Ah, I see that Tomasz just found the answer.  I'll update my patch.

Seems like I originally gave you the wrong symbol name, looking at our
internal 3.10 tree, where the rename is not present yet, and nobody
noticed. Sorry for that.

Best regards,
Tomasz




More information about the linux-arm-kernel mailing list