Hi Mark, I am not entirely clear by few things in the commit log. On 18-08-23, 10:06, Mark Tseng wrote: > For MT8186, it has policy0 and policy6 by different governor thread,so > it may be call cpufreq->set_target_index() by different core. Why does this matter ? > In general > case, it must check BCPU, LCPU and CCI together then take about 10ms. BCPU is Big CPU ? LCPU is Little CPU ? So are you saying that changing the frequency takes roughly 10 ms for MT8186 ? > Atfer 44295af5019f this patch, it may call cpufreq_out_of_sync() by > cpufreq_verify_current_freq() because current frequency is bigger > than clk_get_rate() ouver 1Mh. By the same time, it may call s/ouver/over/ s/1Mh/1 MHz/ > cpufreq->set_target_index() again. Where was it called for the first time ? > So, the CCI freq may be too lower for > BCPU cause BCPU kernel panic. I am not sure how a low frequency causes kernel panic here. > So, it should change the default transition delay 1ms to 10ms. It can > promise the next freq setting then governor trigger new freq change. There are few typos as well here, please fix them. > Fixes: 44295af5019f ("cpufreq: use correct unit when verify cur freq") I think you should drop this. The issue at hand may be visible now after 44295af5019f is applied, but it certainly didn't cause it. -- viresh