]>
Commit | Line | Data |
---|---|---|
1da177e4 LT |
1 | INTRODUCTION |
2 | ------------ | |
3 | ||
4 | Because not every I2C or SMBus adapter implements everything in the | |
5 | I2C specifications, a client can not trust that everything it needs | |
6 | is implemented when it is given the option to attach to an adapter: | |
7 | the client needs some way to check whether an adapter has the needed | |
8 | functionality. | |
9 | ||
10 | ||
11 | FUNCTIONALITY CONSTANTS | |
12 | ----------------------- | |
13 | ||
14 | For the most up-to-date list of functionality constants, please check | |
15 | <linux/i2c.h>! | |
16 | ||
17 | I2C_FUNC_I2C Plain i2c-level commands (Pure SMBus | |
18 | adapters typically can not do these) | |
19 | I2C_FUNC_10BIT_ADDR Handles the 10-bit address extensions | |
d057c96c HI |
20 | I2C_FUNC_PROTOCOL_MANGLING Knows about the I2C_M_IGNORE_NAK, |
21 | I2C_M_REV_DIR_ADDR, I2C_M_NOSTART and | |
22 | I2C_M_NO_RD_ACK flags (which modify the | |
23 | I2C protocol!) | |
1da177e4 LT |
24 | I2C_FUNC_SMBUS_QUICK Handles the SMBus write_quick command |
25 | I2C_FUNC_SMBUS_READ_BYTE Handles the SMBus read_byte command | |
26 | I2C_FUNC_SMBUS_WRITE_BYTE Handles the SMBus write_byte command | |
27 | I2C_FUNC_SMBUS_READ_BYTE_DATA Handles the SMBus read_byte_data command | |
28 | I2C_FUNC_SMBUS_WRITE_BYTE_DATA Handles the SMBus write_byte_data command | |
29 | I2C_FUNC_SMBUS_READ_WORD_DATA Handles the SMBus read_word_data command | |
30 | I2C_FUNC_SMBUS_WRITE_WORD_DATA Handles the SMBus write_byte_data command | |
31 | I2C_FUNC_SMBUS_PROC_CALL Handles the SMBus process_call command | |
32 | I2C_FUNC_SMBUS_READ_BLOCK_DATA Handles the SMBus read_block_data command | |
33 | I2C_FUNC_SMBUS_WRITE_BLOCK_DATA Handles the SMBus write_block_data command | |
34 | I2C_FUNC_SMBUS_READ_I2C_BLOCK Handles the SMBus read_i2c_block_data command | |
35 | I2C_FUNC_SMBUS_WRITE_I2C_BLOCK Handles the SMBus write_i2c_block_data command | |
36 | ||
37 | A few combinations of the above flags are also defined for your convenience: | |
38 | ||
39 | I2C_FUNC_SMBUS_BYTE Handles the SMBus read_byte | |
40 | and write_byte commands | |
41 | I2C_FUNC_SMBUS_BYTE_DATA Handles the SMBus read_byte_data | |
42 | and write_byte_data commands | |
43 | I2C_FUNC_SMBUS_WORD_DATA Handles the SMBus read_word_data | |
44 | and write_word_data commands | |
45 | I2C_FUNC_SMBUS_BLOCK_DATA Handles the SMBus read_block_data | |
46 | and write_block_data commands | |
47 | I2C_FUNC_SMBUS_I2C_BLOCK Handles the SMBus read_i2c_block_data | |
48 | and write_i2c_block_data commands | |
49 | I2C_FUNC_SMBUS_EMUL Handles all SMBus commands than can be | |
50 | emulated by a real I2C adapter (using | |
51 | the transparent emulation layer) | |
52 | ||
53 | ||
54 | ALGORITHM/ADAPTER IMPLEMENTATION | |
55 | -------------------------------- | |
56 | ||
57 | When you write a new algorithm driver, you will have to implement a | |
58 | function callback `functionality', that gets an i2c_adapter structure | |
59 | pointer as its only parameter: | |
60 | ||
61 | struct i2c_algorithm { | |
62 | /* Many other things of course; check <linux/i2c.h>! */ | |
63 | u32 (*functionality) (struct i2c_adapter *); | |
64 | } | |
65 | ||
66 | A typically implementation is given below, from i2c-algo-bit.c: | |
67 | ||
68 | static u32 bit_func(struct i2c_adapter *adap) | |
69 | { | |
70 | return I2C_FUNC_SMBUS_EMUL | I2C_FUNC_10BIT_ADDR | | |
71 | I2C_FUNC_PROTOCOL_MANGLING; | |
72 | } | |
73 | ||
74 | ||
75 | ||
76 | CLIENT CHECKING | |
77 | --------------- | |
78 | ||
79 | Before a client tries to attach to an adapter, or even do tests to check | |
80 | whether one of the devices it supports is present on an adapter, it should | |
81 | check whether the needed functionality is present. There are two functions | |
82 | defined which should be used instead of calling the functionality hook | |
83 | in the algorithm structure directly: | |
84 | ||
85 | /* Return the functionality mask */ | |
86 | extern u32 i2c_get_functionality (struct i2c_adapter *adap); | |
87 | ||
88 | /* Return 1 if adapter supports everything we need, 0 if not. */ | |
89 | extern int i2c_check_functionality (struct i2c_adapter *adap, u32 func); | |
90 | ||
91 | This is a typical way to use these functions (from the writing-clients | |
92 | document): | |
93 | int foo_detect_client(struct i2c_adapter *adapter, int address, | |
94 | unsigned short flags, int kind) | |
95 | { | |
96 | /* Define needed variables */ | |
97 | ||
98 | /* As the very first action, we check whether the adapter has the | |
99 | needed functionality: we need the SMBus read_word_data, | |
100 | write_word_data and write_byte functions in this example. */ | |
101 | if (!i2c_check_functionality(adapter,I2C_FUNC_SMBUS_WORD_DATA | | |
102 | I2C_FUNC_SMBUS_WRITE_BYTE)) | |
103 | goto ERROR0; | |
104 | ||
105 | /* Now we can do the real detection */ | |
106 | ||
107 | ERROR0: | |
108 | /* Return an error */ | |
109 | } | |
110 | ||
111 | ||
112 | ||
113 | CHECKING THROUGH /DEV | |
114 | --------------------- | |
115 | ||
116 | If you try to access an adapter from a userspace program, you will have | |
117 | to use the /dev interface. You will still have to check whether the | |
118 | functionality you need is supported, of course. This is done using | |
014e4538 | 119 | the I2C_FUNCS ioctl. An example, adapted from the lm_sensors i2cdetect |
1da177e4 LT |
120 | program, is below: |
121 | ||
122 | int file; | |
123 | if (file = open("/dev/i2c-0",O_RDWR) < 0) { | |
124 | /* Some kind of error handling */ | |
125 | exit(1); | |
126 | } | |
127 | if (ioctl(file,I2C_FUNCS,&funcs) < 0) { | |
128 | /* Some kind of error handling */ | |
129 | exit(1); | |
130 | } | |
131 | if (! (funcs & I2C_FUNC_SMBUS_QUICK)) { | |
132 | /* Oops, the needed functionality (SMBus write_quick function) is | |
133 | not available! */ | |
134 | exit(1); | |
135 | } | |
136 | /* Now it is safe to use the SMBus write_quick command */ |