RE: [ECOS] Interrupt arbitration on MPC555

[Jesper Skov <jskov at redhat dot com>]

>>>>> "Bob" == Bob Koninckx <bob.koninckx@mech.kuleuven.ac.be> writes:

Bob> Sure, it makes sense. I specifically like the idea of enabling it
Bob> only on level 7.  Is this chaining mechanism documented ?? I
Bob> didnt find it at first sight, might have looked over it though.

Yes and no. There's the generic chaining mechanism which can be
enabled with a config option.

But what you want - a special chaining handler on a specific interrupt
level - is something you'll have to write yourself.  But just like the
existing arbiters in the PPC HAL, there's no reason this code could
not be integrated into eCos and have suitable configuration options
associated with it.  For instance, I just added some simple
configuration options for the SIU arbiter in the PPC mpc8xx HAL.

Bob> Yet anoter question: suppose all the above were available, who is
Bob> responsible for setting up the arbiters ?? I suppose it belongs
Bob> in the device driver, right before creating the interrupts, want
Bob> to hear it from the specialist.

Specialist? I think you'd better wait for some of the brainy Red Hat
employees to reply then :)


But it's a good question. Without spending too much thinking about it
(i.e., it may be a dumb way to do it) I would set up a
variant-specific wrapper for the allocation of interrupt sources.

That is, the drivers would call mpc5xx_attach_interrupt (or similar)
which gets defined in the variant interrupt code and keeps track of
what levels are in use. It could be based on either HAL macros (like
the existing arbiters in the PPC HAL) or the kernel interrupt API.

So the first time mpc5xx_attach_interrupt is called, it will attach
the driver's arbiter/ISR directly to the vector. On the second call,
it will put the two drivers's arbiters/ISRs in a list and attach the
chain-handler on the vector instead - that chain handler would then
call the abiters/ISRs in turn. Next calls would just add to the
chain-handler's list.

The chain-handler needs to emulate the kernel's calling of ISR, filing
DSRs as necessary - semantics must be the same from the ISR/DSRs
viewpoint whether being invoked through the chain-handler or directly
from the kernel interrupt handlers.

Some of this could be hardwired by configuration settings to save some
cycles and bytes (i.e., if only one source uses lvl7 there's no reason
to have the chain-handling magic in place, just as if you know
multiple sources would use the level, the chain-handler could be set
up immediately).

Make any sense?  I'm sure it would be possible to achieve the desired
performance while providing a nice abstraction, possibly by the help
of some configuration magic.

Jesper