Alan Stern <[email protected]> writes: > On Thu, 7 Oct 2010, Kevin Hilman wrote: > >> > Do you need "normal" resume to work after "atomic" suspend, or is it >> > sufficient that "atomic" suspend will require "atomic" resume? >> >> hmm... while I'm definitely needing an "atomic" resume after a "normal" >> suspend, for now I can't think of a case where a "normal" resume would >> be needed after an "atomic" suspend. All the cases where I'm currently >> using an atomic suspend also have a corresponding atomic resume. >> >> As I write this, it wouldn't surprise me down the road to find some HW >> errata that requires the device in a specific state only before idle, >> but not caring about the state after idle. That would be a case where >> an atomic suspend would be needed, but the resume would be "normal" >> sometime later when the device is next needed. > > Put it this way: Are you okay with just the following two > possibilities? > > (1) Both suspends and resumes always have interrupts enabled. > > (2) Both suspends and resumes always have interrupts disabled. > > In other words, is it okay to rule out the ability of mixing "atomic" > and "normal" runtime PM operations?
Yes, I think that's a reasonable limitation. If a driver/subsystem needs to handle an occasional "atomic" runtime PM operation, it's callbacks will have to be atomic as well, so I don't see any reason it can't be made to use only atomic operations. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
