iMX6q PCIe phy link never came up on kernel v4.4.x

Hi There,

Working on a custom iMX6q board I'm getting a PCIe phy link never came up, even if uboot seems detecting everything ok. My DTS is enabling PCIe with

&pcie {
    pinctrl-names = "default";
    pinctrl-0 = <&pinctrl_pcie_reset>;
    reset-gpio = <&gpio7 12 0>;
    status = "okay";
};

The PCIe is connected to a PCIe-to-PCI TI XIO2001. The XIO2001 power is controlled by GPIO_9 and the corresponding fixed regulator is set as

		reg_pcie: regulator@4 {
			compatible = "regulator-fixed";
			reg = <4>;
			pinctrl-names = "default";
			pinctrl-0 = <&pinctrl_pcie_reg>;
			regulator-name = "MPCIE_3V3";
			regulator-min-microvolt = <3300000>;
			regulator-max-microvolt = <3300000>;
			gpio = <&gpio1 9 0>;
			regulator-always-on;
			enable-active-high;
		};

so I'd like to know if there is any other special setup to do in order to get it to work on a v4.4.x kernel. Or anyway how to debug it.

Any suggestion?

Thanks in advance,
Roberto Fichera.

U-Boot 2014.04-imx_v2014.04_3.14.38_6qp_beta+g6e9282c (Feb 15 2016 - 10:02:31)

CPU:   Freescale i.MX6Q rev1.5 at 792 MHz
CPU:   Temperature 35 C, calibration data: 0x5664d569
Reset cause: POR
Board: Janas iMX6Q (ID:e315c064140749d4)
I2C:   ready
DRAM:  2 GiB
MMC:   FSL_SDHC: 0, FSL_SDHC: 1

*** Warning - bad CRC, using default environment

  00:01.0     - 16c3:abcd - Bridge device
   01:00.0    - 104c:8240 - Bridge device
    02:04.0   - 1397:08b4 - Network controller
In:    serial
Out:   serial
Err:   serial

Found PFUZE100! deviceid=10,revid=21
mmc1(part 0) is current device
Net: FEC [PRIME]
Warning: failed to set MAC address

Normal Boot
....
....

[    0.236141] PCI host bridge /soc/pcie@0x01000000 ranges:
[    0.236162]   No bus range found for /soc/pcie@0x01000000, using [bus 00-ff]
[    0.236213]   err 0x01f00000..0x01f7ffff -> 0x01f00000
[    0.236250]    IO 0x01f80000..0x01f8ffff -> 0x00000000
[    0.236330]   MEM 0x01000000..0x01efffff -> 0x01000000
-->>> [    0.546690] imx6q-pcie 1ffc000.pcie: phy link never came up
[    0.547263] imx6q-pcie 1ffc000.pcie: PCI host bridge to bus 0000:00
[    0.547287] pci_bus 0000:00: root bus resource [bus 00-ff]
[    0.547304] pci_bus 0000:00: root bus resource [??? 0x01f00000-0x01f7ffff flags 0x0]
[    0.547321] pci_bus 0000:00: root bus resource [io  0x0000-0xffff]
[    0.547335] pci_bus 0000:00: root bus resource [mem 0x01000000-0x01efffff]
[    0.548608] PCI: bus0: Fast back to back transfers disabled
[    0.548950] PCI: bus1: Fast back to back transfers enabled
[    0.549107] pci 0000:00:00.0: BAR 0: assigned [mem 0x01000000-0x010fffff]
[    0.549137] pci 0000:00:00.0: BAR 6: assigned [mem 0x01100000-0x0110ffff pref]
[    0.549159] pci 0000:00:00.0: PCI bridge to [bus 01]
[    0.549945] pcieport 0000:00:00.0: Signaling PME through PCIe PME interrupt

...

--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

On 03/01/2016 07:47 PM, Roberto Fichera wrote:

Sorry guy if I push a little bit about this, I've added some debugging code regarding my issue:

[    0.557268] imx6q-pcie 1ffc000.pcie: phy link never came up
[    0.557290] imx6q-pcie 1ffc000.pcie: LTSSM current state: 0x3 (S_POLL_COMPLIANCE)
[    0.557304] imx6q-pcie 1ffc000.pcie: PIPE transmit K indication: 1
[    0.557318] imx6q-pcie 1ffc000.pcie: PIPE Transmit data: 0x4abc
[    0.557332] imx6q-pcie 1ffc000.pcie: Receiver is receiving logical idle: no
[    0.557345] imx6q-pcie 1ffc000.pcie: Second symbol is also idle (16-bit PHY interface only): no
[    0.557360] imx6q-pcie 1ffc000.pcie: Currently receiving k237 (PAD) in place of link number: no
[    0.557372] imx6q-pcie 1ffc000.pcie: Currently receiving k237 (PAD) in place of lane number: no
[    0.557385] imx6q-pcie 1ffc000.pcie: Link control bits advertised by link partner: 0xa
[    0.557398] imx6q-pcie 1ffc000.pcie: Receiver detected lane reversal: no
[    0.557410] imx6q-pcie 1ffc000.pcie: TS2 training sequence received: no
[    0.557422] imx6q-pcie 1ffc000.pcie: TS1 training sequence received: no
[    0.557434] imx6q-pcie 1ffc000.pcie: Receiver reports skip reception: no
[    0.557446] imx6q-pcie 1ffc000.pcie: LTSSM reports PHY link up: no
[    0.557460] imx6q-pcie 1ffc000.pcie: A skip ordered set has been transmitted: no
[    0.557474] imx6q-pcie 1ffc000.pcie: Link number advertised/confirmed by link partner: 68
[    0.557487] imx6q-pcie 1ffc000.pcie: Application request to initiate training reset: no
[    0.557500] imx6q-pcie 1ffc000.pcie: PIPE transmit compliance request: no
[    0.557512] imx6q-pcie 1ffc000.pcie: PIPE transmit electrical idle request: no
[    0.557524] imx6q-pcie 1ffc000.pcie: PIPE receiver detect/loopback request: no
[    0.557536] imx6q-pcie 1ffc000.pcie: LTSSM-negotiated link reset: yes
[    0.557547] imx6q-pcie 1ffc000.pcie: LTSSM testing for polarity reversal: no
[    0.557559] imx6q-pcie 1ffc000.pcie: LTSSM performing link training: no
[    0.557572] imx6q-pcie 1ffc000.pcie: LTSSM in DISABLE state; link inoperable: no
[    0.557583] imx6q-pcie 1ffc000.pcie: Scrambling disabled for the link: no
[    0.558156] imx6q-pcie 1ffc000.pcie: PCI host bridge to bus 0000:00
[    0.558179] pci_bus 0000:00: root bus resource [bus 00-ff]
[    0.558197] pci_bus 0000:00: root bus resource [??? 0x01f00000-0x01f7ffff flags 0x0]
[    0.558212] pci_bus 0000:00: root bus resource [io  0x0000-0xffff]
[    0.558226] pci_bus 0000:00: root bus resource [mem 0x01000000-0x01efffff]
[    0.558346] pci 0000:00:00.0: [16c3:abcd] type 01 class 0x060400
[    0.558468] pci 0000:00:00.0: reg 0x10: [mem 0x00000000-0x000fffff]
[    0.558510] pci 0000:00:00.0: reg 0x38: [mem 0x00000000-0x0000ffff pref]
[    0.558708] pci 0000:00:00.0: supports D1
[    0.558727] pci 0000:00:00.0: PME# supported from D0 D1 D3hot D3cold
[    0.559495] PCI: bus0: Fast back to back transfers disabled
[    0.559834] PCI: bus1: Fast back to back transfers enabled
[    0.559997] pci 0000:00:00.0: BAR 0: assigned [mem 0x01000000-0x010fffff]
[    0.560025] pci 0000:00:00.0: BAR 6: assigned [mem 0x01100000-0x0110ffff pref]
[    0.560047] pci 0000:00:00.0: PCI bridge to [bus 01]
[    0.560812] pcieport 0000:00:00.0: Signaling PME through PCIe PME interrupt
[    0.560837] pcie_pme 0000:00:00.0:pcie01: service driver pcie_pme loaded

Any idea what's going on?

Thanks in advance,
Roberto Fichera.

Quoted 78 lines

Hi There,

Working on a custom iMX6q board I'm getting a PCIe phy link never came up, even if uboot seems detecting everything ok. My DTS is enabling PCIe with

&pcie {
    pinctrl-names = "default";
    pinctrl-0 = <&pinctrl_pcie_reset>;
    reset-gpio = <&gpio7 12 0>;
    status = "okay";
};

The PCIe is connected to a PCIe-to-PCI TI XIO2001. The XIO2001 power is controlled by GPIO_9 and the corresponding fixed regulator is set as

		reg_pcie: regulator@4 {
			compatible = "regulator-fixed";
			reg = <4>;
			pinctrl-names = "default";
			pinctrl-0 = <&pinctrl_pcie_reg>;
			regulator-name = "MPCIE_3V3";
			regulator-min-microvolt = <3300000>;
			regulator-max-microvolt = <3300000>;
			gpio = <&gpio1 9 0>;
			regulator-always-on;
			enable-active-high;
		};

so I'd like to know if there is any other special setup to do in order to get it to work on a v4.4.x kernel. Or anyway how to debug it.

Any suggestion?

Thanks in advance,
Roberto Fichera.

U-Boot 2014.04-imx_v2014.04_3.14.38_6qp_beta+g6e9282c (Feb 15 2016 - 10:02:31)

CPU:   Freescale i.MX6Q rev1.5 at 792 MHz
CPU:   Temperature 35 C, calibration data: 0x5664d569
Reset cause: POR
Board: Janas iMX6Q (ID:e315c064140749d4)
I2C:   ready
DRAM:  2 GiB
MMC:   FSL_SDHC: 0, FSL_SDHC: 1

*** Warning - bad CRC, using default environment

  00:01.0     - 16c3:abcd - Bridge device
   01:00.0    - 104c:8240 - Bridge device
    02:04.0   - 1397:08b4 - Network controller
In:    serial
Out:   serial
Err:   serial

Found PFUZE100! deviceid=10,revid=21
mmc1(part 0) is current device
Net: FEC [PRIME]
Warning: failed to set MAC address

Normal Boot
....
....

[    0.236141] PCI host bridge /soc/pcie@0x01000000 ranges:
[    0.236162]   No bus range found for /soc/pcie@0x01000000, using [bus 00-ff]
[    0.236213]   err 0x01f00000..0x01f7ffff -> 0x01f00000
[    0.236250]    IO 0x01f80000..0x01f8ffff -> 0x00000000
[    0.236330]   MEM 0x01000000..0x01efffff -> 0x01000000
-->>> [    0.546690] imx6q-pcie 1ffc000.pcie: phy link never came up
[    0.547263] imx6q-pcie 1ffc000.pcie: PCI host bridge to bus 0000:00
[    0.547287] pci_bus 0000:00: root bus resource [bus 00-ff]
[    0.547304] pci_bus 0000:00: root bus resource [??? 0x01f00000-0x01f7ffff flags 0x0]
[    0.547321] pci_bus 0000:00: root bus resource [io  0x0000-0xffff]
[    0.547335] pci_bus 0000:00: root bus resource [mem 0x01000000-0x01efffff]
[    0.548608] PCI: bus0: Fast back to back transfers disabled
[    0.548950] PCI: bus1: Fast back to back transfers enabled
[    0.549107] pci 0000:00:00.0: BAR 0: assigned [mem 0x01000000-0x010fffff]
[    0.549137] pci 0000:00:00.0: BAR 6: assigned [mem 0x01100000-0x0110ffff pref]
[    0.549159] pci 0000:00:00.0: PCI bridge to [bus 01]
[    0.549945] pcieport 0000:00:00.0: Signaling PME through PCIe PME interrupt

