[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c3c40d62-f5bb-6b13-0af9-ce774718eaa6@samsung.com>
Date: Tue, 15 Sep 2020 13:34:24 +0200
From: Sylwester Nawrocki <s.nawrocki@...sung.com>
To: Chanwoo Choi <cw00.choi@...sung.com>, tomasz.figa@...il.com
Cc: linux-clk@...r.kernel.org, sboyd@...nel.org,
mturquette@...libre.com, linux-samsung-soc@...r.kernel.org,
linux-kernel@...r.kernel.org, b.zolnierkie@...sung.com,
m.szyprowski@...sung.com
Subject: Re: [PATCH v3] clk: samsung: Prevent potential endless loop in the
PLL set_rate ops
On 14.08.2020 02:46, Chanwoo Choi wrote:
> On 8/13/20 6:55 PM, Sylwester Nawrocki wrote:
>> In the .set_rate callback for some PLLs there is a loop polling state
>> of the PLL lock bit and it may become an endless loop when something
>> goes wrong with the PLL. For some PLLs there is already code for polling
>> with a timeout but it uses the ktime API, which doesn't work in some
>> conditions when the set_rate op is called, in particular during
>> initialization of the clk provider before the clocksource initialization
>> has completed. Hence the ktime API cannot be used to reliably detect
>> the PLL locking timeout.
>>
>> This patch adds a common helper function for busy waiting on the PLL lock
>> bit with timeout detection.
>> Signed-off-by: Sylwester Nawrocki <s.nawrocki@...sung.com>
>> ---
>> Changes for v3:
>> - use busy-loop with udelay() instead of ktime API
>> Changes for v2:
>> - use common readl_relaxed_poll_timeout_atomic() macro
>> ---
>> drivers/clk/samsung/clk-pll.c | 94 ++++++++++++++++---------------------------
>> 1 file changed, 34 insertions(+), 60 deletions(-)
> Thanks.
>
> Acked-by: Chanwoo Choi <cw00.choi@...sung.com>
Patch applied, thank you for your comments.
Powered by blists - more mailing lists