[U-Boot] FSL PCIe LTSSM >= PCI_LTSSM_L0 equals link up
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.
On 08/28/2017 09:48 AM, Joakim Tjernlund wrote:
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.
Jocke,
I am not an expert on PCIe. Please if this thread is helpful, http://patchwork.ozlabs.org/patch/801519/.
York
On Mon, 2017-08-28 at 16:55 +0000, York Sun wrote:
On 08/28/2017 09:48 AM, Joakim Tjernlund wrote:
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.
Jocke,
I am not an expert on PCIe. Please if this thread is helpful,
Me neither .. :)
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
+Xiaowei
On 08/28/2017 10:09 AM, Joakim Tjernlund wrote:
On Mon, 2017-08-28 at 16:55 +0000, York Sun wrote:
On 08/28/2017 09:48 AM, Joakim Tjernlund wrote:
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.
Jocke,
I am not an expert on PCIe. Please if this thread is helpful,
Me neither .. :)
https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpatchwork.....
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?
York
Hi York,
- 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 xiaowei.bao@nxp.com Cc: Joakim Tjernlund Joakim.Tjernlund@infinera.com; u-boot@lists.denx.de Subject: Re: FSL PCIe LTSSM >= PCI_LTSSM_L0 equals link up
+Xiaowei
On 08/28/2017 10:09 AM, Joakim Tjernlund wrote:
On Mon, 2017-08-28 at 16:55 +0000, York Sun wrote:
On 08/28/2017 09:48 AM, Joakim Tjernlund wrote:
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.
Jocke,
I am not an expert on PCIe. Please if this thread is helpful,
Me neither .. :)
https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpatchwork.....
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?
York
On Tue, 2017-08-29 at 03:19 +0000, Xiaowei Bao wrote:
Hi York,
- 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
Thanks
-----Original Message----- From: York Sun Sent: Tuesday, August 29, 2017 1:15 AM To: Xiaowei Bao xiaowei.bao@nxp.com Cc: Joakim Tjernlund Joakim.Tjernlund@infinera.com; u-boot@lists.denx.de Subject: Re: FSL PCIe LTSSM >= PCI_LTSSM_L0 equals link up
+Xiaowei
On 08/28/2017 10:09 AM, Joakim Tjernlund wrote:
On Mon, 2017-08-28 at 16:55 +0000, York Sun wrote:
On 08/28/2017 09:48 AM, Joakim Tjernlund wrote:
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.
Jocke,
I am not an expert on PCIe. Please if this thread is helpful,
Me neither .. :)
https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpatchwork.....
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?
York
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@infinera.com] Sent: Tuesday, August 29, 2017 2:45 PM To: Xiaowei Bao xiaowei.bao@nxp.com; York Sun york.sun@nxp.com Cc: u-boot@lists.denx.de Subject: Re: FSL PCIe LTSSM >= PCI_LTSSM_L0 equals link up
On Tue, 2017-08-29 at 03:19 +0000, Xiaowei Bao wrote:
Hi York,
- 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
Thanks
-----Original Message----- From: York Sun Sent: Tuesday, August 29, 2017 1:15 AM To: Xiaowei Bao xiaowei.bao@nxp.com Cc: Joakim Tjernlund Joakim.Tjernlund@infinera.com; u-boot@lists.denx.de Subject: Re: FSL PCIe LTSSM >= PCI_LTSSM_L0 equals link up
+Xiaowei
On 08/28/2017 10:09 AM, Joakim Tjernlund wrote:
On Mon, 2017-08-28 at 16:55 +0000, York Sun wrote:
On 08/28/2017 09:48 AM, Joakim Tjernlund wrote:
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.
Jocke,
I am not an expert on PCIe. Please if this thread is helpful,
Me neither .. :)
https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpatchwork.....
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?
York
On Tue, 2017-08-29 at 09:53 +0000, Xiaowei Bao wrote:
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.
Thanks
-----Original Message----- From: Joakim Tjernlund [mailto:Joakim.Tjernlund@infinera.com] Sent: Tuesday, August 29, 2017 2:45 PM To: Xiaowei Bao xiaowei.bao@nxp.com; York Sun york.sun@nxp.com Cc: u-boot@lists.denx.de Subject: Re: FSL PCIe LTSSM >= PCI_LTSSM_L0 equals link up
On Tue, 2017-08-29 at 03:19 +0000, Xiaowei Bao wrote:
Hi York,
- 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
Thanks
-----Original Message----- From: York Sun Sent: Tuesday, August 29, 2017 1:15 AM To: Xiaowei Bao xiaowei.bao@nxp.com Cc: Joakim Tjernlund Joakim.Tjernlund@infinera.com; u-boot@lists.denx.de Subject: Re: FSL PCIe LTSSM >= PCI_LTSSM_L0 equals link up
+Xiaowei
On 08/28/2017 10:09 AM, Joakim Tjernlund wrote:
On Mon, 2017-08-28 at 16:55 +0000, York Sun wrote:
On 08/28/2017 09:48 AM, Joakim Tjernlund wrote:
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.
Jocke,
I am not an expert on PCIe. Please if this thread is helpful,
Me neither .. :)
https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpatchwork.....
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?
York
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@infinera.com] Sent: Tuesday, August 29, 2017 6:27 PM To: Xiaowei Bao xiaowei.bao@nxp.com; York Sun york.sun@nxp.com Cc: u-boot@lists.denx.de Subject: Re: FSL PCIe LTSSM >= PCI_LTSSM_L0 equals link up
On Tue, 2017-08-29 at 09:53 +0000, Xiaowei Bao wrote:
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.
Thanks
-----Original Message----- From: Joakim Tjernlund [mailto:Joakim.Tjernlund@infinera.com] Sent: Tuesday, August 29, 2017 2:45 PM To: Xiaowei Bao xiaowei.bao@nxp.com; York Sun york.sun@nxp.com Cc: u-boot@lists.denx.de Subject: Re: FSL PCIe LTSSM >= PCI_LTSSM_L0 equals link up
On Tue, 2017-08-29 at 03:19 +0000, Xiaowei Bao wrote:
Hi York,
- 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
Thanks
-----Original Message----- From: York Sun Sent: Tuesday, August 29, 2017 1:15 AM To: Xiaowei Bao xiaowei.bao@nxp.com Cc: Joakim Tjernlund Joakim.Tjernlund@infinera.com; u-boot@lists.denx.de Subject: Re: FSL PCIe LTSSM >= PCI_LTSSM_L0 equals link up
+Xiaowei
On 08/28/2017 10:09 AM, Joakim Tjernlund wrote:
On Mon, 2017-08-28 at 16:55 +0000, York Sun wrote:
On 08/28/2017 09:48 AM, Joakim Tjernlund wrote:
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.
Jocke,
I am not an expert on PCIe. Please if this thread is helpful,
Me neither .. :)
https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpatchwork.....
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?
York
On Tue, 2017-08-29 at 10:46 +0000, Xiaowei Bao wrote:
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.
Thanks
-----Original Message----- From: Joakim Tjernlund [mailto:Joakim.Tjernlund@infinera.com] Sent: Tuesday, August 29, 2017 6:27 PM To: Xiaowei Bao xiaowei.bao@nxp.com; York Sun york.sun@nxp.com Cc: u-boot@lists.denx.de Subject: Re: FSL PCIe LTSSM >= PCI_LTSSM_L0 equals link up
On Tue, 2017-08-29 at 09:53 +0000, Xiaowei Bao wrote:
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.
Thanks
-----Original Message----- From: Joakim Tjernlund [mailto:Joakim.Tjernlund@infinera.com] Sent: Tuesday, August 29, 2017 2:45 PM To: Xiaowei Bao xiaowei.bao@nxp.com; York Sun york.sun@nxp.com Cc: u-boot@lists.denx.de Subject: Re: FSL PCIe LTSSM >= PCI_LTSSM_L0 equals link up
On Tue, 2017-08-29 at 03:19 +0000, Xiaowei Bao wrote:
Hi York,
- 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
Thanks
-----Original Message----- From: York Sun Sent: Tuesday, August 29, 2017 1:15 AM To: Xiaowei Bao xiaowei.bao@nxp.com Cc: Joakim Tjernlund Joakim.Tjernlund@infinera.com; u-boot@lists.denx.de Subject: Re: FSL PCIe LTSSM >= PCI_LTSSM_L0 equals link up
+Xiaowei
On 08/28/2017 10:09 AM, Joakim Tjernlund wrote:
On Mon, 2017-08-28 at 16:55 +0000, York Sun wrote:
On 08/28/2017 09:48 AM, Joakim Tjernlund wrote:
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.
Jocke,
I am not an expert on PCIe. Please if this thread is helpful,
Me neither .. :)
https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpatchwork.....
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?
York
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@infinera.com] Sent: Tuesday, August 29, 2017 6:50 PM To: Xiaowei Bao xiaowei.bao@nxp.com; York Sun york.sun@nxp.com Cc: u-boot@lists.denx.de Subject: Re: FSL PCIe LTSSM >= PCI_LTSSM_L0 equals link up
On Tue, 2017-08-29 at 10:46 +0000, Xiaowei Bao wrote:
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.
Thanks
-----Original Message----- From: Joakim Tjernlund [mailto:Joakim.Tjernlund@infinera.com] Sent: Tuesday, August 29, 2017 6:27 PM To: Xiaowei Bao xiaowei.bao@nxp.com; York Sun york.sun@nxp.com Cc: u-boot@lists.denx.de Subject: Re: FSL PCIe LTSSM >= PCI_LTSSM_L0 equals link up
On Tue, 2017-08-29 at 09:53 +0000, Xiaowei Bao wrote:
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.
Thanks
-----Original Message----- From: Joakim Tjernlund [mailto:Joakim.Tjernlund@infinera.com] Sent: Tuesday, August 29, 2017 2:45 PM To: Xiaowei Bao xiaowei.bao@nxp.com; York Sun york.sun@nxp.com Cc: u-boot@lists.denx.de Subject: Re: FSL PCIe LTSSM >= PCI_LTSSM_L0 equals link up
On Tue, 2017-08-29 at 03:19 +0000, Xiaowei Bao wrote:
Hi York,
- 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
Thanks
-----Original Message----- From: York Sun Sent: Tuesday, August 29, 2017 1:15 AM To: Xiaowei Bao xiaowei.bao@nxp.com Cc: Joakim Tjernlund Joakim.Tjernlund@infinera.com; u-boot@lists.denx.de Subject: Re: FSL PCIe LTSSM >= PCI_LTSSM_L0 equals link up
+Xiaowei
On 08/28/2017 10:09 AM, Joakim Tjernlund wrote:
On Mon, 2017-08-28 at 16:55 +0000, York Sun wrote:
On 08/28/2017 09:48 AM, Joakim Tjernlund wrote:
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.
Jocke,
I am not an expert on PCIe. Please if this thread is helpful,
Me neither .. :)
https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpatchwork.....
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?
York
On Mon, 2017-08-28 at 17:14 +0000, York Sun wrote:
+Xiaowei
On 08/28/2017 10:09 AM, Joakim Tjernlund wrote:
On Mon, 2017-08-28 at 16:55 +0000, York Sun wrote:
On 08/28/2017 09:48 AM, Joakim Tjernlund wrote:
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.
Jocke,
I am not an expert on PCIe. Please if this thread is helpful,
Me neither .. :)
https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpatchwork.....
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?
York
Ping? Should I just send a patch ?
Jocke
On 09/05/2017 04:08 AM, Joakim Tjernlund wrote:
On Mon, 2017-08-28 at 17:14 +0000, York Sun wrote:
+Xiaowei
On 08/28/2017 10:09 AM, Joakim Tjernlund wrote:
On Mon, 2017-08-28 at 16:55 +0000, York Sun wrote:
On 08/28/2017 09:48 AM, Joakim Tjernlund wrote:
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)) ?
JockeBTW, the same test is valid in Linux too.
Jocke,
I am not an expert on PCIe. Please if this thread is helpful,
Me neither .. :)
https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpatchwork.....
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?
York
Ping? Should I just send a patch ?
+Mingkai
-----Original Message----- From: York Sun Sent: Wednesday, September 06, 2017 11:37 PM To: Joakim Tjernlund Joakim.Tjernlund@infinera.com; Mingkai Hu mingkai.hu@nxp.com Cc: Xiaowei Bao xiaowei.bao@nxp.com; u-boot@lists.denx.de Subject: Re: FSL PCIe LTSSM >= PCI_LTSSM_L0 equals link up
On 09/05/2017 04:08 AM, Joakim Tjernlund wrote:
On Mon, 2017-08-28 at 17:14 +0000, York Sun wrote:
+Xiaowei
On 08/28/2017 10:09 AM, Joakim Tjernlund wrote:
On Mon, 2017-08-28 at 16:55 +0000, York Sun wrote:
On 08/28/2017 09:48 AM, Joakim Tjernlund wrote:
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)) ?
JockeBTW, the same test is valid in Linux too.
Jocke,
I am not an expert on PCIe. Please if this thread is helpful,
Me neither .. :)
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.
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?
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
participants (4)
-
Joakim Tjernlund -
Mingkai Hu -
Xiaowei Bao -
York Sun