From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: Kukjin Kim <kgene.kim@samsung.com>,
Grant Likely <grant.likely@secretlab.ca>,
spi-devel-general@lists.sourceforge.net,
linux-samsung-soc@vger.kernel.org,
Magnus Damm <magnus.damm@gmail.com>
Subject: Re: [PATCH 2/2] spi/s3c64xx: Implement runtime PM support
Date: Mon, 5 Dec 2011 23:16:48 +0000 [thread overview]
Message-ID: <20111205231647.GA21083@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <CACRpkdYPdV2_Hr8hO_CAhZ=MvqcBiNdgwySbATcPSfwFRvkARg@mail.gmail.com>
On Mon, Dec 05, 2011 at 10:41:21PM +0100, Linus Walleij wrote:
> Just wanted to mention that I had this discussion with Magnus Damm
> about how they do this in shmobile: in there their central runtime PM
> policy in arch/arm/mach-shmobile/pm_runtime.c adds in the
> pm_clk_notifier from drivers/base/power/clock_ops.c to gate/ungate
> the clocks centrally acting on bus notifiers without any per-driver
> hooks like these.
Yeah, I'm familiar with that - some other platforms were looking into a
similar scheme I think.
> I clearly see that in this platform it's *not* going to work since
> for this one driver atleast, there are two clocks, not just one,
> that need to be managed for the device.
Well, that's not something that's a blocker to central management - the
core can always work with two clocks. What's more of an issue is when
devices need to work with their clocks independantly of the core, but
that's not insurmountable.
I do also think that if we do decide to move more platforms to central
management it's going to be easier to first transition all their drivers
to a repetitive style of clock management and then do a big factor out
once the pattern is clearly visible. It's a big undertaking for things
like the Samsung family of processors where you've got a huge set of
chips to work with going all the way back to s3c24xx so anything we can
do to make it easier is going to be a win.
next prev parent reply other threads:[~2011-12-05 23:16 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-05 16:50 [PATCH 1/2] spi/s3c64xx: Convert to dev_pm_ops Mark Brown
2011-12-05 16:50 ` [PATCH 2/2] spi/s3c64xx: Implement runtime PM support Mark Brown
2011-12-05 21:41 ` Linus Walleij
2011-12-05 23:16 ` Mark Brown [this message]
[not found] ` <20111205231647.GA21083-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
2011-12-06 14:05 ` Linus Walleij
2011-12-13 14:49 ` Heiko Stübner
2011-12-13 15:02 ` Heiko Stübner
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=20111205231647.GA21083@opensource.wolfsonmicro.com \
--to=broonie@opensource.wolfsonmicro.com \
--cc=grant.likely@secretlab.ca \
--cc=kgene.kim@samsung.com \
--cc=linus.walleij@linaro.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=magnus.damm@gmail.com \
--cc=spi-devel-general@lists.sourceforge.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.