From mboxrd@z Thu Jan 1 00:00:00 1970 From: l.stach@pengutronix.de (Lucas Stach) Date: Thu, 26 Mar 2015 14:39:58 +0100 Subject: imx6: PCIe imx6_pcie_assert_core_reset() hangs after watchdog reset In-Reply-To: References: <55128016.3030903@denx.de> <1427276390.2813.7.camel@pengutronix.de> <55128EC8.6080805@denx.de> <1427367975.3378.6.camel@pengutronix.de> Message-ID: <1427377198.3378.16.camel@pengutronix.de> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org 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 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/ |