Lines Matching +full:baz +full:- +full:names
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.
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
138 typedef void (*subsystem_do_that_t)(const struct device *dev, void *baz);
147 return DEVICE_API_GET(subsystem, dev)->do_this(dev, foo, bar);
150 static inline void subsystem_do_that(const struct device *dev, void *baz)
152 DEVICE_API_GET(subsystem, dev)->do_that(dev, baz);
159 .. code-block:: C
166 static void my_driver_do_that(const struct device *dev, void *baz)
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;
305 config->config_func(dev);
312 .. code-block:: C
376 still in pre-kernel states by using the :c:func:`k_is_pre_kernel`
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;
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.
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