[3/4] bus: Add DT bindings for 96Boards low speed connector

Message ID 20180823103332.32047-4-linus.walleij@linaro.org
State New
Headers show
Series
  • Mezzanine Low Speed connector bus
Related show

Commit Message

Linus Walleij Aug. 23, 2018, 10:33 a.m.
We need to be able to grab resources on a 96Boards low
speed connector to populate and use a daughterboard, so
define some very rudimentary properties simply passing
phandles for the resources used on the low speed
connector.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

---
 .../bus/96boards,low-speed-connector.txt      | 50 +++++++++++++++++++
 1 file changed, 50 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/bus/96boards,low-speed-connector.txt

-- 
2.17.0

Comments

Rob Herring Aug. 23, 2018, 1:45 p.m. | #1
On Thu, Aug 23, 2018 at 5:33 AM Linus Walleij <linus.walleij@linaro.org> wrote:
>

> We need to be able to grab resources on a 96Boards low

> speed connector to populate and use a daughterboard, so

> define some very rudimentary properties simply passing

> phandles for the resources used on the low speed

> connector.


This only works for describing what's on the connector, but does
nothing for describing downstream devices on the connector. We already
have a way to do the former with label properties at least for uart,
i2c and spi. And gpio has it's own method of labeling lines.

> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

> ---

>  .../bus/96boards,low-speed-connector.txt      | 50 +++++++++++++++++++

>  1 file changed, 50 insertions(+)

>  create mode 100644 Documentation/devicetree/bindings/bus/96boards,low-speed-connector.txt

>

> diff --git a/Documentation/devicetree/bindings/bus/96boards,low-speed-connector.txt b/Documentation/devicetree/bindings/bus/96boards,low-speed-connector.txt

> new file mode 100644

> index 000000000000..6631b3edd01f

> --- /dev/null

> +++ b/Documentation/devicetree/bindings/bus/96boards,low-speed-connector.txt

> @@ -0,0 +1,50 @@

> +96Boards Low Speed Connectors

> +

> +The 96Boards connectors represent a non-dicoverable Low Speed (LS)

> +and High Speed (HS) external bus on the 96Board development

> +boards. Each 96Board presents both of these connectors.

> +

> +The Low Speed (LS) connector is a 40 pin 2x20 female pin header:

> +- Power

> +- Two buttons: power and reset

> +- 2 x UART one optional with just RX/TX, one required with modem

> +  CTS/RTS

> +- 2 x I2C

> +- 1 x SPI

> +- 1 x I2S (audio)

> +- 12 x GPIO lines named GPIO-A thru GPIO-L

> +

> +Further details on the electronics and signals are available in

> +"96Boards Consumer Edition, Low Cost Hardware Platform Specification"

> +As of writing version 1.0, January 2015.

> +

> +Required properties:

> +

> +- compatible: shall be "96boards,low-speed-connector"

> +- i2c0: phandle to the I2C0 bus

> +- i2c1: phandle to the I2C1 bus

> +- spi: phandle to the SPI bus

> +- gpios: a list of phandles to the GPIOs connected to the

> +  connector. The handles need to be uniformly specified with the

> +  0 flag as the connector is not the end consumer.

> +

> +Example:

> +

