[RFC] clocksource: improve GENERIC_CLOCKEVENTS dependency

We regularly run into build errors when a clocksource driver selects
CONFIG_TIMER_OF while CONFIG_GENERIC_CLOCKEVENTS is disabled:

 In file included from drivers/clocksource/timer-of.c:25:0:
drivers/clocksource/timer-of.h:35:28: error: field 'clkevt' has incomplete type

At the moment, three drivers can show this behavior: ARMV7M_SYSTICK,
CLKSRC_ST_LPC and CLKSRC_NPS. We could add further dependencies as we did
many times, but I have looked a little bit more at what architectures
are left that don't use GENERIC_CLOCKEVENTS, and this shows that there
is a better solution.

On arch/frv and arch/ia64, we never select CONFIG_GENERIC_CLOCKEVENTS
and we also don't use ARCH_USES_GETTIMEOFFSET, which would
block the clocksource Kconfig menu. On m68k, some platforms use
CONFIG_GENERIC_CLOCKEVENTS, some use ARCH_USES_GETTIMEOFFSET, and some
use neither of them. The good news is that there is no configuration that
does not set CONFIG_GENERIC_CLOCKEVENTS but that wants to enable any of
the Kconfig symbols in the menu, so we can simply replace the dependency
with the stricter one. While in theory one could have a clocksource
driver without the clockevent infrastructure, this seems unlikely
to be relevant in the future any more.

We can probably drop some of the other dependencies as well now,
e.g. there should generally be no reason to depend on CONFIG_ARM
unless the driver uses architecture specific assembly.

Reported-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>

---
 drivers/clocksource/Kconfig | 50 ++++++++-------------------------------------
 1 file changed, 9 insertions(+), 41 deletions(-)

-- 
2.9.0

On Tue, Sep 5, 2017 at 5:04 PM, Arnd Bergmann <arnd@arndb.de> wrote:

> We regularly run into build errors when a clocksource driver selects

> CONFIG_TIMER_OF while CONFIG_GENERIC_CLOCKEVENTS is disabled:

>

>  In file included from drivers/clocksource/timer-of.c:25:0:

> drivers/clocksource/timer-of.h:35:28: error: field 'clkevt' has incomplete type

>

> At the moment, three drivers can show this behavior: ARMV7M_SYSTICK,

> CLKSRC_ST_LPC and CLKSRC_NPS. We could add further dependencies as we did

> many times, but I have looked a little bit more at what architectures

> are left that don't use GENERIC_CLOCKEVENTS, and this shows that there

> is a better solution.

>

> On arch/frv and arch/ia64, we never select CONFIG_GENERIC_CLOCKEVENTS

> and we also don't use ARCH_USES_GETTIMEOFFSET, which would

> block the clocksource Kconfig menu. On m68k, some platforms use

> CONFIG_GENERIC_CLOCKEVENTS, some use ARCH_USES_GETTIMEOFFSET, and some

> use neither of them. The good news is that there is no configuration that

> does not set CONFIG_GENERIC_CLOCKEVENTS but that wants to enable any of

> the Kconfig symbols in the menu, so we can simply replace the dependency

> with the stricter one. While in theory one could have a clocksource

> driver without the clockevent infrastructure, this seems unlikely

> to be relevant in the future any more.


As far as I can see this works and makes sense.
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>


> We can probably drop some of the other dependencies as well now,

> e.g. there should generally be no reason to depend on CONFIG_ARM

> unless the driver uses architecture specific assembly.


I think they are just there to cut down on the available menu choices
when doing manual configuration. Which is moot since the machine/subarch
likely selects the right clocksource driver anyway.

About ARM:

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 is a bit annoying since even the Commodore 64 has good enough
timers to run generic clock events, had it only had compiler support
and enough memory to run Linux...

Anyways, I'm too ignorant to even fully understand what happens
on a system with just GETTIMEOFFSET and not clockevents, does the
OS just run in an eternal loop and advancing any event in the system
using that time offset?

Yours,
Linus Walleij

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: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

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

On 05/09/2017 17:04, Arnd Bergmann wrote:
> We regularly run into build errors when a clocksource driver selects

> CONFIG_TIMER_OF while CONFIG_GENERIC_CLOCKEVENTS is disabled:

> 

>  In file included from drivers/clocksource/timer-of.c:25:0:

> drivers/clocksource/timer-of.h:35:28: error: field 'clkevt' has incomplete type

> 

> At the moment, three drivers can show this behavior: ARMV7M_SYSTICK,

> CLKSRC_ST_LPC and CLKSRC_NPS. We could add further dependencies as we did

> many times, but I have looked a little bit more at what architectures

> are left that don't use GENERIC_CLOCKEVENTS, and this shows that there

> is a better solution.

> 

> On arch/frv and arch/ia64, we never select CONFIG_GENERIC_CLOCKEVENTS

> and we also don't use ARCH_USES_GETTIMEOFFSET, which would

> block the clocksource Kconfig menu. On m68k, some platforms use

> CONFIG_GENERIC_CLOCKEVENTS, some use ARCH_USES_GETTIMEOFFSET, and some

> use neither of them. The good news is that there is no configuration that

> does not set CONFIG_GENERIC_CLOCKEVENTS but that wants to enable any of

> the Kconfig symbols in the menu, so we can simply replace the dependency

> with the stricter one. While in theory one could have a clocksource

> driver without the clockevent infrastructure, this seems unlikely

> to be relevant in the future any more.

> 

> We can probably drop some of the other dependencies as well now,

> e.g. there should generally be no reason to depend on CONFIG_ARM

> unless the driver uses architecture specific assembly.

> 

> Reported-by: Randy Dunlap <rdunlap@infradead.org>

> Signed-off-by: Arnd Bergmann <arnd@arndb.de>

> ---


Makes sense. Agree with this change.


-- 
 <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog