Re: Multi-level CPM Interrupts

Re: Multi-level CPM Interrupts

[Wolfgang Denk]

In message <3BDD6F59.7070301@mvista.com> Dan Malek wrote:
>
> Wolfgang Grandegger wrote:
...
> > I have incorporated the CPM into the multilevel interrupt structure
> > on the 8xx.
>
> Why?
...
> Why is this good?

It seems you did not real until the end of Wolfgang's message; he wrote:

| it easily allows RTAI users to use CPM interrupts.


We need this for RTAI, and I don't see any problems with it.

> Please leave the 8xx/CPM interrupt stucture alone, and add some /proc

Would you please explain why you think the proposal is bad? ANd  what
is your recommendation for RTAI, then?

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
It took him several minutes to understand any new idea  put  to  him,
and  this is a very valuable trait in a leader, because anything any-
one is still trying to explain to you after two minutes  is  probably
important  and anything they give up after a mere minute or so is al-
most certainly something they shouldn't have been bothering you  with
in the first place.                   - Terry Pratchett, _Reaper Man_

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Multi-level CPM Interrupts

[Dan Malek]

Wolfgang Denk wrote:


> It seems you did not real until the end of Wolfgang's message; he wrote:
>
> | it easily allows RTAI users to use CPM interrupts.

Well, I know that other people are running RTLinux without the same
modification, so "easy" must be a relative :-).

> We need this for RTAI, and I don't see any problems with it.

The problem I have is that it is a reasonable argument for exactly
the _one_ board you have.  We have tried to do what you are asking
in the past, and it resulted in a big mess.  A multiple level interrupt
controller has interrupts numbered from zero to the extent of their
implemetation, few are the same.  Further, on processors with flexible
integrated peripherals, the _real_ interrupt number for that particular
service controller has to be programmed into the peripheral.  On one hand,
you "simplify" the programming interface, and on the other you make it
a confusing implementation of arithmetic/shift/macros and configuration
unique to nearly every board.  With the current implementation all of
the 8xx boards are generally supported (or generally broken, if you choose
the "half-empty" outlook on life :-).

In all cases, moving everything under a virtual, single programming
interface doesn't remove the underlying interrupt management you have
to perform in a RTLinux environment.  There is still _only one_ CPM
interrupt vector from the perspective of the exception handler.  IMHO,
you still have to design the software to work with that, so why not
just admit it's different under all circumstances instead of just one?

We had a multilevel interrupt structure for a short time back in the
late 2.1.xxx development days.  Because we couldn't find a way to make
it support the legacy PeeCee AT cards without changing the API in the
drivers, it was dropped.  I don't want to promote the kind of change
you are requesting because it will simply propagate and become the
same mess we have seen in the past.  The proper solution is to design
a multlevel interrupt structure and acknowledge the hooks necessary
for something like an RTLinux insertion.  This design goal isn't unique
to 8xx.  There are many PowerPC boards with a variety of interrupt
controller designs that would benefit from this.  Let's do something
to make forward progress that benefits everyone instead of a modification
unique to one board.

Thanks.


	-- Dan


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Multi-level CPM Interrupts

[Wolfgang Denk]

In message <3BE19161.8060402@mvista.com> you wrote:
>
> Well, I know that other people are running RTLinux without the same
> modification, so "easy" must be a relative :-).

Running RTAI or RTLinux is one thing, registering an interrupt for  -
say - a port C pin for a RT task is a different story.

> > We need this for RTAI, and I don't see any problems with it.
>
> The problem I have is that it is a reasonable argument for exactly
> the _one_ board you have.  We have tried to do what you are asking

What makes you think so? IMHO this is  a  generic  modification  that
will work on all 8xx CPUs and all boards based on 8xx CPUs.

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
Do not simplify the design of a program if a way can be found to make
it complex and wonderful.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Multi-level CPM Interrupts

[Wolfgang Grandegger]

Dan Malek wrote:

>
> Wolfgang Denk wrote:
>
>
>> It seems you did not real until the end of Wolfgang's message; he wrote:
>>
>> | it easily allows RTAI users to use CPM interrupts.
>
>
> Well, I know that other people are running RTLinux without the same
> modification, so "easy" must be a relative :-).

The problem only shows up, if CPM interrupts have to be handled in
real-time *and* in Linux at the same time. A customer actually wants
to handle the CPM-IRQ-PC4 on the RTAI layer, but at the same time
all other CPM interrupts (console, enet etc.) should still be handled
within Linux. It would require substantial modifications to RTAI (and
RTLinux) to deal with the CPM handler stuff ... just for the 8xx!

>
>> We need this for RTAI, and I don't see any problems with it.
>
>
> The problem I have is that it is a reasonable argument for exactly
> the _one_ board you have.  We have tried to do what you are asking

I'm confused. All 8xx have a CPM, are'nt they?

> in the past, and it resulted in a big mess.  A multiple level interrupt
> controller has interrupts numbered from zero to the extent of their
> implemetation, few are the same.  Further, on processors with flexible
> integrated peripherals, the _real_ interrupt number for that particular
> service controller has to be programmed into the peripheral.  On one
> hand,
> you "simplify" the programming interface, and on the other you make it
> a confusing implementation of arithmetic/shift/macros and configuration
> unique to nearly every board.  With the current implementation all of
> the 8xx boards are generally supported (or generally broken, if you
> choose
> the "half-empty" outlook on life :-).
>
> In all cases, moving everything under a virtual, single programming
> interface doesn't remove the underlying interrupt management you have
> to perform in a RTLinux environment.  There is still _only one_ CPM
> interrupt vector from the perspective of the exception handler.  IMHO,
> you still have to design the software to work with that, so why not
> just admit it's different under all circumstances instead of just one?
>
> We had a multilevel interrupt structure for a short time back in the
> late 2.1.xxx development days.  Because we couldn't find a way to make
> it support the legacy PeeCee AT cards without changing the API in the
> drivers, it was dropped.  I don't want to promote the kind of change
> you are requesting because it will simply propagate and become the
> same mess we have seen in the past.  The proper solution is to design
> a multlevel interrupt structure and acknowledge the hooks necessary
> for something like an RTLinux insertion.  This design goal isn't unique
> to 8xx.  There are many PowerPC boards with a variety of interrupt
> controller designs that would benefit from this.  Let's do something
> to make forward progress that benefits everyone instead of a modification
> unique to one board.

Sorry, I cannot follow. There is already a "multilevel interrupt structure"
which RTLinux/RTAI uses and - as far as I have seen - *apart* from the
CPM on the 8xx all secondary PowerPC interrupt controllers are incorporated
into this "multilevel interrupt structure" (see open_pic.c, i8259_pic.c,
pmac_pic.c).

Thanks,

Wolfgang.


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/