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? Cheers, Tyler [1] http://kernelci.org/soc/tegra/job/tegra/kernel/v4.4-rc1-60-gb924f95da320/ [2] http://kernelci.org/soc/tegra/job/tegra/ [3] http://hastebin.com/sekozibilo.lua [4] http://storage.kernelci.org/images/rootfs/buildroot/armel/base/rootfs.cpio.gz [5] http://hastebin.com/jomigahiro.coffee -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
