Received: by 2002:a25:d80d:0:0:0:0:0 with SMTP id p13csp162204ybg; Sat, 23 May 2020 10:13:56 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw2CoXvQpMORniTXLmCN5qRpYamLae1YQYQo6owP+FkEPxYO7ltSezWMd+35mOtleC+BgG/ X-Received: by 2002:a50:ee8e:: with SMTP id f14mr7740227edr.115.1590254036198; Sat, 23 May 2020 10:13:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1590254036; cv=none; d=google.com; s=arc-20160816; b=qqfytcHz35KnDHcfexLPiErT9eLYOHdsBi40NkleehQhyoghC2DPVT+v1ZrLpXEwMs Y4Ru9u06aHhzw6PbmatH7pLayrjXGqQHJKpPU+ZtWCve7S9ryJKb5vgZV9u0KJVfv5TX d5VYH2mRf/rPiYRr6JsGgEy/kEBVGt0p3FaR8SQ4HuO4xDlZ6B/xJ46PdORgzZh6cfmv thMFFqOjPahLlV/0kXiA+5p2hMC/x3qQZBCgiDl4LyulRKFVGj2ozcfOoHHJF8ULyF2k 6fotH4W+AQQzogK2tK+W5LIU0o2k0WSqaUIH6MYKLhv4BhVIfW9hFOviOLqw/gf5aeHo rV9w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from :dmarc-filter:dkim-signature; bh=qvi0VRqlKEMVA/6GmY+485IFJ3sXKzvdCZwty6wFVGo=; b=vl8o6mS4R53vNnaIqvHxtQU/OO/ocXMZay1ydOXdFZ3+RJ52+4YfL6XBetw/g4NAlY 9OrkQW2hq9sdBRIjvpSZw/2hQSNNw81nom+o9SoEJ/bf6LwYMjyGxvMzFiBTpkJpuy8A 3a0TH/boSqMc6VGy2f9kXR7OJSNa/6u7pkPUqdTWYjG+8AL2fZjGGkxweqfKEUHn1Z8k EQoINo6eij41/aQELWjXlEFRCrW4uvXlCY20o4s3KaLd7YpPHx96PwWYDj5K9xbmHWgI YJl/t1T9DFOreMO64Wm/lLAXalsnCvAa0yLwIySXR5YCT/+AQfrcZ8x2SZj5yZYW8BF+ avbw== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@mg.codeaurora.org header.s=smtp header.b=WpzksIlV; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id ch20si7036018ejb.31.2020.05.23.10.13.33; Sat, 23 May 2020 10:13:56 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=fail header.i=@mg.codeaurora.org header.s=smtp header.b=WpzksIlV; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728590AbgEWRLk (ORCPT + 99 others); Sat, 23 May 2020 13:11:40 -0400 Received: from mail27.static.mailgun.info ([104.130.122.27]:48396 "EHLO mail27.static.mailgun.info" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728310AbgEWRLj (ORCPT ); Sat, 23 May 2020 13:11:39 -0400 DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=mg.codeaurora.org; q=dns/txt; s=smtp; t=1590253899; h=Message-Id: Date: Subject: Cc: To: From: Sender; bh=qvi0VRqlKEMVA/6GmY+485IFJ3sXKzvdCZwty6wFVGo=; b=WpzksIlVNGDw+LxVrpemOe4cweaglY+Tg2/j04S3WGl4i1mHSsV5s/CSZLSuhshgHlxos94e SNAlU80zcEwMMDQ6Snv7g4Drxm/7goBTVuw7stiKKNhmafaeyqH1iDXw5CvLapASfcRKBP1q 41Ios7mlSmcoUitX7isWASPamCw= X-Mailgun-Sending-Ip: 104.130.122.27 X-Mailgun-Sid: WyI0MWYwYSIsICJsaW51eC1rZXJuZWxAdmdlci5rZXJuZWwub3JnIiwgImJlOWU0YSJd Received: from smtp.codeaurora.org (ec2-35-166-182-171.us-west-2.compute.amazonaws.com [35.166.182.171]) by mxa.mailgun.org with ESMTP id 5ec9593c.7fc0b43cc1b8-smtp-out-n03; Sat, 23 May 2020 17:11:24 -0000 (UTC) Received: by smtp.codeaurora.org (Postfix, from userid 1001) id 56EF7C433A1; Sat, 23 May 2020 17:11:24 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-caf-mail-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=2.0 tests=ALL_TRUSTED,SPF_NONE autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mkshah-linux.qualcomm.com (blr-c-bdr-fw-01_GlobalNAT_AllZones-Outside.qualcomm.com [103.229.19.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mkshah) by smtp.codeaurora.org (Postfix) with ESMTPSA id 9BE3CC433C6; Sat, 23 May 2020 17:11:18 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org 9BE3CC433C6 Authentication-Results: aws-us-west-2-caf-mail-1.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: aws-us-west-2-caf-mail-1.web.codeaurora.org; spf=none smtp.mailfrom=mkshah@codeaurora.org From: Maulik Shah To: bjorn.andersson@linaro.org, maz@kernel.org, linus.walleij@linaro.org, swboyd@chromium.org, evgreen@chromium.org, mka@chromium.org Cc: linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org, linux-gpio@vger.kernel.org, agross@kernel.org, tglx@linutronix.de, jason@lakedaemon.net, dianders@chromium.org, rnayak@codeaurora.org, ilina@codeaurora.org, lsrao@codeaurora.org, Maulik Shah Subject: [PATCH v2 0/4] irqchip: qcom: pdc: Introduce irq_set_wake call Date: Sat, 23 May 2020 22:41:09 +0530 Message-Id: <1590253873-11556-1-git-send-email-mkshah@codeaurora.org> X-Mailer: git-send-email 2.7.4 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Changes in v2: - Fix compiler error on gpiolib patch This series adds support to lazy disable pdc interrupt. Some drivers using gpio interrupts want to configure gpio for wakeup using enable_irq_wake() but during suspend entry disables irq and expects system to resume when interrupt occurs. In the driver resume call interrupt is re-enabled and removes wakeup capability using disable_irq_wake() one such example is cros ec driver. With [1] in documentation saying "An irq can be disabled with disable_irq() and still wake the system as long as the irq has wake enabled". The PDC IRQs are currently "unlazy disabled" (disable here means that it will be masked in PDC & GIC HW GICD_ISENABLER, the moment driver invokes disable_irq()) such IRQs can not wakeup from low power modes like suspend to RAM since the driver chosen to disable this. During suspend entry, no one re-enable/unmask in HW, even if its marked for wakeup. One solutions thought to address this problem was...During suspend entry at last point, irq chip driver re-enable/unmask IRQs in HW that are marked for wakeup. This was attemped in [2]. This series adds alternate solution to [2] by "lazy disable" IRQs in HW. The genirq takes care of lazy disable in case if irqchip did not implement irq_disable callback. Below is high level steps on how this works out.. a. During driver's disable_irq() call, IRQ will be marked disabled in SW b. IRQ will still be enabled(read unmasked in HW) c. The device then enters low power mode like suspend to RAM d. The HW detects unmasked IRQs and wakesup the CPU e. During resume after local_irq_enable() CPU goes to handle the wake IRQ f. Generic handler comes to know that IRQ is disabled in SW g. Generic handler marks IRQ as pending and now invokes mask callback h. IRQ gets disabled/masked in HW now i. When driver invokes enable_irq() the SW pending IRQ leads IRQ's handler j. enable_irq() will again enable/unmask in HW [1] https://www.spinics.net/lists/kernel/msg3398294.html [2] https://patchwork.kernel.org/patch/11466021/ Maulik Shah (4): gpio: gpiolib: Allow GPIO IRQs to lazy disable pinctrl: qcom: Remove irq_disable callback from msmgpio irqchip pinctrl: qcom: Add msmgpio irqchip flags irqchip: qcom-pdc: Introduce irq_set_wake call drivers/gpio/gpiolib.c | 55 +++++++++++++++++++++++++------------- drivers/irqchip/qcom-pdc.c | 33 ++++++++++++----------- drivers/pinctrl/qcom/pinctrl-msm.c | 15 ++--------- include/linux/gpio/driver.h | 13 +++++++++ 4 files changed, 68 insertions(+), 48 deletions(-) -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation