FSL PCIe LTSSM >= PCI_LTSSM_L0 equals link up

U-Boot Joakim Tjernlund 4 participants 14 messages Aug 28, 2017 – Sep 7, 2017

Share & tools

Joakim Tjernlund

author

2017-08-28 16:48 UTC #0 lore raw

FSL PCIe controller drivers before REV 3 has this test for link up:
enabled = ltssm >= PCI_LTSSM_L0;

We have a PCIe dev. that stays in LTSSM=0x51 (Polling Compliance) when non ready for PCI transaktions. When FSL PCIe controller tries to access this device, it hangs forever.

Is LTSSM=0x51 really a "legal" state for link up?
If not, what is a suitable range(maybe LO <= ltssm <= L0s(0x27)) ?

Jocke

BTW, the same test is valid in Linux too.

York Sun

2017-08-28 16:55 UTC #1 lore raw

Quoted 7 lines · Joakim Tjernlund

FSL PCIe controller drivers before REV 3 has this test for link up:
   enabled = ltssm >= PCI_LTSSM_L0;
We have a PCIe dev. that stays in LTSSM=0x51 (Polling Compliance) when non ready for PCI transaktions. When FSL PCIe controller tries to access this device, it hangs forever.

Quoted 7 lines

Is LTSSM=0x51 really a "legal" state for link up?
If not, what is a suitable range(maybe LO <= ltssm <= L0s(0x27)) ?
Jocke
BTW, the same test is valid in Linux too.

Jocke,

I am not an expert on PCIe. Please if this thread is helpful,
http://patchwork.ozlabs.org/patch/801519/.

York

Joakim Tjernlund

author

2017-08-28 17:09 UTC #2 lore raw

Quoted 11 lines · York Sun

Quoted 10 lines · Joakim Tjernlund
FSL PCIe controller drivers before REV 3 has this test for link up:
   enabled = ltssm >= PCI_LTSSM_L0;
We have a PCIe dev. that stays in LTSSM=0x51 (Polling Compliance) when non ready for PCI transaktions. When FSL PCIe controller tries to access this device, it hangs forever.
Is LTSSM=0x51 really a "legal" state for link up?
If not, what is a suitable range(maybe LO <= ltssm <= L0s(0x27)) ?

Quoted 8 lines

Quoted 4 lines
Jocke
BTW, the same test is valid in Linux too.
Jocke,
I am not an expert on PCIe. Please if this thread is helpful,

Me neither .. :)

Quoted 2 lines

http://patchwork.ozlabs.org/patch/801519/.

It mentions polling compliance but this driver already tests for:
if (ltssm < LTSSM_PCIE_L0)

		return 0; 
	return 1;

It just adds some delay if the device is in Polling Compliance to see if that changes to L0.
Since both layerscape and fsl >= rev 3 already require ltssm to be == L0, I suspect the ltssm >= L0 is bogus.

Jocke

York Sun

2017-08-28 17:14 UTC #3 lore raw

+Xiaowei

Quoted 26 lines · Joakim Tjernlund

Quoted 11 lines · York Sun
Quoted 10 lines · Joakim Tjernlund
FSL PCIe controller drivers before REV 3 has this test for link up:
    enabled = ltssm >= PCI_LTSSM_L0;
We have a PCIe dev. that stays in LTSSM=0x51 (Polling Compliance) when non ready for PCI transaktions. When FSL PCIe controller tries to access this device, it hangs forever.
Is LTSSM=0x51 really a "legal" state for link up?
If not, what is a suitable range(maybe LO <= ltssm <= L0s(0x27)) ?
Quoted 8 lines
Quoted 4 lines
Jocke
BTW, the same test is valid in Linux too.
Jocke,
I am not an expert on PCIe. Please if this thread is helpful,
Me neither .. :)
Quoted 2 lines
https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpatchwork.ozlabs.org%2Fpatch%2F801519%2F&data=01%7C01%7Cyork.sun%40nxp.com%7Cf46ff5111ba04e631a9b08d4ee377ecc%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0&sdata=n9%2B2NIjEvsMBCljRLHS6NVVN4ANa3nBGpwUjI4Od%2Bhs%3D&reserved=0.
It mentions polling compliance but this driver already tests for:
if (ltssm < LTSSM_PCIE_L0)

Quoted 8 lines

		return 0;
	return 1;
It just adds some delay if the device is in Polling Compliance to see if that changes to L0.
Since both layerscape and fsl >= rev 3 already require ltssm to be == L0, I suspect the ltssm >= L0 is bogus.

Xiaowei, can you comment?

York

Xiaowei Bao

2017-08-29 03:19 UTC #4 lore raw

Hi York,

Review

Quoted 2 lines

(quoted diff) +2 -0

