aboutsummaryrefslogtreecommitdiffstats
path: root/Documentation/hwmon
diff options
context:
space:
mode:
authorGuenter Roeck <guenter.roeck@ericsson.com>2011-08-27 14:42:30 -0400
committerGuenter Roeck <guenter.roeck@ericsson.com>2011-10-24 14:09:38 -0400
commitced29d422557feb4230ea6b0067f1e24c5bd83f7 (patch)
treeddd6665b703ea3496f4ed219bb758062ae2a7cef /Documentation/hwmon
parent6543439f19b829f94a37e1ea277ead76e93b917f (diff)
hwmon: (pmbus) Provide more documentation
Provide more documentation describing PMBus driver functionality and the API between the PMBus core driver and PMBus chip drivers. Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com> Reviewed-by: Robert Coulson <robert.coulson@ericsson.com>
Diffstat (limited to 'Documentation/hwmon')
-rw-r--r--Documentation/hwmon/pmbus-core283
1 files changed, 283 insertions, 0 deletions
diff --git a/Documentation/hwmon/pmbus-core b/Documentation/hwmon/pmbus-core
new file mode 100644
index 000000000000..31e4720fed18
--- /dev/null
+++ b/Documentation/hwmon/pmbus-core
@@ -0,0 +1,283 @@
1PMBus core driver and internal API
2==================================
3
4Introduction
5============
6
7[from pmbus.org] The Power Management Bus (PMBus) is an open standard
8power-management protocol with a fully defined command language that facilitates
9communication with power converters and other devices in a power system. The
10protocol is implemented over the industry-standard SMBus serial interface and
11enables programming, control, and real-time monitoring of compliant power
12conversion products. This flexible and highly versatile standard allows for
13communication between devices based on both analog and digital technologies, and
14provides true interoperability which will reduce design complexity and shorten
15time to market for power system designers. Pioneered by leading power supply and
16semiconductor companies, this open power system standard is maintained and
17promoted by the PMBus Implementers Forum (PMBus-IF), comprising 30+ adopters
18with the objective to provide support to, and facilitate adoption among, users.
19
20Unfortunately, while PMBus commands are standardized, there are no mandatory
21commands, and manufacturers can add as many non-standard commands as they like.
22Also, different PMBUs devices act differently if non-supported commands are
23executed. Some devices return an error, some devices return 0xff or 0xffff and
24set a status error flag, and some devices may simply hang up.
25
26Despite all those difficulties, a generic PMBus device driver is still useful
27and supported since kernel version 2.6.39. However, it was necessary to support
28device specific extensions in addition to the core PMBus driver, since it is
29simply unknown what new device specific functionality PMBus device developers
30come up with next.
31
32To make device specific extensions as scalable as possible, and to avoid having
33to modify the core PMBus driver repeatedly for new devices, the PMBus driver was
34split into core, generic, and device specific code. The core code (in
35pmbus_core.c) provides generic functionality. The generic code (in pmbus.c)
36provides support for generic PMBus devices. Device specific code is responsible
37for device specific initialization and, if needed, maps device specific
38functionality into generic functionality. This is to some degree comparable
39to PCI code, where generic code is augmented as needed with quirks for all kinds
40of devices.
41
42PMBus device capabilities auto-detection
43========================================
44
45For generic PMBus devices, code in pmbus.c attempts to auto-detect all supported
46PMBus commands. Auto-detection is somewhat limited, since there are simply too
47many variables to consider. For example, it is almost impossible to autodetect
48which PMBus commands are paged and which commands are replicated across all
49pages (see the PMBus specification for details on multi-page PMBus devices).
50
51For this reason, it often makes sense to provide a device specific driver if not
52all commands can be auto-detected. The data structures in this driver can be
53used to inform the core driver about functionality supported by individual
54chips.
55
56Some commands are always auto-detected. This applies to all limit commands
57(lcrit, min, max, and crit attributes) as well as associated alarm attributes.
58Limits and alarm attributes are auto-detected because there are simply too many
59possible combinations to provide a manual configuration interface.
60
61PMBus internal API
62==================
63
64The API between core and device specific PMBus code is defined in
65drivers/hwmon/pmbus/pmbus.h. In addition to the internal API, pmbus.h defines
66standard PMBus commands and virtual PMBus commands.
67
68Standard PMBus commands
69-----------------------
70
71Standard PMBus commands (commands values 0x00 to 0xff) are defined in the PMBUs
72specification.
73
74Virtual PMBus commands
75----------------------
76
77Virtual PMBus commands are provided to enable support for non-standard
78functionality which has been implemented by several chip vendors and is thus
79desirable to support.
80
81Virtual PMBus commands start with command value 0x100 and can thus easily be
82distinguished from standard PMBus commands (which can not have values larger
83than 0xff). Support for virtual PMBus commands is device specific and thus has
84to be implemented in device specific code.
85
86Virtual commands are named PMBUS_VIRT_xxx and start with PMBUS_VIRT_BASE. All
87virtual commands are word sized.
88
89There are currently two types of virtual commands.
90
91- READ commands are read-only; writes are either ignored or return an error.
92- RESET commands are read/write. Reading reset registers returns zero
93 (used for detection), writing any value causes the associated history to be
94 reset.
95
96Virtual commands have to be handled in device specific driver code. Chip driver
97code returns non-negative values if a virtual command is supported, or a
98negative error code if not. The chip driver may return -ENODATA or any other
99Linux error code in this case, though an error code other than -ENODATA is
100handled more efficiently and thus preferred. Either case, the calling PMBus
101core code will abort if the chip driver returns an error code when reading
102or writing virtual registers (in other words, the PMBus core code will never
103send a virtual command to a chip).
104
105PMBus driver information
106------------------------
107
108PMBus driver information, defined in struct pmbus_driver_info, is the main means
109for device specific drivers to pass information to the core PMBus driver.
110Specifically, it provides the following information.
111
112- For devices supporting its data in Direct Data Format, it provides coefficients
113 for converting register values into normalized data. This data is usually
114 provided by chip manufacturers in device datasheets.
115- Supported chip functionality can be provided to the core driver. This may be
116 necessary for chips which react badly if non-supported commands are executed,
117 and/or to speed up device detection and initialization.
118- Several function entry points are provided to support overriding and/or
119 augmenting generic command execution. This functionality can be used to map
120 non-standard PMBus commands to standard commands, or to augment standard
121 command return values with device specific information.
122
123 API functions
124 -------------
125
126 Functions provided by chip driver
127 ---------------------------------
128
129 All functions return the command return value (read) or zero (write) if
130 successful. A return value of -ENODATA indicates that there is no manufacturer
131 specific command, but that a standard PMBus command may exist. Any other
132 negative return value indicates that the commands does not exist for this
133 chip, and that no attempt should be made to read or write the standard
134 command.
135
136 As mentioned above, an exception to this rule applies to virtual commands,
137 which _must_ be handled in driver specific code. See "Virtual PMBus Commands"
138 above for more details.
139
140 Command execution in the core PMBus driver code is as follows.
141
142 if (chip_access_function) {
143 status = chip_access_function();
144 if (status != -ENODATA)
145 return status;
146 }
147 if (command >= PMBUS_VIRT_BASE) /* For word commands/registers only */
148 return -EINVAL;
149 return generic_access();
150
151 Chip drivers may provide pointers to the following functions in struct
152 pmbus_driver_info. All functions are optional.
153
154 int (*read_byte_data)(struct i2c_client *client, int page, int reg);
155
156 Read byte from page <page>, register <reg>.
157 <page> may be -1, which means "current page".
158
159 int (*read_word_data)(struct i2c_client *client, int page, int reg);
160
161 Read word from page <page>, register <reg>.
162
163 int (*write_word_data)(struct i2c_client *client, int page, int reg,
164 u16 word);
165
166 Write word to page <page>, register <reg>.
167
168 int (*write_byte)(struct i2c_client *client, int page, u8 value);
169
170 Write byte to page <page>, register <reg>.
171 <page> may be -1, which means "current page".
172
173 int (*identify)(struct i2c_client *client, struct pmbus_driver_info *info);
174
175 Determine supported PMBus functionality. This function is only necessary
176 if a chip driver supports multiple chips, and the chip functionality is not
177 pre-determined. It is currently only used by the generic pmbus driver
178 (pmbus.c).
179
180 Functions exported by core driver
181 ---------------------------------
182
183 Chip drivers are expected to use the following functions to read or write
184 PMBus registers. Chip drivers may also use direct I2C commands. If direct I2C
185 commands are used, the chip driver code must not directly modify the current
186 page, since the selected page is cached in the core driver and the core driver
187 will assume that it is selected. Using pmbus_set_page() to select a new page
188 is mandatory.
189
190 int pmbus_set_page(struct i2c_client *client, u8 page);
191
192 Set PMBus page register to <page> for subsequent commands.
193
194 int pmbus_read_word_data(struct i2c_client *client, u8 page, u8 reg);
195
196 Read word data from <page>, <reg>. Similar to i2c_smbus_read_word_data(), but
197 selects page first.
198
199 int pmbus_write_word_data(struct i2c_client *client, u8 page, u8 reg,
200 u16 word);
201
202 Write word data to <page>, <reg>. Similar to i2c_smbus_write_word_data(), but
203 selects page first.
204
205 int pmbus_read_byte_data(struct i2c_client *client, int page, u8 reg);
206
207 Read byte data from <page>, <reg>. Similar to i2c_smbus_read_byte_data(), but
208 selects page first. <page> may be -1, which means "current page".
209
210 int pmbus_write_byte(struct i2c_client *client, int page, u8 value);
211
212 Write byte data to <page>, <reg>. Similar to i2c_smbus_write_byte(), but
213 selects page first. <page> may be -1, which means "current page".
214
215 void pmbus_clear_faults(struct i2c_client *client);
216
217 Execute PMBus "Clear Fault" command on all chip pages.
218 This function calls the device specific write_byte function if defined.
219 Therefore, it must _not_ be called from that function.
220
221 bool pmbus_check_byte_register(struct i2c_client *client, int page, int reg);
222
223 Check if byte register exists. Return true if the register exists, false
224 otherwise.
225 This function calls the device specific write_byte function if defined to
226 obtain the chip status. Therefore, it must _not_ be called from that function.
227
228 bool pmbus_check_word_register(struct i2c_client *client, int page, int reg);
229
230 Check if word register exists. Return true if the register exists, false
231 otherwise.
232 This function calls the device specific write_byte function if defined to
233 obtain the chip status. Therefore, it must _not_ be called from that function.
234
235 int pmbus_do_probe(struct i2c_client *client, const struct i2c_device_id *id,
236 struct pmbus_driver_info *info);
237
238 Execute probe function. Similar to standard probe function for other drivers,
239 with the pointer to struct pmbus_driver_info as additional argument. Calls
240 identify function if supported. Must only be called from device probe
241 function.
242
243 void pmbus_do_remove(struct i2c_client *client);
244
245 Execute driver remove function. Similar to standard driver remove function.
246
247 const struct pmbus_driver_info
248 *pmbus_get_driver_info(struct i2c_client *client);
249
250 Return pointer to struct pmbus_driver_info as passed to pmbus_do_probe().
251
252
253PMBus driver platform data
254==========================
255
256PMBus platform data is defined in include/linux/i2c/pmbus.h. Platform data
257currently only provides a flag field with a single bit used.
258
259#define PMBUS_SKIP_STATUS_CHECK (1 << 0)
260
261struct pmbus_platform_data {
262 u32 flags; /* Device specific flags */
263};
264
265
266Flags
267-----
268
269PMBUS_SKIP_STATUS_CHECK
270
271During register detection, skip checking the status register for
272communication or command errors.
273
274Some PMBus chips respond with valid data when trying to read an unsupported
275register. For such chips, checking the status register is mandatory when
276trying to determine if a chip register exists or not.
277Other PMBus chips don't support the STATUS_CML register, or report
278communication errors for no explicable reason. For such chips, checking the
279status register must be disabled.
280
281Some i2c controllers do not support single-byte commands (write commands with
282no data, i2c_smbus_write_byte()). With such controllers, clearing the status
283register is impossible, and the PMBUS_SKIP_STATUS_CHECK flag must be set.