From: Rob Herring <robh@xxxxxxxxxx> Sent: Monday, February 24, 2025 9:44 PM >On Mon, Feb 24, 2025 at 02:50:55PM +0100, Maud Spierings wrote: >> The main point of the Moduline series of embedded controllers is its >> ecosystem of IO modules, these currently are operated through the spidev >> interface. Ideally there will be a full dedicated driver in the future. >> >> Add the gocontroll moduline-module-slot device to enable the required >> spidev interface. >> >> Signed-off-by: Maud Spierings <maudspierings@xxxxxxxxxxxxxx> >> --- >> Documentation/devicetree/bindings/trivial-devices.yaml | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/Documentation/devicetree/bindings/trivial-devices.yaml b/Documentation/devicetree/bindings/trivial-devices.yaml >> index 8255bb590c0cc619d15b27dcbfd3aa85389c0a54..24ba810f91b73efdc615c7fb46f771a300926f05 100644 >> --- a/Documentation/devicetree/bindings/trivial-devices.yaml >> +++ b/Documentation/devicetree/bindings/trivial-devices.yaml >> @@ -107,6 +107,8 @@ properties: >> - fsl,mpl3115 >> # MPR121: Proximity Capacitive Touch Sensor Controller >> - fsl,mpr121 >> + # GOcontroll Moduline module slot for spi based IO modules > >I couldn't find anything about SPI for GOcontroll Moduline. Can you >point me to what this hardware looks like. Based on what I did find, >this seems incomplete and not likely a trivial device. I'll give some more details, if there is a v2 of this patch I will also add more information in the commit message. The module slots have a number of pins, a lot of them currently unused as they have not found a function yet, this is very much still a developing product. The currently used interfaces to the SoC are: 1. SPI bus as a spidev to ease developing new modules and quickly integrate them. This is the main communication interface for control and firmware updates. 2. A reset pin, this is/was driven with the gpio-led driver but I doubt that would get accepted upstream so I intend to switch to the much better suited libgpio. 3. An interrupt pin, this is currently only used in the firmware update utility [2] to speed up the update process. Other communication is done at a regular interval. What is unused: 1. A potentially multi-master i2c bus between all the module slots and the SoC 2. An SMBus alert line is shared between the modules, but not the SoC. 3. A shared line designated as a clock line, intended to in the future aid with synchronizing modules to each other for time critical control. current software that is used to work with the modules can be found at [2] and [3], one of them is a Node-RED module the other is a blockset for Matlab/Simulink generated code. If you know a better way I could describe this in the devicetree then I would love to know, I am always keen on learning more. As I said in the commit message it would be nice to have an in kernel driver that would do all the interrupt handling, firmware updating, probing but that is sadly not in our capabilties right now. We are hoping to eventually make this interface an open standard that other people can integrate into their PCB's to make use of the various IO modules. I have personally made a raspberry pi hat that can take 2 modules for example, which I hope will in the future serve as an open source reference design. It is not open right now though. [1]: https://github.com/GOcontroll/go-modules [2]: https://github.com/GOcontroll/node-red-gocontroll/tree/master/nodes/modules [3]: https://github.com/GOcontroll/GOcontroll-Simulink/tree/2023b/blockset/code >> + - gocontroll,moduline-module-slot >> # Honeywell Humidicon HIH-6130 humidity/temperature sensor >> - honeywell,hi6130 >> # IBM Common Form Factor Power Supply Versions (all versions) >> >> -- >> 2.48.1 >> Kind regards, Maud
