LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: David Brownell <david-b@pacbell.net>
To: Haavard Skinnemoen <hskinnemoen@atmel.com>
Cc: michael <trimarchi@gandalf.sssup.it>,
	linux-kernel@vger.kernel.org, Andrew Victor <linux@maxim.org.za>
Subject: Re: at91sam9260 wakeup on serial port
Date: Wed, 30 Jan 2008 10:56:12 -0800	[thread overview]
Message-ID: <200801301056.13186.david-b@pacbell.net> (raw)
In-Reply-To: <20080130124754.70f5b218@dhcp-252-066.norway.atmel.com>

On Wednesday 30 January 2008, Haavard Skinnemoen wrote:
> On Tue, 29 Jan 2008 19:44:53 -0800
> David Brownell <david-b@pacbell.net> wrote:
> 
> > On Monday 28 January 2008, Haavard Skinnemoen wrote:
> > > 
> > > > What will AVR32 (AP7) need to do, when it supports system sleep states?
> > > 
> > > Not sure. The PIOs seem to require a clock in order to detect a pin
> > > change, so I don't think we can enter very deep sleep states if we want
> > > to be woken up by the USART.
> > 
> > Right; if no DMA is pending, then the HSB matrix clock can be idled, DRAM put
> > into self-refresh, and most peripherals can issue wakeups ... AP7 "Frozen"
> > state, very analagous to AT91 "standby" on Linux.  UARTs and GPIOs can wake.
> 
> Yeah, although the nasty thing about UARTs is that you never know when
> DMA really is idle.

If the UART isn't open, its DMA should be inactive.  :)

Also, after suspend() it should normally be inactive.
(That latter is somewhat platform-specific.)


> > The closest analogue to the AT91 support would map /sys/power/state:
> > 
> > 	standby --> to AP7 "Frozen"
> > 	mem --> to AP7 "Stop"
> 
> Yes, that looks reasonable. We can also do something in between by
> stopping most peripherals and busses. For example, keep one peripheral
> bus and one USART running from OSC0 with everything else stopped.

Wouldn't that just be a variant of "Frozen"?  The clock API should
be fully capable of disabling unused clocks, PLLs, and oscillators
when the platform supports it.  It's common for lots of clocks to be
disable even in non-suspended system states.


> I think we need some chip- or family-specific sleep code that knows how
> to enter a given power state. But the specifics about how to wake the
> system up must necessarily be board-specific (or even run-time
> configurable.)

The sysfs wakeup attributes are the runtiime config mechanism for all
events associated with a single device.

- Dave

  reply	other threads:[~2008-01-30 18:56 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-28 11:15 michael
2008-01-28 13:56 ` Haavard Skinnemoen
2008-01-28 18:21   ` David Brownell
2008-01-28 18:44     ` trimarchi
2008-01-28 18:51     ` Haavard Skinnemoen
2008-01-30  0:37       ` michael
2008-01-30  3:44       ` David Brownell
2008-01-30 11:47         ` Haavard Skinnemoen
2008-01-30 18:56           ` David Brownell [this message]
2008-01-30 20:34             ` Haavard Skinnemoen

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=200801301056.13186.david-b@pacbell.net \
    --to=david-b@pacbell.net \
    --cc=hskinnemoen@atmel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@maxim.org.za \
    --cc=trimarchi@gandalf.sssup.it \
    --subject='Re: at91sam9260 wakeup on serial port' \
    /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

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).