Lines Matching +full:pre +full:- +full:initialization
18 function pointers to its API functions during driver initialization. These
19 structures are placed into the RAM section in initialization level order.
57 should support an interrupt-based implementation, rather than polling, unless
60 High-level calls accessed through device-specific APIs, such as
75 up for boot-time initialization.
96 The device initialization macros populate some data structures at build time
98 split into read-only and runtime-mutable parts. At a high level we have:
100 .. code-block:: C
109 The ``config`` member is for read-only configuration data set at build time. For
115 per-instance runtime housekeeping. For example, it may contain reference counts,
118 The ``api`` struct maps generic subsystem APIs to the device-specific
119 implementations in the driver. It is typically read-only and populated at
126 Most drivers will be implementing a device-independent subsystem API.
135 .. code-block:: C
147 return DEVICE_API_GET(subsystem, dev)->do_this(dev, foo, bar);
152 DEVICE_API_GET(subsystem, dev)->do_that(dev, baz);
159 .. code-block:: C
183 ``gc-sections`` linker option will always see at least one reference to
184 them. Providing for link-time size optimizations with driver APIs in
188 Device-Specific API Extensions
194 device-specific APIs, described in a device-specific header.
196 A device-specific API definition typically looks like this:
198 .. code-block:: C
214 .. code-block:: C
227 /* supervisor-only API is globally visible */
257 Public API for device-specific extensions should be prefixed with the
271 through the use of per-instance configuration functions, since the parameters
277 .. code-block:: C
288 .. code-block:: C
298 const struct my_driver_config *config = dev->config;
302 /* Do other initialization stuff */
305 config->config_func(dev);
312 .. code-block:: C
340 Initialization Levels
347 initialization levels:
358 Used for devices that rely on the initialization of devices initialized
367 Within each initialization level you may specify a priority level, relative to
368 other devices in the same initialization level. The priority level is specified
370 initialization. The priority level must be a decimal integer literal without
376 still in pre-kernel states by using the :c:func:`k_is_pre_kernel`
379 Deferred initialization
382 Initialization of devices can also be deferred to a later time. In this case,
385 To defer a device driver initialization, add the property ``zephyr,deferred-init``
388 .. code-block:: devicetree
391 a-driver@40000000 {
393 zephyr,deferred-init;
403 same device policies for initialization level and priority apply.
405 Inspecting the initialization sequence
410 initialization functions are called sequentially according to their specified
413 Sometimes it's useful to inspect the final sequence of initialization function
415 target, for example ``west build -t initlevels``.
430 https://github.com/zephyrproject-rtos/zephyr/wiki/Naming-Conventions#return-codes
436 On some systems, the linear address of peripheral memory-mapped I/O (MMIO)
439 - The I/O ranges must be probed at runtime from the bus, such as with
441 - A memory management unit (MMU) is active, and the physical address of
448 DTS and do not need any RAM-based storage for it.
460 and ``driver_data`` structures, with initialization of the ``config_info``
464 .. code-block:: C
497 a device with no MMU or PCI-e, ``DEVICE_MMIO_MAP`` and
513 .. code-block:: C
530 ((const struct my_driver_config *)((_dev)->config))
533 ((struct my_driver_dev_data *)((_dev)->data))
563 node using the ``reg-names`` property to differentiate them, for example:
565 .. code-block:: devicetree
567 /dts-v1/;
570 a-driver@40000000 {
573 reg-names = "corge", "grault";
581 .. code-block:: C
593 Some drivers or driver-like code may not user Zephyr's device model,
600 .. code-block:: C
621 is the case with PCI-E. In this case the :c:func:`device_map` function
624 .. code-block:: C