Part Number: AM5728
Other Parts Discussed in Thread: OMAP-L138, , AM5726, BEAGLEBOARD-X15, TPD12S015
Tool/software: Linux
Sorry for the delay, I was only able to revisit the issue now.
I added some debugging prints into the
__pci_restore_msi_state
function of
drivers/pci/msi.c
that is called during wakeup:
static void __pci_restore_msi_state(struct pci_dev *dev)
{
u16 control;
struct msi_desc *entry;
printk(KERN_ERR "__pci_restore_msi_state dev bus: 0x%02x %s vendor: 0x%02x device: 0x%02x resource: 0x%08x\n", dev->bus->number, dev->bus->name, dev->vendor, dev->device, (int)(dev->bus->resource[0]));
+--- 4 lines: if (!dev->msi_enabled) {------------------------------------------------------------------------------
printk(KERN_ERR "irq_get_msi_desc, dev: %p, dev->irq: %p\n", dev, dev->irq);
entry = irq_get_msi_desc(dev->irq);
printk(KERN_ERR "int: %i\n", dev->irq);
printk(KERN_ERR "pci_intx_for_msi\n");
pci_intx_for_msi(dev, 0);
pci_msi_set_enable(dev, 0);
arch_restore_msi_irqs(dev);
printk(KERN_ERR "pci_read_config_word\n");
pci_read_config_word(dev, dev->msi_cap + PCI_MSI_FLAGS, &control);
printk(KERN_ERR "msi_mask_irq: %p\n", entry);
msi_mask_irq(entry, msi_mask(entry->msi_attrib.multi_cap),
entry->masked);
control &= ~PCI_MSI_FLAGS_QSIZE;
control |= (entry->msi_attrib.multiple << 4) | PCI_MSI_FLAGS_ENABLE;
printk(KERN_ERR "pci_write_config_word\n");
This results in following output:
[ 1641.716315] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[ 1641.721663] sd 0:0:0:0: [sda] Stopping disk
[ 1641.750497] PM: suspend of devices complete after 35.630 msecs
[ 1641.759764] PM: late suspend of devices complete after 3.366 msecs
[ 1641.766284] __pci_msi_desc_mask_irq
[ 1641.769787] desc->masked
[ 1641.772329] pci_msi_ignore_mask
[ 1641.775527] __pci_msi_desc_mask_irq
[ 1641.779027] desc->masked
[ 1641.781569] pci_msi_ignore_mask
[ 1641.787718] PM: noirq suspend of devices complete after 21.706 msecs
[ 1645.033410] __pci_restore_msi_state dev bus: 0x00 vendor: 0x104c device: 0x8888 resource: 0x00000000
[ 1645.042889] __pci_restore_msi_state dev bus: 0x00 vendor: 0x104c device: 0x8888 resource: 0x00000000
[ 1645.042892] irq_get_msi_desc
[ 1645.042895] int: 407
[ 1645.042897] pci_intx_for_msi
[ 1645.042906] pci_read_config_word
[ 1645.042909] msi_mask_irq: ee13b740 'all ok for interrupt nr 407'
[ 1645.042911] __pci_msi_desc_mask_irq
[ 1645.042913] desc->masked
[ 1645.042914] pci_msi_ignore_mask
[ 1645.042916] pci_write_config_word
[ 1645.080124] irq_get_msi_desc
[ 1645.083015] int: 406
[ 1645.085395] pci_intx_for_msi
[ 1645.088292] pci_read_config_word
[ 1645.091535] msi_mask_irq: (null) 'null pointer for irq 406
[ 1645.094954] Unable to handle kernel NULL pointer dereference at virtual address 00000028
[ 1645.103092] pgd = c0003000
[ 1645.105822] [00000028] *pgd=80000080004003, *pmd=00000000
[ 1645.111266] Internal error: Oops: 207 [#1] PREEMPT SMP ARM
In short the function
entry = irq_get_msi_desc(dev->irq);
returns a null pointer for irq 406
Following are several further information:
cat /proc/interrupts returns:
..
374: 0 0 PCI-MSI 0 Edge PCIe PME, aerdrv
407: 0 0 PCI-MSI 0 Edge PCIe PME, aerdrv
root@tqma574x-mba57xx:/sys/devices/platform/44000000.ocp/44000000.ocp:axi@0/51000000.pcie/pci0000:00/0000:00:00.0# cat irq
406
root@tqma574x-mba57xx:/sys/devices/platform/44000000.ocp/44000000.ocp:axi@0/51000000.pcie/pci0000:00/0000:00:00.0/msi_ir qs# ls
374
root@tqma574x-mba57xx:/sys/devices/platform/44000000.ocp/44000000.ocp:axi@1/51800000.pcie/pci0001:00/0001:00:00.0# cat irq
407
root@tqma574x-mba57xx:/sys/devices/platform/44000000.ocp/44000000.ocp:axi@1/51800000.pcie/pci0001:00/0001:00:00.0/msi_irqs# ls
407
It seems there is a issue with the pcie and msi irq numbers that do not correspond to each other.
Unsure how this could happen.
In our device tree we only enable the relevant device nodes with status = "okay", not touching anything irq-revelant here.
/* PCIe lane 0 PCIe x4 connector */
&pcie1_rc {
status = "okay";
};
/* PCIe lane 1 mPCIe connector */
&pcie2_rc {
status = "okay";
/* PCIe reset R532 not placed */
};
&pcie2_phy {
status = "okay";
};
axi@1 {
status = "okay";
See dts files attached to initial thread.
Has PCIe lane 2 been tested on a TI or custom board before? I havent found anything in the public repositories.
If so, how did the device tree look in this case?
