From patchwork Thu Sep 13 05:33:28 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Felipe Balbi X-Patchwork-Id: 1450211 Return-Path: X-Original-To: patchwork-linux-arm@patchwork.kernel.org Delivered-To: patchwork-process-083081@patchwork2.kernel.org Received: from merlin.infradead.org (unknown [205.233.59.134]) by patchwork2.kernel.org (Postfix) with ESMTP id 3C928DF24C for ; Thu, 13 Sep 2012 05:49:31 +0000 (UTC) Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.76 #1 (Red Hat Linux)) id 1TC27s-0005oH-N1; Thu, 13 Sep 2012 05:38:08 +0000 Received: from na3sys009aog138.obsmtp.com ([74.125.149.19]) by merlin.infradead.org with smtps (Exim 4.76 #1 (Red Hat Linux)) id 1TC27p-0005nQ-8F for linux-arm-kernel@lists.infradead.org; Thu, 13 Sep 2012 05:38:06 +0000 Received: from mail-lpp01m010-f49.google.com ([209.85.215.49]) (using TLSv1) by na3sys009aob138.postini.com ([74.125.148.12]) with SMTP ID DSNKUFFxOnZFBFXFBe8Lvpj1faioNwEpEQZ1@postini.com; Wed, 12 Sep 2012 22:38:04 PDT Received: by lagu2 with SMTP id u2so1605924lag.36 for ; Wed, 12 Sep 2012 22:38:01 -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=7T4J9Dlz3r03lIsHPPL/KFidSSC7VQFTamrYKXAOMr4=; b=hogq7CqKCngT70EM9FMsnstOdEHNfpXZOXN0o8ynXMDTqEkrzJfavCFiTkV1jaf1nc U17knbdkzyNruU57ymL/KkLwcTkIJQ2UwM54rziBEEzAnRdIlF3jyzsQ9nDf4ofgvYud uCNkpAG5NpvDzSQm7hJOkn9liWLN3gsqvNSiMRB9+d2q2f7gw6G0768dFrw3OFQpB/vO Wy4oMPF+lDO8nTN+WP8nGBcE8NP+atcYLkP5ITBG1BfpLIwGxW3MeLl1fPbLH/4CaWD7 1wgh7ppkcQ2d/41PPrUUyxJoURmm6z9RJTftPXOekolkgBTFLjnRhSLMP5e6TsTDV13w Cx7Q== Received: by 10.152.103.11 with SMTP id fs11mr692695lab.23.1347514681383; Wed, 12 Sep 2012 22:38:01 -0700 (PDT) Received: from localhost (cs78217178.pp.htv.fi. [62.78.217.178]) by mx.google.com with ESMTPS id y4sm5781603lbg.5.2012.09.12.22.37.59 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 12 Sep 2012 22:38:00 -0700 (PDT) Date: Thu, 13 Sep 2012 08:33:28 +0300 From: Felipe Balbi To: Kevin Hilman Subject: Re: [PATCHv8 00/23]I2C big cleanup Message-ID: <20120913053325.GC6504@arwen.pp.htv.fi> References: <1347447496-16793-1-git-send-email-shubhrajyoti@ti.com> <874nn2vpv9.fsf@deeprootsystems.com> MIME-Version: 1.0 In-Reply-To: <874nn2vpv9.fsf@deeprootsystems.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Gm-Message-State: ALoCoQmifrVVQ+/RZhfoG8Gj9bowbdAZv5YJxSVjFlUESCUbTqM0F4OLrcMbTdWNUpX4ekUrjLy7 X-Spam-Note: CRM114 invocation failed X-Spam-Score: -4.2 (----) X-Spam-Report: SpamAssassin version 3.3.2 on merlin.infradead.org summary: Content analysis details: (-4.2 points) pts rule name description ---- ---------------------- -------------------------------------------------- -2.3 RCVD_IN_DNSWL_MED RBL: Sender listed at http://www.dnswl.org/, medium trust [74.125.149.19 listed in list.dnswl.org] -0.0 SPF_PASS SPF: sender matches SPF record -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] Cc: tony@atomide.com, w.sang@pengutronix.de, linux-i2c@vger.kernel.org, ben-linux@fluff.org, linux-omap@vger.kernel.org, Shubhrajyoti D , linux-arm-kernel@lists.infradead.org X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: balbi@ti.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-arm-kernel-bounces@lists.infradead.org Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org On Wed, Sep 12, 2012 at 03:27:22PM -0700, Kevin Hilman wrote: > Shubhrajyoti D writes: > > [...] > > > > > This is the cleanup only series. > > > > Tested on omap4sdp and 3430sdp. > > It would be extremely helpful if you would describe how this was tested. > And for me, it would be a source of extreme joy if you described any PM > testing. > > I gave this some additional PM testing on 3430/n900, 3530/Overo, > 3730/OveroSTORM, 3730/Beagle-xM and 4430/Panda. > > I tested v3.6-rc5 which passed all PM tests and then added this series > (by merging the i2c-embedded/i2c-next branch.) PM tests then fail. > > At least on 3530/Overo and 3730/Overo, CORE no longer hits retenion (or > off) during idle. > > The easy way to notice this is to see that even when no i2c transactions > are happening, the runtime PM status for omap_i2c.1 is remains 'active': > > # cat omap_i2c.*/power/runtime_status > active > suspended > > Of course that means that clocks are never gated during idle, and CORE > will never hit retention. > > I noticed it because my PM tests detected that the CORE powerdomain was > not transitioning to retention (or off) during idle. > > To reproduce, simply enable UART timeouts so CORE will hit retention: > > echo 3000 > /sys/devices/platform/omap_uart.0/power/autosuspend_delay_ms > echo 3000 > /sys/devices/platform/omap_uart.1/power/autosuspend_delay_ms > echo 3000 > /sys/devices/platform/omap_uart.2/power/autosuspend_delay_ms > echo 3000 > /sys/devices/platform/omap_uart.3/power/autosuspend_delay_ms > > and check the core_pwrm state counters: > > cat /debug/pm_debug/count > > wait > 3 seconds for the UART autosuspend timers to kick in. At this > point, CORE should be transitioning to retenion in idle (determined by > noticing that the RET counter for core_pwrdm is increasing.) I just ran same tests on pandaboard and i2c is suspended actually, though no power domain transitions to RET. Do we not have retention while idle on pandaboard ? See below for a few results... First I ran this script to set everything up: #!/bin/sh echo "mounting proc" mount -t proc none /proc echo "mounting sysfs" mount -t sysfs none /sys echo "mounting debugfs" mount -t debugfs none /debug echo "UART autosuspend delay" echo 3000 > /sys/devices/platform/omap_uart.0/power/autosuspend_delay_ms echo 3000 > /sys/devices/platform/omap_uart.1/power/autosuspend_delay_ms echo 3000 > /sys/devices/platform/omap_uart.2/power/autosuspend_delay_ms echo 3000 > /sys/devices/platform/omap_uart.3/power/autosuspend_delay_ms echo "check omap_i2c.* status" cat /sys/devices/platform/omap_i2c.*/power/runtime_status echo "check CORE pm counters" grep "^core_pwrdm" /debug/pm_debug/count Then I triggered a few i2c transfers by reading regulator status through sysfs: # cat /sys/class/regulator/regulator.*/status [ 507.469299] omap_i2c omap_i2c.1: omap_i2c_runtime_resume normal normal off off normal normal normal normal normal off # [ 509.010711] omap_i2c omap_i2c.1: omap_i2c_runtime_suspend cat /sys/devices/platform/omap_i2c.*/power/runtime_status suspended suspended suspended suspended notice the prints I've added... I don't know what could go wrong only on Overo that i2c doesn't suspend. Can you add this debugging patch just for me to see if, at least, omap_i2c_runtime_suspend is being called ? this is on top of Wolfram's for-next branch, btw. Maybe you should also add: CONFIG_I2C_DEBUG_CORE=y CONFIG_I2C_DEBUG_ALGO=y CONFIG_I2C_DEBUG_BUS=y to your .config just in case. cheers diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index c78431a..ac61664 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -1238,6 +1238,8 @@ static int omap_i2c_runtime_suspend(struct device *dev) struct omap_i2c_dev *_dev = platform_get_drvdata(pdev); u16 iv; + dev_info(dev, "%s\n", __func__); + _dev->iestate = omap_i2c_read_reg(_dev, OMAP_I2C_IE_REG); omap_i2c_write_reg(_dev, OMAP_I2C_IE_REG, 0); @@ -1277,6 +1279,8 @@ static int omap_i2c_runtime_resume(struct device *dev) if (_dev->iestate) omap_i2c_write_reg(_dev, OMAP_I2C_IE_REG, _dev->iestate); + dev_info(dev, "%s\n", __func__); + return 0; } #endif /* CONFIG_PM_RUNTIME */