From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933640AbcH2Nsm (ORCPT ); Mon, 29 Aug 2016 09:48:42 -0400 Received: from ozlabs.org ([103.22.144.67]:46209 "EHLO ozlabs.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933371AbcH2NsJ (ORCPT ); Mon, 29 Aug 2016 09:48:09 -0400 Date: Mon, 29 Aug 2016 09:45:11 -0400 From: David Gibson To: Stephen Boyd Cc: Rob Herring , Frank Rowand , Pantelis Antoniou , Mark Brown , Grant Likely , Mark Rutland , Matt Porter , Koen Kooi , Guenter Roeck , Marek =?utf-8?B?VmHFoXV0?= , Wolfram Sang , "devicetree@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-i2c@vger.kernel.org" , Pantelis Antoniou Subject: Re: DT connectors, thoughts Message-ID: <20160829134511.GC2166@littlecatz> References: <577ACE0D.9050700@gmail.com> <20160718142037.GS16769@voom.fritz.box> <20160722042556.GL15941@voom.fritz.box> <147217552167.17958.11590706771471540284@sboyd-linaro> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="t0UkRYy7tHLRMCai" Content-Disposition: inline In-Reply-To: <147217552167.17958.11590706771471540284@sboyd-linaro> User-Agent: Mutt/1.7.0 (2016-08-17) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --t0UkRYy7tHLRMCai Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 25, 2016 at 06:38:41PM -0700, Stephen Boyd wrote: > Quoting David Gibson (2016-07-21 21:25:56) > > On Thu, Jul 21, 2016 at 02:15:57PM -0500, Rob Herring wrote: > > > On Mon, Jul 18, 2016 at 9:20 AM, David Gibson > > > wrote: > > >=20 > > > I understand how you are using i2c alias, but not the intc. It would > > > help if the same names were not used in multiple places unless they > > > are the same thing. > >=20 > > Yes, sorry. We have both the /soc/intc node which is the base board's > > master interrupt controller. Then we have the connector local 'intc' > > alias which describes the local interrupt space for just the > > connector. > >=20 > > > What does using aliases here buy us vs. just properties with a > > > phandle? > >=20 > > Um.. I'm not sure what you mean. >=20 > I think Rob means drop the aliases node and just have: Oh, ok. The reason for the aliases node is that putting the aliases (or whatever you want to call them) in the top level connector node limits what potential extensions we can make to the connector format. The aliases can essentially have any property name, so they could collide with additional "metadata" properties we might want to add. > property =3D &phandle; Note that the example above is misleading. Without the < >, the label reference will expand to a path string, not a phandle. > In this example: >=20 > i2c =3D &i2c; > intc =3D &w1_irqs; > mmio =3D &mmio; >=20 > or perhaps to have a list of phandles and names that map to them? >=20 > targets =3D <&i2c>, <&w1_irqs>, <&mmio>; > target-names =3D "i2c", "intc", "mmio"; That would work, but a) using phandles instead of paths introduces an additional lookup for no particular benegit and b) it seems harder to parse. In addition the aliases format suggested matches the global aliases property already defined by IEEE1275, so it seems a good place to start. >=20 > ? >=20 > >=20 > > > > mmio =3D &mmio; > > > > }; > > > > }; > > > > }; > > > > }; > > > > > > > > Note that the symbols are local to the connector, and explicitly > > > > listed, rather than including all labels in the tree. This is to > > > > enforce (or at the very least encourage) plugins to only access tho= se > > > > parts of the base tree. > > > > > > > > Note also the use of an interrupt nexus node contained within the > > > > connector to control which irqs the socketed device can use. I thi= nk > > > > this needs some work to properly handle unit addresses, but hope > > > > that's enough to give the rough idea. > > > > > > > > So, what does the thing that goes in the socket look like? I'm > > > > thinking some new dts syntax like this: > > > > > > > > /dts-v1/; > > > > > > > > /plugin/ foo,widget-socket { > > > > compatible =3D "foo,whirligig-widget"; > > > > }; > > > > > > > > &i2c { > > > > whirligig-controller@... { > > > > ... > > > > interrupt-parent =3D <&widget-irqs>; > > > > interrupts =3D <0>; > > > > }; > > > > }; >=20 > How would we support an expansion board that goes onto two > sockets/connectors provided by the baseboard when the connectors > "export" the same phandle aliases? From what I can tell with this design > we'll be unable to describe a device on the expansion board that is > wired to properties provided by the two connectors. Ok, so there are two parts to this. 1) Allowing a plugin to use multiple connectors. I thought a bit about this case, but didn't address it for simplicity. That would require a different syntax, so we can rethink this if it's a use case we think we need. 2) Dealing with alias collisions between connector types This one is fairly straightforward to handle. By default, we'll use labels from connectors we plug into "as is". However, we can add a syntax that allows us to locally rename labels from a connector (for those familiar with Python, think "import foo from bar as baz"). So, combining those thoughts together, I'm thinking dtc format for something connecting to two different widget sockets (pretty much the worst case) would look something like: /plugin/ foo,widget-socket { }; /plugin/ foo,widget-socket { realias { i2c-b =3D "i2c"; intc-b =3D "intc"; mmio-b =3D "mmio"; }; }; &i2c { .. devices on the i2c from the first plug .. }; &i2c-b { .. devices on the i2c from the second plug .. }; Obviously we'd also need to devise an encoding for this to compile into, since the one I proposed previously won't work in this case. --=20 David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson --t0UkRYy7tHLRMCai Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBAgAGBQJXxDxnAAoJEGw4ysog2bOSbbYP/RAMCJ345JO1SPcWlw4/t8G/ 4Zg+guc4RfVqbbgxrWWiw4U238DJLqr0Yf3i0JXU7QFZxUTcqfpVTs05DEUchwkX YXLZWBhtrcbt2L3jlzv/xSMiCIux4YshwbWLzDwJInAyO1J61m+AdjTqPDxY94Ei ULCBAzhSPXN/XGGHvqOntounsAZtXt/ky73tr6LXYtp9jDupaBvJzUsUhH8MG4zI 16g7E8ROCObyo6ReG6RKHMzkHl4ogwUv6EhMM62YlmRKFW3Ljbl6+pMYA1bzllgi ci17KkvA3+kawzc1CZBZoRTkGFlR4z0O5SL8cbzw4xogMTP9lLRuqSAv58sIL/lo LEEzdK2UeQqPnFQGwFTNHc4cZek7nsXfc6nYtsxRudnqo2vu6g2RIjjxsdIzMKV+ ezfUroZcfZtrneRx/ETlpMZ6lzKo8mEWW/ixVwzPDa4XgoGUhvr4KTtDvSlDgvLv 3mSf6F8KlYyTUQEekY+wFMGh3oeARlb62qKP61kbrhkpxa68SURZn/SkUkK21gWi WNgPAtgVnKeuB4YKFE0LN9IwzEEKPZ6mlROFT2LeVaK9F/Jix3iwgKKR82yeuIv3 ZyXcP1MbPdO22PGGqaFZ7FvoZvlPxxb9NAexOD/e/LFzfcaC6nkn6KBh+8vL5Ufv KG02Twxz4cYHUjmSQjfI =DOFp -----END PGP SIGNATURE----- --t0UkRYy7tHLRMCai--