On 7 April 2017 at 19:35, Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> wrote:
> On 7 April 2017 at 19:06, Lorenzo Pieralisi <lorenzo.pieralisi@xxxxxxx> wrote:
>> On Fri, Apr 07, 2017 at 06:12:05PM +0100, Ard Biesheuvel wrote:
>>> On 7 April 2017 at 18:06, Bjorn Helgaas <helgaas@xxxxxxxxxx> wrote:
[...]
>
> OK, I have changed my DSDT as follows:
>
>
> Device (PCI0)
> {
> Name (_ADR, 0x00)
> Name (_HID, "PNP0A08" /* PCI Express Bus */) // _HID: Hardware ID
> Name (_CID, "PNP0A03" /* PCI Bus */) // _CID: Compatible ID
> Name (_SEG, 0x00) // _SEG: PCI Segment
> Name (_BBN, 0x00) // _BBN: BIOS Bus Number
> Name (_CCA, 0x01) // _CCA: Cache Coherency Attribute
>
> Device (EXP1)
> {
> Name (_ADR, 0x20001) // _ADR: Address
> Name (_PRT, Package () // _PRT: PCI Routing Table
> {
> // slot 1: dev 2 fn 1
> Package () { 0xFFFF, 0x0, 0x0, 0x140 },
> Package () { 0xFFFF, 0x1, 0x0, 0x141 },
> Package () { 0xFFFF, 0x2, 0x0, 0x142 },
> Package () { 0xFFFF, 0x3, 0x0, 0x143 }
> }) // _PRT
> }
> Device (EXP2)
> {
> Name (_ADR, 0x20002) // _ADR: Address
> Name (_PRT, Package () // _PRT: PCI Routing Table
> {
> // slot 2: dev 2 fn 2
> Package () { 0xFFFF, 0x0, 0x0, 0x144 },
> Package () { 0xFFFF, 0x1, 0x0, 0x145 },
> Package () { 0xFFFF, 0x2, 0x0, 0x146 },
> Package () { 0xFFFF, 0x3, 0x0, 0x147 }
> }) // _PRT
> }
> Device (EXP3)
> {
> Name (_ADR, 0x20003) // _ADR: Address
> Name (_PRT, Package () // _PRT: PCI Routing Table
> {
> // slot 3: dev 2 fn 3
> Package () { 0xFFFF, 0x0, 0x0, 0x148 },
> Package () { 0xFFFF, 0x1, 0x0, 0x149 },
> Package () { 0xFFFF, 0x2, 0x0, 0x14a },
> Package () { 0xFFFF, 0x3, 0x0, 0x14b }
> }) // _PRT
> }
>
> but it does not get picked up, and I am back to
>
> [ 3.357555] pcieport 0000:00:02.2: can't derive routing for PCI INT A
> [ 3.370477] pcieport 0000:00:02.2: PCI INT A: no GSI
> [ 3.380549] pcieport 0000:00:02.3: can't derive routing for PCI INT A
> [ 3.393476] pcieport 0000:00:02.3: PCI INT A: no GSI
>
OK, this does appear to work in fact, for the devices behind the
bridges. These messages are from the pcieport driver trying to request
an IRQ for the bridge device itself, which no longer works now that
the _PRT methods have been moved out.
So that mostly solves the problem. I'll try adding back a _PRT in the
PCI root device itself, but i'm not sure if I can make any inferences
about the IRQ wiring from the data i have.
Thanks all,
--
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