Quoted 7 lines

...

--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

-----Original Message-----
From: Bjorn Helgaas [mailto:[email protected]]
Sent: Thursday, March 03, 2016 3:57 AM
To: Roberto Fichera
Cc: [email protected]; Richard Zhu; Lucas Stach
Subject: Re: iMX6q PCIe phy link never came up on kernel v4.4.x

[+cc Richard, Lucas]

Quoted 3 lines · Roberto Fichera

On 03/01/2016 07:47 PM, Roberto Fichera wrote:

Sorry guy if I push a little bit about this, I've added some debugging code

regarding my issue:

Quoted 3 lines

[    0.557268] imx6q-pcie 1ffc000.pcie: phy link never came up
[    0.557290] imx6q-pcie 1ffc000.pcie: LTSSM current state: 0x3

(S_POLL_COMPLIANCE)

Quoted 4 lines

[    0.557304] imx6q-pcie 1ffc000.pcie: PIPE transmit K indication: 1
[    0.557318] imx6q-pcie 1ffc000.pcie: PIPE Transmit data: 0x4abc
[    0.557332] imx6q-pcie 1ffc000.pcie: Receiver is receiving logical idle: no
[    0.557345] imx6q-pcie 1ffc000.pcie: Second symbol is also idle (16-bit PHY

interface only): no

Quoted 1 line

[    0.557360] imx6q-pcie 1ffc000.pcie: Currently receiving k237 (PAD) in

place of link number: no

Quoted 1 line

[    0.557372] imx6q-pcie 1ffc000.pcie: Currently receiving k237 (PAD) in

place of lane number: no

Quoted 1 line

[    0.557385] imx6q-pcie 1ffc000.pcie: Link control bits advertised by link

partner: 0xa

Quoted 6 lines

[    0.557398] imx6q-pcie 1ffc000.pcie: Receiver detected lane reversal: no
[    0.557410] imx6q-pcie 1ffc000.pcie: TS2 training sequence received: no
[    0.557422] imx6q-pcie 1ffc000.pcie: TS1 training sequence received: no
[    0.557434] imx6q-pcie 1ffc000.pcie: Receiver reports skip reception: no
[    0.557446] imx6q-pcie 1ffc000.pcie: LTSSM reports PHY link up: no
[    0.557460] imx6q-pcie 1ffc000.pcie: A skip ordered set has been

transmitted: no

Quoted 1 line

[    0.557474] imx6q-pcie 1ffc000.pcie: Link number advertised/confirmed by

link partner: 68

Quoted 1 line

[    0.557487] imx6q-pcie 1ffc000.pcie: Application request to initiate training

reset: no

Quoted 2 lines

[    0.557500] imx6q-pcie 1ffc000.pcie: PIPE transmit compliance request: no
[    0.557512] imx6q-pcie 1ffc000.pcie: PIPE transmit electrical idle request:

no

Quoted 1 line

[    0.557524] imx6q-pcie 1ffc000.pcie: PIPE receiver detect/loopback request:

no

Quoted 4 lines

[    0.557536] imx6q-pcie 1ffc000.pcie: LTSSM-negotiated link reset: yes
[    0.557547] imx6q-pcie 1ffc000.pcie: LTSSM testing for polarity reversal: no
[    0.557559] imx6q-pcie 1ffc000.pcie: LTSSM performing link training: no
[    0.557572] imx6q-pcie 1ffc000.pcie: LTSSM in DISABLE state; link

inoperable: no

Quoted 4 lines

[    0.557583] imx6q-pcie 1ffc000.pcie: Scrambling disabled for the link: no
[    0.558156] imx6q-pcie 1ffc000.pcie: PCI host bridge to bus 0000:00
[    0.558179] pci_bus 0000:00: root bus resource [bus 00-ff]
[    0.558197] pci_bus 0000:00: root bus resource [??? 0x01f00000-0x01f7ffff

flags 0x0]

Quoted 2 lines

[    0.558212] pci_bus 0000:00: root bus resource [io  0x0000-0xffff]
[    0.558226] pci_bus 0000:00: root bus resource [mem 0x01000000-

0x01efffff]

Quoted 9 lines

[    0.558346] pci 0000:00:00.0: [16c3:abcd] type 01 class 0x060400
[    0.558468] pci 0000:00:00.0: reg 0x10: [mem 0x00000000-0x000fffff]
[    0.558510] pci 0000:00:00.0: reg 0x38: [mem 0x00000000-0x0000ffff pref]
[    0.558708] pci 0000:00:00.0: supports D1
[    0.558727] pci 0000:00:00.0: PME# supported from D0 D1 D3hot D3cold
[    0.559495] PCI: bus0: Fast back to back transfers disabled
[    0.559834] PCI: bus1: Fast back to back transfers enabled
[    0.559997] pci 0000:00:00.0: BAR 0: assigned [mem 0x01000000-0x010fffff]
[    0.560025] pci 0000:00:00.0: BAR 6: assigned [mem 0x01100000-0x0110ffff

pref]

Quoted 2 lines

[    0.560047] pci 0000:00:00.0: PCI bridge to [bus 01]
[    0.560812] pcieport 0000:00:00.0: Signaling PME through PCIe PME

interrupt

Quoted 37 lines

[    0.560837] pcie_pme 0000:00:00.0:pcie01: service driver pcie_pme loaded

Any idea what's going on?

Thanks in advance,
Roberto Fichera.

Quoted 30 lines

Hi There,

Working on a custom iMX6q board I'm getting a PCIe phy link never came up, even if uboot seems detecting everything ok. My DTS is enabling PCIe with

&pcie {
    pinctrl-names = "default";
    pinctrl-0 = <&pinctrl_pcie_reset>;
    reset-gpio = <&gpio7 12 0>;
    status = "okay";
};

The PCIe is connected to a PCIe-to-PCI TI XIO2001. The XIO2001 power is controlled by GPIO_9 and the corresponding fixed regulator is set as

		reg_pcie: regulator@4 {
			compatible = "regulator-fixed";
			reg = <4>;
			pinctrl-names = "default";
			pinctrl-0 = <&pinctrl_pcie_reg>;
			regulator-name = "MPCIE_3V3";
			regulator-min-microvolt = <3300000>;
			regulator-max-microvolt = <3300000>;
			gpio = <&gpio1 9 0>;
			regulator-always-on;
			enable-active-high;
		};

Quoted 1 line

Quoted 1 line

so I'd like to know if there is any other special setup to do in order to get it

to work on a v4.4.x kernel.

Quoted 4 lines

Quoted 4 lines

Or anyway how to debug it.

Any suggestion?

Quoted 25 lines

Quoted 25 lines

Thanks in advance,
Roberto Fichera.

U-Boot 2014.04-imx_v2014.04_3.14.38_6qp_beta+g6e9282c (Feb 15 2016 - 10:02:31)

CPU:   Freescale i.MX6Q rev1.5 at 792 MHz
CPU:   Temperature 35 C, calibration data: 0x5664d569
Reset cause: POR
Board: Janas iMX6Q (ID:e315c064140749d4)
I2C:   ready
DRAM:  2 GiB
MMC:   FSL_SDHC: 0, FSL_SDHC: 1

*** Warning - bad CRC, using default environment

  00:01.0     - 16c3:abcd - Bridge device
   01:00.0    - 104c:8240 - Bridge device
    02:04.0   - 1397:08b4 - Network controller
In:    serial
Out:   serial
Err:   serial

Found PFUZE100! deviceid=10,revid=21 mmc1(part 0) is current device
Net: FEC [PRIME]
Warning: failed to set MAC address

Quoted 5 lines

Quoted 5 lines

Normal Boot
....
....

[    0.236141] PCI host bridge /soc/pcie@0x01000000 ranges:
[    0.236162]   No bus range found for /soc/pcie@0x01000000, using [bus

00-ff]

Quoted 7 lines

Quoted 7 lines

[    0.236213]   err 0x01f00000..0x01f7ffff -> 0x01f00000
[    0.236250]    IO 0x01f80000..0x01f8ffff -> 0x00000000
[    0.236330]   MEM 0x01000000..0x01efffff -> 0x01000000
-->>> [    0.546690] imx6q-pcie 1ffc000.pcie: phy link never came up
[    0.547263] imx6q-pcie 1ffc000.pcie: PCI host bridge to bus 0000:00
[    0.547287] pci_bus 0000:00: root bus resource [bus 00-ff]
[    0.547304] pci_bus 0000:00: root bus resource [??? 0x01f00000-

0x01f7ffff flags 0x0]

Quoted 2 lines

Quoted 2 lines

[    0.547321] pci_bus 0000:00: root bus resource [io  0x0000-0xffff]
[    0.547335] pci_bus 0000:00: root bus resource [mem 0x01000000-

0x01efffff]

Quoted 3 lines

Quoted 3 lines

[    0.548608] PCI: bus0: Fast back to back transfers disabled
[    0.548950] PCI: bus1: Fast back to back transfers enabled
[    0.549107] pci 0000:00:00.0: BAR 0: assigned [mem 0x01000000-

0x010fffff]

Quoted 1 line

Quoted 1 line

[    0.549137] pci 0000:00:00.0: BAR 6: assigned [mem 0x01100000-

0x0110ffff pref]

Quoted 2 lines

Quoted 2 lines

[    0.549159] pci 0000:00:00.0: PCI bridge to [bus 01]
[    0.549945] pcieport 0000:00:00.0: Signaling PME through PCIe PME

interrupt

Quoted 12 lines

Quoted 7 lines

...

--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

Quoted 108 lines

-----Original Message-----
From: Bjorn Helgaas [mailto:[email protected]]
Sent: Thursday, March 03, 2016 3:57 AM
To: Roberto Fichera
Cc: [email protected]; Richard Zhu; Lucas Stach
Subject: Re: iMX6q PCIe phy link never came up on kernel v4.4.x

[+cc Richard, Lucas]

Quoted 3 lines · Roberto Fichera

On 03/01/2016 07:47 PM, Roberto Fichera wrote:

Sorry guy if I push a little bit about this, I've added some debugging code

regarding my issue:

Quoted 2 lines

[    0.557268] imx6q-pcie 1ffc000.pcie: phy link never came up
[    0.557290] imx6q-pcie 1ffc000.pcie: LTSSM current state: 0x3

(S_POLL_COMPLIANCE)

Quoted 4 lines

[    0.557304] imx6q-pcie 1ffc000.pcie: PIPE transmit K indication: 1
[    0.557318] imx6q-pcie 1ffc000.pcie: PIPE Transmit data: 0x4abc
[    0.557332] imx6q-pcie 1ffc000.pcie: Receiver is receiving logical idle: no
[    0.557345] imx6q-pcie 1ffc000.pcie: Second symbol is also idle (16-bit PHY

interface only): no

Quoted 1 line

[    0.557360] imx6q-pcie 1ffc000.pcie: Currently receiving k237 (PAD) in

