Re: debug needed: twl4030 RTC wakeups: repeated attempts fail on Beagle

[Felipe Balbi <balbi@ti.com>]

[-- Attachment #1: Type: text/plain, Size: 3025 bytes --]

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]