On 02.09.2020 11:24, Sylwester Nawrocki wrote: > On 24.08.2020 12:31, Krzysztof Kozlowski wrote: >> On Mon, Aug 24, 2020 at 12:28:51PM +0200, Sylwester Nawrocki wrote: >>> On 8/23/20 12:12, Sylwester Nawrocki wrote: >>>> On 8/19/20 05:14, Stephen Boyd wrote: >>>>> Quoting Marek Szyprowski (2020-08-07 06:31:43) >>>>>> BPLL clock must not be disabled because it is needed for proper DRAM >>>>>> operation. This is normally handled by respective memory devfreq driver, >>>>>> but when that driver is not yet probed or its probe has been >>>>>> deferred the >>>>>> clock might got disabled what causes board hang. Fix this by calling >>>>>> clk_prepare_enable() directly from the clock provider driver. >>>>>> >>>>>> Signed-off-by: Marek Szyprowski <m.szyprowski@xxxxxxxxxxx> >>>>>> Reviewed-by: Lukasz Luba <lukasz.luba@xxxxxxx> >>>>>> Tested-by: Lukasz Luba <lukasz.luba@xxxxxxx> >>>>>> Acked-by: Krzysztof Kozlowski <krzk@xxxxxxxxxx> >>>>>> --- >>>>> >>>>> Can I pick this up for clk-fixes? >>>> >>>> Sure, thanks for taking care of this. >>> >>> OTOH, I planned to queue that patch for next merged window, together >>> with a patch that depends on that one, since the fix is not for an issue >>> introduced in the last merge window. >>> I guess it's better to avoid pulling (part of) the clk-fixes branch to >>> the clk/samsung tree for next merge window? >> >> All current multi_v7 and some of exynos defconfig boots fail on Odroid >> XU3-family, starting from v5.9-rc1. On kernelci and my boot systems. If >> I understand correctly, this is a fix for this issue, so it should go as >> fast as possible to v5.9 cycle. >> >> Otherwise we cannot test anything. The current v5.9 RC is then simply >> broken. > > Right, we need that patch in v5.9. Stephen, can you please apply > the patch to your clk-fixes? So I applied the patch to my tree and sent you a pull request instead... :) I thought it will handling subsequent patches that depend on that one more straightforward. -- Regards, Sylwester