On 18 June 2013 13:54, Lukasz Majewski <l.majewski@xxxxxxxxxxx> wrote: > On Tue, 18 Jun 2013 08:42:13 +0200, Viresh Kumar wrote: >> Its not about how long.. One cpu type can work longer with boost freq >> compared to other. >> >> What we probably need is: >> - Enabled boost from sysfs if required (now below steps will come into >> picture) >> - See how many cpus are running, if only one then start using boost >> freqs > > You are right here. > > I'd like to propose following solution: > 1. For acpi (where boost_enable come into play) - do not consider > number of active cpus (this is done in HW anyway) > > 2. For SW solution evaluate how many CPUs are running. If only one is > running then allow enabling boost from sysfs. Looks fine. > But following situation is also possible: User enable boost when one > core is only running and then for some reason other core is woken up. > What shall be done then? > Shall we then disable boost immediately when cpufreq detects that > more than one core is running? Or leave this situation to be handled by > thermal subsystem? Obviously disable boost ASAP. Every SoC might not have a thermal framework glue to do it. > As a side note: > Logic proposed at point 2, is already implemented at LAB > (enable LAB only when one core is running and disable it when more > than one come into play). Hmm.. So, eventually that will go away now :) >> - Now thermal should be come into picture to save chip in case a >> single cpu running at boost can burn it out. > > I will extent v4 to embrace code which switches off boost at thermal. Gud. -- 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
