diff options
author | Linus Torvalds <torvalds@ppc970.osdl.org> | 2005-04-16 18:20:36 -0400 |
---|---|---|
committer | Linus Torvalds <torvalds@ppc970.osdl.org> | 2005-04-16 18:20:36 -0400 |
commit | 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 (patch) | |
tree | 0bba044c4ce775e45a88a51686b5d9f90697ea9d /Documentation/i2c/functionality |
Linux-2.6.12-rc2v2.6.12-rc2
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.
Let it rip!
Diffstat (limited to 'Documentation/i2c/functionality')
-rw-r--r-- | Documentation/i2c/functionality | 135 |
1 files changed, 135 insertions, 0 deletions
diff --git a/Documentation/i2c/functionality b/Documentation/i2c/functionality new file mode 100644 index 000000000000..8a78a95ae04e --- /dev/null +++ b/Documentation/i2c/functionality | |||
@@ -0,0 +1,135 @@ | |||
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 | ||
20 | I2C_FUNC_PROTOCOL_MANGLING Knows about the I2C_M_REV_DIR_ADDR, | ||
21 | I2C_M_REV_DIR_ADDR and I2C_M_REV_DIR_NOSTART | ||
22 | flags (which modify the i2c protocol!) | ||
23 | I2C_FUNC_SMBUS_QUICK Handles the SMBus write_quick command | ||
24 | I2C_FUNC_SMBUS_READ_BYTE Handles the SMBus read_byte command | ||
25 | I2C_FUNC_SMBUS_WRITE_BYTE Handles the SMBus write_byte command | ||
26 | I2C_FUNC_SMBUS_READ_BYTE_DATA Handles the SMBus read_byte_data command | ||
27 | I2C_FUNC_SMBUS_WRITE_BYTE_DATA Handles the SMBus write_byte_data command | ||
28 | I2C_FUNC_SMBUS_READ_WORD_DATA Handles the SMBus read_word_data command | ||
29 | I2C_FUNC_SMBUS_WRITE_WORD_DATA Handles the SMBus write_byte_data command | ||
30 | I2C_FUNC_SMBUS_PROC_CALL Handles the SMBus process_call command | ||
31 | I2C_FUNC_SMBUS_READ_BLOCK_DATA Handles the SMBus read_block_data command | ||
32 | I2C_FUNC_SMBUS_WRITE_BLOCK_DATA Handles the SMBus write_block_data command | ||
33 | I2C_FUNC_SMBUS_READ_I2C_BLOCK Handles the SMBus read_i2c_block_data command | ||
34 | I2C_FUNC_SMBUS_WRITE_I2C_BLOCK Handles the SMBus write_i2c_block_data command | ||
35 | |||
36 | A few combinations of the above flags are also defined for your convenience: | ||
37 | |||
38 | I2C_FUNC_SMBUS_BYTE Handles the SMBus read_byte | ||
39 | and write_byte commands | ||
40 | I2C_FUNC_SMBUS_BYTE_DATA Handles the SMBus read_byte_data | ||
41 | and write_byte_data commands | ||
42 | I2C_FUNC_SMBUS_WORD_DATA Handles the SMBus read_word_data | ||
43 | and write_word_data commands | ||
44 | I2C_FUNC_SMBUS_BLOCK_DATA Handles the SMBus read_block_data | ||
45 | and write_block_data commands | ||
46 | I2C_FUNC_SMBUS_I2C_BLOCK Handles the SMBus read_i2c_block_data | ||
47 | and write_i2c_block_data commands | ||
48 | I2C_FUNC_SMBUS_EMUL Handles all SMBus commands than can be | ||
49 | emulated by a real I2C adapter (using | ||
50 | the transparent emulation layer) | ||
51 | |||
52 | |||
53 | ALGORITHM/ADAPTER IMPLEMENTATION | ||
54 | -------------------------------- | ||
55 | |||
56 | When you write a new algorithm driver, you will have to implement a | ||
57 | function callback `functionality', that gets an i2c_adapter structure | ||
58 | pointer as its only parameter: | ||
59 | |||
60 | struct i2c_algorithm { | ||
61 | /* Many other things of course; check <linux/i2c.h>! */ | ||
62 | u32 (*functionality) (struct i2c_adapter *); | ||
63 | } | ||
64 | |||
65 | A typically implementation is given below, from i2c-algo-bit.c: | ||
66 | |||
67 | static u32 bit_func(struct i2c_adapter *adap) | ||
68 | { | ||
69 | return I2C_FUNC_SMBUS_EMUL | I2C_FUNC_10BIT_ADDR | | ||
70 | I2C_FUNC_PROTOCOL_MANGLING; | ||
71 | } | ||
72 | |||
73 | |||
74 | |||
75 | CLIENT CHECKING | ||
76 | --------------- | ||
77 | |||
78 | Before a client tries to attach to an adapter, or even do tests to check | ||
79 | whether one of the devices it supports is present on an adapter, it should | ||
80 | check whether the needed functionality is present. There are two functions | ||
81 | defined which should be used instead of calling the functionality hook | ||
82 | in the algorithm structure directly: | ||
83 | |||
84 | /* Return the functionality mask */ | ||
85 | extern u32 i2c_get_functionality (struct i2c_adapter *adap); | ||
86 | |||
87 | /* Return 1 if adapter supports everything we need, 0 if not. */ | ||
88 | extern int i2c_check_functionality (struct i2c_adapter *adap, u32 func); | ||
89 | |||
90 | This is a typical way to use these functions (from the writing-clients | ||
91 | document): | ||
92 | int foo_detect_client(struct i2c_adapter *adapter, int address, | ||
93 | unsigned short flags, int kind) | ||
94 | { | ||
95 | /* Define needed variables */ | ||
96 | |||
97 | /* As the very first action, we check whether the adapter has the | ||
98 | needed functionality: we need the SMBus read_word_data, | ||
99 | write_word_data and write_byte functions in this example. */ | ||
100 | if (!i2c_check_functionality(adapter,I2C_FUNC_SMBUS_WORD_DATA | | ||
101 | I2C_FUNC_SMBUS_WRITE_BYTE)) | ||
102 | goto ERROR0; | ||
103 | |||
104 | /* Now we can do the real detection */ | ||
105 | |||
106 | ERROR0: | ||
107 | /* Return an error */ | ||
108 | } | ||
109 | |||
110 | |||
111 | |||
112 | CHECKING THROUGH /DEV | ||
113 | --------------------- | ||
114 | |||
115 | If you try to access an adapter from a userspace program, you will have | ||
116 | to use the /dev interface. You will still have to check whether the | ||
117 | functionality you need is supported, of course. This is done using | ||
118 | the I2C_FUNCS ioctl. An example, adapted from the lm_sensors i2c_detect | ||
119 | program, is below: | ||
120 | |||
121 | int file; | ||
122 | if (file = open("/dev/i2c-0",O_RDWR) < 0) { | ||
123 | /* Some kind of error handling */ | ||
124 | exit(1); | ||
125 | } | ||
126 | if (ioctl(file,I2C_FUNCS,&funcs) < 0) { | ||
127 | /* Some kind of error handling */ | ||
128 | exit(1); | ||
129 | } | ||
130 | if (! (funcs & I2C_FUNC_SMBUS_QUICK)) { | ||
131 | /* Oops, the needed functionality (SMBus write_quick function) is | ||
132 | not available! */ | ||
133 | exit(1); | ||
134 | } | ||
135 | /* Now it is safe to use the SMBus write_quick command */ | ||