Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp1107141imu; Fri, 11 Jan 2019 15:22:30 -0800 (PST) X-Google-Smtp-Source: ALg8bN4T7460fVCDcbxwMVQCYzUpF1d4cUKjslDJ6HeWK86gWPTzd8DlldvdSjVen0c9pIq7Eph5 X-Received: by 2002:a62:2b8b:: with SMTP id r133mr16427985pfr.246.1547248950289; Fri, 11 Jan 2019 15:22:30 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1547248950; cv=none; d=google.com; s=arc-20160816; b=mV9QekB3AA+2i0SGYFEaJj7Wc9UEDHqwj/vnX4gDLI7SiHUDdASUrKMLxHrBQyxmxm EyT8O38OeuFOUdFjkl3kQ/U8nxaYDeqdcmAeUnNPee5uH4mjF4CkIg5HDR1OFPdRZ+7J 11n0hduiVNkZsiiY4Mz3NGG6tzeUr52eLuDMvWPvo3qmF+SABBUgY0YdRfVlmXEFmwV9 /rhjEuMNu2twLQRyusgHyjg6W6op4G4uqSuW9WawIAB+ifgF/pMmP9tYDZ72xbWTN2oo LWAQlLpLOJpskWmC8LweTtooaHAQb5HeAR/t/433WMxR7zzTKyr4Ae+GSO81Wk5wlth7 QqIA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:date:from:message-id:to:cc:references :in-reply-to:user-agent:subject:content-transfer-encoding :mime-version:dkim-signature; bh=kpbn7F/uM9epogKhiav4+hF6tS9nr3TNBVocSYAqhG8=; b=rwzp1wxXu/6OCYnrnxYiUhyCZQdOPKudtcJub4Ej+OsfbSnDwNiI60rqau83NvnEid SSIEAIrxOTKhaSOHkX9nbOJ+cmcT7BbSZays+ApHpPrwipOXWgoJgTsoHkqfLWLfkezy /uEJLaI/A1wO4JPNKT3eq3hUUP2JdtRUxmrjRTu7GTINxG9bhPI0tcaotA2YvfSQWmY1 yo/cl3t8MQAxwstaCZGg0xrBmSpyunySNmMqJsdNt12CZcXdeKW7iMEcsSyyZtGZNfWL oa2Snm2RfJvxf82DPIsZEBXr1Zqi+gG35DOTsLx95i2ZVF/yUB6Ib11cfUEWW5QQ9vRk 0ptw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=RRLDs1jh; 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 21si73850850pgk.74.2019.01.11.15.22.14; Fri, 11 Jan 2019 15:22:30 -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=RRLDs1jh; 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 S1726483AbfAKXUv (ORCPT + 99 others); Fri, 11 Jan 2019 18:20:51 -0500 Received: from mail.kernel.org ([198.145.29.99]:60166 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725927AbfAKXUu (ORCPT ); Fri, 11 Jan 2019 18:20:50 -0500 Received: from localhost (unknown [104.132.0.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 9928D206B6; Fri, 11 Jan 2019 23:20:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1547248849; bh=o2P8ttXrh+vvAaghmRZs97QsHcoinWVkF+uHKclR9J8=; h=Subject:In-Reply-To:References:Cc:To:From:Date:From; b=RRLDs1jhx7WxNmB7onUwxdPl2E+U/xNp/VTdtErKSnkOT81zD31vsq3wdfkIgkubk uERPxXwlAflhElksZVEPopZAWp0KuHi50syfn/y/A6uj4xDcBfV8qzAFSm1gYNxuiP 9/3RobCsRVxL3cHCr4zrl7WzHV034LtlTyY4iELQ= Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Subject: Re: [PATCH 4/7] dt-bindings: sdm845-pinctrl: add wakeup interrupt parent for GPIO User-Agent: alot/0.8 In-Reply-To: References: <20181219221105.3004-1-ilina@codeaurora.org> <20181219221105.3004-5-ilina@codeaurora.org> <20181229000714.GA3654@bogus> <20190107185113.GH14960@codeaurora.org> <20190109173111.GB22547@codeaurora.org> Cc: 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 To: Lina Iyer , Rob Herring Message-ID: <154724884881.169631.9705938789464714812@swboyd.mtv.corp.google.com> From: Stephen Boyd Date: Fri, 11 Jan 2019 15:20:48 -0800 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Quoting Rob Herring (2019-01-09 11:36:56) >=20 > > >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. >=20 > 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? >=20 I'd say it's not the interrupt-parent, but a secondary-interrupt-parent, because it's another path that some GPIO interrupts will go through vs. the "normal" summary irq line that uses the interrupt-parent. Maybe that's similar to the interrupt partitioning that ARM is doing for PPIs that only go to some CPUs? We don't really specify that some GPIO is corresponding to the secondary or primary interrupt controller for the GPIO controller in DT. If we did, then we could do something like the interrupt-map binding and have the index of that property be the gpio number and the interrupt parent that it maps to (either summary from the GIC or MPM pin number). interrupt-map =3D <0 0 &gic GIC_SPI 208 0>, <1 0 &pdc 3 0>; interrupt-map-mask =3D <0xfffffff 0>; And then we would pass the 2-cell GPIO interrupt specifier (gpio# and flags) through the table and remap it to arbitrary domain parents. We could use this same design for the SSBI and SPMI gpio interrupt controller where we're currently looking at hardcoding the base interrupt number in the driver (0xc0) and then adding the GPIO number to that to get the parent interrupt specifier. It's sort of an abuse of interrupt-map, but I don't know if it really matters because there isn't a child of the gpio controller that is going to go through this table.