On 27 Jun 2010, at 16:10, Guenter Roeck wrote: > On Sun, Jun 27, 2010 at 06:20:59AM -0400, Mark Brown wrote: >> A bit late to the game here but this looks like the chip has some >> regulator control functionality as well as monitoring functionality (and >> the product page on the Summit web site suggests so also). This means >> that when fully supported in software the driver would cross multiple >> subsystems so it might make sense to start off with a MFD rather than >> direct I2C control? >> >> If the non-monitoring functionality can't be controlled from software >> this isn't an issue. > > I thought about that when I started working on the driver, but concluded that > it does not really make sense. > > The chip is commonly used to control all supply voltages on a board. > Changing those voltages is not a good idea. For that reason, the chip can be There's rather a lot of systems out there doing DVFS or using things like MMC cards which would disagree with the idea that it's a bad idea to change supply voltages at runtime. Even for fixed voltage supplies enabling and disabling at runtime is useful to save power. I think it's fair to say that the overall trend is towards more dynamic power management. > set into read-only mode, where changing the voltages is no longer possible > after initial programming. This tends to be done through paranoia more than anything else - people get very worried about things like accidental writes to their PMICs. > While it is theoretically possible that someone might use the device to control > not only fixed but also dynamic voltages, I think that is highly unlikely, given > the risk involved in blowing up the board. Thus, moving the driver to mfd would > effectively serve no real purpose other than to cause confusion and add unnecessary Pretty much any current generation CPU can use dynamic voltage configuration for DVFS. _______________________________________________ lm-sensors mailing list lm-sensors@xxxxxxxxxxxxxx http://lists.lm-sensors.org/mailman/listinfo/lm-sensors