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:
signature.asc
Description: PGP signature