place of link number: no

Quoted 1 line

[    0.557372] imx6q-pcie 1ffc000.pcie: Currently receiving k237 (PAD) in

place of lane number: no

Quoted 1 line

[    0.557385] imx6q-pcie 1ffc000.pcie: Link control bits advertised by link

partner: 0xa

Quoted 6 lines

[    0.557398] imx6q-pcie 1ffc000.pcie: Receiver detected lane reversal: no
[    0.557410] imx6q-pcie 1ffc000.pcie: TS2 training sequence received: no
[    0.557422] imx6q-pcie 1ffc000.pcie: TS1 training sequence received: no
[    0.557434] imx6q-pcie 1ffc000.pcie: Receiver reports skip reception: no
[    0.557446] imx6q-pcie 1ffc000.pcie: LTSSM reports PHY link up: no
[    0.557460] imx6q-pcie 1ffc000.pcie: A skip ordered set has been

transmitted: no

Quoted 1 line

[    0.557474] imx6q-pcie 1ffc000.pcie: Link number advertised/confirmed by

link partner: 68

Quoted 1 line

[    0.557487] imx6q-pcie 1ffc000.pcie: Application request to initiate training

reset: no

Quoted 2 lines

[    0.557500] imx6q-pcie 1ffc000.pcie: PIPE transmit compliance request: no
[    0.557512] imx6q-pcie 1ffc000.pcie: PIPE transmit electrical idle request:

no

Quoted 1 line

[    0.557524] imx6q-pcie 1ffc000.pcie: PIPE receiver detect/loopback request:

no

Quoted 4 lines

[    0.557536] imx6q-pcie 1ffc000.pcie: LTSSM-negotiated link reset: yes
[    0.557547] imx6q-pcie 1ffc000.pcie: LTSSM testing for polarity reversal: no
[    0.557559] imx6q-pcie 1ffc000.pcie: LTSSM performing link training: no
[    0.557572] imx6q-pcie 1ffc000.pcie: LTSSM in DISABLE state; link

inoperable: no

Quoted 4 lines

[    0.557583] imx6q-pcie 1ffc000.pcie: Scrambling disabled for the link: no
[    0.558156] imx6q-pcie 1ffc000.pcie: PCI host bridge to bus 0000:00
[    0.558179] pci_bus 0000:00: root bus resource [bus 00-ff]
[    0.558197] pci_bus 0000:00: root bus resource [??? 0x01f00000-0x01f7ffff

flags 0x0]

Quoted 2 lines

[    0.558212] pci_bus 0000:00: root bus resource [io  0x0000-0xffff]
[    0.558226] pci_bus 0000:00: root bus resource [mem 0x01000000-

0x01efffff]

Quoted 9 lines

[    0.558346] pci 0000:00:00.0: [16c3:abcd] type 01 class 0x060400
[    0.558468] pci 0000:00:00.0: reg 0x10: [mem 0x00000000-0x000fffff]
[    0.558510] pci 0000:00:00.0: reg 0x38: [mem 0x00000000-0x0000ffff pref]
[    0.558708] pci 0000:00:00.0: supports D1
[    0.558727] pci 0000:00:00.0: PME# supported from D0 D1 D3hot D3cold
[    0.559495] PCI: bus0: Fast back to back transfers disabled
[    0.559834] PCI: bus1: Fast back to back transfers enabled
[    0.559997] pci 0000:00:00.0: BAR 0: assigned [mem 0x01000000-0x010fffff]
[    0.560025] pci 0000:00:00.0: BAR 6: assigned [mem 0x01100000-0x0110ffff

pref]

Quoted 2 lines

[    0.560047] pci 0000:00:00.0: PCI bridge to [bus 01]
[    0.560812] pcieport 0000:00:00.0: Signaling PME through PCIe PME

interrupt

Quoted 38 lines

[    0.560837] pcie_pme 0000:00:00.0:pcie01: service driver pcie_pme loaded

Any idea what's going on?

Thanks in advance,
Roberto Fichera.

Quoted 31 lines

Hi There,

Working on a custom iMX6q board I'm getting a PCIe phy link never came up, even if uboot seems detecting everything ok. My DTS is enabling PCIe with

&pcie {
    pinctrl-names = "default";
    pinctrl-0 = <&pinctrl_pcie_reset>;
    reset-gpio = <&gpio7 12 0>;
    status = "okay";
};

The PCIe is connected to a PCIe-to-PCI TI XIO2001. The XIO2001 power is controlled by GPIO_9 and the corresponding fixed regulator is set as

		reg_pcie: regulator@4 {
			compatible = "regulator-fixed";
			reg = <4>;
			pinctrl-names = "default";
			pinctrl-0 = <&pinctrl_pcie_reg>;
			regulator-name = "MPCIE_3V3";
			regulator-min-microvolt = <3300000>;
			regulator-max-microvolt = <3300000>;
			gpio = <&gpio1 9 0>;
			regulator-always-on;
			enable-active-high;
		};

so I'd like to know if there is any other special setup to do in order to get it

Quoted 5 lines

to work on a v4.4.x kernel.

Quoted 4 lines

Quoted 4 lines

Or anyway how to debug it.

Any suggestion?

[Zhu hongxing] It seems that the link down is caused by the different initialization procedure. Can you take a try by the previouse kernel version?
Or, you can dump and compare the register values just before the LTSSM_ENABLE is asserted between Linux and uboot.

Quoted 45 lines

Quoted 25 lines

Quoted 25 lines

Thanks in advance,
Roberto Fichera.

U-Boot 2014.04-imx_v2014.04_3.14.38_6qp_beta+g6e9282c (Feb 15 2016 - 10:02:31)

CPU:   Freescale i.MX6Q rev1.5 at 792 MHz
CPU:   Temperature 35 C, calibration data: 0x5664d569
Reset cause: POR
Board: Janas iMX6Q (ID:e315c064140749d4)
I2C:   ready
DRAM:  2 GiB
MMC:   FSL_SDHC: 0, FSL_SDHC: 1

*** Warning - bad CRC, using default environment

  00:01.0     - 16c3:abcd - Bridge device
   01:00.0    - 104c:8240 - Bridge device
    02:04.0   - 1397:08b4 - Network controller
In:    serial
Out:   serial
Err:   serial

Found PFUZE100! deviceid=10,revid=21 mmc1(part 0) is current device
Net: FEC [PRIME]
Warning: failed to set MAC address

Quoted 5 lines

Quoted 5 lines

Normal Boot
....
....

[    0.236141] PCI host bridge /soc/pcie@0x01000000 ranges:
[    0.236162]   No bus range found for /soc/pcie@0x01000000, using [bus

00-ff]

Quoted 7 lines

Quoted 7 lines

[    0.236213]   err 0x01f00000..0x01f7ffff -> 0x01f00000
[    0.236250]    IO 0x01f80000..0x01f8ffff -> 0x00000000
[    0.236330]   MEM 0x01000000..0x01efffff -> 0x01000000
-->>> [    0.546690] imx6q-pcie 1ffc000.pcie: phy link never came up
[    0.547263] imx6q-pcie 1ffc000.pcie: PCI host bridge to bus 0000:00
[    0.547287] pci_bus 0000:00: root bus resource [bus 00-ff]
[    0.547304] pci_bus 0000:00: root bus resource [??? 0x01f00000-

0x01f7ffff flags 0x0]

Quoted 2 lines

Quoted 2 lines

[    0.547321] pci_bus 0000:00: root bus resource [io  0x0000-0xffff]
[    0.547335] pci_bus 0000:00: root bus resource [mem 0x01000000-

0x01efffff]

Quoted 3 lines

Quoted 3 lines

[    0.548608] PCI: bus0: Fast back to back transfers disabled
[    0.548950] PCI: bus1: Fast back to back transfers enabled
[    0.549107] pci 0000:00:00.0: BAR 0: assigned [mem 0x01000000-

Quoted 17 lines

0x010fffff]

Quoted 1 line

Quoted 1 line

[    0.549137] pci 0000:00:00.0: BAR 6: assigned [mem 0x01100000-

0x0110ffff pref]

Quoted 2 lines

Quoted 2 lines

[    0.549159] pci 0000:00:00.0: PCI bridge to [bus 01]
[    0.549945] pcieport 0000:00:00.0: Signaling PME through PCIe PME

interrupt

Quoted 11 lines

Quoted 7 lines

...

--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

-----Original Message-----
From: Roberto Fichera [mailto:[email protected]]
Sent: Thursday, March 03, 2016 5:30 PM
To: Richard Zhu; Bjorn Helgaas
Cc: [email protected]; Richard Zhu; Lucas Stach
Subject: Re: iMX6q PCIe phy link never came up on kernel v4.4.x

On 03/03/2016 10:15 AM, Richard Zhu wrote:

Hi Richard,

Quoted 14 lines

Quoted 14 lines

-----Original Message-----
From: Bjorn Helgaas [mailto:[email protected]]
Sent: Thursday, March 03, 2016 3:57 AM
To: Roberto Fichera
Cc: [email protected]; Richard Zhu; Lucas Stach
Subject: Re: iMX6q PCIe phy link never came up on kernel v4.4.x

[+cc Richard, Lucas]

Quoted 4 lines · Roberto Fichera

On 03/01/2016 07:47 PM, Roberto Fichera wrote:

Sorry guy if I push a little bit about this, I've added some debugging code

Quoted 8 lines

Quoted 8 lines

regarding my issue:

Quoted 2 lines

[    0.557268] imx6q-pcie 1ffc000.pcie: phy link never came up
[    0.557290] imx6q-pcie 1ffc000.pcie: LTSSM current state: 0x3

(S_POLL_COMPLIANCE)

Quoted 4 lines

[    0.557304] imx6q-pcie 1ffc000.pcie: PIPE transmit K indication: 1
[    0.557318] imx6q-pcie 1ffc000.pcie: PIPE Transmit data: 0x4abc
[    0.557332] imx6q-pcie 1ffc000.pcie: Receiver is receiving logical idle: no
[    0.557345] imx6q-pcie 1ffc000.pcie: Second symbol is also idle (16-bit

PHY

Quoted 7 lines

Quoted 7 lines

interface only): no

Quoted 1 line

[    0.557360] imx6q-pcie 1ffc000.pcie: Currently receiving k237 (PAD) in

place of link number: no

Quoted 1 line

[    0.557372] imx6q-pcie 1ffc000.pcie: Currently receiving k237 (PAD) in

place of lane number: no

Quoted 1 line

[    0.557385] imx6q-pcie 1ffc000.pcie: Link control bits advertised by link

partner: 0xa

Quoted 8 lines

Quoted 8 lines

Quoted 6 lines

[    0.557398] imx6q-pcie 1ffc000.pcie: Receiver detected lane reversal: no
[    0.557410] imx6q-pcie 1ffc000.pcie: TS2 training sequence received: no
[    0.557422] imx6q-pcie 1ffc000.pcie: TS1 training sequence received: no
[    0.557434] imx6q-pcie 1ffc000.pcie: Receiver reports skip reception: no
[    0.557446] imx6q-pcie 1ffc000.pcie: LTSSM reports PHY link up: no
[    0.557460] imx6q-pcie 1ffc000.pcie: A skip ordered set has been

transmitted: no

Quoted 1 line

[    0.557474] imx6q-pcie 1ffc000.pcie: Link number advertised/confirmed

