From: Arnd Bergmann <arnd@arndb.de>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: patches@linaro.org, "Michael S. Tsirkin" <mst@redhat.com>,
"Will Deacon" <will.deacon@arm.com>,
qemu-devel@nongnu.org, "Paul Brook" <paul@codesourcery.com>,
"Andreas Färber" <afaerber@suse.de>,
"Aurelien Jarno" <aurelien@aurel32.net>
Subject: Re: [Qemu-devel] [PATCH 00/10] Fix versatile_pci (and break versatilepb linux guests!)
Date: Sun, 24 Mar 2013 21:16:28 +0000 [thread overview]
Message-ID: <201303242116.28340.arnd@arndb.de> (raw)
In-Reply-To: <CAFEAcA8CowYPR2yRj+f37a78BUview0RvM4otuZ4M8fyEmY7qQ@mail.gmail.com>
On Sunday 24 March 2013, Peter Maydell wrote:
> Yeah, ideally being able to detect the buggy kernel would be good;
> I can't see anything at the controller level that would do though,
> and I don't really know enough about PCI to know about generic
> PCI stuff that would work. (Why would the OS need to tell the
> device anything about its IRQ if it's hardwired?)
I think it actually does on versatile and other platforms on which
the kernel probes the PCI bus itself, rather than relying on firmware
to have resources assigned in advance.
IIRC, the PCI_INTERRUPT_LINE pci config space byte (0x3c) is purely
informational and used as a way to communicate the interrupt number
from the bus scan code (assumed to be a PC BIOS in the PCI spec,
but drivers/pci/setup-irq.c in case of versatile+linux) to a device
driver.
So the kernel should actually write the proper interrupt number in
there. In future kernels, this may not necessarily be the hardware
number, but today it is. Can you try out what the kernel writes into
that register in qemu, with and without my patches?
I would expect the numbers to be (64+27) to (64+30), since we
linearize the interrupt numbers so that VIC gets 32 through
63 and SIC gets 64 through 95.
Arnd
next prev parent reply other threads:[~2013-03-24 21:17 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-24 11:32 [Qemu-devel] [PATCH 00/10] Fix versatile_pci (and break versatilepb linux guests!) Peter Maydell
2013-03-24 11:32 ` [Qemu-devel] [PATCH 01/10] versatile_pci: Fix hardcoded tabs Peter Maydell
2013-03-24 11:32 ` [Qemu-devel] [PATCH 02/10] versatile_pci: Expose PCI I/O region on Versatile PB Peter Maydell
2013-03-25 1:01 ` Peter Crosthwaite
2013-03-25 9:47 ` Peter Maydell
2013-03-25 10:15 ` Peter Maydell
2013-03-24 11:32 ` [Qemu-devel] [PATCH 03/10] versatile_pci: Update to realize and instance init functions Peter Maydell
2013-03-24 11:32 ` [Qemu-devel] [PATCH 04/10] versatile_pci: Change to subclassing TYPE_PCI_HOST_BRIDGE Peter Maydell
2013-03-24 11:32 ` [Qemu-devel] [PATCH 05/10] versatile_pci: Use separate PCI I/O space rather than system I/O space Peter Maydell
2013-03-24 11:32 ` [Qemu-devel] [PATCH 06/10] versatile_pci: Put the host bridge PCI device at slot 29 Peter Maydell
2013-03-24 11:32 ` [Qemu-devel] [PATCH 07/10] versatile_pci: Implement the correct PCI IRQ mapping Peter Maydell
2013-03-25 12:12 ` Michael S. Tsirkin
2013-03-25 12:17 ` Peter Maydell
2013-03-25 12:28 ` Michael S. Tsirkin
2013-03-24 11:32 ` [Qemu-devel] [PATCH 08/10] versatile_pci: Implement the PCI controller's control registers Peter Maydell
2013-03-24 11:32 ` [Qemu-devel] [PATCH 09/10] arm/realview: Fix mapping of PCI regions Peter Maydell
2013-03-24 11:32 ` [Qemu-devel] [PATCH 10/10] versatile_pci: Expose PCI memory space to system Peter Maydell
2013-03-24 15:58 ` [Qemu-devel] [PATCH 00/10] Fix versatile_pci (and break versatilepb linux guests!) Aurelien Jarno
2013-03-24 16:49 ` Peter Maydell
2013-03-24 20:12 ` Aurelien Jarno
2013-03-24 19:17 ` Michael S. Tsirkin
2013-03-24 20:53 ` Peter Maydell
2013-03-24 21:16 ` Arnd Bergmann [this message]
2013-03-24 21:29 ` Peter Maydell
2013-03-24 22:45 ` Arnd Bergmann
2013-03-24 21:37 ` Michael S. Tsirkin
2013-03-24 22:59 ` Arnd Bergmann
2013-03-25 11:56 ` Peter Maydell
2013-03-24 21:34 ` Michael S. Tsirkin
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=201303242116.28340.arnd@arndb.de \
--to=arnd@arndb.de \
--cc=afaerber@suse.de \
--cc=aurelien@aurel32.net \
--cc=mst@redhat.com \
--cc=patches@linaro.org \
--cc=paul@codesourcery.com \
--cc=peter.maydell@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.