Hi Greg, On Thu, Mar 12, 2020 at 5:56 AM Greg Ungerer <gerg@xxxxxxxxxx> wrote: > > Hi Sergio, > > On 12/3/20 4:58 am, Sergio Paracuellos wrote: > > Some time ago Greg Ungerer reported some random hangs using > > the staging mt7621-pci driver: > > > > See: > > * http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2019-June/134947.html > > > > Try to fix that is the main motivation of this patch series. > > Excellent! I am glad to see an effort to get these problems resolved. > I still have to switch back to much earlier version of this PCI > driving code to get reliable working behavior. > > > > Also in openwrt there is a driver for mt7621-pci which seems was rewritten > > from scratch (for kernel 4.14) by Ryder Lee and Weijie Gao from mediatek. > > There the approach for reset assert-deassert process is to set as 'gpio' > > the function for all the 'pcie' group for the pinctrl driver and use those > > gpio's as a reset for the end points. The driver I am talking about is still > > using legacy pci and legacy gpio kernel interfaces. IMHO, the correct thing > > to do is make this staging driver properly clean and functional and put it > > in its correct place in the mainline. > > > > See: > > * https://gist.github.com/dengqf6/7a9e9b4032d99f1a91dd9256c8a65c36 > > > > Because of all of this this patch series tries to avoid random hangs of boot > > trying to use the 'reset-gpios' approach. > > > > Changes are being tested by openwrt people and seems to work. > > > > Hope this helps. > > What kernel did you generate these patches against? > They didn't apply completely cleanly for me against 5.5 or 5.6.0-rc5. > Minor reject and some fuzzing, easy enough to fix for testing. > This is rebased on the top of staging-testing branch of git staging tree. > Running 5.6.0-rc5 I get the following failure on my hardware during boot: > > ... > rt2880-pinmux pinctrl: pcie is already enabled > mt7621-pci 1e140000.pcie: Error applying setting, reverse things back > mt7621-pci 1e140000.pcie: Unable to request GPIO reset in slot 1 > mt7621-pci 1e140000.pcie: Parsing DT failed > mt7621-pci: probe of 1e140000.pcie failed with error -16 > Ok, so it seems depending of boards gpio's can or not can be requested, so maybe we have to do this optional an don't fail on parsing the device tree. > > FWIW: running the original 5.6.0-rc5 code gives a few different > PCI startup failures - but PCI devices never work properly. I can > send the error trace output if useful, but it is similar to what > I have posted in the past. Mmmm. This patches were tested yesterday and I was told they were working. I will change this patches to avoid gpio's to be mandatory and send v3, thanks. See: https://github.com/openwrt/openwrt/pull/2798 > > Regards > Greg Best regards, Sergio Paracuellos > > > > Changes in v2: > > * restore configuration for pers mode to GPIO. > > * Avoid to read FTS_NUM register in reset state. > > > > Best regards, > > Sergio Paracuellos > > > > > > Sergio Paracuellos (5): > > staging: mt7621-pci: use gpios for properly reset > > staging: mt7621-pci: change value for 'PERST_DELAY_US' > > staging: mt7621-dts: make use of 'reset-gpios' property for pci > > staging: mt7621-pci: bindings: update doc accordly to last changes > > staging: mt7621-pci: release gpios after pci initialization > > > > drivers/staging/mt7621-dts/mt7621.dtsi | 11 ++- > > .../mt7621-pci/mediatek,mt7621-pci.txt | 7 +- > > drivers/staging/mt7621-pci/pci-mt7621.c | 94 ++++++++++++------- > > 3 files changed, 72 insertions(+), 40 deletions(-) > > _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
