Will building ad9361 driver as a kernel module ever be possible?

[develoopeer]

What's the problem?

As mentioned in #2514, building ad9361 driver as a module is not an trivial task, cause it required reimplementing some of the core code. Because of that, now building of driver as a module is forcefully disabled. I want to know, if someone working on this? Or maybe i am the only one facing the problem of live reloading driver.

My case

I want to manually reflash fpga firmware in real time without breaking a driver. I found this thread where someone recommended to

unbind dma-axi-dmac via sysfs -> reflash fpga -> bind again.

But for me it is simply not working. I assumed, that on driver initialization phase, driver configure some registers on the fpga, and after reflashing this data is gone. Reinitializing driver with

echo 1 > /sys/kernel/debug/iio/iio:device0/initialize

also didn't work. After that, i thought that the only way to be sure that driver is initialized correctly again is manually removing driver as a module and loading again. That's why i am asking will this ever be implemented?

[nunojsa]

unbind dma-axi-dmac via sysfs -> reflash fpga -> bind again.

This should be identical to unload + loading a module since this will unbind the device and bind it again (meaning that the probe function runs again).

But you have some more devices and we do have some hacking in this kind of devices so you might also have to disable the axi_dds and axi_adc driver. Mainly the axi_adc driver is linked with the transceiver. The whole thing might need some specific ordering.

I want to know, if someone working on this?

Don't think so...

[develoopeer]

I don't think that unbinding and binding again is similar to reloading driver, because look at what i am seeing right after successfuly booting on dmesg

ad9361 spi0.0: ad9361_probe : enter (ad9361)
ad9361 spi0.0: ad9361_probe : AD936x Rev 2 successfully initialized
cf_axi_dds 79024000.cf-ad9361-dds-core-lpc: Analog Devices CF_AXI_DDS_DDS MASTER (9.01.b) at 0x79024000 mapped to 0xf0983000, probed DDS AD9361
fpga_manager fpga0: Xilinx Zynq FPGA Manager registered
NET: Registered protocol family 17
Registering SWP/SWPB emulation handler
cf_axi_adc 79020000.cf-ad9361-lpc: ADI AIM (10.01.b) at 0x79020000 mapped to 0xf0990000, probed ADC AD9361 as MASTER
asoc-simple-card nh7020_sound: ak4954-hifi <-> 77600000.axi-i2s mapping ok

ad9361 driver said successfully initialized, and cf_axi_dds, cf_axi_adc also succesfuly probed.

After the procedure of unbinding dma drivers with commands:

echo 7c40000.dma > /sys/bus/platform/drivers/dma-axi-dmac/unbind

echo 7c42000.dma > /sys/bus/platform/drivers/dma-axi-dmac/unbind

# reload bitstream

echo 7c40000.dma > /sys/bus/platform/drivers/dma-axi-dmac/bind

echo 7c42000.dma > /sys/bus/platform/drivers/dma-axi-dmac/bind

i reloaded only dma drivers and got only this 2 messages in dmesg

cf_axi_dds 79024000.cf-ad9361-dds-core-lpc: Analog Devices CF_AXI_DDS_DDS MASTER (9.01.b) at 0x79024000 mapped to 0xf0983000, probed DDS AD9361
cf_axi_adc 79020000.cf-ad9361-lpc: ADI AIM (10.01.b) at 0x79020000 mapped to 0xf0990000, probed ADC AD9361 as MASTER
asoc-simple-card nh7020_sound: ak4954-hifi <-> 77600000.axi-i2s mapping ok

As i assumed previously at the time then ad9361 driver probing device, some registers configuration happening, which i want to repeat. How can this be dome? I also tried to forcefully reinitialize driver by

echo 1 > /sys/kernel/debug/iio/iio:device0/initialize

but nothing happened, no messages in dmesg.

[nunojsa]

i reloaded only dma drivers and got only this 2 messages in dmesg

Well, because you're not reloading all the devices... Just the DMA ones as you said. As I said:

But you have some more devices and we do have some hacking in this kind of devices so you might also have to disable the axi_dds and axi_adc driver. Mainly the axi_adc driver is linked with the transceiver. The whole thing might need some specific ordering.

echo 1 > /sys/kernel/debug/iio/iio:device0/initialize

This will re-initialize the device (it might even perform an HW reset) but it won't explicitly run probe() again.

I would recommend to look at the device tree to see which driver/devices are in place and then try to remove them.