From: mark gross <markgross@thegnar.org>
To: Raffaele Recalcati <lamiaposta71@gmail.com>
Cc: linux-pm@lists.linux-foundation.org,
davinci-linux-open-source@linux.davincidsp.com,
linux-kernel@vger.kernel.org
Subject: Re: [linux-pm] pm loss development
Date: Sat, 14 May 2011 09:24:24 -0700 [thread overview]
Message-ID: <20110514162423.GA8292@gvim.org> (raw)
In-Reply-To: <1305220265-9020-1-git-send-email-lamiaposta71@gmail.com>
On Thu, May 12, 2011 at 07:11:01PM +0200, Raffaele Recalcati wrote:
> What happen normally in runtime pm implementation is that every devices
> are switched off and are enabled only when needed.
> In our case instead we have a completely functional embedded system and,
> when an asyncrhonous event appear, we have only some tens milliseconds
> before the actual power failure takes place.
Very interesting! I've been worried about a similar failure on battery
driven devices that can experience significant voltage droops when
battery gets old, or low, and we turn on the flashlight led, vibrator
and make the screen bright while a high volume ring tone gets played.
I think 10ms is a bit unrealistic. I think its more like 300uSec before
you hit brown out.
> This patchset add a support in order to switch off not vital part of the system,
> in order to allow the board to survive longer.
> This allow the possibility to save important data.
>
> The implementation has been written by Davide Ciminaghi.
> My work instead was about analyzing different previuos implementation,
> a first completely custom one, a second using runtime pm, arriving
> finally to that one.
>
> I have tested PM loss in our DaVinci dm365 basi board and I write here below a
> piece of code showing a possible usage.
>
> -------------------
>
> static int powerfail_status;
>
> static irqreturn_t basi_powerfail_stop(int irq, void *dev_id);
>
> static irqreturn_t basi_powerfail_quick_check_start(int irq, void *dev_id)
> {
> basi_mask_irq_gpio0(IRQ_DM365_GPIO0_2);
> basi_unmask_irq_gpio0(IRQ_DM365_GPIO0_0);
>
> /* PowerFail situation - START: power is going away */
> return IRQ_WAKE_THREAD;
> }
>
> static irqreturn_t basi_powerfail_start(int irq, void *dev_id)
> {
> if (powerfail_status)
> return IRQ_HANDLED;
> powerfail_status = 1;
> pm_loss_power_changed(SYS_PWR_FAILING);
> return IRQ_HANDLED;
> }
>
>
> static irqreturn_t basi_powerfail_quick_check_stop(int irq, void *dev_id)
> {
> basi_mask_irq_gpio0(IRQ_DM365_GPIO0_0);
> basi_unmask_irq_gpio0(IRQ_DM365_GPIO0_2);
>
> /* PowerFail situation - STOP: power is coming back */
> return IRQ_WAKE_THREAD;
> }
>
> static irqreturn_t basi_powerfail_stop(int irq, void *dev_id)
> {
> if (!powerfail_status)
> return IRQ_HANDLED;
> powerfail_status = 0;
> pm_loss_power_changed(SYS_PWR_GOOD);
> return IRQ_HANDLED;
> }
>
> enum basi_pwrfail_prio {
> BASI_PWR_FAIL_PRIO_0,
> BASI_PWR_FAIL_MIN_PRIO = BASI_PWR_FAIL_PRIO_0,
> BASI_PWR_FAIL_PRIO_1,
> BASI_PWR_FAIL_PRIO_2,
> BASI_PWR_FAIL_PRIO_3,
> BASI_PWR_FAIL_MAX_PRIO = BASI_PWR_FAIL_PRIO_3,
> };
>
> struct pm_loss_default_policy_item basi_pm_loss_policy_items[] = {
> {
> .bus_name = "mmc",
> .bus_priority = BASI_PWR_FAIL_PRIO_1,
> },
> {
> .bus_name = "platform",
> .bus_priority = BASI_PWR_FAIL_PRIO_2,
> },
> };
>
> #define BASI_POLICY_NAME "basi-default"
>
> struct pm_loss_default_policy_table basi_pm_loss_policy_table = {
> .name = BASI_POLICY_NAME,
> .items = basi_pm_loss_policy_items,
> .nitems = ARRAY_SIZE(basi_pm_loss_policy_items),
> };
>
> static void basi_powerfail_configure(void)
> {
> int stat;
> struct pm_loss_policy *p;
> stat = request_threaded_irq(IRQ_DM365_GPIO0_2,
Is this some comparator device that tugs on this gpio when the voltage
drops or goes to 0? Is threaded irq fast enough?
Could we consider something that includes a hot path ISR based
notification call back to do stuff like blink off devices that don't
need to save state; backlights, vibrators, flashlight LEDs, audio
output drivers <-- I'm not sure about audio HW, and then a slower path
for other things that can be put into lower power states?
the all-clear notification that power is good again should be on a
slower path I would assume.
--mark
> basi_powerfail_quick_check_start,
> basi_powerfail_start,
> 0,
> "pwrfail-on", NULL);
> if (stat < 0)
> printk(KERN_ERR "request_threaded_irq for IRQ%d (pwrfail-on) "
> "failed\n", IRQ_DM365_GPIO0_2);
> stat = request_threaded_irq(IRQ_DM365_GPIO0_0,
> basi_powerfail_quick_check_stop,
> basi_powerfail_stop, 0,
> "pwrfail-off", NULL);
> if (stat < 0)
> printk(KERN_ERR "request_threaded_irq for IRQ%d (pwrfail-off) "
> "failed\n", IRQ_DM365_GPIO0_0);
> basi_mask_irq_gpio0(IRQ_DM365_GPIO0_0);
> p = pm_loss_setup_default_policy(&basi_pm_loss_policy_table);
>
> if (!p)
> printk(KERN_ERR "Could not register pwr change policy\n");
>
> if (pm_loss_set_policy(BASI_POLICY_NAME) < 0)
> printk(KERN_ERR "Could not set %s power loss policy\n",
> BASI_POLICY_NAME);
> }
>
> int platform_pm_loss_power_changed(struct device *dev,
> enum sys_power_state s)
> {
> int ret = 0;
>
> /* Calling platform bus pm_loss functions */
> pr_debug_pm_loss("platform_pm_loss_power_changed(%d)\n", s);
>
> if (dev->driver && dev->driver->pm &&
> dev->driver->pm->power_changed)
> ret = dev->driver->pm->power_changed(dev, s);
> return ret;
> }
>
>
>
>
> _______________________________________________
> linux-pm mailing list
> linux-pm@lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/linux-pm
next prev parent reply other threads:[~2011-05-14 16:24 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-12 17:11 pm loss development Raffaele Recalcati
2011-05-12 17:11 ` [PATCH 1/4] export bus_kset Raffaele Recalcati
2011-05-12 19:28 ` Rafael J. Wysocki
2011-05-13 17:11 ` Davide Ciminaghi
2011-05-15 14:13 ` [linux-pm] " Davide Ciminaghi
2011-05-17 23:04 ` Rafael J. Wysocki
2011-05-12 17:11 ` [PATCH 2/4] PM / Loss: power loss management Raffaele Recalcati
2011-05-12 19:57 ` Rafael J. Wysocki
2011-05-13 13:02 ` Davide Ciminaghi
2011-05-17 23:32 ` Rafael J. Wysocki
2011-05-19 9:26 ` Davide Ciminaghi
2011-05-19 14:25 ` [linux-pm] " Alan Stern
2011-05-19 20:52 ` Rafael J. Wysocki
2011-05-12 17:11 ` [PATCH 3/4] mmc: bus and block device drivers: support for pm_loss Raffaele Recalcati
2011-05-12 17:11 ` [PATCH 4/4] DaVinci: vpfe: " Raffaele Recalcati
2011-05-12 19:27 ` pm loss development Rafael J. Wysocki
2011-05-13 6:39 ` Raffaele Recalcati
2011-05-13 16:54 ` Rafael J. Wysocki
2011-05-14 16:35 ` [linux-pm] " mark gross
2011-05-17 23:07 ` Rafael J. Wysocki
2011-05-18 3:12 ` mark gross
2011-05-18 19:43 ` Rafael J. Wysocki
2011-05-18 22:17 ` Mark Brown
2011-05-19 12:45 ` mark gross
2011-06-02 22:21 ` Pavel Machek
2011-06-14 14:06 ` mark gross
2011-06-14 14:36 ` Alan Cox
2011-05-14 20:21 ` Raffaele Recalcati
2011-05-17 23:10 ` Rafael J. Wysocki
2011-05-14 18:53 ` [linux-pm] " Oliver Neukum
2011-05-14 20:34 ` Raffaele Recalcati
2011-05-17 23:06 ` Rafael J. Wysocki
2011-05-14 16:24 ` mark gross [this message]
2011-05-14 20:30 ` Raffaele Recalcati
2011-05-14 23:33 ` mark gross
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=20110514162423.GA8292@gvim.org \
--to=markgross@thegnar.org \
--cc=davinci-linux-open-source@linux.davincidsp.com \
--cc=lamiaposta71@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@lists.linux-foundation.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;
as well as URLs for NNTP newsgroup(s).