On Fri, 26 Jul 2013 15:06:45 +0530 Viresh Kumar viresh.kumar@xxxxxxxxxx wrote, > On 26 July 2013 14:03, Lukasz Majewski <l.majewski@xxxxxxxxxxx> wrote: > > The problem here is with the cpufreq_driver->set_boost() call. > > > > I tried to avoid acquiring lock at one function and release it at > > another (in this case cpufreq_boost_set_sw), especially since the > > __cpufreq_governor() acquires its own lock - good place for > > deadlock. > > > > Is it OK for you to grab lock at one function > > (cpufreq_boost_trigger_state()) and then at other function > > (cpufreq_boost_set_sw) release it before calling > > __cpufreq_governor() and grab it again after its completion? > > Problem is not only that.. but we shouldn't call boost_set() of > drivers like acpi-cpufreq with this lock..... Leave it as it is for > now.. Let me see if I can think of any problems that can happen due > to this. Do you have any second thoughts about this? Shall I leave it as it is now? -- Best regards, Lukasz Majewski Samsung R&D Institute Poland (SRPOL) | Linux Platform Group -- To unsubscribe from this list: send the line "unsubscribe cpufreq" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
