From patchwork Wed Aug 22 18:42:14 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Felipe Balbi X-Patchwork-Id: 1362911 Return-Path: X-Original-To: patchwork-linux-omap@patchwork.kernel.org Delivered-To: patchwork-process-083081@patchwork1.kernel.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by patchwork1.kernel.org (Postfix) with ESMTP id A9FFF3FD40 for ; Wed, 22 Aug 2012 18:46:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755191Ab2HVSqQ (ORCPT ); Wed, 22 Aug 2012 14:46:16 -0400 Received: from na3sys009aog130.obsmtp.com ([74.125.149.143]:39893 "EHLO na3sys009aog130.obsmtp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753413Ab2HVSqP (ORCPT ); Wed, 22 Aug 2012 14:46:15 -0400 Received: from mail-lpp01m010-f53.google.com ([209.85.215.53]) (using TLSv1) by na3sys009aob130.postini.com ([74.125.148.12]) with SMTP ID DSNKUDUo9QXWsA2X8AzZjv4G6VtSF8iTb9nZ@postini.com; Wed, 22 Aug 2012 11:46:14 PDT Received: by lahc1 with SMTP id c1so812548lah.26 for ; Wed, 22 Aug 2012 11:46:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent :x-gm-message-state; bh=AvsKoq95V/aD3933h3SOGXTwVrTBp9Ficne8vrsDDvE=; b=HgGpGOdwz72igN8NZ6gr4QSuFseWMvIR9VkBQE2Wlh40ajlUWVFHPjbl4UIzCW8Gtu DDSnC6AJFKZQGxMGJ1OxkAalSygsOFkouhTosh2TJAaYS3Tgf+kM/PBx7dlgLyBuPhF1 seHOUu1VGlQ/eFjfgQqNzubHHVMrV48uBAV6kTuHd5wVrW7dX18z9oOVRznvVcj/Qt+7 OEfKtLkS/6yGdhr0zUC0ksgFMsfmUezcZdVtwO5nC8MP02DHB1VBPwq/efoSDJdDvl4b iYF/XZIBbrKO0hrwrQcwcJbXdB1kWHb2cLnf9S5aXhegVkgbRvvsjWvGUQkLwzKqJ9og Sgcg== Received: by 10.152.110.80 with SMTP id hy16mr12186559lab.8.1345661172150; Wed, 22 Aug 2012 11:46:12 -0700 (PDT) Received: from localhost (cs78217178.pp.htv.fi. [62.78.217.178]) by mx.google.com with ESMTPS id sn2sm5140422lab.16.2012.08.22.11.46.10 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 22 Aug 2012 11:46:11 -0700 (PDT) Date: Wed, 22 Aug 2012 21:42:14 +0300 From: Felipe Balbi To: "Datta, Shubhrajyoti" Cc: Kevin Hilman , linux-omap , NeilBrown , Russ Dill Subject: Re: debug needed: twl4030 RTC wakeups: repeated attempts fail on Beagle Message-ID: <20120822184211.GA29041@arwen.pp.htv.fi> Reply-To: balbi@ti.com References: <87d32yd1l4.fsf@ti.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Gm-Message-State: ALoCoQniOBeEtmHKnKsup7K7IRyD1sUoQXn+H1Bpe7N5IAiPTW+3vU8veLZuI3hZm6Nl1G7wSsMf Sender: linux-omap-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-omap@vger.kernel.org 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 ? 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 :-) 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"