Messages in this thread | | | Date | Sat, 22 Jun 2013 05:16:58 +0530 | From | pankaj chauhan <> | Subject | Re: [PATCH 3/5] drivers/misc: rf/ad9361: AD9361 device driver for Radio phy |
| |
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 >
| |