From: Mason <slash.tmp@free.fr>
To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
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: Sun, 7 Feb 2016 17:04:54 +0100 [thread overview]
Message-ID: <56B76B26.4050306@free.fr> (raw)
In-Reply-To: <1454690599.31169.103.camel@linux.intel.com>
On 05/02/2016 17:43, Andy Shevchenko wrote:
> There are plenty of implementations of the divider.
I'd be happy to read an overview on the subject, if you have
some links to share.
> You might consider to use one than inventing new one
I find it hard to believe that the interface I'm discussing
has not been used (several times) in the past. (It's merely
a trivial floating point scheme.)
As a matter of fact, the integer divider driver supports
"I" and "2^I", so extending 2^I to "2^I * (1 + F/256)"
is an obvious step.
>> In this part of my message, I was trying to argue that one HW API
>> "2^I * (1 + F/256)" seemed better than another one "I + F/16" on
>> any hardware.
>
> I disagree in a part 2^I.
I don't know what that means. If you speak Russian, maybe you
can write in Russian, and I'll try to figure it out.
>> Maybe the clk-fractional-divider could be made more generic by having
>> the register update part done in a call-back function?
>
> Why do you need to touch that module at all if your hardware doesn't
> suit it?
What does it mean "your hardware doesn't suit it" ?
I am saying that if the register update were moved into a call-back
function, then any scheme could be supported. Maybe you think this
is just vague hand-waving. I'll send a patch to illustrate what
I'm saying.
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: Sun, 7 Feb 2016 17:04:54 +0100 [thread overview]
Message-ID: <56B76B26.4050306@free.fr> (raw)
In-Reply-To: <1454690599.31169.103.camel@linux.intel.com>
On 05/02/2016 17:43, Andy Shevchenko wrote:
> There are plenty of implementations of the divider.
I'd be happy to read an overview on the subject, if you have
some links to share.
> You might consider to use one than inventing new one
I find it hard to believe that the interface I'm discussing
has not been used (several times) in the past. (It's merely
a trivial floating point scheme.)
As a matter of fact, the integer divider driver supports
"I" and "2^I", so extending 2^I to "2^I * (1 + F/256)"
is an obvious step.
>> In this part of my message, I was trying to argue that one HW API
>> "2^I * (1 + F/256)" seemed better than another one "I + F/16" on
>> any hardware.
>
> I disagree in a part 2^I.
I don't know what that means. If you speak Russian, maybe you
can write in Russian, and I'll try to figure it out.
>> Maybe the clk-fractional-divider could be made more generic by having
>> the register update part done in a call-back function?
>
> Why do you need to touch that module at all if your hardware doesn't
> suit it?
What does it mean "your hardware doesn't suit it" ?
I am saying that if the register update were moved into a call-back
function, then any scheme could be supported. Maybe you think this
is just vague hand-waving. I'll send a patch to illustrate what
I'm saying.
Regards.
next prev parent reply other threads:[~2016-02-07 16:04 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
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 [this message]
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=56B76B26.4050306@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.