From: rnayak@ti•com (Rajendra Nayak)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH 2/2] clk: Add support for rate table based dividers
Date: Fri, 01 Jun 2012 10:10:33 +0530 [thread overview]
Message-ID: <4FC847C1.2060809@ti.com> (raw)
In-Reply-To: <4FC6EE00.8010401@codeaurora.org>
On Thursday 31 May 2012 09:35 AM, Saravana Kannan wrote:
> 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?
Well, the flag was already part of Mike's original series, it was just
not used.
>
> 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.
I get the point. But I am just wondering if there are any such
convoluted variants (which are platform specific).
I though the table should be able to handle *all* such variants.
>
> -Saravana
>
next prev parent reply other threads:[~2012-06-01 4:40 UTC|newest]
Thread overview: 11+ 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 ` [PATCH 1/2] clk: Add support for power of two type dividers Rajendra Nayak
2012-05-22 20:26 ` Mike Turquette
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-21 9:47 ` Ben Dooks
2012-05-22 4:45 ` Rajendra Nayak
2012-05-31 4:05 ` Saravana Kannan
2012-06-01 4:40 ` Rajendra Nayak [this message]
2012-05-29 21:15 ` Turquette, Mike
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=4FC847C1.2060809@ti.com \
--to=rnayak@ti$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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