Am 20.12.2009 um 00:31 schrieb Benjamin Herrenschmidt <benh@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?
Alex
Cheers, Ben.