Hi, On Wed, Feb 16, 2011 at 6:01 PM, Jarkko Nikula <jhnikula@xxxxxxxxx> wrote: > On Wed, 16 Feb 2011 17:24:30 +0530 > "Gulati, Shweta" <shweta.gulati@xxxxxx> wrote: > >> > Note proof of concept patch only. I omitted the comments and don't do >> > explicit SR disable and I'd clean up the error paths in twl4030_power_init >> > a bit before this (e.g. printing error codes). Not sure either is the >> > twl4030-power.c right place for this or core. >> You missed commit log which says that "T2 bit is required to enable I2C_SR >> path of voltage control" it is not at all enabling SR, voltage scale >> APIs VPforceupdate/ VCbypass >> needs this path to be enabled. >> And calling APIs twl_i2c_read/write in driver codebase does n't ensure correct >> ordering of flag changes and twl_read/write. > > Ah, yeah. I forgot to comment that I tried shortly also to run this > enable code from workqueue ~60 s after bootup and indeed SR didn't work > if those autocomp sysfs nodes were set before setting the TWL SR bit and > I believe same holds for voltage scaling too as you say. > > What I'm thinking is there actually need for some higher level > control for these that quarantees the right order independently from > when each module are initialized. Yes there is a need. Voltage control for TWL uses different ways VMODE/I2C1/I2C_SR Most of the OMAP3+ boards uses I2C_SR, for this to function properly SR_BIT on TWL side needs to be enabled but there could be some boards that use VMODE method of scaling, for those boards this bit has to be disabled which can be done from board file that is why a flag is set to make sure that API 'omap3_twl_set_sr_bit()' is called once and all initializations are done in order so SR bit is set/cleared aptly. > -- > Jarkko > -- Thanks, Regards, Shweta -- 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
