Prev: [PATCH] Staging: comedi: kcomedilib: fix coding style issues in kcomedilib_main.c
Next: (none)
From: Mark Brown on 27 Jun 2010 16:00
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.--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
 | 
Pages: 1
Prev: [PATCH] Staging: comedi: kcomedilib: fix coding style issues in kcomedilib_main.c
Next: (none)