On Thu, 7 Apr 2011 01:19:59 -0700, Sonny Rao wrote: > On Thu, Apr 7, 2011 at 12:55 AM, Jean Delvare <khali@xxxxxxxxxxxx> wrote: > > Sonny, I would expect you to obtain the time saving by only switching > > the i2c client device to async suspend/resume. wasn't it the case? i2c > > bus device suspend/resume shouldn't matter, as the operation should be > > handled by the hardware (e.g. PCI) layer. > > I tried that first, and it looked like the client resume wouldn't start on the > async thread until the kernel resumed the i2c master which was This is expected... You need an operational i2c master to talk to the i2c client, regardless of async or not. > happening very late for some reason. Maybe this was just a fluke of > the device ordering, but enabling it for both master and client allowed > the device resume to consistently happen much earlier. OK, that makes sense. I don't know how the synchronous resume decides in which order it processes the devices, presumably it simply walks the device tree. If you are unlucky and the i2c master is near the end, then indeed the asynchronous resume of the i2c client device alone may save nothing at all. I get it now. -- Jean Delvare -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
