From: Liam Girdwood <lg@opensource.wolfsonmicro.com>
To: Harald Welte <laforge@gnumonks.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
arm kernel <linux-arm-kernel@lists.arm.linux.org.uk>
Subject: Re: [PATCH 0/13] Updated V4 - Regulator Framework
Date: Fri, 09 May 2008 20:44:04 +0100 [thread overview]
Message-ID: <1210362244.20475.125.camel@odin> (raw)
In-Reply-To: <20080509043708.GG4961@prithivi.gnumonks.org>
On Fri, 2008-05-09 at 06:37 +0200, Harald Welte wrote:
> On Thu, May 08, 2008 at 09:51:27PM +0100, Liam Girdwood wrote:
> > > Do you think it would be worth to export something like this in the
> > > generic API, too? It's probably quite hard, since there are devices
> > > that actually use the PCF506xx STANDBY state during suspend-to-ram, but
> > > other devices leave the PCF506xx in the ON state and just disable the
> > > individual regulators using I2C register writes.
> >
> > Yes I think it would be worthwhile adding this sort of functionality. I
> > had considered this earlier on in development but it was lower priority
> > for me then.
>
> ok. I also believe it is much lower priority. No disagreement here :)
>
> > This would mean some additions to the regulator machine interface (to be
> > used during machine regulator setup) and regulator driver interface (to
> > set the values). I could add some 'standby_uV' and 'standby_mode' fields
> > (one for each standby state) to struct regulation_constraints. This
> > would define the desired voltage and regulator operating mode to be used
> > during the regulators STANDBY/HIBERNATE states. Hence the correct
> > regulator output state would be selected when the PMIC enters it's
> > STANDBY/HIBERNATE state (via either a I2C write or hardware signal).
> >
> > Would this suffice for your PMIC (sorry I don't have the datasheet) ?
>
> basically the pcf506xx cannot support a different voltage in standby
> mode than in active mode. They just simply have something like a
> bitmaks where you define which regulator is still running in standby,
> and which don't.
>
Ok, I've created a new struct regulator_state in machine.h to describe
a regulators suspended state for a given system suspend state :-
struct regulator_state {
int uV; /* suspend voltage */
unsigned int mode; /* suspend regulator operating mode */
int enabled; /* is regulator enabled in this suspend state */
};
'uV' and 'mode' are optional 'enabled' is mandatory. This should also
cover other PMICs where voltage and operating mode may be configurable.
I've also added the following fields to struct regulation_constraints in
machine.h :-
/* regulator suspend states for global PMIC STANDBY/HIBERNATE */
struct regulator_state state_disk;
struct regulator_state state_mem;
struct regulator_state state_standby;
suspend_state_t initial_state; /* suspend state to set at init */
This should define all the regulator's supported system suspend states
and be registered with the other constraints.
In order to switch PMIC suspend configurations, I've added :-
int regulator_suspend_prepare(suspend_state_t state);
This will configure each PMIC regulator (if required) with the correct
suspend setup prior to entering the new suspend state (and could be
called by machine suspend code to prepare the pc506xx).
Liam
next prev parent reply other threads:[~2008-05-09 19:44 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-02 15:40 [PATCH 0/13] Updated V4 - Regulator Framework Liam Girdwood
2008-05-02 23:52 ` Andrew Morton
2008-05-03 10:31 ` Liam Girdwood
2008-05-08 6:35 ` Harald Welte
2008-05-08 20:16 ` Mark Brown
2008-05-08 20:51 ` Liam Girdwood
2008-05-09 4:37 ` Harald Welte
2008-05-09 19:44 ` Liam Girdwood [this message]
2008-05-11 14:39 ` Liam Girdwood
2008-07-10 9:08 ` Andrew Morton
2008-07-29 20:33 ` Liam Girdwood
2008-07-29 20:40 ` Andrew Morton
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=1210362244.20475.125.camel@odin \
--to=lg@opensource.wolfsonmicro.com \
--cc=akpm@linux-foundation.org \
--cc=laforge@gnumonks.org \
--cc=linux-arm-kernel@lists.arm.linux.org.uk \
--cc=linux-kernel@vger.kernel.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