On Sat, Apr 08, 2017 at 12:22:15PM +0100, Ard Biesheuvel wrote:
> 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.
Yes and IIUC with the $SUBJECT patch applied, the endpoints would match
the _PRT entry under PNP0A08 through their bridge (PCIe port device = 2
fn = X) device entry, not their own (device = 0) (ie first look-up in
acpi_pci_irq_lookup() through acpi_pci_irq_find_prt_entry() should fail
for the endpoints, then the same look-up is carried out with the bridge
device instead and that succeeds, the _PRT entry routes IRQs for the
PCIeport AND their downstream endpoint with $SUBJECT patch applied).
If you add the _PRT under the PCIe port itself (table above) the PCIe
port can't find an ACPI parent device to route its own IRQx, that's my
reading of what's going on, I will debug it next week.
Lorenzo
--
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
