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

[Roberto Fichera <kernel@tekno-soft.it>]

On 03/29/2016 07:31 PM, Tim Harvey wrote:
> On Tue, Mar 29, 2016 at 9:44 AM, Roberto Fichera <kernel@tekno-soft.it> wrote:
>>>
>>> Roberto,
>>>
>>> What board/platform is this and what does /proc/interrupts look like?
>> It's a custom board
>>
>> root@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
>>
>>
>>> 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. 

Yep! That was the case

> 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).

GPC 123 is serving J2 and J1, and looks ok

root@voneus-janas-imx6q:~# cat /proc/interrupts
           CPU0       CPU1       CPU2       CPU3
 16:       7409      25043       2869      71444       GIC  29 Edge      twd
 17:          0          0          0          0       GPC  55 Level     i.MX Timer Tick
 22:        526          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:       8808          0          0          0       GIC 150 Level     2188000.ethernet
282:          0          0          0          0       GIC 151 Level     2188000.ethernet
283:       2529          0          0          0       GPC  25 Level     mmc0
284:         95          0          0          0       GPC  37 Level     21a4000.i2c
290:    2391578          0          0          0       GPC 123 Level     PCIe PME, b4xxp, 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:       1122       3838       2051       9631  Rescheduling interrupts
IPI3:         60         56         48         54  Function call interrupts
IPI4:          2          1          2          3  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


root@voneus-janas-imx6q:~# lspci -vv -s 02:
02:00.0 ISDN controller: Cologne Chip Designs GmbH ISDN network Controller [HFC-4S] (rev 01)
        Subsystem: Cologne Chip Designs GmbH HFC-4S [OpenVox B200P / B400P]
        Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Interrupt: pin A routed to IRQ 290
        Region 0: I/O ports at 1000 [size=8]
        Region 1: Memory at 01100000 (32-bit, non-prefetchable) [size=4K]
        Capabilities: [40] Power Management version 2
                Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-)
                Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
        Kernel driver in use: wcb4xxp
        Kernel modules: wcb4xxp

02:04.0 ISDN controller: Cologne Chip Designs GmbH ISDN network Controller [HFC-4S] (rev 01)
        Subsystem: Cologne Chip Designs GmbH HFC-4S [OpenVox B200P / B400P]
        Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Interrupt: pin A routed to IRQ 290
        Region 0: I/O ports at 1008 [size=8]
        Region 1: Memory at 01101000 (32-bit, non-prefetchable) [size=4K]
        Capabilities: [40] Power Management version 2
                Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-)
                Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
        Kernel driver in use: wcb4xxp
        Kernel modules: wcb4xxp


>
> 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

After crosschecking with our hardware designer the PCB IRQ mapping is the following:

J2 : IDSEL  A16: => Device 0 : socket INTA = XIO2001 INTA
J3 : IDSEL  A18: => Device 2 : socket INTA = XIO2001 INTA* **(This should be INTC)*         
J11: IDSEL A20: => Device 4 : socket INTA = XIO2001 INTA

The interrupt routing for J3 is wrong. The XIO2001 driver may expect Device 2 to interrupt on INTC - but it will
interrupt on INTA.

>
> 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).

Yep! I have read it

>
> Tim
>