Messages in this thread | | | Date | Wed, 5 Oct 2005 05:30:11 -0400 | From | Adam Belay <> | Subject | Re: [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/
| |