Date:	Mon, 24 Jun 2013 17:35:39 +0530
From:	pankaj chauhan <pankaj.chauhan@...escale.com>
To:	"Getz, Robin" <robin.getz@...log.com>
CC:	Lars-Peter Clausen <lars@...afoo.de>,
	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>,
	"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/24/2013 1:49 PM, Getz, Robin wrote:
> 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@...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.
>
> 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@...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.
>
> 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.
>

Agreed. We also would like to integrate with standalone driver instead 
of a driver which is dependent on 'ADI GUI tool'. since we had limited 
access to internals AD9361, we choose script generated by ADI tool as 
our configuration path for AD9361.

One your standalone driver is available we can discard AD9361 driver in 
this patch set and integrate our antenna controller driver with the 
standalone driver.

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

Yes we run both LTE and WCDMA stacks in user space. Reason is that most 
of commercial LTE/WCDMA  stack vendors implement their stacks in user space.

Here is how it works:

1. Layer1 stack runs on a DSP core running non Linux RTOS.
2. Layer2/3 stacks run in Linux user space on a application core.
3. Both cores use hardware based communication mechanisms for 
communication between L1 <-> L2/L3.

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

Since L2/L3 stacks are in user space, we can not run it on stock kernel. 
We run it on sock kernel + PREEMT_RT patch. The Real time requirement 
varies from protocol to protocol, for example for LTE we have to perform 
'few operations' in a TTI (1 milli second, with error margin of 30 micro 
seconds). 'Few operations' again depends on use case and data path which 
we are running on system, some examples are:

1. Reading RSSI values.
2. Updating gain.
3. Reading IQ data of last subframe (1 ms), radio frame (10 ms), or 
multiple radio frames (N * 10ms).

updating attenuation isn't currently in real time path.

We are running at maximum of 30.72 MSPS (million samples per second, 
with 16 bit samples). but Speed of IQ transfer wont' matter much for 
Linux drivers because IQ data doesn't pass through Linux drivers (except 
for sniffing).
>
>> 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).
>

Agreed on this. so radio card part of driver can very well be in MFD.
>
>> 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.
>

We are using AD9361 for LTE and WCDMA, so we are real world users :) 
only problem is that the vendors for L2/L3 stacks are in user space (and 
their stacks are not open source). I can document the user space 
interface that we have, and then we can discuss on the interface for 
additions/deletions/modifications.

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

Yes, what we are doing is that we generate script for a particular 
bandwidth/Lo frequency combination and initialize AD9361 with this 
script. Later if we have to change LO frequency, gain tables, 
synthesizer tables we do floating point in user space and pass fixed 
point data in driver. This makes programming interface of AD9361 much 
simpler for us to use.

We can adopt the full fledged standalone driver that you are developing 
and integrate with our controller drivers as long as our requirements 
(functionality for function pointers in phy_ops structure) are met.

  >



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