From: Francesco VIRLINZI <francesco.virlinzi@st.com>
To: linux-sh@vger.kernel.org
Subject: Re: [PATCH] sh: clkfwk: Changed the init function
Date: Thu, 19 Mar 2009 08:24:38 +0000 [thread overview]
Message-ID: <49C20146.70702@st.com> (raw)
In-Reply-To: <49BA1505.7000500@st.com>
Hi Paul
> The clock framework itself also specifies that no assumptions can be made
> about the state of the clock, so you must call clk_enable() to enable the
> clock after bumping the refcount with clk_get(), and then and only then
> can you determine if there is a problem with the clock settings.
I understand you point of view... and also my example was not so good!
Let me try again ;-)
Now in the clock fmwk we have also clk_set_parent/clk_get_parent this means
we can change the topology on the fly (we have this behavior with video
clocks).
From my point of view the .init function should also initialize the
clk->parent field based
on the loaded hw setting... (I assume we can not hard-code something
like clk_x->parent = &clk_y;
just because something like that it's strictly based on hardware value
on power-up).
Therefore I can trust the clk->parent value only after a call to the
.init function.
But with the current clfwk is mandatory that a topology change can be
done _only_ after the clock
is enabled while in my point of view I should be able to change the
topology without
this constraint.
Once a clock is registered I should be able to call clk_set_parent
without being forced to enable it.
Moreover it could be dangerous for the devices that are using the clock
because first of all I have to
enable the clock.. and only after that I can change (if required) the
clk->parent (while the clock is running).
Regards
Francesco
next prev parent reply other threads:[~2009-03-19 8:24 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-13 8:10 [PATCH] sh: clkfwk: Changed the init function Francesco VIRLINZI
2009-03-13 8:34 ` Francesco VIRLINZI
2009-03-13 16:31 ` Jean-Christophe PLAGNIOL-VILLARD
2009-03-16 5:24 ` Francesco VIRLINZI
2009-03-16 11:13 ` Paul Mundt
2009-03-16 12:39 ` Francesco VIRLINZI
2009-03-16 12:45 ` Paul Mundt
2009-03-19 8:24 ` Francesco VIRLINZI [this message]
2009-04-07 8:25 ` Francesco VIRLINZI
2009-04-07 20:27 ` Jean-Christophe PLAGNIOL-VILLARD
2009-05-14 3:40 ` Paul Mundt
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=49C20146.70702@st.com \
--to=francesco.virlinzi@st.com \
--cc=linux-sh@vger.kernel.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