[PATCH] score: Add CPU counter support

[Sebastian Huber]

On 2014-02-12 16:06, Gedare Bloom wrote:
> On Wed, Feb 12, 2014 at 3:43 AM, Sebastian Huber
> <sebastian.huber at embedded-brains.de> wrote:
>> Hello Gedare,
>>
>>
>> On 2014-02-11 19:17, Gedare Bloom wrote:
>>>
>>> I like this idea. I have some requests about the interface though.
>>>
>>> First, is there only one possible counter or would it be extended in
>>> the future to multiple?
>>
>>
>> why do you need more than one free-running counter?  Linux (and many other
>> operating systems) have only one get_cycles() function.
>>
>>
>>> If there may be multiple, this resource should
>>> be represented in the score and configured as an Object, with a
>>> traditional interface in the classic (rtems/rtems) API. I'm not
>>> convinced putting the interface into sapi is exactly the right thing
>>> to do, unless some piece of the public API is needed before
>>> initialization completes. With a classic interface, the 'manager' can
>>> better encapsulate the counter storage such as the frequency scalar.
>>> The more I think about it, the more a simple Counter manager makes
>>> sense to me.
>>
>>
>> No, a counter object makes no sense and would introduce cyclic dependencies.
>> The use case for this free-running counter is profiling, busy wait delay
>> functions and maybe also an entropy source for random numbers.
>>
>> http://www.rtems.org/wiki/index.php?title=SMP#Profiling
>>
>> This counter must be available early to be of any use and the overhead to
>> read the counter must be as small as possible.
>>
> OK thanks for the link that helps me understand your goals here. It
> looks like there will need to be some additional functions defined
> over the rtems_counter_ticks type, such as 'max' and possibly 'add'
> for accumulating statistics.

No, that is not necessary.  The use cases for values obtained by 
rtems_counter_read() is very limited.  You can use it as an entropy source, in 
this case its just a number without further meaning.  The second use case is a 
time instant value.  In this case the only useful operation is to calculate the 
difference between two such values (rtems_counter_subtract).  Once you have a 
difference further operations with it are normal integer operations.

>
>>>> +/**
>>>> + * brief Initializes the CPU counter to/from nanoseconds converter
>>>> functions.
>>>> + *
>>>> + * This function must be used to initialize the
>>>> + * rtems_cpu_counter_to_nanoseconds() and
>>>> rtems_cpu_counter_from_nanoseconds()
>>>> + * functions.  It should be called during system initialization by the
>>>> board
>>>> + * support package.
>>>> + *
>>>> + * @param[in] uint32_t frequency The current CPU counter frequency in
>>>> Hz.
>>>> + */
>>>> +void rtems_cpu_counter_initialize_converter( uint32_t frequency );
>>>> +
>>>
>>> I don't like this name, because it is not clear what a "converter" is
>>> just by seeing it. The correct technical term for what is done is to
>>> compute the prescaler to use when dividing the counter to obtain a
>>> nanoseconds value. So I would suggest the name:
>>> rtems_counter_initialize_prescaler(uint32_t frequency);
>>
>>
>> To change nanoseconds to/from ticks is clearly a conversion.  The existence
>> of a prescaler is an implementation detail.  The comment states which
>> converter functions are targeted.  So I will keep the name.
>>
> OK, but does this function need to be part of the sapi? It is
> implemented within the bsp, and invoked by the bsp during bootstrap. I
> don't see a reason the function would be re-invoked (to re-initialize
> the converter), so an application should never call this function?

Yes, an application should not use this function.  It might be necessary to 
call this function again if the counter frequency changes (e.g. some power 
saving state).

>
> Thanks, and the code is looking good to me.
> Gedare
>


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