We have a design using an AD9361 transceiver on an AD-FSCOMMS2/3 board where we have distributed control, a user space application which controls a fair amount of transceiver content such as operating state, frequency, etc. and a Linux custom device driver operating in Linux kernel space that will need to control settings such as data rate quickly, and also needs to be the source and sink of network packets that originate (outgoing and incoming) to the Linux stack.
Attributes for control of the AD9361 are somewhat orthogonal so in concept, the two processes would not be controlling the same attributes.
We are considering using the No-OS bare metal SPI based driver in the Linux kernel device driver and the exposed exported APIs from ad9361.h from this driver for kernel space access, and using the AD9361 device driver coupled with LibIIO for the user space control. Notionally, the custom Linux device driver would perform the AD9361 initialization, and the User Space application would change attributes using the "sysfs" exposed interface via LibIIO.
Do you feel that conceptually this design is problematic? For example, is there an assumption in the design of
of the bare metal SPI interface of singular master for the AD9361. Since the AD9361 device drive uses the same SPI interface under the covers, are there issues with thread safety or re-entrancy?
The previous discussion addresses the control and status plain, but need for the data plain to be addressed by our custom Linux device driver which will act as a Linux network type of device driver. It would need to transmit content received from the network stack as Ethernet frames, and the converse, push received frames from the transceiver to the stack. This brings to mind issues of marking stream content to the AD9261 in such a manner that an Ethernet frame can be reconstituted. What APIs are available from the AD9361 device driver to support the transfer of data, or is that addressed by a different software component such as the ADCs?