[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120413091828.GJ3168@opensource.wolfsonmicro.com>
Date: Fri, 13 Apr 2012 10:18:29 +0100
From: Mark Brown <broonie@...nsource.wolfsonmicro.com>
To: Ulf Hansson <ulf.hansson@...ricsson.com>
Cc: Russell King <linux@....linux.org.uk>,
Grant Likely <grant.likely@...retlab.ca>,
Linus Walleij <linus.walleij@...aro.org>,
Samuel Ortiz <sameo@...ux.intel.com>,
"spi-devel-general@...ts.sourceforge.net"
<spi-devel-general@...ts.sourceforge.net>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH/RFC v2] ARM: amba: Remove AMBA level regulator support
On Fri, Apr 13, 2012 at 11:03:56AM +0200, Ulf Hansson wrote:
> But, how should those amba drivers that implements runtime PM
> support be able to switch of the vcore regulator during normal
> suspend? In normal suspend case we can not use
A generic AMBA driver should have no idea about the implementation of
the particular SoC that it's integrated on to. This applies even more
to system suspend (where drivers can generally just assume that they
will loose all power normally) than it does to runtime suspend.
> pm_runtime_put/pm_runtime_put_sync to trigger the power domain
> runtime functions to switch of vcore. This is kind of more generic
> problem when dealing with power domains, but as said this patch will
> have consequences.
The power domain gets callbacks on the system suspend path too and can
do whatever is sensible there.
> As far as I can see, the power domain must then implement a
> suspend_noirq function to make sure same things is done as for the
> runtime_suspend function. Do you agree with this as well or is there
> another option?
Yes, the power domain should just be handling this transparently.
Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)
Powered by blists - more mailing lists