Skip to content


omap_timer omap_timer.8: omap2_dm_timer_set_src: clk_set_parent() to sys_ck FAILED #3

erazor83 opened this Issue · 25 comments

5 participants



I compiled the module against a git tree of (;a=shortlog;h=refs/heads/omap-3.2 ) and tried to use it on my gumstix overo board.

When i try to load the module this error occurs in my dmesg:
omap_timer omap_timer.8: omap2_dm_timer_set_src: clk_set_parent() to sys_ck FAILED

CONFIG_OMAP_RESET_CLOCKS is not set in my kernel-config.

Does the module work with the 3er series of the kernel? Do you have any hints for me whats exactly the problem is?

Thanks so far.

Kind regards,


I've been banging my head at the same problem for weeks, any news?


If I understand you correctly, this only fixes the driver not working at all, but it does NOT fix the problem with the clock source?

The "enable" thing is something I tried, but i figured the syntax would be something like calling omap_dm_timer_enable(..) when we're going to use it, and omap_dm_timer_disable(..) when we're done with it, so basically in the open and close of the driver.

Your patch suggests something entirely different, is it so that one has to surround every access to the timer functions with enable..disable calls? I really don't understand why your fix would work, it only puts that around one function that isn't even critical.

Is there any place where I could find some information on the dmtimer interface? How did you find it? Or is the only way to discover this just looking at the source?

From where i'm standing now, the easiest to do would be to just eliminate the timers I want to use from the kernel, and just bitbang the registers myself. At least that's properly documented...


I don't know if this is a different side of the same coin, a new problem or my problem. Once I insmod pwm.ko and I rmmod it, I get:

insmod: error inserting 'pwm.ko': -1 Operation not permitted

An additional factor is persistence, which may be my problem. The system does not recognize 'pwm.ko' on reboot. upon reboot, I get this:

desktop:/root# insmod pwm.ko timers=9,10,11
insmod: can't read 'pwm.ko': No such file or directory

I can readily compile it, only if I remove the artifacts from the last make:

desktop:/root/Documents/pwm# make
make -C /lib/modules/3.2.0-29-omap/build M=/root/Documents/pwm modules
make[1]: Entering directory /usr/src/linux-headers-3.2.0-29-omap'
CC [M] /root/Documents/pwm/pwm.o
Building modules, stage 2.
MODPOST 1 modules
CC /root/Documents/pwm/pwm.mod.o
LD [M] /root/Documents/pwm/pwm.ko
make[1]: Leaving directory
desktop:/root/Documents/pwm# insmod pwm.ko timers=9,10,11
desktop:/root/Documents/pwm# cat /dev/pwm9
desktop:/root/Documents/pwm# echo 50 > /dev/pwm9

When I remove the module and try to re-install it, I get this:

desktop:/root/Documents/pwm# rmmod pwm
desktop:/root/Documents/pwm# insmod pwm.ko timers=9,10,11
insmod: error inserting 'pwm.ko': -1 Operation not permitted

I am native compiling and the make file is:

obj-m := pwm.o

KDIR := /lib/modules/$(shell uname -r)/build
PWD := $(shell pwd)

$(MAKE) -C $(KDIR) M=$(PWD) modules
$(MAKE) -C $(KDIR) M=$(PWD) clean

uname -r tells me that I am using 3.2.0-29-omap

The only pwm.ko produced today is in the same directory that I make it. If I read the makefile correctly, it is supposed to put it in /lib/modules/3.2.0-29-omap/build and it does not. It also is supposed to clean up after compiling. I believe that is the persistence problem and I will work on that separately, but if you see an obvious error, I'd appreciate it.

The system is Ubuntu 12.04 with Unity disabled and XFCE4 installed. Unity requires a minimum 1GHz proc and 1GB of memory and neither is particularly compatible with a BeagleBoardXM. The XFCE4 only requires 300 MHz and 200MB. For actual operations, I will run it headless from the shell (it boots to shell and I run the desktop).


By the way, I don't initialize PWM8 because it kills the USB.


Sounds like you are seeing exactly the symptoms described in those earlier posts.

You cannot reload the pwm module if you used a timer when it was loaded. I suspect you are not trying your insmod commands from a console otherwise you would also see the reason the insmod failed instead of only the generic failure message.

insmod: error inserting 'pwm.ko': -1 Operation not permitted

Check your syslog for the real failure reason. I'm pretty sure it will be an error about not being able to reparent the timer src clock. Either that or try loading from a console session.

Your insmod error on boot comes from the fact that insmod requires a full-path to the driver.

desktop:/root# insmod pwm.ko timers=9,10,11
insmod: can't read 'pwm.ko': No such file or directory

Provide the full-path to pwm.ko. The first insmod of the driver should always work.

The warning to BeagleBoard users about timer 8 messing with USB has been in the README for a long time.
It's down in the notes near the bottom.


Thanks for your prompt answer. I was afraid it was the same problem. They appear to not have fixed the 3.2 kernel.

