From: Adam Belay <ambx1@neo.rr.com>
To: Vitaly Wool <vwool@ru.mvista.com>, David Brownell <david-b@pacbell.net>
Cc: linux-kernel@vger.kernel.org,
spi-devel-general@lists.sourceforge.net, basicmark@yahoo.com,
stephen@streetfiresound.com, dpervushin@gmail.com,
Pavel Machek <pavel@ucw.cz>
Subject: Re: [PATCH/RFC 1/2] simple SPI framework
Date: Wed, 5 Oct 2005 05:30:11 -0400 [thread overview]
Message-ID: <20051005093011.GC14734@neo.rr.com> (raw)
In-Reply-To: <4343898D.1060904@ru.mvista.com>
On Wed, Oct 05, 2005 at 12:06:37PM +0400, Vitaly Wool wrote:
> David,
>
> >+#ifdef CONFIG_PM
> >+
> >+/* Suspend/resume in "struct device_driver" don't really need that
> >+ * strange third parameter, so we just make it a constant and expect
> >+ * SPI drivers to ignore it just like most platform drivers do.
> >+ *
> >
> >
> So you just ignored my letter on that subject :(
> The fact that you don't need it doesn't mean that other people won't.
> The fact that there's no clean way to suspend USB doesn't mean that
> there shouldn't be one for SPI.
>
> >+ * NOTE: the suspend() method for an spi_master controller driver
> >+ * should verify that all its child devices are marked as suspended;
> >+ * suspend requests delivered through sysfs power/state files don't
> >+ * enforce such constraints.
But we should, right? It seems like a child device should never be in a
higher suspend state than its parents. The rule doesn't have to hold with
driver-initiated runtime power management, but when the user requests a
suspend via power/state, it's reasonable to assume every child should
be suspended first.
> >+ */
> >+static int spi_suspend(struct device *dev, pm_message_t message)
> >+{
> >+ int value;
> >+
> >+ if (!dev->driver || !dev->driver->suspend)
> >+ return 0;
> >+
> >+ /* suspend will stop irqs and dma; no more i/o */
> >+ value = dev->driver->suspend(dev, message, SUSPEND_POWER_DOWN);
> >
> >
> So driver->suspend is going to be called 3 timer with SUSPEND_POWER_DOWN
> parameter, right?
> I'm afraid that won't work :(
> Especially in our case, where we *do need* preparation steps that are
> taken in *normal* suspend sequence - i. e. we need to set up the wakeup
> credentials for the *SPI* since the wakeup's gonna happen from a call
> incoming through the network module residing on the SPI bus!
So...
1.) suspend all child devices
2.) calculate their wake requirements
3.) suspend the parent to a degree compatible with those requirements
Right?
Thanks,
Adam
next prev parent reply other threads:[~2005-10-05 9:25 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-10-04 18:02 [PATCH/RFC 1/2] simple SPI framework David Brownell
2005-10-05 8:06 ` Vitaly Wool
2005-10-05 9:01 ` Russell King
2005-10-05 9:13 ` Vitaly Wool
2005-10-05 14:39 ` David Brownell
2005-10-06 18:23 ` Mark Underwood
2005-10-06 18:29 ` Russell King
2005-10-06 19:02 ` [PATCH] Get rid of the obsolete tri-level suspend/resume callbacks (was: Re: [PATCH/RFC 1/2] simple SPI framework) Russell King
2005-10-06 19:09 ` Greg KH
2005-10-06 21:14 ` Pavel Machek
2005-10-06 21:19 ` Russell King
2005-10-05 9:30 ` Adam Belay [this message]
2005-10-05 14:45 ` [PATCH/RFC 1/2] simple SPI framework David Brownell
2005-10-05 11:10 ` Pavel Machek
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=20051005093011.GC14734@neo.rr.com \
--to=ambx1@neo.rr.com \
--cc=basicmark@yahoo.com \
--cc=david-b@pacbell.net \
--cc=dpervushin@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=pavel@ucw.cz \
--cc=spi-devel-general@lists.sourceforge.net \
--cc=stephen@streetfiresound.com \
--cc=vwool@ru.mvista.com \
/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.