On 25/11/15 17:48, Jon Hunter wrote: > > On 25/11/15 15:52, Tyler Baker wrote: >> On 25 November 2015 at 07:11, Thierry Reding <thierry.red...@gmail.com> >> wrote: >>> On Mon, Nov 23, 2015 at 03:18:59PM -0800, Tyler Baker wrote: >>>> Hi Jon, >>>> >>>> On 20 November 2015 at 07:11, Jon Hunter <jonath...@nvidia.com> wrote: >>>>> The _clk_disable_pll() function will attempt to place a PLL into bypass >>>>> if the TEGRA_PLL_BYPASS is specified for the PLL and then disable the PLL >>>>> by clearing the enable bit. To place the PLL into bypass, the bypass bit >>>>> needs to be set and not cleared. Fix this by setting the bypass bit and >>>>> not clearing it. >>>>> >>>>> Signed-off-by: Jon Hunter <jonath...@nvidia.com> >>>> >>>> The kernelci.org bot recently detected a jetson-tk1 boot failure[1][2] >>>> in the tegra tree. This boot failure has only been observed when >>>> booting with a multi_v7_defconfig kernel variant. The bot bisected[3] >>>> this boot failure to this commit, and I confirmed reverting it on top >>>> of the tegra for-next branch resolves the issue. The ramdisk[4] used >>>> for booting is loaded with the modules from the build. It appears to >>>> me that as the modules are being loaded in userspace by eudev the >>>> jetson-tk1 locks up. I've sifted through the console logs a bit, and >>>> found this splat to be most interesting[5]. Can you confirm this >>>> issue on your end? >>> >>> Just to close the loop on this: we've discussed this on IRC and came to >>> the conclusion that not using the bypass mode is safer (switching into >>> and out of bypass can glitch). I've dropped this patch for now and Jon >>> will be looking into a second revision of the patch which, in addition >>> to fixing bypass (the fix is legit, it just happens to break because of >>> the glitch, most likely), will also remove the BYPASS flag setting so >>> that bypass will not be used. >> >> Thanks for the update, I appreciate you guys looking into this issue. >> Please CC me on any fixes, I can re-test and give my tested-by. > > No problem. On 2nd thoughts I am wondering if there is any value in > bypassing the PLL when disabling it. I will look into this and see what > I find out.
So I got some feedback saying that setting the bypass bit is not glitch-less for most PLLs and so we should avoid setting this. It may look a bit odd from reviewing the code, but it is clear to me know. So we should just drop this change. However, if you like we could add a comment to document why we are doing this. Cheers Jon -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
