On Wednesday 08 October 2008, Tony Lindgren wrote: > > > I suspect that twl is not yet initialized for pwrirq handling at this > > > point. At least this patch seems to help, > > > > Did you verify that the value you read isn't 0xff? Or does the > > issue seem to be the mere attempt to read a register? > > Yeah, it seems to be 0 first, then 0xf0, then 0xf7, then 0xff. It seems > that at 0xf0 it still does not work. Values from memory, but something > like that anyways. Huh. Most bizarre. Oh wait ... that might be explained by taking a ginormous amount of time to shift out of the 1.5 MHz clock mode. See 3.4.12 of the manual: When power is first applied to the device, it does not know the external HF clock frequency (HFCLK_FREQ has not been set by the host processor). To ensure that the power subchip registers can be accessed, the default register access frequency is 1.5 MHz (1⁄2 of 3 MHz). Doesn't say how to tell that's happening, or how long it'd take to change to 3 MHz. (Which only happens if HFCLK isn't 19.2 MHz.) Maybe wait for BACKUP_MISC_CFG.PWR_CLK_FREQ to clear... it's just controlling a simple divide-by-two, not a PLL, so it should be pretty much immediate. > > I have a hard time seeing the root cause be anything other than > > problems in i2c-omap, since the timeouts appear at various other > > places too. > > Well at least one twl bug was happening when the source clock was > initialized incorrectly.. And that only happened with one of the twl > modules. The issue above? But we know that HFCLK_FREQ is getting set, so that wouldn't explain i2c-omap timeouts that show up later. Or maybe there's another clocking issue... I hate to look at the i2c-omap, but it really seems like that's got to be the root cause here. After all, the timeout message appears way too quickly for it to be a *legitimate* timeout for any I2C protocol action. (SMBus has timeouts. I2C doesn't...) - Dave -- 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