+	if (ltssm == LTSSM_PCIE_DETECT_QUIET ||
+	    ltssm == LTSSM_PCIE_DETECT_ACTIVE) {

When the pcie slot have no device, the pcie controller access this register return LTSSM_PCIE_DETECT_QUIET or LTSSM_PCIE_DETECT_ACTIVE state, In order to avoid unnecessary delay, return directly.

Reference the spec, except L0 state, the L0s L1 L2state can consider the link state, but these state regards the power management, our pcie driver have not power management code in uboot, so just need to judge the L0 state.

Thanks

-----Original Message-----
From: York Sun
Sent: Tuesday, August 29, 2017 1:15 AM
To: Xiaowei Bao <[email protected]>
Cc: Joakim Tjernlund <[email protected]>; u-boot at lists.denx.de
Subject: Re: FSL PCIe LTSSM >= PCI_LTSSM_L0 equals link up

+Xiaowei

Quoted 26 lines · Joakim Tjernlund

Quoted 11 lines · York Sun
Quoted 10 lines · Joakim Tjernlund
FSL PCIe controller drivers before REV 3 has this test for link up:
    enabled = ltssm >= PCI_LTSSM_L0;
We have a PCIe dev. that stays in LTSSM=0x51 (Polling Compliance) when non ready for PCI transaktions. When FSL PCIe controller tries to access this device, it hangs forever.
Is LTSSM=0x51 really a "legal" state for link up?
If not, what is a suitable range(maybe LO <= ltssm <= L0s(0x27)) ?
Quoted 8 lines
Quoted 4 lines
Jocke
BTW, the same test is valid in Linux too.
Jocke,
I am not an expert on PCIe. Please if this thread is helpful,
Me neither .. :)
Quoted 2 lines
https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpatchwork.ozlabs.org%2Fpatch%2F801519%2F&data=01%7C01%7Cyork.sun%40nxp.com%7Cf46ff5111ba04e631a9b08d4ee377ecc%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0&sdata=n9%2B2NIjEvsMBCljRLHS6NVVN4ANa3nBGpwUjI4Od%2Bhs%3D&reserved=0.
It mentions polling compliance but this driver already tests for:
if (ltssm < LTSSM_PCIE_L0)

Quoted 8 lines

		return 0;
	return 1;
It just adds some delay if the device is in Polling Compliance to see if that changes to L0.
Since both layerscape and fsl >= rev 3 already require ltssm to be == L0, I suspect the ltssm >= L0 is bogus.

Xiaowei, can you comment?

York

Joakim Tjernlund

author

2017-08-29 06:45 UTC #5 lore raw

Quoted 9 lines · Xiaowei Bao

Hi York,
Review
Quoted 2 lines
(quoted diff) +2 -0
+	if (ltssm == LTSSM_PCIE_DETECT_QUIET ||
+	    ltssm == LTSSM_PCIE_DETECT_ACTIVE) {
When the pcie slot have no device, the pcie controller access this register return LTSSM_PCIE_DETECT_QUIET or LTSSM_PCIE_DETECT_ACTIVE state, In order to avoid unnecessary delay, return directly.
Reference the spec, except L0 state, the L0s L1 L2state can consider the link state, but these state regards the power management, our pcie driver have not power management code in uboot, so just need to judge the L0 state.

But Linux has power mgmt(I guess this is ASPM?). Could we come up with a new test that work for both Linux and u-boot ? Is the LTSSM reg. standardized for all FSL PCIe controllers?

Jocke

Quoted 51 lines

Thanks
-----Original Message-----
From: York Sun
Sent: Tuesday, August 29, 2017 1:15 AM
To: Xiaowei Bao <[email protected]>
Cc: Joakim Tjernlund <[email protected]>; u-boot at lists.denx.de
Subject: Re: FSL PCIe LTSSM >= PCI_LTSSM_L0 equals link up
+Xiaowei
Quoted 27 lines · Joakim Tjernlund
Quoted 11 lines · York Sun
Quoted 10 lines · Joakim Tjernlund
FSL PCIe controller drivers before REV 3 has this test for link up:
    enabled = ltssm >= PCI_LTSSM_L0;
We have a PCIe dev. that stays in LTSSM=0x51 (Polling Compliance) when non ready for PCI transaktions. When FSL PCIe controller tries to access this device, it hangs forever.
Is LTSSM=0x51 really a "legal" state for link up?
If not, what is a suitable range(maybe LO <= ltssm <= L0s(0x27)) ?
Quoted 8 lines
Quoted 4 lines
Jocke
BTW, the same test is valid in Linux too.
Jocke,
I am not an expert on PCIe. Please if this thread is helpful,
Me neither .. :)
Quoted 2 lines
https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpatchwork.ozlabs.org%2Fpatch%2F801519%2F&data=01%7C01%7Cyork.sun%40nxp.com%7Cf46ff5111ba04e631a9b08d4ee377ecc%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0&sdata=n9%2B2NIjEvsMBCljRLHS6NVVN4ANa3nBGpwUjI4Od%2Bhs%3D&reserved=0.
It mentions polling compliance but this driver already tests for:
if (ltssm < LTSSM_PCIE_L0)
Quoted 8 lines
		return 0;
	return 1;
