Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp1101631imu; Wed, 9 Jan 2019 11:38:50 -0800 (PST) X-Google-Smtp-Source: ALg8bN6bx7RhQlJr7NgbjhlMlcoMAgty0EEi5Rp3jRA6aW2oSLSs/RBRuCoXd+/lZaoh2vmWprfr X-Received: by 2002:a63:9d05:: with SMTP id i5mr6125142pgd.98.1547062730887; Wed, 09 Jan 2019 11:38:50 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1547062730; cv=none; d=google.com; s=arc-20160816; b=RulYXe1ZVeoe8riNds+8vsIe7zkveQI8AOrK6ocIUjNSgtDPgVM2IL3EJM/6rT9ueU xb8aBNmCXcJfgZ6FAtBq7Yaauja4sq60oh64rFq2ystls0ocsEc7a4CwDS1/SHoi5cUE EbINaLtMdI8Xi8g577VzMrZAEER/q4tF29mysU6R53KUndnirtkb7ycQy7eTyon/CJqf eGfRXblGfewMhRAebaE9+fDaj+mQRfoTacmpqlIX2v6MsX6ELqXHdJA/z6buosD5/WED In1ffgGd/+jDVtCOq6TcOSIhBmOiZNLABN56TJPppAKiAI05IOvJUaha0EDNWp0N5STp fdUg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=9pNbCVrFAePtAsaGfsiHGidPpDSrE6lGmF1TjBg2yxI=; b=ESaVji07tIetE1UZ3yJqP9lQ15g3HzBqty+TEmxc5jjiB131SJ9xJOGsfndZH5Xo9X i5PQknQAf8CB3Cz7KKgj0mAJCzHkonVRc31dmhXN2WGSpMN0alue8m8c+o3ldZ8dR37B 1VMvwrFzDHZt1sHGc1JypgoyRxlyewzHUsXNzWWaac767PwMDGDTH1IRYZLR0eHcL0KU UjZbnM3iaAwhTFKz/ZHNNjza3+VB/HSA2TpA1xKKaHvgfA+jlFdQi1CZ8McNVqy5ZYWC MyGnArz2s5EWa46rhG1NXbX4uaMqS8eI+wxkWy3Z3ElnFML1EbFm6qQ/wewUKhliGbJO UBZA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=lg0kJ2B3; 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=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z22si18663821plo.202.2019.01.09.11.38.35; Wed, 09 Jan 2019 11:38: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=@kernel.org header.s=default header.b=lg0kJ2B3; 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=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728334AbfAIThL (ORCPT + 99 others); Wed, 9 Jan 2019 14:37:11 -0500 Received: from mail.kernel.org ([198.145.29.99]:39586 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727123AbfAIThL (ORCPT ); Wed, 9 Jan 2019 14:37:11 -0500 Received: from mail-qt1-f182.google.com (mail-qt1-f182.google.com [209.85.160.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 27E6721783; Wed, 9 Jan 2019 19:37:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1547062630; bh=cmJ9BUids2jbhalCPElosVSXRss/tV5qmDolb/NM9Jw=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=lg0kJ2B3X69vbsrbRJGyrMy+8WfDGUXkdpYXmRC6UukGUTF1PEwHwt1rKuTqYA2Nx fbVNUWNb1Us/psycyGhpy26TRUpJ9jyouBj1Su6D5YxcSk7PvAgCWnMsezfLLWE/Gi CVfQ4ISDyrewyil37qnBJTQBeU9ulClj8ZBPAdUs= Received: by mail-qt1-f182.google.com with SMTP id n32so9616414qte.11; Wed, 09 Jan 2019 11:37:10 -0800 (PST) X-Gm-Message-State: AJcUukdW52JHl6Y4+3XJmy+dulWAItl9By9/U3kML1jm0Fi/4CekTZSZ KFWwXkqXsIuzdO5UurAscOtkzjhPogVgxXGaCg== X-Received: by 2002:aed:29a6:: with SMTP id o35mr6743674qtd.257.1547062629272; Wed, 09 Jan 2019 11:37:09 -0800 (PST) MIME-Version: 1.0 References: <20181219221105.3004-1-ilina@codeaurora.org> <20181219221105.3004-5-ilina@codeaurora.org> <20181229000714.GA3654@bogus> <20190107185113.GH14960@codeaurora.org> <20190109173111.GB22547@codeaurora.org> In-Reply-To: <20190109173111.GB22547@codeaurora.org> From: Rob Herring Date: Wed, 9 Jan 2019 13:36:56 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 4/7] dt-bindings: sdm845-pinctrl: add wakeup interrupt parent for GPIO To: Lina Iyer Cc: Stephen Boyd , Evan Green , Marc Zyngier , "linux-kernel@vger.kernel.org" , "Raju P.L.S.S.S.N" , linux-arm-msm , Thierry Reding , Bjorn Andersson , devicetree@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jan 9, 2019 at 11:31 AM Lina Iyer wrote: > > On Tue, Jan 08 2019 at 07:49 -0700, Rob Herring wrote: > >On Mon, Jan 7, 2019 at 12:51 PM Lina Iyer wrote: > >> > >> On Fri, Dec 28 2018 at 17:07 -0700, Rob Herring wrote: > >> >On Wed, Dec 19, 2018 at 03:11:02PM -0700, Lina Iyer wrote: > >> >> SDM845 SoC has an always-on interrupt controller (PDC) with select GPIO > >> >> routed to the PDC as interrupts that can be used to wake the system up > >> >> from deep low power modes and suspend. > >> >> > >> >> Cc: devicetree@vger.kernel.org > >> >> Signed-off-by: Lina Iyer > >> >> --- > >> >> .../devicetree/bindings/pinctrl/qcom,sdm845-pinctrl.txt | 7 ++++++- > >> >> 1 file changed, 6 insertions(+), 1 deletion(-) > >> >> > >> >> diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sdm845-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/qcom,sdm845-pinctrl.txt > >> >> index 665aadb5ea28..a522ca46667d 100644 > >> >> --- a/Documentation/devicetree/bindings/pinctrl/qcom,sdm845-pinctrl.txt > >> >> +++ b/Documentation/devicetree/bindings/pinctrl/qcom,sdm845-pinctrl.txt > >> >> @@ -29,6 +29,11 @@ SDM845 platform. > >> >> Definition: must be 2. Specifying the pin number and flags, as defined > >> >> in > >> >> > >> >> +- wakeup-parent: > >> >> + Usage: optional > >> >> + Value type: > >> >> + Definition: A phandle to the wakeup interrupt controller for the SoC. > >> > > >> >Is this really necessary? Is there more than one possible wakeup-parent > >> >node? > >> > > >> No. There is only one but depending on the architecture, the wakeup > >> interrupt controller could be different device like PDC on SDM845 or MPM > >> on SDM820. > >> > >> What do you have in mind? Let me know if you have a better idea than > >> referencing in DT. > > > >If there's only one possibility for a given platform, then you can > >just use of_find_compatible_node(). I don't think it matters that > >different platforms have a different device here. It's not going to be > >a large table and you may need to know the differences if there's not > >an abstracted interface to it (seems there is in your case). > The GPIO irqchip would be in hierarchy with the wakeup-parent > irqchip and no device specific functions would be called directly. > We could achieve this with compatible strings to the irqchip. > > >Alternatively, if the PDC/MPM code knows what interrupt controller it > >is associated with, then it could setup that relationship and the > >interrupt controller code could retrieve that. Maybe the stacked > >domain support doesn't work in that direction (I haven't looked at the > >irq code much since that was added). > > > The PDC/MPM do not know about the association. Neither does the main interrupt controller. The association is part of SoC integration. You can describe that association in either direction and that is sufficient from a DT standpoint. You've probably picked putting this in the GIC(?) based on what works more easily with the Linux irqdomain code. > >However, my main concern is documenting something genericish in a > >device specific binding. It looks like Tegra is trying to add the same > >thing, so this needs to be documented in a common place. One question > >is whether wakeup is the only use or if this should be more generally > >a secondary interrupt parent? > > > Yes, wakeup is the only use of this interrupt parent. Maybe for you, but I was wondering about this more generally. Should we encode what the function (e.g. wakeup) is in the property name or have something like aux-interrupt-controller? Maybe some platforms have some need for a secondary interrupt-controller which is not wakeup. Routing interrupts to other cores perhaps? > It is powered by > an always-on rail and therefore can detect some interrupts that are > routed to it even when the GIC is powered off. Though Tegra's > implementation of the irqchip is a bit different from QCOM, the idea is > generally the same. It would be helpful, if we could make this a > generic enough binding. > > -- Lina >