cpufreq_interactivex.c:239:9: error: implicit declaration of function ‘strict_strtoul’ [-Werror,-Wimplicit-function-declaration]

Lately I’ve been going through the Xperia XA2 Ultra kernel (sdm660) and trying to add new features. Today I was adding in some governors, specific to this post, is the interactiveX governor.

That’s when I ran into this error:

/home/alaskalinuxuser/aokp_pie/kernel/sony/sdm660/drivers/cpufreq/cpufreq_interactivex.c:239:9: error: implicit declaration of function ‘strict_strtoul’ [-Werror,-Wimplicit-function-declaration]
return strict_strtoul(buf, 0, &min_sample_time);

It took me a while to find an answer for it, but once I did, I saw it over and over again as I added more govs to the kernel:

/home/alaskalinuxuser/aokp_pie/kernel/sony/sdm660/drivers/cpufreq/cpufreq_brazilianwax.c:406:15: error: implicit declaration of function ‘strict_strtoul’ [-Werror,-Wimplicit-function-declaration]
res = strict_strtoul(buf, 0, &input);

/home/alaskalinuxuser/aokp_pie/kernel/sony/sdm660/drivers/cpufreq/cpufreq_skywalker.c:723:5: error: implicit declaration of function ‘strict_strtoul’ [-Werror,-Wimplicit-function-declaration]
if(strict_strtoul(buf, 0, &inc_cpu_load)==-EINVAL) return -EINVAL;


/home/alaskalinuxuser/aokp_pie/kernel/sony/sdm660/drivers/cpufreq/cpufreq_smartass2.c: error: implicit declaration of function ‘strict_strtoul’ [-Werror,-Wimplicit-function-declaration]
if(strict_strtoul(buf, 0, &inc_cpu_load)==-EINVAL) return -EINVAL;



With about half of the governors that I added, this error popped up, mainly because I was taking the govs from an older 3.10 kernel and trying to apply them to a 4.4 kernel. That’s a pretty big jump, and several parts of the code gave me interesting errors to hunt down, but this one was so simple to fix, just hard to find. I can’t take the credit, though, since I found this thread where a guy had a similar issue and fixed it.

According to Vasiliy Tolstov:

strict_strtoul() was just a redefinition of kstrtoul() for a long
time. From kernel version of 3.18, strict_strtoul() will not be
defined at all. A compile time kernel version check is needed to
decide which function or macro can be used for a specific version of

Fortunately, the fix was pretty simple. Using gedit, I replaced every instance of “strict_strtoul” with “kstrtoul” in each of these governors. After that, the error not only went away, but the govs actually worked!

Linux – keep it simple.

Darkness overcomes the Blu Life One X2


Sounds sinister! But really I just added the darkness governor to the BLOX2 (Blu Life One X2). It is part of my video series on 64 bit kernel modification, which you can check out on YouTube, or on GitLab.

You can also take a look at the commit if you’d like!

Linux – keep it simple.

The easy guide to understanding CPU and GPU governors

There are a lot of guides out there about CPU and GPU governors. They are all very informative, and usually somewhat technical. The other day, however, I needed to explain CPU and GPU governors to a non-technical person, and I realized that a lot of big verbiage and vague terms get thrown around which help the technical, but cloud the issue for some. So, I decided to share my non-technical explanation here, in hopes that it will help others also. This is not a perfect analogy, nor a technical one, but I think it gets the job done.
Consider driving your car in the rain.
The more it rains, the less you can see. Hence the slower you should drive. Each swipe of the windshield wiper clears the window. The rain is like the CPU/GPU load, or how much work the CPU/GPU needs to do to clear the windshield.

Sometimes it is raining very hard. Sometimes it is a sprinkle. But in this make believe world, it is always raining.

As the driver of the car, you get to pick the speed at which the wipers swipe. It is entirely up to you, you are the governor, or the one in charge of the windshield wipers. You can’t control how much it rains, but you can control how fast your wipers swipe the windshield clear.

There are many types of drivers out there, just like there are many governors. However, they all fall into several basic categories.

The Performance type governors are like a driver who gets into the car, and he turns on the wipers full speed. Even if it is barely raining. No matter how much rain does, or does not fall on the windshield, he keeps the wipers going full blast. This works very well to keep the windshield clear. However it also makes the wiper blades get pretty hot when it is just a sprinkle. All the friction from swiping back and forth will eventually wear out his wiper blades, and he will replace them a lot sooner if he does this, but his windshield will stay clear!

The Powersave type of governors are like a driver who gets into her car and turns the wipers on at the lowest possible speed, with the longest delay between swipes. This works great if it is just sprinkling, but anytime she gets into a down pour, she has to practically come to a stop, because she can’t see where she is going through all that rain on her windshield.

