Message-ID:
 <ac1ccbbe6a4048a79210c6676a8aa691PA4PR04MB7630094413C8E1F3D715EE23C5DD2@PA4PR04MB7630.eurprd04.prod.outlook.com>
Date: Sat, 15 Mar 2025 07:33:47 +0000
From: Maud Spierings | GOcontroll <maudspierings@...ontroll.com>
To: Rob Herring <robh@...nel.org>
CC: Neil Armstrong <neil.armstrong@...aro.org>, Jessica Zhang
	<quic_jesszhan@...cinc.com>, Maarten Lankhorst
	<maarten.lankhorst@...ux.intel.com>, Maxime Ripard <mripard@...nel.org>,
	Thomas Zimmermann <tzimmermann@...e.de>, David Airlie <airlied@...il.com>,
	Simona Vetter <simona@...ll.ch>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>, Thierry Reding
	<thierry.reding@...il.com>, Sam Ravnborg <sam@...nborg.org>, Liu Ying
	<victor.liu@....com>, Shawn Guo <shawnguo@...nel.org>, Sascha Hauer
	<s.hauer@...gutronix.de>, Pengutronix Kernel Team <kernel@...gutronix.de>,
	Fabio Estevam <festevam@...il.com>, Mark Brown <broonie@...nel.org>,
	"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"imx@...ts.linux.dev" <imx@...ts.linux.dev>,
	"linux-arm-kernel@...ts.infradead.org"
	<linux-arm-kernel@...ts.infradead.org>, "linux-spi@...r.kernel.org"
	<linux-spi@...r.kernel.org>
Subject: Re: [PATCH v2 03/12] dt-bindings: connector: Add the GOcontroll
 Moduline module slot bindings

From: Rob Herring <robh@...nel.org>
Sent: Friday, March 14, 2025 10:06 PM
 
>On Wed, Feb 26, 2025 at 03:19:14PM +0100, Maud Spierings wrote:
>> Add the bindings that describe a GOcontroll Moduline module slot. This
>> slot provides all the interfaces to interface with a Moduline compatible
>> IO module. The actual module is not reasonable to describe as it can be
>> swapped at will, with this connector the driver will be able to probe
>> for a module on boot.
>>
>> The connector consists of 2 parts, one part for interfacing with the SoC
>> and main board, the other part has 13 IO channels for the module to
>> interact with the outside world. The functions of these IO channels are
>> determined by the type of module in the slot. The IO on the SoC side is
>> as follows:
>>
>>  - a 3v3 supply, this tends to be the logic level of the module and its
>>    microcontroller
>>  - a 5v0 supply, this can be used to power low power peripherals on the
>>    module
>>  - a 6v-8v supply, this can be used for high power peripherals on the
>>    module
>>  - a 6v-30v supply, this tends to be a dirty supply that comes from the
>>    controller supply after some circuit protection, or is the same as
>>    the 6v-8v supply.
>>  - an SPI bus which carries the communication between the SoC and the
>>    microcontroller on the module.
>>  - an I2C bus shared between the SoC and all module slots which can
>>    carry direct module-to-module communication.
>>  - a reset line
>>  - an interrupt line that indicates a clear to transmit signal
>>  - a sync line shared between the SoC and all module slots which could
>>    be used to synchronize modules for time sensitive IO spread across
>>    modules.
>>  - a SMBus alert line that is shared between the modules but is not
>>    connected to the SoC so that is ignored.
>>
>> A slot-number property is used to identify the physical location of a
>> module slot. Without it, it would be impossible to identify which module
>> to control if there are multiple of one type, to address the desired IO.
>
>Is that for a person to identify slots or s/w? If just a person, we
>generally use 'label' as in a sticker on the connector. If s/w, we
>generally try to avoid made up indexing in DT though there are some
>exceptions.

I guess both, I am not quite sure how the uapi will look like eventually.
Right now we just kind of know that spidev1.0 is slot 1 etc.

Maybe label: true could be enough but that seems to generic, it allows too
much wiggle room, if there is an eventual library that uses the kernel
uapi instead of the spidev interface it must be consistent. Or can the
label be restricted to being "moduleslot#"? I feel that numbers best
represent the way we lay out these module slots, and will provide the best
interface.

