> -Original Message-
> From: York Sun
> Sent: Wednesday, September 06, 2017 11:37 PM
> To: Joakim Tjernlund ; Mingkai Hu
>
> Cc: Xiaowei Bao ; 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
On 09/05/2017 04:08 AM, Joakim Tjernlund wrote:
> On Mon, 2017-08-28 at 17:14 +, York Sun wrote:
>> +Xiaowei
>>
>> On 08/28/2017 10:09 AM, Joakim Tjernlund wrote:
>>> On Mon, 2017-08-28 at 16:55 +, York Sun wrote:
On 08/28/2017 09:48 AM, Joakim Tjernlund wrote:
> FSL PCIe controlle
On Mon, 2017-08-28 at 17:14 +, York Sun wrote:
> +Xiaowei
>
> On 08/28/2017 10:09 AM, Joakim Tjernlund wrote:
> > On Mon, 2017-08-28 at 16:55 +, 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:
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
On Tue, 2017-08-29 at 10:46 +, 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,
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
-Orig
On Tue, 2017-08-29 at 09:53 +, 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 p
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
-
On Tue, 2017-08-29 at 03:19 +, 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_DETEC
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 dire
+Xiaowei
On 08/28/2017 10:09 AM, Joakim Tjernlund wrote:
> On Mon, 2017-08-28 at 16:55 +, 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 d
On Mon, 2017-08-28 at 16:55 +, 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
>
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
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 real
14 matches
Mail list logo
