Lines Matching refs:device

32 separate structures to keep track of device status. This can be done
33 at build time, for example, by creating arrays of device descriptors
43 create arrays of device descriptors corresponding to the devicetree
47 controller and the I3C bus inside the device driver
50 #. Initialize the data structure of the I3C controller device
51    driver instance. The usual device defining macros such as
56      structures to aid in address assignments and device list management.
61    * Initialize the device descriptors if needed by the controller
87    #. Do ``SETDASA`` to assign a dynamic address using the static address of the device
94         the relevant fields in the I3C target device descriptor
100       * If there is a device waiting for address, it will send
108           * Also, set the BCR and DCR fields in the device descriptor
112           assigned a free address, or the device driver can stop
115           * Note that the I3C API requires device descriptor to
116             function. A device without a device descriptor cannot be
131         basic device information such as BCR, DCR, MRL and MWL.
137         enabling IBI of a device.
142 If a target device can generate In-Band Interrupt (IBI),
145 * :c:func:`i3c_ibi_enable` to enable IBI of a target device.
149     from a particular target device.
158     to enable interrupt of this target device.
160 * :c:func:`i3c_ibi_disable` to disable IBI of a target device.
163     description of the target device from the slots.
166     to disable interrupt of this target device.
171 Here is an example for defining a I3C controller in device tree:
215 * The first one is the static address of the device.
221     this will be the address of the device after SETDASA
236 required for properly generating device tree macros.
241 For I\ :sup:`2`\ C devices where the device driver has support for
242 working under I3C bus, the device node can be described as
243 a child of the I3C controller. If the device driver is written to
249 * The first one is the static address of the device. This must be
256     the device tree entry corresponds to a I\ :sup:`2`\ C device.
262   * bit[7:5] are the I\ :sup:`2`\ C device index:
266       * I3C device has a 50 ns spike filter where it is not
271       * I\ :sup:`2`\ C device does not have a 50 ns spike filter but
276       * I3C device does not have a 50 ns spike filter and
293 the use of device descriptors, :c:struct:`i3c_device_desc`.
294 This struct contains runtime information about a I3C device,
296 the device driver of a I3C device should grab a pointer to
297 this device descriptor from the controller using
308 device driver implements the I2C API. This has the advantage of using
309 existing I2C devices without any modifications to their device drivers.
310 However, since the I3C controller API works on device descriptors,
311 any calls to I2C API will need to look up the corresponding device
312 descriptor from the I2C device address. This adds a bit of processing
315 On the other hand, a device driver can be extended to utilize native
316 I2C device support via the I3C controller API. During device
318 retrieve the pointer to the device descriptor. This pointer can be used
322 the I2C device must be declared according to I3C standard:
324 The I\ :sup:`2`\ C virtual controller device driver provides a way to
326 device drivers can be used as-is without modifications. This requires
327 adding an intermediate node in the device tree: