Am Montag, den 28.03.2016, 15:06 -0700 schrieb Tim Harvey: > On Mon, Mar 28, 2016 at 2:30 PM, Fabio Estevam <festevam@xxxxxxxxx> wrote: > > On Mon, Mar 28, 2016 at 5:42 PM, Tim Harvey <tharvey@xxxxxxxxxxxxx> 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 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. > > > > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
