All of lore.kernel.org
 help / color / mirror / Atom feed
From: Maxime Ripard <maxime.ripard@free-electrons.com>
To: Stephen Boyd <sboyd@codeaurora.org>
Cc: Mike Turquette <mturquette@baylibre.com>,
	Emilio Lopez <emilio@elopez.com.ar>,
	linux-arm-kernel@lists.infradead.org,
	Chen-Yu Tsai <wens@csie.org>, Hans de Goede <hdegoede@redhat.com>,
	linux-clk@vger.kernel.org, linux-sunxi@googlegroups.com
Subject: Re: [PATCH v3 1/5] clk: Add a basic multiplier clock
Date: Wed, 7 Oct 2015 12:04:57 +0100	[thread overview]
Message-ID: <20151007110457.GF2278@lukather> (raw)
In-Reply-To: <20151005180929.GB12338@codeaurora.org>

[-- Attachment #1: Type: text/plain, Size: 1883 bytes --]

On Mon, Oct 05, 2015 at 11:09:29AM -0700, Stephen Boyd wrote:
> On 10/05, Maxime Ripard wrote:
> > Hi,
> > 
> > On Fri, Oct 02, 2015 at 01:43:08PM -0700, Stephen Boyd wrote:
> > > On 09/29, Maxime Ripard wrote:
> > > > +
> > > > +	if (!val && mult->flags & CLK_MULTIPLIER_ZERO_BYPASS)
> > > > +		val = 1;
> > > > +	
> > > > +	return parent_rate * val;
> > > > +}
> > > > +
> > > > +static bool __is_best_rate(unsigned long rate, unsigned long new,
> > > > +			   unsigned long best, unsigned long flags)
> > > > +{
> > > > +	if (flags & CLK_MULTIPLIER_ROUND_CLOSEST)
> > > 
> > > Is the only difference in this function vs the divider one that
> > > flag? Maybe we should make this function generic to the framework
> > > and pass a flag indicating closest or not.
> > 
> > Actually, the logic is also reversed.
> > 
> > The divider driver will always try to find some rate that is higher
> > than the one we already have, without going above than the one
> > requested.
> > 
> > Here, we're tring to be lower than the best rate, without going below
> > the requested rate.
> 
> So then a tri-state flag that indicates, closest, less than,
> greater than?

Still, the computation itself is different, and the only consolidation
we could possibly do is by not duplicating the ROUND_CLOSEST. We would
end up with two different code pathes in the same function, which I
feel would make it unnecessarily complex.

> 
> > 
> > > 
> > > > +	unsigned long val;
> > > > +
> > > > +	if (mult->lock)
> > > > +		spin_lock_irqsave(mult->lock, flags);
> > > 
> > > This needs the same "trick" that we did in the generic clock
> > > types to avoid sparse warnings.
> > 
> > The __acquire call ?
> 
> Yes.

Ok.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: maxime.ripard@free-electrons.com (Maxime Ripard)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 1/5] clk: Add a basic multiplier clock
Date: Wed, 7 Oct 2015 12:04:57 +0100	[thread overview]
Message-ID: <20151007110457.GF2278@lukather> (raw)
In-Reply-To: <20151005180929.GB12338@codeaurora.org>

On Mon, Oct 05, 2015 at 11:09:29AM -0700, Stephen Boyd wrote:
> On 10/05, Maxime Ripard wrote:
> > Hi,
> > 
> > On Fri, Oct 02, 2015 at 01:43:08PM -0700, Stephen Boyd wrote:
> > > On 09/29, Maxime Ripard wrote:
> > > > +
> > > > +	if (!val && mult->flags & CLK_MULTIPLIER_ZERO_BYPASS)
> > > > +		val = 1;
> > > > +	
> > > > +	return parent_rate * val;
> > > > +}
> > > > +
> > > > +static bool __is_best_rate(unsigned long rate, unsigned long new,
> > > > +			   unsigned long best, unsigned long flags)
> > > > +{
> > > > +	if (flags & CLK_MULTIPLIER_ROUND_CLOSEST)
> > > 
> > > Is the only difference in this function vs the divider one that
> > > flag? Maybe we should make this function generic to the framework
> > > and pass a flag indicating closest or not.
> > 
> > Actually, the logic is also reversed.
> > 
> > The divider driver will always try to find some rate that is higher
> > than the one we already have, without going above than the one
> > requested.
> > 
> > Here, we're tring to be lower than the best rate, without going below
> > the requested rate.
> 
> So then a tri-state flag that indicates, closest, less than,
> greater than?

Still, the computation itself is different, and the only consolidation
we could possibly do is by not duplicating the ROUND_CLOSEST. We would
end up with two different code pathes in the same function, which I
feel would make it unnecessarily complex.

> 
> > 
> > > 
> > > > +	unsigned long val;
> > > > +
> > > > +	if (mult->lock)
> > > > +		spin_lock_irqsave(mult->lock, flags);
> > > 
> > > This needs the same "trick" that we did in the generic clock
> > > types to avoid sparse warnings.
> > 
> > The __acquire call ?
> 
> Yes.

Ok.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20151007/46995fa7/attachment.sig>

  reply	other threads:[~2015-10-07 11:04 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-29  7:39 [PATCH v3 0/5] clk: sunxi: Add support for the Audio PLL Maxime Ripard
2015-09-29  7:39 ` Maxime Ripard
2015-09-29  7:39 ` [PATCH v3 1/5] clk: Add a basic multiplier clock Maxime Ripard
2015-09-29  7:39   ` Maxime Ripard
2015-10-02 20:43   ` Stephen Boyd
2015-10-02 20:43     ` Stephen Boyd
2015-10-05 10:19     ` Maxime Ripard
2015-10-05 10:19       ` Maxime Ripard
2015-10-05 18:09       ` Stephen Boyd
2015-10-05 18:09         ` Stephen Boyd
2015-10-07 11:04         ` Maxime Ripard [this message]
2015-10-07 11:04           ` Maxime Ripard
2015-10-07 19:17           ` Stephen Boyd
2015-10-07 19:17             ` Stephen Boyd
2015-09-29  7:39 ` [PATCH v3 2/5] clk: sunxi: Add a driver for the PLL2 Maxime Ripard
2015-09-29  7:39   ` Maxime Ripard
2015-09-29  7:39 ` [PATCH v3 3/5] clk: sunxi: pll2: Add A13 support Maxime Ripard
2015-09-29  7:39   ` Maxime Ripard
2015-09-29  7:39 ` [PATCH v3 4/5] clk: sunxi: codec clock support Maxime Ripard
2015-09-29  7:39   ` Maxime Ripard
2015-10-02 20:44   ` Stephen Boyd
2015-10-02 20:44     ` Stephen Boyd
2015-10-05  9:05     ` Maxime Ripard
2015-10-05  9:05       ` Maxime Ripard
2015-09-29  7:39 ` [PATCH v3 5/5] clk: sunxi: mod1 " Maxime Ripard
2015-09-29  7:39   ` Maxime Ripard
2015-10-02 20:45   ` Stephen Boyd
2015-10-02 20:45     ` Stephen Boyd
2015-10-05  9:44     ` Maxime Ripard
2015-10-05  9:44       ` Maxime Ripard

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=20151007110457.GF2278@lukather \
    --to=maxime.ripard@free-electrons.com \
    --cc=emilio@elopez.com.ar \
    --cc=hdegoede@redhat.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-sunxi@googlegroups.com \
    --cc=mturquette@baylibre.com \
    --cc=sboyd@codeaurora.org \
    --cc=wens@csie.org \
    /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.