It just adds some delay if the device is in Polling Compliance to see if that changes to L0.
Since both layerscape and fsl >= rev 3 already require ltssm to be == L0, I suspect the ltssm >= L0 is bogus.
Xiaowei, can you comment?
York

Xiaowei Bao

2017-08-29 09:53 UTC #6 lore raw

Hi,

This solution is got by discuss with minghuan and zhiqiang, according to the customer's response to this problem in the uboot period, when the kernel will not exist after the start of the problem. Because if the uboot scan the pcie device, the kernel also find this device.

Thanks

-----Original Message-----
From: Joakim Tjernlund [mailto:Joakim.Tjernlund at infinera.com]
Sent: Tuesday, August 29, 2017 2:45 PM
To: Xiaowei Bao <[email protected]>; York Sun <[email protected]>
Cc: u-boot at lists.denx.de
Subject: Re: FSL PCIe LTSSM >= PCI_LTSSM_L0 equals link up

Quoted 9 lines · Xiaowei Bao

Hi York,
Review
Quoted 2 lines
(quoted diff) +2 -0
+	if (ltssm == LTSSM_PCIE_DETECT_QUIET ||
+	    ltssm == LTSSM_PCIE_DETECT_ACTIVE) {
When the pcie slot have no device, the pcie controller access this register return LTSSM_PCIE_DETECT_QUIET or LTSSM_PCIE_DETECT_ACTIVE state, In order to avoid unnecessary delay, return directly.
Reference the spec, except L0 state, the L0s L1 L2state can consider the link state, but these state regards the power management, our pcie driver have not power management code in uboot, so just need to judge the L0 state.

But Linux has power mgmt(I guess this is ASPM?). Could we come up with a new test that work for both Linux and u-boot ? Is the LTSSM reg. standardized for all FSL PCIe controllers?

Jocke

Quoted 52 lines

Thanks
-----Original Message-----
From: York Sun
Sent: Tuesday, August 29, 2017 1:15 AM
To: Xiaowei Bao <[email protected]>
Cc: Joakim Tjernlund <[email protected]>; u-boot at lists.denx.de
Subject: Re: FSL PCIe LTSSM >= PCI_LTSSM_L0 equals link up
+Xiaowei
Quoted 27 lines · Joakim Tjernlund
Quoted 11 lines · York Sun
Quoted 10 lines · Joakim Tjernlund
FSL PCIe controller drivers before REV 3 has this test for link up:
    enabled = ltssm >= PCI_LTSSM_L0;
We have a PCIe dev. that stays in LTSSM=0x51 (Polling Compliance) when non ready for PCI transaktions. When FSL PCIe controller tries to access this device, it hangs forever.
Is LTSSM=0x51 really a "legal" state for link up?
If not, what is a suitable range(maybe LO <= ltssm <= L0s(0x27)) ?
Quoted 8 lines
Quoted 4 lines
Jocke
BTW, the same test is valid in Linux too.
Jocke,
I am not an expert on PCIe. Please if this thread is helpful,
Me neither .. :)
Quoted 2 lines
https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpatchwork.ozlabs.org%2Fpatch%2F801519%2F&data=01%7C01%7Cyork.sun%40nxp.com%7Cf46ff5111ba04e631a9b08d4ee377ecc%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0&sdata=n9%2B2NIjEvsMBCljRLHS6NVVN4ANa3nBGpwUjI4Od%2Bhs%3D&reserved=0.
It mentions polling compliance but this driver already tests for:
if (ltssm < LTSSM_PCIE_L0)
Quoted 8 lines
		return 0;
	return 1;
It just adds some delay if the device is in Polling Compliance to see if that changes to L0.
Since both layerscape and fsl >= rev 3 already require ltssm to be == L0, I suspect the ltssm >= L0 is bogus.
Xiaowei, can you comment?
York

Joakim Tjernlund

author

2017-08-29 10:26 UTC #7 lore raw

Quoted 4 lines · Xiaowei Bao

Hi,
This solution is got by discuss with minghuan and zhiqiang, according to the customer's response to this problem in the uboot period, when the kernel will not exist after the start of the problem. Because if the uboot scan the pcie device, the kernel also find this device.

But this does not solve my problem and the solution is only for layerscape ATM. I am asking FSL PCI guys if we could just rewrite the old ltssm >= L0 test to something more sane that will work for me and the rest of FSL u-boot/linux users.

Quoted 77 lines