by

Quoted 2 lines

Quoted 2 lines

link partner: 68

Quoted 1 line

[    0.557487] imx6q-pcie 1ffc000.pcie: Application request to initiate

training

Quoted 2 lines

Quoted 2 lines

reset: no

Quoted 1 line

[    0.557500] imx6q-pcie 1ffc000.pcie: PIPE transmit compliance request:

no

Quoted 3 lines

Quoted 3 lines

Quoted 1 line

[    0.557512] imx6q-pcie 1ffc000.pcie: PIPE transmit electrical idle request:

no

Quoted 1 line

[    0.557524] imx6q-pcie 1ffc000.pcie: PIPE receiver detect/loopback

request:

Quoted 3 lines

Quoted 3 lines

no

Quoted 2 lines

[    0.557536] imx6q-pcie 1ffc000.pcie: LTSSM-negotiated link reset: yes
[    0.557547] imx6q-pcie 1ffc000.pcie: LTSSM testing for polarity reversal:

no

Quoted 7 lines

Quoted 7 lines

Quoted 2 lines

[    0.557559] imx6q-pcie 1ffc000.pcie: LTSSM performing link training: no
[    0.557572] imx6q-pcie 1ffc000.pcie: LTSSM in DISABLE state; link

inoperable: no

Quoted 4 lines

[    0.557583] imx6q-pcie 1ffc000.pcie: Scrambling disabled for the link: no
[    0.558156] imx6q-pcie 1ffc000.pcie: PCI host bridge to bus 0000:00
[    0.558179] pci_bus 0000:00: root bus resource [bus 00-ff]
[    0.558197] pci_bus 0000:00: root bus resource [??? 0x01f00000-

0x01f7ffff

Quoted 7 lines

Quoted 7 lines

flags 0x0]

Quoted 2 lines

[    0.558212] pci_bus 0000:00: root bus resource [io  0x0000-0xffff]
[    0.558226] pci_bus 0000:00: root bus resource [mem 0x01000000-

0x01efffff]

Quoted 3 lines

[    0.558346] pci 0000:00:00.0: [16c3:abcd] type 01 class 0x060400
[    0.558468] pci 0000:00:00.0: reg 0x10: [mem 0x00000000-0x000fffff]
[    0.558510] pci 0000:00:00.0: reg 0x38: [mem 0x00000000-0x0000ffff

pref]

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

[    0.558708] pci 0000:00:00.0: supports D1
[    0.558727] pci 0000:00:00.0: PME# supported from D0 D1 D3hot D3cold
[    0.559495] PCI: bus0: Fast back to back transfers disabled
[    0.559834] PCI: bus1: Fast back to back transfers enabled
[    0.559997] pci 0000:00:00.0: BAR 0: assigned [mem 0x01000000-

0x010fffff]

Quoted 1 line

Quoted 1 line

Quoted 1 line

[    0.560025] pci 0000:00:00.0: BAR 6: assigned [mem 0x01100000-

0x0110ffff

Quoted 5 lines

Quoted 5 lines

pref]

Quoted 2 lines

[    0.560047] pci 0000:00:00.0: PCI bridge to [bus 01]
[    0.560812] pcieport 0000:00:00.0: Signaling PME through PCIe PME

interrupt

Quoted 1 line

[    0.560837] pcie_pme 0000:00:00.0:pcie01: service driver pcie_pme

loaded

Quoted 43 lines

Quoted 43 lines

Quoted 38 lines

Any idea what's going on?

Thanks in advance,
Roberto Fichera.

Quoted 32 lines

Hi There,

Working on a custom iMX6q board I'm getting a PCIe phy link never came up, even if uboot seems detecting everything ok. My DTS is enabling PCIe with

&pcie {
    pinctrl-names = "default";
    pinctrl-0 = <&pinctrl_pcie_reset>;
    reset-gpio = <&gpio7 12 0>;
    status = "okay";
};

The PCIe is connected to a PCIe-to-PCI TI XIO2001. The XIO2001 power is controlled by GPIO_9 and the corresponding fixed regulator is set as

		reg_pcie: regulator@4 {
			compatible = "regulator-fixed";
			reg = <4>;
			pinctrl-names = "default";
			pinctrl-0 = <&pinctrl_pcie_reg>;
			regulator-name = "MPCIE_3V3";
			regulator-min-microvolt = <3300000>;
			regulator-max-microvolt = <3300000>;
			gpio = <&gpio1 9 0>;
			regulator-always-on;
			enable-active-high;
		};

so I'd like to know if there is any other special setup to do in order to get it

to work on a v4.4.x kernel.

Quoted 4 lines

Quoted 4 lines

Or anyway how to debug it.

Any suggestion?

Quoted 1 line

[Zhu hongxing] It seems that the link down is caused by the different

initialization procedure.

Quoted 2 lines

Can you take a try by the previouse kernel version? Or, you can dump and compare the register values just before the

LTSSM_ENABLE is asserted between Linux and uboot.

Which register do you need to dump?

Quoted 54 lines

Quoted 54 lines

Quoted 26 lines

Quoted 26 lines

Thanks in advance,
Roberto Fichera.

U-Boot 2014.04-imx_v2014.04_3.14.38_6qp_beta+g6e9282c (Feb 15 2016 -
10:02:31)

CPU:   Freescale i.MX6Q rev1.5 at 792 MHz
CPU:   Temperature 35 C, calibration data: 0x5664d569
Reset cause: POR
Board: Janas iMX6Q (ID:e315c064140749d4)
I2C:   ready
DRAM:  2 GiB
MMC:   FSL_SDHC: 0, FSL_SDHC: 1

*** Warning - bad CRC, using default environment

  00:01.0     - 16c3:abcd - Bridge device
   01:00.0    - 104c:8240 - Bridge device
    02:04.0   - 1397:08b4 - Network controller
In:    serial
Out:   serial
Err:   serial

Found PFUZE100! deviceid=10,revid=21 mmc1(part 0) is current device
Net: FEC [PRIME]
Warning: failed to set MAC address

Quoted 5 lines

Quoted 5 lines

Normal Boot
....
....

[    0.236141] PCI host bridge /soc/pcie@0x01000000 ranges:
[    0.236162]   No bus range found for /soc/pcie@0x01000000, using [bus

00-ff]

Quoted 7 lines

Quoted 7 lines

[    0.236213]   err 0x01f00000..0x01f7ffff -> 0x01f00000
[    0.236250]    IO 0x01f80000..0x01f8ffff -> 0x00000000
[    0.236330]   MEM 0x01000000..0x01efffff -> 0x01000000
-->>> [    0.546690] imx6q-pcie 1ffc000.pcie: phy link never came up
[    0.547263] imx6q-pcie 1ffc000.pcie: PCI host bridge to bus 0000:00
[    0.547287] pci_bus 0000:00: root bus resource [bus 00-ff]
[    0.547304] pci_bus 0000:00: root bus resource [??? 0x01f00000-

0x01f7ffff flags 0x0]

Quoted 2 lines

Quoted 2 lines

[    0.547321] pci_bus 0000:00: root bus resource [io  0x0000-0xffff]
[    0.547335] pci_bus 0000:00: root bus resource [mem 0x01000000-

0x01efffff]

Quoted 3 lines

Quoted 3 lines

[    0.548608] PCI: bus0: Fast back to back transfers disabled
[    0.548950] PCI: bus1: Fast back to back transfers enabled
[    0.549107] pci 0000:00:00.0: BAR 0: assigned [mem 0x01000000-

0x010fffff]

Quoted 1 line

Quoted 1 line

[    0.549137] pci 0000:00:00.0: BAR 6: assigned [mem 0x01100000-

0x0110ffff pref]

Quoted 2 lines

Quoted 2 lines

[    0.549159] pci 0000:00:00.0: PCI bridge to [bus 01]
[    0.549945] pcieport 0000:00:00.0: Signaling PME through PCIe PME

interrupt

Quoted 2 lines

Quoted 2 lines

...

Quoted 8 lines

Quoted 8 lines

Quoted 8 lines

Quoted 5 lines

--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to [email protected] More

majordomo

Quoted 6 lines

Quoted 1 line

Quoted 1 line

info at http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

[Zhu hongxing] The registers configured during the initialization.
Regarding to the current situation at your side, the pcie link is up in uboot, but is down in kernel. So, you can compare the dump of the register configured during the pcie initialization between uboot and kernel.

Quoted 6 lines

Quoted 6 lines

GPR[1] (0x020e0004): 0x48611005
GPR[5] (0x020e0014): 0x00000000
GPR[8] (0x020e0020): 0xfffd4000
GPR[12] (0x020e0030): 0x0f004090
GPC_BASE_ADDR + 0 (0x020dc000): 0x00100000
MX6_DBI_ADDR + 0x7c (0x01ffc07c): 0x0011cc11

On 03/03/2016 10:39 AM, Richard Zhu wrote:

Hi Richard,

Quoted 3 lines

[Zhu hongxing] The registers configured during the initialization.
Regarding to the current situation at your side, the pcie link is up in uboot, but is down in kernel. So, you can compare the dump of the register configured during the pcie initialization between uboot and kernel.

Here is the register status before to start LTSSM under uboot

...

I2C:   ready
DRAM:  2 GiB
MMC:   FSL_SDHC: 0, FSL_SDHC: 1

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

GPR[1] (0x020e0004): 0x48611005
GPR[5] (0x020e0014): 0x00000000
GPR[8] (0x020e0020): 0xfffd4000
GPR[12] (0x020e0030): 0x0f004090
GPC_BASE_ADDR + 0 (0x020dc000): 0x00100000
MX6_DBI_ADDR + 0x7c (0x01ffc07c): 0x0011cc11

DEBUG_R0: 0x036e2b11, DEBUG_R1: 0x08000410
LTSSM current state: 0x11 (S_L0)
PIPE transmit K indication: 0
PIPE Transmit data: 0x6e2b
Receiver is receiving logical idle: yes

but the funny thing is under kernel, maybe related to some clock setting? see below

Quoted 4 lines

Quoted 4 lines

GPR[1] (0x020e0004): 0x48611005
GPR[8] (0x020e0020): 0xfffd4000
GPR[12] (0x020e0030): 0x0f004090
MX6_DBI_ADDR + 0x7c (0x01ffc07c): 0x0011cc11

[    0.235456] PCI host bridge /soc/pcie@0x01000000 ranges:
[    0.235475]   No bus range found for /soc/pcie@0x01000000, using [bus 00-ff]
[    0.235527]   err 0x01f00000..0x01f7ffff -> 0x01f00000
[    0.235577]    IO 0x01f80000..0x01f8ffff -> 0x00000000
[    0.235659]   MEM 0x01000000..0x01efffff -> 0x01000000
[    0.377644] imx6q-pcie 1ffc000.pcie: >>> GPR[1] (0x00000004): 0x00000000
[    0.377666] imx6q-pcie 1ffc000.pcie: >>> GPR[5] (0x00000014): 0x00000000
[    0.377684] imx6q-pcie 1ffc000.pcie: >>> GPR[8] (0x00000020): 0x00000000
[    0.377701] imx6q-pcie 1ffc000.pcie: >>> GPR[12] (0x00000030): 0x00000000
[    0.377717] imx6q-pcie 1ffc000.pcie: >>> PCIE_RC_LCR (0xf08f007c): 0x0011cc11
[    0.586532] imx6q-pcie 1ffc000.pcie: phy link never came up
[    0.586551] imx6q-pcie 1ffc000.pcie: LTSSM current state: 0x3 (S_POLL_COMPLIANCE)
[    0.586566] imx6q-pcie 1ffc000.pcie: PIPE transmit K indication: 1
[    0.586579] imx6q-pcie 1ffc000.pcie: PIPE Transmit data: 0xb5bc
[    0.586592] imx6q-pcie 1ffc000.pcie: Receiver is receiving logical idle: no

