Re: Interrupt handling and routing: The Big Picture

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

On Sun, 11 Mar 2012 15:27:20 +0100
Frank Wille <frank%phoenix.owl.de@localhost> wrote:

> > My problem is: Where and how to hook up what code to deal with the
> > special PIC of the MPC5200.
> See my previous posting.
And from this:

--- schnipp ---
> > Finally I stated to hack port-ofppc to support my Efika.
> That's great! I always wanted to start with it myself,
Whom do you tell? My Efika collected dust on a shelf for years.

> but I repeatedly decided to work on other hardware first,
> because Efika-support is so difficult to add.
Don't frighten me. ;-)

> I have three Efikas here. One is running MorphOS.
> 
> Also Robert Swindells tried to start a port some time ago:
> http://mail-index.netbsd.org/port-ofppc/2008/03/04/msg000516.html
We have this stuf in tree. You can boot a plain GENERIC kernel on the
Efika. It will detect only PCI devices but can't use them due to
missing interrupts. It gets as far as asking for a root-device.

> > Interrupts are next on the plan. The MPC5200 has its own, special
> > interrupt controller that is not compatible to any other interrupt
> > controller like OpenPIC. So everything in that area has to be coded new
> > from the ground up.
> Yes. This is one of the reasons which frightened me away from it.
Most likely the interrupts will be the lesser problem because...

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

The reason I attacked USB first is simply because it is OHCI compliant.
We have a MI driver backend in tree already. So all I need is the bus
attachment and interrupts to get this going. This way I can concentrate
on these two topics first without the need to fight BestComm.

> I found the MPC5200B User's Manual very hard to read. I was always confused
> what the meaning of local-bus and XLB-bus is... ;)
Most datasheets are hard to read... ;-(

> You're right. I don't see much reasons that genofw_find_ofpics() is in
> pci_machdep_ofw.c either. Maybe it should be in powerpc/ofw_machdep.c.
OK, one confusion less.

> To support the MPC5200 PIC you probably have to do two things:
> - Implement powerpc/pic/pic_mpc5200.c. It just contains the hw-dependant
>   functions for establising/disestablishing, enalbing/disabling interrupts.
> - Define a new PICNODE_TYPE_5200 and detect it in genofw_find_ofpics().
>   You may even check the model_name for it, when there is no other way to
>   find it.
OK. I already thought that it has to go somthing like this. Now I know
my guess was right. ;-)

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

> > 1st Problem: How to get an interrupt to the handler of the device?
[...]
> > OK. Seems I don't need to fight with this.
> Indeed.
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()?

> You need to detect the PICNODE_TYPE. Then you will check for this type in
> init_ofppc_interrupt() and call the PIC's setup-function, e.g.
> setup_mpc5200() (from powerpc/pic/pic_mpc5200.c, which you have to write).
> 
> This function will initialize everything for the PIC and call pic_add().
So my guesswork was about correct.

> > 3rd Problem: How to hookup to autoconf(9).
> > In addition I have to provide something like "efika_intr_map()".
> Hm. You mean for the embedded devices?
Yes. And I suspect pci_intr_map(9) will have to call is in cascade too. 

> > It
> > maps the OFW interrupt properties as given by the device attach
> > arguments to a "hwirq" to feed this in turn to intr_establish()? This
> > should be enough to get the on chip peripherals running.
> 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. Now I need a mapping function that maps
these native interrupt specifiers to a "hwirq" that can be feed to
intr_establish(). I.e. pci_intr_map(9) seems to do the mapping from PCI
IRQ to native interrupt specifier. Or perhaps this is done later in
pci_intr_establish(9)?

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

> > The PCI code has generic functions for this. (genofw_pci_intr_map()
> > genofw_setup_pciintr_map()) I still have no clue about how to shove
> > "efika_intr_map()" in there. As PCI is optional, I'll don't care about
> > this at the moment.
> 
> You can always check the model_name for "Efika" and then call
> efika_intr_map() for the embedded MPC5200 devices.
I'll see. I'll care about PCI when I got the on chip peripherals
working. It will be funky as PCI and the ATA / IDE bus share the same
signal lines. So no PCI access while an ATA transaction is going and
vice versa.

> I would even suggest to call it mpc5200_intr_map() and make a new directory
> like arch/powerpc/mpc5200 for all the new device drivers.
I'll do this in a second step. For the start I keep everything in
ofppc/efika. Once I sorted out how things work I'll refactor it and do
a proper MD / MI split.

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

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


\end{Jochen}

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