1.. SPDX-License-Identifier: GPL-2.0-only
2
3====================
4Reset controller API
5====================
6
7Introduction
8============
9
10Reset controllers are central units that control the reset signals to multiple
11peripherals.
12The reset controller API is split into two parts:
13the `consumer driver interface <#consumer-driver-interface>`__ (`API reference
14<#reset-consumer-api>`__), which allows peripheral drivers to request control
15over their reset input signals, and the `reset controller driver interface
16<#reset-controller-driver-interface>`__ (`API reference
17<#reset-controller-driver-api>`__), which is used by drivers for reset
18controller devices to register their reset controls to provide them to the
19consumers.
20
21While some reset controller hardware units also implement system restart
22functionality, restart handlers are out of scope for the reset controller API.
23
24Glossary
25--------
26
27The reset controller API uses these terms with a specific meaning:
28
29Reset line
30
31    Physical reset line carrying a reset signal from a reset controller
32    hardware unit to a peripheral module.
33
34Reset control
35
36    Control method that determines the state of one or multiple reset lines.
37    Most commonly this is a single bit in reset controller register space that
38    either allows direct control over the physical state of the reset line, or
39    is self-clearing and can be used to trigger a predetermined pulse on the
40    reset line.
41    In more complicated reset controls, a single trigger action can launch a
42    carefully timed sequence of pulses on multiple reset lines.
43
44Reset controller
45
46    A hardware module that provides a number of reset controls to control a
47    number of reset lines.
48
49Reset consumer
50
51    Peripheral module or external IC that is put into reset by the signal on a
52    reset line.
53
54Consumer driver interface
55=========================
56
57This interface provides an API that is similar to the kernel clock framework.
58Consumer drivers use get and put operations to acquire and release reset
59controls.
60Functions are provided to assert and deassert the controlled reset lines,
61trigger reset pulses, or to query reset line status.
62
63When requesting reset controls, consumers can use symbolic names for their
64reset inputs, which are mapped to an actual reset control on an existing reset
65controller device by the core.
66
67A stub version of this API is provided when the reset controller framework is
68not in use in order to minimize the need to use ifdefs.
69
70Shared and exclusive resets
71---------------------------
72
73The reset controller API provides either reference counted deassertion and
74assertion or direct, exclusive control.
75The distinction between shared and exclusive reset controls is made at the time
76the reset control is requested, either via devm_reset_control_get_shared() or
77via devm_reset_control_get_exclusive().
78This choice determines the behavior of the API calls made with the reset
79control.
80
81Shared resets behave similarly to clocks in the kernel clock framework.
82They provide reference counted deassertion, where only the first deassert,
83which increments the deassertion reference count to one, and the last assert
84which decrements the deassertion reference count back to zero, have a physical
85effect on the reset line.
86
87Exclusive resets on the other hand guarantee direct control.
88That is, an assert causes the reset line to be asserted immediately, and a
89deassert causes the reset line to be deasserted immediately.
90
91Assertion and deassertion
92-------------------------
93
94Consumer drivers use the reset_control_assert() and reset_control_deassert()
95functions to assert and deassert reset lines.
96For shared reset controls, calls to the two functions must be balanced.
97
98Note that since multiple consumers may be using a shared reset control, there
99is no guarantee that calling reset_control_assert() on a shared reset control
100will actually cause the reset line to be asserted.
101Consumer drivers using shared reset controls should assume that the reset line
102may be kept deasserted at all times.
103The API only guarantees that the reset line can not be asserted as long as any
104consumer has requested it to be deasserted.
105
106Triggering
107----------
108
109Consumer drivers use reset_control_reset() to trigger a reset pulse on a
110self-deasserting reset control.
111In general, these resets can not be shared between multiple consumers, since
112requesting a pulse from any consumer driver will reset all connected
113peripherals.
114
115The reset controller API allows requesting self-deasserting reset controls as
116shared, but for those only the first trigger request causes an actual pulse to
117be issued on the reset line.
118All further calls to this function have no effect until all consumers have
119called reset_control_rearm().
120For shared reset controls, calls to the two functions must be balanced.
121This allows devices that only require an initial reset at any point before the
122driver is probed or resumed to share a pulsed reset line.
123
124Querying
125--------
126
127Only some reset controllers support querying the current status of a reset
128line, via reset_control_status().
129If supported, this function returns a positive non-zero value if the given
130reset line is asserted.
131The reset_control_status() function does not accept a
132`reset control array <#reset-control-arrays>`__ handle as its input parameter.
133
134Optional resets
135---------------
136
137Often peripherals require a reset line on some platforms but not on others.
138For this, reset controls can be requested as optional using
139devm_reset_control_get_optional_exclusive() or
140devm_reset_control_get_optional_shared().
141These functions return a NULL pointer instead of an error when the requested
142reset control is not specified in the device tree.
143Passing a NULL pointer to the reset_control functions causes them to return
144quietly without an error.
145
146Reset control arrays
147--------------------
148
149Some drivers need to assert a bunch of reset lines in no particular order.
150devm_reset_control_array_get() returns an opaque reset control handle that can
151be used to assert, deassert, or trigger all specified reset controls at once.
152The reset control API does not guarantee the order in which the individual
153controls therein are handled.
154
155Reset controller driver interface
156=================================
157
158Drivers for reset controller modules provide the functionality necessary to
159assert or deassert reset signals, to trigger a reset pulse on a reset line, or
160to query its current state.
161All functions are optional.
162
163Initialization
164--------------
165
166Drivers fill a struct :c:type:`reset_controller_dev` and register it with
167reset_controller_register() in their probe function.
168The actual functionality is implemented in callback functions via a struct
169:c:type:`reset_control_ops`.
170
171API reference
172=============
173
174The reset controller API is documented here in two parts:
175the `reset consumer API <#reset-consumer-api>`__ and the `reset controller
176driver API <#reset-controller-driver-api>`__.
177
178Reset consumer API
179------------------
180
181Reset consumers can control a reset line using an opaque reset control handle,
182which can be obtained from devm_reset_control_get_exclusive() or
183devm_reset_control_get_shared().
184Given the reset control, consumers can call reset_control_assert() and
185reset_control_deassert(), trigger a reset pulse using reset_control_reset(), or
186query the reset line status using reset_control_status().
187
188.. kernel-doc:: include/linux/reset.h
189   :internal:
190
191.. kernel-doc:: drivers/reset/core.c
192   :functions: reset_control_reset
193               reset_control_assert
194               reset_control_deassert
195               reset_control_status
196               reset_control_acquire
197               reset_control_release
198               reset_control_rearm
199               reset_control_put
200               of_reset_control_get_count
201               of_reset_control_array_get
202               devm_reset_control_array_get
203               reset_control_get_count
204
205Reset controller driver API
206---------------------------
207
208Reset controller drivers are supposed to implement the necessary functions in
209a static constant structure :c:type:`reset_control_ops`, allocate and fill out
210a struct :c:type:`reset_controller_dev`, and register it using
211devm_reset_controller_register().
212
213.. kernel-doc:: include/linux/reset-controller.h
214   :internal:
215
216.. kernel-doc:: drivers/reset/core.c
217   :functions: of_reset_simple_xlate
218               reset_controller_register
219               reset_controller_unregister
220               devm_reset_controller_register
221               reset_controller_add_lookup
222