Re: [PATCH v2] clk: samsung: Keep top BPLL mux on Exynos542x enabled

[Sylwester Nawrocki <s.nawrocki@samsung.com>]

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@samsung.com>
>>>>>> Reviewed-by: Lukasz Luba <lukasz.luba@arm.com>
>>>>>> Tested-by: Lukasz Luba <lukasz.luba@arm.com>
>>>>>> Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
>>>>>> ---
>>>>>
>>>>> 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