Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1730730 > unrolled thread

Re: [PATCH] [RFC] clocksource: improve GENERIC_CLOCKEVENTS dependency

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  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

#1730730 — Re: [PATCH] [RFC] clocksource: improve GENERIC_CLOCKEVENTS dependency

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

[toc] | [next] | [standalone]

#1730758

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

[toc] | [prev] | [next] | [standalone]

#1730874

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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web