From: skannan@codeaurora.org (Saravana Kannan)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/2] clk: Add support for rate table based dividers
Date: Wed, 30 May 2012 21:05:20 -0700 [thread overview]
Message-ID: <4FC6EE00.8010401@codeaurora.org> (raw)
In-Reply-To: <4FBB19E6.2040403@ti.com>
On 05/21/2012 09:45 PM, Rajendra Nayak wrote:
> Hi Ben,
>
> On Monday 21 May 2012 03:17 PM, Ben Dooks wrote:
>> On 17/05/12 11:22, Rajendra Nayak wrote:
>>> Some divider clks do not have any obvious relationship
>>> between the divider and the value programmed in the
>>> register. For instance, say a value of 1 could signify divide
>>> by 6 and a value of 2 could signify divide by 4 etc.
>>> Also there are dividers where not all values possible
>>> based on the bitfield width are valid. For instance
>>> a 3 bit wide bitfield can be used to program a value
>>> from 0 to 7. However its possible that only 0 to 4
>>> are valid values.
>>>
>>> All these cases need the platform code to pass a simple
>>> table of divider/value tuple, so the framework knows
>>> the exact value to be written based on the divider
>>> calculation and can also do better error checking.
>>>
>>> This patch adds support for such rate table based
>>> dividers.
>>
>> I was considering the idea that you simply pass a
>> pointer to a set of routines and a data pointer to
>> the clk-divider code so that any new cases don't
>> require changing the drivers/clk/clk-divider.c
>
> I don;t know if I understand your comment completely.
> Are you suggesting the get min/max etc be function pointers
> passed by platform code (and implemented in platform code?)
> so clk-divider does not need an update every time a new divider
> type is added?
> The idea of extending clk-divider was so its useful for more
> than just OMAP, so the code in clk-divider can be reused across
> multiple platforms. Did I understand your comment right?
>
> regards,
> Rajendra
>
>>
>> This would make the get max / min / special just
>> a function call through a struct.
>>
>>> Signed-off-by: Rajendra Nayak<rnayak@ti.com>
>>> ---
>>> drivers/clk/clk-divider.c | 67
>>> ++++++++++++++++++++++++++++++++++++++++--
>>> include/linux/clk-private.h | 3 +-
>>> include/linux/clk-provider.h | 10 +++++-
>>> 3 files changed, 75 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
>>> index e548c43..e4911ee 100644
>>> --- a/drivers/clk/clk-divider.c
>>> +++ b/drivers/clk/clk-divider.c
>>> @@ -32,30 +32,69 @@
>>> #define div_mask(d) ((1<< (d->width)) - 1)
>>> #define is_power_of_two(i) !(i& ~i)
>>>
>>> +static unsigned int _get_table_maxdiv(const struct clk_div_table
>>> *table)
>>> +{
>>> + unsigned int maxdiv;
>>> + const struct clk_div_table *clkt;
>>> +
>>> + for (clkt = table; clkt->div; clkt++)
>>> + if (clkt->div> maxdiv)
>>> + maxdiv = clkt->div;
>>> + return maxdiv;
>>> +}
>>> +
>>> static unsigned int _get_maxdiv(struct clk_divider *divider)
>>> {
>>> if (divider->flags& CLK_DIVIDER_ONE_BASED)
>>> return div_mask(divider);
>>> if (divider->flags& CLK_DIVIDER_POWER_OF_TWO)
>>> return 1<< div_mask(divider);
Where are these flags defined? I don't see it in any of the patches in
the series. Is my search foo not up to par today?
I think what Ben is saying is that you provider a way (using function or
data/table pointers in clk_divider) that will allow the clk provider to
define a "divider" to "register value" mapping. Say you decide to do
that using a function pointer, then you would implement the following in
clk-divider.c.
div_to_reg_one_based
div_to_reg_pow_two
The actual clock-provider code will pick one of these or implement their
own mapping function. That way, clk-divider won't have to change for any
other convoluted variants of clk divider to register value mapping.
-Saravana
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
WARNING: multiple messages have this Message-ID (diff)
From: Saravana Kannan <skannan@codeaurora.org>
To: Rajendra Nayak <rnayak@ti.com>
Cc: Ben Dooks <ben.dooks@codethink.co.uk>,
mturquette@linaro.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, mturquette@ti.com
Subject: Re: [PATCH 2/2] clk: Add support for rate table based dividers
Date: Wed, 30 May 2012 21:05:20 -0700 [thread overview]
Message-ID: <4FC6EE00.8010401@codeaurora.org> (raw)
In-Reply-To: <4FBB19E6.2040403@ti.com>
On 05/21/2012 09:45 PM, Rajendra Nayak wrote:
> Hi Ben,
>
> On Monday 21 May 2012 03:17 PM, Ben Dooks wrote:
>> On 17/05/12 11:22, Rajendra Nayak wrote:
>>> Some divider clks do not have any obvious relationship
>>> between the divider and the value programmed in the
>>> register. For instance, say a value of 1 could signify divide
>>> by 6 and a value of 2 could signify divide by 4 etc.
>>> Also there are dividers where not all values possible
>>> based on the bitfield width are valid. For instance
>>> a 3 bit wide bitfield can be used to program a value
>>> from 0 to 7. However its possible that only 0 to 4
>>> are valid values.
>>>
>>> All these cases need the platform code to pass a simple
>>> table of divider/value tuple, so the framework knows
>>> the exact value to be written based on the divider
>>> calculation and can also do better error checking.
>>>
>>> This patch adds support for such rate table based
>>> dividers.
>>
>> I was considering the idea that you simply pass a
>> pointer to a set of routines and a data pointer to
>> the clk-divider code so that any new cases don't
>> require changing the drivers/clk/clk-divider.c
>
> I don;t know if I understand your comment completely.
> Are you suggesting the get min/max etc be function pointers
> passed by platform code (and implemented in platform code?)
> so clk-divider does not need an update every time a new divider
> type is added?
> The idea of extending clk-divider was so its useful for more
> than just OMAP, so the code in clk-divider can be reused across
> multiple platforms. Did I understand your comment right?
>
> regards,
> Rajendra
>
>>
>> This would make the get max / min / special just
>> a function call through a struct.
>>
>>> Signed-off-by: Rajendra Nayak<rnayak@ti.com>
>>> ---
>>> drivers/clk/clk-divider.c | 67
>>> ++++++++++++++++++++++++++++++++++++++++--
>>> include/linux/clk-private.h | 3 +-
>>> include/linux/clk-provider.h | 10 +++++-
>>> 3 files changed, 75 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
>>> index e548c43..e4911ee 100644
>>> --- a/drivers/clk/clk-divider.c
>>> +++ b/drivers/clk/clk-divider.c
>>> @@ -32,30 +32,69 @@
>>> #define div_mask(d) ((1<< (d->width)) - 1)
>>> #define is_power_of_two(i) !(i& ~i)
>>>
>>> +static unsigned int _get_table_maxdiv(const struct clk_div_table
>>> *table)
>>> +{
>>> + unsigned int maxdiv;
>>> + const struct clk_div_table *clkt;
>>> +
>>> + for (clkt = table; clkt->div; clkt++)
>>> + if (clkt->div> maxdiv)
>>> + maxdiv = clkt->div;
>>> + return maxdiv;
>>> +}
>>> +
>>> static unsigned int _get_maxdiv(struct clk_divider *divider)
>>> {
>>> if (divider->flags& CLK_DIVIDER_ONE_BASED)
>>> return div_mask(divider);
>>> if (divider->flags& CLK_DIVIDER_POWER_OF_TWO)
>>> return 1<< div_mask(divider);
Where are these flags defined? I don't see it in any of the patches in
the series. Is my search foo not up to par today?
I think what Ben is saying is that you provider a way (using function or
data/table pointers in clk_divider) that will allow the clk provider to
define a "divider" to "register value" mapping. Say you decide to do
that using a function pointer, then you would implement the following in
clk-divider.c.
div_to_reg_one_based
div_to_reg_pow_two
The actual clock-provider code will pick one of these or implement their
own mapping function. That way, clk-divider won't have to change for any
other convoluted variants of clk divider to register value mapping.
-Saravana
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
next prev parent reply other threads:[~2012-05-31 4:05 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-17 10:22 [PATCH 0/2] clk: Add support for more default divider types Rajendra Nayak
2012-05-17 10:22 ` Rajendra Nayak
2012-05-17 10:22 ` [PATCH 1/2] clk: Add support for power of two type dividers Rajendra Nayak
2012-05-17 10:22 ` Rajendra Nayak
2012-05-22 20:26 ` Mike Turquette
2012-05-22 20:26 ` Mike Turquette
2012-05-23 4:45 ` Rajendra Nayak
2012-05-23 4:45 ` Rajendra Nayak
2012-05-17 10:22 ` [PATCH 2/2] clk: Add support for rate table based dividers Rajendra Nayak
2012-05-17 10:22 ` Rajendra Nayak
2012-05-21 9:47 ` Ben Dooks
2012-05-21 9:47 ` Ben Dooks
2012-05-22 4:45 ` Rajendra Nayak
2012-05-22 4:45 ` Rajendra Nayak
2012-05-31 4:05 ` Saravana Kannan [this message]
2012-05-31 4:05 ` Saravana Kannan
2012-06-01 4:40 ` Rajendra Nayak
2012-06-01 4:40 ` Rajendra Nayak
2012-05-29 21:15 ` Turquette, Mike
2012-05-29 21:15 ` Turquette, Mike
2012-05-30 9:24 ` Rajendra Nayak
2012-05-30 9:24 ` Rajendra Nayak
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=4FC6EE00.8010401@codeaurora.org \
--to=skannan@codeaurora.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 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.