[PATCH 1/2] ARM: OMAP: dmtimer: fix sleeping function called from invalid context
Tony Lindgren
tony at atomide.com
Mon Dec 12 18:08:26 EST 2011
* Ramirez Luna, Omar <omar.ramirez at ti.com> [111209 13:38]:
> On Fri, Dec 9, 2011 at 3:34 PM, Tony Lindgren <tony at atomide.com> wrote:
> >> + ret = omap_dm_timer_set_source(timer, OMAP_TIMER_SRC_32_KHZ);
> ...
> >> EXPORT_SYMBOL_GPL(omap_dm_timer_request);
> >
> > This does not seem right.. It seems that you're hardcoding the source
> > clock to 32 KiHz clock while other sources are available too?
>
> Agree, but... (below)
>
> >> + ret = omap_dm_timer_set_source(timer, OMAP_TIMER_SRC_32_KHZ);
> ...
> > And here too?
>
> Agree but that is the default behavior set by dm timer framework:
>
> @@ -134,22 +134,13 @@ static void omap_dm_timer_reset(struct
> omap_dm_timer *timer)
> int omap_dm_timer_prepare(struct omap_dm_timer *timer)
> {
> ...
> - ret = omap_dm_timer_set_source(timer, OMAP_TIMER_SRC_32_KHZ);
> ...
>
> All clocks requested are set to 32 KHz first, even with the current
> approach, there exists another API to set a new source.
>
> To be honest I don't know why the clocks are set to 32 KHz first,
> maybe the default call path for users should be:
You need a functional clock for the timer registers to work
I believe.
> omap_dm_timer_request
Yes this would make sense. The omap_timer_list should be protected
by a mutex. There should not be a need for spinlock there as
omap_dm_timer_request should be only called during init. If that's
not the case, the the driver using it is broken.
> omap_dm_timer_set_source (new explicit call)
> omap_dm_timer_start
Once the timer has been requested, there should not be a need
for locking as there should be only one timer user using the
timer specific registers.
> And remove setting the source to 32 KHz by default in omap_dm_timer_request.
That you may need to be able to do anything with the timer :)
Regards,
Tony
More information about the linux-arm-kernel
mailing list