[PATCH] i.MX6 PCIe: Fix imx6_pcie_deassert_core_reset() polarity

On Tue, Mar 29, 2016 at 9:44 AM, Roberto Fichera [off-list ref] wrote:

On 03/29/2016 06:40 PM, Tim Harvey wrote:

quoted

On Tue, Mar 29, 2016 at 9:13 AM, Roberto Fichera [off-list ref] wrote:

quoted

On 03/29/2016 05:10 PM, Tim Harvey wrote:

quoted

Arnd,

Right, on the IMX the MSI interrupt is GIC-120 which is also the
legacy INTD and I do see that if I happen to put a radio in a slot
where due to swizzling its pin1 becomes INTD (GIC-120) the interrupt
does fire and the device works. Any other slot using GIC-123 (INTA),
GIC-122 (INTB), or GIC-121 (INTC) never fires so its very possible
that something in the designware core is masking out the legacy irqs.
I would also think this was something IMX specific, but I really don't
see any codepaths in pci-imx6.c that would cause that: a driver
requesting a legacy PCI would get a GIC interrupt which is handled by
the IMX6 gpc interrupt controller.

Any dra7xxx, exynos, spear13xx, keystone, layerscape, hisi, qcom SoC
users of designware PCIe core out there that can verify PCI MSI and
legacy are both working at the same time?

Lucas is the expert here and I believe he has the documentation for
the designware core that Freescale doens't provide with the IMX6
documentation so hopefully he can provide some insight. He's the one
that has authored all the MSI support and has been using it.

I typically advise our users to 'not' enable MSI because
architecturally you can spread 4 distinct legacy irq's across CPU's
better than a single shared irq.

Don't know if I'm facing similar problem, however devices connected in miniPCI slot behind
a PCIe-to-PCI bridge (MSI is disabled) using INTA all is working ok, including shared IRQ.
In case of INTB will not work, and the GIC irq quite often get stuck.

Roberto,

What board/platform is this and what does /proc/interrupts look like?

It's a custom board

root at voneus-janas-imx6q:~# cat /proc/interrupts
           CPU0       CPU1       CPU2       CPU3
 16:        936        637       2057        938       GIC  29 Edge      twd
 17:          0          0          0          0       GPC  55 Level     i.MX Timer Tick
 22:        247          0          0          0       GPC  26 Level     2020000.serial
 34:          0          0          0          0  gpio-mxc   6 Edge      Factory Reset Button
267:          0          0          0          0       GPC  49 Level     imx_thermal
272:          0          0          0          0       GPC  19 Level     rtc alarm
278:          0          0          0          0       GPC   2 Level     sdma
281:        361          0          0          0       GIC 150 Level     2188000.ethernet
282:          0          0          0          0       GIC 151 Level     2188000.ethernet
283:       2882          0          0          0       GPC  25 Level     mmc0
284:         95          0          0          0       GPC  37 Level     21a4000.i2c
290:      36546          0          0          0       GPC 123 Level     PCIe PME, b4xxp
291:          2          0          0          0       GIC 137 Level     2101000.jr0
292:          0          0          0          0       GIC 138 Level     2102000.jr1
IPI0:          0          0          0          0  CPU wakeup interrupts
IPI1:          0          0          0          0  Timer broadcast interrupts
IPI2:       1642       1038       1626       1781  Rescheduling interrupts
IPI3:         95         95        122        119  Function call interrupts
IPI4:          3          0          2          0  Single function call interrupts
IPI5:          0          0          0          0  CPU stop interrupts
IPI6:          0          0          0          0  IRQ work interrupts
IPI7:          0          0          0          0  completion interrupts
Err:          0

quoted

This sounds like what would happen if the downstream interrupts on the
PCIe-to-PCI bridge are not mapped properly as was the case with a
board I support (in which case I had to work out a bootloader fixup
that placed a non-standard interrupt-map in the device-tree for the
bridge). What bridge are you using?

PCIe-to-PCI bridge is a Ti XIO2001 where we are using INTA/B only wired 1:1

Roberto,

That's right, we've talked about your bridge on IMX community.

I don't see anything in your proc/interrupts other than GPC 123 - you
probably only had one device populated when you did that. Put devices
in all for slots then show me 'cat /proc/interrupts' as well as 'lspci
-vv' (so that I can see what interrupt was given to pin1 and what
interrupt that maps to on the IMX6).

Check your XIO2001 routing and insure the following for proper IRQ mapping:
Slot12: IDSEL A28: socket INTA = XIO2001 INTA
Slot13: IDSEL A29: socket INTA = XIO2001 INTB
Slot14: IDSEL A30: socket INTA = XIO2001 INTC
Slot15: IDSEL A31: socket INTA = XIO2001 INTD

The relationship between slot number of IDSEL is based on the PCI
specification. The XIO2001 int mapping to socket mapping is based on
Table 2 in the XIO2001 implementation guide. In my case what the
hardware designer flipped the IDSEL mappings above such that slot12's
idsel was hooked to A31 (so it was really slot15) etc, which created a
non-standard mapping that required what ended up being a very time
consuming and difficult to figure out software fixup (to say the
least).

Tim