linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: swarren@wwwdotorg.org (Stephen Warren)
To: linux-arm-kernel@lists.infradead.org
Subject: struct sys_timer .suspend/.resume ignored for ARCH_SA1100/ARCH_PXA?
Date: Wed, 07 Nov 2012 17:01:50 -0700	[thread overview]
Message-ID: <509AF66E.8020308@wwwdotorg.org> (raw)
In-Reply-To: <20121107232341.GY28327@n2100.arm.linux.org.uk>

On 11/07/2012 04:23 PM, Russell King - ARM Linux wrote:
> On Wed, Nov 07, 2012 at 04:06:12PM -0700, Stephen Warren wrote:
>> Russell, Kevin,
>>
>> In commit 9e4559d "[ARM] 4258/2: Support for dynticks in idle loop" in
>> 2007, Kevin applied the following change:
>>
>>> diff --git a/arch/arm/kernel/time.c b/arch/arm/kernel/time.c
>>
>>> -#ifdef CONFIG_PM
>>> +#if defined(CONFIG_PM) && !defined(CONFIG_GENERIC_CLOCKEVENTS)
>>>  static int timer_suspend(struct sys_device *dev, pm_message_t state)
>>
>> This means that for any architecture that enables GENERIC_CLOCKEVENTS,
>> the .suspend/.resume fields of struct sys_timer will be ignored, since
>> timer_suspend()/timer_resume() won't be filled into
>> arch/arm/kernel/time.c's struct syscore_ops timer_syscore_ops.
> 
> Correct.
> 
>> Later, in commit 3e238be "[ARM] sa1100: add clock event support" in
>> 2008, Russell modified ARCH_SA1100 to select GENERIC_CLOCKEVENTS. I
>> believe this means that sa1100_timer_suspend()/resume() haven't been
>> used since.
> 
> Also correct.
> 
>> A similar issue exists for ARCH_PXA.
>>
>> Should sa1100_timer_suspend(), sa1100_timer_resume(),
>> pxa_timer_suspend(), pxa_timer_suspend() simply be deleted since they
>> are dead code, or should they be revived somehow; is the ifdef from
>> Kevin's change incorrect?
> 
> Hmm, that's probably not good for either of those two platforms; it means
> that the OSCR and match registers get lost over a suspend/resume.  That's
> not a real big problem for the clocksource code, but if its being used
> for something else (eg, rtc) then it probably means we have a failure
> there.

OK, so it sounds like the correct approach here is to re-enable those
functions. The local patches I have right now do this, and hook them
into e.g. ckevt_sa1100_osmr0's suspend/resume rather than sys_timer's. I
assume that will work fine?

>> As background, I'm working on a patch series that will remove all fields
>> from struct sys_timer except for .init, and will then replace the ARM
>> machine descriptor's .timer struct pointer with a .init_timer function
>> pointer. This will allow machines, on an opt-in basis, to call into a
>> central function in drivers/clocksource to initialize the required
>> timer, as determined by searching device tree for a known device type,
>> in much the same way as has been proposed to use a single implementation
>> for for the machine descriptor's .init_irq. As part of this, I've been
>> looking at moving any use of struct sys_timer .suspend/.resume into e.g.
>> struct clock_event_device .suspend/.resume, and found this issue.
> 
> Don't forget we still have a number of platforms not converted to
> the generic event/clocksource stuff (because they lack the necessary
> counters/timers for this 'new' infrastructure.)

I believe the only user of struct sys_timer .suspend/.resume that does
use struct clock_event_device is s3c2410. I'd missed that before since
I'd only searched for .suspend and not .resume alone. Perhaps this one
should just register its own syscore_ops instead of having the ARM core
do that on its behalf.

      reply	other threads:[~2012-11-08  0:01 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-07 23:06 struct sys_timer .suspend/.resume ignored for ARCH_SA1100/ARCH_PXA? Stephen Warren
2012-11-07 23:23 ` Russell King - ARM Linux
2012-11-08  0:01   ` Stephen Warren [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=509AF66E.8020308@wwwdotorg.org \
    --to=swarren@wwwdotorg.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).