Message-ID: <51C2DAE8.2040100@freescale.com>
Date:	Thu, 20 Jun 2013 16:05:20 +0530
From:	pankaj chauhan <pankaj.chauhan@...escale.com>
To:	Lars-Peter Clausen <lars@...afoo.de>
CC:	Goyal Akhil-B35197 <B35197@...escale.com>,
	"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
	"arnd@...db.de" <arnd@...db.de>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Chauhan Pankaj-B32944 <B32944@...escale.com>,
	"Getz, Robin" <robin.getz@...log.com>,
	"Hennerich, Michael" <Michael.Hennerich@...log.com>,
	Lars-Peter Clausen <lars-peter.clausen@...log.com>
Subject: Re: [PATCH 3/5] drivers/misc: rf/ad9361: AD9361 device driver for
 Radio phy

On 6/19/2013 6:27 PM, Lars-Peter Clausen wrote:
> On 06/17/2013 10:09 AM, akhil.goyal@...escale.com wrote:
>> From: Akhil Goyal <akhil.goyal@...escale.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@...escale.com>
>> Signed-off-by: Pankaj Chauhan <pankaj.chauhan@...escale.com>
>> Signed-off-by: Bhaskar Upadhaya <bhaskar.upadhaya@...escale.com>
>> Signed-off-by: Akhil Goyal <akhil.goyal@...escale.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.

> 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.

> 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


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists