Development Plan Proposal for Unifying Interrupt and PCI APIs

[Bogdan Vacaliuc]

Hi Eric,

On Monday, October 25, 2004 11:28 AM, Eric Valette wrote:
> Bogdan Vacaliuc wrote:
> 
>> If the (new) RTEMS interrupt API provided a complete virtualization
>> of interrupts,
> 
> Could you elaborate what you mean here? For me interrupt
> virtualization means many different things...

Sure.  I'll also include the complete text below, I don't think Thomas will mind.  I wasn't even sure anyone would be interested (as
it was an implementation detail).

What I mean by virtualization of interrupts is that the actual calling of the interrupt handlers is peformed by the RTEMS (common)
interrupt code.  The idea is that every handler is given a unique prioritization number, even when the the device is sharing a
physical IRQ.  While interrupts are pending, the virtualizer always calls one handler (the highest-priority one), then re-evaluates
the pending interrupts.

The choice of prioritization is made by the BSP designer, I would think.

Each handler for each device is associated with a unique (virtual) IRQ level that defines its priority.  The physical IRQ and
necessary 'hooks' into (libchip and) the BSP are also provided here (to aid in an efficient translation).  [NOTE: I can see an
argument which says 'But I don't want my handler to be delayed/virtualized by RTEMS'.  Ok, a flag could be given to indicate that
the interrupt is not to be virtualized, but then the physical IRQ for this handler cannot be shared, and will run at a 'higher
priority' than all the virtualized interrupts].

When an interrupt occurs, a handler installed by the BSP (not necessarily the one the app gave) executes.  This either calls the
common RTEMS api virtualizer or the actual handler installed by the application.  Either way, the called-interrupt API is the same,
as well as the API that is available to the handler itself.

-bogdan


On Sunday, October 24, 2004 1:33 PM, Bogdan Vacaliuc wrote:
> Hello Thomas,
> 
>> But in many realtime systems, there are at least one or two interupt
>> sources, that have hard limits concerning latency. And as a system
>> designer, I really want to have the capability to specify the handler
>> priority (or chain location) of these devices.
> 
> Yes, the handler priority.  I would suggest that priority be an
> attribute of the IRQ (slot or chain head or whatever), not for any
> handlers on a given chain.  
> 
>> I would even postulate this (Thomas' first postulate on interrupt
>> chaining location) : If a device/handler can accept to be shuffled
>> around in the chain, it can also accept to be always located at the
>> end of the chain, because obviously it has very relaxed latency
>> requirements.
> 
> I agree; good postulate.  In this case it is unnecessary to specify
> chain location. 
> 
>>> 'serviced' its device, then that handler would go to the end of the
>>> list (of handlers for a given interrupt).  If the interrupt was
>>> still asserting, the other handlers would get a chance to service
>>> before this one.
>> 
>> This can come up in certain applications. So maybe an option would
>> 	be nice to specify that - either a chain will be polled 'til the
>> end even if a handler already has claimed this interrupt
>> 	- or that the chain will be rearanged as you have
>> proposed.
> 
> Both of these are (must be) equivalent in terms of servicing the
> interrupt handlers within the same interrupt epoch.  That is, for a
> given IRQ all handlers which have devices interrupting (physically)
> must be called at least once.  The goal of the second approach is (on
> the surface) to avoid excessively calling the handlers for devices
> which are not actually interrupting.     
> 
> However, there is a difference in the behavior of the two, as I see
> it.  In "poll 'till end", the handling of *higher priority IRQ's* is
> delayed until the chain of handlers on this (lower priority) IRQ are
> serviced.  In 'rearrange chain', you are allowing the interrupt
> system to re-evaluate priorities from the top after *each* interrupt
> handler is executed, thus ensuring the appropriate prioritization is
> enforced.      
> 
>> From a user's point of view, it would even be nice to specify this
>> for a subsection of a chain, for example for all devices that had
>> been linked to the chain with the same "priority" or position
>> parameter. But this might be difficult/time consuming to implement.
> 
> It seems to me that the "poll 'till end" is never desirable, because
> of the potential delay as more handlers are added to a given IRQ.  I
> see two kinds of interrupt management for a deterministic real time
> system:   
> 
> 1) Total virtualization of interrupts.  This is where each handler
> for each device is installed at a unique (virtual) IRQ level that
> defines its priority.  Every handler executes, and if it indicates
> that service was performed, the interrupt processing starts over from
> the top.  The fact that some interrupts are shared or edge triggered
> or level sensitive or whatever is a detail under the hood.     
> 
> I think this is what you are talking about when you say you want to
> have control over location and position in a chain. 
> 
> 2) Round-Robin handling of shared interrupts.  This is where priority
> processing is applied to non-shared interrupt slots only.  Handlers
> on an IRQ that are shared among devices get serviced in a fairly
> distributed manner.   
> 
> This is what I was talking about.