8mW sleep for Beagle Board.

For one of my masters courses, I performed research on partial array self
refresh and chose the Beagle Board as my implementation platform. As PASR
only ends up saving about 1mW, the sleep mode current consumption of the
omap/pm branch of ~150-250mW (IIRC) dwarfed any savings I would receive
and make it not only difficult to measure, but would make the utilization
of PASR seem quite pointless.

I set about reducing the sleep mode power consumption of the Beagle
Board from both a software and hardware angle. Any hardware modifications
will of course void any warranty, and I don't make any guarantees that these
modifications won't cause latchup or any other form of damage occur to your
board.

On the hardware side, the 3.3V rail ends up consuming quite a bit of current.
The low power mode of the DVI transceiver chip utilizes about 3mW and the rs232
transceivers are not configured to enter a low power mode and consume about
15-20mW. By disabling the 3.3V LDO during sleep mode, both consumers are cut
as well as any power used by the 3.3V LDO. I just tied the REGEN signal
to the LDO_EN pin to allow the software to control the 3.3V rail.

http://www.flickr.com/photos/31208937@N06/3443906143/
http://www.flickr.com/photos/31208937@N06/3443906137/

The always on power LED consumes about 40-50mW. I tied that to the newly
controllable 3.3V rail to allow it to be powered down along with the 3.3V rail
during sleep.

http://www.flickr.com/photos/31208937@N06/3443906143/

The Beagle Board doesn't utilize any of the high frequency clock request/clock
enable signals. With the proper delays inserted within the TWL 4030 sleep/wake
scripts the high frequency clock circuitry on the TWL 4030 can be powered off
during sleep. The external oscillator can also be put in a low power mode
if it's enable pin is tied to VPLL1 instead of the always on VIO.

http://www.flickr.com/photos/31208937@N06/3443906129/

The 26MHz oscillator that ships with the Beagle Board enters a tri-state output
mode when the enable pin is low. This mode cuts the power usage in half, from
about 15mW to 7mW. However, a variant of the part exists that has a low power
mode instead of just a tri-state output mode. That drops its power consumption
to the microwatt range.

http://www.flickr.com/photos/31208937@N06/3443906135/
http://www.ecliptek.com/pdf/oscillators/EP13E7.pdf
(EP16E7E2J-26.000M vs EP16E7E2H-26.000M)

I have a couple more of this oscillators if someone wants to experiment
with them.

The software changes involved setting up a TWL 4030 sleep script to power
off the necessary rails and to put other resources into sleep mode.
Additionally, the GPIO driver was modified to program the associated
wake padconf wakeenable bits so that the user button can be used to wake
the processor from power off mode. The rs232 driver was also modified to
allow the sysfs power/wakeup to disable the power off wakeup trigger.

As I get more time and a formal paper together, I'll send the changes
I made to actually get PASR working.

This patch creates low power sleep scripts for the Beagle Board. It allows
VDD1, VDD2, and VPLL1 to be powered off during processor off mode. It also
allows the power off of the TWL 4030 internal VINTANA2 reference and the
TWL 4030 high speed clock circuitry. Additionaly, it instructs the VIO
regulator to enter a low power mode as well as the internal VINTANA1,
VINTDIG, and RES_Main_Ref sources.

The scripts require additional changes to allow reset and reboot to function
properly.

This patch configures the wakeup padconf registers to reflect the sysfs
power/wakeup settings. This allows a GPIO to wake the processor from
off mode.

This change causes the REGEN signal to go low during suspend. This can be
used to disable devices on the peripheral board during suspend.

This patch causes the OMAP uarts to honor the sysfs power/wakeup file for
IOPADs. Before the OMAP was always woken up from off mode on a rs232 signal
change.

This patch also creates a different platform device for each serial
port so that the wakeup properties can be control per port.

The patch is not in a complete state, but for my testing it was necessary
to disable rs232 wakeup as allowing the signals to float in off mode by
powering off the level converters was causing a wakeup event.

Should these patches go to linux-omap mailing list instead??
Regards,
Nishanth Menon

Should these patches go to linux-omap mailing list instead??
Regards,
Nishanth Menon

I'll probably forward the GPIO and rs232 padconf wake patches to the
linux-omap list.

Please :slight_smile:

Russ Dill <russ.dill@gmail.com> writes:

For one of my masters courses, I performed research on partial array
self refresh and chose the Beagle Board as my implementation
platform. As PASR only ends up saving about 1mW, the sleep mode
current consumption of the omap/pm branch of ~150-250mW (IIRC)
dwarfed any savings I would receive and make it not only difficult
to measure, but would make the utilization of PASR seem quite
pointless.

Hi Russ,

I'm not an active reader of this list, so just discovered this
discussion now.

I'm curious how you were testing this on the OMAP side. Were you only
testing a full suspend? Were you able see the 8mW in idle as well?
Was this with the OMAP in retention or in off-mode?

Thanks,

Kevin

The 8mW was from a full suspend with the OMAP in off-mode. It also
included modifications to the board and scripts for the twl4030.

Russ Dill <russ.dill@gmail.com> writes: