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

[Getz, Robin]

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

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

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

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