From: James Hogan <james.hogan@imgtec.com>
To: Saravana Kannan <skannan@codeaurora.org>
Cc: Mike Turquette <mturquette@linaro.org>,
<linux-arm-kernel@lists.infradead.org>,
Stephen Boyd <sboyd@codeaurora.org>,
<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v4 3/5] clk: add support for clock reparent on set_rate
Date: Wed, 22 May 2013 11:13:17 +0100 [thread overview]
Message-ID: <519C9A3D.1010902@imgtec.com> (raw)
In-Reply-To: <519B01DF.1080700@codeaurora.org>
On 21/05/13 06:10, Saravana Kannan wrote:
> On 05/20/2013 06:28 AM, James Hogan wrote:
>> diff --git a/include/linux/clk-private.h b/include/linux/clk-private.h
>> index dd7adff..8138c94 100644
>> --- a/include/linux/clk-private.h
>> +++ b/include/linux/clk-private.h
>> @@ -33,8 +33,11 @@ struct clk {
>> const char **parent_names;
>> struct clk **parents;
>> u8 num_parents;
>> + u8 new_parent_index;
>
> Why do you need this? Given the new_parent, can't the specific clock
> implementation just look it up when set_rate() is called? Wouldn't that
> be the only time you would actually need the index?
>
> If it's just for optimization of some error cases, I think we should
> drop this to keep the code simpler. One less state to keep track of when
> reading, writing or reviewing the clock framework.
clk_change_rate cannot currently return an error condition so I had
assumed it was better to check that the requested parent clock has a
valid parent index prior to starting to change any clock rates or firing
off any notifications.
Cheers
James
next prev parent reply other threads:[~2013-05-22 10:13 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-20 13:28 [PATCH v4 0/5] clk: implement remuxing during set_rate James Hogan
2013-05-20 13:28 ` [PATCH v4 1/5] clk: abstract parent cache James Hogan
2013-05-20 13:28 ` [PATCH v4 2/5] clk: move some parent related functions upwards James Hogan
2013-05-20 21:16 ` Stephen Boyd
2013-05-20 13:28 ` [PATCH v4 3/5] clk: add support for clock reparent on set_rate James Hogan
2013-05-20 21:17 ` Stephen Boyd
2013-06-13 14:31 ` James Hogan
2013-05-21 5:10 ` Saravana Kannan
2013-05-22 10:13 ` James Hogan [this message]
2013-05-20 13:28 ` [PATCH v4 4/5] clk: add CLK_SET_RATE_NO_REPARENT flag James Hogan
2013-05-20 20:44 ` Stephen Warren
2013-05-22 15:52 ` Maxime Ripard
2013-05-20 13:28 ` [PATCH v4 5/5] clk: clk-mux: implement remuxing on set_rate James Hogan
2013-05-21 4:44 ` Saravana Kannan
2013-06-12 1:01 ` Doug Anderson
2013-06-12 17:45 ` Mike Turquette
2013-06-12 17:55 ` Doug Anderson
2013-06-12 18:07 ` Mike Turquette
2013-06-13 15:18 ` James Hogan
2013-06-13 15:02 ` James Hogan
2013-06-06 1:39 ` [PATCH v4 0/5] clk: implement remuxing during set_rate Haojian Zhuang
2013-06-13 1:35 ` 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=519C9A3D.1010902@imgtec.com \
--to=james.hogan@imgtec.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mturquette@linaro.org \
--cc=sboyd@codeaurora.org \
--cc=skannan@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