diff mbox

[Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+

Message ID 20130812230408.GA4420@roeck-us.net (mailing list archive)
State New, archived
Headers show

Commit Message

Guenter Roeck Aug. 12, 2013, 11:04 p.m. UTC
On Mon, Aug 12, 2013 at 11:12:50PM +0100, Russell King - ARM Linux wrote:
> On Mon, Aug 12, 2013 at 10:36:17PM +0100, Peter Maydell wrote:
> > On this point, yes. Equivalent bit from the PB926 TRM:
> > http://infocenter.arm.com/help/topic/com.arm.doc.dui0224i/Cacdijji.html
> > 
> > (There are differences between the PCI controllers on
> > the different boards. Differences I know of are:
> >  * size of the three memory mapped regions
> >  * whether the top bits of the PCI address come from the top
> >    or bottom of the IMAP* registers
> > I believe (based on some experimentation and an educated guess)
> > that these both changed at the same point, but some of the board
> > TRMs claim to be part one way part the other, presumably due to
> > copy and paste error. In particular PB1176's TRM has a mangled
> > description of the IMAP* registers which didn't match what the
> > h/w actually did in my testing.)
> 
> Bah, updated TRMs since my version.
> 
> Right, so if I've traced everything correctly, this should work:
> 
>         /*
>          * Slot INTA    INTB    INTC    INTD
>          *  31  PCI1    PCI2    PCI3    PCI0
>          *  30  PCI0    PCI1    PCI2    PCI3
>          *  29  PCI3    PCI0    PCI1    PCI2
>          */
>         return IRQ_SIC_PCI0 + ((slot + 2 + pin - 1) & 3);
> 
I tried the above with qemu 1.5.2. Success!

Hacked diff is below. Can I write that up as clean patch and submit it,
or do we need a test on real hardware ?

Thanks,
Guenter

---

Comments

Russell King - ARM Linux Aug. 14, 2013, 10:33 a.m. UTC | #1
On Mon, Aug 12, 2013 at 04:04:08PM -0700, Guenter Roeck wrote:
> Hacked diff is below. Can I write that up as clean patch and submit it,
> or do we need a test on real hardware ?

Well, if we want to ensure that it is really correct, the sensible thing
to do is to try it on real hardware, otherwise we're risking yet another
change to this.

Earlier in this thread, some people said that they have the hardware, so
it shouldn't be that difficult to get it tested on real stuff.
Peter Maydell Aug. 14, 2013, 12:44 p.m. UTC | #2
On 14 August 2013 11:33, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Mon, Aug 12, 2013 at 04:04:08PM -0700, Guenter Roeck wrote:
>> Hacked diff is below. Can I write that up as clean patch and submit it,
>> or do we need a test on real hardware ?
>
> Well, if we want to ensure that it is really correct, the sensible thing
> to do is to try it on real hardware, otherwise we're risking yet another
> change to this.
>
> Earlier in this thread, some people said that they have the hardware, so
> it shouldn't be that difficult to get it tested on real stuff.

Yes, I definitely think we should test on the hardware before we
land yet another change to this PCI code that hasn't really been
thoroughly tested on anything. I have the board/backplane on my
desk but it'll be later in the week before I can do the testing
(currently still messing with uboot config to get it to actually
boot a kernel).

thanks
-- PMM
Russell King - ARM Linux Aug. 14, 2013, 12:49 p.m. UTC | #3
On Wed, Aug 14, 2013 at 01:44:44PM +0100, Peter Maydell wrote:
> On 14 August 2013 11:33, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > On Mon, Aug 12, 2013 at 04:04:08PM -0700, Guenter Roeck wrote:
> >> Hacked diff is below. Can I write that up as clean patch and submit it,
> >> or do we need a test on real hardware ?
> >
> > Well, if we want to ensure that it is really correct, the sensible thing
> > to do is to try it on real hardware, otherwise we're risking yet another
> > change to this.
> >
> > Earlier in this thread, some people said that they have the hardware, so
> > it shouldn't be that difficult to get it tested on real stuff.
> 
> Yes, I definitely think we should test on the hardware before we
> land yet another change to this PCI code that hasn't really been
> thoroughly tested on anything. I have the board/backplane on my
> desk but it'll be later in the week before I can do the testing
> (currently still messing with uboot config to get it to actually
> boot a kernel).

Realview or Versatile?  I still need to sort out Realview.

The alternative is - I have both the Realview EB and Versatile PB926
here, but no backplane (it wasn't deemed to be necessary for me to
have such a thing.)  If someone wants to donate a backplane...
Peter Maydell Aug. 14, 2013, 12:56 p.m. UTC | #4
On 14 August 2013 13:49, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Wed, Aug 14, 2013 at 01:44:44PM +0100, Peter Maydell wrote:
>> Yes, I definitely think we should test on the hardware before we
>> land yet another change to this PCI code that hasn't really been
>> thoroughly tested on anything. I have the board/backplane on my
>> desk but it'll be later in the week before I can do the testing
>> (currently still messing with uboot config to get it to actually
>> boot a kernel).
>
> Realview or Versatile?  I still need to sort out Realview.

PB926, so versatile. Let's get that one straightened out first,
since at the moment the kernel has no realview PCI support at
all. I should be able to get a PB1176 to go in the backplane
for testing that, though.

-- PMM
Guenter Roeck Aug. 14, 2013, 2:41 p.m. UTC | #5
On 08/14/2013 05:44 AM, Peter Maydell wrote:
> On 14 August 2013 11:33, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
>> On Mon, Aug 12, 2013 at 04:04:08PM -0700, Guenter Roeck wrote:
>>> Hacked diff is below. Can I write that up as clean patch and submit it,
>>> or do we need a test on real hardware ?
>>
>> Well, if we want to ensure that it is really correct, the sensible thing
>> to do is to try it on real hardware, otherwise we're risking yet another
>> change to this.
>>
>> Earlier in this thread, some people said that they have the hardware, so
>> it shouldn't be that difficult to get it tested on real stuff.
>
> Yes, I definitely think we should test on the hardware before we
> land yet another change to this PCI code that hasn't really been
> thoroughly tested on anything. I have the board/backplane on my

Agreed.

> desk but it'll be later in the week before I can do the testing
> (currently still messing with uboot config to get it to actually
> boot a kernel).
>

That would be great. Thanks a lot for your help!

Guenter
diff mbox

Patch

diff --git a/arch/arm/mach-versatile/pci.c b/arch/arm/mach-versatile/pci.c
index e92e5e0..53b4208 100644
--- a/arch/arm/mach-versatile/pci.c
+++ b/arch/arm/mach-versatile/pci.c
@@ -333,7 +333,11 @@  static int __init versatile_map_irq(const struct pci_dev *dev, u8 slot, u8 pin)
 	 *  26     1     IRQ_SIC_PCI2
 	 *  27     1     IRQ_SIC_PCI3
 	 */
+#if 0
 	irq = IRQ_SIC_PCI0 + ((slot - 24 + pin - 1) & 3);
+#else
+	irq = IRQ_SIC_PCI0 + ((slot + 2 + pin - 1) & 3);
+#endif
 
 	return irq;
 }