AnsweredAssumed Answered

Linux Driver to Kernel Module

Question asked by mike.baker Employee on Oct 23, 2017
Latest reply on Oct 26, 2017 by gverma

My understanding is that there are two software packages which could apply for our use case, an "evaluation" package and a "prototyping" package.  See this link:  What makes things a bit more confusing is that the driver itself is divided into a "control" segment (i.e., code that sends SPI commands to the transceiver itself) and a "data" segment (i.e., code that reads data off of an FPGA that is between the CPU and the transceiver).  Additionally, my research for the Linux driver alluded to the fact that there are two APIs.  First, the driver itself builds several files in /sys/bus/iio/devices which can be manipulated via read() and write() calls.  However, there is also another API that is referenced in the AD9371 user's guide (UG992) where all I need to do is edit a common.h/.c set of files to include the necessary hooks for SPI and GPIO.  From there, I can call things like "MYKONOS_initialize(&mykDevice)" in my application code.



For our purposes, we are primarily concerned with the "prototyping" software package since we are going to be building a custom PCB.  Also, we are using a PCIe DMA Xilinx reference design, so we have the "data" portion of the driver taken care of for the most part.  As a result, my questions are directed at the "control" portion of the driver and getting it integrated into a system running Ubuntu 16.04.



Here are my questions currently:
1. How can I build the Linux driver into a kernel module?  The link you provided me I am very familiar with, and it just points to various disparate C files.  Is there a repo or a .zip file somewhere I can download and build a kernel module from?  Ideally, I am looking for a repo that contains the directory structure highlighted in UG992 (see page 8), unless there is a better way to get the driver up and running that I do not know about.
2. Given the two APIs for Linux, which is the preferred route to talk to the transceiver?  Is there maybe another way to talk to the chip that I don't know about that could get us up and running faster?



Thanks in advance for the help.