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

[Linus Walleij]

On Tue, Sep 12, 2017 at 11:10 AM, Russell King - ARM Linux
 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
--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Russell King - ARM Linux]

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
--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Linus Walleij]

On Tue, Sep 5, 2017 at 5:04 PM, 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.

As far as I can see this works and makes sense.
Reviewed-by: Linus Walleij 

> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html