Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1730874
| From | Linus Walleij <linus.walleij@linaro.org> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH] [RFC] clocksource: improve GENERIC_CLOCKEVENTS dependency |
| Date | 2017-09-12 16:20 +0200 |
| Message-ID | <uoUcF-2jr-9@gated-at.bofh.it> (permalink) |
| References | <umnEe-4jf-19@gated-at.bofh.it> <uoOAi-7gK-11@gated-at.bofh.it> <uoPwl-7PF-1@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On Tue, Sep 12, 2017 at 11:10 AM, Russell King - ARM Linux <linux@armlinux.org.uk> wrote: > On Tue, Sep 12, 2017 at 10:09:51AM +0200, Linus Walleij wrote: >> For ARM we now have two subarchs not using generic clockevents: >> RISC PC and EBSA110. >> >> I think Russell stated these two cannot be converted to generic clockevents >> because of hardware limitations I guess, no timer interrupt, simply, which >> means no clockevents, or unreliable or not granular enough timers. >> >> IIUC the SA110 does not contain the built-in SoC goodies of the SA1100 >> so it needs external timer blocks, and those two machines don't have >> good enough timers. > > That's hardly surprising because SA1100 is a SoC, SA110 is just a CPU, > containing no peripherals at all. > > EBSA110 only has one usable timer, which must be programmed to produce > a regular timer tick to the OS: it's no good trying to double up the > clocksource and a periodic clockevent onto one counter register - the > clock source will see the same timer value +/- interrupt latency, and > in any case it won't wrap in a power-of-2 manner. > > This breaks the assumptions behind the clocksource and timekeeping > code, which are that we have a timer that wraps in a power-of-2 > manner, and which takes much longer than the desired period to wrap. Aha, that makes perfect sense. Now I finally understand the exact nature of this problem. > I think RiscPC may be convertable as there are two timers, and I think > the second timer is unused (so could be programmed to the requirements > of a clocksource) but is there much reason to bother given the EBSA110? > I think there isn't. The one reason I've seen is that converting to generic clockevents often makes it simple to also introduce a delay timer at the same time by just reusing the clocksource timer for it, and that saves the boot-time loop calibration. (The MOXA ART and Aspeed saw this when I unified the Faraday timers.) But in general no. Yours, Linus Walleij
Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread
Re: [PATCH] [RFC] clocksource: improve GENERIC_CLOCKEVENTS dependency Linus Walleij <linus.walleij@linaro.org> - 2017-09-12 10:20 +0200
Re: [PATCH] [RFC] clocksource: improve GENERIC_CLOCKEVENTS dependency Russell King - ARM Linux <linux@armlinux.org.uk> - 2017-09-12 11:20 +0200
Re: [PATCH] [RFC] clocksource: improve GENERIC_CLOCKEVENTS dependency Linus Walleij <linus.walleij@linaro.org> - 2017-09-12 16:20 +0200
csiph-web