Received: by 2002:ac0:946b:0:0:0:0:0 with SMTP id j40csp3995617imj; Tue, 12 Feb 2019 08:06:55 -0800 (PST) X-Google-Smtp-Source: AHgI3IYrKJXr+GS8N+bnxrNTndnHd0LDKPesKTVcumfbrICexf92RFVm2QUWRoILJml7+Lm8M7tY X-Received: by 2002:a17:902:be0f:: with SMTP id r15mr4596337pls.97.1549987615670; Tue, 12 Feb 2019 08:06:55 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1549987615; cv=none; d=google.com; s=arc-20160816; b=lK0ysEZs21+xYP2U5oVj1+aLoBUI9xSQd5lKeh7KvhAMEKlP3qfyXH3EZJsi9GDHZN az206WK47oG1oI9prUDAmKbLPAAhxqs9FG8GVmAWL7td0kP4rXGGY6z6XFJ9Q+Xhp+PP 7maLC/8kUe0jZWKb3vVWoa1sXijJIIgBtHW/N3pSem3kk+O/A3rVtAsIibTKU5+mKl/g pT4okkgq8uP0ojRcAXhVpEQXB7+3F4GlNsMZa6eSPwvrhU2nTMmDtCWp5sV9MoEOUANi a1ZIhDGyOleb82lxqHkg5ONpLyuz17TKQCzEW/UC1mfqhbRpV2WaEbjxdoJ1CtvIokyN gB2w== 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; bh=jPxpsTIaNkwFKzskP1q4mkj4Oiq25KCJ6/ddmgPH8lA=; b=e8QyjL/fhQx/zL+4syUB8hNqOXVAiGlSZg9GimnEwDSrB+suM3fj/K/wtccTI4I1we RtNv8fdTDOYU7BhroAx9gsthqMuvgSe2J+d7Ivj8aTc+d7NdhhFmcToY6MnPf4RQOANv SBYtPVStGjgvK34XFRsJ7T6E3EBzzCxCtNrwGP17MJFeuMIxsxfheq5u7sENh0hjX5n8 hl0eYtijLjHDiBwkslMIhOJ5xOqS2z1kplOycIMgq/rtG3WdA0gWGQtXBL5+hVyow1x/ 1D+qcPDXkLrqw/cdp05TYYTwC7UEcjHbY2sg364SejtG2cdtZThYItgpWKXhWHOOut/G ROag== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@codeaurora.org header.s=default header.b=PlyPQsZH; dkim=pass header.i=@codeaurora.org header.s=default header.b=THeQTI3g; 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 9si8505129plc.40.2019.02.12.08.06.38; Tue, 12 Feb 2019 08:06:55 -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=@codeaurora.org header.s=default header.b=PlyPQsZH; dkim=pass header.i=@codeaurora.org header.s=default header.b=THeQTI3g; 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 S1730817AbfBLQFg (ORCPT + 99 others); Tue, 12 Feb 2019 11:05:36 -0500 Received: from smtp.codeaurora.org ([198.145.29.96]:38914 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730728AbfBLQFg (ORCPT ); Tue, 12 Feb 2019 11:05:36 -0500 Received: by smtp.codeaurora.org (Postfix, from userid 1000) id 5D081608BA; Tue, 12 Feb 2019 16:05:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1549987534; bh=rkZ789ag41kz84dzyh+aactYHY+dusweKLn80VrI+6M=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=PlyPQsZH0wrYHPMGjHUtoAsX0falC6EpDOJbYTskpnCDB4DCIl3fA/tJKCs4kINZS fYWWQ6hJMRs2mLHpv7k4huSuo1DrBLt43T2TFoGhYqMA2eYHw0NH1ZYgvADPEVbPpD 6/fHeakS27GSZgbGTo59edAUeH6maBDTGXsyN2BM= 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.7 required=2.0 tests=ALL_TRUSTED,BAYES_00, DKIM_INVALID,DKIM_SIGNED 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 29E4E6030D; Tue, 12 Feb 2019 16:05:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1549987533; bh=rkZ789ag41kz84dzyh+aactYHY+dusweKLn80VrI+6M=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=THeQTI3gFQ/dcKUPHBfurR+YPYYhVXE2Kgjaa1jMTkLUuhciS86e81VrVuxwMp0Ds vxpkN4O1gf4AhC6jx3vknpbbA66eSkNI6ndErukuzSwHHGdRU3D4pe7x3E58RuZ5v1 k48DL/SJibBFAeUdqKZ3T35iEAXRSRttQWQZWT/0= DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org 29E4E6030D 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: Tue, 12 Feb 2019 09:05:31 -0700 From: Lina Iyer To: Rob Herring 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 Subject: Re: [PATCH 4/7] dt-bindings: sdm845-pinctrl: add wakeup interrupt parent for GPIO Message-ID: <20190212160531.GA17102@codeaurora.org> References: <20181219221105.3004-1-ilina@codeaurora.org> <20181219221105.3004-5-ilina@codeaurora.org> <20181229000714.GA3654@bogus> <20190107185113.GH14960@codeaurora.org> <20190109173111.GB22547@codeaurora.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.11.1 (2018-12-01) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jan 09 2019 at 12:37 -0700, Rob Herring wrote: >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? > Rob, Would like to know your opinion on Stephen's idea. Could you take a look at this thread again please? Thanks, Lina >> 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 >>