Re: [PATCH v2 03/12] dt-bindings: connector: Add the GOcontroll Moduline module slot bindings

[Maud Spierings | GOcontroll]

From: Rob Herring <robh@xxxxxxxxxx>
Sent: Tuesday, March 18, 2025 4:37 PM
 
>On Mon, Mar 17, 2025 at 5:42 AM Maud Spierings | GOcontroll
><maudspierings@xxxxxxxxxxxxxx> wrote:
>>
>> From: Krzysztof Kozlowski <krzk@xxxxxxxxxx>
>> Sent: Monday, March 17, 2025 11:34 AM
>>
>> >On Sat, Mar 15, 2025 at 07:32:28AM +0000, Maud Spierings | GOcontroll wrote:
>> >> >> +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
>> >
>> >But which buses...
>>
>> I don't think I am fully understanding what you are asking of me. The
>> module will always be an spi device, that is the main communication bus.
>
>Okay, that clears up whether it should be a SPI device or not, and I
>think it should as SPI is always used. The 2nd question is what does
>"gocontroll,moduline-module-slot" mean exactly. Normally, the
>compatible implies how you interact with the device (or what is the
>programming model). For SPI, that's what do the SPI transactions look
>like to begin with. Does the slot spec define that such that every
>module is the same? Then when it comes to different module types, are
>those discoverable (e.g. PCI has vendor and device ID) or will you
>need "compatible" to make that distinction?

The slot spec defines the physical interface, what pins etc and the
interaction with the bootloader. From the module bootloader it can
retrieve the module hardware identifier. This is a group of 4 bytes:
1. The standard version (currently and for the foreseable future 20)
2. Category currently these exist:
    10: Input
    20: Output
    30: Communication
    40: Multi function
3. A specific module identifier in this category
4. The module hw version

So a common module is 20-10-1-6, which is the 6 Channel Input module
version 6. It was the first input module type so it is number 1.

After this follow 3 bytes for the firmware revision which is a standard
semantic scheme of major.feature.fix.

The actual communication with the firmware is not standardized. Each
module has its own needs when it comes to that. This will be handled in a
userspace program. Our communication library is open source and can be
adapted to any shape a user wishes.

So there is no seperate compatible needed for each module, this would make
swapping modules dramatically more involved and hurt our ease of use.

I am not quite sure yet if the firmware update part will be moved into the
kernel driver as that is a stable part that can easily be there.

So the "slot" will mostly just interact with the module bootloader and set
the module up for userspace use.

kind regards,
Maud