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

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

[Roberto Fichera]

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

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

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

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

> 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

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

[Bjorn Helgaas]

[+cc Richard, Lucas]

On Wed, Mar 02, 2016 at 06:13:11PM +0100, Roberto Fichera wrote:
> 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.
> 
> > 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 majordomo@vger.kernel.org
> > 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Richard Zhu]

> -----Original Message-----
> From: Bjorn Helgaas [mailto:helgaas@kernel.org]
> Sent: Thursday, March 03, 2016 3:57 AM
> To: Roberto Fichera
> Cc: linux-pci@vger.kernel.org; Richard Zhu; Lucas Stach
> Subject: Re: iMX6q PCIe phy link never came up on kernel v4.4.x
> 
> [+cc Richard, Lucas]
> 
> On Wed, Mar 02, 2016 at 06:13:11PM +0100, Roberto Fichera wrote:
> > 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.
> >
> > > 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?
> > >
[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.

> > > 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 majordomo@vger.kernel.org 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 majordomo@vger.kernel.org More majordomo
> > info at  http://vger.kernel.org/majordomo-info.html

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

[Roberto Fichera]

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

Hi Richard,

>> -----Original Message-----
>> From: Bjorn Helgaas [mailto:helgaas@kernel.org]
>> Sent: Thursday, March 03, 2016 3:57 AM
>> To: Roberto Fichera
>> Cc: linux-pci@vger.kernel.org; Richard Zhu; Lucas Stach
>> Subject: Re: iMX6q PCIe phy link never came up on kernel v4.4.x
>>
>> [+cc Richard, Lucas]
>>
>> On Wed, Mar 02, 2016 at 06:13:11PM +0100, Roberto Fichera wrote:
>>> 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.
>>>
>>>> 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?
>>>>
> [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.

Which register do you need to dump?

>>>> 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 majordomo@vger.kernel.org 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 majordomo@vger.kernel.org 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

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

[Richard Zhu]

> -----Original Message-----
> From: Roberto Fichera [mailto:kernel@tekno-soft.it]
> Sent: Thursday, March 03, 2016 5:30 PM
> To: Richard Zhu; Bjorn Helgaas
> Cc: linux-pci@vger.kernel.org; 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,
> 
> >> -----Original Message-----
> >> From: Bjorn Helgaas [mailto:helgaas@kernel.org]
> >> Sent: Thursday, March 03, 2016 3:57 AM
> >> To: Roberto Fichera
> >> Cc: linux-pci@vger.kernel.org; Richard Zhu; Lucas Stach
> >> Subject: Re: iMX6q PCIe phy link never came up on kernel v4.4.x
> >>
> >> [+cc Richard, Lucas]
> >>
> >> On Wed, Mar 02, 2016 at 06:13:11PM +0100, Roberto Fichera wrote:
> >>> 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.
> >>>
> >>>> 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?
> >>>>
> > [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.
> 
> Which register do you need to dump?
> 
[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.

> >>>> 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 majordomo@vger.kernel.org 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 majordomo@vger.kernel.org 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 majordomo@vger.kernel.org More majordomo
> > info at  http://vger.kernel.org/majordomo-info.html
> >

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

[Roberto Fichera]

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

Hi Richard,

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

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

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

[Roberto Fichera]

On 03/03/2016 11:55 AM, Roberto Fichera wrote:
> On 03/03/2016 10:39 AM, Richard Zhu wrote:
>
> Hi Richard,
>
>> [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
>>>> 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

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


>
> [    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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

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

[Roberto Fichera]

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.

> On 03/03/2016 11:55 AM, Roberto Fichera wrote:
>> On 03/03/2016 10:39 AM, Richard Zhu wrote:
>>
>> Hi Richard,
>>
>>> [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
>>>>> 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
> 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
>>>> 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
>
>
>> [    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 majordomo@vger.kernel.org
>> 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

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

[Richard Zhu]

> -----Original Message-----
> From: Roberto Fichera [mailto:kernel@tekno-soft.it]
> Sent: Friday, March 04, 2016 2:34 AM
> To: Richard Zhu; Bjorn Helgaas
> Cc: linux-pci@vger.kernel.org; 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.
> 
[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 11:55 AM, Roberto Fichera wrote:
> >> On 03/03/2016 10:39 AM, Richard Zhu wrote:
> >>
> >> Hi Richard,
> >>
> >>> [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
> >>>>> 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
> > 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
> >>>> 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
> >
> >
> >> [    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 majordomo@vger.kernel.org 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 majordomo@vger.kernel.org More majordomo
> > info at  http://vger.kernel.org/majordomo-info.html
> >

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

[Roberto Fichera]

On 03/04/2016 08:11 AM, Richard Zhu wrote:

Hi Richard,

>> -----Original Message-----
>> > From: Roberto Fichera [mailto:kernel@tekno-soft.it]
>> > Sent: Friday, March 04, 2016 2:34 AM
>> > To: Richard Zhu; Bjorn Helgaas
>> > Cc: linux-pci@vger.kernel.org; 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.
>> > 
> [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.
>
Yes! I've applied the logic below to properly reset the XIO2001

int imx6_pcie_toggle_power(struct pcie_port *pp)
{
    struct imx6_pcie *imx6_pcie = to_imx6_pcie(pp);

        /*
         * TI XIO2001 Power Up procedure:
         *
         * 1) Assert both GRST# and PERST# without power voltages
         */
    gpio_set_value(imx6_pcie->pwr_gpio, 0);
    gpio_set_value(imx6_pcie->reset_gpio, 0);
    gpio_set_value(imx6_pcie->grst_gpio, 0);
    usleep_range(10000, 20000);

        /*
         * 2) Apply 1.5V and 3.3V voltages
         */
    gpio_set_value(imx6_pcie->pwr_gpio, 1);
    usleep_range(10000, 20000);

        /*
         * 3) Deassert GRST#
         */
    gpio_set_value(imx6_pcie->grst_gpio, 1);

        /*
         * 4) After that we should apply a stable PCIe reference clock
         */
    return 0;
}

and in the imx6_pcie_deassert_core_reset() I have:

static int imx6_pcie_deassert_core_reset(struct pcie_port *pp)
{
    struct imx6_pcie *imx6_pcie = to_imx6_pcie(pp);
    int ret;

-->>>    imx6_pcie_toggle_power(pp);

    ret = clk_prepare_enable(imx6_pcie->pcie_phy);
    if (ret) {
        dev_err(pp->dev, "unable to enable pcie_phy clock\n");
        goto err_pcie_phy;
    }
...
...
    /* allow the clocks to stabilize */
    usleep_range(200, 500);

    /* Some boards don't have PCIe reset GPIO. */
    if (gpio_is_valid(imx6_pcie->reset_gpio)) {
        gpio_set_value(imx6_pcie->reset_gpio, 0);
        msleep(100);
        gpio_set_value(imx6_pcie->reset_gpio, 1);
    }
    return 0;

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

[Roberto Fichera]

On 03/03/2016 07:34 PM, Roberto Fichera wrote:
> 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.

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?

[    0.237052] PCI host bridge /soc/pcie@0x01000000 ranges:
[    0.237070]   No bus range found for /soc/pcie@0x01000000, using [bus 00-ff]
[    0.237119]   err 0x01f00000..0x01f7ffff -> 0x01f00000
[    0.237157]    IO 0x01f80000..0x01f8ffff -> 0x00000000
[    0.237241]   MEM 0x01000000..0x01efffff -> 0x01000000
[    0.437893] imx6q-pcie 1ffc000.pcie: >>> GPR[1]: 0x48611005
[    0.437913] imx6q-pcie 1ffc000.pcie: >>> GPR[8]: 0xfffd4000
[    0.437927] imx6q-pcie 1ffc000.pcie: >>> GPR[12]: 0x0f004000
[    0.437945] imx6q-pcie 1ffc000.pcie: >>> ANA_MISC1: 0x8000040b
[    0.437959] imx6q-pcie 1ffc000.pcie: >>> PLL_ENET: 0x80182001
[    0.437973] imx6q-pcie 1ffc000.pcie: >>> CCM_CCGR4 (0xf08f8078): 0x00fff303
[    0.437989] imx6q-pcie 1ffc000.pcie: >>> CCM_CCGR5 (0xf08f807c): 0x0f0000c3
[    0.438003] imx6q-pcie 1ffc000.pcie: >>> PCIE_RC_LCR (0xf08f007c): 0x0011cc11
[    4.437756] imx6q-pcie 1ffc000.pcie: phy link never came up
[    4.437774] imx6q-pcie 1ffc000.pcie: LTSSM current state: 0x2 (S_POLL_ACTIVE)
[    4.437786] imx6q-pcie 1ffc000.pcie: PIPE transmit K indication: 0

>
>> On 03/03/2016 11:55 AM, Roberto Fichera wrote:
>>> On 03/03/2016 10:39 AM, Richard Zhu wrote:
>>>
>>> Hi Richard,
>>>
>>>> [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
>>>>>> 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
>> 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
>>>>> 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
>>
>>
>>> [    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 majordomo@vger.kernel.org
>>> 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 majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>

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

[Lucas Stach]

Am Dienstag, den 08.03.2016, 15:39 +0100 schrieb Roberto Fichera:
> On 03/03/2016 07:34 PM, Roberto Fichera wrote:
> > 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.
> 
> 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

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

[Roberto Fichera]

On 03/08/2016 03:53 PM, Lucas Stach wrote:
> Am Dienstag, den 08.03.2016, 15:39 +0100 schrieb Roberto Fichera:
>> On 03/03/2016 07:34 PM, Roberto Fichera wrote:
>>> 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.
>> 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.

Ok! Will do!

>
> Regards,
> Lucas
>
>

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

[Roberto Fichera]

On 03/08/2016 03:53 PM, Lucas Stach wrote:
> Am Dienstag, den 08.03.2016, 15:39 +0100 schrieb Roberto Fichera:
>> > On 03/03/2016 07:34 PM, Roberto Fichera wrote:
>>> > > 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.
>> > 
>> > 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).

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.

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

[Roberto Fichera]

On 03/10/2016 06:35 PM, Roberto Fichera wrote:
> On 03/08/2016 03:53 PM, Lucas Stach wrote:
>> Am Dienstag, den 08.03.2016, 15:39 +0100 schrieb Roberto Fichera:
>>>> On 03/03/2016 07:34 PM, Roberto Fichera wrote:
>>>>>> 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.
>>>> 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).
> 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?

Good progress! Once kernel booted, I'm still getting the usual PCIe link not coming up:


[    0.236946] PCI host bridge /soc/pcie@0x01000000 ranges:
[    0.236969]   No bus range found for /soc/pcie@0x01000000, using [bus 00-ff]
[    0.237018]   err 0x01f00000..0x01f7ffff -> 0x01f00000
[    0.237056]    IO 0x01f80000..0x01f8ffff -> 0x00000000
[    0.237140]   MEM 0x01000000..0x01efffff -> 0x01000000
[    3.339021] imx6q-pcie 1ffc000.pcie: phy link never came up
[    3.339599] imx6q-pcie 1ffc000.pcie: PCI host bridge to bus 0000:00
[    3.339622] pci_bus 0000:00: root bus resource [bus 00-ff]
[    3.339642] pci_bus 0000:00: root bus resource [??? 0x01f00000-0x01f7ffff flags 0x0]
[    3.339659] pci_bus 0000:00: root bus resource [io  0x0000-0xffff]
[    3.339672] pci_bus 0000:00: root bus resource [mem 0x01000000-0x01efffff]

but when I trigger a pcie bus rescan with an "echo 1 > /sys/bus/pci/rescan" then I finally get:

root@voneus-janas-imx6q:/sys/bus/pci# echo 1 > rescan
[  12.306722] pci 0000:01:00.0: bridge configuration invalid ([bus 00-00]), reconfiguring
[  12.321690] PCI: bus2: Fast back to back transfers disabled
[  12.327421] pci_bus 0000:02: [bus 02] partially hidden behind bridge 0000:01 [bus 01]
[  12.335377] pcieport 0000:00:00.0: bridge has subordinate 01 but max busn 02
[  12.342691] pcieport 0000:00:00.0: BAR 8: assigned [mem 0x01200000-0x012fffff]
[  12.350041] pcieport 0000:00:00.0: BAR 7: assigned [io  0x1000-0x1fff]
[  12.356754] pci 0000:01:00.0: BAR 8: assigned [mem 0x01200000-0x012fffff]
[  12.363650] pci 0000:01:00.0: BAR 7: assigned [io  0x1000-0x1fff]
[  12.369858] pci 0000:02:04.0: BAR 1: assigned [mem 0x01200000-0x01200fff]
[  12.376715] pci 0000:02:04.0: BAR 0: assigned [io  0x1000-0x1007]
[  12.382939] pci 0000:01:00.0: PCI bridge to [bus 02]
[  12.387960] pci 0000:01:00.0:   bridge window [io  0x1000-0x1fff]
[  12.394182] pci 0000:01:00.0:   bridge window [mem 0x01200000-0x012fffff]

root@voneus-janas-imx6q:/sys/bus/pci# lspci -v
00:00.0 PCI bridge: Synopsys, Inc. Device abcd (rev 01) (prog-if 00 [Normal decode])
        Flags: bus master, fast devsel, latency 0, IRQ 290
        Memory at 01000000 (32-bit, non-prefetchable) [size=1M]
        Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
        [virtual] Expansion ROM at 01100000 [disabled] [size=64K]
        Capabilities: [40] Power Management version 3
        Capabilities: [50] MSI: Enable+ Count=1/1 Maskable+ 64bit+
        Capabilities: [70] Express Root Port (Slot-), MSI 00
        Capabilities: [100] Advanced Error Reporting
        Capabilities: [140] Virtual Channel
        Kernel driver in use: pcieport
lspci: Unable to load libkmod resources: error -12

01:00.0 PCI bridge: Texas Instruments XIO2001 PCI Express-to-PCI Bridge (prog-if 00 [Normal decode])
        Flags: fast devsel
        Bus: primary=01, secondary=02, subordinate=02, sec-latency=0
        I/O behind bridge: 00001000-00001fff
        Memory behind bridge: 01200000-012fffff
        Capabilities: [40] Subsystem: Device 0000:0000
        Capabilities: [48] Power Management version 3
        Capabilities: [50] MSI: Enable- Count=1/16 Maskable- 64bit+
        Capabilities: [70] Express PCI-Express to PCI/PCI-X Bridge, MSI 00
        Capabilities: [100] Advanced Error Reporting

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]
        Flags: medium devsel, IRQ 255
        I/O ports at 1000 [disabled] [size=8]
        Memory at 01200000 (32-bit, non-prefetchable) [disabled] [size=4K]
        Capabilities: [40] Power Management version 2

I've also tried to increase the polling loop timeout, but doesn't change anything.

Any suggestion?

>
> Cheers,
> Roberto Fichera.

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

[Roberto Fichera]

On 03/14/2016 09:44 AM, Roberto Fichera wrote:
> On 03/10/2016 06:35 PM, Roberto Fichera wrote:
>> > On 03/08/2016 03:53 PM, Lucas Stach wrote:
>>> >> Am Dienstag, den 08.03.2016, 15:39 +0100 schrieb Roberto Fichera:
>>>>> >>>> On 03/03/2016 07:34 PM, Roberto Fichera wrote:
>>>>>>> >>>>>> 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.
>>>>> >>>> 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).
>> > 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
[    0.369347] pci 0000:01:00.0: bridge configuration invalid ([bus 00-00]), reconfiguring
[    0.369844] pci_bus 0000:02: busn_res: can not insert [bus 02-ff] under [bus 01] (conflicts with (null) [bus 01])
[    0.377975] pci 0000:02:04.0: [1397:08b4] type 00 class 0x020400
[    0.378120] pci 0000:02:04.0: reg 0x10: [io  0x0000-0x0007]
[    0.378174] pci 0000:02:04.0: reg 0x14: [mem 0x00000000-0x00000fff]
[    0.378536] pci 0000:02:04.0: supports D1 D2
[    0.378550] pci 0000:02:04.0: PME# supported from D0 D1 D2 D3hot
[    0.379453] PCI: bus2: Fast back to back transfers disabled
[    0.379474] pci_bus 0000:02: busn_res: [bus 02-ff] end is updated to 02
[    0.379494] pci_bus 0000:02: busn_res: can not insert [bus 02] under [bus 01] (conflicts with (null) [bus 01])
[    0.379524] pci_bus 0000:02: [bus 02] partially hidden behind bridge 0000:01 [bus 01]
[    0.379548] pci 0000:00:00.0: bridge has subordinate 01 but max busn 02
[    0.379837] pci 0000:00:00.0: BAR 0: assigned [mem 0x01000000-0x010fffff]
[    0.379865] pci 0000:00:00.0: BAR 8: assigned [mem 0x01100000-0x011fffff]
[    0.379884] pci 0000:00:00.0: BAR 6: assigned [mem 0x01200000-0x0120ffff pref]
[    0.379900] pci 0000:00:00.0: BAR 7: assigned [io  0x1000-0x1fff]
[    0.379927] pci 0000:01:00.0: BAR 8: assigned [mem 0x01100000-0x011fffff]
[    0.379942] pci 0000:01:00.0: BAR 7: assigned [io  0x1000-0x1fff]
[    0.379963] pci 0000:02:04.0: BAR 1: assigned [mem 0x01100000-0x01100fff]
[    0.379998] pci 0000:02:04.0: BAR 0: assigned [io  0x1000-0x1007]
[    0.380030] pci 0000:01:00.0: PCI bridge to [bus 02]
[    0.380054] pci 0000:01:00.0:   bridge window [io  0x1000-0x1fff]
[    0.380091] pci 0000:01:00.0:   bridge window [mem 0x01100000-0x011fffff]
[    0.380149] pci 0000:00:00.0: PCI bridge to [bus 01]
[    0.380164] pci 0000:00:00.0:   bridge window [io  0x1000-0x1fff]
[    0.380183] pci 0000:00:00.0:   bridge window [mem 0x01100000-0x011fffff]
[    0.380950] pcieport 0000:00:00.0: Signaling PME through PCIe PME interrupt
[    0.380970] pci 0000:01:00.0: Signaling PME through PCIe PME interrupt
[    0.380983] pci 0000:02:04.0: Signaling PME through PCIe PME interrupt
[    0.381003] pcie_pme 0000:00:00.0:pcie01: service driver pcie_pme loaded
[    0.381407] aer 0000:00:00.0:pcie02: service driver aer loaded

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

[Bjorn Helgaas]

On Tue, Mar 15, 2016 at 12:08:14PM +0100, Roberto Fichera wrote:
> On 03/14/2016 09:44 AM, Roberto Fichera wrote:
> > On 03/10/2016 06:35 PM, Roberto Fichera wrote:
> >> > On 03/08/2016 03:53 PM, Lucas Stach wrote:
> >>> >> Am Dienstag, den 08.03.2016, 15:39 +0100 schrieb Roberto Fichera:
> >>>>> >>>> On 03/03/2016 07:34 PM, Roberto Fichera wrote:
> >>>>>>> >>>>>> 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.
> >>>>> >>>> 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).
> >> > 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.

Glad to hear that.

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

Looks like some kind of bug here.

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

What an anachronism to see these "Fast back to back transfers"
messages on a PCIe system where Fast Back-to-Back is meaningless.
That code in pcibios_fixup_bus() was always generic code that should
have been in the PCI core rather than in arch-specific code.  It'd be nice
if somebody would clean that up someday.

Bjorn

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

[Fabio Estevam]

On Tue, Mar 15, 2016 at 8:08 AM, Roberto Fichera <kernel@tekno-soft.it> wrote:

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

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

[Roberto Fichera]

On 03/15/2016 03:10 PM, Fabio Estevam wrote:
> On Tue, Mar 15, 2016 at 8:08 AM, Roberto Fichera <kernel@tekno-soft.it> wrote:
>
>> 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:

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

@@ -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;
 }


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

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

[Fabio Estevam]

Tim,

On Tue, Mar 15, 2016 at 11:29 AM, Roberto Fichera <kernel@tekno-soft.it> wrote:
> On 03/15/2016 03:10 PM, Fabio Estevam wrote:
>> On Tue, Mar 15, 2016 at 8:08 AM, Roberto Fichera <kernel@tekno-soft.it> wrote:
>>
>>> 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?


> @@ -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
>
> @@ -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;
>  }
>
>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>

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

[Tim Harvey]

On Wed, Mar 16, 2016 at 7:19 AM, Fabio Estevam <festevam@gmail.com> wrote:
> Tim,
>
> On Tue, Mar 15, 2016 at 11:29 AM, Roberto Fichera <kernel@tekno-soft.it> wrote:
>> On 03/15/2016 03:10 PM, Fabio Estevam wrote:
>>> On Tue, Mar 15, 2016 at 8:08 AM, Roberto Fichera <kernel@tekno-soft.it> wrote:
>>>
>>>> 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

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

[Fabio Estevam]

On Wed, Mar 16, 2016 at 6:33 PM, Tim Harvey <tharvey@gateworks.com> wrote:

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

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

--- a/drivers/pci/host/pci-imx6.c
+++ b/drivers/pci/host/pci-imx6.c
@@ -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
@@ -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);
        }

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

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

[Roberto Fichera]

On 03/16/2016 11:12 PM, Fabio Estevam wrote:
> On Wed, Mar 16, 2016 at 6:33 PM, Tim Harvey <tharvey@gateworks.com> wrote:
>
>> 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.
> Would this be the minimal change to get Roberto's setup working with 4.5?
>
> --- a/drivers/pci/host/pci-imx6.c
> +++ b/drivers/pci/host/pci-imx6.c
> @@ -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
> @@ -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);
>         }

Indeed, it will :-) !

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

Nope! I've removed them.

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

This one is also not required.

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

[Fabio Estevam]

On Thu, Mar 17, 2016 at 5:32 AM, Roberto Fichera <kernel@tekno-soft.it> wrote:

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

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

[Roberto Fichera]

On 03/17/2016 02:28 PM, Fabio Estevam wrote:
> On Thu, Mar 17, 2016 at 5:32 AM, Roberto Fichera <kernel@tekno-soft.it> wrote:
>
>> 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.

Please do it for me ;-)

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

[Fabio Estevam]

On Thu, Mar 17, 2016 at 11:14 AM, Roberto Fichera <kernel@tekno-soft.it> wrote:

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

Ok, I will submit it after 4.6-rc1 is released. Thanks

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

[Roberto Fichera]

On 03/16/2016 10:33 PM, Tim Harvey wrote:
> On Wed, Mar 16, 2016 at 7:19 AM, Fabio Estevam <festevam@gmail.com> wrote:
>> Tim,
>>
>> On Tue, Mar 15, 2016 at 11:29 AM, Roberto Fichera <kernel@tekno-soft.it> wrote:
>>> On 03/15/2016 03:10 PM, Fabio Estevam wrote:
>>>> On Tue, Mar 15, 2016 at 8:08 AM, Roberto Fichera <kernel@tekno-soft.it> wrote:
>>>>
>>>>> 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.
You are right, I did all my tests again removing all applied changes related
to Gen2 negotiation, and indeed the links goes up correctly at Gen1.

>
> Regards,
>
> Tim
>

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

[Richard Zhu]

PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBSb2JlcnRvIEZpY2hlcmEgW21h
aWx0bzprZXJuZWxAdGVrbm8tc29mdC5pdF0NCj4gU2VudDogVHVlc2RheSwgTWFyY2ggMTUsIDIw
MTYgNzowOCBQTQ0KPiBUbzogTHVjYXMgU3RhY2gNCj4gQ2M6IFJpY2hhcmQgWmh1OyBCam9ybiBI
ZWxnYWFzOyBsaW51eC1wY2lAdmdlci5rZXJuZWwub3JnOyBSaWNoYXJkIFpodTsgRmFiaW8NCj4g
RXN0ZXZhbQ0KPiBTdWJqZWN0OiBSZTogaU1YNnEgUENJZSBwaHkgbGluayBuZXZlciBjYW1lIHVw
IG9uIGtlcm5lbCB2NC40LngNCj4gDQo+IE9uIDAzLzE0LzIwMTYgMDk6NDQgQU0sIFJvYmVydG8g
RmljaGVyYSB3cm90ZToNCj4gPiBPbiAwMy8xMC8yMDE2IDA2OjM1IFBNLCBSb2JlcnRvIEZpY2hl
cmEgd3JvdGU6DQo+ID4+ID4gT24gMDMvMDgvMjAxNiAwMzo1MyBQTSwgTHVjYXMgU3RhY2ggd3Jv
dGU6DQo+ID4+PiA+PiBBbSBEaWVuc3RhZywgZGVuIDA4LjAzLjIwMTYsIDE1OjM5ICswMTAwIHNj
aHJpZWIgUm9iZXJ0byBGaWNoZXJhOg0KPiA+Pj4+PiA+Pj4+IE9uIDAzLzAzLzIwMTYgMDc6MzQg
UE0sIFJvYmVydG8gRmljaGVyYSB3cm90ZToNCj4gPj4+Pj4+PiA+Pj4+Pj4gT24gMDMvMDMvMjAx
NiAwMzozNCBQTSwgUm9iZXJ0byBGaWNoZXJhIHdyb3RlOg0KPiA+Pj4+Pj4+ID4+Pj4+Pg0KPiA+
Pj4+Pj4+ID4+Pj4+PiBJJ3ZlIGFsc28gY2hlY2tlZCBjbG9jaywgcGxsLCBQTVVfTUlTQzEgYW5k
IENDR1JbNDVdDQo+ID4+Pj4+Pj4gPj4+Pj4+IHJlZ2lzdGVycywgYWxsIGxvb2tzIGZpbmUgYW5k
IGV4YWN0bHkgZXF1YWwgdG8gdWJvb3Qgc2V0dGluZ3MuDQo+ID4+Pj4+Pj4gPj4+Pj4+DQo+ID4+
Pj4+Pj4gPj4+Pj4+IEhvd2V2ZXIgSSdtIGludmVzdGlnYXRpbmcgYSBwb3NzaWJsZSBIVyBpc3N1
ZSBpbiB0aGUgTERWUw0KPiA+Pj4+Pj4+ID4+Pj4+PiBwYWQgd2lyaW5nIGFnYWluc3QgdGhlIGJy
aWRnZSBYSU8yMDAxLiBMZXQncyBzZWUgb25jZSB0aGlzIGlzDQo+IGFsc28gY2xhcmlmaWVkLg0K
PiA+Pj4+PiA+Pj4+IE91ciBIVyBlbmdpbmVlciBoYXMgYXBwbGllZCBhIGZpeCB0byBMVkRTIHZz
IFhJTzIwMDEgY2xvY2sgd2lyaW5nLg0KPiBIb3dldmVyIEknbSBzdGlsbCBnZXR0aW5nIHRoZSBz
YW1lIHByb2JsZW0uDQo+ID4+Pj4+ID4+Pj4NCj4gPj4+Pj4gPj4+PiBJJ3ZlIHRyaWVkIHRvIGJv
b3QgYSBrZXJuZWwgd2l0aCB1Ym9vdCBub3Qgc2V0dGluZyB1cCB0aGUgUENJZSBzdWJzeXMNCj4g
YW5kIGJlbG93IHRoZXJlIGlzIHRoZSByZXN1bHRpbmcga2VybmVsIGxvZy4NCj4gPj4+Pj4gPj4+
PiBOb3RlIHRoYXQgdGhlIENDR1I1IGRvZXNuJ3Qgc2V0IHRoZSBDRzIgZmllbGQgYXNzb2NpYXRl
ZCB0bw0KPiA+Pj4+PiA+Pj4+IHNhdGFfY2xrX2VuYWJsZS4gSSB0aGluayB0aGlzIGZpZWxkIHNo
b3VsZCBiZSBzZXQgYWxsIDEgdG8gZW5hYmxlIHRoZQ0KPiBTQVRBIHJlZiBhdCAxMDBNSHosIHJp
Z2h0Pw0KPiA+Pj4+PiA+Pj4+DQo+ID4+PiA+PiBObywgdGhlIHJlZmVyZW5jZSBtYW51YWwgaXMg
YSBiaXQgY29uZnVzaW5nIGFib3V0IHRoaXMsIGJ1dCB0aGUNCj4gPj4+ID4+IExWRFMxIGNsb2Nr
IG91dHB1dCBpcyBkcml2ZW4gYnkgc2F0YV9yZWZfMTAwbWh6LCBub3QgdGhlIHNhdGFfY2xrIGdh
dGUuDQo+ID4+PiA+Pg0KPiA+Pj4gPj4gU28gdGhlIG9ubHkgdGhpbmcgdGhhdCBuZWVkcyB0byBi
ZSBlbmFibGVkIGZvciBMVkRTIGNsb2NrIG91dHB1dA0KPiA+Pj4gPj4gaXMgdGhlIDEwME1IeiBj
bG9jayBvdXRwdXQgZnJvbSBQTEwgRU5FVC4gKFJlZ2lzdGVyDQo+ID4+PiA+PiBDQ01fQU5BTE9H
X1BMTF9FTkVUbiBiaXQgMjApLg0KPiA+PiA+IEd1eXMhIE5vIG1vcmUgaWRlYSB3aGVyZSB0byBs
b29rIGF0ISBTdGlsbCBnZXR0aW5nIFBDSWUgbGluaw0KPiA+PiA+IHJlYWNoaW5nIEwwIHN0YXRl
IHVuZGVyIHVib290IGJ1dCBkb2Vzbid0IHByb2dyZXNzIG1vcmUgdGhhbg0KPiA+PiA+IFBPTExf
QUNUSVZFIG9yIFBPTExfQ09NUExJQU5DRSBzdGF0ZXMgdW5kZXIga2VybmVsLg0KPiA+PiA+DQo+
ID4+ID4gQW55IGlkZWEgd2hhdCB0byBkbz8NCj4gDQo+IEp1c3QgdG8gc2F5IHRoYXQgSSd2ZSBm
aXhlZCB0aGUgcHJvYmxlbSBieSBhc3NlcnRpbmcgUEVSU1QgYmVmb3JlIHRvIGRyb3AgUENJZQ0K
PiByZWZjbGsgYW5kIGVuYWJsZSBwb3dlciBkb3duLiBQRVJTVCBpcyBmaW5hbGx5IHJlbGVhc2Vk
IGF0IHRoZSB1c3VhbCBwbGFjZS4NCj4gDQpbUmljaGFyZF0gSXQncyBncmVhdCB0byBoZWFyIGl0
Lg0KDQo+IFsgICAgMC4yMzc0NzNdIFBDSSBob3N0IGJyaWRnZSAvc29jL3BjaWVAMHgwMTAwMDAw
MCByYW5nZXM6DQo+IFsgICAgMC4yMzc0OTRdICAgTm8gYnVzIHJhbmdlIGZvdW5kIGZvciAvc29j
L3BjaWVAMHgwMTAwMDAwMCwgdXNpbmcgW2J1cyAwMC1mZl0NCj4gWyAgICAwLjIzNzU0NV0gICBl
cnIgMHgwMWYwMDAwMC4uMHgwMWY3ZmZmZiAtPiAweDAxZjAwMDAwDQo+IFsgICAgMC4yMzc1ODVd
ICAgIElPIDB4MDFmODAwMDAuLjB4MDFmOGZmZmYgLT4gMHgwMDAwMDAwMA0KPiBbICAgIDAuMjM3
NjcxXSAgIE1FTSAweDAxMDAwMDAwLi4weDAxZWZmZmZmIC0+IDB4MDEwMDAwMDANCj4gWyAgICAw
LjM1Mzg0N10gaW14NnEtcGNpZSAxZmZjMDAwLnBjaWU6IExpbms6IEdlbjIgZGlzYWJsZWQNCj4g
WyAgICAwLjM1Mzg2Nl0gaW14NnEtcGNpZSAxZmZjMDAwLnBjaWU6IExpbmsgdXAsIEdlbj0xDQo+
IFsgICAgMC4zNTQ0NDFdIGlteDZxLXBjaWUgMWZmYzAwMC5wY2llOiBQQ0kgaG9zdCBicmlkZ2Ug
dG8gYnVzIDAwMDA6MDANCj4gWyAgICAwLjM1NDQ2NV0gcGNpX2J1cyAwMDAwOjAwOiByb290IGJ1
cyByZXNvdXJjZSBbYnVzIDAwLWZmXQ0KPiBbICAgIDAuMzU0NDgzXSBwY2lfYnVzIDAwMDA6MDA6
IHJvb3QgYnVzIHJlc291cmNlIFs/Pz8gMHgwMWYwMDAwMC0weDAxZjdmZmZmDQo+IGZsYWdzIDB4
MF0NCj4gWyAgICAwLjM1NDQ5OV0gcGNpX2J1cyAwMDAwOjAwOiByb290IGJ1cyByZXNvdXJjZSBb
aW8gIDB4MDAwMC0weGZmZmZdDQo+IFsgICAgMC4zNTQ1MTNdIHBjaV9idXMgMDAwMDowMDogcm9v
dCBidXMgcmVzb3VyY2UgW21lbSAweDAxMDAwMDAwLTB4MDFlZmZmZmZdDQo+IFsgICAgMC4zNTQ2
NDBdIHBjaSAwMDAwOjAwOjAwLjA6IFsxNmMzOmFiY2RdIHR5cGUgMDEgY2xhc3MgMHgwNjA0MDAN
Cj4gWyAgICAwLjM1NDcwN10gcGNpIDAwMDA6MDA6MDAuMDogcmVnIDB4MTA6IFttZW0gMHgwMDAw
MDAwMC0weDAwMGZmZmZmXQ0KPiBbICAgIDAuMzU0NzQ1XSBwY2kgMDAwMDowMDowMC4wOiByZWcg
MHgzODogW21lbSAweDAwMDAwMDAwLTB4MDAwMGZmZmYgcHJlZl0NCj4gWyAgICAwLjM1NDkzMl0g
cGNpIDAwMDA6MDA6MDAuMDogc3VwcG9ydHMgRDENCj4gWyAgICAwLjM1NDk1Ml0gcGNpIDAwMDA6
MDA6MDAuMDogUE1FIyBzdXBwb3J0ZWQgZnJvbSBEMCBEMSBEM2hvdCBEM2NvbGQNCj4gWyAgICAw
LjM1NTcxM10gUENJOiBidXMwOiBGYXN0IGJhY2sgdG8gYmFjayB0cmFuc2ZlcnMgZGlzYWJsZWQN
Cj4gWyAgICAwLjM1NjEzOV0gcGNpIDAwMDA6MDE6MDAuMDogWzEwNGM6ODI0MF0gdHlwZSAwMSBj
bGFzcyAweDA2MDQwMA0KPiBbICAgIDAuMzU2Njg4XSBwY2kgMDAwMDowMTowMC4wOiBzdXBwb3J0
cyBEMSBEMg0KPiBbICAgIDAuMzY5MzE4XSBQQ0k6IGJ1czE6IEZhc3QgYmFjayB0byBiYWNrIHRy
YW5zZmVycyBkaXNhYmxlZA0KPiBbICAgIDAuMzY5MzQ3XSBwY2kgMDAwMDowMTowMC4wOiBicmlk
Z2UgY29uZmlndXJhdGlvbiBpbnZhbGlkIChbYnVzIDAwLTAwXSksDQo+IHJlY29uZmlndXJpbmcN
Cj4gWyAgICAwLjM2OTg0NF0gcGNpX2J1cyAwMDAwOjAyOiBidXNuX3JlczogY2FuIG5vdCBpbnNl
cnQgW2J1cyAwMi1mZl0gdW5kZXIgW2J1cw0KPiAwMV0gKGNvbmZsaWN0cyB3aXRoIChudWxsKSBb
YnVzIDAxXSkNCj4gWyAgICAwLjM3Nzk3NV0gcGNpIDAwMDA6MDI6MDQuMDogWzEzOTc6MDhiNF0g
dHlwZSAwMCBjbGFzcyAweDAyMDQwMA0KPiBbICAgIDAuMzc4MTIwXSBwY2kgMDAwMDowMjowNC4w
OiByZWcgMHgxMDogW2lvICAweDAwMDAtMHgwMDA3XQ0KPiBbICAgIDAuMzc4MTc0XSBwY2kgMDAw
MDowMjowNC4wOiByZWcgMHgxNDogW21lbSAweDAwMDAwMDAwLTB4MDAwMDBmZmZdDQo+IFsgICAg
MC4zNzg1MzZdIHBjaSAwMDAwOjAyOjA0LjA6IHN1cHBvcnRzIEQxIEQyDQo+IFsgICAgMC4zNzg1
NTBdIHBjaSAwMDAwOjAyOjA0LjA6IFBNRSMgc3VwcG9ydGVkIGZyb20gRDAgRDEgRDIgRDNob3QN
Cj4gWyAgICAwLjM3OTQ1M10gUENJOiBidXMyOiBGYXN0IGJhY2sgdG8gYmFjayB0cmFuc2ZlcnMg
ZGlzYWJsZWQNCj4gWyAgICAwLjM3OTQ3NF0gcGNpX2J1cyAwMDAwOjAyOiBidXNuX3JlczogW2J1
cyAwMi1mZl0gZW5kIGlzIHVwZGF0ZWQgdG8gMDINCj4gWyAgICAwLjM3OTQ5NF0gcGNpX2J1cyAw
MDAwOjAyOiBidXNuX3JlczogY2FuIG5vdCBpbnNlcnQgW2J1cyAwMl0gdW5kZXIgW2J1cyAwMV0N
Cj4gKGNvbmZsaWN0cyB3aXRoIChudWxsKSBbYnVzIDAxXSkNCj4gWyAgICAwLjM3OTUyNF0gcGNp
X2J1cyAwMDAwOjAyOiBbYnVzIDAyXSBwYXJ0aWFsbHkgaGlkZGVuIGJlaGluZCBicmlkZ2UgMDAw
MDowMQ0KPiBbYnVzIDAxXQ0KPiBbICAgIDAuMzc5NTQ4XSBwY2kgMDAwMDowMDowMC4wOiBicmlk
Z2UgaGFzIHN1Ym9yZGluYXRlIDAxIGJ1dCBtYXggYnVzbiAwMg0KPiBbICAgIDAuMzc5ODM3XSBw
Y2kgMDAwMDowMDowMC4wOiBCQVIgMDogYXNzaWduZWQgW21lbSAweDAxMDAwMDAwLTB4MDEwZmZm
ZmZdDQo+IFsgICAgMC4zNzk4NjVdIHBjaSAwMDAwOjAwOjAwLjA6IEJBUiA4OiBhc3NpZ25lZCBb
bWVtIDB4MDExMDAwMDAtMHgwMTFmZmZmZl0NCj4gWyAgICAwLjM3OTg4NF0gcGNpIDAwMDA6MDA6
MDAuMDogQkFSIDY6IGFzc2lnbmVkIFttZW0gMHgwMTIwMDAwMC0weDAxMjBmZmZmDQo+IHByZWZd
DQo+IFsgICAgMC4zNzk5MDBdIHBjaSAwMDAwOjAwOjAwLjA6IEJBUiA3OiBhc3NpZ25lZCBbaW8g
IDB4MTAwMC0weDFmZmZdDQo+IFsgICAgMC4zNzk5MjddIHBjaSAwMDAwOjAxOjAwLjA6IEJBUiA4
OiBhc3NpZ25lZCBbbWVtIDB4MDExMDAwMDAtMHgwMTFmZmZmZl0NCj4gWyAgICAwLjM3OTk0Ml0g
cGNpIDAwMDA6MDE6MDAuMDogQkFSIDc6IGFzc2lnbmVkIFtpbyAgMHgxMDAwLTB4MWZmZl0NCj4g
WyAgICAwLjM3OTk2M10gcGNpIDAwMDA6MDI6MDQuMDogQkFSIDE6IGFzc2lnbmVkIFttZW0gMHgw
MTEwMDAwMC0weDAxMTAwZmZmXQ0KPiBbICAgIDAuMzc5OTk4XSBwY2kgMDAwMDowMjowNC4wOiBC
QVIgMDogYXNzaWduZWQgW2lvICAweDEwMDAtMHgxMDA3XQ0KPiBbICAgIDAuMzgwMDMwXSBwY2kg
MDAwMDowMTowMC4wOiBQQ0kgYnJpZGdlIHRvIFtidXMgMDJdDQo+IFsgICAgMC4zODAwNTRdIHBj
aSAwMDAwOjAxOjAwLjA6ICAgYnJpZGdlIHdpbmRvdyBbaW8gIDB4MTAwMC0weDFmZmZdDQo+IFsg
ICAgMC4zODAwOTFdIHBjaSAwMDAwOjAxOjAwLjA6ICAgYnJpZGdlIHdpbmRvdyBbbWVtIDB4MDEx
MDAwMDAtMHgwMTFmZmZmZl0NCj4gWyAgICAwLjM4MDE0OV0gcGNpIDAwMDA6MDA6MDAuMDogUENJ
IGJyaWRnZSB0byBbYnVzIDAxXQ0KPiBbICAgIDAuMzgwMTY0XSBwY2kgMDAwMDowMDowMC4wOiAg
IGJyaWRnZSB3aW5kb3cgW2lvICAweDEwMDAtMHgxZmZmXQ0KPiBbICAgIDAuMzgwMTgzXSBwY2kg
MDAwMDowMDowMC4wOiAgIGJyaWRnZSB3aW5kb3cgW21lbSAweDAxMTAwMDAwLTB4MDExZmZmZmZd
DQo+IFsgICAgMC4zODA5NTBdIHBjaWVwb3J0IDAwMDA6MDA6MDAuMDogU2lnbmFsaW5nIFBNRSB0
aHJvdWdoIFBDSWUgUE1FIGludGVycnVwdA0KPiBbICAgIDAuMzgwOTcwXSBwY2kgMDAwMDowMTow
MC4wOiBTaWduYWxpbmcgUE1FIHRocm91Z2ggUENJZSBQTUUgaW50ZXJydXB0DQo+IFsgICAgMC4z
ODA5ODNdIHBjaSAwMDAwOjAyOjA0LjA6IFNpZ25hbGluZyBQTUUgdGhyb3VnaCBQQ0llIFBNRSBp
bnRlcnJ1cHQNCj4gWyAgICAwLjM4MTAwM10gcGNpZV9wbWUgMDAwMDowMDowMC4wOnBjaWUwMTog
c2VydmljZSBkcml2ZXIgcGNpZV9wbWUgbG9hZGVkDQo+IFsgICAgMC4zODE0MDddIGFlciAwMDAw
OjAwOjAwLjA6cGNpZTAyOiBzZXJ2aWNlIGRyaXZlciBhZXIgbG9hZGVkDQoNCg==

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

[Lucas Stach]

Hi Roberto,

Am Dienstag, den 01.03.2016, 19:47 +0100 schrieb Roberto Fichera:
> 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?

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
-- 
Pengutronix e.K.             | Lucas Stach                 |
Industrial Linux Solutions   | http://www.pengutronix.de/  |

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

[Roberto Fichera]

On 03/03/2016 10:32 AM, Lucas Stach wrote:
> Hi Roberto,

Hi Lucas,

>
> Am Dienstag, den 01.03.2016, 19:47 +0100 schrieb Roberto Fichera:
>> 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?
> Is this a regression from earlier kernel versions?

No it isn't. I'm working with a brand new custom PCB so I've started my testing against v4.4.x kernel.

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

Currently for testing I've changed the reset procedure to follow exactly the one I've in uboot, which seems
working:

U-Boot 2014.04-imx_v2014.04_3.14.38_6qp_beta+g6e9282c (Mar 03 2016 - 10:21:24)

CPU:   Freescale i.MX6Q rev1.5 at 792 MHz
CPU:   Temperature 37 C, calibration data: 0x5664d569
Reset cause: WDOG
Board: Janas iMX6Q (ID:e315c064140749d4)
I2C:   ready
DRAM:  2 GiB
MMC:   FSL_SDHC: 0, FSL_SDHC: 1
DEBUG_R0: 0x03584e11, DEBUG_R1: 0x08000410
  LTSSM current state: 0x11 (S_L0)
  PIPE transmit K indication: 0
  PIPE Transmit data: 0x584e
  Receiver is receiving logical idle: yes
  Second symbol is also idle (16-bit PHY interface only): yes
  Currently receiving k237 (PAD) in place of link number: no
  Currently receiving k237 (PAD) in place of lane number: no
  Link control bits advertised by link partner: 0x0
  Receiver detected lane reversal: no
  TS2 training sequence received: no
  TS1 training sequence received: no
  Receiver reports skip reception: no
  LTSSM reports PHY link up: yes
  A skip ordered set has been transmitted: no
  Link number advertised/confirmed by link partner: 4
  Application request to initiate training reset: no
  PIPE transmit compliance request: no
  PIPE transmit electrical idle request: no
  PIPE receiver detect/loopback request: no
  LTSSM-negotiated link reset: yes
  LTSSM testing for polarity reversal: no
  LTSSM performing link training: no
  LTSSM in DISABLE state; link inoperable: no
  Scrambling disabled for the link: no
  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:   Phy not found
PHY reset timed out
FEC [PRIME]
Normal Boot
Hit any key to stop autoboot:  0

Cheers,
Roberto Fichera.

>
> Regards,
> Lucas

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

[Fabio Estevam]

On Thu, Mar 3, 2016 at 6:32 AM, Lucas Stach <l.stach@pengutronix.de> wrote:

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

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

[Roberto Fichera]

On 03/08/2016 04:02 PM, Fabio Estevam wrote:
> On Thu, Mar 3, 2016 at 6:32 AM, Lucas Stach <l.stach@pengutronix.de> wrote:
>
>> 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.

Yes! I've just checked that isn't present

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

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

[Roberto Fichera]

Hi There,

Working on a custom iMX6q board I'm getting a PCIe phy link never came up, even if uboot detect
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, 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.

Any idea?

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 at 0x01000000 ranges:
[    0.236162]   No bus range found for /soc/pcie at 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
...