On Thu, 27 Jun 2013 15:55:26 +0530, Viresh Kumar wrote: > On 27 June 2013 15:18, Lukasz Majewski <l.majewski@xxxxxxxxxxx> wrote: > > On Thu, 27 Jun 2013 14:32:57 +0530, Viresh Kumar wrote: > > > I thought about this idea, but at cpufreq_boost_trigger_state_sw() > > I iterate through all available policies and call > > cpufreq_frequency_table_cpuinfo()[*] on them. In this routine [*] I > > use cpufreq_boost_enabled() [**] route to search for maximal (boost) > > frequency. > > The [**] reads boost_enabled flag, which shall be updated before. > > When this search fails, then I restore the old value of > > boost_enabled. > > Ok. OK > > >> >> > + else > >> >> > + ret = > >> >> > cpufreq_boost_trigger_state_sw(); > >> > >> then why not enable_boost_sw() here? that would be more > >> relevant. > > > > Could you be more specific here? > > I meant rename cpufreq_boost_trigger_state_sw() to > enable_boost_sw() :) No problem: - For SW there will be cpufreq_boost_trigger_state_sw() renamed to enable_boost_sw() - For HW: cpufreq_driver->enable_boost(state) renamed to cpufreq_driver->enable_boost_hw(); -- 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
