qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Peter Maydell <peter.maydell@linaro.org>
To: qemu-devel@nongnu.org
Cc: "Anthony Liguori" <aliguori@us.ibm.com>,
	"Arnd Bergmann" <arnd@arndb.de>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	"Linus Walleij" <linus.walleij@linaro.org>,
	patches@linaro.org, "Will Deacon" <will.deacon@arm.com>,
	"Joss Reeves" <joseph.reeves@gmail.com>,
	"Andreas Färber" <afaerber@suse.de>,
	"Aurelien Jarno" <aurelien@aurel32.net>
Subject: [Qemu-devel] [PATCH for-1.5 2/3] hw/pci-host/versatile.c: Update autodetect to detect newer kernels
Date: Tue, 14 May 2013 16:33:35 +0100	[thread overview]
Message-ID: <1368545616-22344-3-git-send-email-peter.maydell@linaro.org> (raw)
In-Reply-To: <1368545616-22344-1-git-send-email-peter.maydell@linaro.org>

Newer versatilepb kernels still don't get the IRQ mapping right
for the PCI controller, but they get it differently wrong (they add
a fixed +64 offset to everything they write to PCI_INTERRUPT_LINE).
Update the autodetection to handle these too, and include a more
detailed comment on the various different behaviours that might
be present.

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
---
 hw/pci-host/versatile.c |   69 ++++++++++++++++++++++++++++++++++++++++++-----
 1 file changed, 62 insertions(+), 7 deletions(-)

diff --git a/hw/pci-host/versatile.c b/hw/pci-host/versatile.c
index 2bb09fa..f19e2f5 100644
--- a/hw/pci-host/versatile.c
+++ b/hw/pci-host/versatile.c
@@ -28,6 +28,32 @@
  * this allows a newer kernel to use the INTERRUPT_LINE
  * registers arbitrarily once it has indicated that it isn't
  * broken in its init code somewhere.
+ *
+ * Unfortunately we have to cope with multiple different
+ * variants on the broken kernel behaviour:
+ *  phase I (before kernel commit 1bc39ac5d) kernels assume old
+ *   QEMU behaviour, so they use IRQ 27 for all slots
+ *  phase II (1bc39ac5d and later, but before e3e92a7be6) kernels
+ *   swizzle IRQs between slots, but do it wrongly, so they
+ *   work only for every fourth PCI card, and only if (like old
+ *   QEMU) the PCI host device is at slot 0 rather than where
+ *   the h/w actually puts it
+ *  phase III (e3e92a7be6 and later) kernels still swizzle IRQs between
+ *   slots wrongly, but add a fixed offset of 64 to everything
+ *   they write to PCI_INTERRUPT_LINE.
+ *
+ * We live in hope of a mythical phase IV kernel which might
+ * actually behave in ways that work on the hardware. Such a
+ * kernel should probably start off by writing some value neither
+ * 27 nor 91 to slot zero's PCI_INTERRUPT_LINE register to
+ * disable the autodetection. After that it can do what it likes.
+ *
+ * Slot % 4 | hw | I  | II | III
+ * -------------------------------
+ *   0      | 29 | 27 | 27 | 91
+ *   1      | 30 | 27 | 28 | 92
+ *   2      | 27 | 27 | 29 | 93
+ *   3      | 28 | 27 | 30 | 94
  */
 enum {
     PCI_VPB_IRQMAP_ASSUME_OK,
@@ -214,6 +240,41 @@ static const MemoryRegionOps pci_vpb_reg_ops = {
     },
 };
 
+static int pci_vpb_broken_irq(int slot, int irq)
+{
+    /* Determine whether this IRQ value for this slot represents a
+     * known broken Linux kernel behaviour for this slot.
+     * Return one of the PCI_VPB_IRQMAP_ constants:
+     *   BROKEN : if this definitely looks like a broken kernel
+     *   FORCE_OK : if this definitely looks good
+     *   ASSUME_OK : if we can't tell
+     */
+    slot %= PCI_NUM_PINS;
+
+    if (irq == 27) {
+        if (slot == 2) {
+            /* Might be a Phase I kernel, or might be a fixed kernel,
+             * since slot 2 is where we expect this IRQ.
+             */
+            return PCI_VPB_IRQMAP_ASSUME_OK;
+        }
+        /* Phase I kernel */
+        return PCI_VPB_IRQMAP_BROKEN;
+    }
+    if (irq == slot + 27) {
+        /* Phase II kernel */
+        return PCI_VPB_IRQMAP_BROKEN;
+    }
+    if (irq == slot + 27 + 64) {
+        /* Phase III kernel */
+        return PCI_VPB_IRQMAP_BROKEN;
+    }
+    /* Anything else must be a fixed kernel, possibly using an
+     * arbitrary irq map.
+     */
+    return PCI_VPB_IRQMAP_FORCE_OK;
+}
+
 static void pci_vpb_config_write(void *opaque, hwaddr addr,
                                  uint64_t val, unsigned size)
 {
@@ -221,13 +282,7 @@ static void pci_vpb_config_write(void *opaque, hwaddr addr,
     if (!s->realview && (addr & 0xff) == PCI_INTERRUPT_LINE
         && s->irq_mapping == PCI_VPB_IRQMAP_ASSUME_OK) {
         uint8_t devfn = addr >> 8;
-        if ((PCI_SLOT(devfn) % PCI_NUM_PINS) != 2) {
-            if (val == 27) {
-                s->irq_mapping = PCI_VPB_IRQMAP_BROKEN;
-            } else {
-                s->irq_mapping = PCI_VPB_IRQMAP_FORCE_OK;
-            }
-        }
+        s->irq_mapping = pci_vpb_broken_irq(PCI_SLOT(devfn), val);
     }
     pci_data_write(&s->pci_bus, addr, val, size);
 }
-- 
1.7.9.5

  parent reply	other threads:[~2013-05-14 15:55 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-14 15:33 [Qemu-devel] [PATCH for-1.5 0/3] hw/pci-host/versatile: Fix issues with newer kernels Peter Maydell
2013-05-14 15:33 ` [Qemu-devel] [PATCH for-1.5 1/3] Revert "versatile_pci: Put the host bridge PCI device at slot 29" Peter Maydell
2013-05-14 15:33 ` Peter Maydell [this message]
2013-05-14 15:33 ` [Qemu-devel] [PATCH for-1.5 3/3] hw/pci-host/versatile.c: Provide property for forcing broken IRQ mapping Peter Maydell
2013-05-15 14:02 ` [Qemu-devel] [PATCH for-1.5 0/3] hw/pci-host/versatile: Fix issues with newer kernels Linus Walleij
2013-05-16 16:58   ` Arnd Bergmann
2013-05-16 17:07     ` Peter Maydell
2013-05-17 11:50     ` Linus Walleij
2013-05-17 12:10       ` Peter Maydell
2013-05-16 12:50 ` Anthony Liguori

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1368545616-22344-3-git-send-email-peter.maydell@linaro.org \
    --to=peter.maydell@linaro.org \
    --cc=afaerber@suse.de \
    --cc=aliguori@us.ibm.com \
    --cc=arnd@arndb.de \
    --cc=aurelien@aurel32.net \
    --cc=joseph.reeves@gmail.com \
    --cc=linus.walleij@linaro.org \
    --cc=mst@redhat.com \
    --cc=patches@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=will.deacon@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).