> +lscon: connector {

> +       compatible = "96boards,low-speed-connector";

> +       i2c0 = <&i2csw_0>;

> +       i2c1 = <&i2csw_1>;

> +       spi = <&spi0>;


David G has suggested using aliases (in this node, not top-level) for
this purpose of mapping things like spi and i2c, and I think that's a
good use of aliases (versus spi and i2c aliases at the top level which
I don't). The hard part is still how to structure the child devices.

> +       gpios = <&gpio 36 0>, /* GPIO-A */


We defined 'gpio-map' specifically for handling GPIOs thru connectors.
It's in the DT spec (though not a released version yet). Use it here.

Sorry, but the only halfway solution I'm going to accept is one which
can evolve into a full solution. Define the basic structure and add
each interface one by one. Maybe that starts with just:

lscon: connector {
       compatible = "96boards,low-speed-connector";
};

That's not really my recommendation as that's really just kicking the
can down the road.

Rob
Linus Walleij Sept. 5, 2018, 9:05 a.m. | #2
On Thu, Aug 23, 2018 at 3:46 PM Rob Herring <robh+dt@kernel.org> wrote:
> On Thu, Aug 23, 2018 at 5:33 AM Linus Walleij <linus.walleij@linaro.org> wrote:

> >

> > We need to be able to grab resources on a 96Boards low

> > speed connector to populate and use a daughterboard, so

> > define some very rudimentary properties simply passing

> > phandles for the resources used on the low speed

> > connector.

>

> This only works for describing what's on the connector, but does

> nothing for describing downstream devices on the connector. We already

> have a way to do the former with label properties at least for uart,

> i2c and spi. And gpio has it's own method of labeling lines.


This is on purpose as the downstream daughterboards are
described by C code rather than DT. The idea is to use the same
for ACPI rather than DSDT.

> > +lscon: connector {

> > +       compatible = "96boards,low-speed-connector";

> > +       i2c0 = <&i2csw_0>;

> > +       i2c1 = <&i2csw_1>;

> > +       spi = <&spi0>;

>

> David G has suggested using aliases (in this node, not top-level) for

> this purpose of mapping things like spi and i2c, and I think that's a

> good use of aliases (versus spi and i2c aliases at the top level which

> I don't). The hard part is still how to structure the child devices.


Sorry, I am just too ignorant about the semantic difference between
a phandle and an alias. As long as I can follow it to get a handle on
the device node I'm happy, aliases are fine I guess.

The specification says:

"The phandle property specifies a numerical identifier for a node that
is unique within the devicetree. The phandle property value is used by
other nodes that need to refer to the node associated with the
property."

Numerical? Hm.

The aliases are very vague and seem to not be really specified.
Not in the DT spec at least. And that is not in line with how the
Linux kernel DTs uses aliases anyway, it seems.

Syntactically they look like so:

aliases {
        serial0 = &uart1;
};

phandles {
        serial0 = <&uart1>;
};

Not a big difference.

In your opinion, what constitues the semantic meaning of an alias
vs a phandle?

> > +       gpios = <&gpio 36 0>, /* GPIO-A */

>

> We defined 'gpio-map' specifically for handling GPIOs thru connectors.

> It's in the DT spec (though not a released version yet). Use it here.


We have code for it (by Stephen Boyd) which works and I tested
it even, it works fine!

But it is not intended for what I do here. It shares the ambition to
define all devices in the daughterboard using DT, so there must
be a consuming node, on the daughterboard, using
my-gpios = <&connector 0>; and we are back
at overlays. There is no way for a connector driver to
grab a GPIO from the GPIO map, the map is just a
cross-reference, not resource provider.

Maybe I could let the connector say that it's using
GPIOs from itself? I can take a stab at that. It will look weird
but it's allright I guess.

> Sorry, but the only halfway solution

> I'm going to accept is one which

> can evolve into a full solution. Define the basic structure and add

> each interface one by one.

>

> Maybe that starts with just:

>

> lscon: connector {

>        compatible = "96boards,low-speed-connector";

> };


I suspect "full solution" in the above paragraph means full
DT overlays, and ACPI systems are none of your concern
in this context?

A halfway solution is what I am trying to do, because the
walking all the way down the road means we run into the
imperialistic ambitions of both DT and ACPI DSDT to describe
the whole system using just DT or just ACPI DSDT.

As mentioned, we have today the developer box that is
using ACPI, and the other 96Boards using mostly DT.

Which currently means similar support code twice
for these (simple) mezzanines, then author and support
overlays in both HW description languages.

Like with the fwnode rework that is going on in parallel, in
my view it is really necessary for both DT and ACPI to take
a step back and stop being so imperialistic. It seems they
are both living under the assumption that they do not really
need to care about the other HW description language, and
it is stifling development. Maybe this view is too harsh, I am
sometimes also just thinking inside my little box :(

My current plan is to develop the code in the patch set using
fwnode where possible so that I have a proof of concept of
the same mezzanine population code being used for DT and
ACPI alike. It works for GPIOs, but phandles or aliases are
going to be a challenge.

Yours,
Linus Walleij

Patch

diff --git a/Documentation/devicetree/bindings/bus/96boards,low-speed-connector.txt b/Documentation/devicetree/bindings/bus/96boards,low-speed-connector.txt
new file mode 100644
index 000000000000..6631b3edd01f
--- /dev/null
+++ b/Documentation/devicetree/bindings/bus/96boards,low-speed-connector.txt
@@ -0,0 +1,50 @@ 
+96Boards Low Speed Connectors
+
+The 96Boards connectors represent a non-dicoverable Low Speed (LS)
+and High Speed (HS) external bus on the 96Board development
+boards. Each 96Board presents both of these connectors.
+
+The Low Speed (LS) connector is a 40 pin 2x20 female pin header:
+- Power
+- Two buttons: power and reset
+- 2 x UART one optional with just RX/TX, one required with modem
+  CTS/RTS
+- 2 x I2C
+- 1 x SPI
+- 1 x I2S (audio)
+- 12 x GPIO lines named GPIO-A thru GPIO-L
+
+Further details on the electronics and signals are available in
+"96Boards Consumer Edition, Low Cost Hardware Platform Specification"
+As of writing version 1.0, January 2015.
+
+Required properties:
+
+- compatible: shall be "96boards,low-speed-connector"
+- i2c0: phandle to the I2C0 bus
+- i2c1: phandle to the I2C1 bus
+- spi: phandle to the SPI bus
+- gpios: a list of phandles to the GPIOs connected to the
+  connector. The handles need to be uniformly specified with the
+  0 flag as the connector is not the end consumer.
+
+Example:
+
+lscon: connector {
+	compatible = "96boards,low-speed-connector";
+	i2c0 = <&i2csw_0>;
+	i2c1 = <&i2csw_1>;
+	spi = <&spi0>;
+	gpios = <&gpio 36 0>, /* GPIO-A */
+	        <&gpio 37 0>, /* GPIO-B */
+		<&gpio 39 0>, /* GPIO-C */
+		<&gpio 40 0>, /* GPIO-D */
+		<&gpio 44 0>, /* GPIO-E */
+		<&gpio 45 0>, /* GPIO-F */
+		<&gpio 78 0>, /* GPIO-G */
+		<&gpio 79 0>, /* GPIO-H */
+		<&gpio 80 0>, /* GPIO-I */
+		<&gpio 81 0>, /* GPIO-J */
+		<&gpio 82 0>, /* GPIO-K */
+		<&gpio 83 0>; /* GPIO-L */
+};