Hi Viresh, > On 24 May 2013 16:50, Lukasz Majewski <l.majewski@xxxxxxxxxxx> wrote: > >> On 24 May 2013 14:00, Lukasz Majewski <l.majewski@xxxxxxxxxxx> > >> wrote: > > > This is not safe IMHO to add permanently overclocked frequency to > > the freq table. Since, for example, thermal framework also asks for > > reference to this table. > > Yes, its wrong. Even adding it permanently this way would be a problem > if governor is changed to performance. :) > > > The idea beneath overclocking is to add "dangerous" frequency to the > > frequency table only when necessary (and remove it when not needed). > > Hmm.. probably the idea beneath is to use dangerous frequency only > when we are assured that we will not break system.. Exactly, this is the idea. > It doesn't have > anything to do with cpufreq table entries :) > > > In this way, the thermal framework (as it is done at our platform) > > will decrease the frequency (according to thermal governor :-) ) to > > safe level. > > > > Overclocking is disabled in 2 ways (at our setup): > > - thermal framework is here to help us > > - lab governor disables the overclocking when favorable conditions > > are gone. > > I don't want to discuss OR think about LAB for now.. Want to get > overclocking feature in first. > > > One more remark - enabling tb_en_over_clk at sysfs (echo 1 > >> /sys/devices/system/cpu/cpu0/cpufreq/tb_en_over_clk) > > adds overclock frequency to frequency table and updates policy. > > What if it is enabled and governor is changed to performance > without disabling it... Who will take care of disabling dangerous > frequencies? So we could disable overclocking by default when policy is changed, or when we remove governor (at cpufreq_unregister_governor()). > > One thing I am certain about is to make overclocking a generic and > core feature, rather than platform specific... Ok, I see your point. I will prepare appropriate patches to rewrite overclocking as a generic framework. > > What about adding overdrive frequencies in freq table permanently > but with .index field as: CPUFREQ_ENTRY_OVERDRIVE ?? > > This way we will use frequencies marked with > CPUFREQ_ENTRY_OVERDRIVE only when we have overclocking > enabled. And not at other times? It seems to be a good idea. In this way we could solve some other problems as well (like specifying not single overclocked frequency, make sysfs entries read only). As I've stated above, I will prepare only overclocking patches, with new generic approach. -- Best regards, Lukasz Majewski Samsung R&D 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