The code I've used to dump the register is using regmap_read(),

#define IMX6_DUMP_REGISTER(__map, __reg, __name) \

  do {\
    uint32_t val;\
    val = regmap_read(__map, __reg, &val);\
    dev_err(pp->dev, ">>> " __name " (0x%08p): 0x%08x\n", __reg, val);\

} while(0)

#define IMX6_DUMP_REGISTER2(__reg, __name) \

  do {\
    uint32_t val;\
    val = readl(__reg);\
    dev_err(pp->dev, ">>> " __name " (0x%08p): 0x%08x\n", __reg, val);\

} while(0)

static void imx6_pcie_dump_registers(struct pcie_port *pp)

{
    struct imx6_pcie *imx6_pcie = to_imx6_pcie(pp);

        IMX6_DUMP_REGISTER(imx6_pcie->iomuxc_gpr, IOMUXC_GPR1, "GPR[1]");
        IMX6_DUMP_REGISTER(imx6_pcie->iomuxc_gpr, IOMUXC_GPR5, "GPR[5]");
        IMX6_DUMP_REGISTER(imx6_pcie->iomuxc_gpr, IOMUXC_GPR8, "GPR[8]");
        IMX6_DUMP_REGISTER(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12, "GPR[12]");
        IMX6_DUMP_REGISTER2(pp->dbi_base + PCIE_RC_LCR, "PCIE_RC_LCR");
}

Cheers,
Roberto Fichera.
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Quoted 19 lines · Richard Zhu

Hi Richard,

Quoted 3 lines

[Zhu hongxing] The registers configured during the initialization.
Regarding to the current situation at your side, the pcie link is up in uboot, but is down in kernel. So, you can compare the dump of the register configured during the pcie initialization between uboot and kernel.

Here is the register status before to start LTSSM under uboot

...

I2C:   ready
DRAM:  2 GiB
MMC:   FSL_SDHC: 0, FSL_SDHC: 1

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

GPR[1] (0x020e0004): 0x48611005
GPR[5] (0x020e0014): 0x00000000
GPR[8] (0x020e0020): 0xfffd4000
GPR[12] (0x020e0030): 0x0f004090
GPC_BASE_ADDR + 0 (0x020dc000): 0x00100000
MX6_DBI_ADDR + 0x7c (0x01ffc07c): 0x0011cc11

Quoted 7 lines

DEBUG_R0: 0x036e2b11, DEBUG_R1: 0x08000410
LTSSM current state: 0x11 (S_L0)
PIPE transmit K indication: 0
PIPE Transmit data: 0x6e2b
Receiver is receiving logical idle: yes

but the funny thing is under kernel, maybe related to some clock setting? see below

Was my fault! Value are exactly the same I'm getting under uboot:

I2C:   ready
DRAM:  2 GiB
MMC:   FSL_SDHC: 0, FSL_SDHC: 1

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines

GPR[1] (0x020e0004): 0x48611005
GPR[8] (0x020e0020): 0xfffd4000
GPR[12] (0x020e0030): 0x0f004090
MX6_DBI_ADDR + 0x7c (0x01ffc07c): 0x0011cc11

kernel:

[    0.377668] imx6q-pcie 1ffc000.pcie: >>> GPR[1]: 0x48611005
[    0.377705] imx6q-pcie 1ffc000.pcie: >>> GPR[8]: 0xfffd4000
[    0.377720] imx6q-pcie 1ffc000.pcie: >>> GPR[12]: 0x0f004090
[    0.377734] imx6q-pcie 1ffc000.pcie: >>> PCIE_RC_LCR (0xf08f007c): 0x0011cc11
[    0.586591] imx6q-pcie 1ffc000.pcie: phy link never came up

Quoted 44 lines

[    0.235456] PCI host bridge /soc/pcie@0x01000000 ranges:
[    0.235475]   No bus range found for /soc/pcie@0x01000000, using [bus 00-ff]
[    0.235527]   err 0x01f00000..0x01f7ffff -> 0x01f00000
[    0.235577]    IO 0x01f80000..0x01f8ffff -> 0x00000000
[    0.235659]   MEM 0x01000000..0x01efffff -> 0x01000000
[    0.377644] imx6q-pcie 1ffc000.pcie: >>> GPR[1] (0x00000004): 0x00000000
[    0.377666] imx6q-pcie 1ffc000.pcie: >>> GPR[5] (0x00000014): 0x00000000
[    0.377684] imx6q-pcie 1ffc000.pcie: >>> GPR[8] (0x00000020): 0x00000000
[    0.377701] imx6q-pcie 1ffc000.pcie: >>> GPR[12] (0x00000030): 0x00000000
[    0.377717] imx6q-pcie 1ffc000.pcie: >>> PCIE_RC_LCR (0xf08f007c): 0x0011cc11
[    0.586532] imx6q-pcie 1ffc000.pcie: phy link never came up
[    0.586551] imx6q-pcie 1ffc000.pcie: LTSSM current state: 0x3 (S_POLL_COMPLIANCE)
[    0.586566] imx6q-pcie 1ffc000.pcie: PIPE transmit K indication: 1
[    0.586579] imx6q-pcie 1ffc000.pcie: PIPE Transmit data: 0xb5bc
[    0.586592] imx6q-pcie 1ffc000.pcie: Receiver is receiving logical idle: no

The code I've used to dump the register is using regmap_read(),

#define IMX6_DUMP_REGISTER(__map, __reg, __name) \

  do {\
    uint32_t val;\
    val = regmap_read(__map, __reg, &val);\
    dev_err(pp->dev, ">>> " __name " (0x%08p): 0x%08x\n", __reg, val);\

} while(0)

#define IMX6_DUMP_REGISTER2(__reg, __name) \

  do {\
    uint32_t val;\
    val = readl(__reg);\
    dev_err(pp->dev, ">>> " __name " (0x%08p): 0x%08x\n", __reg, val);\

} while(0)

static void imx6_pcie_dump_registers(struct pcie_port *pp)

{
    struct imx6_pcie *imx6_pcie = to_imx6_pcie(pp);

        IMX6_DUMP_REGISTER(imx6_pcie->iomuxc_gpr, IOMUXC_GPR1, "GPR[1]");
        IMX6_DUMP_REGISTER(imx6_pcie->iomuxc_gpr, IOMUXC_GPR5, "GPR[5]");
        IMX6_DUMP_REGISTER(imx6_pcie->iomuxc_gpr, IOMUXC_GPR8, "GPR[8]");
        IMX6_DUMP_REGISTER(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12, "GPR[12]");
        IMX6_DUMP_REGISTER2(pp->dbi_base + PCIE_RC_LCR, "PCIE_RC_LCR");
}

Quoted 7 lines

Cheers,
Roberto Fichera.
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

-----Original Message-----
From: Roberto Fichera [mailto:[email protected]]
Sent: Friday, March 04, 2016 2:34 AM
To: Richard Zhu; Bjorn Helgaas
Cc: [email protected]; Richard Zhu; Lucas Stach
Subject: Re: iMX6q PCIe phy link never came up on kernel v4.4.x

On 03/03/2016 03:34 PM, Roberto Fichera wrote:

I've also checked clock, pll, PMU_MISC1 and CCGR[45] registers, all looks fine and exactly equal to uboot settings.

However I'm investigating a possible HW issue in the LDVS pad wiring against the bridge XIO2001. Let's see once this is also clarified.

Quoted 7 lines · Roberto Fichera

Quoted 6 lines · Richard Zhu

Hi Richard,

Quoted 2 lines

[Zhu hongxing] The registers configured during the initialization. Regarding to the current situation at your side, the pcie link is up in uboot,

but is down in kernel.

Quoted 1 line

Quoted 1 line

Quoted 1 line

So, you can compare the dump of the register configured during the pcie

initialization between uboot and kernel.

Quoted 29 lines

Quoted 12 lines

Here is the register status before to start LTSSM under uboot

...

I2C:   ready
DRAM:  2 GiB
MMC:   FSL_SDHC: 0, FSL_SDHC: 1

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

GPR[1] (0x020e0004): 0x48611005
GPR[5] (0x020e0014): 0x00000000
GPR[8] (0x020e0020): 0xfffd4000
GPR[12] (0x020e0030): 0x0f004090
GPC_BASE_ADDR + 0 (0x020dc000): 0x00100000 MX6_DBI_ADDR + 0x7c (0x01ffc07c): 0x0011cc11

Quoted 8 lines

DEBUG_R0: 0x036e2b11, DEBUG_R1: 0x08000410
LTSSM current state: 0x11 (S_L0)
PIPE transmit K indication: 0
PIPE Transmit data: 0x6e2b
Receiver is receiving logical idle: yes

but the funny thing is under kernel, maybe related to some clock setting? see below

Was my fault! Value are exactly the same I'm getting under uboot:

I2C:   ready
DRAM:  2 GiB
MMC:   FSL_SDHC: 0, FSL_SDHC: 1

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines

GPR[1] (0x020e0004): 0x48611005
GPR[8] (0x020e0020): 0xfffd4000
GPR[12] (0x020e0030): 0x0f004090
MX6_DBI_ADDR + 0x7c (0x01ffc07c): 0x0011cc11

Quoted 6 lines

kernel:

[    0.377668] imx6q-pcie 1ffc000.pcie: >>> GPR[1]: 0x48611005
[    0.377705] imx6q-pcie 1ffc000.pcie: >>> GPR[8]: 0xfffd4000
[    0.377720] imx6q-pcie 1ffc000.pcie: >>> GPR[12]: 0x0f004090
[    0.377734] imx6q-pcie 1ffc000.pcie: >>> PCIE_RC_LCR (0xf08f007c):

0x0011cc11

Quoted 5 lines

[    0.586591] imx6q-pcie 1ffc000.pcie: phy link never came up

Quoted 2 lines

[    0.235456] PCI host bridge /soc/pcie@0x01000000 ranges:
[    0.235475]   No bus range found for /soc/pcie@0x01000000, using [bus

00-ff]

Quoted 4 lines

Quoted 4 lines

[    0.235527]   err 0x01f00000..0x01f7ffff -> 0x01f00000
[    0.235577]    IO 0x01f80000..0x01f8ffff -> 0x00000000
[    0.235659]   MEM 0x01000000..0x01efffff -> 0x01000000
[    0.377644] imx6q-pcie 1ffc000.pcie: >>> GPR[1] (0x00000004):

0x00000000

Quoted 1 line

Quoted 1 line

[    0.377666] imx6q-pcie 1ffc000.pcie: >>> GPR[5] (0x00000014):

0x00000000

Quoted 1 line

Quoted 1 line

[    0.377684] imx6q-pcie 1ffc000.pcie: >>> GPR[8] (0x00000020):

0x00000000

Quoted 1 line

Quoted 1 line

[    0.377701] imx6q-pcie 1ffc000.pcie: >>> GPR[12] (0x00000030):

0x00000000

Quoted 1 line

Quoted 1 line

[    0.377717] imx6q-pcie 1ffc000.pcie: >>> PCIE_RC_LCR (0xf08f007c):

0x0011cc11

Quoted 2 lines

Quoted 2 lines

[    0.586532] imx6q-pcie 1ffc000.pcie: phy link never came up
[    0.586551] imx6q-pcie 1ffc000.pcie: LTSSM current state: 0x3

(S_POLL_COMPLIANCE)

Quoted 21 lines

Quoted 21 lines

[    0.586566] imx6q-pcie 1ffc000.pcie: PIPE transmit K indication: 1
[    0.586579] imx6q-pcie 1ffc000.pcie: PIPE Transmit data: 0xb5bc
[    0.586592] imx6q-pcie 1ffc000.pcie: Receiver is receiving logical idle: no

The code I've used to dump the register is using regmap_read(),

#define IMX6_DUMP_REGISTER(__map, __reg, __name) \

  do {\
    uint32_t val;\
    val = regmap_read(__map, __reg, &val);\
    dev_err(pp->dev, ">>> " __name " (0x%08p): 0x%08x\n", __reg, val);\

} while(0)

#define IMX6_DUMP_REGISTER2(__reg, __name) \

  do {\
    uint32_t val;\
    val = readl(__reg);\
    dev_err(pp->dev, ">>> " __name " (0x%08p): 0x%08x\n", __reg, val);\

} while(0)

Quoted 4 lines

Quoted 4 lines

static void imx6_pcie_dump_registers(struct pcie_port *pp) {
    struct imx6_pcie *imx6_pcie = to_imx6_pcie(pp);

        IMX6_DUMP_REGISTER(imx6_pcie->iomuxc_gpr, IOMUXC_GPR1,

"GPR[1]");

Quoted 1 line

Quoted 1 line

        IMX6_DUMP_REGISTER(imx6_pcie->iomuxc_gpr, IOMUXC_GPR5,

"GPR[5]");

Quoted 1 line

Quoted 1 line

        IMX6_DUMP_REGISTER(imx6_pcie->iomuxc_gpr, IOMUXC_GPR8,

"GPR[8]");

Quoted 1 line

Quoted 1 line

        IMX6_DUMP_REGISTER(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,

"GPR[12]");

Quoted 15 lines

Quoted 10 lines

        IMX6_DUMP_REGISTER2(pp->dbi_base + PCIE_RC_LCR,

"PCIE_RC_LCR"); }

Cheers,
Roberto Fichera.
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

Quoted 12 lines

-----Original Message-----

Quoted 11 lines

From: Roberto Fichera [mailto:[email protected]]
Sent: Friday, March 04, 2016 2:34 AM
To: Richard Zhu; Bjorn Helgaas
Cc: [email protected]; Richard Zhu; Lucas Stach
Subject: Re: iMX6q PCIe phy link never came up on kernel v4.4.x

On 03/03/2016 03:34 PM, Roberto Fichera wrote:

I've also checked clock, pll, PMU_MISC1 and CCGR[45] registers, all looks fine and exactly equal to uboot settings.

Quoted 3 lines

Quoted 3 lines

However I'm investigating a possible HW issue in the LDVS pad wiring against the bridge XIO2001. Let's see once this is also clarified.

[Zhu hongxing] it means there are no differences of the pcie initialization between uboot and kernel. But, pcie link is up in uboot, but failed to link up in kernel.
Thus, we have to take look at the procedures of the initialization between uboot and kernel. As I remember that, the usage of the #PERST is different at least.

On 03/03/2016 03:34 PM, Roberto Fichera wrote:

I've also checked clock, pll, PMU_MISC1 and CCGR[45] registers, all looks fine and exactly equal to uboot settings.

However I'm investigating a possible HW issue in the LDVS pad wiring against the bridge XIO2001. Let's see once this is also clarified.

Quoted 102 lines · Roberto Fichera

Quoted 19 lines · Richard Zhu

Hi Richard,

Quoted 3 lines

[Zhu hongxing] The registers configured during the initialization.
Regarding to the current situation at your side, the pcie link is up in uboot, but is down in kernel. So, you can compare the dump of the register configured during the pcie initialization between uboot and kernel.

Here is the register status before to start LTSSM under uboot

...

I2C:   ready
DRAM:  2 GiB
MMC:   FSL_SDHC: 0, FSL_SDHC: 1

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

GPR[1] (0x020e0004): 0x48611005
GPR[5] (0x020e0014): 0x00000000
GPR[8] (0x020e0020): 0xfffd4000
GPR[12] (0x020e0030): 0x0f004090
GPC_BASE_ADDR + 0 (0x020dc000): 0x00100000
MX6_DBI_ADDR + 0x7c (0x01ffc07c): 0x0011cc11

Quoted 7 lines

DEBUG_R0: 0x036e2b11, DEBUG_R1: 0x08000410
LTSSM current state: 0x11 (S_L0)
PIPE transmit K indication: 0
PIPE Transmit data: 0x6e2b
Receiver is receiving logical idle: yes

but the funny thing is under kernel, maybe related to some clock setting? see below

Was my fault! Value are exactly the same I'm getting under uboot:

I2C:   ready
DRAM:  2 GiB
MMC:   FSL_SDHC: 0, FSL_SDHC: 1

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines

GPR[1] (0x020e0004): 0x48611005
GPR[8] (0x020e0020): 0xfffd4000
GPR[12] (0x020e0030): 0x0f004090
MX6_DBI_ADDR + 0x7c (0x01ffc07c): 0x0011cc11

kernel:

[    0.377668] imx6q-pcie 1ffc000.pcie: >>> GPR[1]: 0x48611005
[    0.377705] imx6q-pcie 1ffc000.pcie: >>> GPR[8]: 0xfffd4000
[    0.377720] imx6q-pcie 1ffc000.pcie: >>> GPR[12]: 0x0f004090
[    0.377734] imx6q-pcie 1ffc000.pcie: >>> PCIE_RC_LCR (0xf08f007c): 0x0011cc11
[    0.586591] imx6q-pcie 1ffc000.pcie: phy link never came up

Quoted 44 lines

[    0.235456] PCI host bridge /soc/pcie@0x01000000 ranges:
[    0.235475]   No bus range found for /soc/pcie@0x01000000, using [bus 00-ff]
[    0.235527]   err 0x01f00000..0x01f7ffff -> 0x01f00000
[    0.235577]    IO 0x01f80000..0x01f8ffff -> 0x00000000
[    0.235659]   MEM 0x01000000..0x01efffff -> 0x01000000
[    0.377644] imx6q-pcie 1ffc000.pcie: >>> GPR[1] (0x00000004): 0x00000000
[    0.377666] imx6q-pcie 1ffc000.pcie: >>> GPR[5] (0x00000014): 0x00000000
[    0.377684] imx6q-pcie 1ffc000.pcie: >>> GPR[8] (0x00000020): 0x00000000
[    0.377701] imx6q-pcie 1ffc000.pcie: >>> GPR[12] (0x00000030): 0x00000000
[    0.377717] imx6q-pcie 1ffc000.pcie: >>> PCIE_RC_LCR (0xf08f007c): 0x0011cc11
[    0.586532] imx6q-pcie 1ffc000.pcie: phy link never came up
[    0.586551] imx6q-pcie 1ffc000.pcie: LTSSM current state: 0x3 (S_POLL_COMPLIANCE)
[    0.586566] imx6q-pcie 1ffc000.pcie: PIPE transmit K indication: 1
[    0.586579] imx6q-pcie 1ffc000.pcie: PIPE Transmit data: 0xb5bc
[    0.586592] imx6q-pcie 1ffc000.pcie: Receiver is receiving logical idle: no

The code I've used to dump the register is using regmap_read(),

#define IMX6_DUMP_REGISTER(__map, __reg, __name) \

  do {\
    uint32_t val;\
    val = regmap_read(__map, __reg, &val);\
    dev_err(pp->dev, ">>> " __name " (0x%08p): 0x%08x\n", __reg, val);\

} while(0)

#define IMX6_DUMP_REGISTER2(__reg, __name) \

  do {\
    uint32_t val;\
    val = readl(__reg);\
    dev_err(pp->dev, ">>> " __name " (0x%08p): 0x%08x\n", __reg, val);\

} while(0)

static void imx6_pcie_dump_registers(struct pcie_port *pp)

{
    struct imx6_pcie *imx6_pcie = to_imx6_pcie(pp);

        IMX6_DUMP_REGISTER(imx6_pcie->iomuxc_gpr, IOMUXC_GPR1, "GPR[1]");
        IMX6_DUMP_REGISTER(imx6_pcie->iomuxc_gpr, IOMUXC_GPR5, "GPR[5]");
        IMX6_DUMP_REGISTER(imx6_pcie->iomuxc_gpr, IOMUXC_GPR8, "GPR[8]");
        IMX6_DUMP_REGISTER(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12, "GPR[12]");
        IMX6_DUMP_REGISTER2(pp->dbi_base + PCIE_RC_LCR, "PCIE_RC_LCR");
}

Quoted 7 lines

Cheers,
Roberto Fichera.
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Quoted 5 lines · Roberto Fichera

I've also checked clock, pll, PMU_MISC1 and CCGR[45] registers, all looks fine and exactly equal to uboot settings.

Quoted 2 lines

However I'm investigating a possible HW issue in the LDVS pad wiring against the bridge XIO2001. Let's see once this is also clarified.

Our HW engineer has applied a fix to LVDS vs XIO2001 clock wiring. However I'm still getting the same problem.

I've tried to boot a kernel with uboot not setting up the PCIe subsys and below there is the resulting kernel log. Note that the CCGR5 doesn't set the CG2 field associated to sata_clk_enable. I think this field should be set all 1 to enable the SATA ref at 100MHz, right?

Am Dienstag, den 08.03.2016, 15:39 +0100 schrieb Roberto Fichera:

Quoted 6 lines · Roberto Fichera

Quoted 5 lines · Roberto Fichera

I've also checked clock, pll, PMU_MISC1 and CCGR[45] registers, all looks fine and exactly equal to uboot settings.

Quoted 8 lines

Quoted 2 lines

However I'm investigating a possible HW issue in the LDVS pad wiring against the bridge XIO2001. Let's see once this is also clarified.

Our HW engineer has applied a fix to LVDS vs XIO2001 clock wiring. However I'm still getting the same problem.

I've tried to boot a kernel with uboot not setting up the PCIe subsys and below there is the resulting kernel log. Note that the CCGR5 doesn't set the CG2 field associated to sata_clk_enable. I think this field should be set all 1 to enable the SATA ref at 100MHz, right?

No, the reference manual is a bit confusing about this, but the LVDS1 clock output is driven by sata_ref_100mhz, not the sata_clk gate.

So the only thing that needs to be enabled for LVDS clock output is the 100MHz clock output from PLL ENET. (Register CCM_ANALOG_PLL_ENETn bit 20).

Can you please try to revert the commit I pointed out in my last mail and see if it helps? We might be holding the PCI device reset gpio at the wrong level with this commit.

Regards,
Lucas

Am Dienstag, den 08.03.2016, 15:39 +0100 schrieb Roberto Fichera:

Quoted 9 lines

Quoted 9 lines · Roberto Fichera

Quoted 7 lines

