Re: [RFC PATCH 0/1] Portable Device Tree Connector -- conceptual

[Frank Rowand]

On 07/08/16 12:20, Frank Rowand wrote:
> On 07/08/16 00:26, Pantelis Antoniou wrote:
>> Hi David,
>>
>>> On Jul 7, 2016, at 10:15 , David Gibson  wrote:
>>>
> 
> < snip >
> 
>>> Given that we're going to need new code to support this new connector
>>> model, I think we should also fix some of the uglies in the current
>>> overlay format while we're at it.
>>>
>>
>> We need to keep compatibility with the old format. There are 5 million
>> RPIs sold, half a million beaglebones and C.H.I.P. is coming out too.
>> They all use overlays in one form or another.
>>
>> That’s not counting all the custom boards that actively use them.
>>
>> We have a user base now.
> 
> Please not that I AM NOT suggesting the we remove compatibility with
 ^^^ note

> the old format!!!
> 
> But I need to push back on the idea that we have a user base that we
> need to keep compatibility with.  If I understand correctly, that
> user base is based on using much code that is not in mainline, including
> an altered dtc and a cape manager.
> 
> People using out of tree code can not use the fact that code exists and
> is being widely used to force us to mainline that out of tree code.
> That is the risk of using out of tree code.
> 
> I do not want to start a big discussion about this now since there is
> no plan to remove the compatibility at this point.
> 
> -Frank
> 

Re: [RFC PATCH 0/1] Portable Device Tree Connector -- conceptual

[Frank Rowand]

On 07/08/16 12:20, Frank Rowand wrote:
> On 07/08/16 00:26, Pantelis Antoniou wrote:
>> Hi David,
>>
>>> On Jul 7, 2016, at 10:15 , David Gibson  wrote:
>>>
> 
> < snip >
> 
>>> Given that we're going to need new code to support this new connector
>>> model, I think we should also fix some of the uglies in the current
>>> overlay format while we're at it.
>>>
>>
>> We need to keep compatibility with the old format. There are 5 million
>> RPIs sold, half a million beaglebones and C.H.I.P. is coming out too.
>> They all use overlays in one form or another.
>>
>> That’s not counting all the custom boards that actively use them.
>>
>> We have a user base now.
> 
> Please not that I AM NOT suggesting the we remove compatibility with
 ^^^ note

> the old format!!!
> 
> But I need to push back on the idea that we have a user base that we
> need to keep compatibility with.  If I understand correctly, that
> user base is based on using much code that is not in mainline, including
> an altered dtc and a cape manager.
> 
> People using out of tree code can not use the fact that code exists and
> is being widely used to force us to mainline that out of tree code.
> That is the risk of using out of tree code.
> 
> I do not want to start a big discussion about this now since there is
> no plan to remove the compatibility at this point.
> 
> -Frank
> 

Re: [RFC PATCH 0/1] Portable Device Tree Connector -- conceptual

[Frank Rowand]

