From: Krzysztof Kozlowski <krzk@kernel.org>
To: Sylwester Nawrocki <s.nawrocki@samsung.com>
Cc: linux-clk@vger.kernel.org, tomasz.figa@gmail.com,
cw00.choi@samsung.com, m.szyprowski@samsung.com,
sboyd@kernel.org, mturquette@baylibre.com,
b.zolnierkie@samsung.com, linux-kernel@vger.kernel.org,
linux-samsung-soc@vger.kernel.org
Subject: Re: [PATCH v5] clk: samsung: Prevent potential endless loop in the PLL ops
Date: Sun, 22 Nov 2020 16:16:02 +0100 [thread overview]
Message-ID: <20201122151602.GA5346@kozik-lap> (raw)
In-Reply-To: <20201120155731.26898-1-s.nawrocki@samsung.com>
On Fri, Nov 20, 2020 at 04:57:31PM +0100, Sylwester Nawrocki wrote:
> The PLL status polling loops in the set_rate callbacks of some PLLs
> have no timeout detection and may become endless loops when something
> goes wrong with the PLL.
>
> For some PLLs there is already the ktime API based timeout detection,
> but it will not work in all conditions when .set_rate gets called.
> In particular, before the clocksource is initialized or when the
> timekeeping is suspended.
>
> This patch adds a common helper with the PLL status bit polling and
> timeout detection. For conditions where the timekeeping API should not
> be used a simple readl_relaxed/cpu_relax() busy loop is added with the
> iterations limit derived from measurements of readl_relaxed() execution
> time for various PLL types and Exynos SoCs variants.
>
> Actual PLL lock time depends on the P divider value, the VCO frequency
> and a constant PLL type specific LOCK_FACTOR and can be calculated as
>
> lock_time = Pdiv * LOCK_FACTOR / VCO_freq
>
> For the ktime API use cases a common timeout value of 20 ms is applied
> for all the PLLs with an assumption that maximum possible value of Pdiv
> is 64, maximum possible LOCK_FACTOR value is 3000 and minimum VCO
> frequency is 24 MHz.
>
> Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Best regards,
Krzysztof
next prev parent reply other threads:[~2020-11-22 15:16 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20201120155747eucas1p248a1f0b71fbd8f329271494d7a207347@eucas1p2.samsung.com>
2020-11-20 15:57 ` [PATCH v5] clk: samsung: Prevent potential endless loop in the PLL ops Sylwester Nawrocki
2020-11-22 15:16 ` Krzysztof Kozlowski [this message]
2020-11-23 10:20 ` Sylwester Nawrocki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20201122151602.GA5346@kozik-lap \
--to=krzk@kernel.org \
--cc=b.zolnierkie@samsung.com \
--cc=cw00.choi@samsung.com \
--cc=linux-clk@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=mturquette@baylibre.com \
--cc=s.nawrocki@samsung.com \
--cc=sboyd@kernel.org \
--cc=tomasz.figa@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.