Thanks
-----Original Message-----
From: Joakim Tjernlund [mailto:Joakim.Tjernlund at infinera.com]
Sent: Tuesday, August 29, 2017 2:45 PM
To: Xiaowei Bao <[email protected]>; York Sun <[email protected]>
Cc: u-boot at lists.denx.de
Subject: Re: FSL PCIe LTSSM >= PCI_LTSSM_L0 equals link up
Quoted 9 lines · Xiaowei Bao
Hi York,
Review
Quoted 2 lines
(quoted diff) +2 -0
+	if (ltssm == LTSSM_PCIE_DETECT_QUIET ||
+	    ltssm == LTSSM_PCIE_DETECT_ACTIVE) {
When the pcie slot have no device, the pcie controller access this register return LTSSM_PCIE_DETECT_QUIET or LTSSM_PCIE_DETECT_ACTIVE state, In order to avoid unnecessary delay, return directly.
Reference the spec, except L0 state, the L0s L1 L2state can consider the link state, but these state regards the power management, our pcie driver have not power management code in uboot, so just need to judge the L0 state.
But Linux has power mgmt(I guess this is ASPM?). Could we come up with a new test that work for both Linux and u-boot ? Is the LTSSM reg. standardized for all FSL PCIe controllers?
Jocke
Quoted 52 lines
Thanks
-----Original Message-----
From: York Sun
Sent: Tuesday, August 29, 2017 1:15 AM
To: Xiaowei Bao <[email protected]>
Cc: Joakim Tjernlund <[email protected]>; u-boot at lists.denx.de
Subject: Re: FSL PCIe LTSSM >= PCI_LTSSM_L0 equals link up
+Xiaowei
Quoted 27 lines · Joakim Tjernlund
Quoted 11 lines · York Sun
Quoted 10 lines · Joakim Tjernlund
FSL PCIe controller drivers before REV 3 has this test for link up:
    enabled = ltssm >= PCI_LTSSM_L0;
We have a PCIe dev. that stays in LTSSM=0x51 (Polling Compliance) when non ready for PCI transaktions. When FSL PCIe controller tries to access this device, it hangs forever.
Is LTSSM=0x51 really a "legal" state for link up?
If not, what is a suitable range(maybe LO <= ltssm <= L0s(0x27)) ?
Quoted 8 lines
Quoted 4 lines
Jocke
BTW, the same test is valid in Linux too.
Jocke,
I am not an expert on PCIe. Please if this thread is helpful,
Me neither .. :)
Quoted 2 lines
https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpatchwork.ozlabs.org%2Fpatch%2F801519%2F&data=01%7C01%7Cyork.sun%40nxp.com%7Cf46ff5111ba04e631a9b08d4ee377ecc%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0&sdata=n9%2B2NIjEvsMBCljRLHS6NVVN4ANa3nBGpwUjI4Od%2Bhs%3D&reserved=0.
It mentions polling compliance but this driver already tests for:
if (ltssm < LTSSM_PCIE_L0)
Quoted 8 lines
		return 0;
	return 1;
It just adds some delay if the device is in Polling Compliance to see if that changes to L0.
Since both layerscape and fsl >= rev 3 already require ltssm to be == L0, I suspect the ltssm >= L0 is bogus.
Xiaowei, can you comment?
York

Xiaowei Bao

2017-08-29 10:46 UTC #8 lore raw

Hi Joakim,

I think this can work for layerscape platform.
The layerscape platform and the powerpc platform have different pcie core, and also the LTSSM reg is not same, the pcie controller driver is different in uboot or kernel, this solution is used for layerscape platform.

Thanks

-----Original Message-----
From: Joakim Tjernlund [mailto:Joakim.Tjernlund at infinera.com]
Sent: Tuesday, August 29, 2017 6:27 PM
To: Xiaowei Bao <[email protected]>; York Sun <[email protected]>
Cc: u-boot at lists.denx.de
Subject: Re: FSL PCIe LTSSM >= PCI_LTSSM_L0 equals link up

Quoted 4 lines · Xiaowei Bao

Hi,
This solution is got by discuss with minghuan and zhiqiang, according to the customer's response to this problem in the uboot period, when the kernel will not exist after the start of the problem. Because if the uboot scan the pcie device, the kernel also find this device.

But this does not solve my problem and the solution is only for layerscape ATM.
I am asking FSL PCI guys if we could just rewrite the old ltssm >= L0 test to something more sane that will work for me and the rest of FSL u-boot/linux users.

Quoted 77 lines

