Last edited one month ago

Reset overview

Applicable for STM32MP13x lines, STM32MP15x lines, STM32MP21x lines, STM32MP23x lines, STM32MP25x lines

The Linux® kernel reset framework offers a generic API for reset lines management at platform level.

1. Framework purpose[edit | edit source]

The purpose of this article is to introduce the Linux kernel Reset Framework. It provides general information and, based on concrete IP use cases, explains how to use it.

The Linux Reset framework offers a generic API for abstracting and controlling the different reset lines of the platform.
Reset lines can be internal system reset signals or external lines such as a GPIO to reset an external device.

2. System overview[edit | edit source]

RCC
Reset Overview

2.1. Component description[edit | edit source]

  • reset core: kernel reset framework designed for abstracting device reset handling via GPIOs or internal reset controller modules.
  • reset-stm32mp: STM32MPx RCC specific reset driver
  • reset-scmi: SCMI reset driver
  • RCC: Reset and clock controller that generates the different internal reset lines on STM32MPx.

2.2. API description[edit | edit source]

Documentation on the reset interface can be found in kernel documentation:

To get the line reset from DT:

  • devm_reset_control_get_exclusive: looks up and obtains an exclusive reference to a reset controller (cannot be shared with another driver).
  • devm_reset_control_get_shared: looks up and obtains a shared reference to reset a controller (can be shared with another driver).
  • devm_reset_control_get: same as devm_reset_control_get_exclusive.
  • devm_reset_control_get_optional: same as devm_reset_control_get except that the reference name is optional.
  • devm_reset_control_get_optional_exclusive: same as devm_reset_control_get_exclusive except that the reference name is optional.
  • devm_reset_control_get_optional_shared: same as devm_reset_control_get_shared except that the reference name is optional.

To configure the reset line and retrieve its status from DT:

  • reset_control_assert: asserts the reset line
  • reset_control_deassert: deasserts the reset line
  • reset_control_status: returns if the line is asserted or not

3. Configuration[edit | edit source]

3.1. Kernel configuration[edit | edit source]

By default, the activation of the Reset framework configuration (CONFIG_RESET_CONTROLER) is selected in the kernel configuration, through the Linux Menuconfig tool: Menuconfig or how to configure kernel (see CONFIG_ARCH_STM32 in arch/arm/mach-stm32/Kconfig and for RCC driver: COMMON_CLK_STM32MP135, COMMON_CLK_STM32MP157, COMMON_CLK_STM32MP25 in drivers/clk/stm32/Makefile ).

3.2. Device tree configuration[edit | edit source]

A detailed device tree configuration is described in Reset device tree configuration.

4. How to use the Reset framework[edit | edit source]

To control a peripheral reset line, a driver must first get a reference on the reset handler thanks to its device tree node.
The driver can then assert and deassert the reset line by calling the reset framework API.

Below an example:

	foo: foo@adcdefgh {
               compatible = "foo-driver";
               ...
		resets = <&rcc FOO_R>;
               ...
	};

Before using the reset specified in the device tree node, the foo driver has to request it at probe execution.

	static int foo_probe(struct platform_device *pdev)
	{
		struct reset_control *rst;
		...
		rst = devm_reset_control_get_exclusive(&pdev->dev, NULL);
		if (IS_ERR(rst)) {
			ret = PTR_ERR(rest);
			dev_err(&pdev->dev, "reset get failed: %d\n", ret);
			goto err_master_put;
		}
		...

The reset can then be asserted or deasserted using the reset framework API:

               ...
               reset_control_assert(rst);
               udelay(2);
               reset_control_deassert(rst);
               ...

5. Source code location[edit | edit source]

The reset framework is composed of:

6. References[edit | edit source]