spi enumeration process

spi enumeration process

[Henk Medenblik]

Hi all,

I am using a custom SPI controller which I created in my Xilinx MPSoC 
fpga part. On this custom spi controller bus I have one or more SPI 
devices (in my case a custom LTC6951 driver) connected in the devicetree 
under my spi controller.
Because the controller is custom, I wrote the SPI controller driver and 
also some slave device drivers which seem to work.
These drivers are both created as out of tree loadable modules.

My issue is that at boot of my SocFPGA I can see that my SPI controller 
driver is correctly loaded during the boot process but the spi slave 
driver which is connected to my controller does not get automatically 
loaded.
Therefore, I manually need to do a modprobe ltc6951.ko in my case before 
the LTC6951 slave in my case is up and running.

So, it seems like if I do not really understand the spi  slaves 
enumeration process or there is something else that I am missing here. I 
was under the assumption that the slaves automatically get enumerated 
(they are put as slaves under my controller inside the device tree) 
whenever it's master controller becomes alive.

Can anybody clarify this issue for me?

Tnx,

Henk

Re: spi enumeration process

[Lars-Peter Clausen]

On 10/22/21 9:55 AM, Henk Medenblik wrote:
> Hi all,
>
> I am using a custom SPI controller which I created in my Xilinx MPSoC 
> fpga part. On this custom spi controller bus I have one or more SPI 
> devices (in my case a custom LTC6951 driver) connected in the 
> devicetree under my spi controller.
> Because the controller is custom, I wrote the SPI controller driver 
> and also some slave device drivers which seem to work.
> These drivers are both created as out of tree loadable modules.
>
> My issue is that at boot of my SocFPGA I can see that my SPI 
> controller driver is correctly loaded during the boot process but the 
> spi slave driver which is connected to my controller does not get 
> automatically loaded.
> Therefore, I manually need to do a modprobe ltc6951.ko in my case 
> before the LTC6951 slave in my case is up and running.
>
> So, it seems like if I do not really understand the spi  slaves 
> enumeration process or there is something else that I am missing here. 
> I was under the assumption that the slaves automatically get 
> enumerated (they are put as slaves under my controller inside the 
> device tree) whenever it's master controller becomes alive. 

Hi,

Modules are loaded by userspace, e.g. udev. It does so based on hints 
that are embedded in the module, these are called MODALIASs. When udev 
sees a device without a driver it will check all the modules to see if 
they have a matching modalias for the driver and then load the module.

In your driver you define the modalias usually using 
MODULE_DEVICE_TABLE(type, table). E.g. for a SPI driver the type would 
be spi and will take a reference to the spi_device_id table for your 
driver. In addition if you are using devicetree you do the same for the 
of_device_id table with `of` as the type.

- Lars

Re: spi enumeration process

[Henk Medenblik]

Hi Lars,

I don't think that the issue is here the two MODULE_DEVICE_TABLE 
modaliases in my ltc6951 driver. I have them both for the spi_device_id 
and also the of_device_id defined.
And I believe that if any of them would be missing, then manual modprobe 
of the ltc6951 driver would fail too.

The issue is that it does not get automatically enumerated when my 
custom spi controller get loaded (i can see after boot that the spi 
controller is alive when looking into /proc/modules)

However, the spi slave device is not alive. The strange thing is that 
this does work if I connect the spi slave to the onboard SPI controller 
which resides inside the Zynq MPSoC.. (after putting the ltc slave in 
the tree under that controller)

Regards

Henk


On 10/22/21 10:25 AM, Lars-Peter Clausen wrote:
> On 10/22/21 9:55 AM, Henk Medenblik wrote:
>> Hi all,
>>
>> I am using a custom SPI controller which I created in my Xilinx MPSoC 
>> fpga part. On this custom spi controller bus I have one or more SPI 
>> devices (in my case a custom LTC6951 driver) connected in the 
>> devicetree under my spi controller.
>> Because the controller is custom, I wrote the SPI controller driver 
>> and also some slave device drivers which seem to work.
>> These drivers are both created as out of tree loadable modules.
>>
>> My issue is that at boot of my SocFPGA I can see that my SPI 
>> controller driver is correctly loaded during the boot process but the 
>> spi slave driver which is connected to my controller does not get 
>> automatically loaded.
>> Therefore, I manually need to do a modprobe ltc6951.ko in my case 
>> before the LTC6951 slave in my case is up and running.
>>
>> So, it seems like if I do not really understand the spi  slaves 
>> enumeration process or there is something else that I am missing 
>> here. I was under the assumption that the slaves automatically get 
>> enumerated (they are put as slaves under my controller inside the 
>> device tree) whenever it's master controller becomes alive. 
>
> Hi,
>
> Modules are loaded by userspace, e.g. udev. It does so based on hints 
> that are embedded in the module, these are called MODALIASs. When udev 
> sees a device without a driver it will check all the modules to see if 
> they have a matching modalias for the driver and then load the module.
>
> In your driver you define the modalias usually using 
> MODULE_DEVICE_TABLE(type, table). E.g. for a SPI driver the type would 
> be spi and will take a reference to the spi_device_id table for your 
> driver. In addition if you are using devicetree you do the same for 
> the of_device_id table with `of` as the type.
>
> - Lars
>

Re: spi enumeration process

[Lars-Peter Clausen]

On 10/22/21 10:40 AM, Henk Medenblik wrote:
> Hi Lars,
>
> I don't think that the issue is here the two MODULE_DEVICE_TABLE 
> modaliases in my ltc6951 driver. I have them both for the 
> spi_device_id and also the of_device_id defined.
> And I believe that if any of them would be missing, then manual 
> modprobe of the ltc6951 driver would fail too.

The table itself is used for the probing process. But the 
MODULE_DEVICE_TABLE is only used to signal userspace that this module 
handles the devices that are listed in the table. udev uses this 
information to load the driver if necessary.

Manual loading will still work without the MODULE_DEVICE_TABLE. But of 
course not without the table itself.

>
> The issue is that it does not get automatically enumerated when my 
> custom spi controller get loaded (i can see after boot that the spi 
> controller is alive when looking into /proc/modules)
>
> However, the spi slave device is not alive. The strange thing is that 
> this does work if I connect the spi slave to the onboard SPI 
> controller which resides inside the Zynq MPSoC.. (after putting the 
> ltc slave in the tree under that controller)

Ok, that's a bit odd that it works with the MPSoC controller. What I'd 
do is check `/sys/bus/spi/devices/`. Your device will be there even if 
driver has not been loaded. And then check the `modalias` and `uevent` 
files of the device. Check if those files look different when using your 
controller vs. the MPSoC.

- Lars

>
> Regards
>
> Henk
>
>
> On 10/22/21 10:25 AM, Lars-Peter Clausen wrote:
>> On 10/22/21 9:55 AM, Henk Medenblik wrote:
>>> Hi all,
>>>
>>> I am using a custom SPI controller which I created in my Xilinx 
>>> MPSoC fpga part. On this custom spi controller bus I have one or 
>>> more SPI devices (in my case a custom LTC6951 driver) connected in 
>>> the devicetree under my spi controller.
>>> Because the controller is custom, I wrote the SPI controller driver 
>>> and also some slave device drivers which seem to work.
>>> These drivers are both created as out of tree loadable modules.
>>>
>>> My issue is that at boot of my SocFPGA I can see that my SPI 
>>> controller driver is correctly loaded during the boot process but 
>>> the spi slave driver which is connected to my controller does not 
>>> get automatically loaded.
>>> Therefore, I manually need to do a modprobe ltc6951.ko in my case 
>>> before the LTC6951 slave in my case is up and running.
>>>
>>> So, it seems like if I do not really understand the spi slaves 
>>> enumeration process or there is something else that I am missing 
>>> here. I was under the assumption that the slaves automatically get 
>>> enumerated (they are put as slaves under my controller inside the 
>>> device tree) whenever it's master controller becomes alive. 
>>
>> Hi,
>>
>> Modules are loaded by userspace, e.g. udev. It does so based on hints 
>> that are embedded in the module, these are called MODALIASs. When 
>> udev sees a device without a driver it will check all the modules to 
>> see if they have a matching modalias for the driver and then load the 
>> module.
>>
>> In your driver you define the modalias usually using 
>> MODULE_DEVICE_TABLE(type, table). E.g. for a SPI driver the type 
>> would be spi and will take a reference to the spi_device_id table for 
>> your driver. In addition if you are using devicetree you do the same 
>> for the of_device_id table with `of` as the type.
>>
>> - Lars
>>

