Hi Sergio,
On 21/3/20 1:25 am, Sergio Paracuellos wrote:
On Fri, Mar 20, 2020 at 4:08 PM Greg Ungerer <g...@kernel.org> wrote:
On 21/3/20 12:38 am, Sergio Paracuellos wrote:
On Fri, Mar 20, 2020 at 3:30 PM Greg Ungerer <g...@kernel.org> wrote:
On 20/3/20 2:14 am, Sergio Paracuellos wrote:
[snip]
rt2880-pinmux pinctrl: pcie is already enabled
mt7621-pci 1e140000.pcie: Error applying setting, reverse things back
mt7621-pci-phy 1e149000.pcie-phy: Xtal is 40MHz
mt7621-pci-phy 1e149000.pcie-phy: Xtal is 40MHz
mt7621-pci-phy 1e14a000.pcie-phy: Xtal is 40MHz
mt7621-pci 1e140000.pcie: pcie0 no card, disable it (RST & CLK)
mt7621-pci 1e140000.pcie: pcie1 no card, disable it (RST & CLK)
mt7621-pci 1e140000.pcie: pcie2 no card, disable it (RST & CLK)
mt7621-pci 1e140000.pcie: Nothing is connected in virtual bridges. Exiting..
...
It is probably 50:50 on any boot whether it will probe pci successfully or
fail to probe it.
BTW, this is with the patch here applied:
http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2020-March/142472.html
Yes this is the behaviour I was talking about in this series:
http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2020-March/142520.html
These patches have been already added to staging-testing and should
work and found properly ports also for you.
Let me know any issue you might find.
Ok, I am testing now a fresh up-to-date staging-testing.
I can see your most recent patches for the pci-phy at the top of the git log.
No other patches applied (just my devicetree for my hardware).
It dumps on every boot with:
...
rt2880-pinmux pinctrl: pcie is already enabled
mt7621-pci 1e140000.pcie: Error applying setting, reverse things back
mt7621-pci-phy 1e149000.pcie-phy: PHY for 0xbe149000 (dual port = 1)
mt7621-pci-phy 1e14a000.pcie-phy: PHY for 0xbe14a000 (dual port = 0)
mt7621-pci-phy 1e149000.pcie-phy: Xtal is 40MHz
mt7621-pci-phy 1e14a000.pcie-phy: Xtal is 40MHz
mt7621-pci 1e140000.pcie: pcie1 no card, disable it (RST & CLK)
Unhandled kernel unaligned access[#1]:
CPU: 3 PID: 111 Comm: kworker/3:2 Not tainted
5.6.0-rc3-00347-g825c6f470c62-dirty #9
Workqueue: events deferred_probe_work_func
$ 0 : 00000000 00000001 5f60d043 8fe1ba80
$ 4 : 0000010d 01eb9000 00000000 00000000
$ 8 : 294b4c00 80940000 00000008 000000ce
$12 : 2e303030 00000000 00000000 65696370
$16 : ffffffed 0000010d 8e373cd0 8214c1e0
$20 : 00000000 82144c80 82144680 8214c250
$24 : 00000018 803ef8f4
$28 : 8e372000 8e373c60 8214c080 803940e8
Hi : 00000125
Lo : 122f2000
epc : 807b3328 mutex_lock+0x8/0x44
ra : 803940e8 phy_power_off+0x28/0xb0
Status: 1100fc03 KERNEL EXL IE
Cause : 00800010 (ExcCode 04)
BadVA : 0000010d
PrId : 0001992f (MIPS 1004Kc)
Modules linked in:
Process kworker/3:2 (pid: 111, threadinfo=(ptrval), task=(ptrval), tls=00000000)
Stack : 8e373cd0 803fe4f4 8e372000 8e373c90 8214c080 804fde1c 8e373c98 808d62f4
8e373c78 00000000 8214c254 804fe648 1e160000 804f27b8 00000001
808d62f4
00000000 00000001 8214c228 808d62f4 80930000 809a0000 8fd47e10
808d63d4
808d62d4 8fd47e10 808d0000 808d0000 8e373cd0 8e373cd0 809e2a74
809db510
809db510 00000006 00000001 00000000 00000000 00000000 01000000
1e1440ff
...
Call Trace:
[<807b3328>] mutex_lock+0x8/0x44
[<803940e8>] phy_power_off+0x28/0xb0
[<804fe648>] mt7621_pci_probe+0xc20/0xd18
[<80402ab8>] platform_drv_probe+0x40/0x94
[<80400a74>] really_probe+0x104/0x364
[<803feb74>] bus_for_each_drv+0x84/0xdc
[<80400924>] __device_attach+0xdc/0x120
[<803ffb5c>] bus_probe_device+0xa0/0xbc
[<80400124>] deferred_probe_work_func+0x7c/0xbc
[<800420e8>] process_one_work+0x230/0x450
[<80042638>] worker_thread+0x330/0x5fc
[<80048eb0>] kthread+0x12c/0x134
[<80007438>] ret_from_kernel_thread+0x14/0x1c
Code: 24050002 27bdfff8 8f830000 <c0850000> 14a00005 00000000 00600825
e0810000 1020fffa
Ok, this seems to be the access for slot 1 which I default set to true
as enabled ports because of the phy is for dual_port,
so because you are using only one of the two ports the
phy_power_off(port->phy); for slot 1 should not be triggered because
it is done for slot 0 if neccessary.
Can you try this small fix:
diff --git a/drivers/staging/mt7621-pci/pci-mt7621.c
b/drivers/staging/mt7621-pci/pci-mt7621.c
index 739504f7e4fc..23b51789f72e 100644
--- a/drivers/staging/mt7621-pci/pci-mt7621.c
+++ b/drivers/staging/mt7621-pci/pci-mt7621.c
@@ -517,7 +517,8 @@ static void mt7621_pcie_init_ports(struct mt7621_pcie *pcie)
if (!mt7621_pcie_port_is_linkup(port)) {
dev_err(dev, "pcie%d no card, disable it (RST &
CLK)\n",
slot);
- phy_power_off(port->phy);
+ if (slot != 1)
+ phy_power_off(port->phy);
mt7621_control_assert(port);
mt7621_pcie_port_clk_disable(port);
port->enabled = false;
---[ end trace 8e3fadee03559cba ]---
Yep, that fixes it. No more dumps.
In limited testing so far every boot up has probed the PCI bu successfully.
I'll keep testing, and report any problems.
Note that I am running with the modified mt7621.dtsi that has the reset
lines for PCIe limited to only GPIO19. (GPIO7 and GPIO8 removed from reset).
Regards
Greg
_______________________________________________
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
