On 26/05/16 18:01, Dmitry Osipenko wrote: > On 26.05.2016 18:27, Jon Hunter wrote: >> On 26/05/16 15:57, Dmitry Osipenko wrote: ... >>> That's how I see it: >>> >>> +----------------------------------------------+ >>> | CPU 0 | >>> +-------------------+--------------------------+ >>> | Idle thread | Interactive gov. thread | >>> +----------------------------------------------+ >>> | inactive | | >>> | | | >>> | | CPU freq. change | >>> | | | >>> | | clk_set_rate() | >>> | | | >>> | ... | clk_prepare_lock() | >>> | | | >>> | | PRE rate notifier call | >>> | | | >>> | | schedule | >> >> What is this notifier doing? Is there some sort of hardware activity >> that it is waiting for to complete? >> > > It changes regulator voltage if required. So at least I2C would cause > scheduling on wait_for_completion_timeout(). Yes, of course that would make sense. What is interesting/odd in this case is that the frequency is increasing (voltage scaled pre frequency change) but yet you are entering LP2. May be that is possible? I guess this problem may also occur on reducing frequency as well? What are you using in the v3.18 kernel for exit_latency and target_residency? The current mainline has 5000us and 10000us, respectively. It does seem that this could be triggered in the right circumstances and I have to say I don't like the fact that this could be fragile as it is today. Have you thought about adding a post clock notifier for pclk in the PMC driver as an alternative to the change you are suggesting? Cheers Jon -- nvpublic -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
