Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: shawn.guo@linaro.org (Shawn Guo)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM: mx28: Clear CLKGATE bit prior to changing DIV field
Date: Fri, 20 Jan 2012 11:56:04 +0800	[thread overview]
Message-ID: <20120120035600.GA26277@S2101-09.ap.freescale.net> (raw)
In-Reply-To: <20120119145313.GZ1068@n2100.arm.linux.org.uk>

On Thu, Jan 19, 2012 at 02:53:13PM +0000, Russell King - ARM Linux wrote:
> On Thu, Jan 19, 2012 at 11:17:34AM +0800, Shawn Guo wrote:
> > >From power saving point of view, I'm not sure you want to keep saif
> > clock on all the time.  So if the clock is off when you try to call
> > clk_set_rate(), you may want to turn it back to off after clk_set_rate()
> > is done.
> 
> You really shouldn't expose these kinds of SoC specific oddities outside
> of the API - it makes a mockery of having an API in the first place.
> 
> Can you not do:
> 
Yes, we can do this for now, but I'm not sure how it will live when we
migrate to common clock framework.  I actually had a brief talk with
Mike Turquette on that.  He does not think this case is common enough
and deserve being handled in clock framework.  He is trying to avoid
cross calling of clock API.  I kinda agree with him that for some cases
the client drivers may need to know the details of clock hardware at
some level.

Regards,
Shawn

> clk_set_rate(clk, rate)
> {
> 	clk_prepare(clk);
> 
> 	reprogram_clock(clk);
> 
> 	clk_unprepare(clk);
> }
> 
> A clk_prepare() call on an already prepared clock should have no impact
> other than incrementing the counter, which will be balanced on the other
> side by the clk_unprepare().
> 

      reply	other threads:[~2012-01-20  3:56 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-17 17:15 [PATCH] ARM: mx28: Clear CLKGATE bit prior to changing DIV field Fabio Estevam
2012-01-17 17:49 ` Marek Vasut
2012-01-17 18:00   ` Fabio Estevam
2012-01-17 17:58 ` [PATCH v2] " Fabio Estevam
2012-01-17 19:03   ` Marek Vasut
2012-01-18  7:14   ` Shawn Guo
2012-01-18  7:44 ` [PATCH] " Lothar Waßmann
2012-01-19  2:18   ` Fabio Estevam
2012-01-19  3:17     ` Shawn Guo
2012-01-19  3:57       ` Fabio Estevam
2012-01-19  4:20         ` Shawn Guo
2012-01-19  4:44           ` Fabio Estevam
2012-01-19  5:14             ` Dong Aisheng-B29396
2012-01-19 14:04               ` Fabio Estevam
2012-01-19  4:55         ` Dong Aisheng-B29396
2012-01-19 14:53       ` Russell King - ARM Linux
2012-01-20  3:56         ` Shawn Guo [this message]

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=20120120035600.GA26277@S2101-09.ap.freescale.net \
    --to=shawn.guo@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox