Messages in this thread | | | Subject | Re: [PATCH] soc/tegra: pmc: Fix "scheduling while atomic" | From | Jon Hunter <> | Date | Fri, 27 May 2016 13:46:37 +0100 |
| |
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
| |