Messages in this thread | | | From | "Getz, Robin" <> | Subject | Re: [PATCH 3/5] drivers/misc: rf/ad9361: AD9361 device driver for Radio phy | Date | Mon, 24 Jun 2013 04:19:27 -0400 |
| |
On Thu 20 Jun 2013 06:35, pankaj chauhan pondered: > 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.
The AD9361 datasheet still hasn't been posted for public consumption yet (as of today), but for those interested, here is something similar - just not exactly - but it gets the idea across.
http://www.analog.com/static/imported-files/data_sheets/AD9357.pdf
> >> 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.
The "ADI GUI tool", is a proprietary, closed source, Windows only application. I think that for a Linux driver - we would want to be completely independent of that, and that the driver should be (a) standalone, or (b) useable with Linux based tools.
> 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).
Wow - LTE in userspace?
What's your requirements for real-timeness of the system? Bandwidth? Are you running a stock kernel for this? If you are monitoring RSSI, and changing attenuation (an AGC loop) - how quickly does this loop need to run? What speed are you running the ADC/DACs into userspace?
> 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.
Isn't this just normal GPIO control? (like Arnd suggested - if you need GPIO - make things a MFD - and use the existing GPIO infrastructure - at least that is how I thought the GPO would be handled, and maybe even the CNTRL IN/OUT).
> 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.
I don't know if we have all the answers yet either. We aren't running LTE - so having a real world userspace consumer might help direct us down a workable path for everyone.
It sounds like all the internal filters (which require floating point to calculate the coefficients) - you are letting the GUI tool handle all this? This is part of the issue we have been looking at - how to split things, so no floating point in the driver...
> > 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
| |