Re: [PATCH 3/5] drivers/misc: rf/ad9361: AD9361 device driver forRadio phy
From: pankaj chauhan
Date: Thu Jun 20 2013 - 06:36:03 EST
On 6/19/2013 6:27 PM, Lars-Peter Clausen wrote:
On 06/17/2013 10:09 AM, akhil.goyal@xxxxxxxxxxxxx wrote:
From: Akhil Goyal <akhil.goyal@xxxxxxxxxxxxx>
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@xxxxxxxxxxxxx>
Signed-off-by: Pankaj Chauhan <pankaj.chauhan@xxxxxxxxxxxxx>
Signed-off-by: Bhaskar Upadhaya <bhaskar.upadhaya@xxxxxxxxxxxxx>
Signed-off-by: Akhil Goyal <akhil.goyal@xxxxxxxxxxxxx>
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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/