Lines Matching +full:on +full:- +full:device
6 level. Instead, the software must know which devices are connected on each
9 several ways to achieve this, depending on the context and requirements.
13 --------------------------------------------
16 for many embedded systems. On such systems, each I2C bus has a number which
17 is known in advance. It is thus possible to pre-declare the I2C devices
18 which live on this bus.
20 This information is provided to the kernel in a different way on different
21 architectures: device tree, ACPI or board files.
24 instantiated automatically by i2c-core. The devices will be automatically
25 unbound and destroyed when the I2C bus they sit on goes away (if ever).
31 On platforms using devicetree, the declaration of I2C devices is done in
36 .. code-block:: dts
40 clock-frequency = <100000>;
49 gpio-controller;
50 #gpio-cells = <2>;
56 additional properties which might be needed to set up the device, please refer
64 which is currently located at Documentation/firmware-guide/acpi/enumeration.rst.
71 description based on board files, but the latter are still used in old
78 .. code-block:: c
85 { /* EEPROM on mainboard */
89 { /* EEPROM on cpu card */
103 The above code declares 3 devices on I2C bus 1, including their respective
108 --------------------------------------------
110 This method is appropriate when a larger device uses an I2C bus for
120 .. code-block:: c
129 efx->board_info.hwmon_client =
130 i2c_new_client_device(&efx->i2c_adap, &sfe4001_hwmon_info);
135 The above code instantiates 1 I2C device on the I2C bus which is on the
138 A variant of this is when you don't know for sure if an I2C device is
140 on cheap variants of a board but you have no way to tell them apart), or
147 .. code-block:: c
167 The above code instantiates up to 1 I2C device on the I2C bus which is on
172 The driver which instantiated the I2C device is responsible for destroying
173 it on cleanup. This is done by calling i2c_unregister_device() on the
179 ----------------------------------------------
181 Sometimes you do not have enough information about an I2C device, not even
183 chips on PC mainboards. There are several dozen models, which can live
187 manufacturer and device ID registers, so they can be identified by
191 explicitly. Instead, i2c-core will probe for such devices as soon as their
192 drivers are loaded, and if any is found, an I2C device will be
196 * The I2C device driver must implement the detect() method, which
197 identifies a supported device by reading from arbitrary registers.
198 * Only buses which are likely to have a supported device and agree to be
200 monitoring chips on a TV adapter.
224 Once again, method 3 should be avoided wherever possible. Explicit device
229 Method 4: Instantiate from user-space
230 -------------------------------------
238 instantiate, respectively delete, an I2C device.
240 File ``new_device`` takes 2 parameters: the name of the I2C device (a
241 string) and the address of the I2C device (a number, typically expressed
245 device. As no two devices can live at the same address on a given I2C
246 segment, the address is sufficient to uniquely identify the device to be
251 # echo eeprom 0x50 > /sys/bus/i2c/devices/i2c-3/new_device
253 While this interface should only be used when in-kernel device declaration
257 segment your device lives on doesn't have the proper class bit set and
259 * The I2C driver usually detects devices, but your device lives at an
261 * The I2C driver usually detects devices, but your device is not detected,
263 device is not officially supported yet but you know it is compatible.
264 * You are developing a driver on a test board, where you soldered the I2C
265 device yourself.
268 drivers implement. Being implemented in i2c-core rather than in each
269 device driver individually, it is much more efficient, and also has the
271 You can also instantiate the device before the driver is loaded or even
272 available, and you don't need to know what driver the device needs.