lkml.org 
[lkml]   [2005]   [Oct]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH/RFC 1/2] simple SPI framework
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-10-05 11:28    [W:1.790 / U:0.060 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site