From: Mason <slash.tmp@free.fr>
To: 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>,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
Sebastian Frias <sf84@laposte.net>,
Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: Common/typical fractional divider HW API
Date: Fri, 5 Feb 2016 15:49:33 +0100 [thread overview]
Message-ID: <56B4B67D.2080707@free.fr> (raw)
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?
My hardware uses a slightly weird (to me) API:
I = 0-255 (8 bits)
F = 0-15 (4 bits)
I = 0 => DIV = +INF
I = 1 => DIV = 1 + F/(32-F)
I > 1 => DIV = I + F/16
Is this HW API common/typical in the embedded world?
(Perhaps just the linear part for I > 1)
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?
Regards.
WARNING: multiple messages have this Message-ID (diff)
From: slash.tmp@free.fr (Mason)
To: linux-arm-kernel@lists.infradead.org
Subject: Common/typical fractional divider HW API
Date: Fri, 5 Feb 2016 15:49:33 +0100 [thread overview]
Message-ID: <56B4B67D.2080707@free.fr> (raw)
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?
My hardware uses a slightly weird (to me) API:
I = 0-255 (8 bits)
F = 0-15 (4 bits)
I = 0 => DIV = +INF
I = 1 => DIV = 1 + F/(32-F)
I > 1 => DIV = I + F/16
Is this HW API common/typical in the embedded world?
(Perhaps just the linear part for I > 1)
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?
Regards.
next reply other threads:[~2016-02-05 14:49 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-05 14:49 Mason [this message]
2016-02-05 14:49 ` Common/typical fractional divider HW API Mason
2016-02-05 15:05 ` Andy Shevchenko
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=56B4B67D.2080707@free.fr \
--to=slash.tmp@free.fr \
--cc=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 \
/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.