[U-Boot] FSL PCIe LTSSM >= PCI_LTSSM_L0 equals link up

[U-Boot] FSL PCIe LTSSM >= PCI_LTSSM_L0 equals link up

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

[U-Boot] FSL PCIe LTSSM >= PCI_LTSSM_L0 equals link up

[York Sun]

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

[U-Boot] FSL PCIe LTSSM >= PCI_LTSSM_L0 equals link up

[Joakim Tjernlund]

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

[U-Boot] FSL PCIe LTSSM >= PCI_LTSSM_L0 equals link up

[York Sun]

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

Xiaowei, can you comment?

York

[U-Boot] FSL PCIe LTSSM >= PCI_LTSSM_L0 equals link up

[Xiaowei Bao]

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

Xiaowei, can you comment?

York

[U-Boot] FSL PCIe LTSSM >= PCI_LTSSM_L0 equals link up

[Joakim Tjernlund]

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 at 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.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.
> > 
> 
> Xiaowei, can you comment?
> 
> York

[U-Boot] FSL PCIe LTSSM >= PCI_LTSSM_L0 equals link up

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

Thanks 


-----Original Message-----
From: Joakim Tjernlund [mailto:Joakim.Tjernlund at 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 at 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 at 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.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.
> > 
> 
> Xiaowei, can you comment?
> 
> York

[U-Boot] FSL PCIe LTSSM >= PCI_LTSSM_L0 equals link up

[Joakim Tjernlund]

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 at 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 at 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 at 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.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.
> > > 
> > 
> > Xiaowei, can you comment?
> > 
> > York

[U-Boot] FSL PCIe LTSSM >= PCI_LTSSM_L0 equals link up

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

Thanks

-----Original Message-----
From: Joakim Tjernlund [mailto:Joakim.Tjernlund at 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 at 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 at 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 at 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 at 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.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.
> > > 
> > 
> > Xiaowei, can you comment?
> > 
> > York

[U-Boot] FSL PCIe LTSSM >= PCI_LTSSM_L0 equals link up

[Joakim Tjernlund]

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 at 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 at 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 at 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 at 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 at 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.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.
> > > > 
> > > 
> > > Xiaowei, can you comment?
> > > 
> > > York

[U-Boot] FSL PCIe LTSSM >= PCI_LTSSM_L0 equals link up

[Xiaowei Bao]

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 <xiaowei.bao@nxp.com>; York Sun <york.sun@nxp.com>
Cc: u-boot at 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 at 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 at 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 at 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 at 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 at 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.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.
> > > > 
> > > 
> > > 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>

[U-Boot] FSL PCIe LTSSM >= PCI_LTSSM_L0 equals link up

[Joakim Tjernlund]

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.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.
> > 
> 
> Xiaowei, can you comment?
> 
> York

Ping?
Should I just send a patch ?

 Jocke

[U-Boot] FSL PCIe LTSSM >= PCI_LTSSM_L0 equals link up

[York Sun]

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)) ?
>>>>>
>>>>>     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.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.
>>>
>>
>> Xiaowei, can you comment?
>>
>> York
> 
> Ping?
> Should I just send a patch ?
> 

+Mingkai

[U-Boot] FSL PCIe LTSSM >= PCI_LTSSM_L0 equals link up

[Mingkai Hu]

> -----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 at 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)) ?
> >>>>>
> >>>>>     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%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