Re: [Gumstix-users] Using timers on kernel 3.2

[jumpnowdev <sc...@ju...>]

The pwm driver is working for me. I've tested all 4 timers on a 3.2 kernel.

In the pwm_init() function in my code, the src clock is changed to the 13
MHz clock unconditionally. 
I never use the 32 kHz clock in the pwm driver. 

If the clock change fails the driver wouldn't load.

... snip from pwm_init() ...

    for (i = 0; i < num_timers; i++) {
        pwm_dev[i].timer = omap_dm_timer_request_specific(pwm_dev[i].id);

        if (!pwm_dev[i].timer)
            goto timer_init_fail;

        omap_dm_timer_set_pwm(pwm_dev[i].timer,
            0,	// ~SCPWM low when off
            1,	// PT pulse toggle modulation
            OMAP_TIMER_TRIGGER_OVERFLOW_AND_COMPARE);

        if (omap_dm_timer_set_source(pwm_dev[i].timer,
OMAP_TIMER_SRC_SYS_CLK))
            goto timer_init_fail;

        // make sure we know the source clock frequency
        fclk = omap_dm_timer_get_fclk(pwm_dev[i].timer);
        pwm_dev[i].input_freq = clk_get_rate(fclk);

        pwm_set_frequency(&pwm_dev[i]);
    }
...

I still can't unload the driver and reload it again and use the same timers
though. 
It fails with the error you point out. 

It isn't my call to omap_dm_timer_set_source() in pwm_init()  that fails
either.

Inside the omap_dm_timer_request_specific() code is another call to
omap_dm_timer_set_source().

That is the omap_dm_timer_set_source() call that is failing.

As I said in the github issue, I traced it down through several function to
arch/arm/plat-omap/clock.c - clk_set_parent()

There are several ways this function can fail, but the actual error code
does not survive the higher calling functions. 

One of them throws away the error code and you get back basically a boolean,
failed or succeeded.

I've yet to put in some printk's to troubleshoot further.

I have one other observation. I can load and unload the driver repeatedly as
long as I don't call omap_dm_timer_start().
Once that has been called I cannot unload the driver and reload it and use
that particular timer again. I suspect it is some
cleanup problem, but it is not obvious to me what is missing.

Likely most kernel timer users/developers would never see this because they
load their kernel driver only once.

Unfortunately and because I'm lazy, that's what I've been doing as well and
the reason I haven't pursued fixing this.


--
View this message in context: http://gumstix.8.n6.nabble.com/Using-timers-on-kernel-3-2-tp4964299p4964681.html
Sent from the Gumstix mailing list archive at Nabble.com.