[PATCH] i.MX6 PCIe: Fix imx6_pcie_deassert_core_reset() polarity
Tim Harvey
tharvey at gateworks.com
Mon Mar 28 15:06:53 PDT 2016
On Mon, Mar 28, 2016 at 2:30 PM, Fabio Estevam <festevam at gmail.com> wrote:
> On Mon, Mar 28, 2016 at 5:42 PM, Tim Harvey <tharvey at 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
More information about the linux-arm-kernel
mailing list