On 07/07/16 00:15, David Gibson wrote:
> On Sat, Jul 02, 2016 at 04:55:49PM -0700, frowand.l...@gmail.com wrote:
>> From: Frank Rowand 
>>
>> Hi All,
>>
>> This is version 2 of this email.
>>
>> Changes from version 1:
>>
>>   - some rewording of the text
>>   - removed new (theoretical) dtc directive "/connector/"
>>   - added compatibility between mother board and daughter board
>>   - added info on applying a single .dtbo to different connectors
>>   - attached an RFC patch showing the required kernel changes
>>   - changes to mother board .dts connector node:
>>  - removed target_path property
>>  - added connector-socket property
>>   - changes to daughter board .dts connector node:
>>  - added connector-plug property
>>
>>
>> I've been trying to wrap my head around what Pantelis and Rob have written
>> on the subject of a device tree representation of a connector for a
>> daughter board to connect to (eg a cape or a shield) and the representation
>> of the daughter board.  (Or any other physically pluggable object.)
>>
>> After trying to make sense of what had been written (or presented via slides
>> at a conference - thanks Pantelis!), I decided to go back to first principals
>> of what we are trying to accomplish.  I came up with some really simple bogus
>> examples to try to explain what my thought process is.
>>
>> This is an extremely simple example to illustrate the concepts.  It is not
>> meant to represent the complexity of a real board.
>>
>> To start with, assume that the device that will eventually be on a daughter
>> board is first soldered onto the mother board.  The mother board contains
>> two devices connected via bus spi_1.  One device is described in the .dts
>> file, the other is described in an included .dtsi file.
>> Then the device tree files will look like:
>>
>> $ cat board.dts
>> /dts-v1/;
>>
>> / {
>> #address-cells = < 1 >;
>> #size-cells = < 1 >;
>>
>> tree_1: soc@0 {
>> reg = <0x0 0x0>;
>>
>> spi_1: spi1 {
>> };
>> };
>>
>> };
>>
>> _1 {
>> ethernet-switch@0 {
>> compatible = "micrel,ks8995m";
>> };
>> };
>>
>> #include "spi_codec.dtsi"
>>
>>
>> $ cat spi_codec.dtsi
>> _1 {
>>  codec@1 {
>>  compatible = "ti,tlv320aic26";
>>  };
>> };
>>
>>
>> #- codec chip on cape
>>
>> Then suppose I move the codec chip to a cape.  Then I will have the same
>> exact .dts and .dtsi and everything still works.
>>
>>
>> @- codec chip on cape, overlay
>>
>> If I want to use overlays, I only have to add the version and "/plugin/",
>> then use the '-@' flag for dtc (both for the previous board.dts and
>> this spi_codec_overlay.dts):
>>
>> $ cat spi_codec_overlay.dts
>> /dts-v1/;
>>
>> /plugin/;
>>
>> _1 {
>>  codec@1 {
>>  compatible = "ti,tlv320aic26";
>>  };
>> };
>>
>>
>> Pantelis pointed out that the syntax has changed to be:
>>/dts-v1/ /plugin/;
>>
>>
>> #- codec chip on cape, overlay, connector
>>
>> Now we move into the realm of connectors.  My mental model of what the
>> hardware and driver look like has not changed.  The only thing that has
>> changed is that I want to be able to specify that the connector that
>> the cape is plugged into has some pins that are the spi bus /soc/spi1.
>>
>> The following _almost_ but not quite gets me what I want.  Note that
>> the only thing the connector node does is provide some kind of
>> pointer or reference to what node(s) are physically routed through
>> the connector.  The connector node does not need to describe the pins;
>> it only has to point to the node that describes the pins.
>>
>> This example will turn out to be not sufficient.  It is a stepping
>> stone in building my mental model.
>>
>> $ cat board_with_connector.dts
>> /dts-v1/;
>>
>> / {
>>  #address-cells = < 1 >;
>>  #size-cells = < 1 >;
>>
>>  tree_1: soc@0 {
>>  reg = <0x0 0x0>;
>>
>>  spi_1: spi1 {
>>  };
>>  };
>>
>>  connector_1: connector_1 {
>>  spi1 {
>>  target_phandle = <_1>;
>>  };
>>  };
>>
>> };
>>
>> _1 {
>>  ethernet-switch@0 {
>>  compatible = "micrel,ks8995m";
>>  };
>> };
>>
>>
>> $ cat spi_codec_overlay_with_connector.dts
>> /dts-v1/;
>>
>> /plugin/;
>>
>> _1 {
>>  spi1 {
>>  codec@1 {
>>  compatible = "ti,tlv320aic26";
>>  };
>>  };
>> };
>>
>>
>> The result is that the overlay fixup for spi1 on the cape will
>> relocate the spi1 node to /connector_1 in the host tree, so
>> this does not solve the connector linkage yet:
>>
>> -- chunk from the decompiled board_with_connector.dtb:
>>
>>  __symbols__ {
>>  connector_1 = "/connector_1";
>>  };
>>
>> -- chunk from the decompiled spi_codec_overlay_with_connector.dtb:
>>
>>  fragment@0 {
>>  target = 

Re: [RFC PATCH 0/1] Portable Device Tree Connector -- conceptual

[Frank Rowand]

On 07/07/16 00:15, David Gibson wrote:
> On Sat, Jul 02, 2016 at 04:55:49PM -0700, frowand.l...@gmail.com wrote:
>> From: Frank Rowand 
>>
>> Hi All,
>>
>> This is version 2 of this email.
>>
>> Changes from version 1:
>>
>>   - some rewording of the text
>>   - removed new (theoretical) dtc directive "/connector/"
>>   - added compatibility between mother board and daughter board
>>   - added info on applying a single .dtbo to different connectors
>>   - attached an RFC patch showing the required kernel changes
>>   - changes to mother board .dts connector node:
>>  - removed target_path property
>>  - added connector-socket property
>>   - changes to daughter board .dts connector node:
>>  - added connector-plug property
>>
>>
>> I've been trying to wrap my head around what Pantelis and Rob have written
>> on the subject of a device tree representation of a connector for a
>> daughter board to connect to (eg a cape or a shield) and the representation
>> of the daughter board.  (Or any other physically pluggable object.)
>>
>> After trying to make sense of what had been written (or presented via slides
>> at a conference - thanks Pantelis!), I decided to go back to first principals
>> of what we are trying to accomplish.  I came up with some really simple bogus
>> examples to try to explain what my thought process is.
>>
>> This is an extremely simple example to illustrate the concepts.  It is not
>> meant to represent the complexity of a real board.
>>
>> To start with, assume that the device that will eventually be on a daughter
>> board is first soldered onto the mother board.  The mother board contains
>> two devices connected via bus spi_1.  One device is described in the .dts
>> file, the other is described in an included .dtsi file.
>> Then the device tree files will look like:
>>
>> $ cat board.dts
>> /dts-v1/;
>>
>> / {
>> #address-cells = < 1 >;
>> #size-cells = < 1 >;
>>
>> tree_1: soc@0 {
>> reg = <0x0 0x0>;
>>
>> spi_1: spi1 {
>> };
>> };
>>
>> };
>>
>> _1 {
>> ethernet-switch@0 {
>> compatible = "micrel,ks8995m";
>> };
>> };
>>
>> #include "spi_codec.dtsi"
>>
>>
>> $ cat spi_codec.dtsi
>> _1 {
>>  codec@1 {
>>  compatible = "ti,tlv320aic26";
>>  };
>> };
>>
>>
>> #- codec chip on cape
>>
>> Then suppose I move the codec chip to a cape.  Then I will have the same
>> exact .dts and .dtsi and everything still works.
>>
>>
>> @- codec chip on cape, overlay
>>
>> If I want to use overlays, I only have to add the version and "/plugin/",
>> then use the '-@' flag for dtc (both for the previous board.dts and
>> this spi_codec_overlay.dts):
>>
>> $ cat spi_codec_overlay.dts
>> /dts-v1/;
>>
>> /plugin/;
>>
>> _1 {
>>  codec@1 {
>>  compatible = "ti,tlv320aic26";
>>  };
>> };
>>
>>
>> Pantelis pointed out that the syntax has changed to be:
>>/dts-v1/ /plugin/;
>>
>>
>> #- codec chip on cape, overlay, connector
>>
>> Now we move into the realm of connectors.  My mental model of what the
>> hardware and driver look like has not changed.  The only thing that has
>> changed is that I want to be able to specify that the connector that
>> the cape is plugged into has some pins that are the spi bus /soc/spi1.
>>
>> The following _almost_ but not quite gets me what I want.  Note that
>> the only thing the connector node does is provide some kind of
>> pointer or reference to what node(s) are physically routed through
>> the connector.  The connector node does not need to describe the pins;
>> it only has to point to the node that describes the pins.
>>
>> This example will turn out to be not sufficient.  It is a stepping
>> stone in building my mental model.
>>
>> $ cat board_with_connector.dts
>> /dts-v1/;
>>
>> / {
>>  #address-cells = < 1 >;
>>  #size-cells = < 1 >;
>>
>>  tree_1: soc@0 {
>>  reg = <0x0 0x0>;
>>
>>  spi_1: spi1 {
>>  };
>>  };
>>
>>  connector_1: connector_1 {
>>  spi1 {
>>  target_phandle = <_1>;
>>  };
>>  };
>>
>> };
>>
>> _1 {
>>  ethernet-switch@0 {
>>  compatible = "micrel,ks8995m";
>>  };
>> };
>>
>>
>> $ cat spi_codec_overlay_with_connector.dts
>> /dts-v1/;
>>
>> /plugin/;
>>
>> _1 {
>>  spi1 {
>>  codec@1 {
>>  compatible = "ti,tlv320aic26";
>>  };
>>  };
>> };
>>
>>
>> The result is that the overlay fixup for spi1 on the cape will
>> relocate the spi1 node to /connector_1 in the host tree, so
>> this does not solve the connector linkage yet:
>>
>> -- chunk from the decompiled board_with_connector.dtb:
>>
>>  __symbols__ {
>>  connector_1 = "/connector_1";
>>  };
>>
>> -- chunk from the decompiled spi_codec_overlay_with_connector.dtb:
>>
>>  fragment@0 {
>>  target = <0x>;
>>  

Re: [RFC PATCH 0/1] Portable Device Tree Connector -- conceptual

[Frank Rowand]

On 07/08/16 00:26, Pantelis Antoniou wrote:
> Hi David,
> 
>> On Jul 7, 2016, at 10:15 , David Gibson  wrote:
>>

< snip >

>> Given that we're going to need new code to support this new connector
>> model, I think we should also fix some of the uglies in the current
>> overlay format while we're at it.
>>
> 
> We need to keep compatibility with the old format. There are 5 million
> RPIs sold, half a million beaglebones and C.H.I.P. is coming out too.
> They all use overlays in one form or another.
> 
> That’s not counting all the custom boards that actively use them.
> 
> We have a user base now.

Please not that I AM NOT suggesting the we remove compatibility with
the old format!!!

But I need to push back on the idea that we have a user base that we
need to keep compatibility with.  If I understand correctly, that
user base is based on using much code that is not in mainline, including
an altered dtc and a cape manager.

People using out of tree code can not use the fact that code exists and
is being widely used to force us to mainline that out of tree code.
That is the risk of using out of tree code.

I do not want to start a big discussion about this now since there is
no plan to remove the compatibility at this point.

-Frank

Re: [RFC PATCH 0/1] Portable Device Tree Connector -- conceptual

[Frank Rowand]

On 07/08/16 00:26, Pantelis Antoniou wrote:
> Hi David,
> 
>> On Jul 7, 2016, at 10:15 , David Gibson  wrote:
>>

< snip >

>> Given that we're going to need new code to support this new connector
>> model, I think we should also fix some of the uglies in the current
>> overlay format while we're at it.
>>
> 
> We need to keep compatibility with the old format. There are 5 million
> RPIs sold, half a million beaglebones and C.H.I.P. is coming out too.
> They all use overlays in one form or another.
> 
> That’s not counting all the custom boards that actively use them.
> 
> We have a user base now.

Please not that I AM NOT suggesting the we remove compatibility with
the old format!!!

But I need to push back on the idea that we have a user base that we
need to keep compatibility with.  If I understand correctly, that
user base is based on using much code that is not in mainline, including
an altered dtc and a cape manager.

People using out of tree code can not use the fact that code exists and
is being widely used to force us to mainline that out of tree code.
That is the risk of using out of tree code.

I do not want to start a big discussion about this now since there is
no plan to remove the compatibility at this point.

-Frank

Re: [RFC PATCH 0/1] Portable Device Tree Connector -- conceptual

[David Gibson]

On Fri, Jul 08, 2016 at 10:26:15AM +0300, Pantelis Antoniou wrote:
> Hi David,
> 
> > On Jul 7, 2016, at 10:15 , David Gibson  wrote:
> > 
> > On Sat, Jul 02, 2016 at 04:55:49PM -0700, frowand.l...@gmail.com wrote:
> >> From: Frank Rowand 
> >> 
> >> Hi All,
> >> 
> >> This is version 2 of this email.
> >> 
> >> Changes from version 1:
> >> 
> >>  - some rewording of the text
> >>  - removed new (theoretical) dtc directive "/connector/"
> >>  - added compatibility between mother board and daughter board
> >>  - added info on applying a single .dtbo to different connectors
> >>  - attached an RFC patch showing the required kernel changes
> >>  - changes to mother board .dts connector node:
> >> - removed target_path property
> >> - added connector-socket property
> >>  - changes to daughter board .dts connector node:
> >> - added connector-plug property
> >> 
> >> 
> >> I've been trying to wrap my head around what Pantelis and Rob have written
> >> on the subject of a device tree representation of a connector for a
> >> daughter board to connect to (eg a cape or a shield) and the representation
> >> of the daughter board.  (Or any other physically pluggable object.)
> >> 
> >> After trying to make sense of what had been written (or presented via 
> >> slides
> >> at a conference - thanks Pantelis!), I decided to go back to first 
> >> principals
> >> of what we are trying to accomplish.  I came up with some really simple 
> >> bogus
> >> examples to try to explain what my thought process is.
> >> 
> >> This is an extremely simple example to illustrate the concepts.  It is not
> >> meant to represent the complexity of a real board.
> >> 
> >> To start with, assume that the device that will eventually be on a daughter
> >> board is first soldered onto the mother board.  The mother board contains
> >> two devices connected via bus spi_1.  One device is described in the .dts
> >> file, the other is described in an included .dtsi file.
> >> Then the device tree files will look like:
> >> 
> >> $ cat board.dts
> >> /dts-v1/;
> >> 
> >> / {
> >>#address-cells = < 1 >;
> >>#size-cells = < 1 >;
> >> 
> >>tree_1: soc@0 {
> >>reg = <0x0 0x0>;
> >> 
> >>spi_1: spi1 {
> >>};
> >>};
> >> 
> >> };
> >> 
> >> _1 {
> >>ethernet-switch@0 {
> >>compatible = "micrel,ks8995m";
> >>};
> >> };
> >> 
> >> #include "spi_codec.dtsi"
> >> 
> >> 
> >> $ cat spi_codec.dtsi
> >> _1 {
> >>codec@1 {
> >>compatible = "ti,tlv320aic26";
> >>};
> >> };
> >> 
> >> 
> >> #- codec chip on cape
> >> 
> >> Then suppose I move the codec chip to a cape.  Then I will have the same
> >> exact .dts and .dtsi and everything still works.
> >> 
> >> 
> >> @- codec chip on cape, overlay
> >> 
> >> If I want to use overlays, I only have to add the version and "/plugin/",
> >> then use the '-@' flag for dtc (both for the previous board.dts and
> >> this spi_codec_overlay.dts):
> >> 
> >> $ cat spi_codec_overlay.dts
> >> /dts-v1/;
> >> 
> >> /plugin/;
> >> 
> >> _1 {
> >>codec@1 {
> >>compatible = "ti,tlv320aic26";
> >>};
> >> };
> >> 
> >> 
> >> Pantelis pointed out that the syntax has changed to be:
> >>   /dts-v1/ /plugin/;
> >> 
> >> 
> >> #- codec chip on cape, overlay, connector
> >> 
> >> Now we move into the realm of connectors.  My mental model of what the
> >> hardware and driver look like has not changed.  The only thing that has
> >> changed is that I want to be able to specify that the connector that
> >> the cape is plugged into has some pins that are the spi bus /soc/spi1.
> >> 
> >> The following _almost_ but not quite gets me what I want.  Note that
> >> the only thing the connector node does is provide some kind of
> >> pointer or reference to what node(s) are physically routed through
> >> the connector.  The connector node does not need to describe the pins;
> >> it only has to point to the node that describes the pins.
> >> 
> >> This example will turn out to be not sufficient.  It is a stepping
> >> stone in building my mental model.
> >> 
> >> $ cat board_with_connector.dts
> >> /dts-v1/;
> >> 
> >> / {
> >>#address-cells = < 1 >;
> >>#size-cells = < 1 >;
> >> 
> >>tree_1: soc@0 {
> >>reg = <0x0 0x0>;
> >> 
> >>spi_1: spi1 {
> >>};
> >>};
> >> 
> >>connector_1: connector_1 {
> >>spi1 {
> >>target_phandle = <_1>;
> >>};
> >>};
> >> 
> >> };
> >> 
> >> _1 {
> >>ethernet-switch@0 {
> >>compatible = "micrel,ks8995m";
> >>};
> >> };
> >> 
> >> 
> >> $ cat spi_codec_overlay_with_connector.dts
> >> /dts-v1/;
> >> 
> >> /plugin/;
> >> 
> >> _1 {
> >>spi1 {
> >>codec@1 {
> >>compatible = "ti,tlv320aic26";
> >>};
> >>};
> >> };
> >> 
> >> 
> >> 

Re: [RFC PATCH 0/1] Portable Device Tree Connector -- conceptual

[David Gibson]

On Fri, Jul 08, 2016 at 10:26:15AM +0300, Pantelis Antoniou wrote:
> Hi David,
> 
> > On Jul 7, 2016, at 10:15 , David Gibson  wrote:
> > 
> > On Sat, Jul 02, 2016 at 04:55:49PM -0700, frowand.l...@gmail.com wrote:
> >> From: Frank Rowand 
> >> 
> >> Hi All,
> >> 
> >> This is version 2 of this email.
> >> 
> >> Changes from version 1:
> >> 
> >>  - some rewording of the text
> >>  - removed new (theoretical) dtc directive "/connector/"
> >>  - added compatibility between mother board and daughter board
> >>  - added info on applying a single .dtbo to different connectors
> >>  - attached an RFC patch showing the required kernel changes
> >>  - changes to mother board .dts connector node:
> >> - removed target_path property
> >> - added connector-socket property
> >>  - changes to daughter board .dts connector node:
> >> - added connector-plug property
> >> 
> >> 
> >> I've been trying to wrap my head around what Pantelis and Rob have written
> >> on the subject of a device tree representation of a connector for a
> >> daughter board to connect to (eg a cape or a shield) and the representation
> >> of the daughter board.  (Or any other physically pluggable object.)
> >> 
> >> After trying to make sense of what had been written (or presented via 
> >> slides
> >> at a conference - thanks Pantelis!), I decided to go back to first 
> >> principals
> >> of what we are trying to accomplish.  I came up with some really simple 
> >> bogus
> >> examples to try to explain what my thought process is.
> >> 
> >> This is an extremely simple example to illustrate the concepts.  It is not
> >> meant to represent the complexity of a real board.
> >> 
> >> To start with, assume that the device that will eventually be on a daughter
> >> board is first soldered onto the mother board.  The mother board contains
> >> two devices connected via bus spi_1.  One device is described in the .dts
> >> file, the other is described in an included .dtsi file.
> >> Then the device tree files will look like:
> >> 
> >> $ cat board.dts
> >> /dts-v1/;
> >> 
> >> / {
> >>#address-cells = < 1 >;
> >>#size-cells = < 1 >;
> >> 
> >>tree_1: soc@0 {
> >>reg = <0x0 0x0>;
> >> 
> >>spi_1: spi1 {
> >>};
> >>};
> >> 
> >> };
> >> 
> >> _1 {
> >>ethernet-switch@0 {
> >>compatible = "micrel,ks8995m";
> >>};
> >> };
> >> 
> >> #include "spi_codec.dtsi"
> >> 
> >> 
> >> $ cat spi_codec.dtsi
> >> _1 {
> >>codec@1 {
> >>compatible = "ti,tlv320aic26";
> >>};
> >> };
> >> 
> >> 
> >> #- codec chip on cape
> >> 
> >> Then suppose I move the codec chip to a cape.  Then I will have the same
> >> exact .dts and .dtsi and everything still works.
> >> 
> >> 
> >> @- codec chip on cape, overlay
> >> 
> >> If I want to use overlays, I only have to add the version and "/plugin/",
> >> then use the '-@' flag for dtc (both for the previous board.dts and
> >> this spi_codec_overlay.dts):
> >> 
> >> $ cat spi_codec_overlay.dts
> >> /dts-v1/;
> >> 
> >> /plugin/;
> >> 
> >> _1 {
> >>codec@1 {
> >>compatible = "ti,tlv320aic26";
> >>};
> >> };
> >> 
> >> 
> >> Pantelis pointed out that the syntax has changed to be:
> >>   /dts-v1/ /plugin/;
> >> 
> >> 
> >> #- codec chip on cape, overlay, connector
> >> 
> >> Now we move into the realm of connectors.  My mental model of what the
> >> hardware and driver look like has not changed.  The only thing that has
> >> changed is that I want to be able to specify that the connector that
> >> the cape is plugged into has some pins that are the spi bus /soc/spi1.
> >> 
> >> The following _almost_ but not quite gets me what I want.  Note that
> >> the only thing the connector node does is provide some kind of
> >> pointer or reference to what node(s) are physically routed through
> >> the connector.  The connector node does not need to describe the pins;
> >> it only has to point to the node that describes the pins.
> >> 
> >> This example will turn out to be not sufficient.  It is a stepping
> >> stone in building my mental model.
> >> 
> >> $ cat board_with_connector.dts
> >> /dts-v1/;
> >> 
> >> / {
> >>#address-cells = < 1 >;
> >>#size-cells = < 1 >;
> >> 
> >>tree_1: soc@0 {
> >>reg = <0x0 0x0>;
> >> 
> >>spi_1: spi1 {
> >>};
> >>};
> >> 
> >>connector_1: connector_1 {
> >>spi1 {
> >>target_phandle = <_1>;
> >>};
> >>};
> >> 
> >> };
> >> 
> >> _1 {
> >>ethernet-switch@0 {
> >>compatible = "micrel,ks8995m";
> >>};
> >> };
> >> 
> >> 
> >> $ cat spi_codec_overlay_with_connector.dts
> >> /dts-v1/;
> >> 
> >> /plugin/;
> >> 
> >> _1 {
> >>spi1 {
> >>codec@1 {
> >>compatible = "ti,tlv320aic26";
> >>};
> >>};
> >> };
> >> 
> >> 
> >> The result is that the overlay fixup for spi1 on the 

Re: [RFC PATCH 0/1] Portable Device Tree Connector -- conceptual

[Pantelis Antoniou]

Hi David,

> On Jul 7, 2016, at 10:15 , David Gibson  wrote:
> 
> On Sat, Jul 02, 2016 at 04:55:49PM -0700, frowand.l...@gmail.com wrote:
>> From: Frank Rowand 
>> 
>> Hi All,
>> 
>> This is version 2 of this email.
>> 
>> Changes from version 1:
>> 
>>  - some rewording of the text
>>  - removed new (theoretical) dtc directive "/connector/"
>>  - added compatibility between mother board and daughter board
>>  - added info on applying a single .dtbo to different connectors
>>  - attached an RFC patch showing the required kernel changes
>>  - changes to mother board .dts connector node:
>> - removed target_path property
>> - added connector-socket property
>>  - changes to daughter board .dts connector node:
>> - added connector-plug property
>> 
>> 
>> I've been trying to wrap my head around what Pantelis and Rob have written
>> on the subject of a device tree representation of a connector for a
>> daughter board to connect to (eg a cape or a shield) and the representation
>> of the daughter board.  (Or any other physically pluggable object.)
>> 
>> After trying to make sense of what had been written (or presented via slides
>> at a conference - thanks Pantelis!), I decided to go back to first principals
>> of what we are trying to accomplish.  I came up with some really simple bogus
>> examples to try to explain what my thought process is.
>> 
>> This is an extremely simple example to illustrate the concepts.  It is not
>> meant to represent the complexity of a real board.
>> 
>> To start with, assume that the device that will eventually be on a daughter
>> board is first soldered onto the mother board.  The mother board contains
>> two devices connected via bus spi_1.  One device is described in the .dts
>> file, the other is described in an included .dtsi file.
>> Then the device tree files will look like:
>> 
>> $ cat board.dts
>> /dts-v1/;
>> 
>> / {
>>#address-cells = < 1 >;
>>#size-cells = < 1 >;
>> 
>>tree_1: soc@0 {
>>reg = <0x0 0x0>;
>> 
>>spi_1: spi1 {
>>};
>>};
>> 
>> };
>> 
>> _1 {
>>ethernet-switch@0 {
>>compatible = "micrel,ks8995m";
>>};
>> };
>> 
>> #include "spi_codec.dtsi"
>> 
>> 
>> $ cat spi_codec.dtsi
>> _1 {
>>  codec@1 {
>>  compatible = "ti,tlv320aic26";
>>  };
>> };
>> 
>> 
>> #- codec chip on cape
>> 
>> Then suppose I move the codec chip to a cape.  Then I will have the same
>> exact .dts and .dtsi and everything still works.
>> 
>> 
>> @- codec chip on cape, overlay
>> 
>> If I want to use overlays, I only have to add the version and "/plugin/",
>> then use the '-@' flag for dtc (both for the previous board.dts and
>> this spi_codec_overlay.dts):
>> 
>> $ cat spi_codec_overlay.dts
>> /dts-v1/;
>> 
>> /plugin/;
>> 
>> _1 {
>>  codec@1 {
>>  compatible = "ti,tlv320aic26";
>>  };
>> };
>> 
>> 
>> Pantelis pointed out that the syntax has changed to be:
>>   /dts-v1/ /plugin/;
>> 
>> 
>> #- codec chip on cape, overlay, connector
>> 
>> Now we move into the realm of connectors.  My mental model of what the
>> hardware and driver look like has not changed.  The only thing that has
>> changed is that I want to be able to specify that the connector that
>> the cape is plugged into has some pins that are the spi bus /soc/spi1.
>> 
>> The following _almost_ but not quite gets me what I want.  Note that
>> the only thing the connector node does is provide some kind of
>> pointer or reference to what node(s) are physically routed through
>> the connector.  The connector node does not need to describe the pins;
>> it only has to point to the node that describes the pins.
>> 
>> This example will turn out to be not sufficient.  It is a stepping
>> stone in building my mental model.
>> 
>> $ cat board_with_connector.dts
>> /dts-v1/;
>> 
>> / {
>>  #address-cells = < 1 >;
>>  #size-cells = < 1 >;
>> 
>>  tree_1: soc@0 {
>>  reg = <0x0 0x0>;
>> 
>>  spi_1: spi1 {
>>  };
>>  };
>> 
>>  connector_1: connector_1 {
>>  spi1 {
>>  target_phandle = <_1>;
>>  };
>>  };
>> 
>> };
>> 
>> _1 {
>>  ethernet-switch@0 {
>>  compatible = "micrel,ks8995m";
>>  };
>> };
>> 
>> 
>> $ cat spi_codec_overlay_with_connector.dts
>> /dts-v1/;
>> 
>> /plugin/;
>> 
>> _1 {
>>  spi1 {
>>  codec@1 {
>>  compatible = "ti,tlv320aic26";
>>  };
>>  };
>> };
>> 
>> 
>> The result is that the overlay fixup for spi1 on the cape will
>> relocate the spi1 node to /connector_1 in the host tree, so
>> this does not solve the connector linkage yet:
>> 
>> -- chunk from the decompiled board_with_connector.dtb:
>> 
>>  __symbols__ {
>>  connector_1 = "/connector_1";
>>  };
>> 
>> -- chunk from the decompiled 

Re: [RFC PATCH 0/1] Portable Device Tree Connector -- conceptual

[Pantelis Antoniou]

Hi David,

> On Jul 7, 2016, at 10:15 , David Gibson  wrote:
> 
> On Sat, Jul 02, 2016 at 04:55:49PM -0700, frowand.l...@gmail.com wrote:
>> From: Frank Rowand 
>> 
>> Hi All,
>> 
>> This is version 2 of this email.
>> 
>> Changes from version 1:
>> 
>>  - some rewording of the text
>>  - removed new (theoretical) dtc directive "/connector/"
>>  - added compatibility between mother board and daughter board
>>  - added info on applying a single .dtbo to different connectors
>>  - attached an RFC patch showing the required kernel changes
>>  - changes to mother board .dts connector node:
>> - removed target_path property
>> - added connector-socket property
>>  - changes to daughter board .dts connector node:
>> - added connector-plug property
>> 
>> 
>> I've been trying to wrap my head around what Pantelis and Rob have written
>> on the subject of a device tree representation of a connector for a
>> daughter board to connect to (eg a cape or a shield) and the representation
>> of the daughter board.  (Or any other physically pluggable object.)
>> 
>> After trying to make sense of what had been written (or presented via slides
>> at a conference - thanks Pantelis!), I decided to go back to first principals
>> of what we are trying to accomplish.  I came up with some really simple bogus
>> examples to try to explain what my thought process is.
>> 
>> This is an extremely simple example to illustrate the concepts.  It is not
>> meant to represent the complexity of a real board.
>> 
>> To start with, assume that the device that will eventually be on a daughter
>> board is first soldered onto the mother board.  The mother board contains
>> two devices connected via bus spi_1.  One device is described in the .dts
>> file, the other is described in an included .dtsi file.
>> Then the device tree files will look like:
>> 
>> $ cat board.dts
>> /dts-v1/;
>> 
>> / {
>>#address-cells = < 1 >;
>>#size-cells = < 1 >;
>> 
>>tree_1: soc@0 {
>>reg = <0x0 0x0>;
>> 
>>spi_1: spi1 {
>>};
>>};
>> 
>> };
>> 
>> _1 {
>>ethernet-switch@0 {
>>compatible = "micrel,ks8995m";
>>};
>> };
>> 
>> #include "spi_codec.dtsi"
>> 
>> 
>> $ cat spi_codec.dtsi
>> _1 {
>>  codec@1 {
>>  compatible = "ti,tlv320aic26";
>>  };
>> };
>> 
>> 
>> #- codec chip on cape
>> 
>> Then suppose I move the codec chip to a cape.  Then I will have the same
>> exact .dts and .dtsi and everything still works.
>> 
>> 
>> @- codec chip on cape, overlay
>> 
>> If I want to use overlays, I only have to add the version and "/plugin/",
>> then use the '-@' flag for dtc (both for the previous board.dts and
>> this spi_codec_overlay.dts):
>> 
>> $ cat spi_codec_overlay.dts
>> /dts-v1/;
>> 
>> /plugin/;
>> 
>> _1 {
>>  codec@1 {
>>  compatible = "ti,tlv320aic26";
>>  };
>> };
>> 
>> 
>> Pantelis pointed out that the syntax has changed to be:
>>   /dts-v1/ /plugin/;
>> 
>> 
>> #- codec chip on cape, overlay, connector
>> 
>> Now we move into the realm of connectors.  My mental model of what the
>> hardware and driver look like has not changed.  The only thing that has
>> changed is that I want to be able to specify that the connector that
>> the cape is plugged into has some pins that are the spi bus /soc/spi1.
>> 
>> The following _almost_ but not quite gets me what I want.  Note that
>> the only thing the connector node does is provide some kind of
>> pointer or reference to what node(s) are physically routed through
>> the connector.  The connector node does not need to describe the pins;
>> it only has to point to the node that describes the pins.
>> 
>> This example will turn out to be not sufficient.  It is a stepping
>> stone in building my mental model.
>> 
>> $ cat board_with_connector.dts
>> /dts-v1/;
>> 
>> / {
>>  #address-cells = < 1 >;
>>  #size-cells = < 1 >;
>> 
>>  tree_1: soc@0 {
>>  reg = <0x0 0x0>;
>> 
>>  spi_1: spi1 {
>>  };
>>  };
>> 
>>  connector_1: connector_1 {
>>  spi1 {
>>  target_phandle = <_1>;
>>  };
>>  };
>> 
>> };
>> 
>> _1 {
>>  ethernet-switch@0 {
>>  compatible = "micrel,ks8995m";
>>  };
>> };
>> 
>> 
>> $ cat spi_codec_overlay_with_connector.dts
>> /dts-v1/;
>> 
>> /plugin/;
>> 
>> _1 {
>>  spi1 {
>>  codec@1 {
>>  compatible = "ti,tlv320aic26";
>>  };
>>  };
>> };
>> 
>> 
>> The result is that the overlay fixup for spi1 on the cape will
>> relocate the spi1 node to /connector_1 in the host tree, so
>> this does not solve the connector linkage yet:
>> 
>> -- chunk from the decompiled board_with_connector.dtb:
>> 
>>  __symbols__ {
>>  connector_1 = "/connector_1";
>>  };
>> 
>> -- chunk from the decompiled spi_codec_overlay_with_connector.dtb:
>> 
>>  fragment@0 {

Re: [RFC PATCH 0/1] Portable Device Tree Connector -- conceptual

[David Gibson]

On Sat, Jul 02, 2016 at 04:55:49PM -0700, frowand.l...@gmail.com wrote:
> From: Frank Rowand 
> 
> Hi All,
> 
> This is version 2 of this email.
> 
> Changes from version 1:
> 
>   - some rewording of the text
>   - removed new (theoretical) dtc directive "/connector/"
>   - added compatibility between mother board and daughter board
>   - added info on applying a single .dtbo to different connectors
>   - attached an RFC patch showing the required kernel changes
>   - changes to mother board .dts connector node:
>  - removed target_path property
>  - added connector-socket property
>   - changes to daughter board .dts connector node:
>  - added connector-plug property
> 
> 
> I've been trying to wrap my head around what Pantelis and Rob have written
> on the subject of a device tree representation of a connector for a
> daughter board to connect to (eg a cape or a shield) and the representation
> of the daughter board.  (Or any other physically pluggable object.)
> 
> After trying to make sense of what had been written (or presented via slides
> at a conference - thanks Pantelis!), I decided to go back to first principals
> of what we are trying to accomplish.  I came up with some really simple bogus
> examples to try to explain what my thought process is.
> 
> This is an extremely simple example to illustrate the concepts.  It is not
> meant to represent the complexity of a real board.
> 
> To start with, assume that the device that will eventually be on a daughter
> board is first soldered onto the mother board.  The mother board contains
> two devices connected via bus spi_1.  One device is described in the .dts
> file, the other is described in an included .dtsi file.
> Then the device tree files will look like:
> 
> $ cat board.dts
> /dts-v1/;
> 
> / {
> #address-cells = < 1 >;
> #size-cells = < 1 >;
> 
> tree_1: soc@0 {
> reg = <0x0 0x0>;
> 
> spi_1: spi1 {
> };
> };
> 
> };
> 
> _1 {
> ethernet-switch@0 {
> compatible = "micrel,ks8995m";
> };
> };
> 
> #include "spi_codec.dtsi"
> 
> 
> $ cat spi_codec.dtsi
> _1 {
>   codec@1 {
>   compatible = "ti,tlv320aic26";
>   };
> };
> 
> 
> #- codec chip on cape
> 
> Then suppose I move the codec chip to a cape.  Then I will have the same
> exact .dts and .dtsi and everything still works.
> 
> 
> @- codec chip on cape, overlay
> 
> If I want to use overlays, I only have to add the version and "/plugin/",
> then use the '-@' flag for dtc (both for the previous board.dts and
> this spi_codec_overlay.dts):
> 
> $ cat spi_codec_overlay.dts
> /dts-v1/;
> 
> /plugin/;
> 
> _1 {
>   codec@1 {
>   compatible = "ti,tlv320aic26";
>   };
> };
> 
> 
> Pantelis pointed out that the syntax has changed to be:
>/dts-v1/ /plugin/;
> 
> 
> #- codec chip on cape, overlay, connector
> 
> Now we move into the realm of connectors.  My mental model of what the
> hardware and driver look like has not changed.  The only thing that has
> changed is that I want to be able to specify that the connector that
> the cape is plugged into has some pins that are the spi bus /soc/spi1.
> 
> The following _almost_ but not quite gets me what I want.  Note that
> the only thing the connector node does is provide some kind of
> pointer or reference to what node(s) are physically routed through
> the connector.  The connector node does not need to describe the pins;
> it only has to point to the node that describes the pins.
> 
> This example will turn out to be not sufficient.  It is a stepping
> stone in building my mental model.
> 
> $ cat board_with_connector.dts
> /dts-v1/;
> 
> / {
>   #address-cells = < 1 >;
>   #size-cells = < 1 >;
> 
>   tree_1: soc@0 {
>   reg = <0x0 0x0>;
> 
>   spi_1: spi1 {
>   };
>   };
> 
>   connector_1: connector_1 {
>   spi1 {
>   target_phandle = <_1>;
>   };
>   };
> 
> };
> 
> _1 {
>   ethernet-switch@0 {
>   compatible = "micrel,ks8995m";
>   };
> };
> 
> 
> $ cat spi_codec_overlay_with_connector.dts
> /dts-v1/;
> 
> /plugin/;
> 
> _1 {
>   spi1 {
>   codec@1 {
>   compatible = "ti,tlv320aic26";
>   };
>   };
> };
> 
> 
> The result is that the overlay fixup for spi1 on the cape will
> relocate the spi1 node to /connector_1 in the host tree, so
> this does not solve the connector linkage yet:
> 
> -- chunk from the decompiled board_with_connector.dtb:
> 
>   __symbols__ {
>   connector_1 = "/connector_1";
>   };
> 
> -- chunk from the decompiled spi_codec_overlay_with_connector.dtb:
> 
>   fragment@0 {
>   target = <0x>;
>   __overlay__ {
>   spi1 {
>   codec@1 {
>  

Re: [RFC PATCH 0/1] Portable Device Tree Connector -- conceptual

[David Gibson]

On Sat, Jul 02, 2016 at 04:55:49PM -0700, frowand.l...@gmail.com wrote:
> From: Frank Rowand 
> 
> Hi All,
> 
> This is version 2 of this email.
> 
> Changes from version 1:
> 
>   - some rewording of the text
>   - removed new (theoretical) dtc directive "/connector/"
>   - added compatibility between mother board and daughter board
>   - added info on applying a single .dtbo to different connectors
>   - attached an RFC patch showing the required kernel changes
>   - changes to mother board .dts connector node:
>  - removed target_path property
>  - added connector-socket property
>   - changes to daughter board .dts connector node:
>  - added connector-plug property
> 
> 
> I've been trying to wrap my head around what Pantelis and Rob have written
> on the subject of a device tree representation of a connector for a
> daughter board to connect to (eg a cape or a shield) and the representation
> of the daughter board.  (Or any other physically pluggable object.)
> 
> After trying to make sense of what had been written (or presented via slides
> at a conference - thanks Pantelis!), I decided to go back to first principals
> of what we are trying to accomplish.  I came up with some really simple bogus
> examples to try to explain what my thought process is.
> 
> This is an extremely simple example to illustrate the concepts.  It is not
> meant to represent the complexity of a real board.
> 
> To start with, assume that the device that will eventually be on a daughter
> board is first soldered onto the mother board.  The mother board contains
> two devices connected via bus spi_1.  One device is described in the .dts
> file, the other is described in an included .dtsi file.
> Then the device tree files will look like:
> 
> $ cat board.dts
> /dts-v1/;
> 
> / {
> #address-cells = < 1 >;
> #size-cells = < 1 >;
> 
> tree_1: soc@0 {
> reg = <0x0 0x0>;
> 
> spi_1: spi1 {
> };
> };
> 
> };
> 
> _1 {
> ethernet-switch@0 {
> compatible = "micrel,ks8995m";
> };
> };
> 
> #include "spi_codec.dtsi"
> 
> 
> $ cat spi_codec.dtsi
> _1 {
>   codec@1 {
>   compatible = "ti,tlv320aic26";
>   };
> };
> 
> 
> #- codec chip on cape
> 
> Then suppose I move the codec chip to a cape.  Then I will have the same
> exact .dts and .dtsi and everything still works.
> 
> 
> @- codec chip on cape, overlay
> 
> If I want to use overlays, I only have to add the version and "/plugin/",
> then use the '-@' flag for dtc (both for the previous board.dts and
> this spi_codec_overlay.dts):
> 
> $ cat spi_codec_overlay.dts
> /dts-v1/;
> 
> /plugin/;
> 
> _1 {
>   codec@1 {
>   compatible = "ti,tlv320aic26";
>   };
> };
> 
> 
> Pantelis pointed out that the syntax has changed to be:
>/dts-v1/ /plugin/;
> 
> 
> #- codec chip on cape, overlay, connector
> 
> Now we move into the realm of connectors.  My mental model of what the
> hardware and driver look like has not changed.  The only thing that has
> changed is that I want to be able to specify that the connector that
> the cape is plugged into has some pins that are the spi bus /soc/spi1.
> 
> The following _almost_ but not quite gets me what I want.  Note that
> the only thing the connector node does is provide some kind of
> pointer or reference to what node(s) are physically routed through
> the connector.  The connector node does not need to describe the pins;
> it only has to point to the node that describes the pins.
> 
> This example will turn out to be not sufficient.  It is a stepping
> stone in building my mental model.
> 
> $ cat board_with_connector.dts
> /dts-v1/;
> 
> / {
>   #address-cells = < 1 >;
>   #size-cells = < 1 >;
> 
>   tree_1: soc@0 {
>   reg = <0x0 0x0>;
> 
>   spi_1: spi1 {
>   };
>   };
> 
>   connector_1: connector_1 {
>   spi1 {
>   target_phandle = <_1>;
>   };
>   };
> 
> };
> 
> _1 {
>   ethernet-switch@0 {
>   compatible = "micrel,ks8995m";
>   };
> };
> 
> 
> $ cat spi_codec_overlay_with_connector.dts
> /dts-v1/;
> 
> /plugin/;
> 
> _1 {
>   spi1 {
>   codec@1 {
>   compatible = "ti,tlv320aic26";
>   };
>   };
> };
> 
> 
> The result is that the overlay fixup for spi1 on the cape will
> relocate the spi1 node to /connector_1 in the host tree, so
> this does not solve the connector linkage yet:
> 
> -- chunk from the decompiled board_with_connector.dtb:
> 
>   __symbols__ {
>   connector_1 = "/connector_1";
>   };
> 
> -- chunk from the decompiled spi_codec_overlay_with_connector.dtb:
> 
>   fragment@0 {
>   target = <0x>;
>   __overlay__ {
>   spi1 {
>   codec@1 {
>   

Re: [RFC PATCH 0/1] Portable Device Tree Connector -- conceptual

[Frank Rowand]

On 07/05/16 11:01, Pantelis Antoniou wrote:
> Hi Frank,
> 
> Sorry for taking a bit to reply, had to grok it well first.
> 
>> On Jul 3, 2016, at 02:55 , frowand.l...@gmail.com wrote:
>>
>> From: Frank Rowand 
>>
>> Hi All,
>>
>> This is version 2 of this email.
>>
>> Changes from version 1:
>>
>>  - some rewording of the text
>>  - removed new (theoretical) dtc directive "/connector/"
>>  - added compatibility between mother board and daughter board
>>  - added info on applying a single .dtbo to different connectors
>>  - attached an RFC patch showing the required kernel changes
>>  - changes to mother board .dts connector node:
>> - removed target_path property
>> - added connector-socket property
>>  - changes to daughter board .dts connector node:
>> - added connector-plug property
>>
>>
>> I've been trying to wrap my head around what Pantelis and Rob have written
>> on the subject of a device tree representation of a connector for a
>> daughter board to connect to (eg a cape or a shield) and the representation
>> of the daughter board.  (Or any other physically pluggable object.)
>>
>> After trying to make sense of what had been written (or presented via slides
>> at a conference - thanks Pantelis!), I decided to go back to first principals
>> of what we are trying to accomplish.  I came up with some really simple bogus
>> examples to try to explain what my thought process is.
>>
>> This is an extremely simple example to illustrate the concepts.  It is not
>> meant to represent the complexity of a real board.
>>
>> To start with, assume that the device that will eventually be on a daughter
>> board is first soldered onto the mother board.  The mother board contains
>> two devices connected via bus spi_1.  One device is described in the .dts
>> file, the other is described in an included .dtsi file.
>> Then the device tree files will look like:
>>
>> $ cat board.dts
>> /dts-v1/;
>>
>> / {
>>#address-cells = < 1 >;
>>#size-cells = < 1 >;
>>
>>tree_1: soc@0 {
>>reg = <0x0 0x0>;
>>
>>spi_1: spi1 {
>>};
>>};
>>
>> };
>>
>> _1 {
>>ethernet-switch@0 {
>>compatible = "micrel,ks8995m";
>>};
>> };
>>
>> #include "spi_codec.dtsi"
>>
>>
>> $ cat spi_codec.dtsi
>> _1 {
>>  codec@1 {
>>  compatible = "ti,tlv320aic26";
>>  };
>> };
>>
>>
>> #- codec chip on cape
>>
>> Then suppose I move the codec chip to a cape.  Then I will have the same
>> exact .dts and .dtsi and everything still works.
>>
>>
>> @- codec chip on cape, overlay
>>
>> If I want to use overlays, I only have to add the version and "/plugin/",
>> then use the '-@' flag for dtc (both for the previous board.dts and
>> this spi_codec_overlay.dts):
>>
>> $ cat spi_codec_overlay.dts
>> /dts-v1/;
>>
>> /plugin/;
>>
>> _1 {
>>  codec@1 {
>>  compatible = "ti,tlv320aic26";
>>  };
>> };
>>
>>
>> Pantelis pointed out that the syntax has changed to be:
>>   /dts-v1/ /plugin/;
>>
>>
>> #- codec chip on cape, overlay, connector
>>
>> Now we move into the realm of connectors.  My mental model of what the
>> hardware and driver look like has not changed.  The only thing that has
>> changed is that I want to be able to specify that the connector that
>> the cape is plugged into has some pins that are the spi bus /soc/spi1.
>>
>> The following _almost_ but not quite gets me what I want.  Note that
>> the only thing the connector node does is provide some kind of
>> pointer or reference to what node(s) are physically routed through
>> the connector.  The connector node does not need to describe the pins;
>> it only has to point to the node that describes the pins.
>>


>> This example will turn out to be not sufficient.  It is a stepping
>> stone in building my mental model.

  ^^

>>
>> $ cat board_with_connector.dts
>> /dts-v1/;
>>
>> / {
>>  #address-cells = < 1 >;
>>  #size-cells = < 1 >;
>>
>>  tree_1: soc@0 {
>>  reg = <0x0 0x0>;
>>
>>  spi_1: spi1 {
>>  };
>>  };
>>
>>  connector_1: connector_1 {
>>  spi1 {
>>  target_phandle = <_1>;
>>  };
>>  };
>>
>> };
>>
>> _1 {
>>  ethernet-switch@0 {
>>  compatible = "micrel,ks8995m";
>>  };
>> };
>>
>>
>> $ cat spi_codec_overlay_with_connector.dts
>> /dts-v1/;
>>
>> /plugin/;
>>
>> _1 {
>>  spi1 {
>>  codec@1 {
>>  compatible = "ti,tlv320aic26";
>>  };
>>  };
>> };
>>

There is an "off by one" here.  The above method was a mental stepping
stone.  You are correct that it does not work.

The stuff below "#- magic new syntax" is what you need to look
at.  That was where I resolved the problem that remains at this step.


> 
> You target connector_1. In theory multiples of the same connector
> may be available.
> 
> There are 

Re: [RFC PATCH 0/1] Portable Device Tree Connector -- conceptual

[Frank Rowand]

On 07/05/16 11:01, Pantelis Antoniou wrote:
> Hi Frank,
> 
> Sorry for taking a bit to reply, had to grok it well first.
> 
>> On Jul 3, 2016, at 02:55 , frowand.l...@gmail.com wrote:
>>
>> From: Frank Rowand 
>>
>> Hi All,
>>
>> This is version 2 of this email.
>>
>> Changes from version 1:
>>
>>  - some rewording of the text
>>  - removed new (theoretical) dtc directive "/connector/"
>>  - added compatibility between mother board and daughter board
>>  - added info on applying a single .dtbo to different connectors
>>  - attached an RFC patch showing the required kernel changes
>>  - changes to mother board .dts connector node:
>> - removed target_path property
>> - added connector-socket property
>>  - changes to daughter board .dts connector node:
>> - added connector-plug property
>>
>>
>> I've been trying to wrap my head around what Pantelis and Rob have written
>> on the subject of a device tree representation of a connector for a
>> daughter board to connect to (eg a cape or a shield) and the representation
>> of the daughter board.  (Or any other physically pluggable object.)
>>
>> After trying to make sense of what had been written (or presented via slides
>> at a conference - thanks Pantelis!), I decided to go back to first principals
>> of what we are trying to accomplish.  I came up with some really simple bogus
>> examples to try to explain what my thought process is.
>>
>> This is an extremely simple example to illustrate the concepts.  It is not
>> meant to represent the complexity of a real board.
>>
>> To start with, assume that the device that will eventually be on a daughter
>> board is first soldered onto the mother board.  The mother board contains
>> two devices connected via bus spi_1.  One device is described in the .dts
>> file, the other is described in an included .dtsi file.
>> Then the device tree files will look like:
>>
>> $ cat board.dts
>> /dts-v1/;
>>
>> / {
>>#address-cells = < 1 >;
>>#size-cells = < 1 >;
>>
>>tree_1: soc@0 {
>>reg = <0x0 0x0>;
>>
>>spi_1: spi1 {
>>};
>>};
>>
>> };
>>
>> _1 {
>>ethernet-switch@0 {
>>compatible = "micrel,ks8995m";
>>};
>> };
>>
>> #include "spi_codec.dtsi"
>>
>>
>> $ cat spi_codec.dtsi
>> _1 {
>>  codec@1 {
>>  compatible = "ti,tlv320aic26";
>>  };
>> };
>>
>>
>> #- codec chip on cape
>>
>> Then suppose I move the codec chip to a cape.  Then I will have the same
>> exact .dts and .dtsi and everything still works.
>>
>>
>> @- codec chip on cape, overlay
>>
>> If I want to use overlays, I only have to add the version and "/plugin/",
>> then use the '-@' flag for dtc (both for the previous board.dts and
>> this spi_codec_overlay.dts):
>>
>> $ cat spi_codec_overlay.dts
>> /dts-v1/;
>>
>> /plugin/;
>>
>> _1 {
>>  codec@1 {
>>  compatible = "ti,tlv320aic26";
>>  };
>> };
>>
>>
>> Pantelis pointed out that the syntax has changed to be:
>>   /dts-v1/ /plugin/;
>>
>>
>> #- codec chip on cape, overlay, connector
>>
>> Now we move into the realm of connectors.  My mental model of what the
>> hardware and driver look like has not changed.  The only thing that has
>> changed is that I want to be able to specify that the connector that
>> the cape is plugged into has some pins that are the spi bus /soc/spi1.
>>
>> The following _almost_ but not quite gets me what I want.  Note that
>> the only thing the connector node does is provide some kind of
>> pointer or reference to what node(s) are physically routed through
>> the connector.  The connector node does not need to describe the pins;
>> it only has to point to the node that describes the pins.
>>


>> This example will turn out to be not sufficient.  It is a stepping
>> stone in building my mental model.

  ^^

>>
>> $ cat board_with_connector.dts
>> /dts-v1/;
>>
>> / {
>>  #address-cells = < 1 >;
>>  #size-cells = < 1 >;
>>
>>  tree_1: soc@0 {
>>  reg = <0x0 0x0>;
>>
>>  spi_1: spi1 {
>>  };
>>  };
>>
>>  connector_1: connector_1 {
>>  spi1 {
>>  target_phandle = <_1>;
>>  };
>>  };
>>
>> };
>>
>> _1 {
>>  ethernet-switch@0 {
>>  compatible = "micrel,ks8995m";
>>  };
>> };
>>
>>
>> $ cat spi_codec_overlay_with_connector.dts
>> /dts-v1/;
>>
>> /plugin/;
>>
>> _1 {
>>  spi1 {
>>  codec@1 {
>>  compatible = "ti,tlv320aic26";
>>  };
>>  };
>> };
>>

There is an "off by one" here.  The above method was a mental stepping
stone.  You are correct that it does not work.

The stuff below "#- magic new syntax" is what you need to look
at.  That was where I resolved the problem that remains at this step.


> 
> You target connector_1. In theory multiples of the same connector
> may be available.
> 
> There are complications about how they 

Re: [RFC PATCH 0/1] Portable Device Tree Connector -- conceptual

[Pantelis Antoniou]

Hi Frank,

Sorry for taking a bit to reply, had to grok it well first.

> On Jul 3, 2016, at 02:55 , frowand.l...@gmail.com wrote:
> 
> From: Frank Rowand 
> 
> Hi All,
> 
> This is version 2 of this email.
> 
> Changes from version 1:
> 
>  - some rewording of the text
>  - removed new (theoretical) dtc directive "/connector/"
>  - added compatibility between mother board and daughter board
>  - added info on applying a single .dtbo to different connectors
>  - attached an RFC patch showing the required kernel changes
>  - changes to mother board .dts connector node:
> - removed target_path property
> - added connector-socket property
>  - changes to daughter board .dts connector node:
> - added connector-plug property
> 
> 
> I've been trying to wrap my head around what Pantelis and Rob have written
> on the subject of a device tree representation of a connector for a
> daughter board to connect to (eg a cape or a shield) and the representation
> of the daughter board.  (Or any other physically pluggable object.)
> 
> After trying to make sense of what had been written (or presented via slides
> at a conference - thanks Pantelis!), I decided to go back to first principals
> of what we are trying to accomplish.  I came up with some really simple bogus
> examples to try to explain what my thought process is.
> 
> This is an extremely simple example to illustrate the concepts.  It is not
> meant to represent the complexity of a real board.
> 
> To start with, assume that the device that will eventually be on a daughter
> board is first soldered onto the mother board.  The mother board contains
> two devices connected via bus spi_1.  One device is described in the .dts
> file, the other is described in an included .dtsi file.
> Then the device tree files will look like:
> 
> $ cat board.dts
> /dts-v1/;
> 
> / {
>#address-cells = < 1 >;
>#size-cells = < 1 >;
> 
>tree_1: soc@0 {
>reg = <0x0 0x0>;
> 
>spi_1: spi1 {
>};
>};
> 
> };
> 
> _1 {
>ethernet-switch@0 {
>compatible = "micrel,ks8995m";
>};
> };
> 
> #include "spi_codec.dtsi"
> 
> 
> $ cat spi_codec.dtsi
> _1 {
>   codec@1 {
>   compatible = "ti,tlv320aic26";
>   };
> };
> 
> 
> #- codec chip on cape
> 
> Then suppose I move the codec chip to a cape.  Then I will have the same
> exact .dts and .dtsi and everything still works.
> 
> 
> @- codec chip on cape, overlay
> 
> If I want to use overlays, I only have to add the version and "/plugin/",
> then use the '-@' flag for dtc (both for the previous board.dts and
> this spi_codec_overlay.dts):
> 
> $ cat spi_codec_overlay.dts
> /dts-v1/;
> 
> /plugin/;
> 
> _1 {
>   codec@1 {
>   compatible = "ti,tlv320aic26";
>   };
> };
> 
> 
> Pantelis pointed out that the syntax has changed to be:
>   /dts-v1/ /plugin/;
> 
> 
> #- codec chip on cape, overlay, connector
> 
> Now we move into the realm of connectors.  My mental model of what the
> hardware and driver look like has not changed.  The only thing that has
> changed is that I want to be able to specify that the connector that
> the cape is plugged into has some pins that are the spi bus /soc/spi1.
> 
> The following _almost_ but not quite gets me what I want.  Note that
> the only thing the connector node does is provide some kind of
> pointer or reference to what node(s) are physically routed through
> the connector.  The connector node does not need to describe the pins;
> it only has to point to the node that describes the pins.
> 
> This example will turn out to be not sufficient.  It is a stepping
> stone in building my mental model.
> 
> $ cat board_with_connector.dts
> /dts-v1/;
> 
> / {
>   #address-cells = < 1 >;
>   #size-cells = < 1 >;
> 
>   tree_1: soc@0 {
>   reg = <0x0 0x0>;
> 
>   spi_1: spi1 {
>   };
>   };
> 
>   connector_1: connector_1 {
>   spi1 {
>   target_phandle = <_1>;
>   };
>   };
> 
> };
> 
> _1 {
>   ethernet-switch@0 {
>   compatible = "micrel,ks8995m";
>   };
> };
> 
> 
> $ cat spi_codec_overlay_with_connector.dts
> /dts-v1/;
> 
> /plugin/;
> 
> _1 {
>   spi1 {
>   codec@1 {
>   compatible = "ti,tlv320aic26";
>   };
>   };
> };
> 

You target connector_1. In theory multiples of the same connector
may be available.

There are complications about how they are applied. A method that’s not
referring to a single phandle/path is going to be needed.

Thinking about it a bit more maybe we can sugar it with DTC with something like
this:

$ cat arduino_connector.dts

/dts-v1/ /plugin/ /portable/;

_connector {
spi1 {
codec@1 {
compatible = “ti,tlv320aic26”;
};
};
};

$ cat 

Re: [RFC PATCH 0/1] Portable Device Tree Connector -- conceptual

[Pantelis Antoniou]

Hi Frank,

Sorry for taking a bit to reply, had to grok it well first.

> On Jul 3, 2016, at 02:55 , frowand.l...@gmail.com wrote:
> 
> From: Frank Rowand 
> 
> Hi All,
> 
> This is version 2 of this email.
> 
> Changes from version 1:
> 
>  - some rewording of the text
>  - removed new (theoretical) dtc directive "/connector/"
>  - added compatibility between mother board and daughter board
>  - added info on applying a single .dtbo to different connectors
>  - attached an RFC patch showing the required kernel changes
>  - changes to mother board .dts connector node:
> - removed target_path property
> - added connector-socket property
>  - changes to daughter board .dts connector node:
> - added connector-plug property
> 
> 
> I've been trying to wrap my head around what Pantelis and Rob have written
> on the subject of a device tree representation of a connector for a
> daughter board to connect to (eg a cape or a shield) and the representation
> of the daughter board.  (Or any other physically pluggable object.)
> 
> After trying to make sense of what had been written (or presented via slides
> at a conference - thanks Pantelis!), I decided to go back to first principals
> of what we are trying to accomplish.  I came up with some really simple bogus
> examples to try to explain what my thought process is.
> 
> This is an extremely simple example to illustrate the concepts.  It is not
> meant to represent the complexity of a real board.
> 
> To start with, assume that the device that will eventually be on a daughter
> board is first soldered onto the mother board.  The mother board contains
> two devices connected via bus spi_1.  One device is described in the .dts
> file, the other is described in an included .dtsi file.
> Then the device tree files will look like:
> 
> $ cat board.dts
> /dts-v1/;
> 
> / {
>#address-cells = < 1 >;
>#size-cells = < 1 >;
> 
>tree_1: soc@0 {
>reg = <0x0 0x0>;
> 
>spi_1: spi1 {
>};
>};
> 
> };
> 
> _1 {
>ethernet-switch@0 {
>compatible = "micrel,ks8995m";
>};
> };
> 
> #include "spi_codec.dtsi"
> 
> 
> $ cat spi_codec.dtsi
> _1 {
>   codec@1 {
>   compatible = "ti,tlv320aic26";
>   };
> };
> 
> 
> #- codec chip on cape
> 
> Then suppose I move the codec chip to a cape.  Then I will have the same
> exact .dts and .dtsi and everything still works.
> 
> 
> @- codec chip on cape, overlay
> 
> If I want to use overlays, I only have to add the version and "/plugin/",
> then use the '-@' flag for dtc (both for the previous board.dts and
> this spi_codec_overlay.dts):
> 
> $ cat spi_codec_overlay.dts
> /dts-v1/;
> 
> /plugin/;
> 
> _1 {
>   codec@1 {
>   compatible = "ti,tlv320aic26";
>   };
> };
> 
> 
> Pantelis pointed out that the syntax has changed to be:
>   /dts-v1/ /plugin/;
> 
> 
> #- codec chip on cape, overlay, connector
> 
> Now we move into the realm of connectors.  My mental model of what the
> hardware and driver look like has not changed.  The only thing that has
> changed is that I want to be able to specify that the connector that
> the cape is plugged into has some pins that are the spi bus /soc/spi1.
> 
> The following _almost_ but not quite gets me what I want.  Note that
> the only thing the connector node does is provide some kind of
> pointer or reference to what node(s) are physically routed through
> the connector.  The connector node does not need to describe the pins;
> it only has to point to the node that describes the pins.
> 
> This example will turn out to be not sufficient.  It is a stepping
> stone in building my mental model.
> 
> $ cat board_with_connector.dts
> /dts-v1/;
> 
> / {
>   #address-cells = < 1 >;
>   #size-cells = < 1 >;
> 
>   tree_1: soc@0 {
>   reg = <0x0 0x0>;
> 
>   spi_1: spi1 {
>   };
>   };
> 
>   connector_1: connector_1 {
>   spi1 {
>   target_phandle = <_1>;
>   };
>   };
> 
> };
> 
> _1 {
>   ethernet-switch@0 {
>   compatible = "micrel,ks8995m";
>   };
> };
> 
> 
> $ cat spi_codec_overlay_with_connector.dts
> /dts-v1/;
> 
> /plugin/;
> 
> _1 {
>   spi1 {
>   codec@1 {
>   compatible = "ti,tlv320aic26";
>   };
>   };
> };
> 

You target connector_1. In theory multiples of the same connector
may be available.

There are complications about how they are applied. A method that’s not
referring to a single phandle/path is going to be needed.

Thinking about it a bit more maybe we can sugar it with DTC with something like
this:

$ cat arduino_connector.dts

/dts-v1/ /plugin/ /portable/;

_connector {
spi1 {
codec@1 {
compatible = “ti,tlv320aic26”;
};
};
};

$ cat board_with_arduino_connectors.dts
/dts-v1/;

/ {
 

Re: [RFC PATCH 0/1] Portable Device Tree Connector -- conceptual

[Frank Rowand]

On 07/04/16 08:22, Mark Brown wrote:
> On Sat, Jul 02, 2016 at 04:55:49PM -0700, frowand.l...@gmail.com wrote:
> 
>> This is an extremely simple example to illustrate the concepts.  It is not
>> meant to represent the complexity of a real board.
>>
>> To start with, assume that the device that will eventually be on a daughter
>> board is first soldered onto the mother board.  The mother board contains
>> two devices connected via bus spi_1.  One device is described in the .dts
>> file, the other is described in an included .dtsi file.
>> Then the device tree files will look like:
> 
> Can I suggest not using SPI as an example here?  It's particularly
> messy since addresses are essentially just a random signal that can be
> totally separate to the controller hardware which might be adding more
> complexity early on in building up your model than is really desirable.
> It will need to be dealt with but perhaps not right now.  I2C might be
> easier.
> 
> The initial issue with SPI is that you really need to do something like
> bring out individual slots on the bus rather than the bus as a whole
> since you're going to need a remapping layer to map chip selects on the
> module to chip selects on the host board.
> 

Yes, thank you for pointing that out.

For the purposes of the mental model, when thinking about what I wrote,
just change SPI to I2C everywhere.

-Frank

Re: [RFC PATCH 0/1] Portable Device Tree Connector -- conceptual

[Frank Rowand]

On 07/04/16 08:22, Mark Brown wrote:
> On Sat, Jul 02, 2016 at 04:55:49PM -0700, frowand.l...@gmail.com wrote:
> 
>> This is an extremely simple example to illustrate the concepts.  It is not
>> meant to represent the complexity of a real board.
>>
>> To start with, assume that the device that will eventually be on a daughter
>> board is first soldered onto the mother board.  The mother board contains
>> two devices connected via bus spi_1.  One device is described in the .dts
>> file, the other is described in an included .dtsi file.
>> Then the device tree files will look like:
> 
> Can I suggest not using SPI as an example here?  It's particularly
> messy since addresses are essentially just a random signal that can be
> totally separate to the controller hardware which might be adding more
> complexity early on in building up your model than is really desirable.
> It will need to be dealt with but perhaps not right now.  I2C might be
> easier.
> 
> The initial issue with SPI is that you really need to do something like
> bring out individual slots on the bus rather than the bus as a whole
> since you're going to need a remapping layer to map chip selects on the
> module to chip selects on the host board.
> 

Yes, thank you for pointing that out.

For the purposes of the mental model, when thinking about what I wrote,
just change SPI to I2C everywhere.

-Frank

Re: [RFC PATCH 0/1] Portable Device Tree Connector -- conceptual

[Mark Brown]

On Sat, Jul 02, 2016 at 04:55:49PM -0700, frowand.l...@gmail.com wrote:

> This is an extremely simple example to illustrate the concepts.  It is not
> meant to represent the complexity of a real board.
> 
> To start with, assume that the device that will eventually be on a daughter
> board is first soldered onto the mother board.  The mother board contains
> two devices connected via bus spi_1.  One device is described in the .dts
> file, the other is described in an included .dtsi file.
> Then the device tree files will look like:

Can I suggest not using SPI as an example here?  It's particularly
messy since addresses are essentially just a random signal that can be
totally separate to the controller hardware which might be adding more
complexity early on in building up your model than is really desirable.
It will need to be dealt with but perhaps not right now.  I2C might be
easier.

The initial issue with SPI is that you really need to do something like
bring out individual slots on the bus rather than the bus as a whole
since you're going to need a remapping layer to map chip selects on the
module to chip selects on the host board.


signature.asc
Description: PGP signature

Re: [RFC PATCH 0/1] Portable Device Tree Connector -- conceptual

[Mark Brown]

On Sat, Jul 02, 2016 at 04:55:49PM -0700, frowand.l...@gmail.com wrote:

> This is an extremely simple example to illustrate the concepts.  It is not
> meant to represent the complexity of a real board.
> 
> To start with, assume that the device that will eventually be on a daughter
> board is first soldered onto the mother board.  The mother board contains
> two devices connected via bus spi_1.  One device is described in the .dts
> file, the other is described in an included .dtsi file.
> Then the device tree files will look like:

Can I suggest not using SPI as an example here?  It's particularly
messy since addresses are essentially just a random signal that can be
totally separate to the controller hardware which might be adding more
complexity early on in building up your model than is really desirable.
It will need to be dealt with but perhaps not right now.  I2C might be
easier.

The initial issue with SPI is that you really need to do something like
bring out individual slots on the bus rather than the bus as a whole
since you're going to need a remapping layer to map chip selects on the
module to chip selects on the host board.


signature.asc
Description: PGP signature

Re: [RFC PATCH 0/1] Portable Device Tree Connector -- conceptual

[Frank Rowand]

On 07/02/16 16:55, frowand.l...@gmail.com wrote:
> From: Frank Rowand 
> 
> Hi All,
> 
> This is version 2 of this email.

< snip >

> The one remaining piece that this patch does not provide is how
> the overlay manager (which does not yet exist in the mainline
> tree) can apply an overlay to two different targets.  That
> final step should be a trivial change to of_overlay_create(),
> adding a parameter that is a mapping of the target (or maybe
> even targets) in the overlay to different targets in the
> active device tree.
> 
> This seems like a more straight forward way to handle connectors.
> 
> First, ignoring pinctrl and pinmux, what does everyone think?
> 
> Then, the next step is whether pinctrl and pinmux work with this method.
> Pantelis, can you point me to a good example for
> 
>   1) an in-tree board dts file
>   2) an overlay file (I am assuming out of tree) that applies to the board
>   3) an in-tree .dtsi file that would provide the same features as
>  the overlay file if it was included by the board dts file
> 
> It should be easier to discuss pinctrl and pinmux with an example.

And I should have added that there are other complexities beyond
pinctrl and pinmux that are not addressed.  Baby steps first,
before the whole enchilada.

-Frank

Re: [RFC PATCH 0/1] Portable Device Tree Connector -- conceptual

[Frank Rowand]

On 07/02/16 16:55, frowand.l...@gmail.com wrote:
> From: Frank Rowand 
> 
> Hi All,
> 
> This is version 2 of this email.

< snip >

> The one remaining piece that this patch does not provide is how
> the overlay manager (which does not yet exist in the mainline
> tree) can apply an overlay to two different targets.  That
> final step should be a trivial change to of_overlay_create(),
> adding a parameter that is a mapping of the target (or maybe
> even targets) in the overlay to different targets in the
> active device tree.
> 
> This seems like a more straight forward way to handle connectors.
> 
> First, ignoring pinctrl and pinmux, what does everyone think?
> 
> Then, the next step is whether pinctrl and pinmux work with this method.
> Pantelis, can you point me to a good example for
> 
>   1) an in-tree board dts file
>   2) an overlay file (I am assuming out of tree) that applies to the board
>   3) an in-tree .dtsi file that would provide the same features as
>  the overlay file if it was included by the board dts file
> 
> It should be easier to discuss pinctrl and pinmux with an example.

And I should have added that there are other complexities beyond
pinctrl and pinmux that are not addressed.  Baby steps first,
before the whole enchilada.

-Frank