[PATCH v2] score: Add CPU counter support

[Chris Johns]

On 12/02/2014 11:56 pm, Sebastian Huber wrote:
> 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.

The examples or the generic one do not seem to handle overflows, ie the 
first sample is greater than the last. Should it do this to avoid a 
simple copy and paste error when others implement this ?

The documentation need to outline this and what it needs to take care of.

>
>>
>>> 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()?
>

These are all great reasons and it would be great to capture into the 
documentation. I see nothing more than what is listed here just as 
sentences rather than questions. I also think a reference to the 
rtems_clock_get_uptime_nanoseconds be provided to help guide users.

>>
>> 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?
>

Asking to delay for a time greater than the timer overflow, warnings and 
clarifications in the doco outlining the restrictions. The intent and 
purpose is clear to you and I am guessing a little to fill in the gaps 
however what happens in 10 years time when a new user sees this.

>> Is there range checking or is overflows used ?
>
> The range is limited by the parameter integer types.
>

And if you have a 24bit timer ?

>> Are the calls re-entrant ?
>
> What do you mean with re-entrant here?
>

If I ask for 100 nsecs do I get that or do I get at least 100+ nsecs 
and/or I am in the delay call for 60% of the timer overflow period and 
get pre-empted and a new call is made to the delay this time for 90% of 
the timer overflow length overflowing the original call.

I feel we need more doco to help define the scope. I am not asking for 
the API or code to be made more complex as I understand the need for 
speed and simplicity.

>>
>>> 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().
>

This should be noted in the doco. Also should _CPU_counter_Subtract be 
_CPU_counter_Difference ?

Chris