Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FS#3381 - Trunk don't initialize pci cards at mt7621 #8245

Closed
openwrt-bot opened this issue Oct 12, 2020 · 6 comments
Closed

FS#3381 - Trunk don't initialize pci cards at mt7621 #8245

openwrt-bot opened this issue Oct 12, 2020 · 6 comments
Labels
flyspray target/sunxi

Comments

@openwrt-bot
Copy link

@openwrt-bot openwrt-bot commented Oct 12, 2020

AelxG:

Trunk does not initialize pci adapter cards properly.

I'm using unielec mt7621 board with kind of Atheros miniPCIe cards? in this test installed AR9287 adapter.

Here is lspci and part of dmesg output from 19.07.4:

root@OpenWrt:~# lspci -v
02:00.0 Network controller: Qualcomm Atheros AR9287 Wireless Network Adapter (PCI-Express) (rev 01)
Subsystem: Qualcomm Atheros Device 30a4
Flags: fast devsel, IRQ 255
Memory at 60200000 (64-bit, non-prefetchable) [disabled] [size=64K]
Capabilities: [40] Power Management version 3
Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit-
Capabilities: [60] Express Legacy Endpoint, MSI 00
Capabilities: [100] Advanced Error Reporting
Capabilities: [140] Virtual Channel
Capabilities: [160] Device Serial Number 00-15-17-ff-ff-24-14-12
Capabilities: [170] Power Budgeting <?>

[ 2.261556] pci 0000:02:00.0: [168c:002e] type 00 class 0x028000
[ 2.261628] pci 0000:02:00.0: reg 0x10: [mem 0x00000000-0x0000ffff 64bit]
[ 2.261756] pci 0000:02:00.0: supports D1
[ 2.261764] pci 0000:02:00.0: PME# supported from D0 D1 D3hot

Here is lspci and part of dmesg output from trunk:

02:00.0 Ethernet controller: Qualcomm Atheros AR5008 Wireless Network Adapter (rev 01)
Flags: fast devsel, IRQ 255
Memory at 60200000 (64-bit, non-prefetchable) [disabled] [size=64K]
Capabilities: [40] Power Management version 3
Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit-
Capabilities: [60] Express Legacy Endpoint, MSI 00
Capabilities: [100] Advanced Error Reporting
Capabilities: [140] Virtual Channel
Capabilities: [160] Device Serial Number 00-00-00-00-00-00-00-00
Capabilities: [170] Power Budgeting <?>

[ 1.604742] pci 0000:02:00.0: [168c:ff1c] type 00 class 0x020000
[ 1.610801] pci 0000:02:00.0: reg 0x10: [mem 0x00000000-0x0000ffff 64bit]
[ 1.617717] pci 0000:02:00.0: supports D1
[ 1.621723] pci 0000:02:00.0: PME# supported from D0 D1 D3hot

You may see the the trunk cannot see correct PCI ID and some pci parameters like device serial numbers. Also any wifi modules does not work (mac80211, etc).

@openwrt-bot
Copy link
Author

@openwrt-bot openwrt-bot commented Nov 1, 2020

marcin1j:

Please post full dmesg output for both 4.14 and 5.4 kernels.

This is probably the same problem as reported in FS#3093. I also noticed this on Netgear R6220 but unfortunately it has not magically disappeared...

In my case adding a short 25ms delay in mt7621-pci driver has helped. This is still much shorter than in old 4.14 driver (100ms with one 50ms exception) but seems to solve the issue.

Try applying attached patch and check if that helps.

@openwrt-bot
Copy link
Author

@openwrt-bot openwrt-bot commented Nov 4, 2020

AelxG:

Thanks a lot but trunks after October 20 work fine.

Should I compile version before october 20 and put dmesg from it here?

@openwrt-bot
Copy link
Author

@openwrt-bot openwrt-bot commented Nov 4, 2020

marcin1j:

That would help verify my hypothesis but since your problem is already gone there's no way this could help you :-)

So if you can check this or dig the logs from somewhere I'd be very obliged. Speaking of PCIe device probing, nothing has changed in upstream kernel or OpenWRT patches yet it started working for you. I have two supposedly identical R6220 devices: one worked flawlessly and the other (the same kernel version) would not initialize pcie2 card in ~90% cases.
I strongly suspect there's missing delay in new driver but devices are probed in parallel so actual intervals depend on what features are enabled and what devices are actually connected.

@openwrt-bot
Copy link
Author

@openwrt-bot openwrt-bot commented Nov 6, 2020

AelxG:

I found old log from August 24, hope it will help you.

But you should note some interesting thing.

At this moment I cannot reproduce this issue. I tried to run custom built trunk and it runs fine. I did the next:

#git pull https://git.openwrt.org/openwrt/openwrt.git
#git checkout 7f5f738
M feeds.conf.default
M target/linux/ramips/dts/mt7621.dtsi
M target/linux/ramips/dts/mt7621_unielec_u7621-06.dtsi
Previous HEAD position was c78e123 rtl838x: various fixes
HEAD is now at 7f5f738 sunxi: Adapt U-Boot config to board rename

At feeds.conf.default I commented out telephony and freifunk, at dtsi -- enable i2c and change serial console speed tp 57600 as used in u-boot at my device.

@openwrt-bot
Copy link
Author

@openwrt-bot openwrt-bot commented Jan 23, 2021

AelxG:

Hi Martin!

Thanks a lot for idea! After applying this patch my board works very fine!

--- drivers/staging/mt7621-pci/pci-mt7621.c | 1 + 1 file changed, 1 insertion(+)

--- a/drivers/staging/mt7621-pci/pci-mt7621.c 2021-01-26 14:36:41.761773605 +0300
+++ b/drivers/staging/mt7621-pci/pci-mt7621.c 2021-01-28 14:23:04.015990292 +0300
@@ -502,6 +502,7 @@
int err;

rt_sysc_m32(PERST_MODE_MASK, PERST_MODE_GPIO, MT7621_GPIO_MODE);
  • mdelay(100);
mt7621_pcie_reset_assert(pcie);
mt7621_pcie_reset_rc_deassert(pcie);

@ynezz ynezz added the target/sunxi label Mar 7, 2022
@ynezz
Copy link
Member

@ynezz ynezz commented Mar 8, 2022

According to #7862 it should be fixed.

@ynezz ynezz closed this as completed Mar 8, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
flyspray target/sunxi
Projects
None yet
Development

No branches or pull requests

2 participants