[PATCH 2/3 v2] LEON3 SMP: support static interrupt affinity

Daniel Hellstrom daniel at gaisler.com
Thu Oct 9 10:59:01 UTC 2014


On 10/09/2014 11:43 AM, Sebastian Huber wrote:
> On 09/10/14 11:31, Daniel Hellstrom wrote:
>> On 10/09/2014 11:13 AM, Sebastian Huber wrote:
>>> On 08/10/14 15:49, Daniel Hellstrom wrote:
>>>> +#ifdef RTEMS_SMP
>>>> +/* Weak table used to implement static interrupt CPU affinity in a SMP
>>>> + * configuration. The array index is the interrupt to be looked up, and
>>>> + * the array[INTERRUPT] content is the CPU number relative to boot CPU
>>>> + * index that will be servicing the interrupts from the IRQ source. The
>>>> + * default is to let the first CPU (the boot cpu) to handle all
>>>> + * interrupts (all zeros).
>>>> + */
>>>> +extern unsigned char sparc_irq_to_cpu[32];
>>>> +#endif
>>>
>>> I am not so fond of adding BSP specific solutions to deal with the interrupt
>>> processor affinity.
>>>
>>> I would rather enhance the interrupt manager extension API:
>>>
>>> http://www.rtems.org/wiki/index.php?title=SMP#Interrupt_Support_2
>>>
>>> http://www.rtems.org/onlinedocs/doxygen/cpukit/html/group__rtems__interrupt__extension.html
>>>
>>
>> I see this as a first step for the BSP to support Interrupt affinity. The
>> rtems_interrupt_{set,get}_affinity() will change the default IRQ2CPU mapping
>> and move already installed interrupts to a specific CPU set. With this patch
>> the default mapping does not have to route all IRQs to CPU0 from the start.
>
> I am fine with adding this, but I am still not fond of it.
>
> Since this is clearly LEON3 specific, can you please name this similar to the LEON3_mp_irq directly above in bsp.h.
>
> Why are these two variables not read-only?

Ok on both.

Thanks




More information about the devel mailing list