Messages in this thread | | | Date | Mon, 28 Mar 2016 15:06:53 -0700 | Subject | Re: [PATCH] i.MX6 PCIe: Fix imx6_pcie_deassert_core_reset() polarity | From | Tim Harvey <> |
| |
On Mon, Mar 28, 2016 at 2:30 PM, Fabio Estevam <festevam@gmail.com> wrote: > On Mon, Mar 28, 2016 at 5:42 PM, Tim Harvey <tharvey@gateworks.com> wrote: > >> Fabio, >> >> ok - I'll respond there as I agree with the patch but not the wording >> of the commit (It's Gateworks 'Ventana' using IMX6 not Laguna and we >> do define the polarity properly as active-low in Ventana dt's). It is >> the fact that the gpio polarity has the wrong logic level that breaks >> Ventana. > > Ok, I will change the wording in v2. > >> >> However, there seems to be another regression in 4.5 that's keeping >> PCI working for me and I'm still bisecting that (using 802.11n access >> points to test). Can you confirm that PCI works in v4.5 on IMX6 boards >> with only 5c5fb40de8f14391a1238db05cef88754faf9229 reverted? > > On imx6qdl-sabresd.dtsi the PCI reset gpio polarity is set to high, > which is not correct, so the Wifi card could be detected even with > 5c5fb40de8f. So two errors in sequence and PCI still works on this > board :-)
ouch - two wrongs did make a right!
It's not too easy to tell how many IMX6 boards incorrectly specify their reset-gpio polarity. I don't know what the best way to determine what boards use the IMX6 pcie host controller. Is there a dtc usage that will display the compiled dtb's then we grep out 'compatible = "fsl,imx6q-pcie"' to at least get the list of boards to inspect? I'm curious if its just one or two boards that incorrectly specify the polarity of their PCI reset.
> > I don't have access to the board at the moment, but the only test I > did was to see that the Wifi card got detected. I haven't really tried > to communicate via Wifi.
I figured out it was the change to enable CONFIG_PCI_MSI in v4.5 that is causing interrupts to fail for me.
Lucas, the case that is failing for me is when I have 4 miniPCI radios behind a PCIe->PCI bridge. In this case the radios get legacy INTA/B/C/D mapped to them correctly from what I can tell (GIC 123/122/121/120 swizzled appropriately), but those interrupts never fire. I don't think this case is necessarily a regression, I'm not clear that it has ever worked. In fact I can't seem to come up with a scenario where the MSI irq is firing either: IMX6->ath9k radio (no bridge) with MSI doesn't fire the PCI-MSI interrupt or the GPC 123 interrupt that gets mapped to it via the driver. Any ideas what can be going on here?
Regards,
Tim
| |