[ECOS] Interrupt arbitration on MPC555

[ECOS] Interrupt arbitration on MPC555

[Bob Koninckx]

Hi,

I have some problems with interrupt arbitration on the MPC555. This
microcontroller has a number of on-chip peripherals like CAN controllers,
Serial controllers etc. These peripherals can be assigned (by software) an
interrupt priority from 0(highest) to 31(lowest).

The MPC555 is build around a powerpc-core and handles 8 interrupt levels. It
is clear that some kind of arbitration is needed (comparable to what is
available for the powerpc version of eCos).

The interrupt priority of the peripheral determines the interrupt level (and
hence the arbitration), priorities o to 6 are mapped to levels 0 to 6,
priorities 7 to 31 are all mapped to level 7.

I suppose not every application is interested in using the same priorities,
some might like to assign a high priority to CAN-interruipts and do not even
use the TPU, for another application it might be necessary to assign a
higher priority (and hence different arbitration) to the TPU than the
CAN-controller. These are strong arguments to assign these priorities and
setup the arbitration somewhere during startup of the APPLICATION.

On the other hand, it also makes sense to use device drivers for can, serial
ports etc,... These device drivers have to create interrupts and hence have
to know the priority of these interrupts. So it seems you have to set-up
priorities and arbitration somewhere within ECOS. And then you lose all
flexibility ....

Any suggestions ???

Regards,
Bob

------------------------------------------------------------------------
ir. Bob Koninckx
Katholieke Universiteit Leuven
Division Production Engineering,                      tel. +32 16 322535
Machine Design and Automation                         fax. +32 16 322987
Celestijnenlaan 300B                 bob.koninckx@mech.kuleuven.ac.be
B-3001 Leuven Belgium            http://www.mech.kuleuven.ac.be/pma.html
------------------------------------------------------------------------

Re: [ECOS] Interrupt arbitration on MPC555

[Jesper Skov]

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

Bob> I suppose not every application is interested in using the same
Bob> priorities, some might like to assign a high priority to
Bob> CAN-interruipts and do not even use the TPU, for another
Bob> application it might be necessary to assign a higher priority
Bob> (and hence different arbitration) to the TPU than the
Bob> CAN-controller. These are strong arguments to assign these
Bob> priorities and setup the arbitration somewhere during startup of
Bob> the APPLICATION.

Bob> On the other hand, it also makes sense to use device drivers for
Bob> can, serial ports etc,... These device drivers have to create
Bob> interrupts and hence have to know the priority of these
Bob> interrupts. So it seems you have to set-up priorities and
Bob> arbitration somewhere within ECOS. And then you lose all
Bob> flexibility ....

I think this belongs in the eCos configuration. I don't see how that
loses you any flexibility: normally you would configure eCos for your
application needs anyway.

Jesper

RE: [ECOS] Interrupt arbitration on MPC555

[Bob Koninckx]

I agree, It would be nice if you could fit it into the eCos configuration,
however, I don't see how to do this, since changing priorities also means
changing code.

Suppose you assign priority 3 to toucan A (the first can controller) and
priority 15 to toucan B. Every can controller has a total of 19 interrupt
sources, sou you have to setup an arbiter on level3 that checks and further
decodes the interrupt, same thing on level 7.

Another configuration (for another application) could assign priorities 15
and 16, meaning that a completely different arbiter is now needed on level7
(one that checks both can controllers).

The arbiter surely cannot be integrated into the device drivers, it might be
that besides the can controllers also TPUs are using level 7.

For the powerpc, you were able to write these general arbiters for TimeBase,
RTC etc ... You can still do this on the MPC555 for these sources, you
cannot do it for the TOUCAN, TPU, MIOS, SCI, SPI since they are not
connected directly to the SIU. They are connected to the SIU by means of the
IMB3.