Thanks
-----Original Message-----
From: Joakim Tjernlund [mailto:Joakim.Tjernlund at infinera.com]
Sent: Tuesday, August 29, 2017 2:45 PM
To: Xiaowei Bao <[email protected]>; York Sun <[email protected]>
Cc: u-boot at lists.denx.de
Subject: Re: FSL PCIe LTSSM >= PCI_LTSSM_L0 equals link up
Quoted 9 lines · Xiaowei Bao
Hi York,
Review
Quoted 2 lines
(quoted diff) +2 -0
+	if (ltssm == LTSSM_PCIE_DETECT_QUIET ||
+	    ltssm == LTSSM_PCIE_DETECT_ACTIVE) {
When the pcie slot have no device, the pcie controller access this register return LTSSM_PCIE_DETECT_QUIET or LTSSM_PCIE_DETECT_ACTIVE state, In order to avoid unnecessary delay, return directly.
Reference the spec, except L0 state, the L0s L1 L2state can consider the link state, but these state regards the power management, our pcie driver have not power management code in uboot, so just need to judge the L0 state.
But Linux has power mgmt(I guess this is ASPM?). Could we come up with a new test that work for both Linux and u-boot ? Is the LTSSM reg. standardized for all FSL PCIe controllers?
Jocke
Quoted 52 lines
Thanks
-----Original Message-----
From: York Sun
Sent: Tuesday, August 29, 2017 1:15 AM
To: Xiaowei Bao <[email protected]>
Cc: Joakim Tjernlund <[email protected]>; u-boot at lists.denx.de
Subject: Re: FSL PCIe LTSSM >= PCI_LTSSM_L0 equals link up
+Xiaowei
Quoted 27 lines · Joakim Tjernlund
Quoted 11 lines · York Sun
Quoted 10 lines · Joakim Tjernlund
FSL PCIe controller drivers before REV 3 has this test for link up:
    enabled = ltssm >= PCI_LTSSM_L0;
We have a PCIe dev. that stays in LTSSM=0x51 (Polling Compliance) when non ready for PCI transaktions. When FSL PCIe controller tries to access this device, it hangs forever.
Is LTSSM=0x51 really a "legal" state for link up?
If not, what is a suitable range(maybe LO <= ltssm <= L0s(0x27)) ?
Quoted 8 lines
Quoted 4 lines
Jocke
BTW, the same test is valid in Linux too.
Jocke,
I am not an expert on PCIe. Please if this thread is helpful,
Me neither .. :)
Quoted 2 lines
https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpatchwork.ozlabs.org%2Fpatch%2F801519%2F&data=01%7C01%7Cyork.sun%40nxp.com%7Cf46ff5111ba04e631a9b08d4ee377ecc%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0&sdata=n9%2B2NIjEvsMBCljRLHS6NVVN4ANa3nBGpwUjI4Od%2Bhs%3D&reserved=0.
It mentions polling compliance but this driver already tests for:
if (ltssm < LTSSM_PCIE_L0)
Quoted 8 lines
		return 0;
	return 1;
It just adds some delay if the device is in Polling Compliance to see if that changes to L0.
Since both layerscape and fsl >= rev 3 already require ltssm to be == L0, I suspect the ltssm >= L0 is bogus.
Xiaowei, can you comment?
York

Joakim Tjernlund

author

2017-08-29 10:49 UTC #9 lore raw

Quoted 5 lines · Xiaowei Bao

Hi Joakim,
I think this can work for layerscape platform.
The layerscape platform and the powerpc platform have different pcie core, and also the LTSSM reg is not same, the pcie controller driver is different in uboot or kernel, this solution is used for layerscape platform.

I am not asking about the layerscape platform, I want to know what to do with FSL. Please read the whole thread.

Quoted 96 lines

