On 19 November 2013 20:29, Nishanth Menon <nm@xxxxxx> wrote: > Not completely true - reaching probe after boot in a few seconds may > not mean that system will remain stable at that frequency for longer > duration. From a silicon vendor perspective, I do know that we > gaurentee the discrete frequencies in the data manual (and that gets > populated in devicetree and hence in freq_table), but we will not > guarentee any other frequency to be functional for any length of time. > in short, if a actual product is manufactured and operational at a > frequency we do not "officially support", there is a risk associated > with that. just a boot on a few development systems do not ever > guarentee productization capability. Maybe for a long duration system isn't stable enough but should be stable for few seconds Atleast? As soon as ->init() of driver is called we will get a call to: cpufreq_set_policy() from cpufreq_init_policy(). And we will execute this for sure: ret = __cpufreq_governor(policy, CPUFREQ_GOV_LIMITS); On this call if the current freq is lesser or greater than policy limits, then we will fix it straight away.. Otherwise whichever the governor is, we will change the freq to any from freq-table very soon.. So, we need a real example of unstable system which really requires your patch. Otherwise I feel that we will not face any problems at all.. > So, to summarize: what is our overall strategy here? to move to a > frequency matched in freq_table OR just giveup? I can try and respin > accordingly. I want cpufreq-stats to be fixed with something else, might be something similar to the patch I have sent.. But this stuff can be left as is.. -- 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
