Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp3909590ybv; Tue, 25 Feb 2020 09:27:50 -0800 (PST) X-Google-Smtp-Source: APXvYqyxVjaKebU1nWWThsZV+mHYchGkFRPNqMGRU9C+9ZHWME05fPbfvHm8yrCvz1xvz0pUYQHh X-Received: by 2002:aca:db41:: with SMTP id s62mr21638oig.87.1582651670047; Tue, 25 Feb 2020 09:27:50 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1582651670; cv=none; d=google.com; s=arc-20160816; b=z/o80LCsgRxg6TIa/xYEYSk+Wj1pulTh11KNBmIy2Nfj2A9pE9dOQGEyF+2r021pzG HA0+R/b5/lW9Rc2hjspef5gJ8b89X+iAounbjfigv8SVOOtN517/KYxc0udUlYij3uhW W+0ZGhTi4OdSjxHgVKtAgbb51xDoZMzHw1GLIGFlrdwvZiZ/uKeN4bfdta5+xkvyloVB gVrLTl4X5DDGBOCRE9uojOuPJl+iJJg7moyX4iIh+ZwYSqaWoygwyXA+pHebQMrr+omw JiwKxIOqOCnzZirCiBV9j7ouRN+6gyPfCSJFv+fl51pcae72/rkTFYGp5dV3p1peIvID OeJw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:message-id:date:to:cc:from :subject:references:in-reply-to:content-transfer-encoding :mime-version:dkim-signature; bh=nA6XtHfCbnQ+UrxP5iH37BANlB2snp9+FgCCs6LFMHc=; b=Z4ZCMxujGBt4X51cS6WA0NErltzZ6QU+UQ0WVLB9wB26YD47Fb8a8laFU1cOIjO6BL Mb3c7WHI7/2VzrtA4TFb0f4Sl/qPiSFQiM/KQ7jwLI3OfdT4/kOgbuEcYw4p06GhZOYW +XhaMYYZ82goQaCs+ybYzVYBZgoxObLECndUMdM5CF7hO1xbqMz6oO9ydd0mzbADSH6C yBdmUg4DWeqetXx9kaV26OpiFNsk5bS35zNxiDf8NRi8PC1uB4+LFWmQNsEe8OPoGuz+ +WtqUx2ISp12r5IhvpBCFji1JdAUOa35m90/Pr2Y403rdTePMwWC2ASSoy12y0ObCv/p ul4A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=MASHOfjq; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b21si11548104ots.38.2020.02.25.09.27.37; Tue, 25 Feb 2020 09:27:50 -0800 (PST) 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=@chromium.org header.s=google header.b=MASHOfjq; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730870AbgBYRQD (ORCPT + 99 others); Tue, 25 Feb 2020 12:16:03 -0500 Received: from mail-pg1-f196.google.com ([209.85.215.196]:41466 "EHLO mail-pg1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730460AbgBYRQD (ORCPT ); Tue, 25 Feb 2020 12:16:03 -0500 Received: by mail-pg1-f196.google.com with SMTP id 70so7179631pgf.8 for ; Tue, 25 Feb 2020 09:16:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:content-transfer-encoding:in-reply-to:references :subject:from:cc:to:date:message-id:user-agent; bh=nA6XtHfCbnQ+UrxP5iH37BANlB2snp9+FgCCs6LFMHc=; b=MASHOfjqGNYT1tp6DvmruXzocvsetadvExcpfODmmFENiPMhWeeGCkLkwK5CrSPHYu xS0lIIYIC9oJ2y3y7AB5I4+/sYx9Jar/0wKwBcM1V1KB88ETjoj2O0jYgcw6SiX6afr8 KdyVnvRqEpAhmxEj6V6AY6f3w0FecY9EkYR68= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:content-transfer-encoding :in-reply-to:references:subject:from:cc:to:date:message-id :user-agent; bh=nA6XtHfCbnQ+UrxP5iH37BANlB2snp9+FgCCs6LFMHc=; b=szA8WQpBVS/GkA1n0kDdXBERfw9wJMQYc0UZMVNl4ocM3irqVjD4P1TSIenYmBDooZ IWa5Lbpa0iLmcRCUgArusCakqLyPgBSmVp/zwj/vDo6DIywUtfe2uk4NN1NCSnaWCD5D FaUh9qxaczIKYFqperKAYpDOt+2Fjsf8sDy8gejToMc3oiS5nijl0+ZItncyZXGagrqE mlLr3PiT1e2S0lZKtUO1Bexa43l8hRw3Jx0Xv7jCZq2Hjcbi4OcjKRYBFbWidCiqK5Jq ThQ6Lhv1k+rBpwnW3awNmWPMbujs+403rbKxz9WQjEcVBudOBHXGptjZx/wEjTTXx6p/ EDaA== X-Gm-Message-State: APjAAAWTA3z/yTDXrTpXOxVM5Gu/VwysfzPPSpgThRIHPhgFQuy6yC1q K6QHEcgbEEm13quzksDwwJf7v7isn7c= X-Received: by 2002:a63:18d:: with SMTP id 135mr33641250pgb.32.1582650962218; Tue, 25 Feb 2020 09:16:02 -0800 (PST) Received: from chromium.org ([2620:15c:202:1:fa53:7765:582b:82b9]) by smtp.gmail.com with ESMTPSA id y5sm18329689pfr.169.2020.02.25.09.16.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 25 Feb 2020 09:16:01 -0800 (PST) Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable In-Reply-To: <4c80783d-8ad0-9bd8-c42e-01659fa81afe@codeaurora.org> References: <1581944408-7656-1-git-send-email-mkshah@codeaurora.org> <1581944408-7656-2-git-send-email-mkshah@codeaurora.org> <158216527227.184098.17500969657143611632@swboyd.mtv.corp.google.com> <4c80783d-8ad0-9bd8-c42e-01659fa81afe@codeaurora.org> Subject: Re: [RFC 1/2] irqchip: qcom: pdc: Introduce irq_set_wake call From: Stephen Boyd Cc: linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org, agross@kernel.org, linus.walleij@linaro.org, tglx@linutronix.de, dianders@chromium.org, rnayak@codeaurora.org, ilina@codeaurora.org, lsrao@codeaurora.org To: Maulik Shah , bjorn.andersson@linaro.org, evgreen@chromium.org, mka@chromium.org Date: Tue, 25 Feb 2020 09:16:00 -0800 Message-ID: <158265096050.177367.409185999509868538@swboyd.mtv.corp.google.com> User-Agent: alot/0.9 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Quoting Maulik Shah (2020-02-21 03:20:59) >=20 > On 2/20/2020 7:51 AM, Stephen Boyd wrote: >=20 > How are wakeups supposed to work when the CPU cluster power is disabl= ed > in low power CPU idle modes? Presumably the parent irq controller is > powered off (in this case it's an ARM GIC) and we would need to have = the > interrupt be "enabled" or "unmasked" at the PDC for the irq to wakeup > the cluster. >=20 > Correct. Interrupt needs to be "enabled" or "unmasked" at wakeup capable = PDC > for irqchip to wakeup from "deep" low power modes where parent GIC may no= t be > monitoring interrupt and only PDC is monitoring. > these "deep" low power modes can either be triggered by kernel "suspend" = or > "cpuidle" path for which drivers may or may not have registered for suspe= nd or > cpu/cluster pm notifications to make a decision of enabling wakeup capabi= lity. >=20 >=20 > We shouldn't need to enable irq wake on any irq for the CPU > to get that interrupt in deep CPU idle states. >=20 > + * > + * Note: irq enable/disable state is completely orthogonal > + * to the enable/disable state of irq wake. >=20 > i think that's what above documentation said to have wakeup capability is > orthogonal to enable/disable state of irq, no? >=20 > A deep cpuidle entry is also orthogonal to drivers unless they register f= or cpu > pm notifications. >=20 > so with this change, > if the drivers want their interrupt to be wakeup capable during both "sus= pend" > and "cpuidle" they can call "enable_irq_wake" and leave it there to be wa= ke up > capable. Where is there a mention about drivers registering for cpu PM notifications? I'm not aware of this being mentioned as a requirement. Instead, my understanding is that deep idle states shouldn't affect irqs from being raised to the CPU. If such an irq is enabled and can't wake the system from deep idle and it's expected to interrupt during this idle time then perhaps the PDC driver needs to block deep idle states until that irq is disabled. Does this scenario exist? It sounds like broken system design to have an irq that can't wake from deep idle, but I see that PDC has a selective set of pins so maybe some irqs just aren't expected to wake the system up during idle. >=20 > This way they don't need to worry about cpu entering to deep low power mo= de and > enabling wakeup capability "only when" deep low power mode get triggered. >