Changes to Linux "Interactive"-Governor

[MOW]

Hi all,

I just noticed that Freescale/NXP seems to be using a completely re-written custom "interactive" CPU-Governor in the Yocto BSPs based on the 3.10.17 kernel (drivers/cpufreq/cpufreq_interactive.c) with a copyfright from 2010 by Google and 2012/2013 by Freescale, instead of a completely different one in Yocto BSPs based on 3.10.53 and 3.14.x kernels, with a copyright only by Google from 2010 (apparanetly without any modifications by Freescale).

Our own Yocto BSPs for our own i.MX5x- and i.MX6x-based systems are still based on the 3.10.17 kernel and we noticed, that even with Freescale/NXP's demo-images on Sabre boards the systems behave differently when scaling the CPU frequency up and down depending on whether we run 3.10.17- oder 3.10.53-based Yocto demo-images.

What was the reason for the custom "interactive" governor in the 3.10.17-based BSPs and why are entirely different unmodified versions of the "interactive" governor used again in all newer BSPs? Would it be possible (or even better) to port the "interactive" governor of the the newer kernels back to 3.10.17?

Kind regards,

Marc

Edit: I modified my questions because at first I thought the "interactive" governor used in the 3.10.53+ BSPs to come from mainline linux, but it seems that the mainline linux-kernel doesn't come with an "interactive" governor. This seems to be coming from Google's Android instead.

[qiang_li-mpu_se]

Yes, the cpufreq_interactive.c is from Google Android kernel, because NXP have Android BSP too, so we need the interactive mode.

[MOW]

Yes, as I noted yesterday, I already figured that out. Doesn't answer my questions, though.

Why do the 3.10.17-based Yocto BSPs contain a completely rewritten "interactive"-governor -- according to the copyright apparantly by Freescale/NXP -- but starting with the 3.10.53-based Yocto-BSP an unmodified "interactive"-governor by Google, only? What was the reason for Freescale/NXP to completely rewrite Google's "interactive" governor for the 3.10.17 kernels but then provide unmodified Google governors with all newer kernels again; apparently discarding all previous Freescale/NXP changes for some reason, again?

Can/Should we replace the Freescale/NXP-governor in the 3.10.17-kernel with the one from Google found in the 3.10.53+ kernels, if we still want/have to stick with the old kernel? How about indirect dependencies on other drivers in this case, e.g. voltage-regulator or thermal monitor drivers?

[qiang_li-mpu_se]

Hi Marc-Oliver, all modification from NXP had been recovered to google's code in 3.10.53 kernel. You can git log the file "drivers/cpufreq/cpufreq_interactive.c" to find all history changes, then you can merge these patches to your 3.10.17 kernel to update the cpufreq_interactive.c.