[bootlin/training-materials updates] master: slides/kernel-power-management: fix build (01fe6161)
Thomas Petazzoni
thomas.petazzoni at bootlin.com
Fri Apr 21 08:45:12 CEST 2023
Repository : https://github.com/bootlin/training-materials
On branch : master
Link : https://github.com/bootlin/training-materials/commit/01fe61616d6d26bead35f74cd1b1ca81045db6c9
>---------------------------------------------------------------
commit 01fe61616d6d26bead35f74cd1b1ca81045db6c9
Author: Thomas Petazzoni <thomas.petazzoni at bootlin.com>
Date: Fri Apr 21 08:31:00 2023 +0200
slides/kernel-power-management: fix build
Signed-off-by: Thomas Petazzoni <thomas.petazzoni at bootlin.com>
>---------------------------------------------------------------
01fe61616d6d26bead35f74cd1b1ca81045db6c9
.../kernel-power-management-content.tex | 324 ---------------------
.../kernel-power-management.tex | 324 +++++++++++++++++++++
2 files changed, 324 insertions(+), 324 deletions(-)
diff --git a/slides/kernel-power-management/kernel-power-management-content.tex b/slides/kernel-power-management/kernel-power-management-content.tex
deleted file mode 100644
index d1bd8c44..00000000
--- a/slides/kernel-power-management/kernel-power-management-content.tex
+++ /dev/null
@@ -1,324 +0,0 @@
-\section{Power Management}
-
-\begin{frame}
- \frametitle{PM building blocks}
- \begin{itemize}
- \item Several power management \emph{building blocks}
- \begin{itemize}
- \item Clock framework
- \item Suspend and resume
- \item CPUidle
- \item Runtime power management
- \item Power domains
- \item Frequency and voltage scaling
- \end{itemize}
- \item Independent \emph{building blocks} that can be improved
- gradually during development
- \end{itemize}
-\end{frame}
-
-\begin{frame}
- \frametitle{Clock framework (1)}
- \begin{itemize}
- \item Generic framework to manage clocks used by devices in the
- system
- \item Allows to reference count clock users and to shutdown the
- unused clocks to save power
- \item Simple API described in \kfile{include/linux/clk.h}.
- \begin{itemize}
- \item \kfunc{clk_get} to lookup and obtain a reference to a clock producer
- \item \kfunc{clk_enable} to inform the system when the clock source should be running
- \item \kfunc{clk_disable} to inform the system when the clock source is no longer required.
- \item \kfunc{clk_put} to free the clock source
- \item \kfunc{clk_get_rate} to obtain the current clock rate (in Hz) for a clock source
- \item \kfunc{clk_set_rate} to set the current clock rate (in Hz) of a clock source
- \end{itemize}
- \end{itemize}
-\end{frame}
-
-
-\begin{frame}{Clock framework (2)}
- The common clock framework
- \begin{itemize}
- \item Allows to declare the available clocks and their association
- to devices in the Device Tree
- \item Provides a {\em debugfs} representation of the clock tree
- \item Is implemented in \kdir{drivers/clk}
- \end{itemize}
-\end{frame}
-
-\begin{frame}{Diagram overview of the common clock framework}
- \begin{center}
- \includegraphics[width=\textwidth]{slides/kernel-power-management-content/clock-framework.pdf}
-\end{center}
-\end{frame}
-
-\begin{frame}{Clock framework (3)}
- The interface of the CCF divided into two halves:
- \begin{itemize}
- \item Common Clock Framework core
- \begin{itemize}
- \item Common definition of \kstruct{clk}
- \item Common implementation of the \code{clk.h} API (defined in
- \kfile{drivers/clk/clk.c})
- \item \kstruct{clk_ops}: operations invoked by the clk API
- implementation
- \item Not supposed to be modified when adding a new driver
- \end{itemize}
- \item Hardware-specific
- \begin{itemize}
- \item Callbacks registered with \kstruct{clk_ops} and the
- corresponding hardware-specific structures
- \item Has to be written for each new hardware clock
- \item Example: \kfile{drivers/clk/mvebu/clk-cpu.c}
- \end{itemize}
- \end{itemize}
-\end{frame}
-
-\begin{frame}{Clock framework (4)}
- Hardware clock operations: device tree
- \begin{itemize}
- \item The \textbf{device tree} is the \textbf{mandatory way} to
- declare a clock and to get its resources, as for any other
- driver using DT we have to:
- \begin{itemize}
- \item \textbf{Parse} the device tree to \textbf{setup} the
- clock: the resources but also the properties are retrieved.
- \item Declare the \textbf{compatible} clocks and associate each
- to an \textbf{initialization} function using
- \kfunc{CLK_OF_DECLARE}
- \item Example: \kfile{arch/arm/boot/dts/armada-xp.dtsi} and
- \kfile{drivers/clk/mvebu/armada-xp.c}
- \end{itemize}
- \end{itemize}
- See our presentation about the Clock Framework for more details:\\
- \scriptsize \url{https://bootlin.com/pub/conferences/2013/elce/common-clock-framework-how-to-use-it/}
-\end{frame}
-
-\begin{frame}
- \frametitle{Suspend and resume (to / from RAM)}
- \begin{itemize}
- \item Infrastructure in the kernel to support suspend and resume
- \item System on Chip hooks
- \begin{itemize}
- \item Define operations (at least \code{valid()} and \code{enter()})
- \kstruct{platform_suspend_ops} structure. See the documentation
- for this structure for details about possible operations and the
- way they are used.
- \item Registered using the \kfunc{suspend_set_ops} function
- \item See \kfile{arch/arm/mach-at91/pm.c}
- \end{itemize}
- \item Device driver hooks
- \begin{itemize}
- \item \code{pm} operations (\code{suspend()} and
- \code{resume()} hooks) in the
- \kstruct{device_driver} as a \kstruct{dev_pm_ops}
- structure in (\kstruct{platform_driver}, \kstruct{usb_driver}, etc.)
- \item See \kfile{drivers/net/ethernet/cadence/macb_main.c}
- \end{itemize}
- \item {\em Hibernate to disk} is based on suspend to RAM, copying
- the RAM contents (after a simulated suspend) to a swap partition.
- \end{itemize}
-\end{frame}
-
-\begin{frame}
- \frametitle{Triggering suspend / hibernate}
- \begin{itemize}
- \item \kstruct{suspend_ops} functions are called by the
- \kfunc{enter_state} function. \kfunc{enter_state} also
- takes care of executing the suspend and resume functions
- for your devices.
- \item Read \kfile{kernel/power/suspend.c}
- \item The execution of this function can be triggered from
- user space:
- \begin{itemize}
- \item \code{echo mem > /sys/power/state} (suspend to RAM)
- \item \code{echo disk > /sys/power/state} (hibernate to disk)
- \end{itemize}
- \item Systemd can also manage suspend and hibernate for you, and
- offers customizations
- \begin{itemize}
- \item \code{systemctl suspend} or \code{systemctl hibernate}.
- \item \small See \url{https://www.man7.org/linux/man-pages/man8/systemd-suspend.service.8.html}
- \end{itemize}
- \end{itemize}
-\end{frame}
-
-\begin{frame}
- \frametitle{Saving power in the idle loop}
- \begin{itemize}
- \item The idle loop is what you run when there's nothing left to run
- in the system.
- \item \kfunc{arch_cpu_idle} implemented in all architectures in
- \code{arch/<arch>/kernel/process.c}
- \item Example: \kfile{arch/arm/kernel/process.c}
- \item The CPU can run power saving HLT instructions, enter NAP mode,
- and even disable the timers (tickless systems).
- \item See also \url{https://en.wikipedia.org/wiki/Idle_loop}
- \end{itemize}
-\end{frame}
-
-\begin{frame}
- \frametitle{Managing idle}
- Adding support for multiple idle levels
- \begin{itemize}
- \item Modern CPUs have several sleep states offering different
- power savings with associated wake up latencies
- \item The {\em dynamic tick} feature allows to remove the
- periodic timer tick to save power, and to know when the next event is
- scheduled, for smarter sleeps.
- \item CPUidle infrastructure to change sleep states
- \begin{itemize}
- \item Platform-specific driver defining sleep states and
- transition operations
- \item Platform-independent governors
- \item Available in particular for x86/ACPI and most ARM SoCs
- \item See \kdochtml{admin-guide/pm/cpuidle} in kernel documentation.
- \end{itemize}
- \end{itemize}
-\end{frame}
-
-\begin{frame}
- \frametitle{PowerTOP}
- \url{https://01.org/powertop/}
- \begin{itemize}
- \item With dynamic ticks, allows to fix parts of kernel code and
- applications that wake up the system too often.
- \item PowerTOP allows to track the worst offenders
- \item Now available on ARM cpus implementing CPUidle
- \item Also gives you useful hints for reducing power.
- \item Try it on your x86 laptop:\\
- \code{sudo powertop}
- \end{itemize}
-\end{frame}
-
-\begin{frame}
- \frametitle{Runtime power management}
- \begin{itemize}
- \item Managing per-device idle, each device being managed by its
- device driver independently from others.
- \item According to the kernel configuration interface: \emph{Enable
- functionality allowing I/O devices to be put into energy-saving
- (low power) states at run time (or autosuspended) after a
- specified period of inactivity and woken up in response to a
- hardware-generated wake-up event or a driver's request.}
- \item New hooks must be added to the drivers:
- \code{runtime_suspend()}, \code{runtime_resume()},
- \code{runtime_idle()} in the \kstruct{dev_pm_ops}
- structure in \kstruct{device_driver}.
- \item API and details on \kdochtml{power/runtime_pm}
- \item See \kfile{drivers/net/ethernet/cadence/macb_main.c} again.
- \end{itemize}
-\end{frame}
-
-\begin{frame}
- \frametitle{Generic PM Domains (genpd)}
- \begin{itemize}
- \item Generic infrastructure to implement power domains based on
- Device Tree descriptions, allowing to group devices by the
- physical power domain they belong to.
- This sits at the same level as bus type for calling PM hooks.
- \item All the devices in the same PD get the same state at the same time.
- \item Specifications and examples available at \kdoctext{devicetree/bindings/power/power_domain.txt}
- \item Driver example: \kfile{drivers/soc/rockchip/pm_domains.c}
- (\kfunc{rockchip_pd_power_on}, \kfunc{rockchip_pd_power_off},
- \kfunc{rockchip_pm_add_one_domain}...)
- \item DT example: look for \kcompat{rockchip\%2Cpx30-power-controller}{rockchip,px30-power-controller}
- (\kfile{arch/arm64/boot/dts/rockchip/px30.dtsi}) and find PD definitions
- and corresponding devices.
- \item See Kevin Hilman's talk at Kernel Recipes 2017: \url{https://youtu.be/SctfvoskABM}
- \end{itemize}
-\end{frame}
-
-\begin{frame}
- \frametitle{Frequency and voltage scaling (1)}
- Frequency and voltage scaling possible through the
- \code{cpufreq} kernel infrastructure.
- \begin{itemize}
- \item Generic infrastructure: \kfile{drivers/cpufreq/cpufreq.c} and
- \kfile{include/linux/cpufreq.h}
- \item Generic governors, responsible for deciding frequency and
- voltage transitions
- \begin{itemize}
- \item \code{performance}: maximum frequency
- \item \code{powersave}: minimum frequency
- \item \code{ondemand}: measures CPU consumption to adjust frequency
- \item \code{conservative}: often better than
- \code{ondemand}. Only increases frequency gradually when the
- CPU gets loaded.
- \item \code{userspace}: leaves the decision to a user space
- daemon.
- \end{itemize}
- \item This infrastructure can be controlled from
- \code{/sys/devices/system/cpu/cpu<n>/cpufreq/}
- \end{itemize}
-\end{frame}
-
-\begin{frame}
- \frametitle{Frequency and voltage scaling (2)}
- \begin{itemize}
- \item CPU frequency drivers are in \kdir{drivers/cpufreq}. Example:
- \kfile{drivers/cpufreq/omap-cpufreq.c}
- \item Must implement the operations of the \code{cpufreq_driver}
- structure and register them using \kfunc{cpufreq_register_driver}
- \begin{itemize}
- \item \code{init()} for initialization
- \item \code{exit()} for cleanup
- \item \code{verify()} to verify the user-chosen policy
- \item \code{setpolicy()} or \code{target()} to actually perform
- the frequency change
- \end{itemize}
- \item See documentation in \kdochtmldir{cpu-freq} for useful explanations
- \end{itemize}
-\end{frame}
-
-\begin{frame}
- \frametitle{Regulator framework}
- \begin{itemize}
- \item Modern embedded platforms have hardware responsible for voltage
- and current regulation
- \item The regulator framework allows to take advantage of this
- hardware to save power when parts of the system are unused
- \begin{itemize}
- \item A consumer interface for device drivers (i.e. users)
- \item Regulator driver interface for regulator drivers
- \item Machine interface for board configuration
- \item sysfs interface for user space
- \end{itemize}
- \item See \kdochtmldir{power/regulator} in kernel documentation.
- \end{itemize}
-\end{frame}
-
-\begin{frame}
- \frametitle{BSP work for a new board}
- In case you just need to create a BSP for your board, and your
- CPU already has full PM support, you should just need to:
- \begin{itemize}
- \item Create clock definitions and bind your devices to them.
- \item Implement PM handlers (suspend, resume) in the drivers for
- your board specific devices.
- \item Implement runtime PM handlers in your drivers.
- \item Implement board specific power management if needed (mainly
- battery management)
- \item Implement regulator framework hooks for your board if
- needed.
- \item Attach on-board devices to PM domains if needed
- \item All other parts of the PM infrastructure should be already
- there: suspend / resume, cpuidle, cpu frequency and voltage
- scaling, PM domains.
- \end{itemize}
-\end{frame}
-
-\begin{frame}
- \frametitle{Useful resources}
- \begin{itemize}
- \item \kdochtmldir{power} in kernel documentation.
- \begin{itemize}
- \item Will give you many useful details.
- \end{itemize}
- \item Introduction to kernel power management, Kevin Hilman (Kernel Recipes 2015)
- \begin{itemize}
- \item \url{https://www.youtube.com/watch?v=juJJZORgVwI}
- \end{itemize}
- \end{itemize}
-\end{frame}
diff --git a/slides/kernel-power-management/kernel-power-management.tex b/slides/kernel-power-management/kernel-power-management.tex
new file mode 100644
index 00000000..dc5a13bf
--- /dev/null
+++ b/slides/kernel-power-management/kernel-power-management.tex
@@ -0,0 +1,324 @@
+\section{Power Management}
+
+\begin{frame}
+ \frametitle{PM building blocks}
+ \begin{itemize}
+ \item Several power management \emph{building blocks}
+ \begin{itemize}
+ \item Clock framework
+ \item Suspend and resume
+ \item CPUidle
+ \item Runtime power management
+ \item Power domains
+ \item Frequency and voltage scaling
+ \end{itemize}
+ \item Independent \emph{building blocks} that can be improved
+ gradually during development
+ \end{itemize}
+\end{frame}
+
+\begin{frame}
+ \frametitle{Clock framework (1)}
+ \begin{itemize}
+ \item Generic framework to manage clocks used by devices in the
+ system
+ \item Allows to reference count clock users and to shutdown the
+ unused clocks to save power
+ \item Simple API described in \kfile{include/linux/clk.h}.
+ \begin{itemize}
+ \item \kfunc{clk_get} to lookup and obtain a reference to a clock producer
+ \item \kfunc{clk_enable} to inform the system when the clock source should be running
+ \item \kfunc{clk_disable} to inform the system when the clock source is no longer required.
+ \item \kfunc{clk_put} to free the clock source
+ \item \kfunc{clk_get_rate} to obtain the current clock rate (in Hz) for a clock source
+ \item \kfunc{clk_set_rate} to set the current clock rate (in Hz) of a clock source
+ \end{itemize}
+ \end{itemize}
+\end{frame}
+
+
+\begin{frame}{Clock framework (2)}
+ The common clock framework
+ \begin{itemize}
+ \item Allows to declare the available clocks and their association
+ to devices in the Device Tree
+ \item Provides a {\em debugfs} representation of the clock tree
+ \item Is implemented in \kdir{drivers/clk}
+ \end{itemize}
+\end{frame}
+
+\begin{frame}{Diagram overview of the common clock framework}
+ \begin{center}
+ \includegraphics[width=\textwidth]{slides/kernel-power-management/clock-framework.pdf}
+\end{center}
+\end{frame}
+
+\begin{frame}{Clock framework (3)}
+ The interface of the CCF divided into two halves:
+ \begin{itemize}
+ \item Common Clock Framework core
+ \begin{itemize}
+ \item Common definition of \kstruct{clk}
+ \item Common implementation of the \code{clk.h} API (defined in
+ \kfile{drivers/clk/clk.c})
+ \item \kstruct{clk_ops}: operations invoked by the clk API
+ implementation
+ \item Not supposed to be modified when adding a new driver
+ \end{itemize}
+ \item Hardware-specific
+ \begin{itemize}
+ \item Callbacks registered with \kstruct{clk_ops} and the
+ corresponding hardware-specific structures
+ \item Has to be written for each new hardware clock
+ \item Example: \kfile{drivers/clk/mvebu/clk-cpu.c}
+ \end{itemize}
+ \end{itemize}
+\end{frame}
+
+\begin{frame}{Clock framework (4)}
+ Hardware clock operations: device tree
+ \begin{itemize}
+ \item The \textbf{device tree} is the \textbf{mandatory way} to
+ declare a clock and to get its resources, as for any other
+ driver using DT we have to:
+ \begin{itemize}
+ \item \textbf{Parse} the device tree to \textbf{setup} the
+ clock: the resources but also the properties are retrieved.
+ \item Declare the \textbf{compatible} clocks and associate each
+ to an \textbf{initialization} function using
+ \kfunc{CLK_OF_DECLARE}
+ \item Example: \kfile{arch/arm/boot/dts/armada-xp.dtsi} and
+ \kfile{drivers/clk/mvebu/armada-xp.c}
+ \end{itemize}
+ \end{itemize}
+ See our presentation about the Clock Framework for more details:\\
+ \scriptsize \url{https://bootlin.com/pub/conferences/2013/elce/common-clock-framework-how-to-use-it/}
+\end{frame}
+
+\begin{frame}
+ \frametitle{Suspend and resume (to / from RAM)}
+ \begin{itemize}
+ \item Infrastructure in the kernel to support suspend and resume
+ \item System on Chip hooks
+ \begin{itemize}
+ \item Define operations (at least \code{valid()} and \code{enter()})
+ \kstruct{platform_suspend_ops} structure. See the documentation
+ for this structure for details about possible operations and the
+ way they are used.
+ \item Registered using the \kfunc{suspend_set_ops} function
+ \item See \kfile{arch/arm/mach-at91/pm.c}
+ \end{itemize}
+ \item Device driver hooks
+ \begin{itemize}
+ \item \code{pm} operations (\code{suspend()} and
+ \code{resume()} hooks) in the
+ \kstruct{device_driver} as a \kstruct{dev_pm_ops}
+ structure in (\kstruct{platform_driver}, \kstruct{usb_driver}, etc.)
+ \item See \kfile{drivers/net/ethernet/cadence/macb_main.c}
+ \end{itemize}
+ \item {\em Hibernate to disk} is based on suspend to RAM, copying
+ the RAM contents (after a simulated suspend) to a swap partition.
+ \end{itemize}
+\end{frame}
+
+\begin{frame}
+ \frametitle{Triggering suspend / hibernate}
+ \begin{itemize}
+ \item \kstruct{suspend_ops} functions are called by the
+ \kfunc{enter_state} function. \kfunc{enter_state} also
+ takes care of executing the suspend and resume functions
+ for your devices.
+ \item Read \kfile{kernel/power/suspend.c}
+ \item The execution of this function can be triggered from
+ user space:
+ \begin{itemize}
+ \item \code{echo mem > /sys/power/state} (suspend to RAM)
+ \item \code{echo disk > /sys/power/state} (hibernate to disk)
+ \end{itemize}
+ \item Systemd can also manage suspend and hibernate for you, and
+ offers customizations
+ \begin{itemize}
+ \item \code{systemctl suspend} or \code{systemctl hibernate}.
+ \item \small See \url{https://www.man7.org/linux/man-pages/man8/systemd-suspend.service.8.html}
+ \end{itemize}
+ \end{itemize}
+\end{frame}
+
+\begin{frame}
+ \frametitle{Saving power in the idle loop}
+ \begin{itemize}
+ \item The idle loop is what you run when there's nothing left to run
+ in the system.
+ \item \kfunc{arch_cpu_idle} implemented in all architectures in
+ \code{arch/<arch>/kernel/process.c}
+ \item Example: \kfile{arch/arm/kernel/process.c}
+ \item The CPU can run power saving HLT instructions, enter NAP mode,
+ and even disable the timers (tickless systems).
+ \item See also \url{https://en.wikipedia.org/wiki/Idle_loop}
+ \end{itemize}
+\end{frame}
+
+\begin{frame}
+ \frametitle{Managing idle}
+ Adding support for multiple idle levels
+ \begin{itemize}
+ \item Modern CPUs have several sleep states offering different
+ power savings with associated wake up latencies
+ \item The {\em dynamic tick} feature allows to remove the
+ periodic timer tick to save power, and to know when the next event is
+ scheduled, for smarter sleeps.
+ \item CPUidle infrastructure to change sleep states
+ \begin{itemize}
+ \item Platform-specific driver defining sleep states and
+ transition operations
+ \item Platform-independent governors
+ \item Available in particular for x86/ACPI and most ARM SoCs
+ \item See \kdochtml{admin-guide/pm/cpuidle} in kernel documentation.
+ \end{itemize}
+ \end{itemize}
+\end{frame}
+
+\begin{frame}
+ \frametitle{PowerTOP}
+ \url{https://01.org/powertop/}
+ \begin{itemize}
+ \item With dynamic ticks, allows to fix parts of kernel code and
+ applications that wake up the system too often.
+ \item PowerTOP allows to track the worst offenders
+ \item Now available on ARM cpus implementing CPUidle
+ \item Also gives you useful hints for reducing power.
+ \item Try it on your x86 laptop:\\
+ \code{sudo powertop}
+ \end{itemize}
+\end{frame}
+
+\begin{frame}
+ \frametitle{Runtime power management}
+ \begin{itemize}
+ \item Managing per-device idle, each device being managed by its
+ device driver independently from others.
+ \item According to the kernel configuration interface: \emph{Enable
+ functionality allowing I/O devices to be put into energy-saving
+ (low power) states at run time (or autosuspended) after a
+ specified period of inactivity and woken up in response to a
+ hardware-generated wake-up event or a driver's request.}
+ \item New hooks must be added to the drivers:
+ \code{runtime_suspend()}, \code{runtime_resume()},
+ \code{runtime_idle()} in the \kstruct{dev_pm_ops}
+ structure in \kstruct{device_driver}.
+ \item API and details on \kdochtml{power/runtime_pm}
+ \item See \kfile{drivers/net/ethernet/cadence/macb_main.c} again.
+ \end{itemize}
+\end{frame}
+
+\begin{frame}
+ \frametitle{Generic PM Domains (genpd)}
+ \begin{itemize}
+ \item Generic infrastructure to implement power domains based on
+ Device Tree descriptions, allowing to group devices by the
+ physical power domain they belong to.
+ This sits at the same level as bus type for calling PM hooks.
+ \item All the devices in the same PD get the same state at the same time.
+ \item Specifications and examples available at \kdoctext{devicetree/bindings/power/power_domain.txt}
+ \item Driver example: \kfile{drivers/soc/rockchip/pm_domains.c}
+ (\kfunc{rockchip_pd_power_on}, \kfunc{rockchip_pd_power_off},
+ \kfunc{rockchip_pm_add_one_domain}...)
+ \item DT example: look for \kcompat{rockchip\%2Cpx30-power-controller}{rockchip,px30-power-controller}
+ (\kfile{arch/arm64/boot/dts/rockchip/px30.dtsi}) and find PD definitions
+ and corresponding devices.
+ \item See Kevin Hilman's talk at Kernel Recipes 2017: \url{https://youtu.be/SctfvoskABM}
+ \end{itemize}
+\end{frame}
+
+\begin{frame}
+ \frametitle{Frequency and voltage scaling (1)}
+ Frequency and voltage scaling possible through the
+ \code{cpufreq} kernel infrastructure.
+ \begin{itemize}
+ \item Generic infrastructure: \kfile{drivers/cpufreq/cpufreq.c} and
+ \kfile{include/linux/cpufreq.h}
+ \item Generic governors, responsible for deciding frequency and
+ voltage transitions
+ \begin{itemize}
+ \item \code{performance}: maximum frequency
+ \item \code{powersave}: minimum frequency
+ \item \code{ondemand}: measures CPU consumption to adjust frequency
+ \item \code{conservative}: often better than
+ \code{ondemand}. Only increases frequency gradually when the
+ CPU gets loaded.
+ \item \code{userspace}: leaves the decision to a user space
+ daemon.
+ \end{itemize}
+ \item This infrastructure can be controlled from
+ \code{/sys/devices/system/cpu/cpu<n>/cpufreq/}
+ \end{itemize}
+\end{frame}
+
+\begin{frame}
+ \frametitle{Frequency and voltage scaling (2)}
+ \begin{itemize}
+ \item CPU frequency drivers are in \kdir{drivers/cpufreq}. Example:
+ \kfile{drivers/cpufreq/omap-cpufreq.c}
+ \item Must implement the operations of the \code{cpufreq_driver}
+ structure and register them using \kfunc{cpufreq_register_driver}
+ \begin{itemize}
+ \item \code{init()} for initialization
+ \item \code{exit()} for cleanup
+ \item \code{verify()} to verify the user-chosen policy
+ \item \code{setpolicy()} or \code{target()} to actually perform
+ the frequency change
+ \end{itemize}
+ \item See documentation in \kdochtmldir{cpu-freq} for useful explanations
+ \end{itemize}
+\end{frame}
+
+\begin{frame}
+ \frametitle{Regulator framework}
+ \begin{itemize}
+ \item Modern embedded platforms have hardware responsible for voltage
+ and current regulation
+ \item The regulator framework allows to take advantage of this
+ hardware to save power when parts of the system are unused
+ \begin{itemize}
+ \item A consumer interface for device drivers (i.e. users)
+ \item Regulator driver interface for regulator drivers
+ \item Machine interface for board configuration
+ \item sysfs interface for user space
+ \end{itemize}
+ \item See \kdochtmldir{power/regulator} in kernel documentation.
+ \end{itemize}
+\end{frame}
+
+\begin{frame}
+ \frametitle{BSP work for a new board}
+ In case you just need to create a BSP for your board, and your
+ CPU already has full PM support, you should just need to:
+ \begin{itemize}
+ \item Create clock definitions and bind your devices to them.
+ \item Implement PM handlers (suspend, resume) in the drivers for
+ your board specific devices.
+ \item Implement runtime PM handlers in your drivers.
+ \item Implement board specific power management if needed (mainly
+ battery management)
+ \item Implement regulator framework hooks for your board if
+ needed.
+ \item Attach on-board devices to PM domains if needed
+ \item All other parts of the PM infrastructure should be already
+ there: suspend / resume, cpuidle, cpu frequency and voltage
+ scaling, PM domains.
+ \end{itemize}
+\end{frame}
+
+\begin{frame}
+ \frametitle{Useful resources}
+ \begin{itemize}
+ \item \kdochtmldir{power} in kernel documentation.
+ \begin{itemize}
+ \item Will give you many useful details.
+ \end{itemize}
+ \item Introduction to kernel power management, Kevin Hilman (Kernel Recipes 2015)
+ \begin{itemize}
+ \item \url{https://www.youtube.com/watch?v=juJJZORgVwI}
+ \end{itemize}
+ \end{itemize}
+\end{frame}
More information about the training-materials-updates
mailing list