PowerPC exceptions and interrupts

[Thomas Doerfler]

Pavel,

I am glad the discussion Sebastian started gets some feedback. Here are 
my comments:

Pavel Pisa schrieb:
> On Tuesday 20 May 2008 09:22, Sebastian Huber wrote:
> 
> I think personally, that additional function
>  rtems_interrupt_handler_unique_install() 
> for unique handler install is not good idea.
> I would prefer to add some mode/flags field into
> regular rtems_interrupt_handler_install() function.
> You implementation uses this approach anyway.
> I would suggest to use masks provided by defines
> for these flags. You need sometimes specific modifications/
> modes for interrupts, not only RTEMS_IRQ_SHARE_ALLOWED.

I like the idea of having a "flags" field to the interrupt handler 
installation call. This allows to adapt the underlying functions to 
hardware specifics.

> The Linux generic IRQ support converged to allow specify
> if IRQ is triggered on rising, falling edge or level directly
> in request_irq() function for GPIO IRQ sources for example.

Note: I assume, that realtime behaviour is not the uppermost priority in 
the Linux interrupt API.

> 
> The Linux adds ability to provide some user recognizable name
> for handler as well. This is not mandatory for RTEMS, but
> it could be of great help, if you need to check what is
> registered in the system and to display IRQ counters.

The penalty for this would not be great, if the driver/interrupt handler 
provides the storage for the name. In that case, the interrupt 
dispatcher only needs to store the (optional) pointer to this string. It 
really may help to create a (monitor ?) function which lists the 
installed interrupt handlers.

For this to work fine, we would need a small, lightweight API to query 
the current set of installed handlers.

> This means, that I would propose with Linux and other OS
> proven prototype
> 
> static rtems_status_code rtems_interrupt_handler_remove( 
> 	rtems_vector_number vector,
> 	void *arg
> 	)
This requires, that a handler always has a unique arg. Currently, at 
least some existing drivers do not use arg at all, so they would 
possibly pass a NULL as arg, (which obviously is not unique). What is 
the harm in passing in the "handler" AND "arg", and both values together 
are used as a search mask to identify the entry to be removed?
> If you ensure safety even more, handler parameter could
> be left there as well. In such case, the functionality
> could be extended next way
> 
>    handler == NULL .. then only match for arg is checked
>    arg == NULL .. then only match for handler is checked
>                   and all instances with this handler are removed
>    (handler == NULL) && (arg == NULL) .. all registration
>                   for given vector are removed

I do not see the benefit of this "search and destroy" API in this 
particular function. If I want to remove MY handler, I should no its 
handler and arg parameters. If I do NOT know these parameters, maybe I 
should not remove the handler at all :-)

Although your proposal seems elegant, I really can't find, where it will 
be useful.
> 
> The next algorithm is required to handle correctly shared edge
> triggered sources
> 
>    rtems_interrupt_handled_state again;
>    rtems_interrupt_handled_state res;
>    do {
>      again = 0;
>      for_each(vector->rtems_irq_connect_data_list, connect) {
>        res=connect->hndl(connect->handle);
>        if(res == RTEMS_INTERRUPT_HANDLED)
>          again = 1;
>      }
>    } while(again);
> 

If understand the above scheme correctly, the intention is to handle 
shared interrupt sources onan edge triggered interrupt input.

 From my perspective as a (sometimes) hardware developer, I assume such 
a structure as a severe bug. I consider it at least questionable, 
whether it makes sense to cure such a design fault in a general way, 
which will greatly increase the interrupt response time for other 
interrupt sources (Note, that normally each chain of interrupt handlers 
will be called at least twice instead of once).

If such a hardware must be serviced correctly, a better, "realtime" way 
would be that the interrupt dispatcher code will check the state of the 
interrupt line AFTER the handlers have been called ONCE and, if the 
(GPIO?) line is still active, will call the handlers again. But this 
must be controlled by specific code in the dispatcher area of the BSP.

wkr,
Thomas.

-- 
--------------------------------------------
embedded brains GmbH
Thomas Doerfler           Obere Lagerstr. 30
D-82178 Puchheim          Germany
Tel. : +49-89-18 90 80 79-2
Fax  : +49-89-18 90 80 79-9
email: Thomas.Doerfler at embedded-brains.de
PGP public key available on request

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.