The point I am trying to make is :
if you write a general arbiter for toucan, tpu, mios, sci etc ..., these
will only work fine for priorities lower than 7. If two devices are assigned
priorities above 6, you should be able to connect more than one arbiter on
level 7

Regards,
Bob

> -----Original Message-----
> From: jskov@redhat.com [ mailto:jskov@redhat.com ]
> Sent: Friday, February 25, 2000 10:31 AM
> To: bob.koninckx@mech.kuleuven.ac.be
> Cc: ecos discussion forum
> Subject: Re: [ECOS] Interrupt arbitration on MPC555
>
>
> >>>>> "Bob" == Bob Koninckx <bob.koninckx@mech.kuleuven.ac.be> writes:
>
> Bob> I suppose not every application is interested in using the same
> Bob> priorities, some might like to assign a high priority to
> Bob> CAN-interruipts and do not even use the TPU, for another
> Bob> application it might be necessary to assign a higher priority
> Bob> (and hence different arbitration) to the TPU than the
> Bob> CAN-controller. These are strong arguments to assign these
> Bob> priorities and setup the arbitration somewhere during startup of
> Bob> the APPLICATION.
>
> Bob> On the other hand, it also makes sense to use device drivers for
> Bob> can, serial ports etc,... These device drivers have to create
> Bob> interrupts and hence have to know the priority of these
> Bob> interrupts. So it seems you have to set-up priorities and
> Bob> arbitration somewhere within ECOS. And then you lose all
> Bob> flexibility ....
>
> I think this belongs in the eCos configuration. I don't see how that
> loses you any flexibility: normally you would configure eCos for your
> application needs anyway.
>
> Jesper
>

RE: [ECOS] Interrupt arbitration on MPC555

[Jesper Skov]

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

Bob> The point I am trying to make is : if you write a general arbiter
Bob> for toucan, tpu, mios, sci etc ..., these will only work fine for
Bob> priorities lower than 7. If two devices are assigned priorities
Bob> above 6, you should be able to connect more than one arbiter on
Bob> level 7

You should be to achieve this by enabling interrupt chaining -
arbiters would be called in sequence and should Do The Right
Thing(TM).

I think it would probably impact performance a bit though (to enable
global interrupt chaining). It might be desirable to add a (suitably
hacked up) chaining-handler to level 7 and register the toucan, tpu,
etc, with this chaining handler. It would call each of those arbiters
in turn.

Did that make any sense?

Jesper

RE: [ECOS] Interrupt arbitration on MPC555

[Bob Koninckx]

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

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

Thanks,
Bob


> -----Original Message-----
> From: ecos-discuss-owner@sourceware.cygnus.com
> [ mailto:ecos-discuss-owner@sourceware.cygnus.com]On Behalf Of Jesper
> Skov
> Sent: Friday, February 25, 2000 11:14 AM
> To: bob.koninckx@mech.kuleuven.ac.be
> Cc: ecos discussion forum
> Subject: RE: [ECOS] Interrupt arbitration on MPC555
>
>
> >>>>> "Bob" == Bob Koninckx <bob.koninckx@mech.kuleuven.ac.be> writes:
>
> Bob> The point I am trying to make is : if you write a general arbiter
> Bob> for toucan, tpu, mios, sci etc ..., these will only work fine for
> Bob> priorities lower than 7. If two devices are assigned priorities
> Bob> above 6, you should be able to connect more than one arbiter on
> Bob> level 7
>
> You should be to achieve this by enabling interrupt chaining -
> arbiters would be called in sequence and should Do The Right
> Thing(TM).
>
> I think it would probably impact performance a bit though (to enable
> global interrupt chaining). It might be desirable to add a (suitably
> hacked up) chaining-handler to level 7 and register the toucan, tpu,
> etc, with this chaining handler. It would call each of those arbiters
> in turn.
>
> Did that make any sense?
>
> Jesper
>

RE: [ECOS] Interrupt arbitration on MPC555

[Jesper Skov]

>>>>> "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