Hi Felipe, On 10/30/2012 02:09 AM, Felipe Balbi wrote: ... >> its bit of an issue to take care. How do you ensure that GPIO >> does idle on SOC idle C-state attempts in such cases. Today that >> job is done by omap_gpio_[prepare/resume]_for_idle. > > that's only there because we pm_runtime_get_sync() on gpio_request() and > pm_runtime_put_sync() only on gpio_free(). > > That's the problem IMHO. And that's easy enough to 'fix': > > call pm_runtime_mark_last_busy(); pm_runtime_put_sync_autosuspend(); > also on gpio_request() and pm_runtime_get_sync() on gpio_free(). Sounds like a good approach. I have been discussing with Kevin and I need to look more at the resume handler as we are working around some old issues in there and with this approach the resume following idle will be delayed and we were not sure if there could be any implications for omap2. I am hoping not, but we need to look into this. So I am wondering if we should just take Tim's original proposal for now and then I will look into improving this long term. I really need to clean-up the suspend/resume stuff for gpio and so may be we can make that a separate change. What do you think? ... > The difficult part, IMHO, is to figure out what's a good autosuspend > timeout to use. Some GPIO lines are used as IRQ lines on some devices, > that means that the GPIO will be periodically triggered and, depending > on our timeout, we will either loose IRQs or prevent power domain from > idling. We could figure out a way to let board code to choose what it > wants on a per-bank basis (maybe some extra DT attribute). I have also been bending Kevin's ear on this, this week and we were wondering if we should make the default 0 for now as this will have the same behaviour that we have today but would allow Tim to customise via the sysfs for his specific app. Cheers Jon -- 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