Thanks
-----Original Message-----
From: Joakim Tjernlund [mailto:Joakim.Tjernlund at infinera.com]
Sent: Tuesday, August 29, 2017 6:27 PM
To: Xiaowei Bao <[email protected]>; York Sun <[email protected]>
Cc: u-boot at lists.denx.de
Subject: Re: FSL PCIe LTSSM >= PCI_LTSSM_L0 equals link up
Quoted 4 lines · Xiaowei Bao
Hi,
This solution is got by discuss with minghuan and zhiqiang, according to the customer's response to this problem in the uboot period, when the kernel will not exist after the start of the problem. Because if the uboot scan the pcie device, the kernel also find this device.
But this does not solve my problem and the solution is only for layerscape ATM.
I am asking FSL PCI guys if we could just rewrite the old ltssm >= L0 test to something more sane that will work for me and the rest of FSL u-boot/linux users.
Quoted 77 lines
Thanks
-----Original Message-----
From: Joakim Tjernlund [mailto:Joakim.Tjernlund at infinera.com]
Sent: Tuesday, August 29, 2017 2:45 PM
To: Xiaowei Bao <[email protected]>; York Sun <[email protected]>
Cc: u-boot at lists.denx.de
Subject: Re: FSL PCIe LTSSM >= PCI_LTSSM_L0 equals link up
Quoted 9 lines · Xiaowei Bao
Hi York,
Review
Quoted 2 lines
(quoted diff) +2 -0
+	if (ltssm == LTSSM_PCIE_DETECT_QUIET ||
+	    ltssm == LTSSM_PCIE_DETECT_ACTIVE) {
When the pcie slot have no device, the pcie controller access this register return LTSSM_PCIE_DETECT_QUIET or LTSSM_PCIE_DETECT_ACTIVE state, In order to avoid unnecessary delay, return directly.
Reference the spec, except L0 state, the L0s L1 L2state can consider the link state, but these state regards the power management, our pcie driver have not power management code in uboot, so just need to judge the L0 state.
But Linux has power mgmt(I guess this is ASPM?). Could we come up with a new test that work for both Linux and u-boot ? Is the LTSSM reg. standardized for all FSL PCIe controllers?
Jocke
Quoted 52 lines
Thanks
-----Original Message-----
From: York Sun
Sent: Tuesday, August 29, 2017 1:15 AM
To: Xiaowei Bao <[email protected]>
Cc: Joakim Tjernlund <[email protected]>; u-boot at lists.denx.de
Subject: Re: FSL PCIe LTSSM >= PCI_LTSSM_L0 equals link up
+Xiaowei
Quoted 27 lines · Joakim Tjernlund
Quoted 11 lines · York Sun
Quoted 10 lines · Joakim Tjernlund
FSL PCIe controller drivers before REV 3 has this test for link up:
    enabled = ltssm >= PCI_LTSSM_L0;
We have a PCIe dev. that stays in LTSSM=0x51 (Polling Compliance) when non ready for PCI transaktions. When FSL PCIe controller tries to access this device, it hangs forever.
Is LTSSM=0x51 really a "legal" state for link up?
If not, what is a suitable range(maybe LO <= ltssm <= L0s(0x27)) ?
Quoted 8 lines
Quoted 4 lines
Jocke
BTW, the same test is valid in Linux too.
Jocke,
I am not an expert on PCIe. Please if this thread is helpful,
Me neither .. :)
Quoted 2 lines
https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpatchwork.ozlabs.org%2Fpatch%2F801519%2F&data=01%7C01%7Cyork.sun%40nxp.com%7Cf46ff5111ba04e631a9b08d4ee377ecc%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0&sdata=n9%2B2NIjEvsMBCljRLHS6NVVN4ANa3nBGpwUjI4Od%2Bhs%3D&reserved=0.
It mentions polling compliance but this driver already tests for:
if (ltssm < LTSSM_PCIE_L0)
Quoted 8 lines
		return 0;
	return 1;
It just adds some delay if the device is in Polling Compliance to see if that changes to L0.
Since both layerscape and fsl >= rev 3 already require ltssm to be == L0, I suspect the ltssm >= L0 is bogus.
Xiaowei, can you comment?
York

Xiaowei Bao

2017-08-29 11:01 UTC #10 lore raw

Hi,

The attached is the powerpc platform patch. I have done but not submit.
I am not sure what to do with FSL, i will discuss with zhiqiang and minghuan, and replay to you tomorrow. Because the powerpc platform is not maintain, so I don't know if need a patch.

Thanks

-----Original Message-----
From: Joakim Tjernlund [mailto:Joakim.Tjernlund at infinera.com]
Sent: Tuesday, August 29, 2017 6:50 PM
To: Xiaowei Bao <[email protected]>; York Sun <[email protected]>
Cc: u-boot at lists.denx.de
Subject: Re: FSL PCIe LTSSM >= PCI_LTSSM_L0 equals link up

Quoted 5 lines · Xiaowei Bao

Hi Joakim,
I think this can work for layerscape platform.
The layerscape platform and the powerpc platform have different pcie core, and also the LTSSM reg is not same, the pcie controller driver is different in uboot or kernel, this solution is used for layerscape platform.

I am not asking about the layerscape platform, I want to know what to do with FSL. Please read the whole thread.

Quoted 9 lines

Thanks
-----Original Message-----
From: Joakim Tjernlund [mailto:Joakim.Tjernlund at infinera.com]
Sent: Tuesday, August 29, 2017 6:27 PM
To: Xiaowei Bao <[email protected]>; York Sun <[email protected]>
Cc: u-boot at lists.denx.de
Subject: Re: FSL PCIe LTSSM >= PCI_LTSSM_L0 equals link up

Quoted 87 lines

