Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp4818412imu; Tue, 8 Jan 2019 06:53:28 -0800 (PST) X-Google-Smtp-Source: ALg8bN6Dvl53UV5ri0ly8zvjnUoMfUgdt+laYNcne4tnlAOhqzQXJlmjzICEs7ffGge3d+vOqjh/ X-Received: by 2002:a17:902:e10a:: with SMTP id cc10mr2097728plb.165.1546959208740; Tue, 08 Jan 2019 06:53:28 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1546959208; cv=none; d=google.com; s=arc-20160816; b=pDkpWw/tiu4dy8scGDHN2xCJ4U3/b5PAJnf6cyLamYlMyuLY1D6yOnvmBj5YpbIige yDyWKmKPkQWEgwXPh0qLv5MlnyJW6Jl77N3vwKBCVqt0V0hgxmQy2PMJo2MWSoci8L1c gRiry48zlCn70g4f0dPfVUM/VTu0+4o0dZBGJOAcywvPUh3KDeaRjBfqAcfbXjL1SUT5 sTw7IDbOp8b6ejavnkSudGe6UjyozYL2dpRCnQihSczpI1F7bm8JG2gSXolUeyLRDIUw XpGznuNAvMlY1HD4PX812T6Jhlm2gHLo8GlfDeSKVlFIGHj6NcHgDONvNpWhQ9Ya2OjJ HaRw== 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=UXmgQIT7epc6DANBdW46V0U4lGMlOysbUbOLwg8gv9g=; b=ZgTfpBLau8rpJYmsEbkwsQpK11YAFz2Jg9QedCqNz1jH3y1UVsQSte1uXRBlgbn2JP 2PDJXPy+cfljIUj6bmWzwH7UI4eLGNq5O/rUHHYkcpXOeoykXh/PwWCcYRuQoXl5Lm2U eFZXJPd1pMLIMEG0XY+mHMXt8epjyVab/OY1Z9GmkArf7axUJl/TUu/f/z/WTAh7P0YX 5RO64KEvYH73h2/3B6cwhGVOxax9MfGY8r0chJrcOwxSUEERWhtVUur6UUcD9S29cG3C oD598O2WgJYc4mWRfeqzR9jyQG9n76xXiIWY0cNjaG5pYAjxl9uVRe6m204sCT3VlPzg B7ng== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=T++pmsMN; 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 b18si31290322plz.105.2019.01.08.06.53.12; Tue, 08 Jan 2019 06:53:28 -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=T++pmsMN; 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 S1728446AbfAHOta (ORCPT + 99 others); Tue, 8 Jan 2019 09:49:30 -0500 Received: from mail.kernel.org ([198.145.29.99]:36996 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727739AbfAHOt3 (ORCPT ); Tue, 8 Jan 2019 09:49:29 -0500 Received: from mail-qt1-f173.google.com (mail-qt1-f173.google.com [209.85.160.173]) (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 3F9E32173C; Tue, 8 Jan 2019 14:49:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1546958968; bh=m8BIIjBVyt7wySueQRm61YIDr1y9Mta75gwDvJq68u4=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=T++pmsMNn1K9IlgrMRUQfiO58HU9MwzCstwZglej0Td7neyDmEa+HTyhlgZ60TM5R NDnxwM8W91rDff9FOEb+IDDEDPEPeIrCFvaJ4skwM8wYGlNqCV7qVSRXn/iWYL/ZBg qKQ4rp7G6T7VGmBloSpSyYnW31X2/z6ZzlsZVPbQ= Received: by mail-qt1-f173.google.com with SMTP id u47so4592585qtj.6; Tue, 08 Jan 2019 06:49:28 -0800 (PST) X-Gm-Message-State: AJcUukfzL0BrP5hDOZD7AANPk186fjHPKIKT9p3Hx5yp47cIpZQyOO2a d6zuYe6jDG5MlH87mEsjcj/N+eUsJBUySVea9g== X-Received: by 2002:ac8:6b18:: with SMTP id w24mr1953881qts.144.1546958967363; Tue, 08 Jan 2019 06:49:27 -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> In-Reply-To: <20190107185113.GH14960@codeaurora.org> From: Rob Herring Date: Tue, 8 Jan 2019 08:49:16 -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 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). 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). 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? Rob