Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp6548513imm; Mon, 27 Aug 2018 18:48:15 -0700 (PDT) X-Google-Smtp-Source: ANB0VdbNhfpgLwhjT6CKI9+Jqh6OrqD5+iHF2a7m49EEl6PnUNuJwuItDcOzrnl+v2mNEnYZvtdi X-Received: by 2002:a63:fe02:: with SMTP id p2-v6mr14605828pgh.148.1535420895825; Mon, 27 Aug 2018 18:48:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1535420895; cv=none; d=google.com; s=arc-20160816; b=lWTDrxGywZ5DXf+r9y+oeMGdefofzk4eFE9OWbwdz2nr4n6yy9bORW5kHZpIcoCwY+ FbDxWSJ5f05uQKgzUVmyoH6IA4xsjaaD5cPXt7tbcJ3zPkg4f2yTtx60OfvLbAAXuswE Kbr3SGHS9jUE7QhN3c6oI9NBkEtsrT8Ye40xecQEA6uhdCrlVjGNMsZ2+/ugYkFrBo9Y lSYVzpn6pMMXLVMh8rW3xfc71NhCls6S+W9IJO2RfSpuEMtuAnzIvlDwRo5NtgHAV08S +jNmf2t8GFTARHLeHnPj8GwdtQP2E+SXJkKM3hvPEBJAJDGjETFz3Q2cpYWeC+8D8ktb m1vA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dmarc-filter:dkim-signature:dkim-signature :arc-authentication-results; bh=5wKsp0xv9VRbevN6rDewt5HgK5JOITtSqgugBr3bl8g=; b=aay3cU+rEhDxBAKaemlBplpM559e0jZO4ZKS0ZlS3vlHkPYrOhJRGC4xFGgXaCyhnT NVgPzHHD7+ObJZygQhYHjrBBj+DOMdy6mQBi1eHS/j7qGezS1bB2bz2ynLC8QpwO2fUS 1XcmC9gO+j2+89Qxmr/7gA9LmXSPe5bO/8hLyVxYUs6w/p8omOKCpuWF87yh0aHHWTsN FLCXG4Jc7twvOU2WIwBOMotb1n55NAnmjChATJdv3MUwoS0cvuTGsjgyYUlG7owlMK9b XBz3cX5M4/mzFCTiTFslmRGLTrzanqB8sfFPknEMexpApAVrE4RrHgdnA6Gov9Z9FPHP zXHw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@codeaurora.org header.s=default header.b="K8M9DWn/"; dkim=pass header.i=@codeaurora.org header.s=default header.b=WAvCrM0L; 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 x25-v6si858147pfi.138.2018.08.27.18.47.59; Mon, 27 Aug 2018 18:48:15 -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; dkim=pass header.i=@codeaurora.org header.s=default header.b="K8M9DWn/"; dkim=pass header.i=@codeaurora.org header.s=default header.b=WAvCrM0L; 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 S1727043AbeH1FgJ (ORCPT + 99 others); Tue, 28 Aug 2018 01:36:09 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:37534 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725724AbeH1FgJ (ORCPT ); Tue, 28 Aug 2018 01:36:09 -0400 Received: by smtp.codeaurora.org (Postfix, from userid 1000) id 71452604BE; Tue, 28 Aug 2018 01:46:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1535420814; bh=oaJgHnfIpOR5sk6Ay/x8VJ0oN7Ql+s8IyzsO1rZEL/s=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=K8M9DWn/XNyXLbUoF3C8APgPrDRn13rgHtBOqNGZXWXc/3GxpJUUv4O2SD52cgZU0 S7EUmTKD6dSQ6cL4oOg2ITORBZ2eU0679kghW1lLyUAvYG8UpxCCzfl54Eur4Mwnv1 MXxI7YZqvEHyNkxa+69Waq+CXa/JOZxRJBWg7SVU= X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on pdx-caf-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.8 required=2.0 tests=ALL_TRUSTED,BAYES_00, DKIM_SIGNED,T_DKIM_INVALID autolearn=no autolearn_force=no version=3.4.0 Received: from localhost (i-global254.qualcomm.com [199.106.103.254]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: ilina@smtp.codeaurora.org) by smtp.codeaurora.org (Postfix) with ESMTPSA id 1301C60271; Tue, 28 Aug 2018 01:46:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1535420813; bh=oaJgHnfIpOR5sk6Ay/x8VJ0oN7Ql+s8IyzsO1rZEL/s=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=WAvCrM0L0vKPZG0W5H0yzx8A26VcUqy2JFgv793dJzz15CvToAs8jsxdi6/Iciuwi 1wBEzV8tPYwihWVPz1g8bFL9fQkKKK/qngxI+02sSulS0N8dV7Pb5H+POWKhWCE6yI uXr4LjTpPh+mL2owkQDqxVuwiTlnYmGOMurjrmes= DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org 1301C60271 Authentication-Results: pdx-caf-mail.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: pdx-caf-mail.web.codeaurora.org; spf=none smtp.mailfrom=ilina@codeaurora.org Date: Mon, 27 Aug 2018 19:46:52 -0600 From: Lina Iyer To: Bjorn Andersson Cc: Linus Walleij , Hans Verkuil , Hans Verkuil , Marc Zyngier , Stephen Boyd , evgreen@chromium.org, rplsssn@codeaurora.org, "linux-kernel@vger.kernel.org" , linux-arm-msm@vger.kernel.org, Rajendra Nayak , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , Andy Gross , Doug Anderson Subject: Re: [PATCH v2 1/5] drivers: pinctrl: qcom: add wakeup capability to GPIO Message-ID: <20180828014652.GB13998@codeaurora.org> References: <20180817163849.30750-1-ilina@codeaurora.org> <20180817163849.30750-2-ilina@codeaurora.org> <20180827165644.GR5081@codeaurora.org> <20180828002641.GC2523@minitux> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20180828002641.GC2523@minitux> User-Agent: Mutt/1.10.0 (2018-05-17) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Aug 27 2018 at 18:26 -0600, Bjorn Andersson wrote: >On Mon 27 Aug 09:56 PDT 2018, Lina Iyer wrote: > >> On Sun, Aug 26 2018 at 08:33 -0600, Linus Walleij wrote: >> > On Fri, Aug 17, 2018 at 6:39 PM Lina Iyer wrote: >> > >> > > QCOM SoC's that have Power Domain Controller (PDC) chip in the always-on >> > > domain can wakeup the SoC, when interrupts and GPIOs are routed to the >> > > its interrupt controller. Only select GPIOs that are deemed wakeup >> > > capable are routed to specific PDC pins. During low power state, the >> > > pinmux interrupt controller may be non-functional but the PDC would be. >> > > The PDC can detect the wakeup GPIO is triggered and bring the TLMM to an >> > > operational state. >> > > >> > > Interrupts that are level triggered will be detected at the TLMM when >> > > the controller becomes operational. Edge interrupts however need to be >> > > replayed again. >> > > >> > > Request the corresponding PDC IRQ, when the GPIO is requested as an IRQ, >> > > but keep it disabled. During suspend, we can enable the PDC IRQ instead >> > > of the GPIO IRQ, which may or not be detected. >> > > >> > > Signed-off-by: Lina Iyer >> > > --- >> > > Changes in v1: >> > > - Trigger GPIO in h/w from PDC IRQ handler >> > > - Avoid big tables for GPIO-PDC map, pick from DT instead >> > > - Use handler_data >> > >> > Just for the record this is an impressive and much needed patch >> > set, no other SoC developer has yet taken on the task of making this >> > work so I very much appreciate that Qualcomm show the way. >> > >> > > +static int msm_gpio_pdc_pin_request(struct irq_data *d) >> > > +static int msm_gpio_pdc_pin_release(struct irq_data *d) >> > > +static int msm_gpio_irq_reqres(struct irq_data *d) >> > > +{ >> > (...) >> > > + if (gpiochip_lock_as_irq(gc, irqd_to_hwirq(d))) { >> > (...) >> > > +static void msm_gpio_irq_relres(struct irq_data *d) >> > > +{ >> > > + gpiochip_unlock_as_irq(gc, irqd_to_hwirq(d)); >> > > +} >> > >> > FYI Hans Verkuil is working on a patch set that moves the >> > lock/unlock as IRQ call to the irqchip request() and release() >> > functions so we can switch a GPIO irqchip line from IRQ >> > mode to say output at runtime without too much trouble. >> > (CEC needs this.) >> > >> Thanks, I will look into Hans's RFCv2. But what would help me would be >> to avoid creating the IRQ for the GPIO itself (I have the latent IRQ), >> if I could just return that instead in gpio_to_irq(), it might be >> easier. I understand ->to_irq() is supposed to be a translate function >> only, I can avoid the dance of enabling and diabling the PDC IRQ on >> suspend and resume. >> > >I did implement gpio_to_irq() like this in the PMIC gpio/mpp drivers and >we've since concluded that we need to move this to some hierarchical >interrupt controller, because people like Linus expect to be able to say > > interrupts = <&gpio_controller 1 IRQ_TYPE_EDGE_RISING> > >which is something used all over the place with the TLMM driver today. Does it have to be &gpio_controller, can it be another interrupt controller? Say, interrupts-extended = <&pdc 1 IRQ_TYPE_EDGE_RISING>; -- Lina