> At least we can say the problem seems to be related to pm. Maybe after
> context restore we should wait until the clock stabilizes or some
> register changes ??
Maybe. An experiment would be to not shut the clock off in the idle routine.
Actually, scanning i2c_init shows what looks to be a problem.
235 static int omap_i2c_init(struct omap_i2c_dev *dev)
236 {
237 u16 psc = 0, scll = 0, sclh = 0;
238 u16 fsscll = 0, fssclh = 0, hsscll = 0, hssclh = 0;
239 unsigned long fclk_rate = 12000000;
240 unsigned long timeout;
241 unsigned long internal_clk = 0;
242
243 if (!dev->rev1) {
244 omap_i2c_write_reg(dev, OMAP_I2C_SYSC_REG,
OMAP_I2C_SYSC_SRST);
None of the module local OCP registers are being setup properly. A write of a
0x2 kills other settings. If after this operation the SSYC reg will say:
-Forced Idle
-Locally gate I+F clock on ocp-segment idle request
-wake up disabled
If it is left this way what can happen is when L4/L3 clock stop partial idle is
broadcast, this module will ack and gate its clocks. This will result in you
dropping data. Or if the data was sent ok, but clock stop happens, you won't be
able to wake the system properly as you've cleared the local wakeup generation.
The result will be a timeout.
On OMAP2 I2C wasn't hooked properly into PRCM for handshake so it needed a
workaround. The same isn't true for OMAP3. Treating the two as if they are
the same with respect to power is false.
Regards,
Richard W.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
