linux-i2c.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Gibson <david@gibson.dropbear.id.au>
To: Frank Rowand <frowand.list@gmail.com>
Cc: Pantelis Antoniou <pantelis.antoniou@konsulko.com>,
	Rob Herring <robh+dt@kernel.org>,
	stephen.boyd@linaro.org, broonie@kernel.org,
	grant.likely@secretlab.ca, Mark Rutland <mark.rutland@arm.com>,
	mporter@konsulko.com, Koen Kooi <koen@dominion.thruhere.net>,
	Guenter Roeck <linux@roeck-us.net>,
	marex@denx.de, Wolfram Sang <wsa@the-dreams.de>,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-i2c@vger.kernel.org, panto@antoniou-consulting.com
Subject: DT connectors, thoughts
Date: Tue, 19 Jul 2016 00:20:37 +1000	[thread overview]
Message-ID: <20160718142037.GS16769@voom.fritz.box> (raw)
In-Reply-To: <577ACE0D.9050700@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 4542 bytes --]

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.

So.. start with an example of a board DT including a widget socket,
which contains pins for an MMIO bus, an i2c bus and 2 interrupt lines.

/dts-v1/;

/ {
	compatible = "foo,oldboard";
	ranges;
	soc@... {
		ranges;
		mmio: mmio-bus@... {
			#address-cells = <2>;
			#size-cells = <2>;
			ranges;
		};
		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
				>;
			};
			aliases = {
				i2c = &i2c;
				intc = &w1_irqs;
				mmio = &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 those
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 think
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 = "foo,whirligig-widget";
};

&i2c {
	whirligig-controller@... {
		...
		interrupt-parent = <&widget-irqs>;
		interrupts = <0>;
	};
};

Use of the /plugin/ keyword is rather different from existing
practice, so we may want a new one instead.

The idea is that this would be compiled to something like:

/dts-v1/;

/ {
	socket-type = "foo,widget-socket";
	compatible = "foo,whirligig-widget";

	fragment@0 {
		target-alias = "i2c";
		__overlay__ {
			whirligig-controller@... {
				...
				interrupt-parent = <0xffffffff>;
				interrupts = <0>;
			};
		};
	};
	__phandle_fixups__ {
		/* These are (path, property, offset) tuples) */
		widget-irqs =
			"/fragment@0/__overlay__/whirligig-controller@...",
			"interrupt-parent", <0>;
	};
};


Suppose then there's a new version of the board.  This extends the
widget socket in a backwards compatible way, but there are now two
interchangeable sockets, and they're wired up to different irqs and
i2c lines on the baseboard:

/dts-v1/;

/ {
	compatible = "foo,newboard";
	ranges;
	soc@... {
		ranges;	
		mmio: mmio-bus@... {
			#address-cells = <2>;
			#size-cells = <2>;
			ranges;
		};
		i2c0: i2c@... {
		};
		i2c1: i2c@... {
		};
		intc: intc@... {
		};
	};

	connectors {
		widget1 {
			compatible = "foo,widget-socket-v2", "foo,widget-socket";
			w1_irqs: irqs {
				interrupt-controller;
				#address-cells = <0>;
				#interrupt-cells = <1>;
				interrupt-map-mask = <0xffffffff>;
				interrupt-map = <
					0 &intc 17 0
					1 &intc 8 0
				>;
			};
			aliases = {
				i2c = &i2c0;
				intc = &w1_irqs;
				mmio = &mmio;
			};
		};
		widget2 {
			compatible = "foo,widget-socket-v2", "foo,widget-socket";
			w2_irqs: irqs {
				interrupt-controller;
				#address-cells = <0>;
				#interrupt-cells = <1>;
				interrupt-map-mask = <0xffffffff>;
				interrupt-map = <
					0 &intc 9 0
					1 &intc 10 0
				>;
			};
			aliases = {
				i2c = &i2c1;
				widget-irqs = &w2_irqs;
				mmio = &mmio;
			};
		};
	};
};


A socketed device could also have it's own connectors - the contrived
example below has a little 256 byte mmio space (maybe some sort of LPC
thingy?):


/dts-v1/;

/plugin/ foo,widget-socket-v2 {
	compatible = "foo,superduper-widget};

	connectors {
		compatible = "foo,super-socket";
		aliases {
			superbus = &superbus;
		};	
	};
};

&mmio {
	superbus: super-bridge@100000000 {
		#address-cells = <1>;
		#size-cells = <1>;
		ranges = <0x0  0xabcd0000 0x12345600  0x100>;
	};
};

&i2c {
	super-controller@... {
		...
	};
	duper-controller@... {
	};
};

Thoughts?


-- 
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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

  parent reply	other threads:[~2016-07-18 14:20 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-04 20:58 portable device tree connector -- problem statement Frank Rowand
     [not found] ` <577ACE0D.9050700-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-07-05  8:31   ` Mark Brown
2016-07-05 14:24     ` Frank Rowand
2016-07-05 18:07       ` Pantelis Antoniou
2016-07-05 18:04     ` Pantelis Antoniou
2016-07-18 14:20 ` David Gibson [this message]
2016-07-20 20:59   ` DT connectors, thoughts Pantelis Antoniou
2016-07-21 13:42     ` David Gibson
2016-07-21 14:14       ` Pantelis Antoniou
2016-07-21 19:09         ` Rob Herring
2016-07-21 19:15           ` Pantelis Antoniou
2016-07-21 19:21             ` Rob Herring
     [not found]             ` <2C63DCA2-385A-4EE3-A957-F1DBEF7929F8-OWPKS81ov/FWk0Htik3J/w@public.gmane.org>
2016-07-22  4:16               ` David Gibson
2016-07-22  3:47           ` David Gibson
2016-07-22  3:46         ` David Gibson
2016-07-20 20:59   ` Pantelis Antoniou
2016-07-21 19:15   ` Rob Herring
2016-07-22  4:25     ` David Gibson
2016-08-26  1:38       ` Stephen Boyd
2016-08-29 13:45         ` David Gibson
     [not found]           ` <147252286938.20899.1763773530822329216@sboyd-linaro>
2016-08-30 23:55             ` David Gibson
     [not found]               ` <147329189889.27412.12053595745294007737@sboyd-linaro>
2016-09-08  0:26                 ` David Gibson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160718142037.GS16769@voom.fritz.box \
    --to=david@gibson.dropbear.id.au \
    --cc=broonie@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=frowand.list@gmail.com \
    --cc=grant.likely@secretlab.ca \
    --cc=koen@dominion.thruhere.net \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=marex@denx.de \
    --cc=mark.rutland@arm.com \
    --cc=mporter@konsulko.com \
    --cc=pantelis.antoniou@konsulko.com \
    --cc=panto@antoniou-consulting.com \
    --cc=robh+dt@kernel.org \
    --cc=stephen.boyd@linaro.org \
    --cc=wsa@the-dreams.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).