[PATCH 12/15] ARM: OMAP: timer: Add suspend-resume callbacks for clockevent device

Jon Hunter jon-hunter at ti.com
Tue Nov 6 11:00:48 EST 2012


On 11/06/2012 01:32 AM, Bedia, Vaibhav wrote:
> Hi Jon,
> 
> On Tue, Nov 06, 2012 at 02:34:05, Hunter, Jon wrote:
> [...]
>>>  static struct clock_event_device clockevent_gpt = {
>>>  	.name		= "gp_timer",
>>>  	.features       = CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT,
>>> @@ -142,6 +171,8 @@ static struct clock_event_device clockevent_gpt = {
>>>  	.rating		= 300,
>>>  	.set_next_event	= omap2_gp_timer_set_next_event,
>>>  	.set_mode	= omap2_gp_timer_set_mode,
>>> +	.suspend	= omap_clkevt_suspend,
>>> +	.resume		= omap_clkevt_resume,
>>
>> So these suspend/resume callbacks are going to be called for all OMAP2+
>> and AMxxxx devices? I don't think we want that. AFAIK OMAP timers will
>> idle on their own when stopped and don't require this.
>>
> 
> IMO instead of skipping the callback registration we could have checks in the
> suspend/resume callbacks to decide what to do. 
> 
> I'll check if the idling part is AM33xx specific. If not, based on the recent timer
> changes that you did, perhaps checking if the clockevent selected doesn't have the
> "ti,timer-alwon" capability will be good enough. What do you think?

Yes, I was thinking along the same lines. If I get chance I will try and
test your scenario on an OMAP3 too.

Cheers
Jon



More information about the linux-arm-kernel mailing list