Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp2656562ybb; Mon, 30 Mar 2020 10:18:32 -0700 (PDT) X-Google-Smtp-Source: ADFU+vvoo4eNtBL2DCPmSyAcmkOs93BUsXXrwgbDM975k7izrhMEiTcO46FPSJOAkKe+69AZ5OQ3 X-Received: by 2002:a05:6820:122:: with SMTP id i2mr10245144ood.73.1585588712110; Mon, 30 Mar 2020 10:18:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1585588712; cv=none; d=google.com; s=arc-20160816; b=QTnK3sAxgcr1bYjkrLumVVpbx6K4icT4z3MfwGTSMh9i1xPvbcZ4ol67LSrDh3sg4n 4Ab8QrKfFgSNEI7Y6a8S/EPaNnZ0lDtEr2l/p6h4CQRQJ0l51xfMdFh0d/4loCocj8Ld NTguPQrqcFOZ0DtKmIyyNkZCCYM4pF6Q8zrNJtpN7mErVS67Hnl/0xCDKXT1zSM3O1R4 c83p3Ux9/RJ75e/uJumqhc0V+D8dxJGOakqiN8vovcgl/PLLxy4EbKmpb6bCpsgivvf0 HuPeP5ofXahSkg24Pqt2aRw9UNGCxoPEDK2ax8Ze2X98/isRpj6Zb5X2k1E/1HrmqcsF cawA== 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=SJTDBgvtt/m4QfLexp01DuyvOrbFHv+2tAxA8lI3SCQ=; b=XKrMHs8iDgCPCBEBCqwoH6r68ndEHHdYQaGXxcqbCzA2dCje38t49T8DR14BRo06Ks NjG92UCnGIwBgQUfymA/ci8MTvrM8FRNZQFxT3y7u4czyifebbCZhoW41KgK1SP3z5xE Vrrl8/isvwAqTEoWyeJIBjuWlAIeIIyZwq0jK1394dN8VBAbzc4vqpBH2ZWyubKUScyP AgDfbqMuHh1rqY49KKxfXjZa8JV6DeS27U1JuVZzoie8eJHfqO08lRAWwrI6v5Hjdbpl 91/ar66ui0bSjooPi+yMTVDvtXnviGCLnlByva283KJMr7GBvTc/eNavMWz1iAWcgGMk mEtA== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@mg.codeaurora.org header.s=smtp header.b=KEUz1Z2W; 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 b5si6297153oif.104.2020.03.30.10.18.19; Mon, 30 Mar 2020 10:18:32 -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=fail header.i=@mg.codeaurora.org header.s=smtp header.b=KEUz1Z2W; 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 S1729445AbgC3Qlb (ORCPT + 99 others); Mon, 30 Mar 2020 12:41:31 -0400 Received: from mail26.static.mailgun.info ([104.130.122.26]:41062 "EHLO mail26.static.mailgun.info" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726497AbgC3Qlb (ORCPT ); Mon, 30 Mar 2020 12:41:31 -0400 DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=mg.codeaurora.org; q=dns/txt; s=smtp; t=1585586490; h=Message-Id: Date: Subject: Cc: To: From: Sender; bh=SJTDBgvtt/m4QfLexp01DuyvOrbFHv+2tAxA8lI3SCQ=; b=KEUz1Z2WrUsqG8va4Ew+5pwtdvYRrv7moQ77ZuuY7F8BnmB0Qe2fXMUnTxC9uaunwNBjxk4S qcgCEgXSBncnX1fGUKtj3L5zPP/qJH5lffeHZsCEGVtkq38xj770DJD38D1K5YbUEh+2c/g2 r85c+fmwYoPL89KK1bT8X/pidZs= X-Mailgun-Sending-Ip: 104.130.122.26 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 5e822132.7f9da58dd458-smtp-out-n05; Mon, 30 Mar 2020 16:41:22 -0000 (UTC) Received: by smtp.codeaurora.org (Postfix, from userid 1001) id AA135C433BA; Mon, 30 Mar 2020 16:41:21 +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 0213EC433F2; Mon, 30 Mar 2020 16:41:15 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org 0213EC433F2 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: swboyd@chromium.org, bjorn.andersson@linaro.org, evgreen@chromium.org, mka@chromium.org Cc: linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org, agross@kernel.org, linus.walleij@linaro.org, tglx@linutronix.de, maz@kernel.org, jason@lakedaemon.net, dianders@chromium.org, rnayak@codeaurora.org, ilina@codeaurora.org, lsrao@codeaurora.org, Maulik Shah Subject: [RFC v3] pdc: Introduce irq_set_wake call Date: Mon, 30 Mar 2020 22:10:59 +0530 Message-Id: <1585586460-3272-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 v3: - Add pm events notification to check if suspend started - Add cpu pm notification to enable wake IRQs during deep/s2idle suspend - Add pdc_pm_data structure as domain->host_data and as irq's chip_data - Add changes to mark wakeup and enabled IRQs in respective domains - Address Stephen's comments from v2. Changes in v2: - Drop pinctrl irqchip change and update in PDC irqchip change - Include more details for .irq_set_wake introduction - Address Stephen's comments for CPUidle need not call enable_irq_wake - Update cover letter inline to add more detail on problem and solution irqchip: qcom: pdc: Introduce irq_set_wake call 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". In such scenario the gpio irq stays disabled at gpio irqchip but needs to keep enabled in the hierarchy for wakeup capable parent PDC and GIC irqchip to be able to detect and forward wake capable interrupt to CPU when system is in sleep state like suspend. The final status at PDC irq_chip should be an "OR" of "enable" and "wake" calls. (i.e. same per below table) |--------------------------------------------------| | ENABLE in SW | WAKE in SW | PDC & GIC HW Status | | 0 | 0 | 0 | | 0 | 1 | 1 | | 1 | 0 | 1 | | 1 | 1 | 1 | |--------------------------------------------------| Sending this as an RFC since this series attempts to add support for [1] by introducing irq_set_wake call for PDC irqchip from which interrupt can be enabled/disabled at PDC (and its parent GIC) hardware. Note that *ALL* drivers using wakeup capable interrupt with enable_irq_wake() and want to disable irq with disable_irq() need to call disable_irq_wake() also if they want to stop wakeup capability at parent PDC irqchip. Not doing so will lead to system getting woken up from sleep states if wakeup capable IRQ comes in. [1] https://www.spinics.net/lists/kernel/msg3398294.html Maulik Shah (1): irqchip: qcom: pdc: Introduce irq_set_wake call drivers/irqchip/qcom-pdc.c | 271 ++++++++++++++++++++++++++++++++++++++++++--- 1 file changed, 256 insertions(+), 15 deletions(-) -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation