=20

> -----Original Message-----
> From: port-ofppc-owner@NetBSD.org=20
> [mailto:port-ofppc-owner@NetBSD.org] On Behalf Of Jochen Kunz
> Sent: Monday, July 17, 2006 6:50 PM
> To: port-ofppc@netbsd.org; netbsd-ports@netbsd.org;=20
> port-powerpc@netbsd.org
> Subject: Re: Pegasos port status
>=20
> On Mon, 17 Jul 2006 21:22:35 +0200
> Jorge Acereda Maci=E1 <jacereda@gmail.com> wrote:
>=20
> > OFW also provides interrupt handling.
>
> How? AFAIK OFW provides interrupt mapping information via the=20
> properties of device nodes. But there is no generic interrupt=20
> interface. (E.g. OFW calls OS back if a device has signaled=20
> an interrupt or the like.) That is why port ofppc runs so=20
> slow. All OFW device drivers use polling.

This is true. Jorge is what we might call a "CHRP Priest" in that
if you read the CHRP docs, and look at the IEEE 1275 interface
for interrupt handlers, you have EVERYTHING you need to support
an OpenPIC interrupt controller.

Of course we are deviating just a tiny bit from the specification
as the Pegasos etc. and pretty much every other controller on the
planet doesn't use OpenPIC. Since this is on the order of.. 6
lines of code to switch between an OpenPIC controller and any other,
and the firmware more than adequately abstracts the controller
settings in order to properly set up any other controller in a
native driver, the distinction that "you need OpenPIC to be true
CHRP" I think is preaching.

Even with the support implemented so the OS can handle it, *ALL*
device drivers inside the OF are practically disallowed from
causing or handling interrupts, as it is just not possible to
do it with the MMU disabled, under RTAS the CPU interrupt (machine
check) is disabled too, while you are in a context switch from the
OS.

Imagine the OF causes an interrupt, it needs to be told to
the OS so that the OS context switches into the Firmware to handle
it, and this context switch during interrupt handling is at the
worst place. The last thing you want to do in an interrupt handler
is wait a thousand cycles for a switch to real-mode, and then
reparse the MMU device tree node and do manual address translations.

--=20
Matt Sealey <matt@genesi-usa.com>
Manager, Genesi, Developer Relations