[PATCH v2] score: Add CPU counter support

[Sebastian Huber]

On 2014-02-12 13:38, Chris Johns wrote:
> On 12/02/2014 8:27 pm, Sebastian Huber wrote:
>> Add a CPU counter interface to allow access to a free-running counter.
>> It is useful to measure short time intervals.
>
> What is meant by a short time interval and also what would a long time mean ?

This actual time interval is CPU/BSP dependent.  The interval should at least 
cover a system tick.

>
> Is an overflow or wrap around status available and/or important ?

A overflow of the counter register will happen on most systems.  Thus we use an 
unsigned integer type since here modulo arithmetic is defined.  Also the 
implementation must provide the _CPU_Counter_Subtract() function.  Some smaller 
ARM controllers have for example only 24-bit timers.

>
>> This can be used for
>> example to enable profiling of critical low-level functions.
>
> Why use this rather than the existing rtems_clock_get_uptime_nanoseconds ?
>
> Are you looking at sub-nano second times ?

The overhead to use rtems_clock_get_uptime_nanoseconds() is too high.  Also 
this counter should work without a clock driver and during system initialization.

Also what happens if your driver using the busy wait is initialized before the 
clock driver, etc.?

The step from CPU counter ticks to/from nanoseconds is explicit in this API 
unlike to rtems_clock_get_uptime_nanoseconds().

How do you profile the spinlock used by rtems_clock_get_uptime_nanoseconds()?

>
> I would be concerned about trace data based on this unless the over was handled
> or interrupts are masked.
>
>>
>> Add two busy wait functions rtems_counter_delay_ticks() and
>> rtems_counter_delay_nanoseconds() implemented via the CPU counter.
>>
>
> How is the user protected in a portable way across different cpus ?

Protected against what?

> Is there range checking or is overflows used ?

The range is limited by the parameter integer types.

> Are the calls re-entrant ?

What do you mean with re-entrant here?

>
>> diff --git a/doc/cpu_supplement/general.t b/doc/cpu_supplement/general.t
>> index cf28eef..3608705 100644
>> --- a/doc/cpu_supplement/general.t
>> +++ b/doc/cpu_supplement/general.t
>> @@ -341,6 +341,26 @@ _TLS_Size = _TLS_BSS_end - _TLS_Data_begin;
>>   _TLS_Alignment = ALIGNOF (.tdata);
>>   @end example
>>
>> + at section CPU counter
>> +
>> +The CPU support must implement the CPU counter interface.  A CPU counter is
>> +some free-running counter.  It ticks usually with a frequency close to the CPU
>> +or system bus clock.  On some architectures the actual implementation is board
>> +support package dependent.  The CPU counter is used for profiling of low-level
>> +functions.  It is also used to implement two busy wait functions
>> + at code{rtems_counter_delay_ticks()} and @code{rtems_counter_delay_nanoseconds()}
>> +which may be used in device drivers.  It may be also used as an entropy source
>> +for random number generators.
>> +
>> +The CPU counter interface uses a CPU port specific unsigned integer type
>> + at code{CPU_Counter_Ticks} to represent CPU counter values.  The CPU port must
>> +provide the following two functions
>> +
>> + at itemize
>> + at item @code{_CPU_counter_Read()} to read the current CPU counter value, and
>> + at item @code{_CPU_counter_Subtract()} to subtract two the CPU counter values.
>> + at end itemize
>
> Is overflows handled in the maths ? I could not see it if important.
>
> Should the user be able to ask the range of the counter ?

The only useful operation with values obtained by _CPU_counter_Read() is 
_CPU_counter_Subtract().

-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.