public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: David Brownell <david-b@pacbell.net>
To: Paul Sokolovsky <pmiscml@gmail.com>
Cc: Alessandro Zummo <alessandro.zummo@towertech.it>,
	kernel-discuss@handhelds.org, linux-kernel@vger.kernel.org,
	Richard Purdie <rpurdie@rpsys.net>
Subject: Re: [PATCH] RTC classdev: Add sysfs support for wakeup alarm (r/w)
Date: Sun, 17 Dec 2006 20:28:58 -0800	[thread overview]
Message-ID: <200612172028.58665.david-b@pacbell.net> (raw)
In-Reply-To: <1866913935.20061217213036@gmail.com>

On Sunday 17 December 2006 11:30 am, Paul Sokolovsky wrote:

>     Small battery-powered systems, like PDAs, need a way to be
> suspended most of the time and woken up just from time to time to
> process pending tasks. 

Sounds like you're thinking of this from a userspace perspective...

Could you share some examples of such "pending tasks"?  I suspect
beaconing once or twice a second in a wireless network isn't quite
what you mean, although it fits your description.  On some Linux
platforms with dynamic tick support, Linux can enter suspend modes
between periodic wakeups needed for such beaconing.


> Obvious way to achieve this is to use timer, or 
> alarm, wakeup. Unfortunately, this matter is bit confusing in Linux.
> There's only one "good" "supported" way to set alarm - via ioctl() on
> an RTC device fd. Unfortunately, this alarm is not persistent - as soon
> as fd is closed, alarm id discharged.

I don't think that's true in general.  Most RTCs don't even care
whether userspace did an open() or close().  I see the S3C one does,
and that explicitly leaves the alarm active. 

But I see that only the SA1100/PXA and SH RTCs turn off all IRQs
after RTC_WKALM_* requests ... that's a distinct minority.

So judging implementations as votes ... only two implementations
that implement the RTC_WKALM_* call follow that rule, and most
don't.  However, a few implementations ignore rtc_wkalrm.enabled,
or otherwise mistreat that flag (e.g. rtc-ds1553 doesn't disable
AIE when enabled==0), so it's clear there are some issues there.

My vote would be that closing the FD should not turn off the alarm.
It's supposed to be a one-shot deal anyway.

And also, that someone audits the drivers/rtc code to make sure that
alarm-capable drivers handle the rtc_wkalrm.enabled flag correctly;
your patch sort of presumes that will happen, anyway.  And hmm, it'd
be good to have rtctest.c (in Documentation/rtc.txt) test for that...
it doesn't actually use RTC_WKALM_* calls, so it's too easy for folk
to goof up their implementations.


> Formal part
> ===========
> 
> Implement "alarm" attribute group for RTC classdevs. At this time,
> add "since_epoch", "wakeup_enabled", and "pending" attributes. First
> two support both read and write.

I think you shouldn't add this group unless the RTC has methods
to read and write the alarm; there are RTCs that don't have that
feature.

Also, I'd rather see a much simpler interface.  Like a single
"alarm" attribute.  It would display as the empty string unless
it was enabled, in which case the alarm time wouhd show.  To
disable it, write an empty string; to enable an alarm, just write
a valid time (in the future).  The other parameters aren't needed;
"wakeup" is PM infrastructure (/sys/devices/.../power/wakeup),
since it's easy to have an alarm that's not wakeup-capable.

- Dave





  reply	other threads:[~2006-12-18  4:29 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-12-17 19:30 [PATCH] RTC classdev: Add sysfs support for wakeup alarm (r/w) Paul Sokolovsky
2006-12-18  4:28 ` David Brownell [this message]
2006-12-18 23:58   ` Paul Sokolovsky
2006-12-19  0:54     ` David Brownell
2006-12-19  0:59       ` David Brownell
2006-12-19  6:41         ` Paul Sokolovsky
2006-12-19  9:06           ` David Brownell

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=200612172028.58665.david-b@pacbell.net \
    --to=david-b@pacbell.net \
    --cc=alessandro.zummo@towertech.it \
    --cc=kernel-discuss@handhelds.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pmiscml@gmail.com \
    --cc=rpurdie@rpsys.net \
    /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