Re: 900af0d breaks some embedded suspend/resume

["Rafael J. Wysocki" <rjw@sisk.pl>]

On Saturday 18 April 2009, Rafael J. Wysocki wrote:
> On Saturday 18 April 2009, Russell King wrote:
> > On Sat, Apr 18, 2009 at 03:23:35PM +0200, Rafael J. Wysocki wrote:
> > > The patchset in question had been discussed quite extensively before it was
> > > merged and it's a pity none of the people caring for the affected platforms
> > > took part in those discussions.  That would allow us to avoid the breakage.
> > 
> > Maybe on some list, but not everyone is subscribed to a million and one
> > mailing lists.  I don't have enough time to read those which I'm currently
> > subscribed to, so I definitely don't want any more.
> > 
> > > > or provide alternative equivalent functionality where the platform code is
> > > > notified of the PM event prior to the late suspend callback being issued.
> > > 
> > > There is the .begin() callback that could be used, but if you need the
> > > platform to be notified _just_ prior to the late suspend callback, then the
> > > only thing I can think of at the moment is the appended patch.
> > > 
> > > It shouldn't break anything in theory, because the majority of drivers put
> > > their devices into low power states in the "regular" suspend callbacks anyway.
> > 
> > Okay, my requirement is:
> > 
> > What I need to be able to do is to suspend most devices on the host side
> > which may involve talking to a separate microcontroller via I2C to shut
> > down power to peripherals.
> > 
> > Once that's complete, I then need to inform this microcontroller via I2C
> > that we're going to be entering suspend mode, and wait for it to acknowledge
> > that (after it's done its own suspend preparations).  At that point I can
> > shutdown the I2C controller, and enter suspend mode.
> 
> Would it be an option to use a sysdev for that?
> 
> > Upon resume (which is activated by this microcontroller, including jtagging
> > the boot code across to the host CPU), we need to tell this microcontroller
> > that we're going back to 'run' mode again via I2C, and then resume the
> > devices.
> > 
> > This is why we hooked the PXA I2C driver into the late suspend and
> > early resume methods, so the I2C driver would be the last to suspend and
> > the first to resume, thus allowing it to be used to talk to this micro-
> > controller when required.  This worked out nicely because the late suspend
> > used to before the platform prepare and platform finish used to happen
> > after the early resume methods were called.
> 
> Unfortunately I'm not familiar with I2C, so I'm not sure whether or not this
> would work, but it looks like sysdev could be used instead of platform_driver
> for i2c_pxa_driver.
> 
> If using sysdev here (and analogously in i2c-s3c2410.c) is an option, I'd
> prefer to do that instead of reordering suspend and resume code once again.

Well, that wouldn't be straightforward, so I think I'll push my patch for
2.6.30 if Len doesn't object to it.

Thanks,
Rafael