From: viresh.kumar@linaro.org (Viresh Kumar)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 5/6] Clk: SPEAr1340: fix sys clock parent source and corresponding mask value
Date: Tue, 10 Jul 2012 09:21:09 +0100 [thread overview]
Message-ID: <CAKohponeGSG376uj_jEGCEj4m4OgShD7zRGNpF-8BP2rmQUOYQ@mail.gmail.com> (raw)
In-Reply-To: <20120709225700.GB16202@gmail.com>
On 9 July 2012 23:57, Mike Turquette <mturquette@ti.com> wrote:
> I assume this change has been tested and wouldn't be posted if modifying
> the parent names broke things.
>
> That said, as long as the parent names are valid strings then the clk
> framework should handle them. When calling __clk_lookup for parent name
> "none", __clk_lookup will return NULL (of course assuming no one else in
> the system registered a clock named "none", which would be silly). This
> is handled gracefully by the clk framework by re-parenting your "sys"
> clk from $old_parent to the "orphan" list.
>
> At the top level, there are basically two clock trees. The first tree
> is "real" clock tree which starts as a list of clocks that set the
> CLK_IS_ROOT flag. The second tree is a tree of "orphans" for clocks
> which are defined but "disconnected" from any real root clock (which
> might be caused by missing data, etc).
>
> In general it is OK to declare parent names which might result in your
> clock being orphaned. In practice it is more likely that your data
> matches your code: e.g. if you don't support a parent clock in the data
> then you likely never try use that missing parent clock in your code.
>
> The OMAP port does in fact make use of the orphan tree for some clocks,
> so it is tested. However we haven't had any users of the clock tree
> which made a lot of use of "dynamic" reparenting to and from the orphan
> tree. I did unit test this back during the 3.4 cycle, but I haven't
> since. Let me know if you have any problems with it.
>
Hi Mike,
For example, clk1 have parents pclk1 and pclk2. Register values
for pclk1 is 0X and for pclk2 is 1X. i.e. pclk1 is selected for both 00 and
01.
And pclk2 is selected for 10 and 11. so, its better to take care of all
these situations,
otherwise there can be corner cases like: In linux we decide to use 00 for
pclk1, 10 for
pclk2 and other two for "none". But bootloader, enabled the clock with 01
for pclk1.
This clock isn't a orphan but it will look like that in our clock tree.
So, is this OK in the current implementation of clk framework to have
parents like
"pclk1", "pclk1", "pclk2", "pclk2"?
--
viresh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120710/01ab87ad/attachment-0001.html>
next prev parent reply other threads:[~2012-07-10 8:21 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-09 10:31 [PATCH 1/6] ARM: DTS: SPEAr13xx: Fix Interrupt bindings Shiraz Hashim
2012-07-09 10:31 ` [PATCH 2/6] clk: SPEAr1340: Fix clk enable register for uart1 and i2c1 Shiraz Hashim
2012-07-09 10:55 ` viresh kumar
2012-07-09 10:31 ` [PATCH 3/6] clk: SPEAr13xx: Add localtimer (twd) clock support Shiraz Hashim
2012-07-09 10:57 ` viresh kumar
2012-07-09 10:31 ` [PATCH 4/6] Clk: SPEAr13xx: Initialize con_id for Ethernet phy clks Shiraz Hashim
2012-07-09 10:58 ` viresh kumar
2012-07-09 10:31 ` [PATCH 5/6] Clk: SPEAr1340: fix sys clock parent source and corresponding mask value Shiraz Hashim
2012-07-09 11:04 ` viresh kumar
2012-07-09 12:04 ` vipul kumar samar
2012-07-09 12:34 ` viresh kumar
2012-07-09 22:57 ` Mike Turquette
2012-07-10 8:21 ` Viresh Kumar [this message]
2012-07-11 20:11 ` Mike Turquette
2012-07-10 8:52 ` Shiraz Hashim
2012-07-09 10:53 ` [PATCH 1/6] ARM: DTS: SPEAr13xx: Fix Interrupt bindings viresh kumar
2012-07-09 11:18 ` [PATCH 6/6] ARM: SPEAr13xx: Add auxdata for Ethernet controller Shiraz Hashim
2012-07-09 11:30 ` viresh kumar
2012-07-09 12:29 ` vipul kumar samar
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=CAKohponeGSG376uj_jEGCEj4m4OgShD7zRGNpF-8BP2rmQUOYQ@mail.gmail.com \
--to=viresh.kumar@linaro.org \
--cc=linux-arm-kernel@lists.infradead.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;
as well as URLs for NNTP newsgroup(s).