[OpenBIOS] [PATCH] Make interrupts work on newworld machines

Alexander Graf agraf at suse.de
Sun Dec 20 03:20:38 CET 2009

Am 20.12.2009 um 00:31 schrieb Benjamin Herrenschmidt <benh at kernel.crashing.org 

> On Sun, 2009-12-20 at 10:26 +1100, Benjamin Herrenschmidt wrote:
>> And that encoding depends on what the parent PIC is. I don't think  
>> the
>> drivers should setup their own interrupt properties that way anyways.
>> Platform code in forth should layout that stuff. Where does that 0x24
>> come from anyways ? It's just arbitrary crap. Nothing to do in the  
>> escc
>> driver itself.
> More specifically, in the case of macs, the ESCC, along with a lot of
> other devices, is part of the "macio" asic. There's various families  
> and
> generations of these, though we probably really only care about
> heathrow, keylargo and K2.
> How those interrupts are routed (and in fact the PIC itself) are a
> property of the ASIC.
> Thus the "ASIC" driver (again, it should be a bit of f-code that binds
> all that together) should layout the interrupt wiring for a given  
> chip.
> Now the interesting thing is that in large part that routing  
> information
> ends up being duplicated: in qemu to emulate the ASIC and in OpenBIOS.
> Thus, maybe a "smart" thing to do here would be to have a  
> representation
> inside qemu of the "bindings" (interrupt, address, driver maps) of a
> given macio-asic, that openbios can suck out using a private call and
> use to construct the device-tree. Or we could have qemu -itself- get  
> fed
> a device-tree, use it to instanciate the HW devices and pass it  
> along to
> openbios :-) That would also allow openbios-less booting using epapr  
> on
> ppc which is handy.

I think there is a proposal for exactly that going on on the qemu ml  
right now.

So I suppose the best would be to keep it hardcoded for now and move  
to the dt based approach later?


> Cheers,
> Ben.

More information about the OpenBIOS mailing list