Commit | Line | Data |
---|---|---|
e7065e20 | 1 | Kernel driver i2c-gpio-mux |
92ed1a76 PK |
2 | |
3 | Author: Peter Korsgaard <peter.korsgaard@barco.com> | |
4 | ||
5 | Description | |
6 | ----------- | |
7 | ||
e7065e20 | 8 | i2c-gpio-mux is an i2c mux driver providing access to I2C bus segments |
92ed1a76 PK |
9 | from a master I2C bus and a hardware MUX controlled through GPIO pins. |
10 | ||
11 | E.G.: | |
12 | ||
13 | ---------- ---------- Bus segment 1 - - - - - | |
14 | | | SCL/SDA | |-------------- | | | |
15 | | |------------| | | |
16 | | | | | Bus segment 2 | | | |
17 | | Linux | GPIO 1..N | MUX |--------------- Devices | |
18 | | |------------| | | | | |
19 | | | | | Bus segment M | |
20 | | | | |---------------| | | |
21 | ---------- ---------- - - - - - | |
22 | ||
23 | SCL/SDA of the master I2C bus is multiplexed to bus segment 1..M | |
24 | according to the settings of the GPIO pins 1..N. | |
25 | ||
26 | Usage | |
27 | ----- | |
28 | ||
e7065e20 | 29 | i2c-gpio-mux uses the platform bus, so you need to provide a struct |
92ed1a76 PK |
30 | platform_device with the platform_data pointing to a struct |
31 | gpio_i2cmux_platform_data with the I2C adapter number of the master | |
32 | bus, the number of bus segments to create and the GPIO pins used | |
e7065e20 | 33 | to control it. See include/linux/i2c-gpio-mux.h for details. |
92ed1a76 PK |
34 | |
35 | E.G. something like this for a MUX providing 4 bus segments | |
36 | controlled through 3 GPIO pins: | |
37 | ||
e7065e20 | 38 | #include <linux/i2c-gpio-mux.h> |
92ed1a76 PK |
39 | #include <linux/platform_device.h> |
40 | ||
41 | static const unsigned myboard_gpiomux_gpios[] = { | |
42 | AT91_PIN_PC26, AT91_PIN_PC25, AT91_PIN_PC24 | |
43 | }; | |
44 | ||
45 | static const unsigned myboard_gpiomux_values[] = { | |
46 | 0, 1, 2, 3 | |
47 | }; | |
48 | ||
49 | static struct gpio_i2cmux_platform_data myboard_i2cmux_data = { | |
50 | .parent = 1, | |
51 | .base_nr = 2, /* optional */ | |
52 | .values = myboard_gpiomux_values, | |
53 | .n_values = ARRAY_SIZE(myboard_gpiomux_values), | |
54 | .gpios = myboard_gpiomux_gpios, | |
55 | .n_gpios = ARRAY_SIZE(myboard_gpiomux_gpios), | |
56 | .idle = 4, /* optional */ | |
57 | }; | |
58 | ||
59 | static struct platform_device myboard_i2cmux = { | |
e7065e20 | 60 | .name = "i2c-gpio-mux", |
92ed1a76 PK |
61 | .id = 0, |
62 | .dev = { | |
63 | .platform_data = &myboard_i2cmux_data, | |
64 | }, | |
65 | }; | |
600a711c JD |
66 | |
67 | If you don't know the absolute GPIO pin numbers at registration time, | |
68 | you can instead provide a chip name (.chip_name) and relative GPIO pin | |
69 | numbers, and the i2c-gpio-mux driver will do the work for you, | |
70 | including deferred probing if the GPIO chip isn't immediately | |
71 | available. | |
72 | ||
73 | Device Registration | |
74 | ------------------- | |
75 | ||
76 | When registering your i2c-gpio-mux device, you should pass the number | |
77 | of any GPIO pin it uses as the device ID. This guarantees that every | |
78 | instance has a different ID. | |
79 | ||
80 | Alternatively, if you don't need a stable device name, you can simply | |
81 | pass PLATFORM_DEVID_AUTO as the device ID, and the platform core will | |
82 | assign a dynamic ID to your device. If you do not know the absolute | |
83 | GPIO pin numbers at registration time, this is even the only option. |