Re: Interrupt handling and routing: The Big Picture

[Jochen Kunz <jkunz%unixag-kl.fh-kl.de@localhost>]

On Mon, 12 Mar 2012 16:55:58 +0100
Frank Wille <frank%phoenix.owl.de@localhost> wrote:

> IIRC there were also hardware bugs with DMA, when using IDE and ethernet
> at the same time.
Delicious. ;-(

> > The Fast Ethernet Controller will
> > be quite some work, I suspect. But I have written the Ethernet iee(4)
> > driver from scratch. So I am somewhat prepared.
> I wonder if this FEC is compatible with the ColdFire FEC?
> But probably not, when BestComm is involved.
I don't know the ColdFire FEC. Do we have code for it in tree? 

> Hmmm. I guess our powerpc/pic is only suitable for older G2/G3/G4 CPUs
> with just one interrupt signal.
Probably. I have no clue about PPC CPU internas.

> Maybe newer CPUs with critical interrupts should be handled like in
> powerpc/booke/e500_intr.c ?
Well. It looks like I can programm the PIC so that it only generates
standard interrupts...

> > Now I need a mapping function that maps
> > these native interrupt specifiers to a "hwirq" that can be feed to
> > intr_establish().
> Isn't there a fixed interrupt (hwirq) for each embedded hardware device?
Yes. But the hwirq is just an int number. The MPC5200 PIC has four
types of interrupts: Peripheral, External, Main and BestComm. All these
interrupts are numbered starting at 0. So I have to do some things
like: hwirq 0..31 is External, 32..63 is Main, 64..95 is Peripheral,
96..112 is BestComm. At least the OpenFirmWare seems to do something
like this. The FEC has this three interrupts, from the OWF properties:
efikaethernet0 at efikabuiltin0
          intr: 0x00000002 0x00000005 0x00000003
        rxintr: 0x00000003 0x00000004 0x00000003
        txintr: 0x00000003 0x00000005 0x00000003
The first cell is the interrupt type. 2 is Peripheral, 3 is BestComm.
The second cell is the actual interrupt number. For BetComm interrupts
this is the task number. The third cell denotes low level triggered.
As you can see IRQ #5 is ambiguous. It needs to be argumented by the
interrupt type / domain to map it into the single, linear space of
hwirq.

> A difficulty will be that you need to find out in which way each embedded
> device has been configured. It may be known for the Efika, but there may
> be other 5200B-based devices.
> 
> For example a PSC device could be a serial port, a modem or an audio output.
Yes. That is a problem. Maybe. It just means that you can not write a
single, general, MI driver for a PSC device. You will allways need some
MD drivers.

> My intention was more like: are there any PPC-family CPUs which have
> similar embedded devices as the MPC5200B has?
OK, you say "CPU" but you mean "SOC". ;-)

> I guess that the MPC5200 is very special...
Probably. At least I could not find signs of somthing similar in the
existing NetBSD source.

> > BTW: The ultimate goal isn't only to get support for the Efika. I plan
> > to update the NetBSD Device Driver Writing Guide that I wrote some
> > years ago. It needs to be integrated into the NetBSD Internals Guide
> > also. I'll use the lessons learned from the Efika as additional
> > examples in this new version of the guide. 
> A commendable intent. :)
A update is overdue. Keep in mind how the NetBSD Device Driver Writing
Guide came into existence: Pure frustration. Lots of it. When I started
to hack the NetBSD kernel many things where undocumented or there where
man pages with only a brief reference. Nothing that explained The Big
Picture, how things interact. So I took some notes for my self during
my reverse engineering of the kernel source. Later I thought that this
could be helpfull for others and added some LaTeXnic...

> I very much liked reading your Driver Writing Guide when I became a
> developer, some years ago.
Thanks for the flowers. :-)
-- 


\end{Jochen}

\ref{http://www.unixag-kl.fh-kl.de/~jkunz/}