imx6: PCIe imx6_pcie_assert_core_reset() hangs after watchdog reset
Philippe De Muyter
phdm at macq.eu
Sun Nov 6 07:31:17 PST 2016
Hi ARM i.MX6q experts,
sorry to come back with an old problem. I work with with two
different custom boards, designed after the SabreSD board with imx6dl
and imx6q cpus, and I have exactly the same problem : linux kernel hangs
in imx6_pcie_assert_core_reset() at the line :
val = readl(pp->dbi_base + PCIE_PL_PFLR);
this happens constantly after a watchdog reset, and also
sometimes (or on some boards) after a reboot. As we know that
U-Boot on our boards will never mess with the PCI setup, and
that if the PCIe block is configured, it has certainly be
configured by the previous kernel session, I have merely disabled the
code block trying to put back the PCIe block into configurable state.
I have no problem so far, but do you agree that this is a valid fix ?
I use either v3.17 or Freescale's 4.1.15_1.2.0_ga
On Thu, Mar 26, 2015 at 12:39:58PM +0000, Lucas Stach wrote:
> Hi Tim,
> Am Donnerstag, den 26.03.2015, 06:23 -0700 schrieb Tim Harvey:
> > On Thu, Mar 26, 2015 at 4:06 AM, Lucas Stach <l.stach at pengutronix.de> wrote:
> > > Am Mittwoch, den 25.03.2015, 11:32 +0100 schrieb Stefan Roese:
> > > Okay, I've looked a bit into this and it seems there is no easy solution
> > > available. It is really unfortunate that the WD reset doesn't reset the
> > > GPR registers. Also I have no idea if the WD reset properly resets the
> > > PCIe core, as the reset signal of this core is only wired to the POR
> > > line.
> > >
> > > To fix this (almost) properly we would have to change the complete init
> > > order of the core, which isn't an easy task, as experience has shown
> > > that even small changes in that area can prevent the link from coming up
> > > under certain circumstances.
> > >
> > > Which brings me back to my earlier assertion that WD reset should really
> > > be done through the PMIC. That's yet another case of a WD making the
> > > overall system more instable.
> > >
> > > I think the easiest workaround for now is to detect the WD reset in your
> > > bootloader and bash the expected default values into the GPR bits.
> > >
> > > Regards,
> > > Lucas
> > Lucas,
> > There are many boards out there that unfortunately don't reset PMIC's
> > properly, IMHO due to a confusing reference design from Freescale.
> > Using the WDOGx_WRSR register we can detect the reason for reset:
> > Bit 4 - POR - Power on reset
> > Bit 1 - TOUT - Watchdog timeout
> > Bit 0 - SFTW - Software reset (used in machine_restart)
> > Can we reset the GPR registers based on bits 0 or 1 set, or use these
> > as further qualifiers in the WAR?
> Doing it in the kernel is too late. This WAR is specifically to work
> around bootloaders leaving the PCI link running when jumping into the
> kernel. We use the GPR bits to detect if the bootloader has touched the
> PCIe core. Unfortunately we see the same signature if the kernel touched
> PCIe and the system got reset by the WD.
> If we reset the GPR bits depending on the reset reason register in the
> kernel we have no way to know if the bootloader has touched the PCIe
> core after a WD reset (in which case we still need to apply the WAR). So
> the only way to keep the WAR working while cleaning out bad WD reset
> behavior is to reset the GPR bits in the bootloader, before the
> bootloader itself may touch the PCIe core.
> It may be possible to come up with a solution for this in the kernel by
> looking at the PCIe clock status when entering the kernel, but this
> means that we scatter even more WAR code for the bad Freescale PCIe
> integration throughout the kernel, as such code has to go into the
> platform as we don't have the required information at hand in the PCI
> driver. So I'm not really thrilled by thinking about doing it in the
> Pengutronix e.K. | Lucas Stach |
> Industrial Linux Solutions | http://www.pengutronix.de/ |
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
Philippe De Muyter +32 2 6101532 Macq SA rue de l'Aeronef 2 B-1140 Bruxelles
More information about the linux-arm-kernel