Hi Greg,
On Sat, Mar 21, 2020 at 7:28 AM Greg Ungerer <g...@kernel.org> wrote:
>
> 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.
Good news :)
> 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).
Please, let me know any issue you can find.
>
> Regards
> Greg
Best regards,
Sergio Paracuellos
>
_______________________________________________
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
