From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753726AbcGUTPo (ORCPT ); Thu, 21 Jul 2016 15:15:44 -0400 Received: from mail-wm0-f50.google.com ([74.125.82.50]:38121 "EHLO mail-wm0-f50.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752318AbcGUTPm convert rfc822-to-8bit (ORCPT ); Thu, 21 Jul 2016 15:15:42 -0400 Subject: Re: DT connectors, thoughts Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: text/plain; charset=utf-8 From: Pantelis Antoniou In-Reply-To: Date: Thu, 21 Jul 2016 22:15:36 +0300 Cc: David Gibson , Frank Rowand , Stephen Boyd , Mark Brown , Grant Likely , Mark Rutland , Matt Porter , Koen Kooi , Guenter Roeck , Marek Vasut , Wolfram Sang , devicetree , Linux Kernel Mailing List , "linux-i2c@vger.kernel.org" Content-Transfer-Encoding: 8BIT Message-Id: <2C63DCA2-385A-4EE3-A957-F1DBEF7929F8@konsulko.com> References: <577ACE0D.9050700@gmail.com> <20160718142037.GS16769@voom.fritz.box> <442C02A9-582D-4FD8-8F05-7A6FCD5B6BCA@konsulko.com> <20160721134208.GD12120@voom.fritz.box> To: Rob Herring X-Mailer: Apple Mail (2.3124) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Rob, > On Jul 21, 2016, at 22:09 , Rob Herring wrote: > > On Thu, Jul 21, 2016 at 9:14 AM, Pantelis Antoniou > wrote: >> Hi David, >> >>> On Jul 21, 2016, at 16:42 , David Gibson wrote: >>> >>> On Wed, Jul 20, 2016 at 11:59:44PM +0300, Pantelis Antoniou wrote: >>>> Hi David, >>>> >>>> Spent some time looking at this, and it looks like it’s going to the right direction. >>>> >>>> Comments inline. >>>> >>>>> On Jul 18, 2016, at 17:20 , David Gibson wrote: >>>>> >>>>> Hi, >>>>> >>>>> Here's some of my thoughts on how a connector format for the DT could >>>>> be done. Sorry it's taken longer than I hoped - I've been pretty >>>>> swamped in my day job. >>>>> >>>>> This is pretty early thoughts, but gives an outline of the approach I >>>>> prefer. > > [...] > >>>>> i2c: i2c@... { >>>>> }; >>>>> intc: intc@... { >>>>> #interrupt-cells = <2>; >>>>> }; >>>>> }; >>>>> >>>>> connectors { >>>>> widget1 { >>>>> compatible = "foo,widget-socket"; >>>>> w1_irqs: irqs { >>>>> interrupt-controller; >>>>> #address-cells = <0>; >>>>> #interrupt-cells = <1>; >>>>> interrupt-map-mask = <0xffffffff>; >>>>> interrupt-map = < >>>>> 0 &intc 7 0 >>>>> 1 &intc 8 0 >>>>>> ; >>>>> }; >>>> >>>> This is fine. We need an interrupt controller node. >>> >>> Actually I think we only need an interrupt nexus, not an interrupt >>> controller (in IEEE1275 terminology). (An interrupt controller would >>> generally require it's own driver, to ack/mask irqs, whereas this just >>> demonstrates the routing to an existing interrupt controller). Which >>> makes that example slightly incorrect (it shouldn't have the >>> interrupt-controller property). >> >> Hmm, as far as I can tell we only have a concept of an interrupt controller >> in the kernel. An interrupt nexus is something new. We should get by without >> a driver but hacking the interrupt lookup path at DT. > > Interrupt nexus is the interrupt-map property which is fully > supported. I'd expect we'll end up with a gpio nexus (i.e. gpio-map) > for connector gpios, too. > Is interrupt-map enough to cover all our cases? On all the cases that I see it used is in the context of PCI or some sort of bus. Is the example above well defined? As far as I can tell interrupt-controller is not needed. > Rob Regards — Pantelis