qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v2 3/3] 40p: add fixed IRQ routing for LSI SCSI


From: Mark Cave-Ayland
Subject: Re: [Qemu-devel] [PATCH v2 3/3] 40p: add fixed IRQ routing for LSI SCSI device
Date: Mon, 10 Sep 2018 21:32:31 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1

On 10/09/18 04:48, David Gibson wrote:

> On Sat, Sep 08, 2018 at 10:08:20AM +0100, Mark Cave-Ayland wrote:
>> Whilst the PReP specification describes how all PCI IRQs are routed via IRQ
>> 15 on the interrupt controller, the real 40p machine has routing quirk in
>> that the LSI SCSI device is routed to IRQ 13.
>>
>> This is implemented using a little hack: the existing IRQ routing code uses
>> (irq_num + (pci_dev->devfn >> 3)) & 1 to give the PCI interrupt pin, where
>> the "& 1" ensures that the only pins A and B (0 and 1) will ever be used.
>>
>> Rather than fix the mask to "& 3" we leave the existing routing above as-is
>> and then force the LSI SCSI device to use pin C (2). This enables us to
>> route pin 2 permanantly to IRQ 13 since the LSI SCSI device will be its
>> only user.
>>
>> Signed-off-by: Mark Cave-Ayland <address@hidden>
> 
> I don't think this is really the right approach.
> 
> As noted in an earlier mail, it's really common for on-board devices
> on pre-express PCI boards to have their LSIs wired specially, rather
> than via the PCI irq pins which are used for "slotted" devices.
> 
> I think we should explicitly model it like that: wiring the SCSI
> device's irq directly to system IRQ 13, rather than wiring it via a
> PCI LSI pin.
> 
> Wiring the SCSI to an otherwise unused pin, then routing that
> specially to the system irq is confusing.  It also might be incorrect
> if we tried to add a "slotted" device that actually used PINC (rare,
> I'll grant you).

Okay. I was hoping to get away with not altering the LSI SCSI device
itself, but after some experimentation I managed to come up with a
solution that is not too invasive and certainly more readable than this
attempt. Let me tidy up and post a v3.


ATB,

Mark.



reply via email to

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