From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Mason <slash.tmp@free.fr>, linux-clk <linux-clk@vger.kernel.org>
Cc: Stephen Boyd <sboyd@codeaurora.org>,
Michael Turquette <mturquette@baylibre.com>,
"Rafael J. Wysocki" <rjw@rjwysocki.net>,
Heikki Krogerus <heikki.krogerus@linux.intel.com>,
Sebastian Frias <sf84@laposte.net>,
Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: Re: Common/typical fractional divider HW API
Date: Fri, 05 Feb 2016 17:05:58 +0200 [thread overview]
Message-ID: <1454684758.31169.77.camel@linux.intel.com> (raw)
In-Reply-To: <56B4B67D.2080707@free.fr>
On Fri, 2016-02-05 at 15:49 +0100, Mason wrote:
> Hello,
>
> AFAICT, the clk-fractional-divider driver implements the following
> hardware API:
>
> M and N are two fields in the same register.
> DIV = M / N
>
> Is this HW API common/typical in the embedded world?
> in the PC world?
>
At least all new Intel SoCs have it, besides that there is one more
user of the struct clk_fractional_divider, but I have no idea if they
have something similar to this.
>
> My hardware uses a slightly weird (to me) API:
>
> I = 0-255 (8 bits)
> F = 0-15 (4 bits)
This part is okay.
>
> I = 0 => DIV = +INF
On Intel we recognize this as an absence of the divider.
> I = 1 => DIV = 1 + F/(32-F)
Weird part, indeed. But seems it doubles a precision in a range
[1 .. 1 + 1/2]
> I > 1 => DIV = I + F/16
This just normal operation.
>
> Is this HW API common/typical in the embedded world?
> (Perhaps just the linear part for I > 1)
I saw similar approach in few UART drivers, but they do not use CLK
framework.
So, I could consider this one is more popular / wider, than what we
have in Intel SoCs.
>
> I see two downsides to this API:
>
> 1) I = 1 is a special case
> 2) A lot of the value space is wasted on large values.
>
> For example, when I = 250, we don't really care about 250.0625,
> 250.125,
> etc, or even nearby integer values, for that matter.
>
> I think it's better to have a distribution with high density in small
> values, and low density in high values (sort of like floating point).
>
> For example:
>
> I = 0-15 (4 bits)
> F = 0-255 (8 bits)
> DIV = 2^I * (1 + F/256)
>
> (We could probably even shave 2-4 bits on F.)
>
> Are there downsides to this HW API?
> Is this HW API common/typical in the embedded world?
So, what is your intention? If you would like to use CLK framework you
might consider existing providers and users and might implement a
specific one for similar cases.
Also it's possible to convert clock providers for, e.g., UARTs to use
this kind of divider.
--
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy
WARNING: multiple messages have this Message-ID (diff)
From: andriy.shevchenko@linux.intel.com (Andy Shevchenko)
To: linux-arm-kernel@lists.infradead.org
Subject: Common/typical fractional divider HW API
Date: Fri, 05 Feb 2016 17:05:58 +0200 [thread overview]
Message-ID: <1454684758.31169.77.camel@linux.intel.com> (raw)
In-Reply-To: <56B4B67D.2080707@free.fr>
On Fri, 2016-02-05 at 15:49 +0100, Mason wrote:
> Hello,
>
> AFAICT, the clk-fractional-divider driver implements the following
> hardware API:
>
> ? M and N are two fields in the same register.
> ? DIV = M / N
>
> Is this HW API common/typical in the embedded world?
> in the PC world?
>
At least all new Intel SoCs have it, besides that there is one more
user of the struct clk_fractional_divider, but I have no idea if they
have something similar to this.
>
> My hardware uses a slightly weird (to me) API:
>
> ? I = 0-255 (8 bits)
> ? F = 0-15??(4 bits)
This part is okay.
>
> ? I = 0 => DIV = +INF
On Intel we recognize this as an absence of the divider.
> ? I = 1 => DIV = 1 + F/(32-F)
Weird part, indeed. But seems it doubles a precision in a range
[1 .. 1 + 1/2]
> ? I > 1 => DIV = I + F/16
This just normal operation.
>
> Is this HW API common/typical in the embedded world?
> (Perhaps just the linear part for I > 1)
I saw similar approach in few UART drivers, but they do not use CLK
framework.
So, I could consider this one is more popular / wider, than what we
have in Intel SoCs.
>
> I see two downsides to this API:
>
> 1) I = 1 is a special case
> 2) A lot of the value space is wasted on large values.
>
> For example, when I = 250, we don't really care about 250.0625,
> 250.125,
> etc, or even nearby integer values, for that matter.
>
> I think it's better to have a distribution with high density in small
> values, and low density in high values (sort of like floating point).
>
> For example:
>
> ? I = 0-15??(4 bits)
> ? F = 0-255 (8 bits)
> ? DIV = 2^I * (1 + F/256)
>
> (We could probably even shave 2-4 bits on F.)
>
> Are there downsides to this HW API?
> Is this HW API common/typical in the embedded world?
So, what is your intention? If you would like to use CLK framework you
might consider existing providers and users and might implement a
specific one for similar cases.
Also it's possible to convert clock providers for, e.g., UARTs to use
this kind of divider.
--
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy
next prev parent reply other threads:[~2016-02-05 15:05 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-05 14:49 Common/typical fractional divider HW API Mason
2016-02-05 14:49 ` Mason
2016-02-05 15:05 ` Andy Shevchenko [this message]
2016-02-05 15:05 ` Andy Shevchenko
2016-02-05 16:01 ` Mason
2016-02-05 16:01 ` Mason
2016-02-05 16:12 ` Andy Shevchenko
2016-02-05 16:12 ` Andy Shevchenko
2016-02-05 16:29 ` Mason
2016-02-05 16:29 ` Mason
2016-02-05 16:43 ` Andy Shevchenko
2016-02-05 16:43 ` Andy Shevchenko
2016-02-07 16:04 ` Mason
2016-02-07 16:04 ` Mason
2016-02-15 15:35 ` Andy Shevchenko
2016-02-15 15:35 ` Andy Shevchenko
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=1454684758.31169.77.camel@linux.intel.com \
--to=andriy.shevchenko@linux.intel.com \
--cc=heikki.krogerus@linux.intel.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-clk@vger.kernel.org \
--cc=mturquette@baylibre.com \
--cc=rjw@rjwysocki.net \
--cc=sboyd@codeaurora.org \
--cc=sf84@laposte.net \
--cc=slash.tmp@free.fr \
/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.