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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
