lkml.org 
[lkml]   [2015]   [Nov]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] clocksource: arm_global_timer: fix suspend resume
From
Date
On 11/13/2015 08:15 PM, Felipe Balbi wrote:
>
> Hi,
>
> Grygorii Strashko <grygorii.strashko@ti.com> writes:
>> On 11/13/2015 07:40 PM, Felipe Balbi wrote:
>>>
>>> Hi,
>>>
>>> Grygorii Strashko <grygorii.strashko@ti.com> writes:
>>>> On 11/13/2015 06:43 PM, Felipe Balbi wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> Grygorii Strashko <grygorii.strashko@ti.com> writes:
>>>>>> Now the System stall is observed on TI AM437x based board
>>>>>> (am437x-gp-evm) during resuming from System suspend when ARM Global
>>>>>> timer is selected as clocksource device - SysRq are working, but
>>>>>> nothing else. The reason of stall is that ARM Global timer loses its
>>>>>> contexts.
>>>>>>
>>>>>> The reason of stall is that ARM Global timer loses its contexts during
>>>>>> System suspend:
>>>>>> GT_CONTROL.TIMER_ENABLE = 0 (unbanked)
>>>>>> GT_COUNTERx = 0
>>>>>>
>>>>>> Hence, update ARM Global timer driver to reflect above behaviour
>>>>>> - save GT_CONTROL.TIMER_ENABLE during suspend and restore on resume;
>>>>>> - ensure clocksource and clockevent devices have coresponding flags
>>>>>> (CLOCK_SOURCE_SUSPEND_NONSTOP and CLOCK_EVT_FEAT_C3STOP) set
>>>>>> depending on presence of "always-on" DT property.
>>>>>>
>>>>>> CC: Arnd Bergmann <arnd@arndb.de>
>>>>>> Cc: John Stultz <john.stultz@linaro.org>
>>>>>> Cc: Felipe Balbi <balbi@ti.com>
>>>>>> Cc: Tony Lindgren <tony@atomide.com>
>>>>>> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
>>>>>> ---
>>>>>> drivers/clocksource/arm_global_timer.c | 23 +++++++++++++++++++++++
>>>>>> 1 file changed, 23 insertions(+)
>>>>>>
>>>>>> diff --git a/drivers/clocksource/arm_global_timer.c b/drivers/clocksource/arm_global_timer.c
>>>>>> index a2cb6fa..1bbaf64 100644
>>>>>> --- a/drivers/clocksource/arm_global_timer.c
>>>>>> +++ b/drivers/clocksource/arm_global_timer.c
>>>>>> @@ -51,6 +51,8 @@ static void __iomem *gt_base;
>>>>>> static unsigned long gt_clk_rate;
>>>>>> static int gt_ppi;
>>>>>> static struct clock_event_device __percpu *gt_evt;
>>>>>> +static bool gt_always_on;
>>>>>> +static u32 gt_control;
>>>>>>
>>>>>> /*
>>>>>> * To get the value from the Global Timer Counter register proceed as follows:
>>>>>> @@ -168,6 +170,9 @@ static int gt_clockevents_init(struct clock_event_device *clk)
>>>>>> {
>>>>>> int cpu = smp_processor_id();
>>>>>>
>>>>>> + if (!gt_always_on)
>>>>>> + clk->features |= CLOCK_EVT_FEAT_C3STOP;
>>>>>> +
>>>>>> clk->name = "arm_global_timer";
>>>>>> clk->features = CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT |
>>>>>> CLOCK_EVT_FEAT_PERCPU;
>>>>>> @@ -195,12 +200,25 @@ static cycle_t gt_clocksource_read(struct clocksource *cs)
>>>>>> return gt_counter_read();
>>>>>> }
>>>>>>
>>>>>> +static void gt_suspend(struct clocksource *cs)
>>>>>> +{
>>>>>> + gt_control = readl(gt_base + GT_CONTROL);
>>>>>> +}
>>>>>> +
>>>>>> +static void gt_resume(struct clocksource *cs)
>>>>>> +{
>>>>>> + /* enables timer on all the cores */
>>>>>> + writel(gt_control & GT_CONTROL_TIMER_ENABLE, gt_base + GT_CONTROL);
>>>>>
>>>>> do you really need to save context if all you restore is TIMER_ENABLE
>>>>> bit ? seems like you could skip gt_suspend altogether. Is there really a
>>>>> situation where this driver is running and GT isn't enabled ?
>>>>
>>>> Now It's not. It's always enabled. I did it because .suspend() is called for
>>>> all registered clock sources regardless of their usage. So, potentially
>>>> in the future, at the moment when .suspend() is called it might be disabled
>>>> (for example, .enable/disable() callbacks can be added and, if ARM Global timer
>>>> will not be registered as sched_clock, it will be possible to keep it disabled
>>>> if not used now).
>>>>
>>>> But It's not essentially now - I can update it and drop save restore.
>>>> Pls, confirm.
>>>
>>> I think it's best to skip suspend completely. You're not restoring
>>> anything you saved during suspend, unless you meant | where you used &.
>>>
>>
>> I didn't get it - I'm restoring one bit(0) only.
>
> that's the point, if you know you're restoring only that bit. Why save
> anything at all ?
>

i think there are difference between "restoring" and "re-enabling".
"restoring" - assume saving smth.. then restore saving value.
I'm saving & restoring one bit here.

But I can do just "re-enabling" -
writel(GT_CONTROL_TIMER_ENABLE, gt_base + GT_CONTROL);
and then I don't need to save anything. It will work with current
code.

--
regards,
-grygorii


\
 
 \ /
  Last update: 2015-11-13 19:41    [W:0.525 / U:0.948 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site