| blob | e6855cd37e8525a8f78350be41d943379579b344 |
1 .. SPDX-License-Identifier: GPL-2.0
3 ===============================
4 The Linux kernel dpll subsystem
5 ===============================
7 DPLL
8 ====
10 PLL - Phase Locked Loop is an electronic circuit which syntonizes clock
11 signal of a device with an external clock signal. Effectively enabling
12 device to run on the same clock signal beat as provided on a PLL input.
14 DPLL - Digital Phase Locked Loop is an integrated circuit which in
15 addition to plain PLL behavior incorporates a digital phase detector
16 and may have digital divider in the loop. As a result, the frequency on
17 DPLL's input and output may be configurable.
19 Subsystem
20 =========
22 The main purpose of dpll subsystem is to provide general interface
23 to configure devices that use any kind of Digital PLL and could use
24 different sources of input signal to synchronize to, as well as
25 different types of outputs.
26 The main interface is NETLINK_GENERIC based protocol with an event
27 monitoring multicast group defined.
29 Device object
30 =============
32 Single dpll device object means single Digital PLL circuit and bunch of
33 connected pins.
34 It reports the supported modes of operation and current status to the
35 user in response to the `do` request of netlink command
36 ``DPLL_CMD_DEVICE_GET`` and list of dplls registered in the subsystem
37 with `dump` netlink request of the same command.
38 Changing the configuration of dpll device is done with `do` request of
39 netlink ``DPLL_CMD_DEVICE_SET`` command.
40 A device handle is ``DPLL_A_ID``, it shall be provided to get or set
41 configuration of particular device in the system. It can be obtained
42 with a ``DPLL_CMD_DEVICE_GET`` `dump` request or
43 a ``DPLL_CMD_DEVICE_ID_GET`` `do` request, where the one must provide
44 attributes that result in single device match.
46 Pin object
47 ==========
49 A pin is amorphic object which represents either input or output, it
50 could be internal component of the device, as well as externally
51 connected.
52 The number of pins per dpll vary, but usually multiple pins shall be
53 provided for a single dpll device.
54 Pin's properties, capabilities and status is provided to the user in
55 response to `do` request of netlink ``DPLL_CMD_PIN_GET`` command.
56 It is also possible to list all the pins that were registered in the
57 system with `dump` request of ``DPLL_CMD_PIN_GET`` command.
58 Configuration of a pin can be changed by `do` request of netlink
59 ``DPLL_CMD_PIN_SET`` command.
60 Pin handle is a ``DPLL_A_PIN_ID``, it shall be provided to get or set
61 configuration of particular pin in the system. It can be obtained with
62 ``DPLL_CMD_PIN_GET`` `dump` request or ``DPLL_CMD_PIN_ID_GET`` `do`
63 request, where user provides attributes that result in single pin match.
65 Pin selection
66 =============
68 In general, selected pin (the one which signal is driving the dpll
69 device) can be obtained from ``DPLL_A_PIN_STATE`` attribute, and only
70 one pin shall be in ``DPLL_PIN_STATE_CONNECTED`` state for any dpll
71 device.
73 Pin selection can be done either manually or automatically, depending
74 on hardware capabilities and active dpll device work mode
75 (``DPLL_A_MODE`` attribute). The consequence is that there are
76 differences for each mode in terms of available pin states, as well as
77 for the states the user can request for a dpll device.
79 In manual mode (``DPLL_MODE_MANUAL``) the user can request or receive
80 one of following pin states:
82 - ``DPLL_PIN_STATE_CONNECTED`` - the pin is used to drive dpll device
83 - ``DPLL_PIN_STATE_DISCONNECTED`` - the pin is not used to drive dpll
84 device
86 In automatic mode (``DPLL_MODE_AUTOMATIC``) the user can request or
87 receive one of following pin states:
89 - ``DPLL_PIN_STATE_SELECTABLE`` - the pin shall be considered as valid
90 input for automatic selection algorithm
91 - ``DPLL_PIN_STATE_DISCONNECTED`` - the pin shall be not considered as
92 a valid input for automatic selection algorithm
94 In automatic mode (``DPLL_MODE_AUTOMATIC``) the user can only receive
95 pin state ``DPLL_PIN_STATE_CONNECTED`` once automatic selection
96 algorithm locks a dpll device with one of the inputs.
98 Shared pins
99 ===========
101 A single pin object can be attached to multiple dpll devices.
102 Then there are two groups of configuration knobs:
104 1) Set on a pin - the configuration affects all dpll devices pin is
105 registered to (i.e., ``DPLL_A_PIN_FREQUENCY``),
106 2) Set on a pin-dpll tuple - the configuration affects only selected
107 dpll device (i.e., ``DPLL_A_PIN_PRIO``, ``DPLL_A_PIN_STATE``,
108 ``DPLL_A_PIN_DIRECTION``).
110 MUX-type pins
111 =============
113 A pin can be MUX-type, it aggregates child pins and serves as a pin
114 multiplexer. One or more pins are registered with MUX-type instead of
115 being directly registered to a dpll device.
116 Pins registered with a MUX-type pin provide user with additional nested
117 attribute ``DPLL_A_PIN_PARENT_PIN`` for each parent they were registered
118 with.
119 If a pin was registered with multiple parent pins, they behave like a
120 multiple output multiplexer. In this case output of a
121 ``DPLL_CMD_PIN_GET`` would contain multiple pin-parent nested
122 attributes with current state related to each parent, like::
124 'pin': [{{
125 'clock-id': 282574471561216,
126 'module-name': 'ice',
127 'capabilities': 4,
128 'id': 13,
129 'parent-pin': [
130 {'parent-id': 2, 'state': 'connected'},
131 {'parent-id': 3, 'state': 'disconnected'}
132 ],
133 'type': 'synce-eth-port'
134 }}]
136 Only one child pin can provide its signal to the parent MUX-type pin at
137 a time, the selection is done by requesting change of a child pin state
138 on desired parent, with the use of ``DPLL_A_PIN_PARENT`` nested
139 attribute. Example of netlink `set state on parent pin` message format:
141 ========================== =============================================
142 ``DPLL_A_PIN_ID`` child pin id
143 ``DPLL_A_PIN_PARENT_PIN`` nested attribute for requesting configuration
144 related to parent pin
145 ``DPLL_A_PIN_PARENT_ID`` parent pin id
146 ``DPLL_A_PIN_STATE`` requested pin state on parent
147 ========================== =============================================
149 Pin priority
150 ============
152 Some devices might offer a capability of automatic pin selection mode
153 (enum value ``DPLL_MODE_AUTOMATIC`` of ``DPLL_A_MODE`` attribute).
154 Usually, automatic selection is performed on the hardware level, which
155 means only pins directly connected to the dpll can be used for automatic
156 input pin selection.
157 In automatic selection mode, the user cannot manually select a input
158 pin for the device, instead the user shall provide all directly
159 connected pins with a priority ``DPLL_A_PIN_PRIO``, the device would
160 pick a highest priority valid signal and use it to control the DPLL
161 device. Example of netlink `set priority on parent pin` message format:
163 ============================ =============================================
164 ``DPLL_A_PIN_ID`` configured pin id
165 ``DPLL_A_PIN_PARENT_DEVICE`` nested attribute for requesting configuration
166 related to parent dpll device
167 ``DPLL_A_PIN_PARENT_ID`` parent dpll device id
168 ``DPLL_A_PIN_PRIO`` requested pin prio on parent dpll
169 ============================ =============================================
171 Child pin of MUX-type pin is not capable of automatic input pin selection,
172 in order to configure active input of a MUX-type pin, the user needs to
173 request desired pin state of the child pin on the parent pin,
174 as described in the ``MUX-type pins`` chapter.
176 Phase offset measurement and adjustment
177 ========================================
179 Device may provide ability to measure a phase difference between signals
180 on a pin and its parent dpll device. If pin-dpll phase offset measurement
181 is supported, it shall be provided with ``DPLL_A_PIN_PHASE_OFFSET``
182 attribute for each parent dpll device.
184 Device may also provide ability to adjust a signal phase on a pin.
185 If pin phase adjustment is supported, minimal and maximal values that pin
186 handle shall be provide to the user on ``DPLL_CMD_PIN_GET`` respond
187 with ``DPLL_A_PIN_PHASE_ADJUST_MIN`` and ``DPLL_A_PIN_PHASE_ADJUST_MAX``
188 attributes. Configured phase adjust value is provided with
189 ``DPLL_A_PIN_PHASE_ADJUST`` attribute of a pin, and value change can be
190 requested with the same attribute with ``DPLL_CMD_PIN_SET`` command.
192 =============================== ======================================
193 ``DPLL_A_PIN_ID`` configured pin id
194 ``DPLL_A_PIN_PHASE_ADJUST_MIN`` attr minimum value of phase adjustment
195 ``DPLL_A_PIN_PHASE_ADJUST_MAX`` attr maximum value of phase adjustment
196 ``DPLL_A_PIN_PHASE_ADJUST`` attr configured value of phase
197 adjustment on parent dpll device
198 ``DPLL_A_PIN_PARENT_DEVICE`` nested attribute for requesting
199 configuration on given parent dpll
200 device
201 ``DPLL_A_PIN_PARENT_ID`` parent dpll device id
202 ``DPLL_A_PIN_PHASE_OFFSET`` attr measured phase difference
203 between a pin and parent dpll device
204 =============================== ======================================
206 All phase related values are provided in pico seconds, which represents
207 time difference between signals phase. The negative value means that
208 phase of signal on pin is earlier in time than dpll's signal. Positive
209 value means that phase of signal on pin is later in time than signal of
210 a dpll.
212 Phase adjust (also min and max) values are integers, but measured phase
213 offset values are fractional with 3-digit decimal places and shell be
214 divided with ``DPLL_PIN_PHASE_OFFSET_DIVIDER`` to get integer part and
215 modulo divided to get fractional part.
217 Embedded SYNC
218 =============
220 Device may provide ability to use Embedded SYNC feature. It allows
221 to embed additional SYNC signal into the base frequency of a pin - a one
222 special pulse of base frequency signal every time SYNC signal pulse
223 happens. The user can configure the frequency of Embedded SYNC.
224 The Embedded SYNC capability is always related to a given base frequency
225 and HW capabilities. The user is provided a range of Embedded SYNC
226 frequencies supported, depending on current base frequency configured for
227 the pin.
229 ========================================= =================================
230 ``DPLL_A_PIN_ESYNC_FREQUENCY`` current Embedded SYNC frequency
231 ``DPLL_A_PIN_ESYNC_FREQUENCY_SUPPORTED`` nest available Embedded SYNC
232 frequency ranges
233 ``DPLL_A_PIN_FREQUENCY_MIN`` attr minimum value of frequency
234 ``DPLL_A_PIN_FREQUENCY_MAX`` attr maximum value of frequency
235 ``DPLL_A_PIN_ESYNC_PULSE`` pulse type of Embedded SYNC
236 ========================================= =================================
238 Configuration commands group
239 ============================
241 Configuration commands are used to get information about registered
242 dpll devices (and pins), as well as set configuration of device or pins.
243 As dpll devices must be abstracted and reflect real hardware,
244 there is no way to add new dpll device via netlink from user space and
245 each device should be registered by its driver.
247 All netlink commands require ``GENL_ADMIN_PERM``. This is to prevent
248 any spamming/DoS from unauthorized userspace applications.
250 List of netlink commands with possible attributes
251 =================================================
253 Constants identifying command types for dpll device uses a
254 ``DPLL_CMD_`` prefix and suffix according to command purpose.
255 The dpll device related attributes use a ``DPLL_A_`` prefix and
256 suffix according to attribute purpose.
258 ==================================== =================================
259 ``DPLL_CMD_DEVICE_ID_GET`` command to get device ID
260 ``DPLL_A_MODULE_NAME`` attr module name of registerer
261 ``DPLL_A_CLOCK_ID`` attr Unique Clock Identifier
262 (EUI-64), as defined by the
263 IEEE 1588 standard
264 ``DPLL_A_TYPE`` attr type of dpll device
265 ==================================== =================================
267 ==================================== =================================
268 ``DPLL_CMD_DEVICE_GET`` command to get device info or
269 dump list of available devices
270 ``DPLL_A_ID`` attr unique dpll device ID
271 ``DPLL_A_MODULE_NAME`` attr module name of registerer
272 ``DPLL_A_CLOCK_ID`` attr Unique Clock Identifier
273 (EUI-64), as defined by the
274 IEEE 1588 standard
275 ``DPLL_A_MODE`` attr selection mode
276 ``DPLL_A_MODE_SUPPORTED`` attr available selection modes
277 ``DPLL_A_LOCK_STATUS`` attr dpll device lock status
278 ``DPLL_A_TEMP`` attr device temperature info
279 ``DPLL_A_TYPE`` attr type of dpll device
280 ==================================== =================================
282 ==================================== =================================
283 ``DPLL_CMD_DEVICE_SET`` command to set dpll device config
284 ``DPLL_A_ID`` attr internal dpll device index
285 ``DPLL_A_MODE`` attr selection mode to configure
286 ==================================== =================================
288 Constants identifying command types for pins uses a
289 ``DPLL_CMD_PIN_`` prefix and suffix according to command purpose.
290 The pin related attributes use a ``DPLL_A_PIN_`` prefix and suffix
291 according to attribute purpose.
293 ==================================== =================================
294 ``DPLL_CMD_PIN_ID_GET`` command to get pin ID
295 ``DPLL_A_PIN_MODULE_NAME`` attr module name of registerer
296 ``DPLL_A_PIN_CLOCK_ID`` attr Unique Clock Identifier
297 (EUI-64), as defined by the
298 IEEE 1588 standard
299 ``DPLL_A_PIN_BOARD_LABEL`` attr pin board label provided
300 by registerer
301 ``DPLL_A_PIN_PANEL_LABEL`` attr pin panel label provided
302 by registerer
303 ``DPLL_A_PIN_PACKAGE_LABEL`` attr pin package label provided
304 by registerer
305 ``DPLL_A_PIN_TYPE`` attr type of a pin
306 ==================================== =================================
308 ==================================== ==================================
309 ``DPLL_CMD_PIN_GET`` command to get pin info or dump
310 list of available pins
311 ``DPLL_A_PIN_ID`` attr unique a pin ID
312 ``DPLL_A_PIN_MODULE_NAME`` attr module name of registerer
313 ``DPLL_A_PIN_CLOCK_ID`` attr Unique Clock Identifier
314 (EUI-64), as defined by the
315 IEEE 1588 standard
316 ``DPLL_A_PIN_BOARD_LABEL`` attr pin board label provided
317 by registerer
318 ``DPLL_A_PIN_PANEL_LABEL`` attr pin panel label provided
319 by registerer
320 ``DPLL_A_PIN_PACKAGE_LABEL`` attr pin package label provided
321 by registerer
322 ``DPLL_A_PIN_TYPE`` attr type of a pin
323 ``DPLL_A_PIN_FREQUENCY`` attr current frequency of a pin
324 ``DPLL_A_PIN_FREQUENCY_SUPPORTED`` nested attr provides supported
325 frequencies
326 ``DPLL_A_PIN_ANY_FREQUENCY_MIN`` attr minimum value of frequency
327 ``DPLL_A_PIN_ANY_FREQUENCY_MAX`` attr maximum value of frequency
328 ``DPLL_A_PIN_PHASE_ADJUST_MIN`` attr minimum value of phase
329 adjustment
330 ``DPLL_A_PIN_PHASE_ADJUST_MAX`` attr maximum value of phase
331 adjustment
332 ``DPLL_A_PIN_PHASE_ADJUST`` attr configured value of phase
333 adjustment on parent device
334 ``DPLL_A_PIN_PARENT_DEVICE`` nested attr for each parent device
335 the pin is connected with
336 ``DPLL_A_PIN_PARENT_ID`` attr parent dpll device id
337 ``DPLL_A_PIN_PRIO`` attr priority of pin on the
338 dpll device
339 ``DPLL_A_PIN_STATE`` attr state of pin on the parent
340 dpll device
341 ``DPLL_A_PIN_DIRECTION`` attr direction of a pin on the
342 parent dpll device
343 ``DPLL_A_PIN_PHASE_OFFSET`` attr measured phase difference
344 between a pin and parent dpll
345 ``DPLL_A_PIN_PARENT_PIN`` nested attr for each parent pin
346 the pin is connected with
347 ``DPLL_A_PIN_PARENT_ID`` attr parent pin id
348 ``DPLL_A_PIN_STATE`` attr state of pin on the parent
349 pin
350 ``DPLL_A_PIN_CAPABILITIES`` attr bitmask of pin capabilities
351 ==================================== ==================================
353 ==================================== =================================
354 ``DPLL_CMD_PIN_SET`` command to set pins configuration
355 ``DPLL_A_PIN_ID`` attr unique a pin ID
356 ``DPLL_A_PIN_FREQUENCY`` attr requested frequency of a pin
357 ``DPLL_A_PIN_PHASE_ADJUST`` attr requested value of phase
358 adjustment on parent device
359 ``DPLL_A_PIN_PARENT_DEVICE`` nested attr for each parent dpll
360 device configuration request
361 ``DPLL_A_PIN_PARENT_ID`` attr parent dpll device id
362 ``DPLL_A_PIN_DIRECTION`` attr requested direction of a pin
363 ``DPLL_A_PIN_PRIO`` attr requested priority of pin on
364 the dpll device
365 ``DPLL_A_PIN_STATE`` attr requested state of pin on
366 the dpll device
367 ``DPLL_A_PIN_PARENT_PIN`` nested attr for each parent pin
368 configuration request
369 ``DPLL_A_PIN_PARENT_ID`` attr parent pin id
370 ``DPLL_A_PIN_STATE`` attr requested state of pin on
371 parent pin
372 ==================================== =================================
374 Netlink dump requests
375 =====================
377 The ``DPLL_CMD_DEVICE_GET`` and ``DPLL_CMD_PIN_GET`` commands are
378 capable of dump type netlink requests, in which case the response is in
379 the same format as for their ``do`` request, but every device or pin
380 registered in the system is returned.
382 SET commands format
383 ===================
385 ``DPLL_CMD_DEVICE_SET`` - to target a dpll device, the user provides
386 ``DPLL_A_ID``, which is unique identifier of dpll device in the system,
387 as well as parameter being configured (``DPLL_A_MODE``).
389 ``DPLL_CMD_PIN_SET`` - to target a pin user must provide a
390 ``DPLL_A_PIN_ID``, which is unique identifier of a pin in the system.
391 Also configured pin parameters must be added.
392 If ``DPLL_A_PIN_FREQUENCY`` is configured, this affects all the dpll
393 devices that are connected with the pin, that is why frequency attribute
394 shall not be enclosed in ``DPLL_A_PIN_PARENT_DEVICE``.
395 Other attributes: ``DPLL_A_PIN_PRIO``, ``DPLL_A_PIN_STATE`` or
396 ``DPLL_A_PIN_DIRECTION`` must be enclosed in
397 ``DPLL_A_PIN_PARENT_DEVICE`` as their configuration relates to only one
398 of parent dplls, targeted by ``DPLL_A_PIN_PARENT_ID`` attribute which is
399 also required inside that nest.
400 For MUX-type pins the ``DPLL_A_PIN_STATE`` attribute is configured in
401 similar way, by enclosing required state in ``DPLL_A_PIN_PARENT_PIN``
402 nested attribute and targeted parent pin id in ``DPLL_A_PIN_PARENT_ID``.
404 In general, it is possible to configure multiple parameters at once, but
405 internally each parameter change will be invoked separately, where order
406 of configuration is not guaranteed by any means.
408 Configuration pre-defined enums
409 ===============================
411 .. kernel-doc:: include/uapi/linux/dpll.h
413 Notifications
414 =============
416 dpll device can provide notifications regarding status changes of the
417 device, i.e. lock status changes, input/output changes or other alarms.
418 There is one multicast group that is used to notify user-space apps via
419 netlink socket: ``DPLL_MCGRP_MONITOR``
421 Notifications messages:
423 ============================== =====================================
424 ``DPLL_CMD_DEVICE_CREATE_NTF`` dpll device was created
425 ``DPLL_CMD_DEVICE_DELETE_NTF`` dpll device was deleted
426 ``DPLL_CMD_DEVICE_CHANGE_NTF`` dpll device has changed
427 ``DPLL_CMD_PIN_CREATE_NTF`` dpll pin was created
428 ``DPLL_CMD_PIN_DELETE_NTF`` dpll pin was deleted
429 ``DPLL_CMD_PIN_CHANGE_NTF`` dpll pin has changed
430 ============================== =====================================
432 Events format is the same as for the corresponding get command.
433 Format of ``DPLL_CMD_DEVICE_`` events is the same as response of
434 ``DPLL_CMD_DEVICE_GET``.
435 Format of ``DPLL_CMD_PIN_`` events is same as response of
436 ``DPLL_CMD_PIN_GET``.
438 Device driver implementation
439 ============================
441 Device is allocated by dpll_device_get() call. Second call with the
442 same arguments will not create new object but provides pointer to
443 previously created device for given arguments, it also increases
444 refcount of that object.
445 Device is deallocated by dpll_device_put() call, which first
446 decreases the refcount, once refcount is cleared the object is
447 destroyed.
449 Device should implement set of operations and register device via
450 dpll_device_register() at which point it becomes available to the
451 users. Multiple driver instances can obtain reference to it with
452 dpll_device_get(), as well as register dpll device with their own
453 ops and priv.
455 The pins are allocated separately with dpll_pin_get(), it works
456 similarly to dpll_device_get(). Function first creates object and then
457 for each call with the same arguments only the object refcount
458 increases. Also dpll_pin_put() works similarly to dpll_device_put().
460 A pin can be registered with parent dpll device or parent pin, depending
461 on hardware needs. Each registration requires registerer to provide set
462 of pin callbacks, and private data pointer for calling them:
464 - dpll_pin_register() - register pin with a dpll device,
465 - dpll_pin_on_pin_register() - register pin with another MUX type pin.
467 Notifications of adding or removing dpll devices are created within
468 subsystem itself.
469 Notifications about registering/deregistering pins are also invoked by
470 the subsystem.
471 Notifications about status changes either of dpll device or a pin are
472 invoked in two ways:
474 - after successful change was requested on dpll subsystem, the subsystem
475 calls corresponding notification,
476 - requested by device driver with dpll_device_change_ntf() or
477 dpll_pin_change_ntf() when driver informs about the status change.
479 The device driver using dpll interface is not required to implement all
480 the callback operation. Nevertheless, there are few required to be
481 implemented.
482 Required dpll device level callback operations:
484 - ``.mode_get``,
485 - ``.lock_status_get``.
487 Required pin level callback operations:
489 - ``.state_on_dpll_get`` (pins registered with dpll device),
490 - ``.state_on_pin_get`` (pins registered with parent pin),
491 - ``.direction_get``.
493 Every other operation handler is checked for existence and
494 ``-EOPNOTSUPP`` is returned in case of absence of specific handler.
496 The simplest implementation is in the OCP TimeCard driver. The ops
497 structures are defined like this:
499 .. code-block:: c
501 static const struct dpll_device_ops dpll_ops = {
502 .lock_status_get = ptp_ocp_dpll_lock_status_get,
503 .mode_get = ptp_ocp_dpll_mode_get,
504 .mode_supported = ptp_ocp_dpll_mode_supported,
505 };
507 static const struct dpll_pin_ops dpll_pins_ops = {
508 .frequency_get = ptp_ocp_dpll_frequency_get,
509 .frequency_set = ptp_ocp_dpll_frequency_set,
510 .direction_get = ptp_ocp_dpll_direction_get,
511 .direction_set = ptp_ocp_dpll_direction_set,
512 .state_on_dpll_get = ptp_ocp_dpll_state_get,
513 };
515 The registration part is then looks like this part:
517 .. code-block:: c
519 clkid = pci_get_dsn(pdev);
520 bp->dpll = dpll_device_get(clkid, 0, THIS_MODULE);
521 if (IS_ERR(bp->dpll)) {
522 err = PTR_ERR(bp->dpll);
523 dev_err(&pdev->dev, "dpll_device_alloc failed\n");
524 goto out;
525 }
527 err = dpll_device_register(bp->dpll, DPLL_TYPE_PPS, &dpll_ops, bp);
528 if (err)
529 goto out;
531 for (i = 0; i < OCP_SMA_NUM; i++) {
532 bp->sma[i].dpll_pin = dpll_pin_get(clkid, i, THIS_MODULE, &bp->sma[i].dpll_prop);
533 if (IS_ERR(bp->sma[i].dpll_pin)) {
534 err = PTR_ERR(bp->dpll);
535 goto out_dpll;
536 }
538 err = dpll_pin_register(bp->dpll, bp->sma[i].dpll_pin, &dpll_pins_ops,
539 &bp->sma[i]);
540 if (err) {
541 dpll_pin_put(bp->sma[i].dpll_pin);
542 goto out_dpll;
543 }
544 }
546 In the error path we have to rewind every allocation in the reverse order:
548 .. code-block:: c
550 while (i) {
551 --i;
552 dpll_pin_unregister(bp->dpll, bp->sma[i].dpll_pin, &dpll_pins_ops, &bp->sma[i]);
553 dpll_pin_put(bp->sma[i].dpll_pin);
554 }
555 dpll_device_put(bp->dpll);
557 More complex example can be found in Intel's ICE driver or nVidia's mlx5 driver.
559 SyncE enablement
560 ================
561 For SyncE enablement it is required to allow control over dpll device
562 for a software application which monitors and configures the inputs of
563 dpll device in response to current state of a dpll device and its
564 inputs.
565 In such scenario, dpll device input signal shall be also configurable
566 to drive dpll with signal recovered from the PHY netdevice.
567 This is done by exposing a pin to the netdevice - attaching pin to the
568 netdevice itself with
569 ``dpll_netdev_pin_set(struct net_device *dev, struct dpll_pin *dpll_pin)``.
570 Exposed pin id handle ``DPLL_A_PIN_ID`` is then identifiable by the user
571 as it is attached to rtnetlink respond to get ``RTM_NEWLINK`` command in
572 nested attribute ``IFLA_DPLL_PIN``.