Quoted 7 lines · Roberto Fichera

I've also checked clock, pll, PMU_MISC1 and CCGR[45] registers, all looks fine and exactly equal to uboot settings.

However I'm investigating a possible HW issue in the LDVS pad wiring against the bridge XIO2001. Let's see once this is also clarified.

Quoted 6 lines

Quoted 6 lines

Our HW engineer has applied a fix to LVDS vs XIO2001 clock wiring. However I'm still getting the same problem.

I've tried to boot a kernel with uboot not setting up the PCIe subsys and below there is the resulting kernel log. Note that the CCGR5 doesn't set the CG2 field associated to sata_clk_enable. I think this field should be set all 1 to enable the SATA ref at 100MHz, right?

No, the reference manual is a bit confusing about this, but the LVDS1 clock output is driven by sata_ref_100mhz, not the sata_clk gate.

So the only thing that needs to be enabled for LVDS clock output is the 100MHz clock output from PLL ENET. (Register CCM_ANALOG_PLL_ENETn bit 20).

Quoted 18 lines · Lucas Stach

Am Dienstag, den 08.03.2016, 15:39 +0100 schrieb Roberto Fichera:

Quoted 6 lines

Quoted 6 lines · Roberto Fichera

Quoted 5 lines

Quoted 5 lines · Roberto Fichera

I've also checked clock, pll, PMU_MISC1 and CCGR[45] registers, all looks fine and exactly equal to uboot settings.

Quoted 8 lines

Quoted 8 lines

Quoted 2 lines

Quoted 2 lines

However I'm investigating a possible HW issue in the LDVS pad wiring against the bridge XIO2001. Let's see once this is also clarified.

Our HW engineer has applied a fix to LVDS vs XIO2001 clock wiring. However I'm still getting the same problem.

I've tried to boot a kernel with uboot not setting up the PCIe subsys and below there is the resulting kernel log. Note that the CCGR5 doesn't set the CG2 field associated to sata_clk_enable. I think this field should be set all 1 to enable the SATA ref at 100MHz, right?

No, the reference manual is a bit confusing about this, but the LVDS1 clock output is driven by sata_ref_100mhz, not the sata_clk gate.

Quoted 3 lines

So the only thing that needs to be enabled for LVDS clock output is the 100MHz clock output from PLL ENET. (Register CCM_ANALOG_PLL_ENETn bit 20).

Guys! No more idea where to look at! Still getting PCIe link reaching L0 state under uboot but doesn't progress more than POLL_ACTIVE or POLL_COMPLIANCE states under kernel.

Any idea what to do?

Cheers,
Roberto Fichera.

Quoted 19 lines · Roberto Fichera

Quoted 19 lines · Lucas Stach

Quoted 18 lines

Quoted 18 lines

Am Dienstag, den 08.03.2016, 15:39 +0100 schrieb Roberto Fichera:

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines · Roberto Fichera

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines · Roberto Fichera

I've also checked clock, pll, PMU_MISC1 and CCGR[45] registers, all looks fine
and exactly equal to uboot settings.

Quoted 8 lines

Quoted 8 lines

Quoted 8 lines

Quoted 8 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

However I'm investigating a possible HW issue in the LDVS pad wiring against
the bridge XIO2001. Let's see once this is also clarified.

Our HW engineer has applied a fix to LVDS vs XIO2001 clock wiring. However I'm still getting the same problem.

I've tried to boot a kernel with uboot not setting up the PCIe subsys and below there is the resulting kernel log. Note that the CCGR5 doesn't set the CG2 field associated to sata_clk_enable. I think this field should be set all 1 to enable the SATA ref at 100MHz, right?

No, the reference manual is a bit confusing about this, but the LVDS1 clock output is driven by sata_ref_100mhz, not the sata_clk gate.

Quoted 8 lines

Quoted 8 lines

Quoted 3 lines

Quoted 3 lines

So the only thing that needs to be enabled for LVDS clock output is the 100MHz clock output from PLL ENET. (Register CCM_ANALOG_PLL_ENETn bit 20).

Guys! No more idea where to look at! Still getting PCIe link reaching L0 state under uboot but doesn't progress more than POLL_ACTIVE or POLL_COMPLIANCE states under kernel.

Any idea what to do?

Quoted 23 lines · Roberto Fichera

Quoted 22 lines · Roberto Fichera

Quoted 22 lines · Lucas Stach

Quoted 21 lines

Quoted 21 lines

Am Dienstag, den 08.03.2016, 15:39 +0100 schrieb Roberto Fichera:

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines · Roberto Fichera

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

On 03/03/2016 03:34 PM, Roberto Fichera wrote:

I've also checked clock, pll, PMU_MISC1 and CCGR[45] registers, all looks fine
and exactly equal to uboot settings.

Quoted 8 lines

Quoted 8 lines

Quoted 8 lines

Quoted 8 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

However I'm investigating a possible HW issue in the LDVS pad wiring against
the bridge XIO2001. Let's see once this is also clarified.

Our HW engineer has applied a fix to LVDS vs XIO2001 clock wiring. However I'm still getting the same problem.

I've tried to boot a kernel with uboot not setting up the PCIe subsys and below there is the resulting kernel log. Note that the CCGR5 doesn't set the CG2 field associated to sata_clk_enable. I think this field should be set all 1 to enable the SATA ref at 100MHz, right?

No, the reference manual is a bit confusing about this, but the LVDS1 clock output is driven by sata_ref_100mhz, not the sata_clk gate.

So the only thing that needs to be enabled for LVDS clock output is the 100MHz clock output from PLL ENET. (Register CCM_ANALOG_PLL_ENETn bit 20).

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Guys! No more idea where to look at! Still getting PCIe link reaching L0 state under uboot but doesn't progress more than POLL_ACTIVE or POLL_COMPLIANCE states under kernel.

Any idea what to do?

Just to say that I've fixed the problem by asserting PERST before to drop PCIe refclk and enable power down. PERST is finally released at the usual place.

[    0.237473] PCI host bridge /soc/pcie@0x01000000 ranges:
[    0.237494]   No bus range found for /soc/pcie@0x01000000, using [bus 00-ff]
[    0.237545]   err 0x01f00000..0x01f7ffff -> 0x01f00000
[    0.237585]    IO 0x01f80000..0x01f8ffff -> 0x00000000
[    0.237671]   MEM 0x01000000..0x01efffff -> 0x01000000
[    0.353847] imx6q-pcie 1ffc000.pcie: Link: Gen2 disabled
[    0.353866] imx6q-pcie 1ffc000.pcie: Link up, Gen=1
[    0.354441] imx6q-pcie 1ffc000.pcie: PCI host bridge to bus 0000:00
[    0.354465] pci_bus 0000:00: root bus resource [bus 00-ff]
[    0.354483] pci_bus 0000:00: root bus resource [??? 0x01f00000-0x01f7ffff flags 0x0]

[    0.354499] pci_bus 0000:00: root bus resource [io  0x0000-0xffff]
[    0.354513] pci_bus 0000:00: root bus resource [mem 0x01000000-0x01efffff]
[    0.354640] pci 0000:00:00.0: [16c3:abcd] type 01 class 0x060400
[    0.354707] pci 0000:00:00.0: reg 0x10: [mem 0x00000000-0x000fffff]
[    0.354745] pci 0000:00:00.0: reg 0x38: [mem 0x00000000-0x0000ffff pref]
[    0.354932] pci 0000:00:00.0: supports D1
[    0.354952] pci 0000:00:00.0: PME# supported from D0 D1 D3hot D3cold
[    0.355713] PCI: bus0: Fast back to back transfers disabled
[    0.356139] pci 0000:01:00.0: [104c:8240] type 01 class 0x060400
[    0.356688] pci 0000:01:00.0: supports D1 D2
[    0.369318] PCI: bus1: Fast back to back transfers disabled

Just to say that I've fixed the problem by asserting PERST before to drop PCIe refclk and enable power down. PERST is finally released at the usual place.

Quoted 2 lines · Roberto Fichera

Just to say that I've fixed the problem by asserting PERST before to drop PCIe refclk and enable power down. PERST is finally released at the usual place.

Excellent! Do you plan to submit a patch to fix this issue?

--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Quoted 5 lines · Fabio Estevam

Quoted 2 lines · Roberto Fichera

Just to say that I've fixed the problem by asserting PERST before to drop PCIe refclk and enable power down. PERST is finally released at the usual place.

Excellent! Do you plan to submit a patch to fix this issue?

I don't know, in my case the problem was related to the XIO2001 that require PERST to be asserted before to drop PCIe refclk as reported by its datasheet:

(quoted diff) +11 -0

@@ -214,6 +352,16 @@ static int imx6_pcie_assert_core_reset(struct pcie_port *pp)
     struct imx6_pcie *imx6_pcie = to_imx6_pcie(pp);
     u32 val, gpr1, gpr12;
 
+        /*
+         * Our PCIe link is connected to a TI XIO2001 PCIe-to-PCI
+         * bridge and this require PERST to be asserted before to
+         * drop PCIe ref_clk otherwise it will get "confused" and
+         * the PCIe link state will stuck in POLL_STATE
+         */
+    if (gpio_is_valid(imx6_pcie->reset_gpio)) {
+            gpio_set_value(imx6_pcie->reset_gpio, 0);
+        }
+
     /*
      * If the bootloader already enabled the link we need some special
      * handling to get the core back into a state where it is safe to

@@ -241,6 +389,7 @@ static int imx6_pcie_assert_core_reset(struct pcie_port *pp)
 
     regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR1,
             IMX6Q_GPR1_PCIE_TEST_PD, 1 << 18);
+    udelay(10);
     regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR1,
             IMX6Q_GPR1_PCIE_REF_CLK_EN, 0 << 16);
 

I've also slightly changed the Gen2 negotiation with this relevant part where the Gen2 speed change is only done if necessary

(quoted diff) +35 -30

@@ -387,46 +541,57 @@ static int imx6_pcie_establish_link(struct pcie_port *pp)
 
     /* Start LTSSM. */
     regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
-            IMX6Q_GPR12_PCIE_CTL_2, 1 << 10);
-
-    ret = imx6_pcie_wait_for_link(pp);
-    if (ret)
-        return ret;
-
-    /* Allow Gen2 mode after the link is up. */
-    tmp = readl(pp->dbi_base + PCIE_RC_LCR);
-    tmp &= ~PCIE_RC_LCR_MAX_LINK_SPEEDS_MASK;
-    tmp |= PCIE_RC_LCR_MAX_LINK_SPEEDS_GEN2;
-    writel(tmp, pp->dbi_base + PCIE_RC_LCR);
-
-    /*
-     * Start Directed Speed Change so the best possible speed both link
-     * partners support can be negotiated.
-     */
-    tmp = readl(pp->dbi_base + PCIE_LINK_WIDTH_SPEED_CONTROL);
-    tmp |= PORT_LOGIC_SPEED_CHANGE;
-    writel(tmp, pp->dbi_base + PCIE_LINK_WIDTH_SPEED_CONTROL);
-
-    ret = imx6_pcie_wait_for_speed_change(pp);
-    if (ret) {
-        dev_err(pp->dev, "Failed to bring link up!\n");
-        return ret;
-    }
+                  IMX6Q_GPR12_PCIE_CTL_2, 1 << 10);
 
