[Xenomai] tsc on armv8

[Xenomai] tsc on armv8

[Don Mahurin]

Hi,

A few questions about tsc as it relates to armv8.

1. armv8 has a 64 bit system counter register CNTPCT_EL0 (system counter
frequency get/set with CNTFRQ_EL0). May this be used as a replacement for
the arm tsc emulation. If so, should we use another architecture to model
the implementation?
(the count value is "at least 56 bits wide" according to spec and zero
padded to 64 bits. is the counter still sufficient?)


2. Is a tsc implementation strictly required to test basic i-pipe
functionality. I understand that a configuration without
CONFIG_IPIPE_ARM_KUSER_TSC is not currently supported on arm (which we are
basing the arm64 port upon), but what is the minimum tsc functionality that
needs to be implemented for basic i-pipe functionality. (Can some functions
be stubbed initially?)

-Don

Re: [Xenomai] tsc on armv8

[Gilles Chanteperdrix]

On Fri, Apr 03, 2015 at 01:45:41PM -0700, Don Mahurin wrote:
> Hi,
> 
> A few questions about tsc as it relates to armv8.
> 
> 1. armv8 has a 64 bit system counter register CNTPCT_EL0 (system counter
> frequency get/set with CNTFRQ_EL0). May this be used as a replacement for
> the arm tsc emulation. If so, should we use another architecture to model
> the implementation?
> (the count value is "at least 56 bits wide" according to spec and zero
> padded to 64 bits. is the counter still sufficient?)

I believe cortex A15 has the same counter, and this is what I-pipe
uses. About the tsc architecture on ARM, it was made to allow the
different counters available on different arm processors while
keeping a unique kernel/user ABI. If the counter you are talking
about is guaranteed to be available on all armv8 based processors
and you are sure nobody will ever want a better counter (from what I
could test on cortex a15, this counter has a rather low resolution,
around 1us), then you can avoid the arm tsc architecture altogether.

> 
> 
> 2. Is a tsc implementation strictly required to test basic i-pipe
> functionality. I understand that a configuration without
> CONFIG_IPIPE_ARM_KUSER_TSC is not currently supported on arm

if !IPIPE_ARM_KUSER_TSC was not supported, this symbol would not be
needed. !IPIPE_ARM_KUSER_TSC is supported, if you do not set this
symbol, you have to provide the tsc emulation function. All this is
explained in the ARM porting guide.


> (which we are basing the arm64 port upon), but what is the minimum
> tsc functionality that needs to be implemented for basic i-pipe
> functionality. (Can some functions be stubbed initially?)

Xenomai timers management needs a high resolution counter. The same
high resolution counter needs to be available in user-space,
preferably without a system call, and for proper implementation of
CLOCK_HOST_REALTIME, needs to also be used by Linux.

When you will want to run the "latency" test to test that the
xenomai timer is working correctly, you will need this high
resolution counter.

-- 
					    Gilles.

Re: [Xenomai] tsc on armv8

[Lennart Sorensen]

On Sat, Apr 04, 2015 at 03:56:15PM +0200, Gilles Chanteperdrix wrote:
> I believe cortex A15 has the same counter, and this is what I-pipe
> uses. About the tsc architecture on ARM, it was made to allow the
> different counters available on different arm processors while
> keeping a unique kernel/user ABI. If the counter you are talking
> about is guaranteed to be available on all armv8 based processors
> and you are sure nobody will ever want a better counter (from what I
> could test on cortex a15, this counter has a rather low resolution,
> around 1us), then you can avoid the arm tsc architecture altogether.

If you mean the master counter, then from what I have seen it usually runs
at 5 to 6 MHz range, so a bit better than 1us, but certainly not 0.1us.

-- 
Len Sorensen