[lkml]   [2017]   [Sep]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] [RFC] clocksource: improve GENERIC_CLOCKEVENTS dependency
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.

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.

RMK's Patch system:
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to 8.21Mbps down 510kbps up

 \ /
  Last update: 2017-09-12 11:11    [W:0.058 / U:40.852 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site