[ECOS] HAL_INTERRUPT_ACKNOWLEDGE question

[ECOS] HAL_INTERRUPT_ACKNOWLEDGE question

[Mike Sweeney]

I am a little confused about what HAL_INTERRUPT_ACKNOWLEDGE is
intended to do. The reference manual for eCos says that it is used if
the interrupt controller requires you to acknowledge an interrupt. The
reason I am confused is that an interrupt service routine for a device
may need to clear a status flag in a peripheral status register even
if there is no interrupt controller. Is the intent that each interrupt
service routine handle this clearing of the flag in the peripheral
status register on its own, in addition to calling
HAL_INTERRUPT_ACKNOWLEDGE for handling anything that has to do with
the interrupt controller? It seems this is the case, but why is there
this special function in the HAL for handling the interrupt controller
acknowledgement? Why isn't this just handled directly by each device's
interrupt service routine without going through this interface?

The hal_clock_reset() function makes it quite clear to me that each
ISR handles any status flags itself, because this is the only way the
ISR for the real time clock could be made generic as it is in the
kernel by calling hal_clock_reset() in addition to calling
HAL_INTERRUPT_ACKNOWLEDGE().

Thanks.

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] HAL_INTERRUPT_ACKNOWLEDGE question

[Daniel Helgason]

On Wed, 2007-06-06 at 23:16 -0400, Mike Sweeney wrote:
> I am a little confused about what HAL_INTERRUPT_ACKNOWLEDGE is
> intended to do. The reference manual for eCos says that it is used if
> the interrupt controller requires you to acknowledge an interrupt. The
> reason I am confused is that an interrupt service routine for a device
> may need to clear a status flag in a peripheral status register even
> if there is no interrupt controller. Is the intent that each interrupt
> service routine handle this clearing of the flag in the peripheral
> status register on its own, in addition to calling
> HAL_INTERRUPT_ACKNOWLEDGE for handling anything that has to do with
> the interrupt controller?
> ...

I think this is because the interrupt controller is a shared resource
and there may be some 'stacking' and 'unstacking' of state required to
manage it and the priorities of interrupts that use it.

Each interrupt routine usually has exclusive access to the peripheral
that caused the interrupt and so the routine can directly handle
interrupt-related registers in the peripheral, but some, most, or all
peripheral interrupts might be channelled through the shared interrupt
controller in a target-specific way. Generally, interrupts from higher
priority sources are masked by the interrupt controller until
HAL_INTERRUPT_ACKNOWLEDGE is called. 

If you don't have an interrupt controller, then the
HAL_INTERRUPT_ACKNOWLEDGE macro/function is going to be very small if it
exists at all.

-- 
+---------------------------------------------
| Daniel Helgason <danielh@telus.net>



-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] HAL_INTERRUPT_ACKNOWLEDGE question

[Daniel Helgason]

On Wed, 2007-06-06 at 21:08 -0700, Daniel Helgason wrote:

> Generally, interrupts from higher priority sources are masked by the
> interrupt controller until HAL_INTERRUPT_ACKNOWLEDGE is called. 

Oops, I can't believe I said that! I think it makes more sense that
interrupts from *lower* priority sources are masked until
HAL_INTERRUPT_ACKNOWLEDGE is called.

But really, it is target-specific whether higher, lower, or any are
released when HAL_INTERRUPT_ACKNOWLEDGE is called. Not that it makes any
difference in HALs that don't support nested interrupts but the macro
might have to tickle the interrupt controller and make it happy.

-- 
+---------------------------------------------
| Daniel Helgason <danielh@telus.net>



-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] HAL_INTERRUPT_ACKNOWLEDGE question

[Nick Garnett]

"Mike Sweeney" <msweeney77@gmail.com> writes:

> I am a little confused about what HAL_INTERRUPT_ACKNOWLEDGE is
> intended to do. The reference manual for eCos says that it is used if
> the interrupt controller requires you to acknowledge an interrupt. The
> reason I am confused is that an interrupt service routine for a device
> may need to clear a status flag in a peripheral status register even
> if there is no interrupt controller. Is the intent that each interrupt
> service routine handle this clearing of the flag in the peripheral
> status register on its own, in addition to calling
> HAL_INTERRUPT_ACKNOWLEDGE for handling anything that has to do with
> the interrupt controller? It seems this is the case, but why is there
> this special function in the HAL for handling the interrupt controller
> acknowledgement? Why isn't this just handled directly by each device's
> interrupt service routine without going through this interface?
> 
> The hal_clock_reset() function makes it quite clear to me that each
> ISR handles any status flags itself, because this is the only way the
> ISR for the real time clock could be made generic as it is in the
> kernel by calling hal_clock_reset() in addition to calling
> HAL_INTERRUPT_ACKNOWLEDGE().

There are several reasons for this:

1. Abstraction. The author of a device driver should only need to
   concern himself with the details of the device, not with the
   details of the interrupt controller too. Acknowledgement is
   abstracted for the same reason masking and configuring the
   interrupts are also abstracted; the same reason we have HALs, a
   kernel, libraries and subsystems: division of responsibility into
   well defined layers.

2. Maintenance. If the way the interrupt controller is used needs to
   be changed, or a bug is found, it need only be changed in one
   place, and one doesn't have to search through all the device
   drivers for random bits of code.

3. Portability. Some device drivers are portable: many of the ethernet
   drivers, 16550 serial driver, CAN, USB etc. These drivers cannot
   contain code for all the possible platforms they may run on;
   platform-specific operations need to be handled in a portable way.

-- 
Nick Garnett                                     eCos Kernel Architect
eCosCentric Limited     http://www.eCosCentric.com/   The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.    Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] HAL_INTERRUPT_ACKNOWLEDGE question

[Mike Sweeney]

On 07 Jun 2007 11:01:15 +0100, Nick Garnett <nickg@ecoscentric.com> wrote:
> "Mike Sweeney" <msweeney77@gmail.com> writes:
>
> > I am a little confused about what HAL_INTERRUPT_ACKNOWLEDGE is
> > intended to do. The reference manual for eCos says that it is used if
> > the interrupt controller requires you to acknowledge an interrupt. The
> > reason I am confused is that an interrupt service routine for a device
> > may need to clear a status flag in a peripheral status register even
> > if there is no interrupt controller. Is the intent that each interrupt
> > service routine handle this clearing of the flag in the peripheral
> > status register on its own, in addition to calling
> > HAL_INTERRUPT_ACKNOWLEDGE for handling anything that has to do with
> > the interrupt controller? It seems this is the case, but why is there
> > this special function in the HAL for handling the interrupt controller
> > acknowledgement? Why isn't this just handled directly by each device's
> > interrupt service routine without going through this interface?
> >
> > The hal_clock_reset() function makes it quite clear to me that each
> > ISR handles any status flags itself, because this is the only way the
> > ISR for the real time clock could be made generic as it is in the
> > kernel by calling hal_clock_reset() in addition to calling
> > HAL_INTERRUPT_ACKNOWLEDGE().
>
> There are several reasons for this:
>
> 1. Abstraction. The author of a device driver should only need to
>    concern himself with the details of the device, not with the
>    details of the interrupt controller too. Acknowledgement is
>    abstracted for the same reason masking and configuring the
>    interrupts are also abstracted; the same reason we have HALs, a
>    kernel, libraries and subsystems: division of responsibility into
>    well defined layers.
>
> 2. Maintenance. If the way the interrupt controller is used needs to
>    be changed, or a bug is found, it need only be changed in one
>    place, and one doesn't have to search through all the device
>    drivers for random bits of code.
>
> 3. Portability. Some device drivers are portable: many of the ethernet
>    drivers, 16550 serial driver, CAN, USB etc. These drivers cannot
>    contain code for all the possible platforms they may run on;
>    platform-specific operations need to be handled in a portable way.
>
> --
> Nick Garnett                                     eCos Kernel Architect
> eCosCentric Limited     http://www.eCosCentric.com/   The eCos experts
> Barnwell House, Barnwell Drive, Cambridge, UK.    Tel: +44 1223 245571
> Registered in England and Wales: Reg No 4422071.
>
>

I thought abstraction might have been a possible reason but I didn't
see how this was too useful since the driver is not very portable
anyways. However, your point about the interrupt controller changes
not having to be made in every driver do make sense. Thanks.

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss