[PATCH] i.MX6 PCIe: Fix imx6_pcie_deassert_core_reset() polarity
From: l.stach@pengutronix.de (Lucas Stach)
Date: 2016-03-29 08:56:08
Also in:
linux-pci, lkml
Am Montag, den 28.03.2016, 15:06 -0700 schrieb Tim Harvey:
On Mon, Mar 28, 2016 at 2:30 PM, Fabio Estevam [off-list ref] wrote:quoted
On Mon, Mar 28, 2016 at 5:42 PM, Tim Harvey [off-list ref] wrote:quoted
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.quoted
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 would suspect that most boards specify the reset polarity the wrong way around. Fixing this without breaking DT stability is hard. OTOH we could just argue that the system description in DT is wrong and needs to be fixed.
quoted
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.
Is this working with v4.4 and PCI_MSI enabled? I'm sure I've tested MSI IRQs before enabling them in the defconfig and they have been working for me for a long time before that. Tested with i210 on Gateworks Ventana.
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?
Please test if MSI IRQs work with v4.4. I'll take a look at this later today. Regards, Lucas