Documentation/driver-api/reset.rst - third_party/kernel - Git at Google

 .. SPDX-License-Identifier: GPL-2.0-only

 ====================
 Reset controller API
 ====================

 Introduction
 ============

 Reset controllers are central units that control the reset signals to multiple
 peripherals.
 The reset controller API is split into two parts:
 the `consumer driver interface <#consumer-driver-interface>`__ (`API reference
 <#reset-consumer-api>`__), which allows peripheral drivers to request control
 over their reset input signals, and the `reset controller driver interface
 <#reset-controller-driver-interface>`__ (`API reference
 <#reset-controller-driver-api>`__), which is used by drivers for reset
 controller devices to register their reset controls to provide them to the
 consumers.

 While some reset controller hardware units also implement system restart
 functionality, restart handlers are out of scope for the reset controller API.

 Glossary
 --------

 The reset controller API uses these terms with a specific meaning:

 Reset line

     Physical reset line carrying a reset signal from a reset controller
     hardware unit to a peripheral module.

 Reset control

     Control method that determines the state of one or multiple reset lines.
     Most commonly this is a single bit in reset controller register space that
     either allows direct control over the physical state of the reset line, or
     is self-clearing and can be used to trigger a predetermined pulse on the
     reset line.
     In more complicated reset controls, a single trigger action can launch a
     carefully timed sequence of pulses on multiple reset lines.

 Reset controller

     A hardware module that provides a number of reset controls to control a
     number of reset lines.

 Reset consumer

     Peripheral module or external IC that is put into reset by the signal on a
     reset line.

 Consumer driver interface
 =========================

 This interface provides an API that is similar to the kernel clock framework.
 Consumer drivers use get and put operations to acquire and release reset
 controls.
 Functions are provided to assert and deassert the controlled reset lines,
 trigger reset pulses, or to query reset line status.

 When requesting reset controls, consumers can use symbolic names for their
 reset inputs, which are mapped to an actual reset control on an existing reset
 controller device by the core.

 A stub version of this API is provided when the reset controller framework is
 not in use in order to minimize the need to use ifdefs.

 Shared and exclusive resets
 ---------------------------

 The reset controller API provides either reference counted deassertion and
 assertion or direct, exclusive control.
 The distinction between shared and exclusive reset controls is made at the time
 the reset control is requested, either via devm_reset_control_get_shared() or
 via devm_reset_control_get_exclusive().
 This choice determines the behavior of the API calls made with the reset
 control.

 Shared resets behave similarly to clocks in the kernel clock framework.
 They provide reference counted deassertion, where only the first deassert,
 which increments the deassertion reference count to one, and the last assert
 which decrements the deassertion reference count back to zero, have a physical
 effect on the reset line.

 Exclusive resets on the other hand guarantee direct control.
 That is, an assert causes the reset line to be asserted immediately, and a
 deassert causes the reset line to be deasserted immediately.

 Assertion and deassertion
 -------------------------

 Consumer drivers use the reset_control_assert() and reset_control_deassert()
 functions to assert and deassert reset lines.
 For shared reset controls, calls to the two functions must be balanced.

 Note that since multiple consumers may be using a shared reset control, there
 is no guarantee that calling reset_control_assert() on a shared reset control
 will actually cause the reset line to be asserted.
 Consumer drivers using shared reset controls should assume that the reset line
 may be kept deasserted at all times.
 The API only guarantees that the reset line can not be asserted as long as any
 consumer has requested it to be deasserted.

 Triggering
 ----------

 Consumer drivers use reset_control_reset() to trigger a reset pulse on a
 self-deasserting reset control.
 In general, these resets can not be shared between multiple consumers, since
 requesting a pulse from any consumer driver will reset all connected
 peripherals.

 The reset controller API allows requesting self-deasserting reset controls as
 shared, but for those only the first trigger request causes an actual pulse to
 be issued on the reset line.
 All further calls to this function have no effect until all consumers have
 called reset_control_rearm().
 For shared reset controls, calls to the two functions must be balanced.
 This allows devices that only require an initial reset at any point before the
 driver is probed or resumed to share a pulsed reset line.

 Querying
 --------

 Only some reset controllers support querying the current status of a reset
 line, via reset_control_status().
 If supported, this function returns a positive non-zero value if the given
 reset line is asserted.
 The reset_control_status() function does not accept a
 `reset control array <#reset-control-arrays>`__ handle as its input parameter.

 Optional resets
 ---------------

 Often peripherals require a reset line on some platforms but not on others.
 For this, reset controls can be requested as optional using
 devm_reset_control_get_optional_exclusive() or
 devm_reset_control_get_optional_shared().
 These functions return a NULL pointer instead of an error when the requested
 reset control is not specified in the device tree.
 Passing a NULL pointer to the reset_control functions causes them to return
 quietly without an error.

 Reset control arrays
 --------------------

 Some drivers need to assert a bunch of reset lines in no particular order.
 devm_reset_control_array_get() returns an opaque reset control handle that can
 be used to assert, deassert, or trigger all specified reset controls at once.
 The reset control API does not guarantee the order in which the individual
 controls therein are handled.

 Reset controller driver interface
 =================================

 Drivers for reset controller modules provide the functionality necessary to
 assert or deassert reset signals, to trigger a reset pulse on a reset line, or
 to query its current state.
 All functions are optional.

 Initialization
 --------------

 Drivers fill a struct :c:type:`reset_controller_dev` and register it with
 reset_controller_register() in their probe function.
 The actual functionality is implemented in callback functions via a struct
 :c:type:`reset_control_ops`.

 API reference
 =============

 The reset controller API is documented here in two parts:
 the `reset consumer API <#reset-consumer-api>`__ and the `reset controller
 driver API <#reset-controller-driver-api>`__.

 Reset consumer API
 ------------------

 Reset consumers can control a reset line using an opaque reset control handle,
 which can be obtained from devm_reset_control_get_exclusive() or
 devm_reset_control_get_shared().
 Given the reset control, consumers can call reset_control_assert() and
 reset_control_deassert(), trigger a reset pulse using reset_control_reset(), or
 query the reset line status using reset_control_status().

 .. kernel-doc:: include/linux/reset.h
    :internal:

 .. kernel-doc:: drivers/reset/core.c
    :functions: reset_control_reset
                reset_control_assert
                reset_control_deassert
                reset_control_status
                reset_control_acquire
                reset_control_release
                reset_control_rearm
                reset_control_put
                of_reset_control_get_count
                of_reset_control_array_get
                devm_reset_control_array_get
                reset_control_get_count

 Reset controller driver API
 ---------------------------

 Reset controller drivers are supposed to implement the necessary functions in
 a static constant structure :c:type:`reset_control_ops`, allocate and fill out
 a struct :c:type:`reset_controller_dev`, and register it using
 devm_reset_controller_register().

 .. kernel-doc:: include/linux/reset-controller.h
    :internal:

 .. kernel-doc:: drivers/reset/core.c
    :functions: of_reset_simple_xlate
                reset_controller_register
                reset_controller_unregister
                devm_reset_controller_register
                reset_controller_add_lookup
	.. SPDX-License-Identifier: GPL-2.0-only

	====================
	Reset controller API
	====================

	Introduction
	============

	Reset controllers are central units that control the reset signals to multiple
	peripherals.
	The reset controller API is split into two parts:
	the `consumer driver interface <#consumer-driver-interface>`__ (`API reference
	<#reset-consumer-api>`__), which allows peripheral drivers to request control
	over their reset input signals, and the `reset controller driver interface
	<#reset-controller-driver-interface>`__ (`API reference
	<#reset-controller-driver-api>`__), which is used by drivers for reset
	controller devices to register their reset controls to provide them to the
	consumers.

	While some reset controller hardware units also implement system restart
	functionality, restart handlers are out of scope for the reset controller API.

	Glossary
	--------

	The reset controller API uses these terms with a specific meaning:

	Reset line

	Physical reset line carrying a reset signal from a reset controller
	hardware unit to a peripheral module.

	Reset control

	Control method that determines the state of one or multiple reset lines.
	Most commonly this is a single bit in reset controller register space that
	either allows direct control over the physical state of the reset line, or
	is self-clearing and can be used to trigger a predetermined pulse on the
	reset line.
	In more complicated reset controls, a single trigger action can launch a
	carefully timed sequence of pulses on multiple reset lines.

	Reset controller

	A hardware module that provides a number of reset controls to control a
	number of reset lines.

	Reset consumer

	Peripheral module or external IC that is put into reset by the signal on a
	reset line.

	Consumer driver interface
	=========================

	This interface provides an API that is similar to the kernel clock framework.
	Consumer drivers use get and put operations to acquire and release reset
	controls.
	Functions are provided to assert and deassert the controlled reset lines,
	trigger reset pulses, or to query reset line status.

	When requesting reset controls, consumers can use symbolic names for their
	reset inputs, which are mapped to an actual reset control on an existing reset
	controller device by the core.

	A stub version of this API is provided when the reset controller framework is
	not in use in order to minimize the need to use ifdefs.

	Shared and exclusive resets
	---------------------------

	The reset controller API provides either reference counted deassertion and
	assertion or direct, exclusive control.
	The distinction between shared and exclusive reset controls is made at the time
	the reset control is requested, either via devm_reset_control_get_shared() or
	via devm_reset_control_get_exclusive().
	This choice determines the behavior of the API calls made with the reset
	control.

	Shared resets behave similarly to clocks in the kernel clock framework.
	They provide reference counted deassertion, where only the first deassert,
	which increments the deassertion reference count to one, and the last assert
	which decrements the deassertion reference count back to zero, have a physical
	effect on the reset line.

	Exclusive resets on the other hand guarantee direct control.
	That is, an assert causes the reset line to be asserted immediately, and a
	deassert causes the reset line to be deasserted immediately.

	Assertion and deassertion
	-------------------------

	Consumer drivers use the reset_control_assert() and reset_control_deassert()
	functions to assert and deassert reset lines.
	For shared reset controls, calls to the two functions must be balanced.

	Note that since multiple consumers may be using a shared reset control, there
	is no guarantee that calling reset_control_assert() on a shared reset control
	will actually cause the reset line to be asserted.
	Consumer drivers using shared reset controls should assume that the reset line
	may be kept deasserted at all times.
	The API only guarantees that the reset line can not be asserted as long as any
	consumer has requested it to be deasserted.

	Triggering
	----------

	Consumer drivers use reset_control_reset() to trigger a reset pulse on a
	self-deasserting reset control.
	In general, these resets can not be shared between multiple consumers, since
	requesting a pulse from any consumer driver will reset all connected
	peripherals.

	The reset controller API allows requesting self-deasserting reset controls as
	shared, but for those only the first trigger request causes an actual pulse to
	be issued on the reset line.
	All further calls to this function have no effect until all consumers have
	called reset_control_rearm().
	For shared reset controls, calls to the two functions must be balanced.
	This allows devices that only require an initial reset at any point before the
	driver is probed or resumed to share a pulsed reset line.

	Querying
	--------

	Only some reset controllers support querying the current status of a reset
	line, via reset_control_status().
	If supported, this function returns a positive non-zero value if the given
	reset line is asserted.
	The reset_control_status() function does not accept a
	`reset control array <#reset-control-arrays>`__ handle as its input parameter.

	Optional resets
	---------------

	Often peripherals require a reset line on some platforms but not on others.
	For this, reset controls can be requested as optional using
	devm_reset_control_get_optional_exclusive() or
	devm_reset_control_get_optional_shared().
	These functions return a NULL pointer instead of an error when the requested
	reset control is not specified in the device tree.
	Passing a NULL pointer to the reset_control functions causes them to return
	quietly without an error.

	Reset control arrays
	--------------------

	Some drivers need to assert a bunch of reset lines in no particular order.
	devm_reset_control_array_get() returns an opaque reset control handle that can
	be used to assert, deassert, or trigger all specified reset controls at once.
	The reset control API does not guarantee the order in which the individual
	controls therein are handled.

	Reset controller driver interface
	=================================

	Drivers for reset controller modules provide the functionality necessary to
	assert or deassert reset signals, to trigger a reset pulse on a reset line, or
	to query its current state.
	All functions are optional.

	Initialization
	--------------

	Drivers fill a struct :c:type:`reset_controller_dev` and register it with
	reset_controller_register() in their probe function.
	The actual functionality is implemented in callback functions via a struct
	:c:type:`reset_control_ops`.

	API reference
	=============

	The reset controller API is documented here in two parts:
	the `reset consumer API <#reset-consumer-api>`__ and the `reset controller
	driver API <#reset-controller-driver-api>`__.

	Reset consumer API
	------------------

	Reset consumers can control a reset line using an opaque reset control handle,
	which can be obtained from devm_reset_control_get_exclusive() or
	devm_reset_control_get_shared().
	Given the reset control, consumers can call reset_control_assert() and
	reset_control_deassert(), trigger a reset pulse using reset_control_reset(), or
	query the reset line status using reset_control_status().

	.. kernel-doc:: include/linux/reset.h
	:internal:

	.. kernel-doc:: drivers/reset/core.c
	:functions: reset_control_reset
	reset_control_assert
	reset_control_deassert
	reset_control_status
	reset_control_acquire
	reset_control_release
	reset_control_rearm
	reset_control_put
	of_reset_control_get_count
	of_reset_control_array_get
	devm_reset_control_array_get
	reset_control_get_count

	Reset controller driver API
	---------------------------

	Reset controller drivers are supposed to implement the necessary functions in
	a static constant structure :c:type:`reset_control_ops`, allocate and fill out
	a struct :c:type:`reset_controller_dev`, and register it using
	devm_reset_controller_register().

	.. kernel-doc:: include/linux/reset-controller.h
	:internal:

	.. kernel-doc:: drivers/reset/core.c
	:functions: of_reset_simple_xlate
	reset_controller_register
	reset_controller_unregister
	devm_reset_controller_register
	reset_controller_add_lookup