From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tony Lindgren Subject: Re: [PATCH] gpio: gpio-omap: take pm_runtime usage while IRQs are claimed Date: Wed, 10 Apr 2019 12:38:04 -0700 Message-ID: <20190410193804.GM2839@atomide.com> References: <20190408194506.25821-1-tony@atomide.com> <4915fcdd-fb07-28c4-e530-d2559b8518ad@ti.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <4915fcdd-fb07-28c4-e530-d2559b8518ad@ti.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=m.gmane.org@lists.infradead.org To: Grygorii Strashko Cc: Tero Kristo , Bartosz Golaszewski , Keerthy , Linus Walleij , Aaro Koskinen , Peter Ujfalusi , linux-gpio@vger.kernel.org, Russell King , linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org List-Id: linux-gpio@vger.kernel.org * Grygorii Strashko [190410 18:17]: > I'm very sorry, but what was the regression exactly? > Can't enter RTC+DDR state? some crash? AFAIK fails to enter RTC+DDR suspend because of conditional PM runtime handling. > We have in driver: > irqc->parent_device = dev; > > which means: > request_threaded_irq() > irq_chip_pm_get() > if (IS_ENABLED(CONFIG_PM) && data->chip->parent_device) { > retval = pm_runtime_get_sync(data->chip->parent_device); > > and power.usage_count will be incremented every time GPIO irq is requested. > > only in free_irq() (or in case of error) power.usage_count is decremented. > > Now above change will introduce just another incrementation of power.usage_count > How is it helping? Oh OK, that means we can simplify things further and drop those changes then. I'll post v2 version shortly with updated subject and description. Regards, Tony From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.5 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS, URIBL_BLOCKED,USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8E409C10F11 for ; Wed, 10 Apr 2019 19:38:15 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 5F02320830 for ; Wed, 10 Apr 2019 19:38:15 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="UCHtB/37" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5F02320830 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=atomide.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=6PtCHnFY93tyIOpnTjtEiTIr4+tuLJC6z4dhSS0sukw=; b=UCHtB/37QaeCrC r2twMXZLfuVy6XGkp7zFbBplaLRF70lo7/uSsBrIoQmZEcdY7is5pgdAflMKhP8sWk1vRZQyOSfvA e7YdNPLVl/X5sqnzNE5AAUGZeYXDVTtwHu3Petner7Aj1q9qMtr0qSNmW0jf1GYRUxr74DsXSpW8r x4gPIXdM0jy77Jj9caZDClInkNdjb5qnpYV2+KQB+JP8KbElVG7pvkEHjsAtZ/NCUbeaLWEiVbWto 9LWWZpTDpzlv5CiOT2q1jAjgz/2zejl3qaeJtNbPVU+/uxi5MgbWAhMAXNYwKjUVt6+OYsPLa/sPs vgHVdKwwMYk9B8HiksTQ==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1hEJ30-00018X-MG; Wed, 10 Apr 2019 19:38:14 +0000 Received: from muru.com ([72.249.23.125]) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1hEJ2x-00017y-Rt for linux-arm-kernel@lists.infradead.org; Wed, 10 Apr 2019 19:38:13 +0000 Received: from atomide.com (localhost [127.0.0.1]) by muru.com (Postfix) with ESMTPS id 508F980B6; Wed, 10 Apr 2019 19:38:23 +0000 (UTC) Date: Wed, 10 Apr 2019 12:38:04 -0700 From: Tony Lindgren To: Grygorii Strashko Subject: Re: [PATCH] gpio: gpio-omap: take pm_runtime usage while IRQs are claimed Message-ID: <20190410193804.GM2839@atomide.com> References: <20190408194506.25821-1-tony@atomide.com> <4915fcdd-fb07-28c4-e530-d2559b8518ad@ti.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <4915fcdd-fb07-28c4-e530-d2559b8518ad@ti.com> User-Agent: Mutt/1.11.4 (2019-03-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190410_123811_945021_74C69CBC X-CRM114-Status: UNSURE ( 7.05 ) X-CRM114-Notice: Please train this message. X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Tero Kristo , Bartosz Golaszewski , Keerthy , Linus Walleij , Aaro Koskinen , Peter Ujfalusi , linux-gpio@vger.kernel.org, Russell King , linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org * Grygorii Strashko [190410 18:17]: > I'm very sorry, but what was the regression exactly? > Can't enter RTC+DDR state? some crash? AFAIK fails to enter RTC+DDR suspend because of conditional PM runtime handling. > We have in driver: > irqc->parent_device = dev; > > which means: > request_threaded_irq() > irq_chip_pm_get() > if (IS_ENABLED(CONFIG_PM) && data->chip->parent_device) { > retval = pm_runtime_get_sync(data->chip->parent_device); > > and power.usage_count will be incremented every time GPIO irq is requested. > > only in free_irq() (or in case of error) power.usage_count is decremented. > > Now above change will introduce just another incrementation of power.usage_count > How is it helping? Oh OK, that means we can simplify things further and drop those changes then. I'll post v2 version shortly with updated subject and description. Regards, Tony _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel