When running qemu in -M mac99 mode, interrupts failed on me all the time.
I finally managed to track things down and it seems like we're missing some properties in several devices.
While at it, I also bumped the ESCC IRQs to 0x24 / 0x25, as that's what qemu now maps them on.
This patch (plus the qemu set) gets PPC64 Linux booting with console=ttyPZ0.
Signed-off-by: Alexander Graf agraf@suse.de
Index: drivers/macio.c =================================================================== --- drivers/macio.c (revision 644) +++ drivers/macio.c (working copy) @@ -145,6 +145,7 @@ static void openpic_init(const char *path, uint32_t addr) { + phandle_t target_node; phandle_t dnode; int props[2]; char buf[128]; @@ -154,7 +155,6 @@ fword("new-device"); push_str("interrupt-controller"); fword("device-name"); - fword("finish-device");
snprintf(buf, sizeof(buf), "%s/interrupt-controller", path); dnode = find_dev(buf); @@ -168,6 +168,21 @@ set_int_property(dnode, "#address-cells", 0); set_property(dnode, "interrupt-controller", "", 0); set_int_property(dnode, "clock-frequency", 4166666); + + fword("finish-device"); + + if (is_newworld()) { + /* patch in interrupt parent */ + dnode = find_dev(buf); + target_node = find_dev("/pci"); + set_int_property(target_node, "interrupt-parent", dnode); + + target_node = find_dev("/pci/mac-io/escc/ch-a"); + set_int_property(target_node, "interrupt-parent", dnode); + + target_node = find_dev("/pci/mac-io/escc/ch-b"); + set_int_property(target_node, "interrupt-parent", dnode); + } }
DECLARE_NODE(ob_macio, INSTALL_OPEN, sizeof(int), "Tmac-io"); Index: drivers/escc.c =================================================================== --- drivers/escc.c (revision 644) +++ drivers/escc.c (working copy) @@ -418,6 +418,11 @@ OLDWORLD(set_property(dnode, "AAPL,interrupts", (char *)&props, 1 * sizeof(cell)));
+ props[0] = 0; + props[0] = (0x24) + offset; + NEWWORLD(set_property(dnode, "interrupts", + (char *)&props, 2 * sizeof(cell))); + device_end();
uart_init_line((unsigned char*)addr + IO_ESCC_OFFSET + offset * 0x20,
Le vendredi 18 décembre 2009 à 23:44 +0100, Alexander Graf a écrit :
When running qemu in -M mac99 mode, interrupts failed on me all the time.
I finally managed to track things down and it seems like we're missing some properties in several devices.
While at it, I also bumped the ESCC IRQs to 0x24 / 0x25, as that's what qemu now maps them on.
This patch (plus the qemu set) gets PPC64 Linux booting with console=ttyPZ0.
Signed-off-by: Alexander Graf agraf@suse.de
Applied, thanks.
Laurent
Am 18.12.2009 um 23:44 schrieb Alexander Graf:
Index: drivers/escc.c
--- drivers/escc.c (revision 644) +++ drivers/escc.c (working copy) @@ -418,6 +418,11 @@ OLDWORLD(set_property(dnode, "AAPL,interrupts", (char *)&props, 1 * sizeof(cell)));
- props[0] = 0;
- props[0] = (0x24) + offset;
It's probably a stupid question again, but is there a reason to double- initialize props[0]? Shouldn't one of them go to a different index or the first one be dropped?
Andreas
NEWWORLD(set_property(dnode, "interrupts",
(char *)&props, 2 * sizeof(cell)));device_end();
uart_init_line((unsigned char*)addr + IO_ESCC_OFFSET + offset *
0x20,
-- OpenBIOS http://openbios.org/ Mailinglist: http://lists.openbios.org/mailman/listinfo Free your System - May the Forth be with you
On 19.12.2009, at 00:43, Andreas Färber wrote:
Am 18.12.2009 um 23:44 schrieb Alexander Graf:
Index: drivers/escc.c
--- drivers/escc.c (revision 644) +++ drivers/escc.c (working copy) @@ -418,6 +418,11 @@ OLDWORLD(set_property(dnode, "AAPL,interrupts", (char *)&props, 1 * sizeof(cell)));
- props[0] = 0;
- props[0] = (0x24) + offset;
It's probably a stupid question again, but is there a reason to double-initialize props[0]? Shouldn't one of them go to a different index or the first one be dropped?
Yes, but the real question is a different one.
[01:02] benh: so any node whose interrupt parent is directly the MPIC will have 2 cells per interrupts [01:02] benh: the first one is the line number, the second is polarity/sense
So I guess props[0] is correct, but props[1] needs to define if it's edge/level(?).
Alex
On Sat, 2009-12-19 at 00:50 +0100, Alexander Graf wrote:
On 19.12.2009, at 00:43, Andreas Färber wrote:
Am 18.12.2009 um 23:44 schrieb Alexander Graf:
Index: drivers/escc.c
--- drivers/escc.c (revision 644) +++ drivers/escc.c (working copy) @@ -418,6 +418,11 @@ OLDWORLD(set_property(dnode, "AAPL,interrupts", (char *)&props, 1 * sizeof(cell)));
- props[0] = 0;
- props[0] = (0x24) + offset;
It's probably a stupid question again, but is there a reason to double-initialize props[0]? Shouldn't one of them go to a different index or the first one be dropped?
Yes, but the real question is a different one.
[01:02] benh: so any node whose interrupt parent is directly the MPIC will have 2 cells per interrupts [01:02] benh: the first one is the line number, the second is polarity/sense
So I guess props[0] is correct, but props[1] needs to define if it's edge/level(?).
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.
Cheers, Ben.
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.
Cheers, Ben.
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.
Am 20.12.2009 um 00:26 schrieb Benjamin Herrenschmidt <benh@kernel.crashing.org
:
On Sat, 2009-12-19 at 00:50 +0100, Alexander Graf wrote:
On 19.12.2009, at 00:43, Andreas Färber wrote:
Am 18.12.2009 um 23:44 schrieb Alexander Graf:
Index: drivers/escc.c
--- drivers/escc.c (revision 644) +++ drivers/escc.c (working copy) @@ -418,6 +418,11 @@ OLDWORLD(set_property(dnode, "AAPL,interrupts", (char *)&props, 1 * sizeof(cell)));
- props[0] = 0;
- props[0] = (0x24) + offset;
It's probably a stupid question again, but is there a reason to double-initialize props[0]? Shouldn't one of them go to a different index or the first one be dropped?
Yes, but the real question is a different one.
[01:02] benh: so any node whose interrupt parent is directly the MPIC will have 2 cells per interrupts [01:02] benh: the first one is the line number, the second is polarity/sense
So I guess props[0] is correct, but props[1] needs to define if it's edge/level(?).
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.
Yes, it's completely arbitrary.
I looked up what the properties look like on the powerstation and it had a setup exactly like this. In fact, the irq lookup debug code in linux breaks when ch-a does not define an interrupt parent.
I'm totally open to alternatives or hints what real hw does!
Alex
-
Alexander Graf -
Andreas Färber -
Benjamin Herrenschmidt -
Laurent Vivier