qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [Qemu-ppc] [PATCH] 40p: fix PCI interrupt routing


From: BALATON Zoltan
Subject: Re: [Qemu-devel] [Qemu-ppc] [PATCH] 40p: fix PCI interrupt routing
Date: Mon, 27 Aug 2018 19:12:29 +0200 (CEST)
User-agent: Alpine 2.21 (BSF 202 2017-01-01)

On Mon, 27 Aug 2018, Mark Cave-Ayland wrote:
According to the PReP specification section 6.1.6 "System Interrupt
Assignments", all PCI interrupts are routed via IRQ 15.

With this patch applied it is now possible to boot the sandalfoot
zImage all the way through to a working userspace when using
OpenBIOS.

Signed-off-by: Mark Cave-Ayland <address@hidden>
---
hw/ppc/prep.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/hw/ppc/prep.c b/hw/ppc/prep.c
index 162b27a3b8..e82c1355d9 100644
--- a/hw/ppc/prep.c
+++ b/hw/ppc/prep.c
@@ -668,10 +668,11 @@ static void ibm_40p_init(MachineState *machine)
    dev = DEVICE(pci_create_simple(pci_bus, PCI_DEVFN(11, 0), "i82378"));
    qdev_connect_gpio_out(dev, 0,
                          cpu->env.irq_inputs[PPC6xx_INPUT_INT]);
-    sysbus_connect_irq(pcihost, 0, qdev_get_gpio_in(dev, 15));
-    sysbus_connect_irq(pcihost, 1, qdev_get_gpio_in(dev, 13));
-    sysbus_connect_irq(pcihost, 2, qdev_get_gpio_in(dev, 15));
-    sysbus_connect_irq(pcihost, 3, qdev_get_gpio_in(dev, 13));
+    /* According to PReP specification section 6.1.6 "System Interrupt
+     * Assignments", all PCI interrupts are routed via IRQ 15 */
+    for (i = 0; i < PCI_NUM_PINS; i++) {
+        sysbus_connect_irq(pcihost, i, qdev_get_gpio_in(dev, 15));
+    }

I'm not sure but this looks similar to what we had with sam460ex:

http://lists.nongnu.org/archive/html/qemu-ppc/2018-07/msg00359.html

I think you may not connect multiple interrupts to the same host irq line this way but you either need an OR gate or handle it within the mapping in the PCI host model (which is what we ended up with for the sam460ex). Peter's suggestion was to do whichever matches real hardware the most if you can find out that (as noted here also with more explanation that could be useful):

http://lists.nongnu.org/archive/html/qemu-ppc/2018-07/msg00360.html

But I could be mistaken in this case, haven't checked it in detail.

Regards,
BALATON Zoltan



reply via email to

[Prev in Thread] Current Thread [Next in Thread]