All of lore.kernel.org
 help / color / mirror / Atom feed
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: Mon, 15 Feb 2016 17:35:52 +0200	[thread overview]
Message-ID: <1455550552.31169.135.camel@linux.intel.com> (raw)
In-Reply-To: <56B76B26.4050306@free.fr>

On Sun, 2016-02-07 at 17:04 +0100, Mason wrote:
> 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.

drivers/tty/serial/*

> 
> > 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.

Just to be simple:
Why do you have to modify existing clk-fractional-divider.c module?

May I suggest to reconsider your design to be fit in the existing CLK
divider implementations? Also, some of the hardware IPs have inside
divider registers, like mentioned above UARTs. I already suggested to
look at them to see how hardware is done.

Again, (actually I bored to repeat) I didn't see (yet!) any HW divider
which has integer part as 2^I. I don't get why you stuck with that
formula and why 1/256? Who prevents to have 1/32768 in HW (like we have
in LPSS of Intel SoCs)?

Here I'm giving up this discussion. Perhaps more experienced people
could correct me.

-- 
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: Mon, 15 Feb 2016 17:35:52 +0200	[thread overview]
Message-ID: <1455550552.31169.135.camel@linux.intel.com> (raw)
In-Reply-To: <56B76B26.4050306@free.fr>

On Sun, 2016-02-07 at 17:04 +0100, Mason wrote:
> 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.

drivers/tty/serial/*

> 
> > 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.

Just to be simple:
Why do you have to modify existing clk-fractional-divider.c module?

May I suggest to reconsider your design to be fit in the existing CLK
divider implementations? Also, some of the hardware IPs have inside
divider registers, like mentioned above UARTs. I already suggested to
look at them to see how hardware is done.

Again, (actually I bored to repeat) I didn't see (yet!) any HW divider
which has integer part as 2^I. I don't get why you stuck with that
formula and why 1/256? Who prevents to have 1/32768 in HW (like we have
in LPSS of Intel SoCs)?

Here I'm giving up this discussion. Perhaps more experienced people
could correct me.

-- 
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy

  reply	other threads:[~2016-02-15 15:35 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
2016-02-07 16:04             ` Mason
2016-02-15 15:35             ` Andy Shevchenko [this message]
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=1455550552.31169.135.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.