imx6: PCIe imx6_pcie_assert_core_reset() hangs after watchdog reset

Lucas Stach l.stach at pengutronix.de
Thu Mar 26 06:39:58 PDT 2015


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

Regards,
Lucas

-- 
Pengutronix e.K.             | Lucas Stach                 |
Industrial Linux Solutions   | http://www.pengutronix.de/  |




More information about the linux-arm-kernel mailing list