Re: pcie_bwctrl fails to probe on Rpi 4 (linux-next-20241101)

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

 



Hi Stefan,

On 11/2/2024 9:53 AM, Stefan Wahren wrote:
Hi,
I tested linux-next-20241101 with the Raspberry Pi 4 (8 GB RAM,
arm64/defconfig) and during boot the driver pcie_bwctrl fails to probe.
Since this driver is very new, I assume this never worked before:

[    6.843802] brcm-pcie fd500000.pcie: host bridge /scb/pcie@7d500000
ranges:
[    6.843851] brcm-pcie fd500000.pcie:   No bus range found for
/scb/pcie@7d500000, using [bus 00-ff]
[    6.843900] brcm-pcie fd500000.pcie:      MEM
0x0600000000..0x0603ffffff -> 0x00f8000000
[    6.843940] brcm-pcie fd500000.pcie:   IB MEM
0x0000000000..0x00bfffffff -> 0x0400000000
[    6.859915] vchiq: module is from the staging directory, the quality
is unknown, you have been warned.
[    6.885670] brcm-pcie fd500000.pcie: PCI host bridge to bus 0000:00
[    6.885704] pci_bus 0000:00: root bus resource [bus 00-ff]
[    6.885725] pci_bus 0000:00: root bus resource [mem
0x600000000-0x603ffffff] (bus address [0xf8000000-0xfbffffff])
[    6.885823] pci 0000:00:00.0: [14e4:2711] type 01 class 0x060400 PCIe
Root Port
[    6.885858] pci 0000:00:00.0: PCI bridge to [bus 01]
[    6.885876] pci 0000:00:00.0:   bridge window [mem
0x600000000-0x6000fffff]
[    6.885954] pci 0000:00:00.0: PME# supported from D0 D3hot
[    6.909911] pci_bus 0000:01: supply vpcie3v3 not found, using dummy
regulator
[    6.910159] pci_bus 0000:01: supply vpcie3v3aux not found, using
dummy regulator
[    6.910251] pci_bus 0000:01: supply vpcie12v not found, using dummy
regulator
[    6.922254] mmc1: new high speed SDIO card at address 0001
[    7.013175] brcm-pcie fd500000.pcie: clkreq-mode set to default
[    7.015309] brcm-pcie fd500000.pcie: link up, 5.0 GT/s PCIe x1 (SSC)
[    7.015526] pci 0000:01:00.0: [1106:3483] type 00 class 0x0c0330 PCIe
Endpoint
[    7.015626] pci 0000:01:00.0: BAR 0 [mem 0x00000000-0x00000fff 64bit]
[    7.015954] pci 0000:01:00.0: PME# supported from D0 D3hot
[    7.062153] pci 0000:00:00.0: bridge window [mem
0x600000000-0x6000fffff]: assigned
[    7.062191] pci 0000:01:00.0: BAR 0 [mem 0x600000000-0x600000fff
64bit]: assigned
[    7.062221] pci 0000:00:00.0: PCI bridge to [bus 01]
[    7.062237] pci 0000:00:00.0:   bridge window [mem
0x600000000-0x6000fffff]
[    7.062255] pci_bus 0000:00: resource 4 [mem 0x600000000-0x603ffffff]
[    7.062269] pci_bus 0000:01: resource 1 [mem 0x600000000-0x6000fffff]
[    7.062590] pcieport 0000:00:00.0: enabling device (0000 -> 0002)
[    7.062812] pcieport 0000:00:00.0: PME: Signaling with IRQ 39
[    7.072890] pcieport 0000:00:00.0: AER: enabled with IRQ 39
[    7.091767] v3d fec00000.gpu: [drm] Using Transparent Hugepages
[    7.124274] genirq: Flags mismatch irq 39. 00002084 (PCIe bwctrl) vs.
00200084 (PCIe PME)
[    7.124391] pcie_bwctrl 0000:00:00.0:pcie010: probe with driver
pcie_bwctrl failed with error -16

Yes this is a new failure for sure. So PME requests the interrupt line with IRQF_TRIGGER_HIGH | IRQF_SHARED | IRQF_COND_ONESHOT whereas the bwctrl driver does: IRQF_TRIGGER_HIGH | IRQF_SHARED | IRQF_ONESHOT. Reading through the comment of IRQF_COND_ONESHOT, that does not seem to be an incompatible configuration, but maybe it is an ordering issue here? That is, bwctlr should claim the interrupt line first, and then PME would too, and they would be OK with the flags?
--
Florian





[Index of Archives]     [DMA Engine]     [Linux Coverity]     [Linux USB]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Greybus]

  Powered by Linux