Re: spi enumeration process

[Henk Medenblik]

Hi Lars,

On 10/22/21 11:06 AM, Lars-Peter Clausen wrote:
>
> Ok, that's a bit odd that it works with the MPSoC controller. What I'd 
> do is check `/sys/bus/spi/devices/`. Your device will be there even if 
> driver has not been loaded. And then check the `modalias` and `uevent` 
> files of the device. Check if those files look different when using 
> your controller vs. the MPSoC.
>
I checked these files after my system boot and with my custom controller:

root@star-module:/sys/bus/spi/devices/spi1.0# cat modalias
spi:ltc6951

root@star-module:/sys/bus/spi/devices/spi1.0# cat uevent
OF_NAME=ltc6951
OF_FULLNAME=/amba_pl@0/spi_ctrl@80020000/ltc6951@0
OF_COMPATIBLE_0=adi,ltc6951
OF_COMPATIBLE_N=1
MODALIAS=spi:ltc6951

Then have to do a manual modprobe of my ltc6951:

root@star-module:/sys/bus/spi/drivers# modprobe ltc6951
[  643.347655] probe ltc6951 driver ok

and after that one it finally pops up here:

root@star-module:/sys/bus/spi/drivers/ltc6951# ls
bind  module  spi1.0  uevent  unbind

and also shows up here:

root@star-module:/sys/bus/spi/drivers# ls
at25  ltc6951  max310x  mtd_dataflash  spi-nor  wl1271_spi

and pops up as an iio device:

root@star-module:/sys/bus/spi/devices/spi1.0# ls
driver           iio:device1  of_node  statistics  uevent
driver_override  modalias     power    subsystem


So I believe it isn't an issue with MODALIASs right? I still wonder if 
it has to do with the fact that both drivers are out of tree modules and 
not compiled in my linux kernel ?
That is not the case with the default Zynq MPSoc Cadence controller 
because that driver is compiled statically in the kernel.

Regards

Henk

Re: spi enumeration process

[Henk Medenblik]

Update,

I have been messing around with driver moving, deleting and falling back 
to the ZynqMP default cadence controller which seemed to have the same 
issue now...(no ltc6951 probing).
Then after some while with same process of moving, running depmod and 
moving driver files back into /lib/modules/5.4.0-xilinx-v2020.2 again I 
managed to get the proper probing of both the custom spi controller and 
the ltc6951 driver.

However.. what might have happening and what the cause for is for having 
it running correctly now is unclear to me.

Does the order of alias'es which pop up in modules.alias could have 
effect? With the current running system I can see now that the ltc6951 
ltc6951 alias is in front of my spi-ctrl . Unfortunately I did not check 
that order when I had the issues...

Regards

Henk


