my tests here are basing on r64 v1. Tested my qualcom card on both slots and it’s only recognized on cn25 and got wifi interface there but have not run hostapd on it
How do you fix that problem? I got the same problem. openwrt + BPI-R64 + Compex WLE900VX QCA9880. kmod-ath10k driver and firmware, the system will crash.
[ 28.373475] ath10k_pci 0000:01:00.0: no of_node; not parsing pinctrl DT
[ 28.380465] ath10k_pci 0000:01:00.0: assign IRQ: got 136
[ 28.386680] pci 0000:00:00.0: enabling device (0000 -> 0002)
[ 28.392554] pci 0000:00:00.0: enabling bus mastering
[ 28.397685] ath10k_pci 0000:01:00.0: enabling device (0000 -> 0002)
[ 28.404209] ath10k_pci 0000:01:00.0: enabling bus mastering
[ 28.410396] Unable to handle kernel paging request at virtual address ffffff800892f0c0
[ 28.418560] Mem abort info:
[ 28.421476] ESR = 0x96000047
[ 28.424624] Exception class = DABT (current EL), IL = 32 bits
[ 28.430736] SET = 0, FnV = 0
[ 28.433883] EA = 0, S1PTW = 0
[ 28.437119] Data abort info:
[ 28.440101] ISV = 0, ISS = 0x00000047
[ 28.444052] CM = 0, WnR = 1
[ 28.447110] swapper pgtable: 4k pages, 39-bit VAs, pgdp = 0000000092d32cfe
[ 28.454207] [ffffff800892f0c0] pgd=000000007fffe003, pud=000000007fffe003, pmd=000000007fffb003, pte=0000000000000000
[ 28.465166] Internal error: Oops: 96000047 [#1] SMP
[ 28.470190] Modules linked in: ath10k_pci(+) ath10k_core ath
[ 28.776245] Process kmodloader (pid: 1064, stack limit = 0x00000000e97ecadb)
[ 28.783513] CPU: 1 PID: 1064 Comm: kmodloader Not tainted 4.19.72 #0
[ 28.790059] Hardware name: Bananapi BPI-R64 (DT)
[ 28.794815] pstate: 00000005 (nzcv daif -PAN -UAO)
[ 28.799759] pc : queued_spin_lock_slowpath+0x180/0x288
[ 28.805057] lr : __mutex_lock.isra.7+0x1b8/0x520
[ 28.809812] sp : ffffff8009d736b0
[ 28.813224] x29: ffffff8009d736b0 x28: ffffff8009d738d0
[ 28.818698] x27: 0000000000080000 x26: ffffff8009d738d0
[ 28.824172] x25: 0000000000000089 x24: ffffff800895c8c8
[ 28.829646] x23: ffffffc03e442908 x22: ffffffc03e442910
[ 28.835121] x21: ffffff8008946000 x20: 0000000000000002
[ 28.840596] x19: ffffffc03e442908 x18: 0000000000000000
[ 28.846070] x17: 0000000000000000 x16: ffffffbf00d7a600
[ 28.851544] x15: 0000000000000000 x14: 0000000000006af0
[ 28.857018] x13: 00000000000001a4 x12: 0000000000000038
[ 28.862492] x11: ffffffc03ffc77e8 x10: 00000000000007b0
[ 28.867966] x9 : 0000000000000000 x8 : ffffffc03ffcc0c0
[ 28.873439] x7 : 0000000000080000 x6 : 0000000000000000
[ 28.878913] x5 : 0000000000000000 x4 : ffffff800892f0c0
[ 28.884387] x3 : ffffffc03ffcc0c8 x2 : ffffff800892f000
[ 28.889860] x1 : ffffffc03ffcc0c0 x0 : ffffffc03e442910
[ 28.895335] Call trace:
[ 28.897857] queued_spin_lock_slowpath+0x180/0x288
[ 28.902793] __mutex_lock_slowpath+0x10/0x18
[ 28.907194] mutex_lock+0x30/0x38
[ 28.910613] mtk_pcie_irq_domain_alloc+0x44/0xd8
[ 28.915373] irq_domain_alloc_irqs_parent+0x1c/0x30
[ 28.920401] msi_domain_alloc+0x84/0x148
[ 28.924441] __irq_domain_alloc_irqs+0x13c/0x270
[ 28.929198] msi_domain_alloc_irqs+0x80/0x278
[ 28.933686] pci_msi_setup_msi_irqs+0x28/0x40
[ 28.938174] __pci_enable_msi_range+0x1f8/0x410
[ 28.942841] pci_enable_msi+0x18/0x28
[ 28.946618] ath10k_pci_setup_resource+0x60c/0x940 [ath10k_pci]
[ 28.952721] pci_device_probe+0x9c/0x138
[ 28.956762] really_probe+0x150/0x2b0
[ 28.960533] driver_probe_device+0xbc/0x108
[ 28.964842] __driver_attach+0xa8/0xe0
[ 28.968707] bus_for_each_dev+0x4c/0x98
[ 28.972657] driver_attach+0x20/0x28
[ 28.976339] bus_add_driver+0xe8/0x208
[ 28.980201] driver_register+0xb0/0xf8
[ 28.984065] __pci_register_driver+0x40/0x48
[ 28.988471] init_module+0x2c/0x1000 [ath10k_pci]
[ 28.993323] do_one_initcall+0x78/0x170
[ 28.997277] do_init_module+0x58/0x1a0
[ 29.001138] load_module+0x19bc/0x1ff0
[ 29.004999] __do_sys_init_module+0x148/0x1a8
[ 29.009486] __arm64_sys_init_module+0x14/0x20
[ 29.014065] el0_svc_common+0x8c/0xf0
[ 29.017836] el0_svc_handler+0x6c/0x78
[ 29.021696] el0_svc+0x8/0xc
[ 29.024661] Code: 8b030084 91002103 f865d929 d2800005 (f8296888)
If use the kmod-ath10-ct driver and firmware, the system will not crash, but the driver can’t work correctly.
[ 28.322762] ath10k_pci 0000:01:00.0: no of_node; not parsing pinctrl DT
[ 28.329733] ath10k_pci 0000:01:00.0: assign IRQ: got 136
[ 28.335226] ath10k 4.19 driver, optimized for CT firmware, probing pci device: 0x3c.
[ 28.343959] pci 0000:00:00.0: enabling device (0000 -> 0002)
[ 28.349831] pci 0000:00:00.0: enabling bus mastering
[ 28.354966] ath10k_pci 0000:01:00.0: enabling device (0000 -> 0002)
[ 28.361494] ath10k_pci 0000:01:00.0: enabling bus mastering
[ 28.367778] ath10k_pci 0000:01:00.0: pci irq msi oper_irq_mode 2 irq_mode 0 reset_mode 0
[ 31.831565] firmware ath10k!fwcfg-pci-0000:01:00.0.txt: firmware_loading_store: map pages failed
[ 31.846045] firmware ath10k!pre-cal-pci-0000:01:00.0.bin: firmware_loading_store: map pages failed
[ 31.860734] firmware ath10k!cal-pci-0000:01:00.0.bin: firmware_loading_store: map pages failed
[ 31.875653] firmware ath10k!QCA988X!hw2.0!ct-firmware-5.bin: firmware_loading_store: map pages failed
[ 31.890581] firmware ath10k!QCA988X!hw2.0!ct-firmware-2.bin: firmware_loading_store: map pages failed
[ 31.905266] firmware ath10k!QCA988X!hw2.0!firmware-6.bin: firmware_loading_store: map pages failed
[ 31.919882] firmware ath10k!QCA988X!hw2.0!firmware-5.bin: firmware_loading_store: map pages failed
[ 31.934292] firmware ath10k!QCA988X!hw2.0!firmware-4.bin: firmware_loading_store: map pages failed
[ 31.948735] firmware ath10k!QCA988X!hw2.0!firmware-3.bin: firmware_loading_store: map pages failed
[ 32.003210] ath10k_pci 0000:01:00.0: qca988x hw2.0 target 0x4100016c chip_id 0x043202ff sub 0000:0000
[ 32.012751] ath10k_pci 0000:01:00.0: kconfig debug 0 debugfs 1 tracing 0 dfs 1 testmode 0
[ 32.022646] ath10k_pci 0000:01:00.0: firmware ver 10.1-ct-8x-__fW-022-fa250764 api 2 features wmi-10.x,has-wmi-mgmt-tx,mfp,txstatus-noack,wmi-10.x-CT,ratemask-CT,txrate-CT,get-temp-CT,tx-rc-CT,cust-stats-CT,retry-gt2-CT,txrate2-CT,beacon-cb-CT,wmi-block-ack-CT crc32 26a1777b
[ 32.080996] firmware ath10k!QCA988X!hw2.0!board-2.bin: firmware_loading_store: map pages failed
[ 32.090420] ath10k_pci 0000:01:00.0: board_file api 1 bmi_id N/A crc32 bebc7c08
[ 34.088464] ath10k_pci 0000:01:00.0: failed to receive control response completion, polling..
[ 35.128464] ath10k_pci 0000:01:00.0: Service connect timeout
[ 35.134298] ath10k_pci 0000:01:00.0: failed to connect htt (-110)
[ 35.250231] ath10k_pci 0000:01:00.0: could not init core (-110)
[ 35.256358] ath10k_pci 0000:01:00.0: could not probe fw (-110)Have you added the pci interrupt patch to your kernel and pci controller splitting?
This looks like my mutex lock issue which was gone in my tests after adding these 2 Patches and reboot
I’m not sure whether openwrt include the pci interrupt patch and pci controller splitting. Could you please give me the patch info to me? My linux kernel is 4.19.72.
Your patch also working with 4.19 kernel. Thank you for your patch, there is no spin lock problem now.
But I face another problem, the R64 board sometimes can’t detect WLE900VX, lspci show nothing.
This is the boot log when R64 can detect WLE900VX.
[ 3.076125] mmc0: new HS200 MMC card at address 0001
[ 3.081364] mmcblk mmc0:0001: no of_node; not parsing pinctrl DT
[ 3.088583] mmcblk0: mmc0:0001 008G30 7.28 GiB
[ 3.093370] mtk-pcie 1a143000.pcie: PCI host bridge to bus 0000:00
[ 3.094159] mmcblk0boot0: mmc0:0001 008G30 partition 1 4.00 MiB
[ 3.099755] pci_bus 0000:00: root bus resource [??? 0x00000000 flags 0x0]
[ 3.106711] mmcblk0boot1: mmc0:0001 008G30 partition 2 4.00 MiB
[ 3.112850] pci_bus 0000:00: root bus resource [mem 0x20000000-0x27ffffff]
[ 3.119052] mmcblk0rpmb: mmc0:0001 008G30 partition 3 4.00 MiB, chardev (250:0)
[ 3.126036] pci_bus 0000:00: root bus resource [bus 00-ff]
[ 3.139249] pci_bus 0000:00: scanning bus
[ 3.143422] pci 0000:00:00.0: [14c3:3258] type 01 class 0x060400
[ 3.149663] pci 0000:00:00.0: reg 0x10: [mem 0x00000000-0xffffffff 64bit pref]
[ 3.158525] pci_bus 0000:00: fixups for bus
[ 3.162848] pci 0000:00:00.0: scanning [bus 00-00] behind bridge, pass 0
[ 3.169763] pci 0000:00:00.0: bridge configuration invalid ([bus 00-00]), reconfiguring
[ 3.178026] pci 0000:00:00.0: scanning [bus 00-00] behind bridge, pass 1
[ 3.185025] pci_bus 0000:01: scanning bus
[ 3.189290] pci 0000:01:00.0: [168c:003c] type 00 class 0x028000
[ 3.195733] pci 0000:01:00.0: reg 0x10: [mem 0x00000000-0x001fffff 64bit]
[ 3.203036] pci 0000:01:00.0: reg 0x30: [mem 0x00000000-0x0000ffff pref]
[ 3.210521] pci 0000:01:00.0: supports D1 D2
[ 3.216281] pci_bus 0000:01: fixups for bus
[ 3.220600] pci_bus 0000:01: bus scan returning with max=01
[ 3.226345] pci_bus 0000:01: busn_res: [bus 01-ff] end is updated to 01
[ 3.233173] pci_bus 0000:00: bus scan returning with max=01
[ 3.238951] pci 0000:00:00.0: BAR 0: no space for [mem size 0x100000000 64bit pref]
[ 3.246845] pci 0000:00:00.0: BAR 0: failed to assign [mem size 0x100000000 64bit pref]
[ 3.255103] pci 0000:00:00.0: BAR 8: assigned [mem 0x20000000-0x202fffff]
[ 3.262110] pci 0000:01:00.0: BAR 0: assigned [mem 0x20000000-0x201fffff 64bit]
[ 3.269735] pci 0000:01:00.0: BAR 6: assigned [mem 0x20200000-0x2020ffff pref]
[ 3.277181] pci 0000:00:00.0: PCI bridge to [bus 01]
[ 3.282308] pci 0000:00:00.0: bridge window [mem 0x20000000-0x202fffff]
[ 3.289457] pinctrl core: add 3 pinctrl maps
[ 3.293881] mtk-pinctrl 10211000.pinctrl: found group selector 45 for pcie1_pad_perst
[ 3.301967] mtk-pinctrl 10211000.pinctrl: found group selector 42 for pcie1_0_waken
[ 3.309871] mtk-pinctrl 10211000.pinctrl: found group selector 43 for pcie1_0_clkreq
[ 3.317857] mtk-pinctrl 10211000.pinctrl: request pin 84 (PERST1_N) for 1a145000.pcie
[ 3.325937] mtk-pinctrl 10211000.pinctrl: enable function pcie group pcie1_pad_perst
[ 3.333929] mtk-pinctrl 10211000.pinctrl: request pin 14 (I2C_SDA) for 1a145000.pcie
[ 3.341918] mtk-pinctrl 10211000.pinctrl: enable function pcie group pcie1_0_waken
[ 3.349731] mtk-pinctrl 10211000.pinctrl: request pin 15 (I2C_SCL) for 1a145000.pcie
[ 3.357714] mtk-pinctrl 10211000.pinctrl: enable function pcie group pcie1_0_clkreq
[ 3.367883] Alternate GPT is invalid, using primary GPT.
[ 3.373385] mmcblk0: p1 p2 p3 p4 p5
[ 3.465795] mtk-pcie 1a145000.pcie: Port1 link down
[ 3.470958] mtk-pcie 1a145000.pcie: PCI host bridge to bus 0001:00
[ 3.477333] pci_bus 0001:00: root bus resource [??? 0x00000000 flags 0x0]
[ 3.484339] pci_bus 0001:00: root bus resource [mem 0x28000000-0x2fffffff]
[ 3.491434] pci_bus 0001:00: root bus resource [bus 00-ff]
[ 3.497086] pci_bus 0001:00: scanning bus
[ 3.502412] pci_bus 0001:00: fixups for bus
[ 3.506722] pci_bus 0001:00: bus scan returning with max=00
This is the boot log when R64 can’t detect WLE900VX.
[ 3.077301] mmc0: new HS200 MMC card at address 0001
[ 3.082541] mmcblk mmc0:0001: no of_node; not parsing pinctrl DT
[ 3.089755] mmcblk0: mmc0:0001 008G30 7.28 GiB
[ 3.095297] mmcblk0boot0: mmc0:0001 008G30 partition 1 4.00 MiB
[ 3.102282] mmcblk0boot1: mmc0:0001 008G30 partition 2 4.00 MiB
[ 3.108495] mmcblk0rpmb: mmc0:0001 008G30 partition 3 4.00 MiB, chardev (250:0)
[ 3.118542] Alternate GPT is invalid, using primary GPT.
[ 3.124047] mmcblk0: p1 p2 p3 p4 p5
[ 3.168217] mtk-pcie 1a143000.pcie: Port0 link down
[ 3.173439] mtk-pcie 1a143000.pcie: PCI host bridge to bus 0000:00
[ 3.179825] pci_bus 0000:00: root bus resource [??? 0x00000000 flags 0x0]
[ 3.186823] pci_bus 0000:00: root bus resource [mem 0x20000000-0x27ffffff]
[ 3.193917] pci_bus 0000:00: root bus resource [bus 00-ff]
[ 3.199577] pci_bus 0000:00: scanning bus
[ 3.204891] pci_bus 0000:00: fixups for bus
[ 3.209212] pci_bus 0000:00: bus scan returning with max=00
[ 3.215052] pinctrl core: add 3 pinctrl maps
[ 3.219484] mtk-pinctrl 10211000.pinctrl: found group selector 45 for pcie1_pad_perst
[ 3.227561] mtk-pinctrl 10211000.pinctrl: found group selector 42 for pcie1_0_waken
[ 3.235465] mtk-pinctrl 10211000.pinctrl: found group selector 43 for pcie1_0_clkreq
[ 3.243458] mtk-pinctrl 10211000.pinctrl: request pin 84 (PERST1_N) for 1a145000.pcie
[ 3.251538] mtk-pinctrl 10211000.pinctrl: enable function pcie group pcie1_pad_perst
[ 3.259530] mtk-pinctrl 10211000.pinctrl: request pin 14 (I2C_SDA) for 1a145000.pcie
[ 3.267511] mtk-pinctrl 10211000.pinctrl: enable function pcie group pcie1_0_waken
[ 3.275321] mtk-pinctrl 10211000.pinctrl: request pin 15 (I2C_SCL) for 1a145000.pcie
[ 3.283309] mtk-pinctrl 10211000.pinctrl: enable function pcie group pcie1_0_clkreq
[ 3.391433] mtk-pcie 1a145000.pcie: Port1 link down
[ 3.396556] mtk-pcie 1a145000.pcie: PCI host bridge to bus 0001:00
[ 3.402938] pci_bus 0001:00: root bus resource [??? 0x00000000 flags 0x0]
[ 3.409941] pci_bus 0001:00: root bus resource [mem 0x28000000-0x2fffffff]
[ 3.417029] pci_bus 0001:00: root bus resource [bus 00-ff]
[ 3.422686] pci_bus 0001:00: scanning bus
[ 3.427940] pci_bus 0001:00: fixups for bus
[ 3.432255] pci_bus 0001:00: bus scan returning with max=00You have applied both patches (splitting +interrupt)? Card still in slot near power jack (cn25)? Havn’t tested on 4.19. As 5.4 is lts i focus on it…but you can compare source of pci driver
git diff 4.19-r64-main..5.4-t64-main -- drivers/pci/controllerYes, both pci interrupt patch and pci controller splitting dts patch are applied. And i use the CN25 minicpie port.
Cloud you please tell me where is the 5.4-r64-main source, so I can compare with my 4.19 source.
Same repo 
only different branch
I am also having several pcie-issues with the r64.
It seemed a bit odd to me to split the pcie-controller into 2 controllers in the dt, so I was looking for the root cause regarding the PCIE-IRQ Issues (hoping, that this would also help with other issues, pls see below).
However: mtk-pcie driver registers 2 INTX IRQ Domains (one for each port) and 2 MSI IRQ Domains (with inner domains). Was produces the IRQ issues is, that those domains are not correctly assigned, when the 2 downstream ports (as pcie-bridges) are discovered during pci probing.
At first the MSI-issue (like mentioned by frank in the first posting of this thread): the msi domain a device is assigned to is derived down the bus: https://code.woboq.org/linux/linux/drivers/pci/probe.c.html#pci_set_bus_msi_domain So the 2 individual MSI-domains need to be assigned to the 2 downstream ports (=pcie bridges), which are the 2 devices found when probing the root bus in order to make it happen, that they get derived correctly when the child-busses are probed. So if you have a pcie-issue (like mentioned before), that goes away when using “pci=nomsi” as kernel cmdline, the improper assignment of the correct msi-domain is likely the cause.
There already exists a patch, that makes an individual assignment (for devices on one host-bridge/controller) possible (it needs to be applied first):
The patch in the following post can then register a callback: when devices are added on the bus during probing, it sets the MSI-domain of the appropriate mtk-pcie-“port”. PCIe-issues, that go away with pci=nomsi should also go away with those patches. You can look into /proc/interrupts whether MSI is used or not.
When probing continues and INTX IRQs (non-msi) are assigned for the devices on the root bus (which are the downstream-ports, recognized as pcie-bridges), the following function is called: https://code.woboq.org/linux/linux/drivers/pci/setup-irq.c.html It calls the map_irq-function of the hostbrige, that was assigned by mtk-pcie controller in line “host->map_irq = of_irq_parse_and_map_pci;” https://code.woboq.org/linux/linux/drivers/pci/of.c.html#of_irq_parse_and_map_pci
of_irq_parse_and_map_pci tries to find the IRQ by calling of_irq_parse_pci, which discovers a DT-node for the downstream-ports (pcie bridges) and calls irq_parse_one https://code.woboq.org/linux/linux/drivers/pci/of.c.html#of_irq_parse_pci https://code.woboq.org/linux/linux/drivers/of/irq.c.html#of_irq_parse_one https://code.woboq.org/linux/linux/drivers/of/irq.c.html#309
According to dt-rules, the interrupt-controller for the pcie-ports(!) is the mtk-sysirq-controller – but the downstream-ports (pcie bridges) (as obvious pcie-devices) are to be used with the dummy-irqchip solution from mediatek in mtk-pcie (which in turn gets triggered by sysirq). However, if the sysirq-controller is assumed, further parsing fails, because the #interrupt-cells of sysirq does not match the interrupts of the port.
Which can then lead to the following symptoms, if the corresponding modules are available/compiled it:
[ 3.129357] pcieport 0000:00:00.0: of_irq_parse_pci: failed with rc=-22
[ 3.151434] shpchp 0000:00:00.0: of_irq_parse_pci: failed with rc=-22
If you look into /proc/interrupts in this case you will likely see, that irq-assigment to pcie-devices (including downstream ports (bridges)) failed.
This can be solved by using the second-patch below, which ties the the pcie-downstream-ports (bridges) to the individual dummy-irqchip of mtk-pcie using dt.
Those patches solve the those issues for me without needing to split the whole pcie-controller in 2 DT-Nodes, because of those 2 ports. IMHO mtk-pcie should be refactored: both pcie-ports should not be individually mentioned in DT (like other pcie-controllers do). Instead, an interrupt-map for 2 slots can be used: https://elinux.org/Device_Tree_Usage#Advanced_Interrupt_Mapping Perhaps it also makes sense to implement the dummy-irqchips in DT as a direct subnodes of the pcie-controller. Regarding MSI, the “msi-controller” DT attribute could be interesing for specifying the individual MSI-domains (if they stay individual).
Jasmin
Index: linux-5.4.8/drivers/pci/controller/pcie-mediatek.c
===================================================================
--- linux-5.4.8.orig/drivers/pci/controller/pcie-mediatek.c
+++ linux-5.4.8/drivers/pci/controller/pcie-mediatek.c
@@ -1088,6 +1088,24 @@ static int mtk_pcie_setup(struct mtk_pci
return 0;
}
+int mtk_pcie_add_device_cb(struct pci_dev *dev) {
+
+ struct mtk_pcie_port *port = mtk_pcie_find_port(dev->bus, dev->devfn);
+
+ if(!port) {
+ dev_err(&dev->dev,"%s: unable to identify mtk_pcie port for this device\n",__func__);
+ return -1;
+ }
+
+ // set msi domain for devices on this controller's root bus only (gets derived for any child busses)
+ if(pci_is_root_bus(dev->bus) && port->pcie->busnr == dev->bus->number) {
+ dev_info(&dev->dev,"%s: setting MSI domain of port %u (at %p)\n",__func__,port->slot,port->msi_domain);
+ dev_set_msi_domain(&dev->dev,port->msi_domain);
+ }
+
+ return 0;
+}
+
static int mtk_pcie_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
@@ -1116,6 +1134,7 @@ static int mtk_pcie_probe(struct platfor
host->map_irq = of_irq_parse_and_map_pci;
host->swizzle_irq = pci_common_swizzle;
host->sysdata = pcie;
+ host->add_device = mtk_pcie_add_device_cb;
err = pci_host_probe(host);
if (err)
1 Like
Index: linux-5.4.8/arch/arm64/boot/dts/mediatek/mt7622.dtsi
===================================================================
--- linux-5.4.8.orig/arch/arm64/boot/dts/mediatek/mt7622.dtsi
+++ linux-5.4.8/arch/arm64/boot/dts/mediatek/mt7622.dtsi
@@ -805,6 +805,9 @@
ranges;
status = "disabled";
+ interrupt-parent = <&pcie_intc0>;
+ interrupts = <0>;
+
interrupt-map-mask = <0 0 0 7>;
interrupt-map = <0 0 0 1 &pcie_intc0 0>,
<0 0 0 2 &pcie_intc0 1>,
@@ -825,6 +828,9 @@
ranges;
status = "disabled";
+ interrupt-parent = <&pcie_intc1>;
+ interrupts = <0>;
+
interrupt-map-mask = <0 0 0 7>;
interrupt-map = <0 0 0 1 &pcie_intc1 0>,
<0 0 0 2 &pcie_intc1 1>,hi jasmin, thank you for the patches, i have applied them to new 5.4-pcie branch
can anybody having issues testing it? (maybe with coral-card)
i hope this patch does not break bpi-r2 (my 5.4 branch is for both boards).
Hi Frank,
thanks for applying the patches… I am courious, whether they work in more setups/with more boards.
However, 2 pcie-issues I discovered still remain:
a) compex WLE1216V5-20 not recognized at all:
mtk-pcie 1a140000.pcie: Port0 link down
I have already tried to increase the training time in mtk-pcie, but it did not help. Furthermore I used k_gbl_speed_sup (see mt7622) to restrict the link speed: did not help either. Perhaps it is related to this: I am now trying to patch mtk-pcie accordingly…
b) exar XR17V35X serial controller (connected via mpcie -> pcie x1 adapter) can not receive data over serial line. This serial controller card (including the adapter) works perfectly with 2 other different boards I have tested with (same kernel version). The card uses MMIO to map 8250 compatible register layout into memory. When data is received over serial line, an interrupt is fired (using INTX or MSI works both with patches above): the receive-function of the serial-driver is then correctly called, which looks into MMIO Bar in order to detect the reason for the interrupt. If data was received over serial line, a corresponding bit should be set in MMIO, which signals this circumstance as reason for the interrupt: but this bit is NOT set in MMIO space. So I guess, that incoming MMIO Transfer from the serial card to memory does not work properly, but
“lspci -vv” does not show SERR or PERR:
01:00.0 Serial controller: Exar Corp. Device 8358 (rev 03) (prog-if 02 [16550])
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 140
Region 0: Memory at 20000000 (32-bit, non-prefetchable) [size=16K]
Capabilities: [50] MSI: Enable+ Count=1/1 Maskable- 64bit+
Address: 0000000040a350c0 Data: 0000
Capabilities: [78] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold-)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [80] Express (v2) Endpoint, MSI 01
DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset- SlotPowerLimit 0.000W
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
MaxPayload 128 bytes, MaxReadReq 512 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
LnkCap: Port #1, Speed 2.5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s <64ns, L1 <1us
ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp-
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk-
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk- DLActive- BWMgmt- ABWMgmt-
DevCap2: Completion Timeout: Not Supported, TimeoutDis-, LTR-, OBFF Not Supported
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled
LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis-
Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -3.5dB, EqualizationComplete-, EqualizationPhase1-
EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
Capabilities: [100 v1] Virtual Channel
Caps: LPEVC=0 RefClk=100ns PATEntryBits=1
Arb: Fixed- WRR32- WRR64- WRR128-
Ctrl: ArbSelect=Fixed
Status: InProgress-
VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
Arb: Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=ff
Status: NegoPending- InProgress-
Kernel driver in use: exar_serial
After receiving some characters, the register 1A143424 (see MT7622 manual) (PCIE_INT_STATUS) is:
[ 1032.661583] mtk_pcie_intr_handler: PCIE_INT_STATUS reg 0x1A143424 val 0x10800000
[ 1032.668885] mtk_pcie_intr_handler: mpci_cfg_soft=0, pcie_rc_l2_wake=0, legacy_pm_chg=0, ltr_en=1, ltr_msg=0, cpu_active=0, obff=0, obff_idle=0
[ 1032.668889] mtk_pcie_intr_handler: msi=1, aer_event=0, pm_hp_event=0, serr=0, intd=0, intc=0, intb=0, inta=0
[ 1032.682006] mtk_pcie_intr_handler: UNUSED=0, b2p_discard=0, b2p_rerr=0, p2b_wr_win2=0, p2b_wr_win1=0, p2b_wr_win0=0, p2b_rerr=0, p2b_werr=0
[ 1032.692259] mtk_pcie_intr_handler: UNUSED=0, rdma_berr=0, rdma_perr=0, rdma_end=0, UNUSED=0, wdma_berr=0, wdma_perr=0, wdma_end=0
Furthermore I have looked into the REG_ES_* registers (see MT7622 manual):
[ 1032.705028] mtk_pcie_intr_handler: reg 0x10a355a0 val 0x0
[ 1032.723442] mtk_pcie_intr_handler: reg 0x10a355a4 val 0x0
[ 1032.729960] mtk_pcie_intr_handler: reg 0x10a355a8 val 0x0
[ 1032.736478] mtk_pcie_intr_handler: reg 0x10a355ac val 0x0
[ 1032.742996] mtk_pcie_intr_handler: reg 0x10a355b0 val 0x8f02
[ 1032.749774] mtk_pcie_intr_handler: reg 0x10a355b4 val 0x2
[ 1032.756293] mtk_pcie_intr_handler: reg 0x10a355b8 val 0x0
[ 1032.762811] mtk_pcie_intr_handler: reg 0x10a355bc val 0x0
[ 1032.769328] mtk_pcie_intr_handler: reg 0x10a355c0 val 0x0
[ 1032.775846] mtk_pcie_intr_handler: reg 0x10a355c4 val 0x0
[ 1032.782365] mtk_pcie_intr_handler: reg 0x10a355c8 val 0x1
[ 1032.788883] mtk_pcie_intr_handler: reg 0x10a355cc val 0x0
[ 1032.795401] mtk_pcie_intr_handler: reg 0x10a355d0 val 0x104
[ 1032.802092] mtk_pcie_intr_handler: reg 0x10a355d4 val 0xc22fff7
I do not know the reason why the bit, that is signalling, that data was received over the serial line, is not transferred to MMIO. As already mentioned: it works perfectly with other boards/SBCs and the same kernel (and architecture arm64).
What I found out is, that if this signalling bit is “ignored” by the serial driver and data is read from MMIO again and again (interrupt fire and loops run all the time), sometimes (and with latency of several seconds) some single characters get through!
My currently “best” hypothesis is, that the data does not come through PCIE-AHB/AXI-Transfer into memory – but only for certain transfer-types or something?
Any help/ideas are appreciated
Thanks Jasmin
which pci-slot do you use? port shared with sata (cn8) has a hardware-limitation (missing capacitors on tx-pins) causing only gen1 cards to be recognized
Good to know I have tried out both ports… same result.
The reset algorithm (like mentioned on github/link in my posting above) is likely the cause I think… I hope this can be solved by changing mtk_pcie_startup_port_v2 in pcie-mediatek.c accordingly.
https://bugzilla.kernel.org/show_bug.cgi?id=84821#c48
So at least there is something, that can be tried out
Jasmin
my compex wle900vx was recognized with splitted pci-ports in cn25 and i had open a AP on it
Btw.did you applied this patch? https://github.com/frank-w/BPI-R2-4.14/commit/9a89cdc0a9ac454bbb52ac2b359efdd80a064902
The issue was caused by class code is zero of Google Coral PCIe card, so linux pcie framework didn’t assign resource after scan.
The work-around solution is remove "class == PCI_CLASS_NOT_DEFINED " in setup-bus.c, thanks.
static void __dev_sort_resources(struct pci_dev *dev,
struct list_head *head)
{
u16 class = dev->class >> 8;
/* Don't touch classless devices or host bridges or ioapics. */
if (class == PCI_CLASS_NOT_DEFINED || class == PCI_CLASS_BRIDGE_HOST)
return;
ps. please refer to page 8 in below pdf to get more information about class id https://pcisig.com/sites/default/files/files/PCI_Code-ID_r_1_11__v24_Jan_2019.pdf
1 Like
You linked mutex issue…do you mean this or the bar0 unassigned issue happening on coral cards?
I linked to the wrong issue. I meant bar0 unassign issue was caused by class id is 0. it is a invalid value, thanks.