Lines Matching +full:driver +full:- +full:bar
3 Device Driver Model
9 driver is available depends on the board and the driver.
15 Each type of driver (e.g. UART, SPI, I2C) is supported by a generic type API.
17 In this model the driver fills in the pointer to the structure containing the
18 function pointers to its API functions during driver initialization. These
24 :alt: Device Driver Model
32 * **Interrupt controller**: This device driver is used by the kernel's
35 * **Timer**: This device driver is used by the kernel's system clock and
38 * **Serial communication**: This device driver is used by the kernel's
41 * **Entropy**: This device driver provides a source of entropy numbers
56 Zephyr provides a set of device drivers for multiple boards. Each driver
57 should support an interrupt-based implementation, rather than polling, unless
60 High-level calls accessed through device-specific APIs, such as
66 Driver APIs
75 up for boot-time initialization.
89 Wrap a driver API declaration to assign it to its respective linker section.
93 Driver Data Structures
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
114 The ``data`` struct is kept in RAM, and is used by the driver 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.
128 code is not specific to any particular driver implementation.
130 If all driver API instances are assigned to their respective API linker section
135 .. code-block:: C
137 typedef int (*subsystem_do_this_t)(const struct device *dev, int foo, int bar);
145 static inline int subsystem_do_this(const struct device *dev, int foo, int bar)
147 return DEVICE_API_GET(subsystem, dev)->do_this(dev, foo, bar);
152 DEVICE_API_GET(subsystem, dev)->do_that(dev, baz);
155 A driver implementing a particular subsystem will define the real implementation
159 .. code-block:: C
161 static int my_driver_do_this(const struct device *dev, int foo, int bar)
176 The driver would then pass ``my_driver_api_funcs`` as the ``api`` argument to
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
191 Some devices can be cast as an instance of a driver subsystem such as GPIO,
194 device-specific APIs, described in a device-specific header.
196 A device-specific API definition typically looks like this:
198 .. code-block:: C
206 __syscall int specific_from_user(const struct device *dev, int bar);
211 A driver implementing extensions to the subsystem will define the real
214 .. code-block:: C
227 /* supervisor-only API is globally visible */
234 int z_impl_specific_from_user(const struct device *dev, int bar)
243 int z_vrfy_specific_from_user(const struct device *dev, int bar)
246 return z_impl_specific_do_that(dev, bar)
257 Public API for device-specific extensions should be prefixed with the
262 Single Driver, Multiple Instances
266 there can be multiple GPIO banks, or multiple UARTS. Each instance of the driver
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
346 function will be executed. Any driver will specify one of four
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
446 establish the mapping within the driver's init function. Other systems
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
510 a properly typed pointer to the driver's config_info or dev_data structs.
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";
579 would be in the driver config struct:
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