On Sat, May 29, 2010 at 11:47:41AM -0400, Wolfram Sang wrote: > > > Yes. PMBus uses i2c as transport, so it can use the existing i2c/smbus infrastructure. > > Data reported is voltage, temperature, current, power, and fan data as available > > from the individual chip. Chips support a chip dependent number of channels. > > Values reported are typically in the form of X = Y * 2^N, ie there is a mantissa > > and an exponent. > > > > So I would say it maps pretty well; I don't really see a substantial difference > > to other HW monitoring chips in that respect. Key difference may be that PMBus devices > > typically also have a control component, but I don't have plans to implement that, > > at least not for now. > > I just had a glimpse, but I came to a similar conclusion. As I further > understood, PMBus devices support a standard range of commands with the > possibility of manufacturer extenstions. > > So, the approach I see (unless I miss something) would be writing an > hwmon-I2C-driver named pmbus-devices.c or so which covers the generic > functionality and provides some hooks for manufacturer extensions, if those are > necessary? (Altough I'd hope a number of devices would be covered by the > generic driver) Makes sense? > That would be one option. It would require either a register() API call, or a table of supported chips, or a combination of both, to identify how many channels (or pages, in PMBus terminology) per chip are supported and to identify supported objects/registers. The other option would be to write separate drivers (one for each chip) and not provide a common infrastructure. Not sure if that is a good idea, though; I personally prefer the first option. Thanks, Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