The On Demand type governors, are the drivers who are always adjusting by wild amounts. “Oh, it’s raining harder, I will turn the wipers all the way up!” He says. “Oh, I guess that was too much. I’ll turn them down now.” Back and forth this driver goes, always pushing up to maximum wiper speed, only to find that he should probably turn the wiper speed down. Often, this guy is over-adjusting for the actual amount of rain, but his windshield stays pretty clear. Essentially, he has become his own delay module, waiting for rain on the windshield, he then turns on the wipers to clear it, then practically turns the wipers off. Then repeat, over and over again.

The Conservative type governors, however, take a more methodical approach. When she sees that it is raining harder, she turns her wiper speed up one notch. Then she waits a few seconds to see how well that works. Not enough wiper speed to keep the window clear? Then she will turn up the wiper speed another notch. Still not enough? Then she turns the wiper speed up another notch. One notch at a time, with a moment to check the results before making another correction. Then, if the wipers are too fast, she turns them down one notch. The process continues, constantly adjusting, one notch at a time. This can work very well. It can also be problematic if there is a huge change in the amount of rain. If it was sprinkling, and then starts to pour, it may be a while before she gets her wiper blades to “catch up” with the amount of rain.

Of course, there are Ideal frequency governors. This man has already determined that if it is raining, he will use a particular delay or speed setting for his wipers. He may adjust them slightly if it is raining more or less, but he will always strive to keep his wipers at the setting that he already determined was the one that he thought was best. Usually this setting is somewhere in the middle. Not really performance, not quite powersave, just somewhere in the middle that he thinks is best. This can work good for average use, but can be taxing your battery while “coasting” and can be less able to handle heavy rains (high work loads).

Then there are the dependent type of governors. This person gets into her car and begins to drive through the rain. Rather than setting her wipers based on her view out the window, this lady sets her wiper speed based on some other variable. For instance, the Intellidemand governor sets the CPU frequency based on GPU speed. This would be like a woman who sets her wiper speed based on her car’s speedometer. If she is driving faster, then she turns up the wiper speed. If she is driving slower, then she turns down her wiper speed. It makes sense, but works only as good as the thing controlling it. It seems like a good idea, if you drive faster, you need a clearer windshield, so you should wipe the rain away faster. The only issue here is that it may not be raining very hard, yet, because you are driving faster, you must set your wipers to swipe faster. Generally this works very well, but may not work in every condition. Some of these governors have other variables, such as “touch poke” where the CPU frequency, or wiper speed, goes up when you touch the screen. Much like turning up the wiper speed when the hi-beam headlights get turned on.

Essentially, all governors are like one or more, or some combination of, the above. Most simply fine tune the variables or combine some functions of the above to get the results they want. Some are designed for power saving, others for performance.
So, which one is the best?

Well, that depends. Is it raining really hard all the time? Does it barely rain at all? Is there just a good gully-wash once a day, and other than that it is just a sprinkle?

Lots of people argue over which one is the best, but it is really hard to quantify. The reality of it is not which governor is the “best” but which governor is the “best for you”. Only you know what your daily “rainfall” is like. Perhaps you are okay with driving a little slower in the rain. You might even enjoy it. Maybe you have ADD and need that windshield spotless all the time. I don’t know.

A few thoughts for you to consider though:

Do you need your phone to be battery friendly?
I get up at 4:30 AM every morning for work. I put my phone back on the charger every night around 8-9 PM. My battery only has to last 16-17 hours. Typically, based on my choices and daily use, I average about 50% battery life left when I put it on the charger. Based on my usage, I could choose a more performance driven governor, and not have to worry too much about battery usage. If you are always out and about, in the wild, hiking, camping, fishing, you may want to consider a more battery friendly option to extend your use for longer trips between chargers. My point being that it does you little good to choose so many battery friendly options that your phone lasts 6 days on a charge, but you plug it in every night.

Do you need your phone to out perform anybody?
I don’t play video games. I rarely watch youtube/hulu/netflix/vudu/(name your video streaming service here) on my phone. Do I need a performance based governor? Sure, the benchmarks are impressive, but does it really mater that you are clocking max speeds to check you email?

You don’t have to choose just one setting.
Many people get “stuck in a rut” (back to our car analogy) when it comes to settings like governors. With apps such as Kernel Adiutor, Device Control, and others, you can set profiles, or make backup configurations that you can quickly implement when you want to. If you hardly use your phone when you are at work, but become a gaming fiend at home. Maybe it is the opposite, at work you use your phone for serious number crunching with some math apps, and at home it just becomes your telephone. Choose a different option that suits your needs in each instance.

What do I use?
Well, again, it really depends on what you do day to day. For me, I play chess on my phone, read a Bible app, I check my emails (work and home), I browse the internet, Github, WordPress and XDA, take a few pictures of the kids, make a few phone calls, and send a few texts. That’s it. So for me, I use the Lionheart governor for my CPU. The vote is still out on GPU, but I have been testing the Simple GPU governor, and I think that it works pretty well.

Linux – keep it simple.

How to check your governor and I/O scheduler from the command line

The other day, when working through some issues with kernel governors and I/O schedulers, I realized that I was a bit rusty on where to find them from the command line. After some searching and tinkering, I thought I might save some internet searcher the long and winding road to find this out.

From the command line:

$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
conservative ondemand userspace powersave performance

$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

$ cat /sys/block/sda/queue/scheduler
noop [deadline] cfq

It’s a pretty simple trick to just read what is written in the /sys directory. As you can see here, my laptop system is running the ondemand kernel governor with the deadline I/O scheduler. If you are using this for yourself, you can check any of the cpu’s and drives by inputing them instead of the cpu0 and sda which I used here. This works on just about anything running a Linux kernel, from computers to cell phones like Android.

Linux – keep it simple.

Adding Governors to your kernel

While building AOKP MM for my Samsung Galaxy S4, T-Mobile phone (SGH-M919 JFLTETMO), I made a rookie mistake. In my mind, AOKP users are the type to want the maximum performance out of their devices at all times. So, when I put AOKP 6 together, I figured that a good default parameter to set the governor to was Performance. This really makes AOKP MM pretty snappy. Not only does it make it snappy, but the CPU frequency is always near max while the screen is on, causing a tremendous waste of battery power. So, as an alternative, I set the CPU governor to Interactive, which was better, but still not very battery friendly.

In a constant quest to make things better, and to understand more about how things work, I decided to do something that I have never done before. I decided to add more governors to the kernel. Sure, I have compiled kernels before, it was part of my LPIC exams. To be honest, I was compiling kernels before I was compiling Android. Governors, however, was never something that I changed on a kernel before. For a desktop computer it is actually quite irrelevant in my opinion, because you are plugged in, you might as well use the best performance governor and disregard any sort of power saving settings. Of course, that doesn’t work very well for cell phones, and my inexperience showed in my last build.

So, on to the task at hand. The CPU frequency is set by the governor. A driver is needed to control the governor, so go to the proper folder:

$ cd ./kernel/samsung/jf/drivers/cpufreq

In this folder, you will do several things. The first is paste your new “.c” files for your new governor. You can find these files by breaking down or looking in source code for your kernel which is specific to your device (in the phone sense). In this case, I added BioShock and Yankactive governors to my system with these two files:


Then I modified the kconfig file from that same folder by adding these lines:

bool “BioShock”
Use the CPUFreq governor ‘BioShock’ as default.

bool “yankactive”
Use the CPUFreq governor ‘yankactive’ as default.

and these lines:

tristate “‘bioshock’ cpufreq bioshock”
depends on CPU_FREQ
‘bioshock’ – Mixing Lionheart and ConservitiveX

tristate “‘yankactive’ cpufreq policy governor”
depends on CPU_FREQ
‘yankactive’ – dynamic cpufreq policy governor

And edited the Makefile in that folder to say:

# CPUfreq governors
obj-$(CONFIG_CPU_FREQ_GOV_PERFORMANCE) += cpufreq_performance.o
obj-$(CONFIG_CPU_FREQ_GOV_POWERSAVE) += cpufreq_powersave.o
obj-$(CONFIG_CPU_FREQ_GOV_USERSPACE) += cpufreq_userspace.o
obj-$(CONFIG_CPU_FREQ_GOV_ONDEMAND) += cpufreq_ondemand.o
obj-$(CONFIG_CPU_FREQ_GOV_CONSERVATIVE) += cpufreq_conservative.o
obj-$(CONFIG_CPU_FREQ_GOV_INTERACTIVE) += cpufreq_interactive.o
obj-$(CONFIG_CPU_FREQ_GOV_YANKACTIVE) += cpufreq_yankactive.o
obj-$(CONFIG_CPU_FREQ_GOV_BIOSHOCK) += cpufreq_bioshock.o

And finaly, I added these lines to the ./kernel/samsung/jf/include/linux/cpufreq.h file:

extern struct cpufreq_governor cpufreq_gov_bioshock;
#define CPUFREQ_DEFAULT_GOVERNOR (&cpufreq_gov_bioshock)
extern struct cpufreq_governor cpufreq_gov_yankactive;
#define CPUFREQ_DEFAULT_GOVERNOR (&cpufreq_gov_yankactive)

The only thing left is to check your “.c” files to make sure that all dependencies are met! Lest you think that I am really, really smart, I will clue you in. While I have compiled kernels before, this was new to me. God graciously gave me a brain and fingers, which I used to look it up online. There are some really great guides about overclocking, under-volting, etc., and if you are interested, it will not take long to find them.

Bioshock is supposed to be a good “balance” between battery savings and performance, while yankactive is supposed to be even more battery conscious. Hopefully between these two kernel governors we can find one that will help with the battery consumption. For my next build, I set BioShock to be the new default kernel governor, as opposed to my old choice of Performance. Only time will tell if it actually makes a difference.

Linux – Keep it simple.