Hi Kevin, On Tue, Nov 2, 2010 at 2:38 PM, Kevin Hilman <khilman@xxxxxxxxxxxxxxxxxxx> wrote: > Jean Pihet <jean.pihet@xxxxxxxxxxxxxx> writes: > >> The low power mode on the latest l-o master branch is broken, so I >> investigated a bit. Here are the results. This has been tested on >> OMAP3EVM and Beagleboard. >> >> The problem is that the CORE does not reach the desired mode (RET, >> OFF). It is caused by the I2C1 fclk that is left enabled at suspend >> time. >> Extra printks has been added in the clock enable and disable functions >> for I2C and a stack dump has been added in the suspend path if the >> clock is still enabled, cf. log below. >> >> In the devices suspend sequence the RTC gets suspended, which triggers >> a read of the TWL RTC through the I2C bus, which in turn enables the >> I2C1 fclk. That clock is only disabled on devices resume. >> >> I am guessing this is linked to the recent changes in the I2C for HWMOD support. >> What is the correct fix to have the I2C modules correctly shut off >> before the suspend? > > I2C clocks are supposed to be disabled after each transaction. This > isn't happening. > > My guess is that the 'put' that happens after TX doesn't actually > actually result in a call to omap_device_idle() since system suspend is > active. Static suspend/resume take the runtime PM lock, effectively > disabling runtime PM suspend during static suspend. > > I have a patch/workaround for this problem which is part of my pm-core > branch, but I did not submit for 2.6.37 as I'm not entirely convinced of > it yet. Basically, in the OMAP bus-methods for static suspend/resume I > tinker with the runtime PM usecounting such that the devices can idle. > > Please take a look at the tip patch in my pm-suspend branch, try it out > and see if it fixes your problem. Indeed the patch fixes the problem. The pm_runtime_get/put_sync methods are correctly called for I2C and so the low power mode is hit. > > Thanks, > > Kevin > Thanks, Jean -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