Quoted 4 lines · Xiaowei Bao
Hi,
This solution is got by discuss with minghuan and zhiqiang, according to the customer's response to this problem in the uboot period, when the kernel will not exist after the start of the problem. Because if the uboot scan the pcie device, the kernel also find this device.
But this does not solve my problem and the solution is only for layerscape ATM.
I am asking FSL PCI guys if we could just rewrite the old ltssm >= L0 test to something more sane that will work for me and the rest of FSL u-boot/linux users.
Quoted 77 lines
Thanks
-----Original Message-----
From: Joakim Tjernlund [mailto:Joakim.Tjernlund at infinera.com]
Sent: Tuesday, August 29, 2017 2:45 PM
To: Xiaowei Bao <[email protected]>; York Sun <[email protected]>
Cc: u-boot at lists.denx.de
Subject: Re: FSL PCIe LTSSM >= PCI_LTSSM_L0 equals link up
Quoted 9 lines · Xiaowei Bao
Hi York,
Review
Quoted 2 lines
(quoted diff) +2 -0
+	if (ltssm == LTSSM_PCIE_DETECT_QUIET ||
+	    ltssm == LTSSM_PCIE_DETECT_ACTIVE) {
When the pcie slot have no device, the pcie controller access this register return LTSSM_PCIE_DETECT_QUIET or LTSSM_PCIE_DETECT_ACTIVE state, In order to avoid unnecessary delay, return directly.
Reference the spec, except L0 state, the L0s L1 L2state can consider the link state, but these state regards the power management, our pcie driver have not power management code in uboot, so just need to judge the L0 state.
But Linux has power mgmt(I guess this is ASPM?). Could we come up with a new test that work for both Linux and u-boot ? Is the LTSSM reg. standardized for all FSL PCIe controllers?
Jocke
Quoted 52 lines
Thanks
-----Original Message-----
From: York Sun
Sent: Tuesday, August 29, 2017 1:15 AM
To: Xiaowei Bao <[email protected]>
Cc: Joakim Tjernlund <[email protected]>; u-boot at lists.denx.de
Subject: Re: FSL PCIe LTSSM >= PCI_LTSSM_L0 equals link up
+Xiaowei
Quoted 27 lines · Joakim Tjernlund
Quoted 11 lines · York Sun
Quoted 10 lines · Joakim Tjernlund
FSL PCIe controller drivers before REV 3 has this test for link up:
    enabled = ltssm >= PCI_LTSSM_L0;
We have a PCIe dev. that stays in LTSSM=0x51 (Polling Compliance) when non ready for PCI transaktions. When FSL PCIe controller tries to access this device, it hangs forever.
Is LTSSM=0x51 really a "legal" state for link up?
If not, what is a suitable range(maybe LO <= ltssm <= L0s(0x27)) ?
Quoted 8 lines
Quoted 4 lines
Jocke
BTW, the same test is valid in Linux too.
Jocke,
I am not an expert on PCIe. Please if this thread is helpful,
Me neither .. :)
Quoted 2 lines
https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpatchwork.ozlabs.org%2Fpatch%2F801519%2F&data=01%7C01%7Cyork.sun%40nxp.com%7Cf46ff5111ba04e631a9b08d4ee377ecc%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0&sdata=n9%2B2NIjEvsMBCljRLHS6NVVN4ANa3nBGpwUjI4Od%2Bhs%3D&reserved=0.
It mentions polling compliance but this driver already tests for:
if (ltssm < LTSSM_PCIE_L0)
Quoted 8 lines
		return 0;
	return 1;
It just adds some delay if the device is in Polling Compliance to see if that changes to L0.
Since both layerscape and fsl >= rev 3 already require ltssm to be == L0, I suspect the ltssm >= L0 is bogus.
Xiaowei, can you comment?
York

-------------- next part --------------
A non-text attachment was scrubbed...
Name: powerpc-pcie-link.patch
Type: application/octet-stream
Size: 1788 bytes
Desc: powerpc-pcie-link.patch
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20170829/5ac4a187/attachment.obj>

Joakim Tjernlund

author

2017-09-05 11:08 UTC #11 lore raw

In reply to York Sun

Quoted 39 lines · York Sun

+Xiaowei
Quoted 27 lines · Joakim Tjernlund
Quoted 11 lines · York Sun
Quoted 10 lines · Joakim Tjernlund
FSL PCIe controller drivers before REV 3 has this test for link up:
    enabled = ltssm >= PCI_LTSSM_L0;
We have a PCIe dev. that stays in LTSSM=0x51 (Polling Compliance) when non ready for PCI transaktions. When FSL PCIe controller tries to access this device, it hangs forever.
Is LTSSM=0x51 really a "legal" state for link up?
If not, what is a suitable range(maybe LO <= ltssm <= L0s(0x27)) ?
Quoted 8 lines
Quoted 4 lines
Jocke
BTW, the same test is valid in Linux too.
Jocke,
I am not an expert on PCIe. Please if this thread is helpful,
Me neither .. :)
Quoted 2 lines
https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpatchwork.ozlabs.org%2Fpatch%2F801519%2F&data=01%7C01%7Cyork.sun%40nxp.com%7Cf46ff5111ba04e631a9b08d4ee377ecc%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0&sdata=n9%2B2NIjEvsMBCljRLHS6NVVN4ANa3nBGpwUjI4Od%2Bhs%3D&reserved=0.
It mentions polling compliance but this driver already tests for:
if (ltssm < LTSSM_PCIE_L0)
Quoted 8 lines
		return 0;
	return 1;
