On Wed, May 25, 2011 at 11:17, Kevin Hilman <khilman@xxxxxx> wrote: > "Menon, Nishanth" <nm@xxxxxx> writes: > >> On Wed, May 18, 2011 at 03:53, Kevin Hilman <khilman@xxxxxx> wrote: >>> Nishanth Menon <nm@xxxxxx> writes: >>> >>>> Patch "OMAP2+: voltage: split voltage controller (VC) code into dedicated layer" >>>> splits out the hardcoded value in the code to vc's channel init. >>>> >>>> This patch further isolates the configuration to remove out PMIC specific >>>> configuration as high and low times are pmic specific. >>>> >>>> Values are updated as well based on latest TI analysis done in android k35 >>>> kernel. >>>> >>>> Signed-off-by: Nishanth Menon <nm@xxxxxx> >>> >>> OK, this is a step in the right direction, but IIUC, these values are >>> sys_clk dependent right? Shouldn't we be calculating these values based >>> on sys_clk? >> 3 factors to my knowledge: >> a) sr clk I believe(I need to grab the relevant internal doc to >> verify) - factor of sysclk - > board based/in a way pmic based >> b) factor of board capacitance (similar to i2c bus) >> c) i2c bus capability of the PMIC itself. >> >> hence based it off pmic data.. > > These are hard-coded constants, that are calculated somehow, or their > simply pulled out of the air at random. Either way, we need to know > *how* they are calculated, and explain it in. > > Personaly, I'd prefer that the explanation come in the form of code. > IOW, functions that calculate the value based on dependent clocks using > whatever the board-specific factors are as inputs. yep, trying to dig internally to simplify the blackmagic involved. ideally, I'd like a person to look at the PMIC data sheet and update relevant params(timing, maybe bus capacitance max) and the rest of the computation should be automated. it makes bigger sense for us considering 4460 has a combination of TPS and TWL controlling rails and we just have one VC I2C config register to configure the common value. Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html