staging: mt7621-pci: factor out 'mt7621_pcie_enable_port' function

Sergio Paracuellos sergio.paracuellos at gmail.com
Mon Jun 3 19:59:06 UTC 2019


Hi Greg,

On Mon, Jun 3, 2019 at 2:32 PM Greg Ungerer <gerg at kernel.org> wrote:
>
> Hi Sergio,
>
> On 3/6/19 3:34 pm, Sergio Paracuellos wrote:
> > On Mon, Jun 3, 2019 at 3:26 AM Greg Ungerer <gerg at kernel.org> wrote:
> >> On 31/5/19 10:37 pm, Sergio Paracuellos wrote:
> >>> On Thu, May 30, 2019 at 3:46 AM Greg Ungerer <gerg at kernel.org> wrote:
> >>>> On 30/5/19 10:44 am, Greg Ungerer wrote:
> >>>>> On 29/5/19 6:08 pm, Sergio Paracuellos wrote:
> >>>>> [snip]
> >>>>>> I have added gpio consumer stuff and reorder a bit the code to be more
> >>>>>> similar to 4.20.
> >>>>>>
> >>>>>> I attach the patch. I have not try it to compile it, because my normal
> >>>>>> environment is in another
> >>>>>> computer and I am in the middle of moving from my current house and
> >>>>>> don't have access to it, sorry.
> >>>>>> So, please try this and let's see what happens.
> >>>>>
> >>>>> No problem, thanks for the patch.
> >>>>>
> >>>>> Unfortunately always locks up on kernel boot:
> >>>>>
> >>>>>      ...
> >>>>>      mt7621-pci-phy 1e149000.pcie-phy: Xtal is 40MHz
> >>>>>      mt7621-pci 1e140000.pcie: Port 454043648 N_FTS = 0
> >>>>>      mt7621-pci-phy 1e149000.pcie-phy: Xtal is 40MHz
> >>>>>      mt7621-pci 1e140000.pcie: Port 454043648 N_FTS = 1
> >>>>>      mt7621-pci-phy 1e14a000.pcie-phy: Xtal is 40MHz
> >>>>>      mt7621-pci 1e140000.pcie: Port 454043648 N_FTS = 2
> >>>>>      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)
> >>>>>
> >>>>> That was original linux-5.1 patched with your attached patch.
> >>>>>
> >>>>> I'll try and dig down into that further today and get some
> >>>>> feedback on where it is failing.
> >>>>
> >>>> The first problem I see is that the GPIO MODE register bits for
> >>>> PERST_MODE are set to 00, so in "PCIe Reset" mode. If I hack in
> >>>> a register update for that with:
> >>>>
> >>>>        /* Force PERST PCIe reset into GPIO mode */
> >>>>        *(unsigned int *)(0xbe000060) |=  BIT(10);
> >>>
> >>> I have set GPIO mode for this in the new attached patch.
> >>>
> >>>>
> >>>> I do that at the start of mt7621_pcie_init_ports(). With that in
> >>>> place I get further:
> >>>>
> >>>>      mt7621-pci-phy 1e149000.pcie-phy: Xtal is 40MHz
> >>>>      mt7621-pci 1e140000.pcie: Port 454043648 N_FTS = 0
> >>>>      mt7621-pci-phy 1e149000.pcie-phy: Xtal is 40MHz
> >>>>      mt7621-pci 1e140000.pcie: Port 454043648 N_FTS = 1
> >>>>      mt7621-pci-phy 1e14a000.pcie-phy: Xtal is 40MHz
> >>>>      mt7621-pci 1e140000.pcie: Port 454043648 N_FTS = 2
> >>>>      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: PCIE0 enabled
> >>>>      mt7621-pci 1e140000.pcie: PCI coherence region base: 0x60000000, mask/settings: 0xf0000002
> >>>>      mt7621-pci 1e140000.pcie: PCI host bridge to bus 0000:00
> >>>>      pci_bus 0000:00: root bus resource [io  0xffffffff]
> >>>>      pci_bus 0000:00: root bus resource [mem 0x60000000-0x6fffffff]
> >>>>      pci_bus 0000:00: root bus resource [bus 00-ff]
> >>>>      pci 0000:00:00.0: bridge configuration invalid ([bus 00-00]), reconfiguring
> >>>>
> >>>> It hangs there...
> >>>
> >>> I had review the boot order is working for you in version 4.20 and the
> >>> order with the new patch applied. There were
> >>> only one difference, the place where interrupt bits are set. I have
> >>> changed that also in the new attached patch.
> >>>
> >>> For me, the order now and how the different boot steps are being done
> >>> in v4.20 are the same.
> >>>
> >>> One other thing I don't really understand why is needed but is in the
> >>> v4.20 code are this two lines:
> >>>
> >>> pcie_write(pcie, 0xffffffff, RALINK_PCI_MEMBASE);
> >>> pcie_write(pcie, RALINK_PCI_IO_MAP_BASE, RALINK_PCI_IOBASE);
> >>>
> >>> These are added also in the current patch.
> >>
> >> Tried out this latest patch. Unfortunately no good news.
> >>
> >> Boot gets through the PCI bus scan, but does not find any devices:
> >>
> >>     mt7621-pci-phy 1e149000.pcie-phy: Xtal is 40MHz
> >>     mt7621-pci 1e140000.pcie: Port 454043648 N_FTS = 0
> >>     mt7621-pci-phy 1e149000.pcie-phy: Xtal is 40MHz
> >>     mt7621-pci 1e140000.pcie: Port 454043648 N_FTS = 1
> >>     mt7621-pci-phy 1e14a000.pcie-phy: Xtal is 40MHz
> >>     mt7621-pci 1e140000.pcie: Port 454043648 N_FTS = 2
> >>     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...
> >
> >
> >
> >>
> >> And now in the completely weird and un-expected department the boot
> >> continues on and appears to hang for me when it tries to attach a
> >> UBI NAND flash partition. It hangs there for about a minute or so
> >> and then dumps complaing about flash problems:
> >>
> >>     ubi0: attaching mtd3
> >>     ubi0: scanning is finished
> >>     ubi0: empty MTD device detected
> >>     ubi0 warning: do_sync_erase: error -5 while erasing PEB 0, retry
> >>     ubi0 warning: do_sync_erase: error -5 while erasing PEB 0, retry
> >>     ubi0 warning: do_sync_erase: error -5 while erasing PEB 0, retry
> >>     ubi0 error: do_sync_erase: cannot erase PEB 0, error -5
> >>     CPU: 1 PID: 1 Comm: swapper/0 Not tainted 5.1.0-ac0 #59
> >>     Stack : 000000f0 00000000 00000000 808e0000 8ebf2000 80070584 808285b8 0000000b
> >>           00000038 00000000 80827e00 8fc23b1c 80870000 00000001 8fc23ab0 aeddef9b
> >>           00000000 00000000 80920000 00000000 00000000 808e7693 000000f1 00000000
> >>           203a6d6d 00000000 00000000 00000000 80870000 00000000 00000000 8080a01c
> >>           00000000 80870000 8ebf1014 8ebd2000 00000018 80361d24 00000004 808e0004
> >>           ...
> >>     Call Trace:
> >>     [<8000cfc0>] show_stack+0x94/0x12c
> >>     [<806e553c>] dump_stack+0x8c/0xd0
> >>     [<803c73c8>] do_sync_erase+0xf4/0x208
> >>     [<803c7694>] ubi_io_sync_erase+0x1b8/0x304
> >>     [<803cbc90>] ubi_early_get_peb+0x148/0x1dc
> >>     [<803ba930>] create_vtbl+0xb4/0x29c
> >>     [<803bafc8>] ubi_read_volume_table+0x27c/0xae4
> >>     [<803cc294>] ubi_attach+0x570/0x15dc
> >>     [<803bf2a0>] ubi_attach_mtd_dev+0x5b0/0xbec
> >>     [<808b0488>] ubi_init+0x1c0/0x274
> >>     [<800015f4>] do_one_initcall+0x50/0x1ac
> >>     [<80897e98>] kernel_init_freeable+0x184/0x26c
> >>     [<807035b4>] kernel_init+0x14/0x110
> >>     [<800071f8>] ret_from_kernel_thread+0x14/0x1c
> >>
> >> I tried booting and running this several times, I always get the same
> >> long hang and dump from USB/NAND. If I copy in the one linux-4.20
> >> file, drivers/staging/mt7621-pci/pci-mt7621.c, then the system
> >> boots, scans and finds PCI devices, and does not hang/dump on
> >> UBI/NAND flash setup.
> >
> > Can you try to read and set BIT(10) instead of write it directly?:
> >
> > Instead of:
> >
> > rt_sysc_w32(PERST_MODE_GPIO, MT7621_GPIO_MODE);
>
> Oh, yeah, that is definitely not going to work. There is a bunch of
> other GPIO control bits in there for other hardware blocks. Would
> explain the broken NAND flash behavior...

Yes, my bad here. Sometimes is better to go to sleep :)).

>
>
> > Do:
> >
> > u32 val = rt_sysc_r32(MT7621_GPIO_MODE);
> > val |= PERST_MODE_GPIO;
> > rt_sysc_w32(val, MT7621_GPIO_MODE);
>
> Much better result with that. Though ultimately it should clear
> bits 10 and 11 (both are PERST_MODE bits) and then OR in BIT(10).

Ok, so the following should do the trick:

rt_sysc_m32(PERST_MODE_MASK, PERST_MODE_GPIO, MT7621_GPIO_MODE);

with PERST_MODE_MASK defined as:

#define PERST_MODE_MASK         GENMASK(11, 10)

(patch attached with this changes)

It would be also good to know what happen if you comment the following lines:

pcie_write(pcie, 0xffffffff, RALINK_PCI_MEMBASE);
pcie_write(pcie, RALINK_PCI_IO_MAP_BASE, RALINK_PCI_IOBASE);

Are they really needed?

>
> Boot is successful and now shows:
>
> mt7621-pci-phy 1e149000.pcie-phy: Xtal is 40MHz
> mt7621-pci 1e140000.pcie: Port 454043648 N_FTS = 0
> mt7621-pci-phy 1e149000.pcie-phy: Xtal is 40MHz
> mt7621-pci 1e140000.pcie: Port 454043648 N_FTS = 1
> mt7621-pci-phy 1e14a000.pcie-phy: Xtal is 40MHz
> mt7621-pci 1e140000.pcie: Port 454043648 N_FTS = 2
> 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: PCIE0 enabled
> mt7621-pci 1e140000.pcie: PCI coherence region base: 0x60000000, mask/settings: 0xf0000002
> mt7621-pci 1e140000.pcie: PCI host bridge to bus 0000:00
> pci_bus 0000:00: root bus resource [io  0xffffffff]
> pci_bus 0000:00: root bus resource [mem 0x60000000-0x6fffffff]
> pci_bus 0000:00: root bus resource [bus 00-ff]
> pci 0000:00:00.0: bridge configuration invalid ([bus 00-00]), reconfiguring
> pci 0000:00:00.0: PCI bridge to [bus 01-ff]
> pci 0000:00:00.0: BAR 0: no space for [mem size 0x80000000]
> pci 0000:00:00.0: BAR 0: failed to assign [mem size 0x80000000]
> pci 0000:00:00.0: BAR 8: assigned [mem 0x60000000-0x601fffff]
> pci 0000:00:00.0: BAR 9: assigned [mem 0x60200000-0x602fffff pref]
> pci 0000:00:00.0: BAR 1: assigned [mem 0x60300000-0x6030ffff]
> pci 0000:00:00.0: BAR 7: no space for [io  size 0x1000]
> pci 0000:00:00.0: BAR 7: failed to assign [io  size 0x1000]
> pci 0000:01:00.0: BAR 0: assigned [mem 0x60000000-0x601fffff 64bit]
> pci 0000:01:00.0: BAR 6: assigned [mem 0x60200000-0x6020ffff pref]
> pci 0000:00:00.0: PCI bridge to [bus 01]
> pci 0000:00:00.0:   bridge window [mem 0x60000000-0x601fffff]
> pci 0000:00:00.0:   bridge window [mem 0x60200000-0x602fffff pref]
> pcieport 0000:00:00.0: of_irq_parse_pci: failed with rc=-22
> pcieport 0000:00:00.0: enabling device (0004 -> 0006)
>
>
> So that is really good. Still now just some problem with the IRQ.

No idea at all why irq is failing there. The driver code related with
irq is the same for 4.20.
Some debug traces would be useful.

>
> I also found that I could dump /sys/bus/pci/devices/0000:01:00.0/config
> and get a good dump from the command line:
>
> 00000000: 8c 16 3c 00 06 00 10 00 00 00 80 02 00 00 00 00     ..<.............
> 00000010: 04 00 00 60 00 00 00 00 00 00 00 00 00 00 00 00     ...`............
> 00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00     ................
> 00000030: 00 00 00 00 40 00 00 00 00 00 00 00 17 01 00 00     .... at ...........
> ...
>
> Also good.

Yeah, That looks good. Much  better than getting all F's like the other day.

>
>
> >> I'll try and dig into it some time today and get you some feedback.
>
> Sorry, I didn't get any more time to look at this today.
>

No problem at all.

>
> > No other changes with the previous one, just the order of where
> > interrupts bits are set up in
> > the same place of 4.20.
> >
> > Can you point me out to the link to your board of something to check
> > if I can acquire one and test
> > in my side?
>
> I am using a Digi/EX15:
> https://www.digi.com/products/networking/cellular-routers/enterprise/digi-ex15
>
> FWIW, I think we are close now.

Only one step more to get this properly working.

>
> Regards
> Greg

Best regards,
    Sergio Paracuellos
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-staging-mt7621-pci-use-perst-gpio-instead-of-builtin.patch
Type: text/x-patch
Size: 8761 bytes
Desc: not available
URL: <http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/attachments/20190603/006096df/attachment.bin>


More information about the devel mailing list