From: "Heiko Stübner" <heiko@sntech.de>
To: Mike Turquette <mturquette@linaro.org>,
Stephen Boyd <sboyd@codeaurora.org>
Cc: dianders@chromium.org, linux-clk@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-rockchip@lists.infradead.org,
linux@arm.linux.org.uk
Subject: [PATCH v2 0/2] clk: improve handling of orphan clocks
Date: Sun, 12 Apr 2015 13:36:30 +0200 [thread overview]
Message-ID: <75204537.lSvovFhEiG@diego> (raw)
Using orphan clocks can introduce strange behaviour as they don't have
rate information at all and also of course don't track
This v2 takes into account suggestions from Stephen Boyd to not try to
walk the clock tree at runtime but instead keep track of orphan states
on clock tree changes and making it mandatory for everybody from the
start as orphan clocks should not be used at all.
This fixes an issue on most rk3288 platforms, where some soc-clocks
are supplied by a 32khz clock from an external i2c-chip which often
is only probed later in the boot process and maybe even after the
drivers using these soc-clocks like the tsadc temperature sensor.
In this case the driver using the clock should of course defer probing
until the clock is actually usable.
changes since v1:
- track orphan status on clock tree changes instead of walking the
tree on clk_get operations
- make get-deferals mandatory for everybody
Heiko Stuebner (2):
clk: track the orphan status of clocks and their children
clk: prevent orphan clocks from being used
drivers/clk/clk.c | 49 ++++++++++++++++++++++++++++++++++++++++++++++---
1 file changed, 46 insertions(+), 3 deletions(-)
--
2.1.4
next reply other threads:[~2015-04-12 11:36 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-12 11:36 Heiko Stübner [this message]
2015-04-12 11:37 ` [PATCH v2 1/2] clk: track the orphan status of clocks and their children Heiko Stübner
2015-04-20 22:29 ` Stephen Boyd
2015-04-12 11:38 ` [PATCH v2 2/2] clk: prevent orphan clocks from being used Heiko Stübner
2015-04-20 22:32 ` Stephen Boyd
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=75204537.lSvovFhEiG@diego \
--to=heiko@sntech.de \
--cc=dianders@chromium.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=linux@arm.linux.org.uk \
--cc=mturquette@linaro.org \
--cc=sboyd@codeaurora.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox