All of lore.kernel.org
 help / color / mirror / Atom feed
From: Roberto Fichera <kernel@tekno-soft.it>
To: Richard Zhu <hongxing.zhu@nxp.com>, Bjorn Helgaas <helgaas@kernel.org>
Cc: "linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	Richard Zhu <Richard.Zhu@freescale.com>,
	Lucas Stach <l.stach@pengutronix.de>
Subject: Re: iMX6q PCIe phy link never came up on kernel v4.4.x
Date: Tue, 8 Mar 2016 15:39:34 +0100	[thread overview]
Message-ID: <56DEE426.8030902@tekno-soft.it> (raw)
In-Reply-To: <56D883AD.5060601@tekno-soft.it>

On 03/03/2016 07:34 PM, Roberto Fichera wrote:
> On 03/03/2016 03:34 PM, Roberto Fichera wrote:
>
> I've also checked clock, pll, PMU_MISC1 and CCGR[45] registers, all looks fine
> and exactly equal to uboot settings.
>
> However I'm investigating a possible HW issue in the LDVS pad wiring against
> the bridge XIO2001. Let's see once this is also clarified.

Our HW engineer has applied a fix to LVDS vs XIO2001 clock wiring. However I'm still getting the same problem.

I've tried to boot a kernel with uboot not setting up the PCIe subsys and below there is the resulting kernel log.
Note that the CCGR5 doesn't set the CG2 field associated to sata_clk_enable. I think this field should be set all 1 to
enable the SATA ref at 100MHz, right?

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

