Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp2946142imm; Fri, 10 Aug 2018 00:46:29 -0700 (PDT) X-Google-Smtp-Source: AA+uWPxdhjDDFNB8pOmX1TGeCa8J9tFQdxMK+ACTRj31PrzotzMN/W7UFPmPi6snSTDWYxkoaEnT X-Received: by 2002:a17:902:28aa:: with SMTP id f39-v6mr5141792plb.150.1533887189038; Fri, 10 Aug 2018 00:46:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1533887189; cv=none; d=google.com; s=arc-20160816; b=LKoSDyL0TbaerEVzCGNp+gaFukEc7JFgmre+4i2dID6u6vWdLX9SnSRBFiL4HY3YT4 XSJnDbjHn+kTSiifGKINraj1pvZDCMbu8+HeZWLmZSB1YzAAqQdqcJNNQZNlcMtme6qq Bi1hDQfB3RuFIKyl6VnJCgJMLkIp2E4CB/LFVEr9XKgGEgxvzX7m4Sd8q7Tyn7uDWWBI 25sQzh5ChH6N+uV+39lKFcX2l4R5HFQYoQcOOzrkzY30nvDc/MBHektteWpmtKBxqnjO 9O1oRR/VpsmTsGbkzqHrJnA8YrPVADM6y9q5tnTMrNk3S/gYJmBMcHq2ZkCU71KZ/Hqt 3njg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:organization:user-agent :references:in-reply-to:subject:cc:to:from:message-id:date :arc-authentication-results; bh=LfoPka4I75gVggP+5rJxsHjyBT0JXrf0CTYBLuZziWE=; b=P/JsZcBogyhxchgpJy3btLBfm4sumYYt0+NcaAIc5Sdkb+6tstFQAL1sDUBNf5jTgi q9WiHpVWWzAd5A5vHRnoVs+OaT3cu0rRBSC6QHXBZiA0Pa+b3OERHz9wAMqZWnXAaNcF +xJSXYraaWE3b7c26Rf4p03aihkqzlEyI/Zs5ORvJZiD2vn0EauAJ6PdYxFWgh6merYr 2F2Pq0BcZAjeNCFg7tGtGF+fDSC4UZcsTqNrzwj7iZuXxhKieRL23MzqD7qKmXb0B93u xboGz0T5WHYU3ioJvnedeRSgJs/zWoCNaX2j28aremXcFIwMbIltpmaDQwnl+YETWA0K Dpvg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id j10-v6si7134483plg.499.2018.08.10.00.46.12; Fri, 10 Aug 2018 00:46:29 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727693AbeHJKN6 (ORCPT + 99 others); Fri, 10 Aug 2018 06:13:58 -0400 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:33778 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727028AbeHJKN6 (ORCPT ); Fri, 10 Aug 2018 06:13:58 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 5F67680D; Fri, 10 Aug 2018 00:45:18 -0700 (PDT) Received: from big-swifty.misterjones.org (usa-sjc-mx-foss1.foss.arm.com [217.140.101.70]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id D66B23F5B3; Fri, 10 Aug 2018 00:45:15 -0700 (PDT) Date: Fri, 10 Aug 2018 08:45:12 +0100 Message-ID: <86wosypsvr.wl-marc.zyngier@arm.com> From: Marc Zyngier To: Stephen Boyd Cc: Lina Iyer , evgreen@chromium.org, linus.walleij@linaro.org, bjorn.andersson@linaro.org, rplsssn@codeaurora.org, linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org, rnayak@codeaurora.org, devicetree@vger.kernel.org Subject: Re: [PATCH RESEND RFC 1/4] drivers: pinctrl: qcom: add wakeup capability to GPIO In-Reply-To: <153383585322.220756.9422019201626837843@swboyd.mtv.corp.google.com> References: <20180801020021.9782-1-ilina@codeaurora.org> <20180801020021.9782-2-ilina@codeaurora.org> <86600uy4vh.wl-marc.zyngier@arm.com> <20180801194538.GA6422@codeaurora.org> <86wot9wb9u.wl-marc.zyngier@arm.com> <20180802065104.GA27850@codeaurora.org> <86sh3xw7m9.wl-marc.zyngier@arm.com> <20180802125827.GB27850@codeaurora.org> <153370830708.220756.4595316550560511917@swboyd.mtv.corp.google.com> <20180808072632.21f076b6@why.wild-wind.fr.eu.org> <153383585322.220756.9422019201626837843@swboyd.mtv.corp.google.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 EasyPG/1.0.0 Emacs/25.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) Organization: ARM Ltd MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 09 Aug 2018 18:30:53 +0100, Stephen Boyd wrote: > > Quoting Marc Zyngier (2018-08-07 23:26:32) > > On Tue, 07 Aug 2018 23:05:07 -0700 > > Stephen Boyd wrote: > > > > > Quoting Lina Iyer (2018-08-02 05:58:27) > > > > On Thu, Aug 02 2018 at 01:27 -0600, Marc Zyngier wrote: > > > > > > > > > >Sure. But once woken up (GIC *and* TLMM), the gpio line (which I > > > > >assume is level) is still high at the TLMM input. So why isn't it > > > > >registering that state once it has been woken up? > > > > > > > > > >I can understand that it would be missing an edge. But that doesn't > > > > >hold for level signalling. > > > > > > > > > Sure, yes. Sorry for not registering your point in my response. > > > > Once woken up we should see the level interrupt in TLMM. > > > > > > And the level type gpio interrupt will trigger the TLMM summary > > > interrupt line after the wakeup? So then the only thing that needs to be > > > replayed is edge interrupts? How are edge interrupts going to be > > > replayed? > > > > Level interrupts should be taken care of without doing anything, by the > > very nature of being a level signal. > > Right. I suspect we'll still need to configure the PDC to actually wake > up on the level triggered signal though so PDC needs to be told to > unmask the line. Surely this can be done at suspend time with the PDC driver tracking the interrupts that are configured as a wake-up source (although it needs to track an interrupt that is logically connected to the TLMM, which sucks). > > Edge interrupts should be replayed using check_irq_resend() after > > taking the right locks and making the interrupt pending. Or, if there > > is a way for SW to make the interrupt pending at the TLMM level, to use > > that as a way to reinject the interrupt (which would be the preferred > > way, as it avoids all kind of ugly locking considerations). > > > > Ok. Looking at the hardware it seems that I can write the interrupt > status bit directly for an edge type interrupt and that causes the > interrupt handler to run. So that's good news, we can use that ability > to directly inject interrupts here. That's pretty good news. It means that if TLMM implements the irq_set_irqchip_state() API, there isn't muc that needs doing, and most of the original ugliness can go. At least I hope. M. -- Jazz is not dead, it just smell funny.