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=-1.2 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,MAILING_LIST_MULTI,SPF_PASS,T_MIXED_ES 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 EE449C67839 for ; Thu, 13 Dec 2018 09:00:45 +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 BC8D520672 for ; Thu, 13 Dec 2018 09:00:45 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="eN2XQ4Go"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="Xulx05i1" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BC8D520672 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org 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:Date:From:Message-ID:References:To: Subject:In-Reply-To:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=zCgpSWg0NVH7uZrMa+HgEiEMt2zdqrD3EnywmVTDNUU=; b=eN2XQ4GojpJABD Gm6TgR19u0uD1L/+ZDqhV3GKoYa7U08eivrzEf29Ix6b1Bsp8TtRn0sUp5JmKc4nLpEAGYLok8eHR FNTeO9eJu9SMXa7weyqOrWBA/x4HXqLbVA2IhsBcxRpNecA7GEQN3FrZ23fP1r9d+ssMTzem36wL+ V3WVSU5zNcl7XdXOiY8vBeFfDIHQnhmtRK+WRfYDPXU7wcu4LIaQVPzWQYvOr9GWhoJkcjUx/ztNc kNpO9esOb4VudsjpzV83NBrSFBCK+US8fYXqZMvVO2rGIF4fB1qqiHkgu8SR4GJipq+/7/wMTQm0b HT7jxAcHbJA7MvoOX2jQ==; 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 1gXMrM-0007ov-Qd; Thu, 13 Dec 2018 09:00:44 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1gXMrF-0007n6-MQ for linux-arm-kernel@lists.infradead.org; Thu, 13 Dec 2018 09:00:43 +0000 Received: from localhost (unknown [104.132.0.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 2337D20849; Thu, 13 Dec 2018 09:00:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1544691627; bh=n60jGYTA/cKtftl3HoEEGpChDFMsL9X1Zzmy/CGdafY=; h=In-Reply-To:Subject:To:References:From:Cc:Date:From; b=Xulx05i19h7jFFRHMAeXFXCVrfhvV+m6PqVuIvnMWKZ+Olr5aILeaRuptg4Irz3fl bxqTX8WhPe6tndc3U2APdeMKb7lat3wFpJSL4RA08KSzOuhg+Z+UkxPZg2wkGh8ZJn MZrrzcPDJ+PUXd6moutluLNSFavnUTGD4xiQyMkM= MIME-Version: 1.0 In-Reply-To: <20181211141627.GA526@e107981-ln.cambridge.arm.com> Subject: Re: [PATCH 05/12] PCI: aardvark: add suspend to RAM support To: "Rafael J. Wysocki" , Lorenzo Pieralisi References: <20181123141831.8214-1-miquel.raynal@bootlin.com> <1999610.6DN9RK2Tt3@aspire.rjw.lan> <20181204094558.GA24588@e107981-ln.cambridge.arm.com> <1966692.fVZYlVgWHv@aspire.rjw.lan> <20181211141627.GA526@e107981-ln.cambridge.arm.com> Message-ID: <154469162632.19322.13092710881803732022@swboyd.mtv.corp.google.com> From: Stephen Boyd User-Agent: alot/0.8 Date: Thu, 13 Dec 2018 01:00:26 -0800 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20181213_010037_771351_E5A40CDD X-CRM114-Status: GOOD ( 27.92 ) 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: Mark Rutland , Andrew Lunn , Jason Cooper , devicetree@vger.kernel.org, Antoine Tenart , linux-pci@vger.kernel.org, Gregory Clement , Miquel Raynal , linux-kernel@vger.kernel.org, Maxime Chevallier , Nadav Haklai , Rob Herring , Thomas Petazzoni , sudeep.holla@arm.com, Bjorn Helgaas , linux-arm-kernel@lists.infradead.org, Sebastian Hesselbarth 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 Quoting Lorenzo Pieralisi (2018-12-11 06:16:27) > On Tue, Dec 04, 2018 at 10:42:19PM +0100, Rafael J. Wysocki wrote: > > On Tuesday, December 4, 2018 10:45:58 AM CET Lorenzo Pieralisi wrote: > > > On Mon, Dec 03, 2018 at 11:00:20PM +0100, Rafael J. Wysocki wrote: > > > > On Monday, December 3, 2018 4:38:46 PM CET Miquel Raynal wrote: > > > > > > I did not ask my question (that may be silly) properly apologies. I know > > > that the S2R context allows sleeping the question is, in case > > > clk_disable_unprepare() (and resume counterparts) sleeps, > > > > If it just sleeps, then this is not a problem, but if it actually *waits* > > for something meaningful to happen (which I guess is what you really mean), > > then things may go awry. > > > > > what is going to wake it up, given that we are in the S2R NOIRQ phase and as > > > you said the action handlers (that are possibly required to wake up the eg > > > clk_disable_unprepare() caller) are disabled (unless, AFAIK, > > > IRQF_NO_SUSPEND is passed at IRQ request time in the respective driver). > > > > So if it waits for an action handler to do something and wake it up, it may > > very well deadlock. I have no idea if that really happens, though. > > > > > The clk API implementations back-ends are beyond my depth, I just wanted > > > to make sure I understand how the S2R flow is expected to work in this > > > specific case. > > > > Action handlers won't run unless the IRQs are marked as IRQF_NO_SUSPEND > > (well, there are a few more complications I don't recall exactly, but > > that's the basic rule). If anything depends on them to run, it will block. > > Stephen, any comments on this ? Sorry I seemed to miss this email. BTW, what is an "action handler" here? The IRQ action handler? > I would like to understand if it is safe > to call a clk_*unprepare/prepare_* function (that may have a blocking > back-end waiting on a wake-up event triggered by an IRQ action) in the > suspend/resume NOIRQ phase. Does this ever occur in practice? I imagine "blocking back-end waiting on a wake-up event" would be some sort of i2c or SPI based "slow" clk that is prepared/unprepared in the NOIRQ phase of suspend/resume? So that function call into the clk API fails because the i2c or SPI controller used to toggle the clk on/off state relies on the controller's IRQ to manage the transaction over the bus but that IRQ is disabled. I suppose this is possible but I've never heard of it happening in practice. Do you have such a scenario? > > It is not clear how the unprepare/prepare() callers can possibly know > whether it is safe to block at that stage given that IRQ actions are > suspended and the wake-up may never trigger. > Is this solved in other situations somehow? I don't think clk consumers have any idea that things are safe or not safe to use in the NOIRQ phase of suspend, but I also don't see how clks are special here. Any provider consumer pattern would fall into the same trap, but maybe clks are the first ones to get here. It seems like a larger problem with NOIRQ suspend in general and how it is too coarse of a solution for suspend ordering of devices. It's not like we need *all* device interrupts to be disabled to do something in suspend with one particular device. Most likely, we just need the device and all it's children to be suspended and this device to have it's IRQ disabled for the NOIRQ suspend callback to work. (Maybe any devices it's supplying with device links too?) If that's really the case, then I can see how one device and it's children are suspended and the irq for it is disabled but the providing devices (clk, regulator, bus controller, etc.) are still fully active and not suspended but in fact completely usable and able to service interrupts. If that all makes sense, then I would answer the question with a definitive "yes it's all fine" because the clk consumer could be in the NOIRQ phase of its suspend but the clk provider wouldn't have even started suspending yet when clk_disable_unprepare() is called. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel