\subchapter{Power management}{Objective: practice with standard power
  management interfaces offered by Linux}

After this lab, you will be able to:

\begin{itemize}
\item Suspend and resume your Linux system
\item Change the CPU frequency of your system
\end{itemize}

\section{Setup}

Go to the \code{/home/<user>/felabs/powermgt/usage/} directory.

Download and extract the latest update to the Linux 3.1 kernel.

Suspend/resume support for the Calao board is already included in this
kernel.

Cpu frequency scaling support for this hardware was developed by Free
Electrons and is not yet part of the mainline kernel. Therefore,
before compiling the 3.1 kernel, you'll have to apply the three
patches in the \code{data/} directory of this lab:

\begin{itemize}

\item The first patch implements the CPU frequency driver itself,
  which allows to change the frequency on the AT91SAM9263 CPU

\item The second patch adds CPU frequency support to the serial port
  driver. When the CPU clock is changed, the divisors for the baud
  rate generator must be modified. This is what this patch does.

\item The third patch adds CPU frequency support to the Ethernet
  controller driver for similar reasons.

\end{itemize}

Configure your kernel with CPU Frequency scaling support, with the CPU
Frequency driver for AT91, and for the different cpufreq governors.

Then, compile this kernel, and boot the system over NFS on the root 
filesystem used in the debugging lab (\code{/home/<user>/felabs/linux/debugging/nfsroot/}).

\section{Suspend and resume}

To suspend to RAM the Calao board, run:

\begin{verbatim}
echo mem > /sys/power/state
\end{verbatim}

The Calao board will then put itself in a low power-consumption mode,
as the inactivity of most LEDs will show.

To resume the Calao board, push the User button. After a short time,
the board will be usable again.

\section{CPU frequency control}

Linux has a {\em cpufreq} driver to control CPU frequency. Of course, it can
only switch between the limited number of operating states that your
CPU and board can support.

This interface can be controlled by userspace. This means it allows
you to let the system user tune it from a graphical front-end, for
example.

Go to the \code{/sys/devices/system/cpu/cpu0/cpufreq/} directory, and
see what available files are.

Check what the current cpufreq governor is.

Find what the allowed frequencies are on your system.

Now look at the files which offer write permission. These are the ones
you can use to control \code{cpufreq}.

Switch to the \code{userspace} governor, the one that disables the
kernel autopilot.  Now, set the frequency of \code{cpu0} to the maximum
one. View the \code{scaling_cur_freq} file to check that the
frequency is the one you expected.

Change the governor to \code{performance}, check the current frequency,
and change to \code{powersave} and check the frequency again.

You can also select the \code{ondemand} governor, add some load to your
target by running \code{ping -f target-ip} ({\em ping} in flood mode) from
your PC and see the cpu frequency increase when your system gets
pinged.

Note that with the \code{userspace} governor enabled, you can implement
your own, custom CPU frequency control based on your own criteria. You
could check the system temperature, for example, and if it gets hotter
than a specified threshold, you could slow down the frequency. You
could also let a time critical process bump the frequency to the
maximum value. You can see that in userspace, {\bf you} are the
governor.

\section{Using PowerTop}

On your development PC. Install the nice PowerTop tool contributed by Intel:

\begin{verbatim}
sudo apt-get install powertop
\end{verbatim}

Run the \code{powertop} command, and see it display statistics, and
list the top processes that cause you CPU to wake up from a deeper
sleep state, causing it to consume more power. You could use this
interface to find power management bugs in the applications running on
your system.

If you're using a laptop, remove the AC power for a while. This gives
you access to live power estimates from ACPI.

Also follow the tips that PowerTop gives you to conserve power, and
try to make your system consume as little power as possible.

Compare your power estimates with other people in the classroom, and
try to achieve the best results. Any technique can be used!

Thanks to Linaro, PowerTop is also available on ARM now. See
\url{https://wiki.linaro.org/WorkingGroups/PowerManagement/Doc/Powertop}.

So, if your embedded architecture has CPUidle support, you could try
this utility on it. If your embedded architecture has CPUidle support,
even if you didn't compile powertop, you can still access idle state
statistics by looking at the files
in \code{/sys/devices/system/cpu/cpu<n>/cpuidle}.
