I also try to get a pcie wifi card (Compex WLE600VX) running in the
clearfog pro board with kernel 4.4.
As I read in this thread the "irg.mode=1" shoud help:
https://www.spinics.net/lists/linux-wireless/msg155685.html
But it is not working for me:
debian@clearfog:~$ lsmod
Module Size Used by
8021q 36864 0
garp 16384 1 8021q
mrp 20480 1 8021q
stp 16384 1 garp
llc 16384 2 stp,garp
bnep 20480 2
ath10k_pci 45056 0
ath10k_core 249856 1 ath10k_pci
ath 32768 1 ath10k_core
mac80211 786432 1 ath10k_core
bluetooth 385024 7 bnep
qcserial 16384 0
cfg80211 561152 3 ath,mac80211,ath10k_core
usb_wwan 16384 1 qcserial
qmi_wwan 24576 0
cdc_wdm 20480 1 qmi_wwan
usbserial 40960 2 qcserial,usb_wwan
usbnet 36864 1 qmi_wwan
mii 16384 1 usbnet
rfkill 32768 4 cfg80211,bluetooth
firmware_class 24576 1 ath10k_core
marvell_cesa 45056 0
ehci_orion 16384 0
des_generic 28672 1 marvell_cesa
mcp3021 16384 0
hwmon 16384 1 mcp3021
evbug 16384 0
uio_pdrv_genirq 16384 0
uio 20480 1 uio_pdrv_genirq
fuse 102400 1
ipv6 532480 0
autofs4 36864 2
debian@clearfog:~$ uname -a
Linux clearfog 4.4.15-clearfog #1 SMP Wed Oct 5 00:03:36 UTC 2016 armv7l
GNU/Linux
debian@clearfog:~$ sudo rmmod ath10k_pci ath10k_core
debian@clearfog:~$ sudo modprobe ath10k_core
debian@clearfog:~$ sudo modprobe ath10k_pci
[ 69.529351] ath10k_pci 0000:01:00.0: Refused to change power state,
currently in D3
[ 69.567989] ath10k_pci 0000:01:00.0: failed to wake up device : -110
[ 69.575267] ath10k_pci: probe of 0000:01:00.0 failed with error -110
debian@clearfog:~$ sudo rmmod ath10k_pci ath10k_core
debian@clearfog:~$ sudo modprobe ath10k_core
debian@clearfog:~$ sudo modprobe ath10k_pci irq_mode=1
[ 97.899370] ath10k_pci 0000:01:00.0: Refused to change power state,
currently in D3
[ 97.938045] ath10k_pci 0000:01:00.0: failed to wake up device : -110
[ 97.944973] ath10k_pci: probe of 0000:01:00.0 failed with error -110
debian@clearfog:~$ lspci -vvv
00:02.0 PCI bridge: Marvell Technology Group Ltd. Device 6828 (rev 04)
(prog-if 00 [Normal decode])
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, Cache Line Size: 64 bytes
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
I/O behind bridge: 0000f000-00000fff
Memory behind bridge: f8000000-f82fffff
Prefetchable memory behind bridge: 00000000-000fffff
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- <SERR- <PERR-
BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: <access denied>
00:03.0 PCI bridge: Marvell Technology Group Ltd. Device 6828 (rev 04)
(prog-if 00 [Normal decode])
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-
Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
I/O behind bridge: 0000f000-00000fff
Memory behind bridge: fff00000-000fffff
Prefetchable memory behind bridge: 00000000-000fffff
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- <SERR- <PERR-
BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: <access denied>
01:00.0 Network controller: Qualcomm Atheros QCA988x 802.11ac Wireless
Network Adapter (rev ff) (prog-if ff)
!!! Unknown header type 7f
Something else what I can try?
Best regards,
Matthias
>I (naively) went through pci/pm git log and found the following was
>applied on 4.7-rc2 (i.e. prior to 4.7 release):
>
> commit 006d44e49a259b39947366728d65a873a19aadc0
> Author: Mika Westerberg <[email protected]>
> Date: Thu Jun 2 11:17:15 2016 +0300
>
> PCI: Add runtime PM support for PCIe ports
>
>From reading the commit log it seems to me like it could be it.
>
>ath10k tries to wake up the device during probing before it starts
>talking to it and it does so through MMIO/PCI config space. If it's
>not mapped properly then driver will not be able to wake it up and
>will timeout waiting for it.
>
>Can you try cherry-picking it into your 4.4.24 and see if it helps?
>
>
Thanks for the help!
Until now I did not compile a kernel for the board.
I will give it a try and come back with the results ...
Best regards,
Matthias
On 24 October 2016 at 12:18, Matthias Klein <[email protected]> wr=
ote:
> I also try to get a pcie wifi card (Compex WLE600VX) running in the clear=
fog
> pro board with kernel 4.4.
>
> As I read in this thread the "irg.mode=3D1" shoud help:
> https://www.spinics.net/lists/linux-wireless/msg155685.html
>
> But it is not working for me:
>
[...]
> [ 97.899370] ath10k_pci 0000:01:00.0: Refused to change power state,
> currently in D3
> [ 97.938045] ath10k_pci 0000:01:00.0: failed to wake up device : -110
> [ 97.944973] ath10k_pci: probe of 0000:01:00.0 failed with error -110
[...]
> 01:00.0 Network controller: Qualcomm Atheros QCA988x 802.11ac Wireless
> Network Adapter (rev ff) (prog-if ff)
> !!! Unknown header type 7f
The device looks completely unresponsive.
I don't think this is MSI problem. This error happens before
interrupts are even set up.
I suspect platform/PCI/PM specific problem. I would suggest bisecting
the kernel and seeing which patch is making the difference.
I (naively) went through pci/pm git log and found the following was
applied on 4.7-rc2 (i.e. prior to 4.7 release):
commit 006d44e49a259b39947366728d65a873a19aadc0
Author: Mika Westerberg <[email protected]>
Date: Thu Jun 2 11:17:15 2016 +0300
PCI: Add runtime PM support for PCIe ports
>From reading the commit log it seems to me like it could be it.
ath10k tries to wake up the device during probing before it starts
talking to it and it does so through MMIO/PCI config space. If it's
not mapped properly then driver will not be able to wake it up and
will timeout waiting for it.
Can you try cherry-picking it into your 4.4.24 and see if it helps?
Micha=C5=82
>
>> I (naively) went through pci/pm git log and found the following was
>> applied on 4.7-rc2 (i.e. prior to 4.7 release):
>>
>> commit 006d44e49a259b39947366728d65a873a19aadc0
>> Author: Mika Westerberg <[email protected]>
>> Date: Thu Jun 2 11:17:15 2016 +0300
>>
>> PCI: Add runtime PM support for PCIe ports
>>
>> From reading the commit log it seems to me like it could be it.
>>
>> ath10k tries to wake up the device during probing before it starts
>> talking to it and it does so through MMIO/PCI config space. If it's
>> not mapped properly then driver will not be able to wake it up and
>> will timeout waiting for it.
>>
>> Can you try cherry-picking it into your 4.4.24 and see if it helps?
>>
>>
> Thanks for the help!
>
> Until now I did not compile a kernel for the board.
> I will give it a try and come back with the results ...
>
>
> Best regards,
> Matthias
>
Any news on that? I am in contact with the support of SolidRun
(clearfog). Unfortunately they will stay at 4.4.x - no upgrade to 4.8
nor 4.9 planned. Unfortunately the commit (006d44e) is incompatible to
4.4. because pci_dev does not know bridge_d3
> I created a patch which should work for 4.4.24 (at least for arch
> linux arm it applied successful)
>
> Just compiling the kernel... lets see what happens
Did not work. First, there was a + which was wrong, guess i have this
simply overseen. After fixing that i got:
drivers/pci/pcie/portdrv_pci.c: In function 'pcie_port_runtime_suspend':
drivers/pci/pcie/portdrv_pci.c:98:24: error: 'struct pci_dev' has no
member named 'bridge_d3'
return to_pci_dev(dev)->bridge_d3 ? 0 : -EBUSY;
^~
drivers/pci/pcie/portdrv_pci.c: In function 'pcie_port_runtime_idle':
drivers/pci/pcie/portdrv_pci.c:113:24: error: 'struct pci_dev' has no
member named 'bridge_d3'
return to_pci_dev(dev)->bridge_d3 ? 0 : -EBUSY;
^~
drivers/pci/pcie/portdrv_pci.c:114:1: warning: control reaches end of
non-void function [-Wreturn-type]
}
^
drivers/pci/pcie/portdrv_pci.c: In function 'pcie_port_runtime_suspend':
drivers/pci/pcie/portdrv_pci.c:99:1: warning: control reaches end of
non-void function [-Wreturn-type]
}
^
make[3]: *** [scripts/Makefile.build:259:
drivers/pci/pcie/portdrv_pci.o] Error 1
make[2]: *** [scripts/Makefile.build:403: drivers/pci/pcie] Error 2
make[1]: *** [scripts/Makefile.build:403: drivers/pci] Error 2
make: *** [Makefile:959: drivers] Error 2
==> ERROR: A failure occurred in build().
Aborting...
A simple cherry pick does not work in that case.
>> Can you try cherry-picking it into your 4.4.24 and see if it helps?
I created a patch which should work for 4.4.24 (at least for arch linux
arm it applied successful)
diff --git a/drivers/pci/pcie/portdrv_core.c
b/drivers/pci/pcie/portdrv_core.c
index 88122dc..f2caf38 100644
--- a/drivers/pci/pcie/portdrv_core.c
+++ b/drivers/pci/pcie/portdrv_core.c
@@ -8,6 +8,7 @@
#include <linux/module.h>
#include <linux/pci.h>
+#include <linux/pm_runtime.h>
#include <linux/kernel.h>
#include <linux/errno.h>
#include <linux/pm.h>
@@ -350,6 +351,8 @@ static int pcie_device_init(struct pci_dev *pdev,
int service, int irq)
return retval;
}
+ pm_runtime_no_callbacks(device);
+
return 0;
}
diff --git a/drivers/pci/pcie/portdrv_pci.c b/drivers/pci/pcie/portdrv_pci.c
index be35da2..1624cc3 100644
--- a/drivers/pci/pcie/portdrv_pci.c
+++ b/drivers/pci/pcie/portdrv_pci.c
@@ -93,6 +93,28 @@ static int pcie_port_resume_noirq(struct device *dev)
return 0;
}
+static int pcie_port_runtime_suspend(struct device *dev)
+{
+ return to_pci_dev(dev)->bridge_d3 ? 0 : -EBUSY;
+}
+
+static int pcie_port_runtime_resume(struct device *dev)
+{
+ return 0;
+}
+
+static int pcie_port_runtime_idle(struct device *dev)
+{
+ /*
+ * Assume the PCI core has set bridge_d3 whenever it thinks the port
+ * should be good to go to D3. Everything else, including moving
+ * the port to D3, is handled by the PCI core.
+ */
+ return to_pci_dev(dev)->bridge_d3 ? 0 : -EBUSY;
+}
++
+
+
static const struct dev_pm_ops pcie_portdrv_pm_ops = {
.suspend = pcie_port_device_suspend,
.resume = pcie_port_device_resume,
@@ -101,6 +123,9 @@ static const struct dev_pm_ops pcie_portdrv_pm_ops = {
.poweroff = pcie_port_device_suspend,
.restore = pcie_port_device_resume,
.resume_noirq = pcie_port_resume_noirq,
+ .runtime_suspend = pcie_port_runtime_suspend,
+ .runtime_resume = pcie_port_runtime_resume,
+ .runtime_idle = pcie_port_runtime_idle,
};
#define PCIE_PORTDRV_PM_OPS (&pcie_portdrv_pm_ops)
@@ -139,11 +164,39 @@ static int pcie_portdrv_probe(struct pci_dev *dev,
* it by default.
*/
dev->d3cold_allowed = false;
+
+ /*
+ * Prevent runtime PM if the port is advertising support for PCIe
+ * hotplug. Otherwise the BIOS hotplug SMI code might not be able
+ * to enumerate devices behind this port properly (the port is
+ * powered down preventing all config space accesses to the
+ * subordinate devices). We can't be sure for native PCIe hotplug
+ * either so prevent that as well.
+ */
+ if (!dev->is_hotplug_bridge) {
+ /*
+ * Keep the port resumed 100ms to make sure things like
+ * config space accesses from userspace (lspci) will not
+ * cause the port to repeatedly suspend and resume.
+ */
+ pm_runtime_set_autosuspend_delay(&dev->dev, 100);
+ pm_runtime_use_autosuspend(&dev->dev);
+ pm_runtime_mark_last_busy(&dev->dev);
+ pm_runtime_put_autosuspend(&dev->dev);
+ pm_runtime_allow(&dev->dev);
+ }
+
return 0;
}
static void pcie_portdrv_remove(struct pci_dev *dev)
{
+ if (!dev->is_hotplug_bridge) {
+ pm_runtime_forbid(&dev->dev);
+ pm_runtime_get_noresume(&dev->dev);
+ pm_runtime_dont_use_autosuspend(&dev->dev);
+ }
+
pcie_port_device_remove(dev);
}
Just compiling the kernel... lets see what happens