linux-kernel - Re: at91sam9260 wakeup on serial port

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20080128195114.33d7616d@dhcp-252-066.norway.atmel.com>
Date:	Mon, 28 Jan 2008 19:51:14 +0100
From:	Haavard Skinnemoen <hskinnemoen@...el.com>
To:	David Brownell <david-b@...bell.net>
Cc:	michael <trimarchi@...dalf.sssup.it>, linux-kernel@...r.kernel.org,
	Andrew Victor <linux@...im.org.za>
Subject: Re: at91sam9260 wakeup on serial port

On Mon, 28 Jan 2008 10:21:57 -0800
David Brownell <david-b@...bell.net> 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.

But I suppose we can still disable the HSB (system) bus, all the
peripherals we don't care about, switch the remaining ones over to an
oscillator and keep that oscillator running. In order to be able to
actually respond to something happening on the serial line, we need to
keep a relatively-high-speed oscillator or PLL running anyway (32 kHz
won't do.)

There's a separate WAKE_N pin that is completely asynchronous, so with
some external logic, we can probably wake up the CPU all the way from
Static mode if a given input state is present. But that's definitely
"board specific" territory, and starting the oscillators take a _long_
time on the AP7000 (especially the 32 kHz, but then again, it barely
consumes any power, so we might as well keep it running and keep the
RTC going as well.)

So on AP7000, I think we'll just need to keep clocking the USART and
let it generate the interrupt that wakes up the rest of the system.
With the rest of the system effectively stopped, I don't think this is
very expensive power-wise, but it remains to be seen.

Haavard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/