PowerPC exceptions and interrupts

[Daron Chabot]

Till Straumann wrote:
> Sebastian Huber wrote:
>   
>> Hi,
>> I adapted the shared exception and interrupt 
>> (libcpu/powerpc/new-exceptions/*) code to work with the e200z6 and this 
>> lead to some comments.
>>
>> The current code implicitly defines BSP_SHARED_HANDLER_SUPPORT. I 
>> modified it to support this preprocessor directive. Where is the right 
>> place to define it?
>>   
>>     

> <snip> Implementing
> shared interrupts (more than 1 handler per IRQ) should be
> mandatory. 

I'll drink to that idea !

I've got an application here at the CLS (pc386 BSP, rtems 4.7.1) that 
uses 5 PCI cards: one NIC and 4 VME-PCI bridge devices. I hacked the 
VME-PCI driver to allow IRQ sharing, but the catch is that the PCI 
devices have to be in a specific physical ordering in the PC such that 
the devices sharing an IRQ are of the same "species" (i.e. both must be 
VME-PCI bridge devices).

...I did say it was a hack...
> It doesn't consume a lot of resources; especially
> if not used (the 'install' routine could be split into a separate
> file so that it is not linked if unused).
>
> The current situation is ugly -- if you don't include the file
> where BSP_SHARED_HANDLER_SUPPORT is defined prior to
> including rtems/irq.h then you don't get the correct declarations
> IIRC.
>   
>> Currently the shared interrupt handler support works like a stack. You 
>> can push and pop a handler. But in BSP_remove_rtems_irq_handler is also 
>> code that removes the handler from a list. What was intended?
>>   
>>     

> <snip> BSP_install_rtems_shared_irq_handler
> adds a handler at the head of the list of handlers,
> BSP_remove_rtems_irq_handler extracts a handler from the list.
>   

This sounds like a prime opportunity for sharing/unifying code across 
the PIC-vectored interrupt-handling API... at least between elements of 
the PPC and x86 BSPs.

>   
>> The interrupt support code only ensures that interrupts are disabled 
>> during critical sections. May it be useful to add a mutex to support 
>> usage in multiple threads?
>>   
>>     
> No. Protecting a critical section by disabling interrupts is
> already thread-safe (and used in many places in RTEMS).
> It might also be quicker/cheaper if it protects short sections
> of code.
>
> That said - I realize that interrupts were disabled across
> malloc and free which is bad. I just fixed this.
>   
>> The BSP interrupt routines are declared in cpukit/include/rtems/irq.h 
>> but don't follow the RTEMS naming conventions. A RTEMS interface for 
>> interrupts would be nice?
>>   
>>     

> Oh yes - and a less clumsy one. The existing rtems_interrupt_catch
> would be great *if* it supported a user argument to the isr...
>   

That's a wonderful suggestion too...
>> I found no place where the entry isOn from rtems_irq_connect_data is 
>> used. We may remove it.
>>   
>>     
> Unfortunately, this would break all existing applications which
> use the current API. This is IMO not a good idea.
>
> It would be better to come up with a new API, deprecate the old
> one and phase it out eventually.
>   
>> The MPC5566 evaluation board has only 128kB internal RAM. Due to the 328 
>> interrupt sources the interrupt handler table is quite big: 7896 Bytes 
>> (6% of internal RAM). The exception handler table is also not very small 
>> with 896 Bytes (0.7% of internal RAM). Thus I want to introduce two new 
>> defines BSP_CONFIG_CONSTANT_EXCEPTION_TABLE and 
>> BSP_CONFIG_CONSTANT_INTERRUPT_TABLE and modify the code to support 
>> constant tables.
>>   
>>     
> This defeats the whole 'new-exceptions' API which provides
> methods to change raw exception handlers. Just playing
> devil's advocate...
>
> And how can a BSP with a constant interrupt table support
> applications which use the calls to install/remove interrupt
> handlers? You'd rather have to think of an alternative implementation
> of the current API -- since probably most of the 328 sources
> are unused e.g., a (smaller) hash table could be used and
> the real 'rtems_irq_connect_data' structs be allocated only on demand.
>
> In any case: prior to modifying code I suggest you make
> proposals as to how the API must be changed and what
> implementation you propose. Any implementation should
> be generically useful rather than #ifdef dependent...
>
> Cheers
> -- Till
>   
>> Regards,
>>     Sebastian
>>
>> --------------------------------------------
>> embedded brains GmbH
>> Sebastian Huber           Obere Lagerstr. 30
>> D-82178 Puchheim          Germany
>> Tel. : +49-89-18 90 80 79-6
>> Fax  : +49-89-18 90 80 79-9
>> email: Sebastian.Huber at embedded-brains.de
>> PGP public key available on request
>>
>> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>>
>> _______________________________________________
>> rtems-users mailing list
>> rtems-users at rtems.com
>> http://rtems.rtems.org/mailman/listinfo/rtems-users
>>   
>>     
>
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.com
> http://rtems.rtems.org/mailman/listinfo/rtems-users
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20080514/bfd8cbb3/attachment.html>