From patchwork Wed Aug 22 15:06:31 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Shubhrajyoti Datta X-Patchwork-Id: 1361891 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 514D03FD40 for ; Wed, 22 Aug 2012 15:06:49 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932337Ab2HVPGn (ORCPT ); Wed, 22 Aug 2012 11:06:43 -0400 Received: from na3sys009aog119.obsmtp.com ([74.125.149.246]:34717 "EHLO na3sys009aog119.obsmtp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932736Ab2HVPGi (ORCPT ); Wed, 22 Aug 2012 11:06:38 -0400 Received: from mail-vc0-f177.google.com ([209.85.220.177]) (using TLSv1) by na3sys009aob119.postini.com ([74.125.148.12]) with SMTP ID DSNKUDT1eKMFAzgeZAXh86mUd7WAOM2Fb673@postini.com; Wed, 22 Aug 2012 08:06:38 PDT Received: by vcbfl13 with SMTP id fl13so1208589vcb.36 for ; Wed, 22 Aug 2012 08:06:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=+5JMePPtpRKEeK8PbUqFnoqUegA4Pya8V9uZeiy7MII=; b=EimLqWatTGYxqTN3pLFx6xo2nzIAMBc51WtCUVPPa05kpfWNGzPobrSa1CVjvIlLec DxRjXmx0GNU7ImdVyEzpPpwsZQJMwkP+oZuyWTtFICCdFwlALp+V1dXjHB0AFFEosLxb vK8rtWqpA8I3Zlz5/rMn/taYKSNmJdaEOf+a2bRIukgHYLME/2BcVK3ooi+WpVcXQNLN foNd/+rlhUKRhOYpz8N9MwV1KLK8ObSTTunNzXtiFA18AUsoACkhqwkCqlFakKq7tuAW wATgHFGWN6EVMvYyjC7tCUjWxdACe1M9YOb+eB4TtGi39WBdQ10/RhUAQVnQlJiz29Hs 1jjQ== MIME-Version: 1.0 Received: by 10.52.72.79 with SMTP id b15mr14328149vdv.13.1345647991591; Wed, 22 Aug 2012 08:06:31 -0700 (PDT) Received: by 10.58.79.18 with HTTP; Wed, 22 Aug 2012 08:06:31 -0700 (PDT) In-Reply-To: <87d32yd1l4.fsf@ti.com> References: <87d32yd1l4.fsf@ti.com> Date: Wed, 22 Aug 2012 20:36:31 +0530 Message-ID: Subject: Re: debug needed: twl4030 RTC wakeups: repeated attempts fail on Beagle From: "Datta, Shubhrajyoti" To: Kevin Hilman Cc: linux-omap , NeilBrown , Russ Dill X-Gm-Message-State: ALoCoQn9qapvo+UZZ5SaQDahYBCkhH1mxlfoLMBhUDIO0rxbESsj2B9SW0iKVJzqZCI1ir91Nzi7 Sender: linux-omap-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-omap@vger.kernel.org On Sat, Aug 11, 2012 at 12:19 AM, Kevin Hilman wrote: > Hello, > > In doing some automated testing of suspend/resume I noticed that > repeated attempts to suspend and resume via RTC wakeup fail on > 3530/Beagle and 3730/Beagle-xM, but work fine on 3430/n900, 3530/Overo, > 3730/OveroSTORM and 4430/Panda. > > When RTC wakeup fails, a UART wakeup will work, and in the logs, you'll > see this: > > [ 316.036132] twl: i2c_read failed to transfer all messages > [ 316.036163] twl4030: I2C error -13 reading PIH ISR The error value is is propagated from the i2c get_sync failure. > > My guess about what might be happening is that very late in the suspend > process (during the noirq hooks), a PMIC interrupt fires, but by this > time the I2C driver is runtime suspended (and clock gated.) Since > runtime PM is disabled at this point, I2C reads fail, so the twl4030 IRQ > driver cannot talk over I2C to the PMIC to determine the interrupt > source. Agreed. > > 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. > > Reproducing is easy. Simply run rtcwake in a loop: > > # while true; do rtcwake -m mem -s 1; done > > In my tests, this happens using omap2plus_defconfig (+ initramfs) on > v3.6-rc1, v3.5, v3.4, v3.3 but seems to work fine on v3.2. > > I'm going on vacation for a few weeks, so any help debugging this would > be greatly appreciated. > > Thanks, > > Kevin > -- > To unsubscribe from this list: send the line "unsubscribe linux-omap" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html --- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html 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.