-    /* Make sure link training is finished as well! */
     ret = imx6_pcie_wait_for_link(pp);
-    if (ret) {
-        dev_err(pp->dev, "Failed to bring link up!\n");
-        return ret;
+        if(ret)
+                return ret;
+
+        if(pp->link_gen == 2) {
+            /* Allow Gen2 mode after the link is up. */
+            tmp = readl(pp->dbi_base + PCIE_RC_LCR);
+            tmp &= ~PCIE_RC_LCR_MAX_LINK_SPEEDS_MASK;
+            tmp |= PCIE_RC_LCR_MAX_LINK_SPEEDS_GEN2;
+            writel(tmp, pp->dbi_base + PCIE_RC_LCR);
+
+            /*
+             * Start Directed Speed Change so the best possible speed both link
+             * partners support can be negotiated.
+             */
+            tmp = readl(pp->dbi_base + PCIE_LINK_WIDTH_SPEED_CONTROL);
+            tmp |= PORT_LOGIC_SPEED_CHANGE;
+            writel(tmp, pp->dbi_base + PCIE_LINK_WIDTH_SPEED_CONTROL);
+
+            ret = imx6_pcie_wait_for_speed_change(pp);
+            if (ret) {
+                dev_err(pp->dev, "Failed to bring link up!\n");
+                return ret;
+            }
+
+            /* Make sure link training is finished as well! */
+            ret = imx6_pcie_wait_for_link(pp);
+            if (ret) {
+                dev_err(pp->dev, "Failed to bring link up!\n");
+                return ret;
+            }
+
+    } else {
+        dev_info(pp->dev, "Link: Gen2 disabled\n");
     }
 
     tmp = readl(pp->dbi_base + PCIE_RC_LCSR);
-    dev_dbg(pp->dev, "Link up, Gen=%i\n", (tmp >> 16) & 0xf);
+    dev_info(pp->dev, "Link up, Gen=%i\n", (tmp >> 16) & 0xf);
     return 0;
 }
 
 

Quoted 5 lines

--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Tim,

Quoted 5 lines · Roberto Fichera

Quoted 4 lines · Fabio Estevam

Quoted 2 lines · Roberto Fichera

Just to say that I've fixed the problem by asserting PERST before to drop PCIe refclk and enable power down. PERST is finally released at the usual place.

Quoted 4 lines

Quoted 1 line

Excellent! Do you plan to submit a patch to fix this issue?

I don't know, in my case the problem was related to the XIO2001 that require PERST to be asserted before to drop PCIe refclk as reported by its datasheet:

Does your board detect XIO2001 bridge with kernel 4.4.x or do you also need something like Roberto's changes below?

Fabio,

The board combination I have where an XIO2001 is connected directly to an IMX6 is a bit different from Roberto's setup. In our configuration the XIO2001 is on an 'expansion' board that its own local PCI clock generation. So, in my case the XIO2001 always has a valid clock before/during/after its reset. This is different from Roberto's scenario. I do recall running into an issue with the XIO2001 on another product with a different host controller that had to do with noise on the clk prior to its reset being asserted so I am not too surprised at what Roberto has found.

I don't specifically see an issue with a change that asserts PCI_RST# before the CLK gets enabled then de-asserts it after at least 100ms has expired from clock enable - I think that actually follows the specs wording closer than what we currently do (turning o the clock prior to assert/de-assert reset). However I get very nervous at any change to the IMX6 PCIe init. We have found it to be very finicky because of the lack of a proper reset.

Roberto,

Did you require the changes regarding Gen2 negotiation? My IMX6+XIO2001 links reliably at Gen1 which makes sense for that chip.

Quoted 12 lines · Tim Harvey

Fabio,

The board combination I have where an XIO2001 is connected directly to an IMX6 is a bit different from Roberto's setup. In our configuration the XIO2001 is on an 'expansion' board that its own local PCI clock generation. So, in my case the XIO2001 always has a valid clock before/during/after its reset. This is different from Roberto's scenario. I do recall running into an issue with the XIO2001 on another product with a different host controller that had to do with noise on the clk prior to its reset being asserted so I am not too surprised at what Roberto has found.

Quoted 7 lines

I don't specifically see an issue with a change that asserts PCI_RST# before the CLK gets enabled then de-asserts it after at least 100ms has expired from clock enable - I think that actually follows the specs wording closer than what we currently do (turning o the clock prior to assert/de-assert reset). However I get very nervous at any change to the IMX6 PCIe init. We have found it to be very finicky because of the lack of a proper reset.

Would this be the minimal change to get Roberto's setup working with 4.5?

drivers/pci/host/pci-imx6.c +9 -0

@@ -232,6 +232,15 @@ static int imx6_pcie_assert_core_reset(struct
 pcie_port *pp)
        u32 val, gpr1, gpr12;
 
        /*
+        * Some PCI bridges such as TI XIO2001 require PERST to be
+        * asserted before enabling the PCIe ref_clk, otherwise it will
+        * get "confused" and the PCIe link state will stuck in POLL_STATE
+        */
+
+       if (gpio_is_valid(imx6_pcie->reset_gpio))
+               gpiod_set_value_cansleep(imx6_pcie->reset_gpio, 0);
+
+       /*
         * If the bootloader already enabled the link we need some special
         * handling to get the core back into a state where it is safe to

* touch it for configuration. As there is no dedicated reset signal

drivers/pci/host/pci-imx6.c +0 -1

@@ -305,7 +314,6 @@ static int imx6_pcie_deassert_core_reset(struct
 pcie_port *pp)
 
        /* Some boards don't have PCIe reset GPIO. */
        if (imx6_pcie->reset_gpio) {
-               gpiod_set_value_cansleep(imx6_pcie->reset_gpio, 0);
                msleep(100);
                gpiod_set_value_cansleep(imx6_pcie->reset_gpio, 1);

        }

Quoted 4 lines

Roberto,

Did you require the changes regarding Gen2 negotiation? My IMX6+XIO2001 links reliably at Gen1 which makes sense for that chip.

Yes, it would be nice if Roberto could clarify if the Gen2 changes are needed or not.

Also, is this change also really required?

     regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR1,
             IMX6Q_GPR1_PCIE_TEST_PD, 1 << 18);
+    udelay(10);
     regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR1,
             IMX6Q_GPR1_PCIE_REF_CLK_EN, 0 << 16);

Indeed, it will :-) !

Quoted 1 line · Roberto Fichera

Indeed, it will :-) !

Thanks for confirming, Roberto.

Would you like to submit this patch formally? Or would you like me to do it?

Please let me know.

Quoted 3 lines

Would you like to submit this patch formally? Or would you like me to do it?

Please let me know.

Please do it for me ;-)

Quoted 6 lines · Fabio Estevam

Tim,

Quoted 3 lines · Roberto Fichera

Quoted 2 lines · Fabio Estevam

On Tue, Mar 15, 2016 at 8:08 AM, Roberto Fichera <[email protected]> wrote:

Quoted 8 lines

Quoted 5 lines

Quoted 3 lines

Quoted 2 lines

Just to say that I've fixed the problem by asserting PERST before to drop PCIe refclk and enable power down. PERST is finally released at the usual place.

Excellent! Do you plan to submit a patch to fix this issue?

I don't know, in my case the problem was related to the XIO2001 that require PERST to be asserted before to drop PCIe refclk as reported by its datasheet:

Does your board detect XIO2001 bridge with kernel 4.4.x or do you also need something like Roberto's changes below?

Fabio,

The board combination I have where an XIO2001 is connected directly to an IMX6 is a bit different from Roberto's setup. In our configuration the XIO2001 is on an 'expansion' board that its own local PCI clock generation. So, in my case the XIO2001 always has a valid clock before/during/after its reset. This is different from Roberto's scenario. I do recall running into an issue with the XIO2001 on another product with a different host controller that had to do with noise on the clk prior to its reset being asserted so I am not too surprised at what Roberto has found.

I don't specifically see an issue with a change that asserts PCI_RST# before the CLK gets enabled then de-asserts it after at least 100ms has expired from clock enable - I think that actually follows the specs wording closer than what we currently do (turning o the clock prior to assert/de-assert reset). However I get very nervous at any change to the IMX6 PCIe init. We have found it to be very finicky because of the lack of a proper reset.

Roberto,

Did you require the changes regarding Gen2 negotiation? My IMX6+XIO2001 links reliably at Gen1 which makes sense for that chip.

Regards,

Tim

Hi There,

Working on a custom iMX6q board I'm getting a PCIe phy link never came up, even if uboot seems detecting everything ok. My DTS is enabling PCIe with

&pcie {
    pinctrl-names = "default";
    pinctrl-0 = <&pinctrl_pcie_reset>;
    reset-gpio = <&gpio7 12 0>;
    status = "okay";
};

The PCIe is connected to a PCIe-to-PCI TI XIO2001. The XIO2001 power is controlled by GPIO_9 and the corresponding fixed regulator is set as

		reg_pcie: regulator@4 {
			compatible = "regulator-fixed";
			reg = <4>;
			pinctrl-names = "default";
			pinctrl-0 = <&pinctrl_pcie_reg>;
			regulator-name = "MPCIE_3V3";
			regulator-min-microvolt = <3300000>;
			regulator-max-microvolt = <3300000>;
			gpio = <&gpio1 9 0>;
			regulator-always-on;
			enable-active-high;
		};

so I'd like to know if there is any other special setup to do in order to get it to work on a v4.4.x kernel. Or anyway how to debug it.

Any suggestion?

Hi Roberto,

Am Dienstag, den 01.03.2016, 19:47 +0100 schrieb Roberto Fichera:

Quoted 28 lines

Hi There,

Working on a custom iMX6q board I'm getting a PCIe phy link never came up, even if uboot seems detecting everything ok. My DTS is enabling PCIe with

&pcie {
    pinctrl-names = "default";
    pinctrl-0 = <&pinctrl_pcie_reset>;
    reset-gpio = <&gpio7 12 0>;
    status = "okay";
};

The PCIe is connected to a PCIe-to-PCI TI XIO2001. The XIO2001 power is controlled by GPIO_9 and the corresponding fixed regulator is set as

		reg_pcie: regulator@4 {
			compatible = "regulator-fixed";
			reg = <4>;
			pinctrl-names = "default";
			pinctrl-0 = <&pinctrl_pcie_reg>;
			regulator-name = "MPCIE_3V3";
			regulator-min-microvolt = <3300000>;
			regulator-max-microvolt = <3300000>;
			gpio = <&gpio1 9 0>;
			regulator-always-on;
			enable-active-high;
		};

Quoted 4 lines

so I'd like to know if there is any other special setup to do in order to get it to work on a v4.4.x kernel. Or anyway how to debug it.

Any suggestion?

Is this a regression from earlier kernel versions?

If so, can you please revert 5c5fb40de8f14 (PCI: imx6: Add support for active-low reset GPIO) and see if this helps?

Regards,
Lucas

Is this a regression from earlier kernel versions?

If so, can you please revert 5c5fb40de8f14 (PCI: imx6: Add support for active-low reset GPIO) and see if this helps?

Quoted 4 lines · Lucas Stach

Is this a regression from earlier kernel versions?

If so, can you please revert 5c5fb40de8f14 (PCI: imx6: Add support for active-low reset GPIO) and see if this helps?

This commit has been applied to 4.5-rc1. Roberto is using 4.4.x.

--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html