It just adds some delay if the device is in Polling Compliance to see if that changes to L0.
Since both layerscape and fsl >= rev 3 already require ltssm to be == L0, I suspect the ltssm >= L0 is bogus.

Quoted 3 lines

Xiaowei, can you comment?
York

Ping?
Should I just send a patch ?

Jocke

York Sun

2017-09-06 15:36 UTC #12 lore raw

Quoted 40 lines · Joakim Tjernlund

Quoted 39 lines · York Sun
+Xiaowei
Quoted 35 lines · Joakim Tjernlund
Quoted 11 lines · York Sun
Quoted 10 lines · Joakim Tjernlund
FSL PCIe controller drivers before REV 3 has this test for link up:
     enabled = ltssm >= PCI_LTSSM_L0;
We have a PCIe dev. that stays in LTSSM=0x51 (Polling Compliance) when non ready for PCI transaktions. When FSL PCIe controller tries to access this device, it hangs forever.
Is LTSSM=0x51 really a "legal" state for link up?
If not, what is a suitable range(maybe LO <= ltssm <= L0s(0x27)) ?
Quoted 8 lines
Quoted 4 lines
Jocke
BTW, the same test is valid in Linux too.
Jocke,
I am not an expert on PCIe. Please if this thread is helpful,
Me neither .. :)
Quoted 2 lines
https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpatchwork.ozlabs.org%2Fpatch%2F801519%2F&data=01%7C01%7Cyork.sun%40nxp.com%7Cf46ff5111ba04e631a9b08d4ee377ecc%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0&sdata=n9%2B2NIjEvsMBCljRLHS6NVVN4ANa3nBGpwUjI4Od%2Bhs%3D&reserved=0.
It mentions polling compliance but this driver already tests for:
if (ltssm < LTSSM_PCIE_L0)
		return 0;
	return 1;
It just adds some delay if the device is in Polling Compliance to see if that changes to L0.
Since both layerscape and fsl >= rev 3 already require ltssm to be == L0, I suspect the ltssm >= L0 is bogus.

Quoted 7 lines

Quoted 3 lines
Xiaowei, can you comment?
York
Ping?
Should I just send a patch ?

+Mingkai

Mingkai Hu

2017-09-07 08:12 UTC #13 lore raw

Quoted 58 lines

-----Original Message-----
From: York Sun
Sent: Wednesday, September 06, 2017 11:37 PM
To: Joakim Tjernlund <[email protected]>; Mingkai Hu <[email protected]>
Cc: Xiaowei Bao <[email protected]>; u-boot at lists.denx.de
Subject: Re: FSL PCIe LTSSM >= PCI_LTSSM_L0 equals link up
Quoted 21 lines · Joakim Tjernlund
Quoted 20 lines · York Sun
+Xiaowei
Quoted 17 lines · Joakim Tjernlund
Quoted 16 lines · York Sun
Quoted 14 lines · Joakim Tjernlund
FSL PCIe controller drivers before REV 3 has this test for link up:
     enabled = ltssm >= PCI_LTSSM_L0;
We have a PCIe dev. that stays in LTSSM=0x51 (Polling Compliance) when non ready for PCI transaktions. When FSL PCIe controller tries to access this device, it hangs forever.
Is LTSSM=0x51 really a "legal" state for link up?
If not, what is a suitable range(maybe LO <= ltssm <= L0s(0x27)) ?
Jocke
BTW, the same test is valid in Linux too.
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 3 lines
Jocke,
I am not an expert on PCIe. Please if this thread is helpful,
Me neither .. :)
Quoted 2 lines
https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpatc
hwork.ozlabs.org%2Fpatch%2F801519%2F&data=01%7C01%7Cyork.sun%40n xp.com%7Cf46ff5111ba04e631a9b08d4ee377ecc%7C686ea1d3bc2b4c6fa92cd 99c5c301635%7C0&sdata=n9%2B2NIjEvsMBCljRLHS6NVVN4ANa3nBGpwUjI4 Od%2Bhs%3D&reserved=0.
Quoted 14 lines
Quoted 14 lines
Quoted 11 lines
It mentions polling compliance but this driver already tests for:
if (ltssm < LTSSM_PCIE_L0)
		return 0;
	return 1;
It just adds some delay if the device is in Polling Compliance to see if that changes to L0.
Since both layerscape and fsl >= rev 3 already require ltssm to be == L0, I suspect the ltssm >= L0 is bogus.
Xiaowei, can you comment?

Quoted 7 lines

Quoted 5 lines
Quoted 1 line
York
Ping?
Should I just send a patch ?
+Mingkai

LTSSM should be L0 state for linkup. Xiaowei have the patch to modify the code for layerscape platform:
http://patchwork.ozlabs.org/patch/801519/

He will work out a patch for PowerPC platform also.

Mingkai