| Message ID | CAOMZO5B2eTfHC2Rx7A3L5UhdmFV5r2jHpgLBwZpuxmGnEKd-zw@mail.gmail.com |
|---|---|
| State | Not Applicable |
| Delegated to: | Stefano Babic |
| Headers | show |
On Thursday, June 05, 2014 at 05:27:08 PM, Fabio Estevam wrote: > Tim, > > On Wed, Jun 4, 2014 at 9:16 PM, Tim Harvey <tharvey@gateworks.com> wrote: > > work-around the problem on my end as well. Note that I do not see this > > issue unless I'm using one of our boards with a PCIe switch and If I > > disable PCI support in u-boot this does not occur. This feels like a > > Does this help? > > drivers/pci/pcie_imx.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/drivers/pci/pcie_imx.c b/drivers/pci/pcie_imx.c > index c48737e..190cdec 100644 > --- a/drivers/pci/pcie_imx.c > +++ b/drivers/pci/pcie_imx.c > @@ -435,8 +435,7 @@ static int imx6_pcie_init_phy(void) > clrbits_le32(&iomuxc_regs->gpr[12], IOMUXC_GPR12_APPS_LTSSM_ENABLE); > > clrsetbits_le32(&iomuxc_regs->gpr[12], > - IOMUXC_GPR12_DEVICE_TYPE_MASK, > - IOMUXC_GPR12_DEVICE_TYPE_RC); > + IOMUXC_GPR12_DEVICE_TYPE_MASK, 4 << 12); Is this the setting of RC-mode in GPR12 ? That's wrong in the FSL datasheet, not in the code IIRC ;-) Best regards, Marek Vasut
On Thu, Jun 5, 2014 at 2:53 PM, Marek Vasut <marex@denx.de> wrote: >> Does this help? >> >> drivers/pci/pcie_imx.c | 3 +-- >> 1 file changed, 1 insertion(+), 2 deletions(-) >> >> diff --git a/drivers/pci/pcie_imx.c b/drivers/pci/pcie_imx.c >> index c48737e..190cdec 100644 >> --- a/drivers/pci/pcie_imx.c >> +++ b/drivers/pci/pcie_imx.c >> @@ -435,8 +435,7 @@ static int imx6_pcie_init_phy(void) >> clrbits_le32(&iomuxc_regs->gpr[12], IOMUXC_GPR12_APPS_LTSSM_ENABLE); >> >> clrsetbits_le32(&iomuxc_regs->gpr[12], >> - IOMUXC_GPR12_DEVICE_TYPE_MASK, >> - IOMUXC_GPR12_DEVICE_TYPE_RC); >> + IOMUXC_GPR12_DEVICE_TYPE_MASK, 4 << 12); > > Is this the setting of RC-mode in GPR12 ? That's wrong in the FSL datasheet, not > in the code IIRC ;-) Yes, RM is wrong. U-boot is setting it to 2. Kernel sets it to 4, which is the correct value.
On Thursday, June 05, 2014 at 09:20:12 PM, Fabio Estevam wrote: > On Thu, Jun 5, 2014 at 2:53 PM, Marek Vasut <marex@denx.de> wrote: > >> Does this help? > >> > >> drivers/pci/pcie_imx.c | 3 +-- > >> 1 file changed, 1 insertion(+), 2 deletions(-) > >> > >> diff --git a/drivers/pci/pcie_imx.c b/drivers/pci/pcie_imx.c > >> index c48737e..190cdec 100644 > >> --- a/drivers/pci/pcie_imx.c > >> +++ b/drivers/pci/pcie_imx.c > >> @@ -435,8 +435,7 @@ static int imx6_pcie_init_phy(void) > >> > >> clrbits_le32(&iomuxc_regs->gpr[12], > >> IOMUXC_GPR12_APPS_LTSSM_ENABLE); > >> > >> clrsetbits_le32(&iomuxc_regs->gpr[12], > >> > >> - IOMUXC_GPR12_DEVICE_TYPE_MASK, > >> - IOMUXC_GPR12_DEVICE_TYPE_RC); > >> + IOMUXC_GPR12_DEVICE_TYPE_MASK, 4 << 12); > > > > Is this the setting of RC-mode in GPR12 ? That's wrong in the FSL > > datasheet, not in the code IIRC ;-) > > Yes, RM is wrong. U-boot is setting it to 2. Kernel sets it to 4, > which is the correct value. Ah yes, 0x4 is correct, I stand corrected, sorry. Best regards, Marek Vasut
On Thu, Jun 5, 2014 at 7:04 PM, Marek Vasut <marex@denx.de> wrote:
> Ah yes, 0x4 is correct, I stand corrected, sorry.
No problem. I will submit a patch for it soon.
On Friday, June 06, 2014 at 12:14:03 AM, Fabio Estevam wrote: > On Thu, Jun 5, 2014 at 7:04 PM, Marek Vasut <marex@denx.de> wrote: > > Ah yes, 0x4 is correct, I stand corrected, sorry. > > No problem. I will submit a patch for it soon. Thanks! Best regards, Marek Vasut
On Thu, Jun 5, 2014 at 8:27 AM, Fabio Estevam <festevam@gmail.com> wrote: > Tim, > > On Wed, Jun 4, 2014 at 9:16 PM, Tim Harvey <tharvey@gateworks.com> wrote: > >> work-around the problem on my end as well. Note that I do not see this >> issue unless I'm using one of our boards with a PCIe switch and If I >> disable PCI support in u-boot this does not occur. This feels like a > > Does this help? > > drivers/pci/pcie_imx.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/drivers/pci/pcie_imx.c b/drivers/pci/pcie_imx.c > index c48737e..190cdec 100644 > --- a/drivers/pci/pcie_imx.c > +++ b/drivers/pci/pcie_imx.c > @@ -435,8 +435,7 @@ static int imx6_pcie_init_phy(void) > clrbits_le32(&iomuxc_regs->gpr[12], IOMUXC_GPR12_APPS_LTSSM_ENABLE); > > clrsetbits_le32(&iomuxc_regs->gpr[12], > - IOMUXC_GPR12_DEVICE_TYPE_MASK, > - IOMUXC_GPR12_DEVICE_TYPE_RC); > + IOMUXC_GPR12_DEVICE_TYPE_MASK, 4 << 12); > clrsetbits_le32(&iomuxc_regs->gpr[12], > IOMUXC_GPR12_LOS_LEVEL_MASK, > IOMUXC_GPR12_LOS_LEVEL_9); Fabio, Good catch, but that doesn't resolve the issue i'm seeing here. Any other ideas? Regards, Tim
Hi Tim, On Fri, Jun 6, 2014 at 1:35 AM, Tim Harvey <tharvey@gateworks.com> wrote: > Fabio, > > Good catch, but that doesn't resolve the issue i'm seeing here. > > Any other ideas? Do you still have issues after applying David's delay workaround? On my mx6qsabresd I noticed that: - if U-boot has PCI driver enabled, then kernel hangs 100% of time. - if U-boot does not have PCI driver enabled, then the kernel boots but does not detect my PCI card. After applying David's workaround I can boot the kernel with PCI driver enabled in U-boot and the kernel does detect the PCI Wifi module.
On Tuesday, June 17, 2014 at 04:14:20 PM, Fabio Estevam wrote: > Hi Tim, > > On Fri, Jun 6, 2014 at 1:35 AM, Tim Harvey <tharvey@gateworks.com> wrote: > > Fabio, > > > > Good catch, but that doesn't resolve the issue i'm seeing here. > > > > Any other ideas? > > Do you still have issues after applying David's delay workaround? Yes Again, apologies for the late reply. > On my mx6qsabresd I noticed that: > > - if U-boot has PCI driver enabled, then kernel hangs 100% of time. That's because the PCIe core and PCIe PIPE PHY are not properly restarted. Do we have any software way to put the PCIe core to an initial state ? Same pro PIPE PHY ? > - if U-boot does not have PCI driver enabled, then the kernel boots > but does not detect my PCI card. Well, that's some other shitness. I can get MX6SabreSDP to detect my card, but I have that 1-out-of-200 "phy link never came up" problem. > After applying David's workaround I can boot the kernel with PCI > driver enabled in U-boot and the kernel does detect the PCI Wifi > module. OK. Even with David's patch or with FSL supplied patches, I still have the 1- out-of-200 failure case :-/ Best regards, Marek Vasut
diff --git a/drivers/pci/pcie_imx.c b/drivers/pci/pcie_imx.c index c48737e..190cdec 100644 --- a/drivers/pci/pcie_imx.c +++ b/drivers/pci/pcie_imx.c @@ -435,8 +435,7 @@ static int imx6_pcie_init_phy(void) clrbits_le32(&iomuxc_regs->gpr[12], IOMUXC_GPR12_APPS_LTSSM_ENABLE); clrsetbits_le32(&iomuxc_regs->gpr[12], - IOMUXC_GPR12_DEVICE_TYPE_MASK, - IOMUXC_GPR12_DEVICE_TYPE_RC); + IOMUXC_GPR12_DEVICE_TYPE_MASK, 4 << 12); clrsetbits_le32(&iomuxc_regs->gpr[12], IOMUXC_GPR12_LOS_LEVEL_MASK, IOMUXC_GPR12_LOS_LEVEL_9);