Hi,
The following patchset adds device tree support to
the spi variant of the wl1251 driver.
Some notes:
The first patch is from Luciano's wilink DT support
patchset [0].
The third patch (vio regulator support) is optional. N900's
wifi also worked without this patch, but its probably cleaner
to have it.
The patchset has been tested using DT boot with the Nokia N900
and connecting to my wlan access point.
[0] https://lkml.org/lkml/2013/7/3/333
-- Sebastian
Luciano Coelho (1):
wl1251: split wl251 platform data to a separate structure
Sebastian Reichel (3):
wl1251: move power GPIO handling into the driver
wl1251: spi: add vio regulator support
wl1251: spi: add device tree support
.../devicetree/bindings/net/wireless/ti,wl1251.txt | 36 +++++++++++
arch/arm/mach-omap2/board-omap3pandora.c | 6 +-
arch/arm/mach-omap2/board-rx51-peripherals.c | 15 ++---
drivers/net/wireless/ti/wilink_platform_data.c | 37 +++++++++--
drivers/net/wireless/ti/wl1251/sdio.c | 31 +++++++---
drivers/net/wireless/ti/wl1251/spi.c | 71 ++++++++++++++++------
drivers/net/wireless/ti/wl1251/wl1251.h | 4 +-
include/linux/wl12xx.h | 24 +++++++-
8 files changed, 175 insertions(+), 49 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/wireless/ti,wl1251.txt
--
1.8.4.rc3
From: Luciano Coelho <[email protected]>
Move the wl1251 part of the wl12xx platform data structure into a new
structure specifically for wl1251. Change the platform data built-in
block and board files accordingly.
Cc: Tony Lindgren <[email protected]>
Signed-off-by: Luciano Coelho <[email protected]>
Acked-by: Tony Lindgren <[email protected]>
Reviewed-by: Felipe Balbi <[email protected]>
---
arch/arm/mach-omap2/board-omap3pandora.c | 4 +--
arch/arm/mach-omap2/board-rx51-peripherals.c | 2 +-
drivers/net/wireless/ti/wilink_platform_data.c | 37 +++++++++++++++++++++-----
drivers/net/wireless/ti/wl1251/sdio.c | 12 ++++-----
drivers/net/wireless/ti/wl1251/spi.c | 2 +-
include/linux/wl12xx.h | 22 ++++++++++++++-
6 files changed, 62 insertions(+), 17 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3pandora.c b/arch/arm/mach-omap2/board-omap3pandora.c
index de1bc6b..24f3c1b 100644
--- a/arch/arm/mach-omap2/board-omap3pandora.c
+++ b/arch/arm/mach-omap2/board-omap3pandora.c
@@ -536,7 +536,7 @@ static struct spi_board_info omap3pandora_spi_board_info[] __initdata = {
static void __init pandora_wl1251_init(void)
{
- struct wl12xx_platform_data pandora_wl1251_pdata;
+ struct wl1251_platform_data pandora_wl1251_pdata;
int ret;
memset(&pandora_wl1251_pdata, 0, sizeof(pandora_wl1251_pdata));
@@ -550,7 +550,7 @@ static void __init pandora_wl1251_init(void)
goto fail_irq;
pandora_wl1251_pdata.use_eeprom = true;
- ret = wl12xx_set_platform_data(&pandora_wl1251_pdata);
+ ret = wl1251_set_platform_data(&pandora_wl1251_pdata);
if (ret < 0)
goto fail_irq;
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c b/arch/arm/mach-omap2/board-rx51-peripherals.c
index 65e3627..0d8e7d2 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -82,7 +82,7 @@ enum {
RX51_SPI_MIPID, /* LCD panel */
};
-static struct wl12xx_platform_data wl1251_pdata;
+static struct wl1251_platform_data wl1251_pdata;
static struct tsc2005_platform_data tsc2005_pdata;
#if defined(CONFIG_SENSORS_LIS3_I2C) || defined(CONFIG_SENSORS_LIS3_I2C_MODULE)
diff --git a/drivers/net/wireless/ti/wilink_platform_data.c b/drivers/net/wireless/ti/wilink_platform_data.c
index 998e958..a92bd3e 100644
--- a/drivers/net/wireless/ti/wilink_platform_data.c
+++ b/drivers/net/wireless/ti/wilink_platform_data.c
@@ -23,17 +23,17 @@
#include <linux/err.h>
#include <linux/wl12xx.h>
-static struct wl12xx_platform_data *platform_data;
+static struct wl12xx_platform_data *wl12xx_platform_data;
int __init wl12xx_set_platform_data(const struct wl12xx_platform_data *data)
{
- if (platform_data)
+ if (wl12xx_platform_data)
return -EBUSY;
if (!data)
return -EINVAL;
- platform_data = kmemdup(data, sizeof(*data), GFP_KERNEL);
- if (!platform_data)
+ wl12xx_platform_data = kmemdup(data, sizeof(*data), GFP_KERNEL);
+ if (!wl12xx_platform_data)
return -ENOMEM;
return 0;
@@ -41,9 +41,34 @@ int __init wl12xx_set_platform_data(const struct wl12xx_platform_data *data)
struct wl12xx_platform_data *wl12xx_get_platform_data(void)
{
- if (!platform_data)
+ if (!wl12xx_platform_data)
return ERR_PTR(-ENODEV);
- return platform_data;
+ return wl12xx_platform_data;
}
EXPORT_SYMBOL(wl12xx_get_platform_data);
+
+static struct wl1251_platform_data *wl1251_platform_data;
+
+int __init wl1251_set_platform_data(const struct wl1251_platform_data *data)
+{
+ if (wl1251_platform_data)
+ return -EBUSY;
+ if (!data)
+ return -EINVAL;
+
+ wl1251_platform_data = kmemdup(data, sizeof(*data), GFP_KERNEL);
+ if (!wl1251_platform_data)
+ return -ENOMEM;
+
+ return 0;
+}
+
+struct wl1251_platform_data *wl1251_get_platform_data(void)
+{
+ if (!wl1251_platform_data)
+ return ERR_PTR(-ENODEV);
+
+ return wl1251_platform_data;
+}
+EXPORT_SYMBOL(wl1251_get_platform_data);
diff --git a/drivers/net/wireless/ti/wl1251/sdio.c b/drivers/net/wireless/ti/wl1251/sdio.c
index e2b3d9c..b75a37a 100644
--- a/drivers/net/wireless/ti/wl1251/sdio.c
+++ b/drivers/net/wireless/ti/wl1251/sdio.c
@@ -227,7 +227,7 @@ static int wl1251_sdio_probe(struct sdio_func *func,
struct wl1251 *wl;
struct ieee80211_hw *hw;
struct wl1251_sdio *wl_sdio;
- const struct wl12xx_platform_data *wl12xx_board_data;
+ const struct wl1251_platform_data *wl1251_board_data;
hw = wl1251_alloc_hw();
if (IS_ERR(hw))
@@ -254,11 +254,11 @@ static int wl1251_sdio_probe(struct sdio_func *func,
wl->if_priv = wl_sdio;
wl->if_ops = &wl1251_sdio_ops;
- wl12xx_board_data = wl12xx_get_platform_data();
- if (!IS_ERR(wl12xx_board_data)) {
- wl->set_power = wl12xx_board_data->set_power;
- wl->irq = wl12xx_board_data->irq;
- wl->use_eeprom = wl12xx_board_data->use_eeprom;
+ wl1251_board_data = wl1251_get_platform_data();
+ if (!IS_ERR(wl1251_board_data)) {
+ wl->set_power = wl1251_board_data->set_power;
+ wl->irq = wl1251_board_data->irq;
+ wl->use_eeprom = wl1251_board_data->use_eeprom;
}
if (wl->irq) {
diff --git a/drivers/net/wireless/ti/wl1251/spi.c b/drivers/net/wireless/ti/wl1251/spi.c
index c7dc6fe..6bbbfe6 100644
--- a/drivers/net/wireless/ti/wl1251/spi.c
+++ b/drivers/net/wireless/ti/wl1251/spi.c
@@ -238,7 +238,7 @@ static const struct wl1251_if_operations wl1251_spi_ops = {
static int wl1251_spi_probe(struct spi_device *spi)
{
- struct wl12xx_platform_data *pdata;
+ struct wl1251_platform_data *pdata;
struct ieee80211_hw *hw;
struct wl1251 *wl;
int ret;
diff --git a/include/linux/wl12xx.h b/include/linux/wl12xx.h
index a54fe82..b516b4f 100644
--- a/include/linux/wl12xx.h
+++ b/include/linux/wl12xx.h
@@ -48,11 +48,15 @@ enum {
WL12XX_TCXOCLOCK_33_6 = 7, /* 33.6 MHz */
};
-struct wl12xx_platform_data {
+struct wl1251_platform_data {
void (*set_power)(bool enable);
/* SDIO only: IRQ number if WLAN_IRQ line is used, 0 for SDIO IRQs */
int irq;
bool use_eeprom;
+};
+
+struct wl12xx_platform_data {
+ int irq;
int board_ref_clock;
int board_tcxo_clock;
unsigned long platform_quirks;
@@ -68,6 +72,10 @@ int wl12xx_set_platform_data(const struct wl12xx_platform_data *data);
struct wl12xx_platform_data *wl12xx_get_platform_data(void);
+int wl1251_set_platform_data(const struct wl1251_platform_data *data);
+
+struct wl1251_platform_data *wl1251_get_platform_data(void);
+
#else
static inline
@@ -82,6 +90,18 @@ struct wl12xx_platform_data *wl12xx_get_platform_data(void)
return ERR_PTR(-ENODATA);
}
+static inline
+int wl1251_set_platform_data(const struct wl1251_platform_data *data)
+{
+ return -ENOSYS;
+}
+
+static inline
+struct wl1251_platform_data *wl1251_get_platform_data(void)
+{
+ return ERR_PTR(-ENODATA);
+}
+
#endif
#endif
--
1.8.4.rc3
Move the power GPIO handling from the board code into
the driver. This is a dependency for device tree support.
Signed-off-by: Sebastian Reichel <[email protected]>
---
arch/arm/mach-omap2/board-omap3pandora.c | 2 ++
arch/arm/mach-omap2/board-rx51-peripherals.c | 11 ++--------
drivers/net/wireless/ti/wl1251/sdio.c | 21 +++++++++++++-----
drivers/net/wireless/ti/wl1251/spi.c | 33 ++++++++++++++++++----------
drivers/net/wireless/ti/wl1251/wl1251.h | 2 +-
include/linux/wl12xx.h | 2 +-
6 files changed, 43 insertions(+), 28 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3pandora.c b/arch/arm/mach-omap2/board-omap3pandora.c
index 24f3c1b..cf18340 100644
--- a/arch/arm/mach-omap2/board-omap3pandora.c
+++ b/arch/arm/mach-omap2/board-omap3pandora.c
@@ -541,6 +541,8 @@ static void __init pandora_wl1251_init(void)
memset(&pandora_wl1251_pdata, 0, sizeof(pandora_wl1251_pdata));
+ pandora_wl1251_pdata.power_gpio = -1;
+
ret = gpio_request_one(PANDORA_WIFI_IRQ_GPIO, GPIOF_IN, "wl1251 irq");
if (ret < 0)
goto fail;
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c b/arch/arm/mach-omap2/board-rx51-peripherals.c
index 0d8e7d2..b9d95dd 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -1164,13 +1164,7 @@ static inline void board_smc91x_init(void)
#endif
-static void rx51_wl1251_set_power(bool enable)
-{
- gpio_set_value(RX51_WL1251_POWER_GPIO, enable);
-}
-
static struct gpio rx51_wl1251_gpios[] __initdata = {
- { RX51_WL1251_POWER_GPIO, GPIOF_OUT_INIT_LOW, "wl1251 power" },
{ RX51_WL1251_IRQ_GPIO, GPIOF_IN, "wl1251 irq" },
};
@@ -1187,17 +1181,16 @@ static void __init rx51_init_wl1251(void)
if (irq < 0)
goto err_irq;
- wl1251_pdata.set_power = rx51_wl1251_set_power;
+ wl1251_pdata.power_gpio = RX51_WL1251_POWER_GPIO;
rx51_peripherals_spi_board_info[RX51_SPI_WL1251].irq = irq;
return;
err_irq:
gpio_free(RX51_WL1251_IRQ_GPIO);
- gpio_free(RX51_WL1251_POWER_GPIO);
error:
printk(KERN_ERR "wl1251 board initialisation failed\n");
- wl1251_pdata.set_power = NULL;
+ wl1251_pdata.power_gpio = -1;
/*
* Now rx51_peripherals_spi_board_info[1].irq is zero and
diff --git a/drivers/net/wireless/ti/wl1251/sdio.c b/drivers/net/wireless/ti/wl1251/sdio.c
index b75a37a..b661f89 100644
--- a/drivers/net/wireless/ti/wl1251/sdio.c
+++ b/drivers/net/wireless/ti/wl1251/sdio.c
@@ -28,6 +28,7 @@
#include <linux/wl12xx.h>
#include <linux/irq.h>
#include <linux/pm_runtime.h>
+#include <linux/gpio.h>
#include "wl1251.h"
@@ -182,8 +183,9 @@ static int wl1251_sdio_set_power(struct wl1251 *wl, bool enable)
* callback in case it wants to do any additional setup,
* for example enabling clock buffer for the module.
*/
- if (wl->set_power)
- wl->set_power(true);
+ if (gpio_is_valid(wl->power_gpio))
+ gpio_set_value(wl->power_gpio, true);
+
ret = pm_runtime_get_sync(&func->dev);
if (ret < 0) {
@@ -203,8 +205,8 @@ static int wl1251_sdio_set_power(struct wl1251 *wl, bool enable)
if (ret < 0)
goto out;
- if (wl->set_power)
- wl->set_power(false);
+ if (gpio_is_valid(wl->power_gpio))
+ gpio_set_value(wl->power_gpio, false);
}
out:
@@ -256,11 +258,20 @@ static int wl1251_sdio_probe(struct sdio_func *func,
wl1251_board_data = wl1251_get_platform_data();
if (!IS_ERR(wl1251_board_data)) {
- wl->set_power = wl1251_board_data->set_power;
+ wl->power_gpio = wl1251_board_data->power_gpio;
wl->irq = wl1251_board_data->irq;
wl->use_eeprom = wl1251_board_data->use_eeprom;
}
+ if (gpio_is_valid(wl->power_gpio)) {
+ ret = devm_gpio_request(&func->dev, wl->power_gpio,
+ "wl1251 power");
+ if (ret) {
+ wl1251_error("Failed to request gpio: %d\n", ret);
+ goto disable;
+ }
+ }
+
if (wl->irq) {
irq_set_status_flags(wl->irq, IRQ_NOAUTOEN);
ret = request_irq(wl->irq, wl1251_line_irq, 0, "wl1251", wl);
diff --git a/drivers/net/wireless/ti/wl1251/spi.c b/drivers/net/wireless/ti/wl1251/spi.c
index 6bbbfe6..9a2df9d 100644
--- a/drivers/net/wireless/ti/wl1251/spi.c
+++ b/drivers/net/wireless/ti/wl1251/spi.c
@@ -26,6 +26,7 @@
#include <linux/crc7.h>
#include <linux/spi/spi.h>
#include <linux/wl12xx.h>
+#include <linux/gpio.h>
#include "wl1251.h"
#include "reg.h"
@@ -221,8 +222,8 @@ static void wl1251_spi_disable_irq(struct wl1251 *wl)
static int wl1251_spi_set_power(struct wl1251 *wl, bool enable)
{
- if (wl->set_power)
- wl->set_power(enable);
+ if (gpio_is_valid(wl->power_gpio))
+ gpio_set_value(wl->power_gpio, enable);
return 0;
}
@@ -271,22 +272,33 @@ static int wl1251_spi_probe(struct spi_device *spi)
goto out_free;
}
- wl->set_power = pdata->set_power;
- if (!wl->set_power) {
- wl1251_error("set power function missing in platform data");
- return -ENODEV;
+ wl->power_gpio = pdata->power_gpio;
+
+ if (gpio_is_valid(wl->power_gpio)) {
+ ret = devm_gpio_request_one(&spi->dev, wl->power_gpio,
+ GPIOF_OUT_INIT_LOW, "wl1251 power");
+ if (ret) {
+ wl1251_error("Failed to request gpio: %d\n", ret);
+ goto out_free;
+ }
+ } else {
+ wl1251_error("set power gpio missing in platform data");
+ ret = -ENODEV;
+ goto out_free;
}
wl->irq = spi->irq;
if (wl->irq < 0) {
wl1251_error("irq missing in platform data");
- return -ENODEV;
+ ret = -ENODEV;
+ goto out_free;
}
wl->use_eeprom = pdata->use_eeprom;
irq_set_status_flags(wl->irq, IRQ_NOAUTOEN);
- ret = request_irq(wl->irq, wl1251_irq, 0, DRIVER_NAME, wl);
+ ret = devm_request_irq(&spi->dev, wl->irq, wl1251_irq, 0,
+ DRIVER_NAME, wl);
if (ret < 0) {
wl1251_error("request_irq() failed: %d", ret);
goto out_free;
@@ -296,13 +308,10 @@ static int wl1251_spi_probe(struct spi_device *spi)
ret = wl1251_init_ieee80211(wl);
if (ret)
- goto out_irq;
+ goto out_free;
return 0;
- out_irq:
- free_irq(wl->irq, wl);
-
out_free:
ieee80211_free_hw(hw);
diff --git a/drivers/net/wireless/ti/wl1251/wl1251.h b/drivers/net/wireless/ti/wl1251/wl1251.h
index fd02060..5e9808c 100644
--- a/drivers/net/wireless/ti/wl1251/wl1251.h
+++ b/drivers/net/wireless/ti/wl1251/wl1251.h
@@ -275,7 +275,7 @@ struct wl1251 {
void *if_priv;
const struct wl1251_if_operations *if_ops;
- void (*set_power)(bool enable);
+ int power_gpio;
int irq;
bool use_eeprom;
diff --git a/include/linux/wl12xx.h b/include/linux/wl12xx.h
index b516b4f..a9c723b 100644
--- a/include/linux/wl12xx.h
+++ b/include/linux/wl12xx.h
@@ -49,7 +49,7 @@ enum {
};
struct wl1251_platform_data {
- void (*set_power)(bool enable);
+ int power_gpio;
/* SDIO only: IRQ number if WLAN_IRQ line is used, 0 for SDIO IRQs */
int irq;
bool use_eeprom;
--
1.8.4.rc3
This patch adds support for requesting the regulator powering
the vio pin.
The patch also adds the regulator for the all boards using the
wl1251 in spi mode (only the Nokia N900).
Signed-off-by: Sebastian Reichel <[email protected]>
---
arch/arm/mach-omap2/board-rx51-peripherals.c | 2 ++
drivers/net/wireless/ti/wl1251/spi.c | 19 +++++++++++++++++--
drivers/net/wireless/ti/wl1251/wl1251.h | 2 ++
3 files changed, 21 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c b/arch/arm/mach-omap2/board-rx51-peripherals.c
index b9d95dd..a791fef 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -552,6 +552,8 @@ static struct regulator_consumer_supply rx51_vio_supplies[] = {
REGULATOR_SUPPLY("vio", "2-0063"),
/* lis3lv02d */
REGULATOR_SUPPLY("Vdd_IO", "3-001d"),
+ /* wl1251 */
+ REGULATOR_SUPPLY("vio", "spi4.0"),
};
static struct regulator_consumer_supply rx51_vaux1_consumers[] = {
diff --git a/drivers/net/wireless/ti/wl1251/spi.c b/drivers/net/wireless/ti/wl1251/spi.c
index 9a2df9d..efea57a 100644
--- a/drivers/net/wireless/ti/wl1251/spi.c
+++ b/drivers/net/wireless/ti/wl1251/spi.c
@@ -27,6 +27,7 @@
#include <linux/spi/spi.h>
#include <linux/wl12xx.h>
#include <linux/gpio.h>
+#include <linux/regulator/consumer.h>
#include "wl1251.h"
#include "reg.h"
@@ -306,13 +307,26 @@ static int wl1251_spi_probe(struct spi_device *spi)
irq_set_irq_type(wl->irq, IRQ_TYPE_EDGE_RISING);
- ret = wl1251_init_ieee80211(wl);
+ wl->vio = devm_regulator_get(&spi->dev, "vio");
+ if (IS_ERR(wl->vio)) {
+ ret = PTR_ERR(wl->vio);
+ wl1251_error("vio regulator missing: %d", ret);
+ goto out_free;
+ }
+
+ ret = regulator_enable(wl->vio);
if (ret)
goto out_free;
+ ret = wl1251_init_ieee80211(wl);
+ if (ret)
+ goto disable_regulator;
+
return 0;
- out_free:
+disable_regulator:
+ regulator_disable(wl->vio);
+out_free:
ieee80211_free_hw(hw);
return ret;
@@ -324,6 +338,7 @@ static int wl1251_spi_remove(struct spi_device *spi)
free_irq(wl->irq, wl);
wl1251_free_hw(wl);
+ regulator_disable(wl->vio);
return 0;
}
diff --git a/drivers/net/wireless/ti/wl1251/wl1251.h b/drivers/net/wireless/ti/wl1251/wl1251.h
index 5e9808c..010718b 100644
--- a/drivers/net/wireless/ti/wl1251/wl1251.h
+++ b/drivers/net/wireless/ti/wl1251/wl1251.h
@@ -279,6 +279,8 @@ struct wl1251 {
int irq;
bool use_eeprom;
+ struct regulator *vio;
+
spinlock_t wl_lock;
enum wl1251_state state;
--
1.8.4.rc3
Add device tree support for the spi variant of wl1251
and document the binding.
Signed-off-by: Sebastian Reichel <[email protected]>
---
.../devicetree/bindings/net/wireless/ti,wl1251.txt | 36 ++++++++++++++++++++++
drivers/net/wireless/ti/wl1251/spi.c | 23 ++++++++++----
2 files changed, 53 insertions(+), 6 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/wireless/ti,wl1251.txt
diff --git a/Documentation/devicetree/bindings/net/wireless/ti,wl1251.txt b/Documentation/devicetree/bindings/net/wireless/ti,wl1251.txt
new file mode 100644
index 0000000..5f8a154
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/wireless/ti,wl1251.txt
@@ -0,0 +1,36 @@
+* Texas Instruments wl1251 controller
+
+The wl1251 chip can be connected via SPI or via SDIO. The linux
+kernel currently only supports device tree for the SPI variant.
+
+Required properties:
+- compatible : Should be "ti,wl1251"
+- interrupts : Should contain interrupt line
+- interrupt-parent : Should be the phandle for the interrupt
+ controller that services interrupts for this device
+- vio-supply : phandle to regulator providing VIO
+- power-gpio : GPIO connected to chip's PMEN pin
+- For additional required properties on SPI, please consult
+ Documentation/devicetree/bindings/spi/spi-bus.txt
+
+Optional properties:
+- ti,use-eeprom : If found, configuration will be loaded from eeprom.
+
+Examples:
+
+&spi1 {
+ wl1251_spi@0 {
+ compatible = "ti,wl1251";
+
+ reg = <0>;
+ spi-max-frequency = <48000000>;
+ spi-cpol;
+ spi-cpha;
+
+ interrupt-parent = <&gpio2>;
+ interrupts = <10 IRQ_TYPE_NONE>; /* gpio line 42 */
+
+ vio-supply = <&vio>;
+ power-gpio = <&gpio3 23 GPIO_ACTIVE_HIGH>; /* 87 */
+ };
+};
diff --git a/drivers/net/wireless/ti/wl1251/spi.c b/drivers/net/wireless/ti/wl1251/spi.c
index efea57a..ee6ce4c 100644
--- a/drivers/net/wireless/ti/wl1251/spi.c
+++ b/drivers/net/wireless/ti/wl1251/spi.c
@@ -27,6 +27,8 @@
#include <linux/spi/spi.h>
#include <linux/wl12xx.h>
#include <linux/gpio.h>
+#include <linux/of.h>
+#include <linux/of_gpio.h>
#include <linux/regulator/consumer.h>
#include "wl1251.h"
@@ -240,13 +242,13 @@ static const struct wl1251_if_operations wl1251_spi_ops = {
static int wl1251_spi_probe(struct spi_device *spi)
{
- struct wl1251_platform_data *pdata;
+ struct wl1251_platform_data *pdata = spi->dev.platform_data;
+ struct device_node *np = spi->dev.of_node;
struct ieee80211_hw *hw;
struct wl1251 *wl;
int ret;
- pdata = spi->dev.platform_data;
- if (!pdata) {
+ if (!np && !pdata) {
wl1251_error("no platform data");
return -ENODEV;
}
@@ -273,7 +275,18 @@ static int wl1251_spi_probe(struct spi_device *spi)
goto out_free;
}
- wl->power_gpio = pdata->power_gpio;
+ if (np) {
+ wl->use_eeprom = of_property_read_bool(np, "ti,use-eeprom");
+ wl->power_gpio = of_get_named_gpio(np, "power-gpio", 0);
+ } else if (pdata) {
+ wl->power_gpio = pdata->power_gpio;
+ wl->use_eeprom = pdata->use_eeprom;
+ }
+
+ if (wl->power_gpio == -EPROBE_DEFER) {
+ ret = -EPROBE_DEFER;
+ goto out_free;
+ }
if (gpio_is_valid(wl->power_gpio)) {
ret = devm_gpio_request_one(&spi->dev, wl->power_gpio,
@@ -295,8 +308,6 @@ static int wl1251_spi_probe(struct spi_device *spi)
goto out_free;
}
- wl->use_eeprom = pdata->use_eeprom;
-
irq_set_status_flags(wl->irq, IRQ_NOAUTOEN);
ret = devm_request_irq(&spi->dev, wl->irq, wl1251_irq, 0,
DRIVER_NAME, wl);
--
1.8.4.rc3
On Sun, Oct 27, 2013 at 08:24:16PM +0400, Alexander Shiyan wrote:
> > Move the power GPIO handling from the board code into
> > the driver. This is a dependency for device tree support.
> >
> > Signed-off-by: Sebastian Reichel <[email protected]>
> > ---
> > arch/arm/mach-omap2/board-omap3pandora.c | 2 ++
> > arch/arm/mach-omap2/board-rx51-peripherals.c | 11 ++--------
> > drivers/net/wireless/ti/wl1251/sdio.c | 21 +++++++++++++-----
> > drivers/net/wireless/ti/wl1251/spi.c | 33 ++++++++++++++++++----------
> > drivers/net/wireless/ti/wl1251/wl1251.h | 2 +-
> > include/linux/wl12xx.h | 2 +-
> > 6 files changed, 43 insertions(+), 28 deletions(-)
> ...
> > diff --git a/include/linux/wl12xx.h b/include/linux/wl12xx.h
> > index b516b4f..a9c723b 100644
> > --- a/include/linux/wl12xx.h
> > +++ b/include/linux/wl12xx.h
> > @@ -49,7 +49,7 @@ enum {
> > };
> >
> > struct wl1251_platform_data {
> > - void (*set_power)(bool enable);
> > + int power_gpio;
> > /* SDIO only: IRQ number if WLAN_IRQ line is used, 0 for SDIO IRQs */
> > int irq;
> > bool use_eeprom;
> > --
>
> What a reason for not using regulator API here with GPIO-based
> regulator?
I think this pin is not used as power supply, but like an enable pin
for low power states. Of course the regulator API could still be
(mis?)used for this, but I think it would be the first linux device
driver doing this.
Note: I don't have wl1251 documentation.
-- Sebastian
On Oct 27, 2013, at 11:14 AM, Sebastian Reichel wrote:
> Add device tree support for the spi variant of wl1251
> and document the binding.
>
> Signed-off-by: Sebastian Reichel <[email protected]>
> ---
> .../devicetree/bindings/net/wireless/ti,wl1251.txt | 36 ++++++++++++++++++++++
> drivers/net/wireless/ti/wl1251/spi.c | 23 ++++++++++----
> 2 files changed, 53 insertions(+), 6 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/net/wireless/ti,wl1251.txt
>
> diff --git a/Documentation/devicetree/bindings/net/wireless/ti,wl1251.txt b/Documentation/devicetree/bindings/net/wireless/ti,wl1251.txt
> new file mode 100644
> index 0000000..5f8a154
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/wireless/ti,wl1251.txt
> @@ -0,0 +1,36 @@
> +* Texas Instruments wl1251 controller
> +
> +The wl1251 chip can be connected via SPI or via SDIO. The linux
> +kernel currently only supports device tree for the SPI variant.
> +
>From the binding I have no idea what this chip actually does, also we don't normally reference linux kernel support in bindings specs (so please remove it).
However, what would expect the SDIO binding to look like? Or more specifically, how would you distinguish the SPI vs SDIO binding/connection? I'm wondering if the compatible should be something like "ti,wl1251-spi" and than the sdio can be "ti,wl1251-sdio"
> +Required properties:
> +- compatible : Should be "ti,wl1251"
reg is not listed as a required prop.
> +- interrupts : Should contain interrupt line
> +- interrupt-parent : Should be the phandle for the interrupt
> + controller that services interrupts for this device
> +- vio-supply : phandle to regulator providing VIO
> +- power-gpio : GPIO connected to chip's PMEN pin
should be vendor prefixed: ti,power-gpio
> +- For additional required properties on SPI, please consult
> + Documentation/devicetree/bindings/spi/spi-bus.txt
> +
> +Optional properties:
> +- ti,use-eeprom : If found, configuration will be loaded from eeprom.
can you be a bit more specific on what cfg will be loaded. Also, is this property a boolean, if so how do I know which eeprom the cfg is loaded from (is it one that is directly connected to the wl1251?
> +
> +Examples:
> +
> +&spi1 {
> + wl1251_spi@0 {
> + compatible = "ti,wl1251";
> +
> + reg = <0>;
> + spi-max-frequency = <48000000>;
> + spi-cpol;
> + spi-cpha;
> +
> + interrupt-parent = <&gpio2>;
> + interrupts = <10 IRQ_TYPE_NONE>; /* gpio line 42 */
> +
> + vio-supply = <&vio>;
> + power-gpio = <&gpio3 23 GPIO_ACTIVE_HIGH>; /* 87 */
> + };
> +};
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
On Mon, Oct 28, 2013 at 8:37 AM, Kumar Gala <[email protected]> wrote:
> On Oct 27, 2013, at 11:14 AM, Sebastian Reichel wrote:
> > +++ b/Documentation/devicetree/bindings/net/wireless/ti,wl1251.txt
> > @@ -0,0 +1,36 @@
> > +* Texas Instruments wl1251 controller
> > +
> > +The wl1251 chip can be connected via SPI or via SDIO. The linux
> > +kernel currently only supports device tree for the SPI variant.
> > +
>
> From the binding I have no idea what this chip actually does, also we don't normally reference linux kernel support in bindings specs (so please remove it).
>
> However, what would expect the SDIO binding to look like? Or more specifically, how would you distinguish the SPI vs SDIO binding/connection? I'm wondering if the compatible should be something like "ti,wl1251-spi" and than the sdio can be "ti,wl1251-sdio"
When connected to SDIO, it doesn't act as standard SDIO device and
can't be probed (standard SDIO registers missing), so information has
to come some other way. That used to partially come through
platform_data and partially through a callback from mmc subsystem (see
pandora_wl1251_init_card() in
arch/arm/mach-omap2/board-omap3pandora.c). I don't know much about DT,
but maybe the information that comes from SDIO registers on "normal"
SDIO devices should come through DT in this case too? I don't really
know how that should be integrated with mmc subsystem though..
> > +Required properties:
> > +- compatible : Should be "ti,wl1251"
>
> reg is not listed as a required prop.
>
> > +- interrupts : Should contain interrupt line
> > +- interrupt-parent : Should be the phandle for the interrupt
> > + controller that services interrupts for this device
> > +- vio-supply : phandle to regulator providing VIO
> > +- power-gpio : GPIO connected to chip's PMEN pin
>
> should be vendor prefixed: ti,power-gpio
>
> > +- For additional required properties on SPI, please consult
> > + Documentation/devicetree/bindings/spi/spi-bus.txt
> > +
> > +Optional properties:
> > +- ti,use-eeprom : If found, configuration will be loaded from eeprom.
>
> can you be a bit more specific on what cfg will be loaded. Also, is this property a boolean, if so how do I know which eeprom the cfg is loaded from (is it one that is directly connected to the wl1251?
wl1251 is a wifi chip that can have an optional eeprom connected to it
to store things like calibration stuff and MAC address, and that
eeprom is usually inside a single module with some additional radio
related chips. If the eeprom is connected (like the module on pandora
board has), the driver can issue command to the firmware running on
chip to load that data on it's startup, alternatively the driver can
load calibration from other storage (like it happens on N900).
Gražvydas
On Sun, Oct 27, 2013 at 10:12 PM, Sebastian Reichel <[email protected]> wrote:
> On Sun, Oct 27, 2013 at 08:24:16PM +0400, Alexander Shiyan wrote:
>> > Move the power GPIO handling from the board code into
>> > the driver. This is a dependency for device tree support.
>> >
>> > Signed-off-by: Sebastian Reichel <[email protected]>
>> > ---
>> > arch/arm/mach-omap2/board-omap3pandora.c | 2 ++
>> > arch/arm/mach-omap2/board-rx51-peripherals.c | 11 ++--------
>> > drivers/net/wireless/ti/wl1251/sdio.c | 21 +++++++++++++-----
>> > drivers/net/wireless/ti/wl1251/spi.c | 33 ++++++++++++++++++----------
>> > drivers/net/wireless/ti/wl1251/wl1251.h | 2 +-
>> > include/linux/wl12xx.h | 2 +-
>> > 6 files changed, 43 insertions(+), 28 deletions(-)
>> ...
>> > diff --git a/include/linux/wl12xx.h b/include/linux/wl12xx.h
>> > index b516b4f..a9c723b 100644
>> > --- a/include/linux/wl12xx.h
>> > +++ b/include/linux/wl12xx.h
>> > @@ -49,7 +49,7 @@ enum {
>> > };
>> >
>> > struct wl1251_platform_data {
>> > - void (*set_power)(bool enable);
>> > + int power_gpio;
>> > /* SDIO only: IRQ number if WLAN_IRQ line is used, 0 for SDIO IRQs */
>> > int irq;
>> > bool use_eeprom;
>> > --
>>
>> What a reason for not using regulator API here with GPIO-based
>> regulator?
>
> I think this pin is not used as power supply, but like an enable pin
> for low power states. Of course the regulator API could still be
> (mis?)used for this, but I think it would be the first linux device
> driver doing this.
>
> Note: I don't have wl1251 documentation.
When wl12xx family of chips is connected through SDIO, we already have
that pin set up as a regulator controlled with the help of mmc
subsystem. When time comes to communicate with the chip, mmc subsystem
sees this as yet another SD card and looks for associated regulator
for it, and the board file has that set up as a fixed regulator
controlling that pin (see pandora_vmmc3 in
arch/arm/mach-omap2/board-omap3pandora.c). To prevent poweroff after
first SDIO communications are over, pm_runtime calls are used in
drivers/net/wireless/ti/wl1251/sdio.c .
I don't know if something similar can be done done in SPI case, but
I'm sure this is not the first your-so-called regulator misuse.
Gražvydas
On Mon, Oct 28, 2013 at 07:29:52PM +0200, Grazvydas Ignotas wrote:
> When wl12xx family of chips is connected through SDIO, we already have
> that pin set up as a regulator controlled with the help of mmc
> subsystem. When time comes to communicate with the chip, mmc subsystem
> sees this as yet another SD card and looks for associated regulator
> for it, and the board file has that set up as a fixed regulator
> controlling that pin (see pandora_vmmc3 in
> arch/arm/mach-omap2/board-omap3pandora.c). To prevent poweroff after
> first SDIO communications are over, pm_runtime calls are used in
> drivers/net/wireless/ti/wl1251/sdio.c .
Is this actually controlling VMMC though, or is it some other control?
If it's not controlling VMMC then it shouldn't say that it is.
> I don't know if something similar can be done done in SPI case, but
> I'm sure this is not the first your-so-called regulator misuse.
It's not the first but that doesn't make controlling something other
than a regulator through the regulator API any less broken.
On Oct 28, 2013, at 12:15 PM, Grazvydas Ignotas wrote:
> On Mon, Oct 28, 2013 at 8:37 AM, Kumar Gala <[email protected]> wrote:
>> On Oct 27, 2013, at 11:14 AM, Sebastian Reichel wrote:
>>> +++ b/Documentation/devicetree/bindings/net/wireless/ti,wl1251.txt
>>> @@ -0,0 +1,36 @@
>>> +* Texas Instruments wl1251 controller
>>> +
>>> +The wl1251 chip can be connected via SPI or via SDIO. The linux
>>> +kernel currently only supports device tree for the SPI variant.
>>> +
>>
>> From the binding I have no idea what this chip actually does, also we don't normally reference linux kernel support in bindings specs (so please remove it).
>>
>> However, what would expect the SDIO binding to look like? Or more specifically, how would you distinguish the SPI vs SDIO binding/connection? I'm wondering if the compatible should be something like "ti,wl1251-spi" and than the sdio can be "ti,wl1251-sdio"
>
> When connected to SDIO, it doesn't act as standard SDIO device and
> can't be probed (standard SDIO registers missing), so information has
> to come some other way. That used to partially come through
> platform_data and partially through a callback from mmc subsystem (see
> pandora_wl1251_init_card() in
> arch/arm/mach-omap2/board-omap3pandora.c). I don't know much about DT,
> but maybe the information that comes from SDIO registers on "normal"
> SDIO devices should come through DT in this case too? I don't really
> know how that should be integrated with mmc subsystem though..
Ok, my point is still valid that we can use a different compatible for the SDIO case even if its no standard SDIO vs the SPI case.
>
>>> +Required properties:
>>> +- compatible : Should be "ti,wl1251"
>>
>> reg is not listed as a required prop.
>>
>>> +- interrupts : Should contain interrupt line
>>> +- interrupt-parent : Should be the phandle for the interrupt
>>> + controller that services interrupts for this device
>>> +- vio-supply : phandle to regulator providing VIO
>>> +- power-gpio : GPIO connected to chip's PMEN pin
>>
>> should be vendor prefixed: ti,power-gpio
>>
>>> +- For additional required properties on SPI, please consult
>>> + Documentation/devicetree/bindings/spi/spi-bus.txt
>>> +
>>> +Optional properties:
>>> +- ti,use-eeprom : If found, configuration will be loaded from eeprom.
>>
>> can you be a bit more specific on what cfg will be loaded. Also, is this property a boolean, if so how do I know which eeprom the cfg is loaded from (is it one that is directly connected to the wl1251?
>
> wl1251 is a wifi chip that can have an optional eeprom connected to it
> to store things like calibration stuff and MAC address, and that
> eeprom is usually inside a single module with some additional radio
> related chips. If the eeprom is connected (like the module on pandora
> board has), the driver can issue command to the firmware running on
> chip to load that data on it's startup, alternatively the driver can
> load calibration from other storage (like it happens on N900).
So sounds like a boolean. I think just adding that its a boolean and maybe something like "configuration (calibration data, MAC addr, etc..)"
- k
>
>
> Gra?vydas
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
On Monday 28 of October 2013 01:37:34 Kumar Gala wrote:
> On Oct 27, 2013, at 11:14 AM, Sebastian Reichel wrote:
> > Add device tree support for the spi variant of wl1251
> > and document the binding.
> >
> > Signed-off-by: Sebastian Reichel <[email protected]>
> > ---
> > .../devicetree/bindings/net/wireless/ti,wl1251.txt | 36
> > ++++++++++++++++++++++ drivers/net/wireless/ti/wl1251/spi.c
> > | 23 ++++++++++---- 2 files changed, 53 insertions(+), 6
> > deletions(-)
> > create mode 100644
> > Documentation/devicetree/bindings/net/wireless/ti,wl1251.txt
> >
> > diff --git
> > a/Documentation/devicetree/bindings/net/wireless/ti,wl1251.txt
> > b/Documentation/devicetree/bindings/net/wireless/ti,wl1251.txt new
> > file mode 100644
> > index 0000000..5f8a154
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/net/wireless/ti,wl1251.txt
> > @@ -0,0 +1,36 @@
> > +* Texas Instruments wl1251 controller
> > +
> > +The wl1251 chip can be connected via SPI or via SDIO. The linux
> > +kernel currently only supports device tree for the SPI variant.
> > +
>
> From the binding I have no idea what this chip actually does, also we
> don't normally reference linux kernel support in bindings specs (so
> please remove it).
>
> However, what would expect the SDIO binding to look like? Or more
> specifically, how would you distinguish the SPI vs SDIO
> binding/connection? I'm wondering if the compatible should be
> something like "ti,wl1251-spi" and than the sdio can be
> "ti,wl1251-sdio"
Well, you can easily distinguish an SDIO device from an SPI device by its
parent node, but...
The binding for SDIO might require different set of properties (other than
ones inherited from generic SDIO or SPI bindings) than one for SPI. So
probably different compatible values might be justified.
Did we already have such case before? (maybe some I2C + SPI devices?)
> > +Required properties:
> > +- compatible : Should be "ti,wl1251"
>
> reg is not listed as a required prop.
It is implied by SPI bindings, but it might be a good idea to have this
stated here as well.
>
> > +- interrupts : Should contain interrupt line
> > +- interrupt-parent : Should be the phandle for the interrupt
> > + controller that services interrupts for this device
> > +- vio-supply : phandle to regulator providing VIO
> > +- power-gpio : GPIO connected to chip's PMEN pin
>
> should be vendor prefixed: ti,power-gpio
Hmm, out of curiosity, is it a rule for this kind of properties? I can see
both cases with and without prefixes when grepping for "-gpios" in
Documentation/devicetree/bindings. We should really have such things
written down somewhere.
>
> > +- For additional required properties on SPI, please consult
> > + Documentation/devicetree/bindings/spi/spi-bus.txt
> > +
> > +Optional properties:
> > +- ti,use-eeprom : If found, configuration will be loaded from eeprom.
>
> can you be a bit more specific on what cfg will be loaded. Also, is
> this property a boolean, if so how do I know which eeprom the cfg is
> loaded from (is it one that is directly connected to the wl1251?
Maybe one from ti,has-eeprom or ti,config-eeprom would be better name for
this property?
Best regards,
Tomasz
Hi,
On Mon, Oct 28, 2013 at 12:23:54PM -0700, Mark Brown wrote:
> On Mon, Oct 28, 2013 at 07:29:52PM +0200, Grazvydas Ignotas wrote:
>
> > When wl12xx family of chips is connected through SDIO, we already have
> > that pin set up as a regulator controlled with the help of mmc
> > subsystem. When time comes to communicate with the chip, mmc subsystem
> > sees this as yet another SD card and looks for associated regulator
> > for it, and the board file has that set up as a fixed regulator
> > controlling that pin (see pandora_vmmc3 in
> > arch/arm/mach-omap2/board-omap3pandora.c). To prevent poweroff after
> > first SDIO communications are over, pm_runtime calls are used in
> > drivers/net/wireless/ti/wl1251/sdio.c .
>
> Is this actually controlling VMMC though, or is it some other control?
> If it's not controlling VMMC then it shouldn't say that it is.
>
> > I don't know if something similar can be done done in SPI case, but
> > I'm sure this is not the first your-so-called regulator misuse.
>
> It's not the first but that doesn't make controlling something other
> than a regulator through the regulator API any less broken.
I gave it a second try to find out details for this pin:
1. The pin is named PMEN in the Nokia N900 schematics
2. PMEN is described as "Power management enable - system shutdown"
in a crippled datasheet of the wl1253, which I found in the internet.
I don't think this is supposed to be handled by the regulator API.
-- Sebastian
On Tue, Oct 29, 2013 at 12:26:26AM +0100, Sebastian Reichel wrote:
> 1. The pin is named PMEN in the Nokia N900 schematics
> 2. PMEN is described as "Power management enable - system shutdown"
> in a crippled datasheet of the wl1253, which I found in the internet.
> I don't think this is supposed to be handled by the regulator API.
I agree, this sounds like a GPIO that the driver should be understanding
directly to me.
On Oct 28, 2013, at 5:38 PM, Tomasz Figa wrote:
> On Monday 28 of October 2013 01:37:34 Kumar Gala wrote:
>> On Oct 27, 2013, at 11:14 AM, Sebastian Reichel wrote:
>>> Add device tree support for the spi variant of wl1251
>>> and document the binding.
>>>
>>> Signed-off-by: Sebastian Reichel <[email protected]>
>>> ---
>>> .../devicetree/bindings/net/wireless/ti,wl1251.txt | 36
>>> ++++++++++++++++++++++ drivers/net/wireless/ti/wl1251/spi.c
>>> | 23 ++++++++++---- 2 files changed, 53 insertions(+), 6
>>> deletions(-)
>>> create mode 100644
>>> Documentation/devicetree/bindings/net/wireless/ti,wl1251.txt
>>>
>>> diff --git
>>> a/Documentation/devicetree/bindings/net/wireless/ti,wl1251.txt
>>> b/Documentation/devicetree/bindings/net/wireless/ti,wl1251.txt new
>>> file mode 100644
>>> index 0000000..5f8a154
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/net/wireless/ti,wl1251.txt
>>> @@ -0,0 +1,36 @@
>>> +* Texas Instruments wl1251 controller
>>> +
>>> +The wl1251 chip can be connected via SPI or via SDIO. The linux
>>> +kernel currently only supports device tree for the SPI variant.
>>> +
>>
>> From the binding I have no idea what this chip actually does, also we
>> don't normally reference linux kernel support in bindings specs (so
>> please remove it).
>>
>> However, what would expect the SDIO binding to look like? Or more
>> specifically, how would you distinguish the SPI vs SDIO
>> binding/connection? I'm wondering if the compatible should be
>> something like "ti,wl1251-spi" and than the sdio can be
>> "ti,wl1251-sdio"
>
> Well, you can easily distinguish an SDIO device from an SPI device by its
> parent node, but...
>
> The binding for SDIO might require different set of properties (other than
> ones inherited from generic SDIO or SPI bindings) than one for SPI. So
> probably different compatible values might be justified.
>
> Did we already have such case before? (maybe some I2C + SPI devices?)
>
>>> +Required properties:
>>> +- compatible : Should be "ti,wl1251"
>>
>> reg is not listed as a required prop.
>
> It is implied by SPI bindings, but it might be a good idea to have this
> stated here as well.
>
>>
>>> +- interrupts : Should contain interrupt line
>>> +- interrupt-parent : Should be the phandle for the interrupt
>>> + controller that services interrupts for this device
>>> +- vio-supply : phandle to regulator providing VIO
>>> +- power-gpio : GPIO connected to chip's PMEN pin
>>
>> should be vendor prefixed: ti,power-gpio
>
> Hmm, out of curiosity, is it a rule for this kind of properties? I can see
> both cases with and without prefixes when grepping for "-gpios" in
> Documentation/devicetree/bindings. We should really have such things
> written down somewhere.
Agreed, it should be part of the various docs we are suppose to produce for review and binding creation guidelines.
>>> +- For additional required properties on SPI, please consult
>>> + Documentation/devicetree/bindings/spi/spi-bus.txt
>>> +
>>> +Optional properties:
>>> +- ti,use-eeprom : If found, configuration will be loaded from eeprom.
>>
>> can you be a bit more specific on what cfg will be loaded. Also, is
>> this property a boolean, if so how do I know which eeprom the cfg is
>> loaded from (is it one that is directly connected to the wl1251?
>
> Maybe one from ti,has-eeprom or ti,config-eeprom would be better name for
> this property?
Probably, ti,wl1251-has-eeprom or something like that would be better. However, I'm not going to get too caught up on names of properties.
- k
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation