LEON3 Clock and Timer Driver

[Daniel Hellstrom]

Hello,

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

Is there a reason why having both timer and ckinit using the same timer? Perhaps it is assumed that the timer interface is only used when the clock timer is disabled?

Daniel


On 02/11/2014 09:46 AM, Sebastian Huber wrote:
> Hello,
>
> the LEON3 clock and timer driver use both LEON3_Timer_Regs (usually GPTIMER 0).
>
> In separate source files we have
>
> http://git.rtems.org/rtems/tree/c/src/lib/libbsp/sparc/leon3/clock/ckinit.c#n33
>
> #if defined(RTEMS_MULTIPROCESSING)
>   #define LEON3_CLOCK_INDEX \
>     (rtems_configuration_get_user_multiprocessing_table() ? LEON3_Cpu_Index : 0)
> #else
>   #define LEON3_CLOCK_INDEX 0
> #endif
>
> and
>
> http://git.rtems.org/rtems/tree/c/src/lib/libbsp/sparc/leon3/timer/timer.c#n24
>
> #if defined(RTEMS_MULTIPROCESSING)
>   #define LEON3_TIMER_INDEX \
>       ((rtems_configuration_get_user_multiprocessing_table()) ? \
> (rtems_configuration_get_user_multiprocessing_table()->node) - 1 : 1)
> #else
>   #define LEON3_TIMER_INDEX 0
> #endif
>
> So we cannot use a clock and timer driver at the same time.  Is this intentional?
>
> Why are there different methods used to select the index in the RTEMS_MULTIPROCESSING case?
>