LEON3 Clock and Timer Driver

[Daniel Hellstrom]

On 02/12/2014 02:33 PM, Sebastian Huber wrote:
> On 2014-02-12 12:11, Daniel Hellstrom wrote:
>>
>> I'm not familiar with this, but indeed it look a bit wrong. The timer resources
>> on LEON is not per-CPU, they area shared and we never know how many timers are
>> available. Most systems have at least two timers. In case of a multi-processor
>> system the LEON3 usually configured which timer it takes by looking at the CPU
>> index. It seems like there are two ways, of course the preferable way would be
>> to look at LEON3_Cpu_Index in case the AMP CPUs does not involve CPU0. How does
>> other AMP systems assign resources? I guess it would be better to solve it in
>> another way, by a BSP configuration option instead so select timer? But then
>> you would need different kernel libraries...
>
> Ok, I will change this to use LEON3_Cpu_Index instead of rtems_configuration_get_user_multiprocessing_table()->node.
>
>>
>> Is there a reason why having both timer and ckinit using the same timer?
>
> Its a bit unusual.  On other BSPs this is separate.  Also the timer initialization will destroy the setup of the clock driver.
>
>> Perhaps it is assumed that the timer interface is only used when the clock
>> timer is disabled?
>
> I don't know.  For the timer driver one dedicated timer should be enough.

That means that timer driver should use timer1 instead of timer0. But in the case of AMP it should use (MAX_CPUs*1 + LEON3_Cpu_Index + 1)?

>
> With the new CPU counter API we can also use a generic benchmark timer and get rid of the problem with the timer driver.
>
That sounds good, but relies on the NGMP hardware or rather the IRQCTRLs that support this feature starting with NGMP, so its not limited to LEON4 but can be available in newer LEON3 designs too.

Daniel