I tried installing a newer kernel but none of them want to boot. The latter distros mess with the boot.scr and uEnv.txt doesn't work for me. I don't feel like messing with the uEnv.txt/boot.scr right now. So, I'm installing a Ubuntu 11.10 distro that has the 3.0 kernel. I looked at Linaro and they stopped updating the BeagleBoard distro because they couldn't get it to boot. I will figure out how to fix it later. I haven't worked on UNIX since I was using microbus and a 6800. So, the functions are little foggy.

Thanks for the heads up on the full path. I had read some place else that I should do a make modules-install. I had tried that with another LKM, but it said that make didn't have that command. I'll work on that.


Thanks Scott.
I tried a couple of distros and found various no compatible header files. I settled on Linaro 1203
which has kernel 3.1.1-21. When I installed pwm, it worked fine. When I tried to re-insert it, it froze the
machine. It accepted the insmod, though. I've moved forward a little.

I can send you the whole syslog for this, if you wish. There seems to be a series hub 1-2:1.0: port 2 events associated with the initial insmod and hub 1.0:1-0: port 2 with the ones resulting in a freeze. I'm going to attempt a recompile by removing all references to pwm8.



I commented out the references to timer 8 and pwm8 and changed the 4 timers to 3. It inserted and removed the pwm module fine. I rmmod pwm and it shut down OK. I insmod ed it again and it still had the random tripping. I decided to reboot and forgot to rmmod. After reboot, it came back with the message
Timer 9 specified more than once
insmod: error inserting '/workspace/pwm/pwm.ko' : -1 operation not permitted

I tried rmmod and it told me that pwm was not inserted. A clean install got the same results. My guess is that the bug extended to 3.1.1-21. I will be looking to a 3.0 that I can use. There were some changes from 2.6 that creates problems for me if I go back that far.


I'm using your latest code and I still get:
omap_timer omap_timer.10: omap2_dm_timer_set_src: clk_set_parent() to sys_ck FAILED
Error: could not insert module pwm.ko: Operation not permitted

My kernel version is as follows: 3.2.28

Any suggestions what could be going wrong?


I removed the following lines of code and now it works. So for some reason the omap_dm_timer_set_source does not work. Although the PWM seems to work fine with out that call.
// if (omap_dm_timer_set_source(pwm_dev[i].timer,
// goto timer_init_fail;


I'm not sure what to suggest.

I'm using the pwm driver on several projects with a 3.2 kernel on a Gumstix Overo without any problems. The kernel comes from the gumstix/meta-gumstix repo on Github.

Without that omap_dm_timer_set_source() call, the timer is likely using a 32K source timer and not the 13MHz sys timer. That might not be a problem for you. It just means a coarser resolution and less range for the frequency.

It's still an outstanding problem that you cannot reload the driver on a running system if you activated any of the pwm timers. Then you will get the error that you are seeing.

That's usually only a problem (for me mostly) during development. I have looked at the problem, but the solution isn't obvious. My dev systems reboot under 10 seconds so it's not been inconvenient enough to force me to fix.

My production systems only load the driver once at boot so it's never a problem there.


Thanks for the quick response.

I've traced it down to the following code inside of clk_set_parent():
if (clk->usecount == 0) {
ret = arch_clock->clk_set_parent(clk, parent);
if (ret == 0)
} else{
ret = -EBUSY;

Where clk->usercount is NOT equal to zero so clk_set_parent() returns -EBUSY. I will keep digging into usercount, any insight on it that you might have would also be helpful.


So I'm clear, you get an error the first time you load the driver?


Yes, the first time I load the driver.


I just fixed my problem and the problem of removing/adding back in the module. Not sure if this is clean or not (pretty sure it probably is not as I just hacked it) so hopefully you can give me insight on a better approach.

The problem is to set the timer (clk) source there must not be anyone using the clk (as per my post above). Your PWM code actually registers the timer (clk) somewhere early on (not sure where) so it is actually using it in my kernel therefore when the code goes to set the src it punts out because usecount is equal to 1. I fixed this part of the problem by just issuing a clock disable/enable around the code were the src is being set as clk_disable() decrements usecount and disables the clk if no one is using it and clk_enable() increments usecount and enables the clk.

fclk = omap_dm_timer_get_fclk(pwm_dev[i].timer); //Moved up from below!!
if (omap_dm_timer_set_source(pwm_dev[i].timer,
goto timer_init_fail;

Next, the module removing reinserting problem seems to be the same issue. The clk is never being disabled (usecount decremented) when the module is removed so the next time it can't set the source and the disable/enable I have in place does not work since the usecount is now 2 instead of 1 and since clk_disable only decrements by 1 usecount is not 0. I just added a clk_disable to the pwm_timer_cleanup() function:

static void pwm_timer_cleanup(void)
int i;
struct clk *fclk;

    for (i = 0; i < num_timers; i++) {

fclk = omap_dm_timer_get_fclk(pwm_dev[i].timer);

            if (pwm_dev[i].timer) {
                    pwm_dev[i].timer = NULL;
                    if (irq_mode)
                            free_irq(pwm_dev[i].irq, &pwm_dev[i]);





CONFIG_OMAP_RESET_CLOCKS is set to no on mine. I will try to set it to yes as it does make sense that it could be the difference between our systems.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.