About Kernel Documentation Linux Kernel Contact Linux Resources Linux Blog

Documentation / hwmon / pmbus-core

Custom Search

Based on kernel version 3.13. Page generated on 2014-01-20 22:03 EST.

1	PMBus core driver and internal API
2	==================================
4	Introduction
5	============
7	[from pmbus.org] The Power Management Bus (PMBus) is an open standard
8	power-management protocol with a fully defined command language that facilitates
9	communication with power converters and other devices in a power system. The
10	protocol is implemented over the industry-standard SMBus serial interface and
11	enables programming, control, and real-time monitoring of compliant power
12	conversion products. This flexible and highly versatile standard allows for
13	communication between devices based on both analog and digital technologies, and
14	provides true interoperability which will reduce design complexity and shorten
15	time to market for power system designers. Pioneered by leading power supply and
16	semiconductor companies, this open power system standard is maintained and
17	promoted by the PMBus Implementers Forum (PMBus-IF), comprising 30+ adopters
18	with the objective to provide support to, and facilitate adoption among, users.
20	Unfortunately, while PMBus commands are standardized, there are no mandatory
21	commands, and manufacturers can add as many non-standard commands as they like.
22	Also, different PMBUs devices act differently if non-supported commands are
23	executed. Some devices return an error, some devices return 0xff or 0xffff and
24	set a status error flag, and some devices may simply hang up.
26	Despite all those difficulties, a generic PMBus device driver is still useful
27	and supported since kernel version 2.6.39. However, it was necessary to support
28	device specific extensions in addition to the core PMBus driver, since it is
29	simply unknown what new device specific functionality PMBus device developers
30	come up with next.
32	To make device specific extensions as scalable as possible, and to avoid having
33	to modify the core PMBus driver repeatedly for new devices, the PMBus driver was
34	split into core, generic, and device specific code. The core code (in
35	pmbus_core.c) provides generic functionality. The generic code (in pmbus.c)
36	provides support for generic PMBus devices. Device specific code is responsible
37	for device specific initialization and, if needed, maps device specific
38	functionality into generic functionality. This is to some degree comparable
39	to PCI code, where generic code is augmented as needed with quirks for all kinds
40	of devices.
42	PMBus device capabilities auto-detection
43	========================================
45	For generic PMBus devices, code in pmbus.c attempts to auto-detect all supported
46	PMBus commands. Auto-detection is somewhat limited, since there are simply too
47	many variables to consider. For example, it is almost impossible to autodetect
48	which PMBus commands are paged and which commands are replicated across all
49	pages (see the PMBus specification for details on multi-page PMBus devices).
51	For this reason, it often makes sense to provide a device specific driver if not
52	all commands can be auto-detected. The data structures in this driver can be
53	used to inform the core driver about functionality supported by individual
54	chips.
56	Some commands are always auto-detected. This applies to all limit commands
57	(lcrit, min, max, and crit attributes) as well as associated alarm attributes.
58	Limits and alarm attributes are auto-detected because there are simply too many
59	possible combinations to provide a manual configuration interface.
61	PMBus internal API
62	==================
64	The API between core and device specific PMBus code is defined in
65	drivers/hwmon/pmbus/pmbus.h. In addition to the internal API, pmbus.h defines
66	standard PMBus commands and virtual PMBus commands.
68	Standard PMBus commands
69	-----------------------
71	Standard PMBus commands (commands values 0x00 to 0xff) are defined in the PMBUs
72	specification.
74	Virtual PMBus commands
75	----------------------
77	Virtual PMBus commands are provided to enable support for non-standard
78	functionality which has been implemented by several chip vendors and is thus
79	desirable to support.
81	Virtual PMBus commands start with command value 0x100 and can thus easily be
82	distinguished from standard PMBus commands (which can not have values larger
83	than 0xff). Support for virtual PMBus commands is device specific and thus has
84	to be implemented in device specific code.
86	Virtual commands are named PMBUS_VIRT_xxx and start with PMBUS_VIRT_BASE. All
87	virtual commands are word sized.
89	There are currently two types of virtual commands.
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.
96	Virtual commands have to be handled in device specific driver code. Chip driver
97	code returns non-negative values if a virtual command is supported, or a
98	negative error code if not. The chip driver may return -ENODATA or any other
99	Linux error code in this case, though an error code other than -ENODATA is
100	handled more efficiently and thus preferred. Either case, the calling PMBus
101	core code will abort if the chip driver returns an error code when reading
102	or writing virtual registers (in other words, the PMBus core code will never
103	send a virtual command to a chip).
105	PMBus driver information
106	------------------------
108	PMBus driver information, defined in struct pmbus_driver_info, is the main means
109	for device specific drivers to pass information to the core PMBus driver.
110	Specifically, it provides the following information.
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.
123	  API functions
124	  -------------
126	  Functions provided by chip driver
127	  ---------------------------------
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.
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.
140	  Command execution in the core PMBus driver code is as follows.
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();
151	  Chip drivers may provide pointers to the following functions in struct
152	  pmbus_driver_info. All functions are optional.
154	  int (*read_byte_data)(struct i2c_client *client, int page, int reg);
156	  Read byte from page <page>, register <reg>.
157	  <page> may be -1, which means "current page".
159	  int (*read_word_data)(struct i2c_client *client, int page, int reg);
161	  Read word from page <page>, register <reg>.
163	  int (*write_word_data)(struct i2c_client *client, int page, int reg,
164			         u16 word);
166	  Write word to page <page>, register <reg>.
168	  int (*write_byte)(struct i2c_client *client, int page, u8 value);
170	  Write byte to page <page>, register <reg>.
171	  <page> may be -1, which means "current page".
173	  int (*identify)(struct i2c_client *client, struct pmbus_driver_info *info);
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).
180	  Functions exported by core driver
181	  ---------------------------------
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.
190	  int pmbus_set_page(struct i2c_client *client, u8 page);
192	  Set PMBus page register to <page> for subsequent commands.
194	  int pmbus_read_word_data(struct i2c_client *client, u8 page, u8 reg);
196	  Read word data from <page>, <reg>. Similar to i2c_smbus_read_word_data(), but
197	  selects page first.
199	  int pmbus_write_word_data(struct i2c_client *client, u8 page, u8 reg,
200				    u16 word);
202	  Write word data to <page>, <reg>. Similar to i2c_smbus_write_word_data(), but
203	  selects page first.
205	  int pmbus_read_byte_data(struct i2c_client *client, int page, u8 reg);
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".
210	  int pmbus_write_byte(struct i2c_client *client, int page, u8 value);
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".
215	  void pmbus_clear_faults(struct i2c_client *client);
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.
221	  bool pmbus_check_byte_register(struct i2c_client *client, int page, int reg);
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.
228	  bool pmbus_check_word_register(struct i2c_client *client, int page, int reg);
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.
235	  int pmbus_do_probe(struct i2c_client *client, const struct i2c_device_id *id,
236	                     struct pmbus_driver_info *info);
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.
243	  void pmbus_do_remove(struct i2c_client *client);
245	  Execute driver remove function. Similar to standard driver remove function.
247	  const struct pmbus_driver_info
248		*pmbus_get_driver_info(struct i2c_client *client);
250	  Return pointer to struct pmbus_driver_info as passed to pmbus_do_probe().
253	PMBus driver platform data
254	==========================
256	PMBus platform data is defined in include/linux/i2c/pmbus.h. Platform data
257	currently only provides a flag field with a single bit used.
259	#define PMBUS_SKIP_STATUS_CHECK (1 << 0)
261	struct pmbus_platform_data {
262	        u32 flags;              /* Device specific flags */
263	};
266	Flags
267	-----
271	During register detection, skip checking the status register for
272	communication or command errors.
274	Some PMBus chips respond with valid data when trying to read an unsupported
275	register. For such chips, checking the status register is mandatory when
276	trying to determine if a chip register exists or not.
277	Other PMBus chips don't support the STATUS_CML register, or report
278	communication errors for no explicable reason. For such chips, checking the
279	status register must be disabled.
281	Some i2c controllers do not support single-byte commands (write commands with
282	no data, i2c_smbus_write_byte()). With such controllers, clearing the status
283	register is impossible, and the PMBUS_SKIP_STATUS_CHECK flag must be set.
Hide Line Numbers
About Kernel Documentation Linux Kernel Contact Linux Resources Linux Blog

Information is copyright its respective author. All material is available from the Linux Kernel Source distributed under a GPL License. This page is provided as a free service by mjmwired.net.