Re: [PATCH 3/5] drivers/misc: rf/ad9361: AD9361 device driver for Radio phy
On 7/4/2013 1:06 AM, Mark Brown wrote: > On Thu, Jun 20, 2013 at 04:05:20PM +0530, pankaj chauhan wrote: > >> 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. > > Use regmap, it should have the infrastructure you need here. > Thanks! I looked into regmap, and it is exactly what we want. We'll remove reg read/write from our patch and use regmap. >> 2. Initializing AD9361 using Low level script generated by ADI GUI tool. > > This sounds like generating a firmmware blob that the driver can load. > You may have to cook the GUI output to be more amenable to loading in > the kernel (or persuade the GUI guys to generate something useful here). > Yes it is kind of generating firmware blob from GUI tool. They reason why we choose to initialize AD9361 using script generated by GUI tool was lack of our insight in AD9361, and script is the quickest way to bring-up AD9361. This GUI is developed by analog devices, so we don't have much control on it. Lars and Robin are developing full fledged driver for Ad9661, We intend to use that driver only, that's why in next version of patch we'll remove AD9361 driver from our patchset, and integrate with Lars' driver once it is available. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/5] drivers/misc: rf/ad9361: AD9361 device driver for Radio phy
On 7/4/2013 1:06 AM, Mark Brown wrote: On Thu, Jun 20, 2013 at 04:05:20PM +0530, pankaj chauhan wrote: 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. Use regmap, it should have the infrastructure you need here. Thanks! I looked into regmap, and it is exactly what we want. We'll remove reg read/write from our patch and use regmap. 2. Initializing AD9361 using Low level script generated by ADI GUI tool. This sounds like generating a firmmware blob that the driver can load. You may have to cook the GUI output to be more amenable to loading in the kernel (or persuade the GUI guys to generate something useful here). Yes it is kind of generating firmware blob from GUI tool. They reason why we choose to initialize AD9361 using script generated by GUI tool was lack of our insight in AD9361, and script is the quickest way to bring-up AD9361. This GUI is developed by analog devices, so we don't have much control on it. Lars and Robin are developing full fledged driver for Ad9661, We intend to use that driver only, that's why in next version of patch we'll remove AD9361 driver from our patchset, and integrate with Lars' driver once it is available. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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.go...@freescale.com wrote: From: Akhil Goyal 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 Signed-off-by: Pankaj Chauhan Signed-off-by: Bhaskar Upadhaya Signed-off-by: Akhil Goyal 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
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.go...@freescale.com wrote: From: Akhil Goyal akhil.go...@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 shav...@freescale.com Signed-off-by: Pankaj Chauhan pankaj.chau...@freescale.com Signed-off-by: Bhaskar Upadhaya bhaskar.upadh...@freescale.com Signed-off-by: Akhil Goyal akhil.go...@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. 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
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.go...@freescale.com wrote: From: Akhil Goyal 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 Signed-off-by: Pankaj Chauhan Signed-off-by: Bhaskar Upadhaya Signed-off-by: Akhil Goyal 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 w
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.go...@freescale.com wrote: From: Akhil Goyal akhil.go...@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 shav...@freescale.com Signed-off-by: Pankaj Chauhan pankaj.chau...@freescale.com Signed-off-by: Bhaskar Upadhaya bhaskar.upadh...@freescale.com Signed-off-by: Akhil Goyal akhil.go...@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
Re: [PATCH 1/5] drivers/misc: Support for RF interface device framework
On 6/19/2013 5:01 PM, Lars-Peter Clausen wrote: On 06/18/2013 09:44 AM, Akhil Goyal wrote: [...] +/* + * Spin_locks are changed to mutexes if PREEMPT_RT is enabled, + * i.e they can sleep. This fact is problem for us because + * add_wait_queue()/wake_up_all() takes wait queue spin lock. + * Since spin lock can sleep with PREEMPT_RT, wake_up_all() can not be + * called from rf_notify_dl_tti (which is called in interrupt context). + * As a workaround, wait_q_lock is used for protecting the wait_q and + * add_wait_queue_locked()/ wake_up_locked() functions of wait queues + * are used. + */ +raw_spin_lock_irqsave(_dev->wait_q_lock, flags); +__add_wait_queue_tail_exclusive(_dev->wait_q,); +raw_spin_unlock_irqrestore(_dev->wait_q_lock, flags); +set_current_state(TASK_INTERRUPTIBLE); +/*Now wait here, tti notificaion will wake us up*/ +schedule(); +set_current_state(TASK_RUNNING); +raw_spin_lock_irqsave(_dev->wait_q_lock, flags); +__remove_wait_queue(_dev->wait_q,); +raw_spin_unlock_irqrestore(_dev->wait_q_lock, flags); This is not a proper method of waiting for an event. Why can't you use wait_event() here? wait_event() is internally calling spin_lock_irqsave() and this function will be called in hard IRQ context with PREEMPT_RT enabled(IRQF_NODELAY set). So wait_event cannot be used. This problem can be solved if we can get the following patch applied on the tree. https://patchwork.kernel.org/patch/2161261/ The explanation about the interrupt handler seems incorrect, since PREEMPT_RT also turns interrupt handlers into threads. The interrupt handler has real time requirement and thus running in HARDIRQ context with flag IRQF_NODELAY. We get this interrupt in every millisecond. But if you are running in HARDIRQ context the whole sequence doesn't make much sense at all, since you won't be able to sleep and wait for the event. This function for adding process to rf_dev->wait_q runs in process context, but the function (dl_notify_tti())which wakes process up from this queue runs in HARDIRQ context, that's why we could not use wait_event() or spin_lock() here. thanks, pankaj -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/5] drivers/misc: rf/ad9361: AD9361 device driver for Radio phy
On 6/19/2013 6:27 PM, Lars-Peter Clausen wrote: On 06/17/2013 10:09 AM, akhil.go...@freescale.com wrote: From: Akhil Goyal 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 Signed-off-by: Pankaj Chauhan Signed-off-by: Bhaskar Upadhaya Signed-off-by: Akhil Goyal 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 ra
Re: [PATCH 3/5] drivers/misc: rf/ad9361: AD9361 device driver for Radio phy
On 6/19/2013 6:27 PM, Lars-Peter Clausen wrote: On 06/17/2013 10:09 AM, akhil.go...@freescale.com wrote: From: Akhil Goyal akhil.go...@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 shav...@freescale.com Signed-off-by: Pankaj Chauhan pankaj.chau...@freescale.com Signed-off-by: Bhaskar Upadhaya bhaskar.upadh...@freescale.com Signed-off-by: Akhil Goyal akhil.go...@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. 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
Re: [PATCH 1/5] drivers/misc: Support for RF interface device framework
On 6/19/2013 5:01 PM, Lars-Peter Clausen wrote: On 06/18/2013 09:44 AM, Akhil Goyal wrote: [...] +/* + * Spin_locks are changed to mutexes if PREEMPT_RT is enabled, + * i.e they can sleep. This fact is problem for us because + * add_wait_queue()/wake_up_all() takes wait queue spin lock. + * Since spin lock can sleep with PREEMPT_RT, wake_up_all() can not be + * called from rf_notify_dl_tti (which is called in interrupt context). + * As a workaround, wait_q_lock is used for protecting the wait_q and + * add_wait_queue_locked()/ wake_up_locked() functions of wait queues + * are used. + */ +raw_spin_lock_irqsave(rf_dev-wait_q_lock, flags); +__add_wait_queue_tail_exclusive(rf_dev-wait_q,wait); +raw_spin_unlock_irqrestore(rf_dev-wait_q_lock, flags); +set_current_state(TASK_INTERRUPTIBLE); +/*Now wait here, tti notificaion will wake us up*/ +schedule(); +set_current_state(TASK_RUNNING); +raw_spin_lock_irqsave(rf_dev-wait_q_lock, flags); +__remove_wait_queue(rf_dev-wait_q,wait); +raw_spin_unlock_irqrestore(rf_dev-wait_q_lock, flags); This is not a proper method of waiting for an event. Why can't you use wait_event() here? wait_event() is internally calling spin_lock_irqsave() and this function will be called in hard IRQ context with PREEMPT_RT enabled(IRQF_NODELAY set). So wait_event cannot be used. This problem can be solved if we can get the following patch applied on the tree. https://patchwork.kernel.org/patch/2161261/ The explanation about the interrupt handler seems incorrect, since PREEMPT_RT also turns interrupt handlers into threads. The interrupt handler has real time requirement and thus running in HARDIRQ context with flag IRQF_NODELAY. We get this interrupt in every millisecond. But if you are running in HARDIRQ context the whole sequence doesn't make much sense at all, since you won't be able to sleep and wait for the event. This function for adding process to rf_dev-wait_q runs in process context, but the function (dl_notify_tti())which wakes process up from this queue runs in HARDIRQ context, that's why we could not use wait_event() or spin_lock() here. thanks, pankaj -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
