Re: [PATCH 3/5] drivers/misc: rf/ad9361: AD9361 device driver for Radio phy

[pankaj chauhan <pankaj.chauhan@freescale.com>]

On 6/20/2013 4:05 PM, pankaj chauhan wrote:
> On 6/19/2013 6:27 PM, Lars-Peter Clausen wrote:
>> On 06/17/2013 10:09 AM, akhil.goyal@freescale.com wrote:
>>> From: Akhil Goyal <akhil.goyal@freescale.com>
>>>
>>> AD9361 is a radio phy(RFIC) for radio networks. This phy
>>> can support LTE-FDD/LTE-TDD and WCDMA networks. The RFIC
>>> can convert the analog radio signals from air to digital
>>> IQ samples.
>>>
>>> AD9361 is controlled via an SPI bus and all the register
>>> read/ write can be performed via SPI transactions.
>>>
>>> Driver provides various operations for configuring and
>>> controlling the AD PHY. These can be controlled from the
>>> user space via the rfdev framework.
>>>
>>> Driver also binds itself to one of AIC lane using RF framework.
>>> The combination of AIC lane and PHY connected to it works
>>> as one RF device.
>>>
>>> Signed-off-by: Shaveta Leekha <shaveta@freescale.com>
>>> Signed-off-by: Pankaj Chauhan <pankaj.chauhan@freescale.com>
>>> Signed-off-by: Bhaskar Upadhaya <bhaskar.upadhaya@freescale.com>
>>> Signed-off-by: Akhil Goyal <akhil.goyal@freescale.com>
>>
>> Hi,
>>
>> This is interesting. We at Analog Devices are currently also working on a
>> driver for this part. We are using the Linux Industrial IO (IIO)
>> framework
>> though, since the AD9361 is more or less a multifunction device
>> implementing
>> different functions already covered by the IIO framework, like ADCs,
>> DACs,
>> clock chips and so on.
>>
> Yes i agree AD9361 is more of a multifunction device and it can fit in
> IIO framework. This patch (ad9361: AD9361 device driver for Radio phy)
> implements:
>
> 1. Programming of AD9361 :
>
> Most of initialization is done by parsing Low level script generated by
> ADI tool, and sending the SPIwrite/read/wait calibration commands to the
> driver. This is more of a raw write interface to device.
>
> 2. Adding utility function APIs for higher layers:
>
> We have LTE/WCDMA stacks running in user space. They have requirement of
> monitoring RSSI, changing Attenuation, reading/changing Rx gain,
> disable/enable of tx/rx antennas, changing LO frequency etc. This patch
> exposes APIs which can be accessed through RF device layer user space
> interface (explained later in the email).
>
> 3. Control of Radio card (which has AD9361): We have radio card which
> contains AD9361 and there are different set of PA/LNAs (Power
> amplifier/Low Noise Amplifier). Each set caters a set of frequency
> bands. This patch also exports functions to enable/disable a Tx/Rx path
> (PA/LNAs) which are external to AD9361.
>
> May be we can spit this driver in two parts :
>
> 1. AD9361 driver: which covers #1 and #2 as mentioned as above. And this
> can be merged with the driver you have in IIO framework.
>
> 2. Radio card driver: which covers #3 and uses AD9361 driver's exported
> APIs to program AD9361 OR may be we can program AD9361 from user space
> using IIO interface.
>
> pls let me know what do you think is best approach.

Lars pls suggest whether this split will work for both of us.