On 10/22/21 11:06 AM, Lars-Peter Clausen wrote:
> On 10/22/21 10:40 AM, Henk Medenblik wrote:
>> Hi Lars,
>>
>> I don't think that the issue is here the two MODULE_DEVICE_TABLE 
>> modaliases in my ltc6951 driver. I have them both for the 
>> spi_device_id and also the of_device_id defined.
>> And I believe that if any of them would be missing, then manual 
>> modprobe of the ltc6951 driver would fail too.
>
> The table itself is used for the probing process. But the 
> MODULE_DEVICE_TABLE is only used to signal userspace that this module 
> handles the devices that are listed in the table. udev uses this 
> information to load the driver if necessary.
>
> Manual loading will still work without the MODULE_DEVICE_TABLE. But of 
> course not without the table itself.
>
>>
>> The issue is that it does not get automatically enumerated when my 
>> custom spi controller get loaded (i can see after boot that the spi 
>> controller is alive when looking into /proc/modules)
>>
>> However, the spi slave device is not alive. The strange thing is that 
>> this does work if I connect the spi slave to the onboard SPI 
>> controller which resides inside the Zynq MPSoC.. (after putting the 
>> ltc slave in the tree under that controller)
>
> Ok, that's a bit odd that it works with the MPSoC controller. What I'd 
> do is check `/sys/bus/spi/devices/`. Your device will be there even if 
> driver has not been loaded. And then check the `modalias` and `uevent` 
> files of the device. Check if those files look different when using 
> your controller vs. the MPSoC.
>
> - Lars
>
>>
>> Regards
>>
>> Henk
>>
>>
>> On 10/22/21 10:25 AM, Lars-Peter Clausen wrote:
>>> On 10/22/21 9:55 AM, Henk Medenblik wrote:
>>>> Hi all,
>>>>
>>>> I am using a custom SPI controller which I created in my Xilinx 
>>>> MPSoC fpga part. On this custom spi controller bus I have one or 
>>>> more SPI devices (in my case a custom LTC6951 driver) connected in 
>>>> the devicetree under my spi controller.
>>>> Because the controller is custom, I wrote the SPI controller driver 
>>>> and also some slave device drivers which seem to work.
>>>> These drivers are both created as out of tree loadable modules.
>>>>
>>>> My issue is that at boot of my SocFPGA I can see that my SPI 
>>>> controller driver is correctly loaded during the boot process but 
>>>> the spi slave driver which is connected to my controller does not 
>>>> get automatically loaded.
>>>> Therefore, I manually need to do a modprobe ltc6951.ko in my case 
>>>> before the LTC6951 slave in my case is up and running.
>>>>
>>>> So, it seems like if I do not really understand the spi slaves 
>>>> enumeration process or there is something else that I am missing 
>>>> here. I was under the assumption that the slaves automatically get 
>>>> enumerated (they are put as slaves under my controller inside the 
>>>> device tree) whenever it's master controller becomes alive. 
>>>
>>> Hi,
>>>
>>> Modules are loaded by userspace, e.g. udev. It does so based on 
>>> hints that are embedded in the module, these are called MODALIASs. 
>>> When udev sees a device without a driver it will check all the 
>>> modules to see if they have a matching modalias for the driver and 
>>> then load the module.
>>>
>>> In your driver you define the modalias usually using 
>>> MODULE_DEVICE_TABLE(type, table). E.g. for a SPI driver the type 
>>> would be spi and will take a reference to the spi_device_id table 
>>> for your driver. In addition if you are using devicetree you do the 
>>> same for the of_device_id table with `of` as the type.
>>>
>>> - Lars
>>>
>

spi enumeration process

[Henk Medenblik]

Hi all,

I am using a custom SPI controller which I created in my Xilinx MPSoC 
fpga part. On this custom spi controller bus I have one or more SPI 
devices (in my case a custom LTC6951 driver) connected in the devicetree 
under my spi controller.
Because the controller is custom, I wrote the SPI controller driver and 
also some slave device drivers which seem to work.
These drivers are both created as out of tree loadable modules.

My issue is that at boot of my SocFPGA I can see that my SPI controller 
driver is correctly loaded during the boot process but the spi slave 
driver which is connected to my controller does not get automatically 
loaded.
Therefore, I manually need to do a modprobe ltc6951.ko in my case before 
the LTC6951 slave in my case is up and running.

So, it seems like if I do not really understand the spi  slaves 
enumeration process or there is something else that I am missing here. I 
was under the assumption that the slaves automatically get enumerated 
(they are put as slaves under my controller inside the device tree) 
whenever it's master controller becomes alive.

Can anybody clarify this issue for me?

Tnx,

Henk