[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <alpine.LFD.2.02.1301312221400.11905@ionos>
Date: Thu, 31 Jan 2013 22:31:14 +0100 (CET)
From: Thomas Gleixner <tglx@...utronix.de>
To: Matt Sealey <matt@...esi-usa.com>
cc: John Stultz <john.stultz@...aro.org>,
Arnd Bergmann <arnd@...db.de>,
Linux ARM Kernel ML <linux-arm-kernel@...ts.infradead.org>,
LKML <linux-kernel@...r.kernel.org>,
Peter Zijlstra <peterz@...radead.org>,
Ingo Molnar <mingo@...hat.com>,
Russell King - ARM Linux <linux@....linux.org.uk>
Subject: Re: One of these things (CONFIG_HZ) is not like the others..
On Mon, 21 Jan 2013, Matt Sealey wrote:
> And if I wanted to I could register 8 more timers. That seems rather
> excessive, but the ability to use those extra 8 as clock outputs from
> the SoC or otherwise directly use comparators is useful to some
> people, does Linux in general really give a damn about having 8 timers
> of the same quality being available when most systems barely have two
> clocksources anyway (on x86, tsc and hpet - on ARM I guess twd and
> some SoC-specific timer). I dunno how many people might actually want
If you want to use that timers just for delivering arbitrary timer
events, then no. There is no point to have a gazillion of timer
interrupts happening w/o being coordinated. We have a pretty well
structured timer event infrastructure for precise and more timeout
oriented events, which are pretty happy to be served by a single per
cpu event device.
If you want to use the extra timers for other purposes (PWM, timer
triggered DMA transfers, etc...) then they are not in any way related
to the timers/timekeeping core.
Thanks,
tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists