Hi, On Wed, Aug 22, 2012 at 08:36:31PM +0530, Datta, Shubhrajyoti wrote: > > The real mystery is why this happens on Beagle and Beagle-xM, but none > > of the other OMAP3 boards (at least the ones I have.) > > Looks like some race/ timing issue. > However I am not sure what is a good way to synchronise the i2c > requests from a client from an isr and > the device disable / runtime resumed. > > However on merging the clean up series > > http://www.mail-archive.com/linux-omap@vger.kernel.org/msg73870.html > > Didn't see the above mentioned issue. > > but there were some error's like timeout. > > This may be because the controller was not fully enabled. > > SYSC in case of I2C not only reflects the reset status from sysc > reset( register is reset) > but also controller enable ( controller reset ). > > On checking the reset after controller didnt see the time out issue. > > patch below. > > > > diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c > index 9aefd36..b35afa4 100644 > --- a/drivers/i2c/busses/i2c-omap.c > +++ b/drivers/i2c/busses/i2c-omap.c > @@ -1254,6 +1254,7 @@ static int omap_i2c_runtime_resume(struct device *dev) > { > struct platform_device *pdev = to_platform_device(dev); > struct omap_i2c_dev *_dev = platform_get_drvdata(pdev); > + unsigned long timeout = 10000; > > if (_dev->flags & OMAP_I2C_FLAG_RESET_REGS_POSTIDLE) { > omap_i2c_write_reg(_dev, OMAP_I2C_CON_REG, 0); > @@ -1266,6 +1267,15 @@ static int omap_i2c_runtime_resume(struct device *dev) > omap_i2c_write_reg(_dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN); > } > > + while (!(omap_i2c_read_reg(_dev, OMAP_I2C_SYSS_REG) & > + SYSS_RESETDONE_MASK)) { > + if (time_after(jiffies, timeout)) { > + dev_warn(dev, "timeout waiting for controller reset\n"); > + return -ETIMEDOUT; > + } > + msleep(1); > + } > + > /* > * Don't write to this register if the IE state is 0 as it can > * cause deadlock.
That's weird. i2c has SYSS_HAS_RESET_STATUS set, so hwmod framework should be checking that for us. And, in fact, SYSS_HAS_RESET_STATUS is set on all *data.c files. When you wrote that patch, did you check that reset hasn't completed yet ? I mean, was reset still asserted at that time ? If instead of your patch, you just wait longer for reset to complete, will it work ? diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c index 6ca8e51..7a39c72 100644 --- a/arch/arm/mach-omap2/omap_hwmod.c +++ b/arch/arm/mach-omap2/omap_hwmod.c @@ -156,7 +156,7 @@ #include "pm.h" /* Maximum microseconds to wait for OMAP module to softreset */ -#define MAX_MODULE_SOFTRESET_WAIT 10000 +#define MAX_MODULE_SOFTRESET_WAIT 50000 /* Name of the OMAP hwmod for the MPU */ #define MPU_INITIATOR_NAME "mpu" If it does, then reset takes longer to complete on those particular boards and it would be nice to know why, but one step at a time :-) -- balbi
signature.asc
Description: Digital signature
