[PATCH] sparc: Fix CPU counter support

[Daniel Hellstrom]

On 02/24/2014 04:16 PM, Sebastian Huber wrote:
> On 2014-02-24 15:20, Daniel Hellstrom wrote:
>> Sebastian, I think it's a good solution to rely on the GPTIMER[0].timer0 as a
>> fallback.
>>
>> Looks good to me, and should work on the TSIM/GRSIM and LEON3 hardware.
>>
>> Assuming that the frequency has been initialized to 1MHz for secondary GPTIMER
>> may be wrong when invoked from a boot loader, however this can be fixed later
>> if determined a problem.
>
> Thanks for the quick review.  I checked in a slightly different version that uses now only the first GPTIMER to determine the frequency:
>
> http://git.rtems.org/rtems/commit/?id=a4bc90af4ee55e72b18de4b64da6338634490760


Ok. that is much better I think. But it is not 100% correct, you can not be sure that the timers are clocked at the same frequency. To your help is the function call:

freq_hz = ambapp_freq_get(&ambapp_plb, adev_gptimer1);

That will return the frequency of any APB or AHB device in the system, the call can be made after the frequency of the AMBA bus have been initialized in amba_initialize() calling ambapp_freq_init().

Basically we don't have to use AMBA PnP to search for GPTIMER[0], since we assume that initialization has been performed by the system clock driver we could might as well assume that the 
LEON3_Timer_Regs variable is initialized too? The problem is that the CPU cycle counter is initialized before the timer driver, but is that working for all other platform also or are we really sure no 
other platform depend upon the system clock initialisation to complete?

Regards,
Daniel