We got an SPI device connected at the SPI interface, and we need to load the kernel module for the spi_device driver manually because we need to use the pins as gpios before.
Currently we were loading the kernel modules spi_controller and spi_device with the insmod command. Thats works pretty well, but now we need to define a delay between issuing the CS and starting the clock.
Usually I can set the parameters for the kernel module by just appending them to the insmod command:
insmod <param1=value2> <param2=value2>
But this doesn’t work in this case. I can see in the kernel outputs that both modules don’t accept the parameter.
Can someone give a hint how to set this parameter per insmod as argument?
I found a workarround by adding a new parameter to spi_device kernel module and passing this per ‘struct spi_device.controller_data’ per ‘spi_setup()’ to the spi-fsl-dspi kernel module. But that feels somehow wrong and would also only work with the tweaked fsl-dspi driver.
To be more clear about my actual problem:
The parameter I need to set is specified in the device tree on the spi device node, not on the spi controller node.
And now I’m looking for a way to achieve the same by passing the parameter to insmod or modprobe.
I tried different options of passing this parameter:
modprobe <spi_device> spi_fsl_dspi.fsl,spi-cs-sck-delay=120
modprobe <spi_device> fsl,spi-cs-sck-delay=120
modprobe spi_fsl_dspi modprobe <spi_device> spi_fsl_dspi.fsl,spi-cs-sck-delay=120
modprobe spi_fsl_dspi modprobe <spi_device> fsl,spi-cs-sck-delay=120
but all this attempts lead to the same kernel output, that the parameter is not supported.
The only thing that has worked was extending the spi_device device with an addtional parameter and passing this option to the spi_controller on the spi_device structure in the controller_data field.
Then I extended the spi_fsl_dspi kernel module in the dspi_setup() methode to query if the controller_data field is set and use the value defined here, instead of the parameter from the device tree.
But thats directly couples the spi_device driver to spi controller driver, which I don’t like, because if ever switch to another device, the spi_controller driver of that new device also needs to be extended.
You are right. Some kernel modules implement/support this kind of command line argument passing. But be aware that not all kernel modules implement/support this, as it is not a required/mandatory behavior.
In these attempts, you tried to use device tree parameters as command line parameters and (usually) it is not possible. If you want to use those parameters, you must do so in the device tree. And, reinforcing, refer to the suitable branch of the linux-toradex repository.
Thanks for the explanation. And please excuse the long delay until i answered.
I am familiar with the syntax of module_param macro.
Like stated above sticking to the device tree was not an option for our problem.
I stayed on my own solution.
Extending our spi-device (in linux kernel terms Protocol Driver), with an module_param.
The value of this module_param is transfered to the spi-fsl-dspi (Linux Term: Controller Driver) using the struct spi_device.controller_data field. Which I assume is thought for passing information to the controller driver.
This value is now read in a tweaked version of the spi-fsl-dspi driver. And handled in the same way as the 'fsl,spi-cs-sck-delay module_param is handled.