>
>> You seem to have made the kernel layer as thin as possible and provide a
>> IOCTL which allows userspace to directly modify the registers of the
>> hardware. So this sentence from the documentation "user space
>> interface is
>> independent of component (vendor specific) drivers" is not exactly
>> true. If
>> you write a userspace application it will still only work with one
>> specific
>> RF-frontend. There is only a common interface on how to talk to the
>> frontend. Your documentation on this is also a bit sparse, e.g. there
>> is no
>> explanation of the individual IOCTLs.
>>
> Yes modifying registers from user space is part of the patch set and
> register read/write interface is aimed only for two purposes:
>
> 1. Debugging : taking register dumps etc.
> 2. Initializing AD9361 using Low level script generated by ADI GUI tool.
>
> I'll try to explain what we meant by 'independent of vendor specific
> drivers' and the framework itself.
>
>
> Following is the overview of hardware on which are running these drivers:
>
> 1. Antenna controller : This is part of SOC. The controller has
>     multiple IQ data lanes. On the application core of SOC we run Linux.
>     LTE/WCDMA stacks run in user space, and they interact with antenna
>     controller and RFPHY.
> 2. Radio card: This contains one or more RF PHYS (AD9361). Each AD9361
>     is connected to Antenna controller IQ lane over JESD207 bus.
>
> With this patch set we aim to abstract combination of a IQ data lane and
> RF PHY as a 'radio device'. So this patch set is divided in three parts:
>
> 1. RF device layer :
>      - Exposes IOCTLS to user space for device configuration.
>      - Exposes registration APIs so that antenna controllers and PHYs
>        so that they can register their control operations.
>        antenna controller and RF PHYs don't interact with user space
>        directly.
>      - Maintains state of overall RF device. For example IQ data
>        transfer starts only when both the controller and PHY are
>        configured and ready.
>
> 2. Antenna controller driver: This configures the Antenna controller
>     hardware. It registers its control functions as a ops structure
>     (containing function pointers) with RF device layer.
>
> 3. RF PHY driver: This is AD9361 driver (in this patch set). This also
> registers with it ops structure with RF device layer. One of the
> operation is raw register read/write as you pointed out.
>
> The RF device layer exposes the two (or more than two) devices (i.e
> antenna controller and RF PHY) as a RF device 'rf0' to user space. It is
> similar to Ethernet,  which  has two drivers (Ethernet MAC controller
> driver, and the Ethernet PHY driver) under eth0/eth1 interface.
>
> The exposed IOCTLs from RF device layer are generic or protocol specific
> (except raw register read/write interface), for example:
>
> 1. Setting network mode of device to LTE, WCDMA etc
> 2. Configuring device in TDD or FDD mode.
> 3. Setting bandwidth to 10 Mhz, 15 Mhz, or 20 Mz.
> 4. Changing Downlink/Uplink LO frequency to 'X' Mhz.
> 5. Capturing IQ data from controller.
> 6. Changing RF settings: attenuation, rx gain etc.
> 7. Raw register read/write: so that PHYS with programming model
>     similar to AD9361 (using script containing SPI commands) can
>     be supported.
>
> Generally LTE/WCDMA stacks run in user space and they have to interact
> with the antenna controller and the RF PHY (AD9361) for initialization,
> control, IQ capture etc.
>
> If we don't have RF device layer then these stacks have to write vendor
> drivers (antenna controller and RF PHY) specific code for interaction
> with underlying controller and PHY drivers.
>
> The RF device layer solves this problem by exposing an interface which
> is protocol/functionality specific, so that the user space stack do not
> change if underlying antenna controller or RF phy changes.
>
> In user space we have a library called 'rflib' which interacts with RF
> device layer through exposed IOCTLs. User space LTE/WCDMA stacks
> interact only with 'rflib' and they are immune to underlying vendor
> specific drivers. This is the reason for calling 'vendor independent
> interface'. And if user space wants to fine tune the RF PHY then raw
> register read/write interface is also exposed.
>
> We are not aware of any other subsystem which meets above mentioned
> requirements, and exposes interface for LTE/WCDMA stacks for controlling
> radio hardware. That's why we introduced RF device layer between user
> space interface and controller specific drivers.
>
> pls suggest what is best possible way/subsystem for hardware and
> software requirements that i explained above.
>

I've tried to capture the need of a framework for drivers dealing with 
IQ data which interact with LTE/WCDMA stacks. Pls suggest the way forward.

>> Since it is probably not such a good idea to have two different
>> drivers for
>> the same device in different subsystems we should probably try to figure
>> something out that will work for us both.
>>
>
> I agree, for AD9361 should have one driver, we'll figure out way how
> requirements for both of us can be met by single driver.
>
>> I'd also be interested in learning more about how the userspace side
>> looks like.
>>
>
> The user space (rflib) is not on a public repository yet, i'll try to
> figure out how rflib can be
>> - Lars
>>
>
> sorry for long reply, we'll cover the details of API/framework in
> documentation in next version of patch.
>
> thanks,
> pankaj
>