On 3/14/2016 9:48 PM, Bjorn Helgaas wrote:
Yes. I was talking about PCIe on ARM64.
> If you go to Fry's and buy a conventional PCI card, it is going to
> pull INTA# low to assert an interrupt. It doesn't matter whether you
> put it in an x86 system or an arm64 system.
>
I don't see INTA# of the PCIe card at the system level. The PCIe wire
interrupt gets converted to the system level interrupt by the PCIe controller.
>> > I pasted the code here again. It looks like you want to validate that
>> > PCI interrupts are always level low.
> I don't really care whether PCI interrupts are always level low. What
> matters is that the PCI interrupt line matches the configuration of
> the interrupt controller input.
>
Agreed. But the interrupt controller configuration is system specific. How would
you check interrupt line against what the interrupt controller requires
on each architecture as this is common code?
> If the PCI interrupt can be a different type, e.g., level high, and
> there's a way to discover that, we can check that against the
> interrupt controller configuration.
>
> This is all in the context of conventional PCI, and we're probably
> talking about arm64 PCIe systems, not conventional PCI.
INTx interrupts are TLP messages on PCIe as you already know. There is no INTA
interrupt wire.
"6.1.2. PCI Compatible INTx Emulation" section of the PCIe spec describes
INTx emulation on PCIe.
I pasted that section here for your reference.
"Two types of Messages are defined, Assert_INTx and Deassert_INTx, for emulation of PCI INTx
signaling, where x is A, B, C, and D for respective PCI interrupt signals. These Messages are used to
provide “virtual wires” for signaling interrupts across a Link. Switches collect these virtual wires and
present a combined set at the Switch’s Upstream Port. Ultimately, the virtual wires are routed to the
Root Complex which maps the virtual wires to system interrupt resources. Devices must use
10 assert/de-assert Messages in pairs to emulate PCI interrupt level-triggered signaling. Actual
mapping of PCI Express INTx emulation to system interrupts is implementation specific as is
mapping of physical interrupt signals in conventional PCI."
> I'm not sure what an Interrupt Link device means in PCIe. I suppose it would have
> to connect an INTx virtual wire to a system interrupt? The PCIe spec
> says this sort of mapping is system implementation specific (r3.0, sec
> 2.2.8.1).
>
The INTx messages are converted to the system interrupt by the PCIe controller.
The interrupt type between the PCIe controller and the ARM GIC interrupt
controller is dictated by the ARM GIC Interrupt Controller Specification for
ARM64.
Here is what ACPI table looks like for reference
Name(_PRT, Package(){
Package(){0x0FFFF, 0, \_SB.LN0A, 0}, // Slot 0, INTA
Package(){0x0FFFF, 1, \_SB.LN0B, 0}, // Slot 0, INTB
Package(){0x0FFFF, 2, \_SB.LN0C, 0}, // Slot 0, INTC
Package(){0x0FFFF, 3, \_SB.LN0D, 0} // Slot 0, INTD
})
Device(LN0A){
Name(_HID, EISAID("PNP0C0F")) // PCI interrupt link
Name(_UID, 1)
Name(_PRS, ResourceTemplate(){
Interrupt(ResourceProducer, Level, ActiveHigh, Exclusive, , ,) {0x123}
})
Method(_DIS) {}
Method(_CRS) { Return (_PRS) }
Method(_SRS, 1) {}
}
--
Sinan Kaya
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
