Re: Interrupt handling and routing: The Big Picture

[Frank Wille <frank%phoenix.owl.de@localhost>]

On Sun, 11 Mar 2012 19:00:42 +0100
Jochen Kunz <jkunz%unixag-kl.fh-kl.de@localhost> wrote:

> > The others are the many MPC5200-specific embedded devices,
> > which you need to support.
> that is the real problem. Most due to the funky BestComm DMA engine
> that is shared between all devices.

True. Although you are not forced to use DMA, it makes not much sense to
develop a driver without it.

IIRC there were also hardware bugs with DMA, when using IDE and ethernet
at the same time.


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


> > Make sure to have a look at pic_mpcsoc.c (which is used for the
> > MPC824x, for example). There may be similarities to the MPC5200 PIC.
> I have to check. pic_mpcsoc.c is just a small wrapper around an
> OpenPIC. Documentation for the OpenPIC seems to be non-existent. But
> from a glance at openpicreg.h the MPC5200 PIC seems to be very
> different.

You're right. I just checked the MPC5200UM again. It has nothing to do
with OpenPIC.


> I have to admit I have no clue about PPC CPU internals. So this
> question my be very stupid. One thing in this area isn't clear to me
> still: The MPC5200 PIC can signal three different interrupts to the
> CPU: core_cint, core_smi and core_int that map to MSR[ce], MSR[ee] and
> MSR[ee]. How do I tell the interrupt code that I use MSR[ce] or MSR
> [ee]? Or can I use MSR[ee] only? Because of that "& ~PSL_EE" in
> pic_do_pending_int()?

Hmmm. I guess our powerpc/pic is only suitable for older G2/G3/G4 CPUs
with just one interrupt signal.

Maybe newer CPUs with critical interrupts should be handled like in
powerpc/booke/e500_intr.c ?


> > This should be done by genofw_setup_pciiintr_map(). It will either
> > read the interrupt information directly from the Efika's OFW nodes,
> > or it will fallback to reading the interrupts from the PCI device
> > (as for the Pegasos2).
> genofw_setup_pciiintr_map() does set up the interrupt map for the PCI
> bus. As I understand it this map is used to map PCI interrupts to
> native interrupt specifiers.

Right.


> 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?
So such a mapping wouldn't be needed.

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.


> > Check the OFW tree of you Efika if it contains information about the
> > interrupts (I don't remember ATM).
> It seems to have proper interrupt properties.

That's good news. So you just have to read the OFW properties, in the same
way as from the PCI tree.


> > Is the MPC5200 compatible to other CPUs?
> The CPU core is a PPC603e.

Yes. :)
My intention was more like: are there any PPC-family CPUs which have
similar embedded devices as the MPC5200B has?

I guess that the MPC5200 is very special...


> 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. :)

I very much liked reading your Driver Writing Guide when I became a
developer, some years ago.

-- 
Frank Wille