>
>> On 03/03/2016 11:55 AM, Roberto Fichera wrote:
>>> On 03/03/2016 10:39 AM, Richard Zhu wrote:
>>>
>>> Hi Richard,
>>>
>>>> [Zhu hongxing] The registers configured during the initialization.
>>>> Regarding to the current situation at your side, the pcie link is up in uboot, but is down in kernel.
>>>> So, you can compare the dump of the register configured during the pcie initialization between uboot and kernel.
>>> Here is the register status before to start LTSSM under uboot
>>>
>>> ...
>>> I2C:   ready
>>> DRAM:  2 GiB
>>> MMC:   FSL_SDHC: 0, FSL_SDHC: 1
>>>>>> GPR[1] (0x020e0004): 0x48611005
>>>>>> GPR[5] (0x020e0014): 0x00000000
>>>>>> GPR[8] (0x020e0020): 0xfffd4000
>>>>>> GPR[12] (0x020e0030): 0x0f004090
>>>>>> GPC_BASE_ADDR + 0 (0x020dc000): 0x00100000
>>>>>> MX6_DBI_ADDR + 0x7c (0x01ffc07c): 0x0011cc11
>>> DEBUG_R0: 0x036e2b11, DEBUG_R1: 0x08000410
>>>   LTSSM current state: 0x11 (S_L0)
>>>   PIPE transmit K indication: 0
>>>   PIPE Transmit data: 0x6e2b
>>>   Receiver is receiving logical idle: yes
>>>
>>> but the funny thing is under kernel, maybe related to some clock setting? see below
>> Was my fault! Value are exactly the same I'm getting under uboot:
>>
>> I2C:   ready
>> DRAM:  2 GiB
>> MMC:   FSL_SDHC: 0, FSL_SDHC: 1
>>>>> GPR[1] (0x020e0004): 0x48611005
>>>>> GPR[8] (0x020e0020): 0xfffd4000
>>>>> GPR[12] (0x020e0030): 0x0f004090
>>>>> MX6_DBI_ADDR + 0x7c (0x01ffc07c): 0x0011cc11
>> kernel:
>>
>> [    0.377668] imx6q-pcie 1ffc000.pcie: >>> GPR[1]: 0x48611005
>> [    0.377705] imx6q-pcie 1ffc000.pcie: >>> GPR[8]: 0xfffd4000
>> [    0.377720] imx6q-pcie 1ffc000.pcie: >>> GPR[12]: 0x0f004090
>> [    0.377734] imx6q-pcie 1ffc000.pcie: >>> PCIE_RC_LCR (0xf08f007c): 0x0011cc11
>> [    0.586591] imx6q-pcie 1ffc000.pcie: phy link never came up
>>
>>
>>> [    0.235456] PCI host bridge /soc/pcie@0x01000000 ranges:
>>> [    0.235475]   No bus range found for /soc/pcie@0x01000000, using [bus 00-ff]
>>> [    0.235527]   err 0x01f00000..0x01f7ffff -> 0x01f00000
>>> [    0.235577]    IO 0x01f80000..0x01f8ffff -> 0x00000000
>>> [    0.235659]   MEM 0x01000000..0x01efffff -> 0x01000000
>>> [    0.377644] imx6q-pcie 1ffc000.pcie: >>> GPR[1] (0x00000004): 0x00000000
>>> [    0.377666] imx6q-pcie 1ffc000.pcie: >>> GPR[5] (0x00000014): 0x00000000
>>> [    0.377684] imx6q-pcie 1ffc000.pcie: >>> GPR[8] (0x00000020): 0x00000000
>>> [    0.377701] imx6q-pcie 1ffc000.pcie: >>> GPR[12] (0x00000030): 0x00000000
>>> [    0.377717] imx6q-pcie 1ffc000.pcie: >>> PCIE_RC_LCR (0xf08f007c): 0x0011cc11
>>> [    0.586532] imx6q-pcie 1ffc000.pcie: phy link never came up
>>> [    0.586551] imx6q-pcie 1ffc000.pcie: LTSSM current state: 0x3 (S_POLL_COMPLIANCE)
>>> [    0.586566] imx6q-pcie 1ffc000.pcie: PIPE transmit K indication: 1
>>> [    0.586579] imx6q-pcie 1ffc000.pcie: PIPE Transmit data: 0xb5bc
>>> [    0.586592] imx6q-pcie 1ffc000.pcie: Receiver is receiving logical idle: no
>>>
>>> The code I've used to dump the register is using regmap_read(),
>>>
>>> #define IMX6_DUMP_REGISTER(__map, __reg, __name) \
>>>   do {\
>>>     uint32_t val;\
>>>     val = regmap_read(__map, __reg, &val);\
>>>     dev_err(pp->dev, ">>> " __name " (0x%08p): 0x%08x\n", __reg, val);\
>>>   } while(0)
>>>
>>> #define IMX6_DUMP_REGISTER2(__reg, __name) \
>>>   do {\
>>>     uint32_t val;\
>>>     val = readl(__reg);\
>>>     dev_err(pp->dev, ">>> " __name " (0x%08p): 0x%08x\n", __reg, val);\
>>>   } while(0)
>>>
>>>
>>> static void imx6_pcie_dump_registers(struct pcie_port *pp)
>>> {
>>>     struct imx6_pcie *imx6_pcie = to_imx6_pcie(pp);
>>>
>>>         IMX6_DUMP_REGISTER(imx6_pcie->iomuxc_gpr, IOMUXC_GPR1, "GPR[1]");
>>>         IMX6_DUMP_REGISTER(imx6_pcie->iomuxc_gpr, IOMUXC_GPR5, "GPR[5]");
>>>         IMX6_DUMP_REGISTER(imx6_pcie->iomuxc_gpr, IOMUXC_GPR8, "GPR[8]");
>>>         IMX6_DUMP_REGISTER(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12, "GPR[12]");
>>>         IMX6_DUMP_REGISTER2(pp->dbi_base + PCIE_RC_LCR, "PCIE_RC_LCR");
>>> }
>>>
>>> Cheers,
>>> Roberto Fichera.
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>


  parent reply	other threads:[~2016-03-08 14:39 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-01 18:47 iMX6q PCIe phy link never came up on kernel v4.4.x Roberto Fichera
2016-03-02 17:13 ` Roberto Fichera
2016-03-02 19:56   ` Bjorn Helgaas
2016-03-03  9:15     ` Richard Zhu
2016-03-03  9:30       ` Roberto Fichera
2016-03-03  9:39         ` Richard Zhu
2016-03-03 10:55           ` Roberto Fichera
2016-03-03 14:34             ` Roberto Fichera
2016-03-03 18:34               ` Roberto Fichera
2016-03-04  7:11                 ` Richard Zhu
2016-03-04  8:09                   ` Roberto Fichera
2016-03-08 14:39                 ` Roberto Fichera [this message]
2016-03-08 14:53                   ` Lucas Stach
2016-03-08 14:59                     ` Roberto Fichera
2016-03-10 17:35                     ` Roberto Fichera
2016-03-14  8:44                       ` Roberto Fichera
2016-03-15 11:08                         ` Roberto Fichera
2016-03-15 14:04                           ` Bjorn Helgaas
2016-03-15 14:10                           ` Fabio Estevam
2016-03-15 14:29                             ` Roberto Fichera
2016-03-16 14:19                               ` Fabio Estevam
2016-03-16 21:33                                 ` Tim Harvey
2016-03-16 22:12                                   ` Fabio Estevam
2016-03-17  8:32                                     ` Roberto Fichera
2016-03-17 13:28                                       ` Fabio Estevam
2016-03-17 14:14                                         ` Roberto Fichera
2016-03-17 21:09                                           ` Fabio Estevam
2016-03-17  8:20                                   ` Roberto Fichera
2016-03-16  2:07                           ` Richard Zhu
2016-03-03  9:32 ` Lucas Stach
2016-03-03  9:38   ` Roberto Fichera
2016-03-08 15:02   ` Fabio Estevam
2016-03-08 15:06     ` Roberto Fichera
  -- strict thread matches above, loose matches on Subject: below --
2016-02-24 10:12 Roberto Fichera

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=56DEE426.8030902@tekno-soft.it \
    --to=kernel@tekno-soft.it \
    --cc=Richard.Zhu@freescale.com \
    --cc=helgaas@kernel.org \
    --cc=hongxing.zhu@nxp.com \
    --cc=l.stach@pengutronix.de \
    --cc=linux-pci@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.