> I thought I'd fix this issue for both pm-idle and the up-coming cpu-idle > by moving the smartreflex disable/enable calls to omap_sram_idle. But I > could not do it, because this way the device hangs on both suspend and > dynamic idle. I wonder why this is? > > The CDP code seems to disable smartreflex in the early stages of the > function calling omap_sram_idle. In the suspend path the disable call is > made just before local_fiq_disable. In pm-idle path the call seems to be > before checking if some interrupt has occurred. So I gathered this might > have something to do with interrupts. > > The thing that puzzles me is that with linux-omap, the suspend path does > not have any local_fiq_disable calls. Nevertheless, if the smartreflex > disable call is in omap_sram_idle, the suspend hangs. But, if it is in > start of the preceding omap3_pm_suspend call, as it is now, suspending > works fine. So this makes me think there could be some delay from when > smartreflex is disabled to when the actual I2C commands stop to the > voltage controller. Have you enabled SR really to do something? With out proper efuse values its job is to do OPP changes. Once you have proper efuses it can do safe auto-adjustment. Most early non-production devices won't have useable efuse values. I agree hardware I2C messages when it is in use might be a point of worry when investigating issues. > Do you know why the smartreflex disable calls are positioned as they are > in the CDP code? I don't recall there being a placement. I can ask others if there aware. Regards, Richard W. -- 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