>> Signed-off-by: Maud Spierings <maudspierings@...ontroll.com>
>> ---
>>  .../connector/gocontroll,moduline-module-slot.yaml | 88 ++++++++++++++++++++++
>>  1 file changed, 88 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/connector/gocontroll,moduline-module-slot.yaml b/Documentation/devicetree/bindings/connector/gocontroll,moduline-module-slot.yaml
>> new file mode 100644
>> index 0000000000000000000000000000000000000000..a16ae2762d160180d5b163e20f5294235e65053b
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/connector/gocontroll,moduline-module-slot.yaml
>> @@ -0,0 +1,88 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/connector/gocontroll,moduline-module-slot.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: GOcontroll Moduline Module slot
>> +
>> +maintainers:
>> +  - Maud Spierings <maudspierings@...ontroll.com>
>> +
>> +description:
>> +  The GOcontroll Moduline module slot represents a connector that fullfills the
>> +  Moduline slot specification, and can thus house any IO module that is also
>> +  built to this spec.
>> +
>> +properties:
>> +  compatible:
>> +    const: gocontroll,moduline-module-slot
>> +
>> +  reg:
>> +    maxItems: 1
>> +
>> +  interrupts:
>> +    description: indicates readiness, high means busy.
>> +    maxItems: 1
>> +  reset-gpios:
>> +    description: resets the module, active low.
>> +    maxItems: 1
>> +  sync-gpios:
>> +    description: sync line between all module slots.
>> +    maxItems: 1
>> +
>> +  vdd-supply:
>> +    description: low power 3v3 supply generally for the microcontroller.
>> +  vddp-supply:
>> +    description: medium power 5v0 supply for on module low power peripherals.
>> +  vddhpp-supply:
>> +    description: high power 6v-8v supply for on module high power peripherals.
>> +  power-supply:
>> +    description: high power 6v-30v supply for high power module circuits.
>> +
>> +  i2c-bus:
>> +    description: i2c bus shared between module slots and the SoC
>> +    $ref: /schemas/types.yaml#/definitions/phandle
>> +
>> +  slot-number:
>> +    description:
>> +      The number of the module slot representing the location of on the pcb.
>> +      This enables access to the modules based on slot location.
>> +    $ref: /schemas/types.yaml#/definitions/uint32
>> +
>> +  spi-max-frequency: true
>> +
>> +required:
>> +  - compatible
>> +  - reg
>> +  - reset-gpios
>> +  - interrupts
>> +  - sync-gpios
>> +  - i2c-bus
>> +  - slot-number
>> +
>> +additionalProperties: false
>> +
>> +examples:
>> +  - |
>> +    #include <dt-bindings/gpio/gpio.h>
>> +    #include <dt-bindings/interrupt-controller/irq.h>
>> +
>> +    spi {
>> +        #address-cells = <1>;
>> +        #size-cells = <0>;
>> +
>> +        connector@0 {
>
>I find this being a SPI device a bit strange. Is there a defined SPI
>device that every slot is going to have? Or the connector has SPI
>interface and *anything* could be attached on it?

So a module slot is like a pcie slot, it can be occupied or not, and when
it is occupied it can be any kind of module, but it can at least only be
one module, there is no hub like functionality.

On this module is a microcontroller or perhaps even an FPGA in the future
which is the spi-device, it has the miso, mosi, sclk and cs hooked up to
it.

For now this tends to be some kind of stm32f4xx, but it is very much not
set in stone. The only thing sure is there is some kind of module
controller that is hooked up to the spi device when a module is present.

So I would say it is option 2 of what you ask. But the 'anything' is
restricted to module compatible with the standard, its not just going to 
be some IC like an ADC chip like the mcp3004 that we use on the mainboard.

>> +            reg = <0>;
>> +            compatible = "gocontroll,moduline-module-slot";
>> +            reset-gpios = <&gpio5 10 GPIO_ACTIVE_LOW>;
>> +            sync-gpios = <&gpio4 16 GPIO_ACTIVE_HIGH>;
>> +            interrupt-parent = <&gpio4>;
>> +            interrupts = <5 IRQ_TYPE_EDGE_FALLING>;
>> +            vdd-supply = <&reg_3v3_per>;
>> +            vddp-supply = <&reg_5v0>;
>> +            vddhpp-supply = <&reg_6v4>;
>> +            i2c-bus = <&i2c2>;
>> +            slot-number = <1>;
>> +        };
>> +    };
>>
>> --
>> 2.48.1
>>

I hope this cleared everything up and the bindings are still okay

Kind Regards,
Maud

Powered by blists - more mailing lists