Lines Matching +full:operations +full:- +full:per +full:- +full:run
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
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
193 standard API. These devices combine subsystem operations with
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
354 so it's OK to set up interrupts. Init functions at this level run on the
361 available. Init functions at this level run on the interrupt stack.
365 Init functions at this level run in context of the kernel main task.
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;
400 In some cases you may just need to run a function at boot. For such cases, the
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