[PATCH v3 7/9] omap: zoom: add fixed regulator device for wlan
Add a fixed regulator vmmc device to enable power control
of the wl1271 wlan device.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
arch/arm/mach-omap2/board-zoom-peripherals.c | 35 ++
1 files changed, 35 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-zoom-peripherals.c
b/arch/arm/mach-omap2/board-zoom-peripherals.c
index 6b39849..de88635 100644
--- a/arch/arm/mach-omap2/board-zoom-peripherals.c
+++ b/arch/arm/mach-omap2/board-zoom-peripherals.c
@@ -16,6 +16,7 @@
#include linux/gpio.h
#include linux/i2c/twl.h
#include linux/regulator/machine.h
+#include linux/regulator/fixed.h
#include asm/mach-types.h
#include asm/mach/arch.h
@@ -27,6 +28,8 @@
#include mux.h
#include hsmmc.h
+#define OMAP_ZOOM_WLAN_PMENA_GPIO (101)
+
/* Zoom2 has Qwerty keyboard*/
static int board_keymap[] = {
KEY(0, 0, KEY_E),
@@ -106,6 +109,11 @@ static struct regulator_consumer_supply zoom_vmmc2_supply
= {
.supply = vmmc,
};
+static struct regulator_consumer_supply zoom_vmmc3_supply = {
+ .supply = vmmc,
+ .dev_name = mmci-omap-hs.2,
+};
+
/* VMMC1 for OMAP VDD_MMC1 (i/o) and MMC1 card */
static struct regulator_init_data zoom_vmmc1 = {
.constraints = {
@@ -151,6 +159,32 @@ static struct regulator_init_data zoom_vsim = {
.consumer_supplies = zoom_vsim_supply,
};
+static struct regulator_init_data zoom_vmmc3 = {
+ .constraints = {
+ .valid_ops_mask = REGULATOR_CHANGE_STATUS,
+ },
+ .num_consumer_supplies = 1,
+ .consumer_supplies = zoom_vmmc3_supply,
+};
+
+static struct fixed_voltage_config zoom_vwlan = {
+ .supply_name = vwl1271,
+ .microvolts = 180, /* 1.8V */
+ .gpio = OMAP_ZOOM_WLAN_PMENA_GPIO,
+ .startup_delay = 7, /* 70msec */
+ .enable_high = 1,
+ .enabled_at_boot = 0,
+ .init_data = zoom_vmmc3,
+};
+
+static struct platform_device omap_vwlan_device = {
+ .name = reg-fixed-voltage,
+ .id = 1,
+ .dev = {
+ .platform_data = zoom_vwlan,
+ },
+};
+
static struct omap2_hsmmc_info mmc[] __initdata = {
{
.name = external,
@@ -280,6 +314,7 @@ static void enable_board_wakeup_source(void)
void __init zoom_peripherals_init(void)
{
omap_i2c_init();
+ platform_device_register(omap_vwlan_device);
usb_musb_init(musb_board_data);
enable_board_wakeup_source();
}
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 8/9] omap: hsmmc: split mmc23 power control
Prepare for mmc3 regulator power control by splitting the power
control functions of mmc2 and mmc3, and expecting mmc3 to have
a single, dedicated, regulator support.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
arch/arm/mach-omap2/hsmmc.c | 10 --
drivers/mmc/host/omap_hsmmc.c | 67
2 files changed, 66 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-omap2/hsmmc.c b/arch/arm/mach-omap2/hsmmc.c
index 1ef54b0..5d3d789 100644
--- a/arch/arm/mach-omap2/hsmmc.c
+++ b/arch/arm/mach-omap2/hsmmc.c
@@ -174,7 +174,7 @@ static void omap4_hsmmc1_after_set_reg(struct device *dev,
int slot,
}
}
-static void hsmmc23_before_set_reg(struct device *dev, int slot,
+static void hsmmc2_before_set_reg(struct device *dev, int slot,
int power_on, int vdd)
{
struct omap_mmc_platform_data *mmc = dev-platform_data;
@@ -325,14 +325,16 @@ void __init omap2_hsmmc_init(struct omap2_hsmmc_info
*controllers)
c-transceiver = 1;
if (c-transceiver c-wires 4)
c-wires = 4;
- /* FALLTHROUGH */
- case 3:
if (mmc-slots[0].features HSMMC_HAS_PBIAS) {
/* off-chip level shifting, or none */
- mmc-slots[0].before_set_reg =
hsmmc23_before_set_reg;
+ mmc-slots[0].before_set_reg =
hsmmc2_before_set_reg;
mmc-slots[0].after_set_reg = NULL;
}
break;
+ case 3:
+ mmc-slots[0].before_set_reg = NULL;
+ mmc-slots[0].after_set_reg = NULL;
+ break;
default:
pr_err(MMC%d configuration not supported!\n, c-mmc);
kfree(mmc);
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index d50e917..6f5cea0 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -258,7 +258,7 @@ static int omap_hsmmc_1_set_power(struct device *dev, int
slot, int power_on,
return ret;
}
-static int omap_hsmmc_23_set_power(struct device *dev, int slot, int power_on,
+static int omap_hsmmc_2_set_power(struct device *dev, int slot, int power_on,
int vdd)
{
struct omap_hsmmc_host *host =
@@ -309,6 +309,31 @@ static int omap_hsmmc_23_set_power(struct device *dev, int
slot, int power_on,
return ret;
}
+static int omap_hsmmc_3_set_power(struct device *dev, int slot, int power_on,
+ int vdd)
+{
+ struct omap_hsmmc_host *host =
+ platform_get_drvdata(to_platform_device(dev));
+ int ret = 0;
+
+ if (power_on) {
+ ret = mmc_regulator_set_ocr(host-vcc, vdd);
+ /* Enable interface voltage rail, if needed */
+ if (ret == 0 host-vcc) {
+ ret = regulator_enable(host-vcc);
+ if (ret 0)
+ ret = mmc_regulator_set_ocr(host-vcc, 0);
+ }
+ } else {
+ if (host-vcc)
+ ret = regulator_disable(host-vcc);
+ if (ret == 0)
+ ret = mmc_regulator_set_ocr(host-vcc, 0);
+ }
+
+ return ret;
+}
+
static int omap_hsmmc_1_set_sleep(struct device *dev, int slot, int sleep,
int vdd, int cardsleep)
{
@@ -319,7 +344,7 @@ static int omap_hsmmc_1_set_sleep(struct device *dev, int
slot, int sleep,
return regulator_set_mode(host-vcc, mode);
}
-static int omap_hsmmc_23_set_sleep(struct device *dev, int slot, int sleep,
+static int omap_hsmmc_2_set_sleep(struct device *dev, int slot, int sleep,
int vdd, int cardsleep)
{
struct omap_hsmmc_host *host =
@@ -358,6 +383,31 @@ static int omap_hsmmc_23_set_sleep(struct device *dev, int
slot, int sleep,
return regulator_enable(host-vcc_aux);
}
+static int omap_hsmmc_3_set_sleep(struct device *dev, int slot, int sleep,
+ int vdd, int cardsleep)
+{
+ struct omap_hsmmc_host *host =
+ platform_get_drvdata(to_platform_device(dev));
+ int err = 0;
+
+ /*
+* If we don't see a Vcc regulator, assume it's a fixed
+* voltage always-on regulator.
+*/
+ if (!host-vcc)
+ return 0;
+
+ if (cardsleep) {
+ /* VCC can be turned off if card is asleep */
+ if (sleep)
+ err = mmc_regulator_set_ocr(host-vcc, 0);
+ else
+ err = mmc_regulator_set_ocr(host-vcc, vdd);
+ }
+
+ return err;
+}
+
static int omap_hsmmc_reg_get
[PATCH v3 9/9] omap: zoom: add mmc3/wl1271 device support
Add MMC3 support on ZOOM, which has the wl1271 device hardwired to.
The wl1271 is a 4-wire, 1.8V, embedded SDIO WLAN device with an
external IRQ line, and power-controlled by a GPIO-based fixed regulator.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
arch/arm/mach-omap2/board-zoom-peripherals.c | 34 ++
1 files changed, 34 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-zoom-peripherals.c
b/arch/arm/mach-omap2/board-zoom-peripherals.c
index de88635..82776bc 100644
--- a/arch/arm/mach-omap2/board-zoom-peripherals.c
+++ b/arch/arm/mach-omap2/board-zoom-peripherals.c
@@ -17,6 +17,8 @@
#include linux/i2c/twl.h
#include linux/regulator/machine.h
#include linux/regulator/fixed.h
+#include linux/mmc/host.h
+#include linux/wl12xx.h
#include asm/mach-types.h
#include asm/mach/arch.h
@@ -29,6 +31,7 @@
#include hsmmc.h
#define OMAP_ZOOM_WLAN_PMENA_GPIO (101)
+#define OMAP_ZOOM_WLAN_IRQ_GPIO(162)
/* Zoom2 has Qwerty keyboard*/
static int board_keymap[] = {
@@ -185,6 +188,28 @@ static struct platform_device omap_vwlan_device = {
},
};
+struct wl12xx_platform_data omap_zoom_wlan_data = {
+ /* ZOOM ref clock is 26 MHz */
+ .board_ref_clock = 1,
+};
+
+static struct resource omap_zoom_wl1271_resources[] = {
+ {
+ .start = OMAP_GPIO_IRQ(OMAP_ZOOM_WLAN_IRQ_GPIO),
+ .end = OMAP_GPIO_IRQ(OMAP_ZOOM_WLAN_IRQ_GPIO),
+ .flags = IORESOURCE_IRQ,
+ }
+};
+static struct platform_device omap_zoom_wl1271 = {
+ .name = wl1271_plat.2,
+ .id = -1,
+ .resource = omap_zoom_wl1271_resources,
+ .num_resources = ARRAY_SIZE(omap_zoom_wl1271_resources),
+ .dev = {
+ .platform_data = omap_zoom_wlan_data,
+ },
+};
+
static struct omap2_hsmmc_info mmc[] __initdata = {
{
.name = external,
@@ -202,6 +227,14 @@ static struct omap2_hsmmc_info mmc[] __initdata = {
.nonremovable = true,
.power_saving = true,
},
+ {
+ .name = wl1271,
+ .mmc= 3,
+ .wires = 4,
+ .gpio_wp= -EINVAL,
+ .gpio_cd= -EINVAL,
+ .ocr_mask = MMC_VDD_165_195,
+ },
{} /* Terminator */
};
@@ -313,6 +346,7 @@ static void enable_board_wakeup_source(void)
void __init zoom_peripherals_init(void)
{
+ platform_device_register(omap_zoom_wl1271);
omap_i2c_init();
platform_device_register(omap_vwlan_device);
usb_musb_init(musb_board_data);
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 3/9] wireless: wl1271: add platform driver to get board data
Dynamically create and register a platform driver, that will
be used to to receive board-specific information like irq and
reference clock numbers.
The driver is created dynamically in order to avoid the 1-device
limitation of a fixed platform driver name.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
drivers/net/wireless/wl12xx/wl1271.h | 12
drivers/net/wireless/wl12xx/wl1271_sdio.c | 103 +++--
2 files changed, 108 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wireless/wl12xx/wl1271.h
b/drivers/net/wireless/wl12xx/wl1271.h
index faa5925..013eabb 100644
--- a/drivers/net/wireless/wl12xx/wl1271.h
+++ b/drivers/net/wireless/wl12xx/wl1271.h
@@ -31,6 +31,7 @@
#include linux/list.h
#include linux/bitops.h
#include net/mac80211.h
+#include linux/platform_device.h
#include wl1271_conf.h
#include wl1271_ini.h
@@ -319,8 +320,19 @@ struct wl1271_if_operations {
void (*disable_irq)(struct wl1271 *wl);
};
+/* exact size needed for wl1271_plat.x */
+#define WL12XX_PLAT_NAME_LEN 14
+
+struct wl12xx_plat_instance {
+ struct platform_driver pdriver;
+ char name[WL12XX_PLAT_NAME_LEN];
+ struct wl12xx_platform_data *pdata;
+ struct completion data_ready;
+};
+
struct wl1271 {
struct platform_device *plat_dev;
+ struct wl12xx_plat_instance *pinstance;
struct ieee80211_hw *hw;
bool mac80211_registered;
diff --git a/drivers/net/wireless/wl12xx/wl1271_sdio.c
b/drivers/net/wireless/wl12xx/wl1271_sdio.c
index c41293a..5b43626 100644
--- a/drivers/net/wireless/wl12xx/wl1271_sdio.c
+++ b/drivers/net/wireless/wl12xx/wl1271_sdio.c
@@ -28,7 +28,11 @@
#include linux/mmc/sdio_func.h
#include linux/mmc/sdio_ids.h
#include linux/mmc/card.h
+#include linux/mmc/host.h
+#include linux/wl12xx.h
#include linux/gpio.h
+#include linux/platform_device.h
+#include linux/completion.h
#include wl1271.h
#include wl12xx_80211.h
@@ -182,10 +186,84 @@ static struct wl1271_if_operations sdio_ops = {
.disable_irq= wl1271_sdio_disable_interrupts
};
+static int wl1271_plat_probe(struct platform_device *pdev)
+{
+ struct wl12xx_platform_data *pdata;
+ struct platform_driver *pdriver;
+ struct wl12xx_plat_instance *pinstance;
+
+ pdata = pdev-dev.platform_data;
+ if (!pdata) {
+ wl1271_error(no platform data);
+ return -ENODEV;
+ }
+
+ pdriver = container_of(pdev-dev.driver, struct platform_driver,
+ driver);
+ pinstance = container_of(pdriver, struct wl12xx_plat_instance, pdriver);
+
+ pinstance-pdata = pdata;
+
+ complete(pinstance-data_ready);
+
+ return 0;
+}
+
+static struct wl12xx_platform_data *wl1271_get_data(struct wl1271 *wl, int id)
+{
+ int ret;
+ struct wl12xx_plat_instance *pinstance;
+
+ #define WL1271_PLAT_NAME wl1271_plat.%d
+
+ pinstance = kzalloc(sizeof(*pinstance), GFP_KERNEL);
+ if (!pinstance)
+ return ERR_PTR(-ENOMEM);
+
+ init_completion(pinstance-data_ready);
+
+ pinstance-pdriver.probe = wl1271_plat_probe;
+
+ ret = snprintf(pinstance-name, ARRAY_SIZE(pinstance-name),
+ WL1271_PLAT_NAME, id);
+ if (ret = WL12XX_PLAT_NAME_LEN) {
+ wl1271_error(truncated plat drv name\n);
+ goto out_free;
+ }
+
+ pinstance-pdriver.driver.name = pinstance-name;
+ pinstance-pdriver.driver.owner = THIS_MODULE;
+
+ ret = platform_driver_register(pinstance-pdriver);
+ if (ret 0) {
+ wl1271_error(failed to register plat driver: %d, ret);
+ goto out_free;
+ }
+
+ ret = wait_for_completion_interruptible_timeout(pinstance-data_ready,
+ msecs_to_jiffies(15000));
+ if (ret = 0) {
+ wl1271_error(can't get platform device (%d), ret);
+ ret = (ret == 0 ? -EAGAIN : ret);
+ goto unreg;
+ }
+
+ wl-pinstance = pinstance;
+
+ return pinstance-pdata;
+
+unreg:
+ platform_driver_unregister(pinstance-pdriver);
+out_free:
+ kfree(pinstance);
+ return ERR_PTR(ret);
+}
+
static int __devinit wl1271_probe(struct sdio_func *func,
const struct sdio_device_id *id)
{
struct ieee80211_hw *hw;
+ struct wl12xx_platform_data *wlan_data;
struct wl1271 *wl;
int ret;
@@ -205,17 +283,24 @@ static int __devinit wl1271_probe(struct sdio_func *func,
/* Grab access to FN0 for ELP reg. */
func-card-quirks |= MMC_QUIRK_LENIENT_FN0;
+ wlan_data = wl1271_get_data(wl, func-card-host-index);
+ if (IS_ERR(wlan_data)) {
+ ret = PTR_ERR(wlan_data);
+ wl1271_error(missing wlan data (needed for irq/ref_clk)!);
+ goto
Re: [PATCH v2 03/20] mmc: support embedded data field in mmc_host
On Fri, Aug 6, 2010 at 10:07 AM, Linus Walleij
linus.ml.wall...@gmail.com wrote:
2010/8/4 Ohad Ben-Cohen o...@wizery.com:
On Wed, Aug 4, 2010 at 2:41 PM, Russell King - ARM Linux
Why not arrange for a small piece of code to be built into the kernel
when this driver is selected as a module or built-in, which handles
the passing of platform data to the driver?
It's interesting.
The only drawback I can see is that it has an inherent limitation of
having only a single wl1271 device on board,
...which is exactly what the *_board_info scheme in the spi
and i2c subsystems is designed to solve.
This is an established design pattern in the kernel with two
precedents, what makes it so hard to implement this idea?
There are plenty of examples all over the place.
How would a driver ask for the platform data of its specific device ?
Using DEVICE_ID and VENDOR_ID is wrong - those numbers do not identify
a specific device instance (think of a board with two wl1271 devices.
the only difference between them is the index of their mmc
controller).
The only sane way to uniquely identify a specific device instance is
to couple its platform data with the host controller the device is
hardwired to.
So if we want to have an external sdio_board_info table to work, it
would have to map a controller index to sdio_board_info objects.
Something in the lines of:
int sdio_get_platform_data(struct sdio_board_info *data, struct sdio_func *func)
{
if (platform_data[func-card-host-index]) {
memcpy(data, platform_data[func-card-host-index],
sizeof(*data));
return 0;
}
return -ENODEV;
}
typechecking is not preserved (the driver would have to cast
data-platform_data), and there is a possibility for the wrong driver
to pick up the data (at least as much as there was with the original
proposal).
AFAICS, the difference between SDIO and I2C/SPI in that respect, is
that SDIO devices are created dynamically when hardware is probed,
whereas I2C/SPI uses the *_board_info table to populate the device
tree. The I2C/SPI drivers then elegantly get the platform data in the
probe call. In our case, the device is created dynamically, and the
only way to couple it with the correct platform data is using the
knowledge that it is hardwired to a specific host controller.
So using an external repository of platform data objects seem to have
similar disadvantages like the original proposal, but with much more
code.
We have Russell's suggestion which is nice and simple, but it has the
1 device limitation.
Or, we can go back to the approach of creating another platform device
for that chip. That device's name should be wl1271.x where x is the
index of the controller the device is hardwired to. Later, when the
SDIO function probe is invoked, it would register the platform driver
(after dynamically sprintf()ing the name using the
func-card-host-index number), and then
wait_for_completion_interruptible_timeout() for it to probe.
That seem to settle all the concerns raised: we get typechecking, no
wrong driver getting the data, no 1 device limit, no races between the
two probes.
Thanks,
Ohad.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 03/20] mmc: support embedded data field in mmc_host
Hi Vitaly,
On Tue, Aug 3, 2010 at 5:17 PM, Vitaly Wool vitalyw...@gmail.com wrote:
On Mon, Aug 2, 2010 at 11:35 PM, Ohad Ben-Cohen o...@wizery.com wrote:
I'm honestly trying to understand your concerns, but I'm afraid that
just saying it's a hack is not too informative. Can you please
explain what do you think is technically wrong with the proposed
solution ? is it not general enough for other use cases ? will it
break something ?
So if I'd like to set the *same* structure for the *same* WL1271
driver, provided that I'm working with the other platform, I'll need
to do the following:
- add the pointer to the board-specific header;
- add the structure to the board-specific C file and propagate its
pointer to the controller driver;
- add setting the pointer in the core structure into the controller driver.
This is far from being intuitive. This means we need to hack,
generally speaking, all the MMC controller drivers to get it working
on all platforms. This is error prone.
You make it sound really complex.
Let's see what it means to add it to a totally different platform.
As an example, let's take Google's ADP1 which is based on a different
host controller (msm-sdcc), and add the required support (untested of
course, just a quick sketch, patch is based on android's msm git):
diff --git a/arch/arm/mach-msm/board-trout-mmc.c b/arch/arm/mach-msm/board-trout
index 13755f5..df32b2f 100644
--- a/arch/arm/mach-msm/board-trout-mmc.c
+++ b/arch/arm/mach-msm/board-trout-mmc.c
@@ -10,6 +10,7 @@
#include linux/mmc/sdio_ids.h
#include linux/err.h
#include linux/debugfs.h
+#include linux/wl12xx.h
#include asm/gpio.h
#include asm/io.h
@@ -297,11 +298,16 @@ int trout_wifi_reset(int on)
EXPORT_SYMBOL(trout_wifi_reset);
#endif
+struct wl12xx_platform_data trout_wlan_data = {
+ .irq = 62, /* put here your irq number */
+ .board_ref_clock = 1, /* put here your ref clock */
+};
+
static struct mmc_platform_data trout_wifi_data = {
.ocr_mask = MMC_VDD_28_29,
.status = trout_wifi_status,
.register_status_notify = trout_wifi_status_register,
- .embedded_sdio = trout_wifi_emb_data,
+ .embedded_sdio = trout_wlan_data,
};
int __init trout_init_mmc(unsigned int sys_rev)
diff --git a/drivers/mmc/host/msm_sdcc.c b/drivers/mmc/host/msm_sdcc.c
index 1697d42..c40f0d1 100755
--- a/drivers/mmc/host/msm_sdcc.c
+++ b/drivers/mmc/host/msm_sdcc.c
@@ -1261,6 +1261,7 @@ msmsdcc_probe(struct platform_device *pdev)
mmc-f_min = msmsdcc_fmin;
mmc-f_max = msmsdcc_fmax;
mmc-ocr_avail = plat-ocr_mask;
+mmc_set_embedded_data(mmc, plat-embedded_sdio);
if (msmsdcc_4bit)
mmc-caps |= MMC_CAP_4_BIT_DATA;
Is it really that complex ?
Thanks,
Ohad.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 03/20] mmc: support embedded data field in mmc_host
On Wed, Aug 4, 2010 at 2:41 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Wed, Aug 04, 2010 at 02:24:39PM +0300, Ohad Ben-Cohen wrote:
On Tue, Aug 3, 2010 at 5:17 PM, Vitaly Wool vitalyw...@gmail.com wrote:
On Mon, Aug 2, 2010 at 11:35 PM, Ohad Ben-Cohen o...@wizery.com wrote:
I'm honestly trying to understand your concerns, but I'm afraid that
just saying it's a hack is not too informative. Can you please
explain what do you think is technically wrong with the proposed
solution ? is it not general enough for other use cases ? will it
break something ?
So if I'd like to set the *same* structure for the *same* WL1271
driver, provided that I'm working with the other platform, I'll need
to do the following:
- add the pointer to the board-specific header;
- add the structure to the board-specific C file and propagate its
pointer to the controller driver;
- add setting the pointer in the core structure into the controller driver.
This is far from being intuitive. This means we need to hack,
generally speaking, all the MMC controller drivers to get it working
on all platforms. This is error prone.
You make it sound really complex.
Let's see what it means to add it to a totally different platform.
As an example, let's take Google's ADP1 which is based on a different
host controller (msm-sdcc), and add the required support (untested of
course, just a quick sketch, patch is based on android's msm git):
What if some other driver gets attached and tries to use this
platform data? This whole idea sounds extremely silly, cumbersome,
error prone, and is inviting misuse by normal MMC sockets.
Why not arrange for a small piece of code to be built into the kernel
when this driver is selected as a module or built-in, which handles
the passing of platform data to the driver?
It's interesting.
The only drawback I can see is that it has an inherent limitation of
having only a single wl1271 device on board, but there are no such
boards outside development/testing labs.
Vitaly would that work for you too ?
Thanks,
Ohad.
Something like:
wl12xx_platform_data.c:
#include linux/module.h
#include whatever/required/for/wl12xx.h
static struct wl12xx_platform_data *platform_data;
int __init wl12xx_set_platform_data(const struct wl12xx_platform_data *data)
{
if (platform_data)
return -EBUSY;
platform_data = kmemdup(data, sizeof(*data), GFP_KERNEL);
if (!platform_data)
return -ENOMEM;
return 0;
}
int wl12xx_get_platform_data(struct wl12xx_platform_data *data)
{
if (platform_data) {
memcpy(data, platform_data, sizeof(*data));
return 0;
}
return -ENODEV;
}
EXPORT_SYMBOL(wl12xx_get_platform_data);
And in the Kconfig, something like:
config WL12XX_PLATFORM_DATA
bool
depends on WL12XX != n
default y
This means there'll be no confusion over who owns the 'embedded data',
typechecking is preserved, and no possibility for the wrong driver to
pick up the data.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 00/20] native support for wl1271 on ZOOM
On Mon, Aug 2, 2010 at 2:42 PM, Tony Lindgren t...@atomide.com wrote: Nicolas Pitre made a comment saying he wants to look at these patches more, are there other pending comments? I plan to post a v3 series this week with some of the comments that were already discussed after v2. Thanks everyone for the attention, Ohad. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 00/20] native support for wl1271 on ZOOM
On Mon, Aug 2, 2010 at 6:12 PM, Vitaly Wool vitalyw...@gmail.com wrote: Also, specifically to 12xx, I'd like to see REF_CLOCK moved on and have this set by platform too (I haven't found anything like that in the patches but maybe I've overlooked that). Check out patch no. 9: http://www.spinics.net/lists/arm-kernel/msg93836.html Thanks, Vitaly -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 03/20] mmc: support embedded data field in mmc_host
Hi Vitaly, On Thu, Jul 29, 2010 at 7:16 PM, Vitaly Wool vitalyw...@gmail.com wrote: On Thu, Jul 29, 2010 at 8:00 AM, Ohad Ben-Cohen o...@wizery.com wrote: To my understanding, this data doesn't belong to mmc_host. It's not a host data at all. E. g. imagine a GPIO IRQ for some SDIO chip -- it's totally unrelated to host. I think a cleaner way would be to introduce something similar to what we have for SPI, e. g. struct sdio_board_info. This board info will contain platform-specific stuff and vendor id/chip id for each onboard SDIO device. Then the SDIO core will pick up the appropriate data basing on vendor id/chip id. Can you please elaborate some more about your proposal (specifically where does this sdio_board_info get set and how do function drivers access it) ? If I understand you correctly, you suggest to have a global, board-specific table of sdio_board_info structures, which would be accessible to the SDIO core (through the host driver ?). When a new SDIO device is found the core would search this table for the appropriate sdio_board_info struct and make it accessible to the SDIO function driver ? Well, let's look at how it's implemented for SPI. There is the function spi_register_board_info in the SPI core which copies the board info into the local data structure (a linked list, actually). Whenever needed, the core walks through the list to find the appropriate board_info basing on some search key. I think this may be the way to go for SDIO as well. IMHO this is a bit overkill solution for our problem. SPI is using these spi_board_info tables to populate the SPI device trees. These tables are registered early at the board-specific init code, and are later used by SPI core to populate the devices when the SPI master controller is registered. SDIO doesn't normally needs any kind of hard coded data: most devices are dynamically probed and populated. On rare cases like the wl1271, we have some platform-specific data we need to deliver the SDIO function driver (i.e. the irq info in this case). Since the device is hardwired to a specific controller, it does make some sense to pass this private data from the controller's info in the board files, through the host driver, and make it accessible through the specific host instance that drives this controller. Btw, if our problem was be broader (e.g., needs to supply private data for non-hardwired devices), then I agree that a more complex mechanism, such as the one you suggest, would be needed. But currently the problem is very simple and the solution is even simpler: just add 1 private pointer to the host. Hope you find this reasonable, Thanks, Ohad. ~Vitaly -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 00/20] native support for wl1271 on ZOOM
Hi Vitaly, On Mon, Aug 2, 2010 at 7:19 PM, Vitaly Wool vitalyw...@gmail.com wrote: On Mon, Aug 2, 2010 at 5:59 PM, Ohad Ben-Cohen o...@wizery.com wrote: Check out patch no. 9: sorry for the confusion. However, I guess if the platform doesn't supply this value, we'll just consider it 0? Without any warning, right? The problem is, we can't really distinguish between this field not set and value zero, and that means something is wrong with the design. The easiest way is probably changing the clock ids to start with 1. I don't think it's a huge deal as adding new devices on board files is anyway something that is done carefully and not so often. Btw, we have this kind of mechanism in other locations of the kernel as well and it doesn't seem to be problematic (e.g. spi-chip_select, spi-mode, spi-irq, ...). Having said that I don't mind applying your proposal either and pushing those defines by 1 in the driver. Luca what do you think ? Thanks, Ohad. Thanks, Vitaly -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 03/20] mmc: support embedded data field in mmc_host
Hi Vitaly, On Mon, Aug 2, 2010 at 7:25 PM, Vitaly Wool vitalyw...@gmail.com wrote: On Mon, Aug 2, 2010 at 5:54 PM, Ohad Ben-Cohen o...@wizery.com wrote: SPI is using these spi_board_info tables to populate the SPI device trees. These tables are registered early at the board-specific init code, and are later used by SPI core to populate the devices when the SPI master controller is registered. SDIO doesn't normally needs any kind of hard coded data: most devices are dynamically probed and populated. On rare cases like the wl1271, we have some platform-specific data we need to deliver the SDIO function driver (i.e. the irq info in this case). Since the device is hardwired to a specific controller, it does make some sense to pass this private data from the controller's info in the board files, through the host driver, and make it accessible through the specific host instance that drives this controller. Btw, if our problem was be broader (e.g., needs to supply private data for non-hardwired devices), then I agree that a more complex mechanism, such as the one you suggest, would be needed. But currently the problem is very simple and the solution is even simpler: just add 1 private pointer to the host. Hope you find this reasonable, no, actually I don't. I think this is a hack that intrudes into the area it completely doesn't belong to. In fact, one can have 2 views on this problem: either this is a fairly generic problem we need to address, or this is a very specific corner case. Your solution will be treated as a hack in both cases. If we consider it a generic problem, then we need to find a generic solution, which is the board_info solution, for instance. FWIW, I2C also uses this approach now. If we consider it to be a corner case, let's just add a dummy platform_device like it's done in WL1251 implementation and keep the MMC subsystem clean. Let's start by defining the problem exactly: SDIO devices that are hardwired to a specific controller and have some platform data that needs to be available to the SDIO function driver. It doesn't get more generic than that - it's not needed with common fully-enumerable SDIO devices (at least I'm not aware of such need), hence a generic mechanism of maintaining a global pile of platform data pointers, which can be queried with the device and vendor ID, really sounds like an overkill. But it's not specific to the wl1271 device - I prefer to support this at the MMC level, so we wouldn't have to add an extra platform device for every SDIO function driver that needs to cope with such issue (we already have two drivers - wl1271_sdio.c and wl1251_sdio.c); Adding an extra platform device for every driver is just too much dummy code (that btw adds a well-hidden race condition between the two probe calls), which can be nicely eliminated if we just introduce this new per-host private data pointer. So we have a SDIO device hardwired to a specific controller, that is driven by a specific host controller driver instance. This patch allows this specific host instance to carry platform data for the device that is hardwired to it. The platform data would be available only to SDIO function driver instances of that specific host controller. The solution is generic enough to support all SDIO function drivers with similar needs, and it's extremely simple. I'm honestly trying to understand your concerns, but I'm afraid that just saying it's a hack is not too informative. Can you please explain what do you think is technically wrong with the proposed solution ? is it not general enough for other use cases ? will it break something ? Thanks, Ohad. Thanks, Vitaly -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/10] staging:ti dspbridge: Remove DSP_FAILED and DSP_SUCCEEDED macros
Hi Ernesto,
On Wed, Jul 28, 2010 at 5:45 PM, Ernesto Ramos erne...@ti.com wrote:
This series of patches is targetted to remove macros DSP_FAILED
and DSP_SUCCEEDED since bridge driver currently uses standard kernel
error codes.
These macros were often used to test for success, instead for errors.
This often leads to dspbridge code being highly nested, and hard to
read. The excessive indentation sometimes even lead to longer lines,
which were broken to meet the 80-chars recommendation, where the real
problem is actually the redundant indentation (e.g. check out this
patch http://www.mail-archive.com/linux-omap@vger.kernel.org/msg26700.html).
E.g. the following error testing is very common in the bridge code:
do_something1();
if (success) {
do_something2();
if (success) {
do_something3();
}
}
The kernel alternative would be to check for errors, and take error
paths out of the code flow, e.g.:
do_something1();
if (error)
leave;
do_something2();
if (error)
leave;
do_something3();
if (error)
leave;
This leads to code which is much more easier to read.
If you could hunt some of those highly nested areas and make them test
for error instead of success, it can be really great.
Thanks,
Ohad.
Ernesto Ramos (10):
staging:ti dspbridge: remove DSP_SUCCEEDED macro from core
staging:ti dspbridge: remove DSP_SUCCEEDED macro from pmgr
staging:ti dspbridge: remove DSP_SUCCEEDED macro from rmgr
staging:ti dspbridge: remove DSP_SUCCEEDED macro from services
staging:ti dspbridge: remove DSP_SUCCEEDED macro definition
staging:ti dspbridge: remove DSP_FAILED macro from core
staging:ti dspbridge: remove DSP_FAILED macro from pmgr
staging:ti dspbridge: remove DSP_FAILED macro from rmgr
staging:ti dspbridge: remove DSP_FAILED macro from services
staging:ti dspbridge: remove DSP_FAILED macro definition
drivers/staging/tidspbridge/core/chnl_sm.c | 42 ++--
drivers/staging/tidspbridge/core/dsp-clock.c | 4 +-
drivers/staging/tidspbridge/core/io_sm.c | 111 +-
drivers/staging/tidspbridge/core/msg_sm.c | 26 ++--
drivers/staging/tidspbridge/core/tiomap3430.c | 61 +++---
drivers/staging/tidspbridge/core/tiomap3430_pwr.c | 8 +-
drivers/staging/tidspbridge/core/tiomap_io.c | 41 ++--
.../staging/tidspbridge/include/dspbridge/dbdefs.h | 4 -
drivers/staging/tidspbridge/pmgr/chnl.c | 10 +-
drivers/staging/tidspbridge/pmgr/cmm.c | 137 ++---
drivers/staging/tidspbridge/pmgr/cod.c | 18 +-
drivers/staging/tidspbridge/pmgr/dbll.c | 32 ++--
drivers/staging/tidspbridge/pmgr/dev.c | 79 +++
drivers/staging/tidspbridge/pmgr/dmm.c | 12 +-
drivers/staging/tidspbridge/pmgr/dspapi.c | 82
drivers/staging/tidspbridge/pmgr/io.c | 4 +-
drivers/staging/tidspbridge/pmgr/msg.c | 2 +-
drivers/staging/tidspbridge/rmgr/dbdcd.c | 48 ++--
drivers/staging/tidspbridge/rmgr/disp.c | 62 +++---
drivers/staging/tidspbridge/rmgr/drv.c | 39 ++--
drivers/staging/tidspbridge/rmgr/drv_interface.c | 10 +-
drivers/staging/tidspbridge/rmgr/dspdrv.c | 16 +-
drivers/staging/tidspbridge/rmgr/mgr.c | 32 ++--
drivers/staging/tidspbridge/rmgr/nldr.c | 106 +-
drivers/staging/tidspbridge/rmgr/node.c | 224
++--
drivers/staging/tidspbridge/rmgr/proc.c | 137 ++--
drivers/staging/tidspbridge/rmgr/pwr.c | 26 +--
drivers/staging/tidspbridge/rmgr/rmm.c | 12 +-
drivers/staging/tidspbridge/rmgr/strm.c | 75
drivers/staging/tidspbridge/services/cfg.c | 21 +-
30 files changed, 710 insertions(+), 771 deletions(-)
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 03/20] mmc: support embedded data field in mmc_host
Hi Vitaly,
On Wed, Jul 28, 2010 at 10:47 PM, Vitaly Wool vitalyw...@gmail.com wrote:
On Wed, Jul 21, 2010 at 7:33 PM, Ohad Ben-Cohen o...@wizery.com wrote:
Add support to set/get mmc_host private embedded
data.
This is needed to allow software to dynamically
create (and remove) SDIO functions which represents
embedded SDIO devices.
snip
@@ -209,6 +209,8 @@ struct mmc_host {
struct led_trigger *led; /* activity led */
#endif
+ void *embedded_data;
+
To my understanding, this data doesn't belong to mmc_host. It's not a
host data at all. E. g. imagine a GPIO IRQ for some SDIO chip -- it's
totally unrelated to host.
I think a cleaner way would be to introduce something similar to what
we have for SPI, e. g. struct sdio_board_info. This board info will
contain platform-specific stuff and vendor id/chip id for each onboard
SDIO device. Then the SDIO core will pick up the appropriate data
basing on vendor id/chip id.
Can you please elaborate some more about your proposal (specifically
where does this sdio_board_info get set and how do function drivers
access it) ?
If I understand you correctly, you suggest to have a global,
board-specific table of sdio_board_info structures, which would be
accessible to the SDIO core (through the host driver ?). When a new
SDIO device is found the core would search this table for the
appropriate sdio_board_info struct and make it accessible to the SDIO
function driver ?
Thanks,
Ohad.
~Vitaly
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] omap:mailbox-provide multiple reader support
Hi Hari,
On Wed, Jul 28, 2010 at 1:02 AM, Ohad Ben-Cohen o...@wizery.com wrote:
On Wed, Jul 21, 2010 at 12:41 AM, Hari Kanigeri h-kanige...@ti.com wrote:
This patch provides mutiple readers support for a mailbox
instance.
Signed-off-by: Hari Kanigeri h-kanige...@ti.com
---
arch/arm/plat-omap/include/plat/mailbox.h | 6 ++-
arch/arm/plat-omap/mailbox.c | 63
2 files changed, 40 insertions(+), 29 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/mailbox.h
b/arch/arm/plat-omap/include/plat/mailbox.h
index 0486d64..c8e47d8 100644
--- a/arch/arm/plat-omap/include/plat/mailbox.h
+++ b/arch/arm/plat-omap/include/plat/mailbox.h
@@ -68,13 +68,15 @@ struct omap_mbox {
void *priv;
void (*err_notify)(void);
+ atomic_t use_count;
+ struct blocking_notifier_head notifier;
};
int omap_mbox_msg_send(struct omap_mbox *, mbox_msg_t msg);
void omap_mbox_init_seq(struct omap_mbox *);
-struct omap_mbox *omap_mbox_get(const char *);
-void omap_mbox_put(struct omap_mbox *);
+struct omap_mbox *omap_mbox_get(const char *, struct notifier_block *nb);
In this context, I'd like to change notifier to support adding a
cookie which will be passed back to the handler function (unmodified,
in a similar manner to request_irq's void *dev param).
This can be easily achieved with a simple container_of manipulation,
so please disregard my request : your patch is fine as-is. After it is
accepted, it'd be simple to add this context-get-back to dspbridge.
Thanks,
Ohad.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 00/20] native support for wl1271 on ZOOM
On Mon, Jul 26, 2010 at 10:30 PM, John W. Linville linvi...@tuxdriver.com wrote: On Wed, Jul 21, 2010 at 08:33:34PM +0300, Ohad Ben-Cohen wrote: This patch series adds native support for wl1271 on ZOOM. Just for the record, I'm fine with the wl1271 bits here going through the omap tree with the rest of the series. Thanks, John. John -- John W. Linville Someday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/6] Introducing OMAP Remote Processor module
Hi Sanjeev, Thanks for your comments. As we plan to move remoteproc to hwmod, the code will be substantially changed. We will keep your comments in mind, and also keep in mind other TI platforms (like davinci). Thanks, Ohad. On Tue, Jul 27, 2010 at 3:27 PM, Premi, Sanjeev pr...@ti.com wrote: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Ohad Ben-Cohen Sent: Friday, July 02, 2010 3:53 AM To: linux-omap@vger.kernel.org Cc: Kanigeri, Hari; Ben-cohen, Ohad Subject: [RFC 0/6] Introducing OMAP Remote Processor module From: Ohad Ben-Cohen oh...@ti.com This is a preliminary version of OMAP's remoteproc module, submitted for RFC purposes. The purpose of the remoteproc module is to decouple hw-specific code from generic IPC drivers (such as dspbridge and syslink), in order to eventually make those IPC drivers platform-independent. Currently the supported operations are starting and stopping the remote processor, but in the future additional functionality might be added. Both OMAP3 and OMAP4 are supported; OMAP3 supports the dsp remote processor, and OMAP4 supports ducati (tesla support is planned as well). The code was tested on both OMAP3 (using dspbridge) and OMAP4 (using syslink). The code is preliminary: we plan to add much more extensive hwmod support, ideally squashing as much hw-specific code as possible (including RST and PRCM manipulations). In addition, a rebase to recent code bases is needed. While dspbridge accesses remoteproc's interface via pdata pointers, syslink accesses it from user space, via character device interface, so both kernel and user space interfaces are supported. A few words on the char device interface: * Each remote processor is represented by a different character device: /dev/omap-rproc0, /dev/omap-rproc1, ... [sp] Concept of remote processor is not really tied to omap. Though the implementation is being done in context of OMAP, I would suggest removing the prefix omap- from the device name. * A rproc character device can only be opened by a single user (e.g. the syslink daemon) * The start/stop/get_state functionality is exposed via ioctl's * We plan to add automatic stop() invokation in case the user closes the device after starting a remote processor (for resource cleanup purposes. Thus the user will be required to hold the device open as long as it lives). Thanks, Hari Kanigeri (1): omap: introduce OMAP4 remoteproc module Ohad Ben-Cohen (5): omap: add iva2 hwmod support to omap3 omap: introduce OMAP3 remoteproc module omap: introduce common remoteproc module omap: add remoteproc device(s) omap: enable remoteproc building arch/arm/mach-omap2/Makefile | 6 + arch/arm/mach-omap2/devices.c | 86 +++ arch/arm/mach-omap2/omap_hwmod_34xx.h | 23 ++ arch/arm/mach-omap2/remoteproc3xxx.c | 226 ++ arch/arm/mach-omap2/remoteproc44xx.c | 196 arch/arm/plat-omap/Kconfig | 7 + arch/arm/plat-omap/Makefile | 1 + arch/arm/plat-omap/include/plat/omap_hwmod.h | 1 + arch/arm/plat-omap/include/plat/remoteproc.h | 75 ++ arch/arm/plat-omap/remoteproc.c | 316 ++ 10 files changed, 937 insertions(+), 0 deletions(-) create mode 100644 arch/arm/mach-omap2/remoteproc3xxx.c create mode 100644 arch/arm/mach-omap2/remoteproc44xx.c create mode 100644 arch/arm/plat-omap/include/plat/remoteproc.h create mode 100644 arch/arm/plat-omap/remoteproc.c -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] omap:mailbox-provide multiple reader support
Hi Hari,
On Wed, Jul 21, 2010 at 12:41 AM, Hari Kanigeri h-kanige...@ti.com wrote:
This patch provides mutiple readers support for a mailbox
instance.
Signed-off-by: Hari Kanigeri h-kanige...@ti.com
---
arch/arm/plat-omap/include/plat/mailbox.h | 6 ++-
arch/arm/plat-omap/mailbox.c | 63
2 files changed, 40 insertions(+), 29 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/mailbox.h
b/arch/arm/plat-omap/include/plat/mailbox.h
index 0486d64..c8e47d8 100644
--- a/arch/arm/plat-omap/include/plat/mailbox.h
+++ b/arch/arm/plat-omap/include/plat/mailbox.h
@@ -68,13 +68,15 @@ struct omap_mbox {
void *priv;
void (*err_notify)(void);
+ atomic_t use_count;
+ struct blocking_notifier_head notifier;
};
int omap_mbox_msg_send(struct omap_mbox *, mbox_msg_t msg);
void omap_mbox_init_seq(struct omap_mbox *);
-struct omap_mbox *omap_mbox_get(const char *);
-void omap_mbox_put(struct omap_mbox *);
+struct omap_mbox *omap_mbox_get(const char *, struct notifier_block *nb);
In this context, I'd like to change notifier to support adding a
cookie which will be passed back to the handler function (unmodified,
in a similar manner to request_irq's void *dev param).
This cookie param will be passed to the mailbox callback whenever a
mailbox event is triggered, and will allow drivers to have multiple
instances: instead of maintaining their state in a global variable
(like bridge is doing today), it will be given back every time a
mailbox event is delivered. For syslink it will also help using the
same mbox callback for different devices (e.g. sysm3, appm3).
The changes should be minor, and shouldn't affect existing notifier
users, here's the diff (untested):
diff --git a/include/linux/notifier.h b/include/linux/notifier.h
index 540703b..e740aea 100644
--- a/include/linux/notifier.h
+++ b/include/linux/notifier.h
@@ -51,6 +51,7 @@ struct notifier_block {
int (*notifier_call)(struct notifier_block *, unsigned long, void *);
struct notifier_block *next;
int priority;
+ void *dev_id;
};
struct atomic_notifier_head {
diff --git a/kernel/notifier.c b/kernel/notifier.c
index 2488ba7..050fd9b 100644
--- a/kernel/notifier.c
+++ b/kernel/notifier.c
@@ -64,6 +64,7 @@ static int notifier_chain_unregister(struct notifier_block **n
* @nl:Pointer to head of the blocking notifier chain
* @val: Value passed unmodified to notifier function
* @v: Pointer passed unmodified to notifier function
+ * If pointer is NULL, the notifier block's
cookie is passed
* @nr_to_call:Number of notifier functions to be called. Don't care
* value of this parameter is -1.
* @nr_calls: Records the number of notifications sent. Don't care
@@ -90,6 +91,7 @@ static int __kprobes notifier_call_chain(struct notifier_block
continue;
}
#endif
+ v = v ? v : nb-dev_id;
ret = nb-notifier_call(nb, val, v);
if (nr_calls)
And the only change in your mbox patch should be:
@@ -149,8 +149,8 @@ static void mbox_rx_work(struct work_struct *work)
if (unlikely(len != sizeof(msg)))
pr_err(%s: kfifo_out anomaly detected\n, __func__);
- blocking_notifier_call_chain(mq-mbox-notifier, len,
- (void *)msg);
+ blocking_notifier_call_chain(mq-mbox-notifier, msg, NULL);
}
}
The result should be us getting both the mailbox msg and the original
cookie, which will, in our case, be the context of the relevant
dspbridge or syslink driver.
What do you think ?
Thanks,
Ohad.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 10/20] omap: zoom: add fixed regulator device for wlan
On Fri, Jul 23, 2010 at 12:15 PM, Mark Brown broo...@opensource.wolfsonmicro.com wrote: On Fri, Jul 23, 2010 at 02:13:38AM +0300, Ohad Ben-Cohen wrote: On Thu, Jul 22, 2010 at 2:16 PM, Roger Quadros roger.quad...@nokia.com wrote: .dev_name = mmci-omap-hs.2 I already set the .dev member of the consumer in a similar manner to how all other regulators are configured in this board - please check out patch 13: https://patchwork.kernel.org/patch/113418/ Does this look reasonable to you ? You should really be using dev_name in preference to dev these days unless there's a *very* good reason. Changed, thank you. I'll submit the updated patch now as a standalone patch as it has no dependencies on the whole series, and it could only help to start trimming that series down. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] omap: zoom: add fixed regulator device for wl1271
Add a fixed regulator vmmc device to enable power control
of the wl1271 wlan device.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
This patch is a follow-up to a previous wl1271 discussion,
thus all original recipients are CC'ed.
arch/arm/mach-omap2/board-zoom-peripherals.c | 35 ++
1 files changed, 35 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-zoom-peripherals.c
b/arch/arm/mach-omap2/board-zoom-peripherals.c
index 6b39849..de88635 100644
--- a/arch/arm/mach-omap2/board-zoom-peripherals.c
+++ b/arch/arm/mach-omap2/board-zoom-peripherals.c
@@ -16,6 +16,7 @@
#include linux/gpio.h
#include linux/i2c/twl.h
#include linux/regulator/machine.h
+#include linux/regulator/fixed.h
#include asm/mach-types.h
#include asm/mach/arch.h
@@ -27,6 +28,8 @@
#include mux.h
#include hsmmc.h
+#define OMAP_ZOOM_WLAN_PMENA_GPIO (101)
+
/* Zoom2 has Qwerty keyboard*/
static int board_keymap[] = {
KEY(0, 0, KEY_E),
@@ -106,6 +109,11 @@ static struct regulator_consumer_supply zoom_vmmc2_supply
= {
.supply = vmmc,
};
+static struct regulator_consumer_supply zoom_vmmc3_supply = {
+ .supply = vmmc,
+ .dev_name = mmci-omap-hs.2,
+};
+
/* VMMC1 for OMAP VDD_MMC1 (i/o) and MMC1 card */
static struct regulator_init_data zoom_vmmc1 = {
.constraints = {
@@ -151,6 +159,32 @@ static struct regulator_init_data zoom_vsim = {
.consumer_supplies = zoom_vsim_supply,
};
+static struct regulator_init_data zoom_vmmc3 = {
+ .constraints = {
+ .valid_ops_mask = REGULATOR_CHANGE_STATUS,
+ },
+ .num_consumer_supplies = 1,
+ .consumer_supplies = zoom_vmmc3_supply,
+};
+
+static struct fixed_voltage_config zoom_vwlan = {
+ .supply_name = vwl1271,
+ .microvolts = 180, /* 1.8V */
+ .gpio = OMAP_ZOOM_WLAN_PMENA_GPIO,
+ .startup_delay = 7, /* 70msec */
+ .enable_high = 1,
+ .enabled_at_boot = 0,
+ .init_data = zoom_vmmc3,
+};
+
+static struct platform_device omap_vwlan_device = {
+ .name = reg-fixed-voltage,
+ .id = 1,
+ .dev = {
+ .platform_data = zoom_vwlan,
+ },
+};
+
static struct omap2_hsmmc_info mmc[] __initdata = {
{
.name = external,
@@ -280,6 +314,7 @@ static void enable_board_wakeup_source(void)
void __init zoom_peripherals_init(void)
{
omap_i2c_init();
+ platform_device_register(omap_vwlan_device);
usb_musb_init(musb_board_data);
enable_board_wakeup_source();
}
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 18/20] mmc: sdio: enable a default power off mode of the card
On Thu, Jul 22, 2010 at 2:35 PM, Roger Quadros roger.quad...@nokia.com wrote: On 07/21/2010 08:33 PM, ext Ohad Ben-Cohen wrote: Add support for an SDIO device to stay powered off even without the presence of an SDIO function driver. A host should explicitly ask for it by means of MMC_CAP_DONT_POWER_CARD, and the SDIO function driver should know it needs to call sdio_claim_power before accessing the device. Signed-off-by: Ohad Ben-Coheno...@wizery.com Shouldn't this be the default behaviour? If there is no function driver for any of the functions of the card, then sdio core shold power off the card. I don't see a need for a special capability flag for this. in fact MMC_CAP_DONT_POWER_CARD does not seem like an mmc host's capability Totally agree. I didn't want to change the current behavior of the cards/funcs so I looked for a way to explicitly power down only specific cards. Alternatively we could power down all cards at the end mmc_attach_sdio, and then power them up selectively in sdio_bus_probe, just before calling probe. If the probe succeeds, the function driver takes over. If the probe fails, we can power them down again. Is that what you meant ? This would work both if the sdio function driver is already loaded, or will only be loaded at a later time. But I'm not too fond of the extra power on/off cycles that it will introduce for each card.. Thanks, Ohad. flag, it seems more like a request from the board to keep the card powered off. regards, -roger -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 18/20] mmc: sdio: enable a default power off mode of the card
On Sun, Jul 25, 2010 at 4:56 PM, Nicolas Pitre n...@fluxnic.net wrote: On Sun, 25 Jul 2010, Ohad Ben-Cohen wrote: On Thu, Jul 22, 2010 at 2:35 PM, Roger Quadros roger.quad...@nokia.com wrote: On 07/21/2010 08:33 PM, ext Ohad Ben-Cohen wrote: Add support for an SDIO device to stay powered off even without the presence of an SDIO function driver. A host should explicitly ask for it by means of MMC_CAP_DONT_POWER_CARD, and the SDIO function driver should know it needs to call sdio_claim_power before accessing the device. Signed-off-by: Ohad Ben-Coheno...@wizery.com Shouldn't this be the default behaviour? If there is no function driver for any of the functions of the card, then sdio core shold power off the card. I don't see a need for a special capability flag for this. in fact MMC_CAP_DONT_POWER_CARD does not seem like an mmc host's capability Totally agree. I didn't want to change the current behavior of the cards/funcs so I looked for a way to explicitly power down only specific cards. Alternatively we could power down all cards at the end mmc_attach_sdio, and then power them up selectively in sdio_bus_probe, just before calling probe. If the probe succeeds, the function driver takes over. If the probe fails, we can power them down again. Exactly! Ok, v3 is on the way :) (featuring no special host CAP, fix locking issues, and power down unclaimed cards also on resume) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 10/20] omap: zoom: add fixed regulator device for wlan
On Thu, Jul 22, 2010 at 2:16 PM, Roger Quadros roger.quad...@nokia.com wrote:
On 07/21/2010 08:59 PM, ext Mark Brown wrote:
On Wed, Jul 21, 2010 at 08:33:44PM +0300, Ohad Ben-Cohen wrote:
+static struct regulator_consumer_supply zoom_vmmc3_supply = {
+ .supply = vmmc,
+};
This looks like a misconfiguration on the consumer - I'd strongly expect
the consumer to have a dev_name specified also with the name being in
terms of the consumer device.
you need to add something like
.dev_name = mmci-omap-hs.2
I already set the .dev member of the consumer in a similar manner to
how all other regulators are configured in this board - please check
out patch 13:
https://patchwork.kernel.org/patch/113418/
Does this look reasonable to you ?
Thanks,
Ohad.
regards,
-roger
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 19/20] omap: zoom: keep the MMC3 wl1271 device powered off
Hi Gever,
On Wed, Jul 21, 2010 at 9:55 PM, Gabay, Benzy ben...@ti.com wrote:
From: Ohad Ben-Cohen [mailto:o...@wizery.com]
Sent: Wednesday, July 21, 2010 12:34 PM
To: linux-wirel...@vger.kernel.org; linux-...@vger.kernel.org;
linux-omap@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org; li...@arm.linux.org.uk; Chikkature
Rajashekar, Madhusudhan; Luciano Coelho; a...@linux-foundation.org; San
Mehat; Roger Quadros; Tony Lindgren; Nicolas Pitre; Pandita, Vikram; Kalle
Valo; Ohad Ben-Cohen
Subject: [PATCH v2 19/20] omap: zoom: keep the MMC3 wl1271 device powered off
Keep the MMC3 wl1271 WLAN device powered off until its
SDIO function driver requests otherwise.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
arch/arm/mach-omap2/board-zoom-peripherals.c | 1 +
arch/arm/mach-omap2/hsmmc.c | 3 +++
arch/arm/mach-omap2/hsmmc.h | 1 +
arch/arm/plat-omap/include/plat/mmc.h | 3 +++
drivers/mmc/host/omap_hsmmc.c | 3 +++
5 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-zoom-peripherals.c
b/arch/arm/mach-omap2/board-zoom-peripherals.c
index 3230801..3ab9125 100644
--- a/arch/arm/mach-omap2/board-zoom-peripherals.c
+++ b/arch/arm/mach-omap2/board-zoom-peripherals.c
@@ -217,6 +217,7 @@ static struct omap2_hsmmc_info mmc[] __initdata = {
.gpio_wp = -EINVAL,
.gpio_cd = -EINVAL,
.ocr_mask = MMC_VDD_165_195,
+ .dont_power_card = true,
.priv_data = omap_zoom_wlan_data,
},
{} /* Terminator */
...
--
1.7.0.4
[Benzy Gabay] small comment: Please make sure that all 127x related changes
are not bounded only to MMC3.
On OMAP4 WLAN is used on MMC5.
The only place MMC3 is bound is in the board files (see code snippet
above), so that should be ok.
I can probably split this patch to make this more obvious just by
reading the diffstat if you prefer.
Thanks,
Ohad.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 01/20] sdio: add TI + wl1271 ids
Hi Marcel, On Wed, Jul 21, 2010 at 8:58 PM, Marcel Holtmann mar...@holtmann.org wrote: Add SDIO IDs for TI and for TI's wl1271 wlan device. Signed-off-by: Ohad Ben-Cohen o...@wizery.com --- include/linux/mmc/sdio_ids.h | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/include/linux/mmc/sdio_ids.h b/include/linux/mmc/sdio_ids.h index 33b2ea0..0d313c6 100644 --- a/include/linux/mmc/sdio_ids.h +++ b/include/linux/mmc/sdio_ids.h @@ -43,4 +43,7 @@ #define SDIO_DEVICE_ID_SIANO_NOVA_A0 0x1100 #define SDIO_DEVICE_ID_SIANO_STELLAR 0x5347 +#define SDIO_VENDOR_ID_TI 0x0097 +#define SDIO_DEVICE_ID_TI_WL1271 0x4076 + are we still doing this non-sense for no real reason. What is so wrong with keeping the IDs inside the driver code? Either way we can't go so wrong here (having global VENDOR_IDs can potentially prevent redefinitions of the same ID in different drivers, but that's probably not that big of an issue too). But if we prefer people to stop adding IDs to this global pool, let's at least make it clear. We can probably seal it with some please don't add new IDs if you don't have to footnote (care to send such patch ? :) Thanks, Ohad. Personally I don't even see a point for these ID defines at all. Just use the bare numbers in SDIO_DEVICE and put a comment above what kind of device this is. Regards Marcel -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 00/20] native support for wl1271 on ZOOM
On Fri, Jul 23, 2010 at 1:56 AM, Nicolas Pitre n...@fluxnic.net wrote: On Wed, 21 Jul 2010, Ohad Ben-Cohen wrote: This patch series adds native support for wl1271 on ZOOM. Changes since v1: - introduce a fixed regulator device to control the power of wl1271 - allow to propagate private board-specific data to SDIO function drivers - allow SDIO function driver to control the card's power via new API - make it possible to keep the card's power down (without depending on an explicit SDIO function driver power-down request) Thanks to these changes, we no longer need a separate platform device (carrying e.g. the external irq information of the device), and no longer need to emulate virtual card detect events. The two board muxing pathces were already taken by Tony, and are resent here just to make it easier for people to use/test these pathces. The changes to the MMC core really needs careful review; there still might be some pitfalls that haven't been covered. E.g., one thing we plan to look at next is their bahvior together with SDIO Suspend/Resume. Special thanks to Roger Quadros and Nicolas Pitre for their extensive review and helpful suggestions. FYI, I do intend to review those patches, but I'll be flying home in a couple hours, and once there I'll be gone on vacation for 2 weeks. So this review won't happen right away. Thanks, Nicolas. Nicolas -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 03/20] mmc: support embedded data field in mmc_host
Add support to set/get mmc_host private embedded
data.
This is needed to allow software to dynamically
create (and remove) SDIO functions which represents
embedded SDIO devices.
Typically, it will be used to set the context of
a driver that is creating a new SDIO function
(and would then expect to be able to get that context
back upon creation of the new sdio func).
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
include/linux/mmc/host.h | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
index f65913c..80db597 100644
--- a/include/linux/mmc/host.h
+++ b/include/linux/mmc/host.h
@@ -209,6 +209,8 @@ struct mmc_host {
struct led_trigger *led; /* activity led */
#endif
+ void*embedded_data;
+
struct dentry *debugfs_root;
unsigned long private[0] cacheline_aligned;
@@ -264,5 +266,15 @@ static inline void mmc_set_disable_delay(struct mmc_host
*host,
host-disable_delay = disable_delay;
}
+static inline void *mmc_get_embedded_data(struct mmc_host *host)
+{
+ return host-embedded_data;
+}
+
+static inline void mmc_set_embedded_data(struct mmc_host *host, void *data)
+{
+ host-embedded_data = data;
+}
+
#endif
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 04/20] omap zoom2: wlan board muxing
Add board muxing to support the wlan wl1271 chip that is
hardwired to mmc2 (third mmc controller) on the ZOOM2.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
arch/arm/mach-omap2/board-zoom2.c | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-zoom2.c
b/arch/arm/mach-omap2/board-zoom2.c
index 803ef14..1520a2c 100644
--- a/arch/arm/mach-omap2/board-zoom2.c
+++ b/arch/arm/mach-omap2/board-zoom2.c
@@ -71,6 +71,19 @@ static struct twl4030_platform_data zoom2_twldata = {
#ifdef CONFIG_OMAP_MUX
static struct omap_board_mux board_mux[] __initdata = {
+ /* WLAN IRQ - GPIO 162 */
+ OMAP3_MUX(MCBSP1_CLKX, OMAP_MUX_MODE4 | OMAP_PIN_INPUT_PULLUP),
+ /* WLAN POWER ENABLE - GPIO 101 */
+ OMAP3_MUX(CAM_D2, OMAP_MUX_MODE4 | OMAP_PIN_OUTPUT),
+ /* WLAN SDIO: MMC3 CMD */
+ OMAP3_MUX(MCSPI1_CS1, OMAP_MUX_MODE3 | OMAP_PIN_INPUT_PULLUP),
+ /* WLAN SDIO: MMC3 CLK */
+ OMAP3_MUX(ETK_CLK, OMAP_MUX_MODE2 | OMAP_PIN_INPUT_PULLUP),
+ /* WLAN SDIO: MMC3 DAT[0-3] */
+ OMAP3_MUX(ETK_D3, OMAP_MUX_MODE2 | OMAP_PIN_INPUT_PULLUP),
+ OMAP3_MUX(ETK_D4, OMAP_MUX_MODE2 | OMAP_PIN_INPUT_PULLUP),
+ OMAP3_MUX(ETK_D5, OMAP_MUX_MODE2 | OMAP_PIN_INPUT_PULLUP),
+ OMAP3_MUX(ETK_D6, OMAP_MUX_MODE2 | OMAP_PIN_INPUT_PULLUP),
{ .reg_offset = OMAP_MUX_TERMINATOR },
};
#else
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 05/20] omap zoom3: wlan board muxing
Add board muxing to support the wlan wl1271 chip that is
hardwired to mmc2 (third mmc controller) on the ZOOM3.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
arch/arm/mach-omap2/board-zoom3.c | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-zoom3.c
b/arch/arm/mach-omap2/board-zoom3.c
index 3314704..7d17046 100644
--- a/arch/arm/mach-omap2/board-zoom3.c
+++ b/arch/arm/mach-omap2/board-zoom3.c
@@ -46,6 +46,19 @@ static void __init omap_zoom_init_irq(void)
#ifdef CONFIG_OMAP_MUX
static struct omap_board_mux board_mux[] __initdata = {
+ /* WLAN IRQ - GPIO 162 */
+ OMAP3_MUX(MCBSP1_CLKX, OMAP_MUX_MODE4 | OMAP_PIN_INPUT_PULLUP),
+ /* WLAN POWER ENABLE - GPIO 101 */
+ OMAP3_MUX(CAM_D2, OMAP_MUX_MODE4 | OMAP_PIN_OUTPUT),
+ /* WLAN SDIO: MMC3 CMD */
+ OMAP3_MUX(MCSPI1_CS1, OMAP_MUX_MODE3 | OMAP_PIN_INPUT_PULLUP),
+ /* WLAN SDIO: MMC3 CLK */
+ OMAP3_MUX(ETK_CLK, OMAP_MUX_MODE2 | OMAP_PIN_INPUT_PULLUP),
+ /* WLAN SDIO: MMC3 DAT[0-3] */
+ OMAP3_MUX(ETK_D3, OMAP_MUX_MODE2 | OMAP_PIN_INPUT_PULLUP),
+ OMAP3_MUX(ETK_D4, OMAP_MUX_MODE2 | OMAP_PIN_INPUT_PULLUP),
+ OMAP3_MUX(ETK_D5, OMAP_MUX_MODE2 | OMAP_PIN_INPUT_PULLUP),
+ OMAP3_MUX(ETK_D6, OMAP_MUX_MODE2 | OMAP_PIN_INPUT_PULLUP),
{ .reg_offset = OMAP_MUX_TERMINATOR },
};
#else
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 06/20] wireless: wl1271: make wl12xx.h common to both spi and sdio
Move wl12xx.h outside of the spi-specific location,
so it can be shared with both spi and sdio solutions.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
drivers/net/wireless/wl12xx/wl1251_sdio.c |2 +-
drivers/net/wireless/wl12xx/wl1251_spi.c |2 +-
drivers/net/wireless/wl12xx/wl1271_spi.c |2 +-
include/linux/spi/wl12xx.h| 34 -
include/linux/wl12xx.h| 34 +
5 files changed, 37 insertions(+), 37 deletions(-)
delete mode 100644 include/linux/spi/wl12xx.h
create mode 100644 include/linux/wl12xx.h
diff --git a/drivers/net/wireless/wl12xx/wl1251_sdio.c
b/drivers/net/wireless/wl12xx/wl1251_sdio.c
index c561332..416d5aa 100644
--- a/drivers/net/wireless/wl12xx/wl1251_sdio.c
+++ b/drivers/net/wireless/wl12xx/wl1251_sdio.c
@@ -24,7 +24,7 @@
#include linux/mmc/sdio_func.h
#include linux/mmc/sdio_ids.h
#include linux/platform_device.h
-#include linux/spi/wl12xx.h
+#include linux/wl12xx.h
#include linux/irq.h
#include wl1251.h
diff --git a/drivers/net/wireless/wl12xx/wl1251_spi.c
b/drivers/net/wireless/wl12xx/wl1251_spi.c
index e814742..4847b6a 100644
--- a/drivers/net/wireless/wl12xx/wl1251_spi.c
+++ b/drivers/net/wireless/wl12xx/wl1251_spi.c
@@ -26,7 +26,7 @@
#include linux/slab.h
#include linux/crc7.h
#include linux/spi/spi.h
-#include linux/spi/wl12xx.h
+#include linux/wl12xx.h
#include wl1251.h
#include wl1251_reg.h
diff --git a/drivers/net/wireless/wl12xx/wl1271_spi.c
b/drivers/net/wireless/wl12xx/wl1271_spi.c
index 5189b81..e866049 100644
--- a/drivers/net/wireless/wl12xx/wl1271_spi.c
+++ b/drivers/net/wireless/wl12xx/wl1271_spi.c
@@ -25,7 +25,7 @@
#include linux/module.h
#include linux/crc7.h
#include linux/spi/spi.h
-#include linux/spi/wl12xx.h
+#include linux/wl12xx.h
#include linux/slab.h
#include wl1271.h
diff --git a/include/linux/spi/wl12xx.h b/include/linux/spi/wl12xx.h
deleted file mode 100644
index a223ecb..000
--- a/include/linux/spi/wl12xx.h
+++ /dev/null
@@ -1,34 +0,0 @@
-/*
- * This file is part of wl12xx
- *
- * Copyright (C) 2009 Nokia Corporation
- *
- * Contact: Kalle Valo kalle.v...@nokia.com
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License
- * version 2 as published by the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful, but
- * WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
- * General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
- * 02110-1301 USA
- *
- */
-
-#ifndef _LINUX_SPI_WL12XX_H
-#define _LINUX_SPI_WL12XX_H
-
-struct wl12xx_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;
-};
-
-#endif
diff --git a/include/linux/wl12xx.h b/include/linux/wl12xx.h
new file mode 100644
index 000..137ac89
--- /dev/null
+++ b/include/linux/wl12xx.h
@@ -0,0 +1,34 @@
+/*
+ * This file is part of wl12xx
+ *
+ * Copyright (C) 2009 Nokia Corporation
+ *
+ * Contact: Kalle Valo kalle.v...@nokia.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ *
+ */
+
+#ifndef _LINUX_WL12XX_H
+#define _LINUX_WL12XX_H
+
+struct wl12xx_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;
+};
+
+#endif
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 07/20] wireless: wl1271: support return value for the set power func
Make it possible for the set power method to indicate a
success/failure return value. This is needed to support
more complex power on/off operations such as bringing up
(and down) sdio functions.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
drivers/net/wireless/wl12xx/wl1271.h |2 +-
drivers/net/wireless/wl12xx/wl1271_io.h |8 +---
drivers/net/wireless/wl12xx/wl1271_main.c |4 +++-
drivers/net/wireless/wl12xx/wl1271_sdio.c |4 +++-
drivers/net/wireless/wl12xx/wl1271_spi.c |4 +++-
5 files changed, 15 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wireless/wl12xx/wl1271.h
b/drivers/net/wireless/wl12xx/wl1271.h
index 6f1b6b5..a21cdb2 100644
--- a/drivers/net/wireless/wl12xx/wl1271.h
+++ b/drivers/net/wireless/wl12xx/wl1271.h
@@ -340,7 +340,7 @@ struct wl1271_if_operations {
bool fixed);
void (*reset)(struct wl1271 *wl);
void (*init)(struct wl1271 *wl);
- void (*power)(struct wl1271 *wl, bool enable);
+ int (*power)(struct wl1271 *wl, bool enable);
struct device* (*dev)(struct wl1271 *wl);
void (*enable_irq)(struct wl1271 *wl);
void (*disable_irq)(struct wl1271 *wl);
diff --git a/drivers/net/wireless/wl12xx/wl1271_io.h
b/drivers/net/wireless/wl12xx/wl1271_io.h
index bc806c7..4a5b92c 100644
--- a/drivers/net/wireless/wl12xx/wl1271_io.h
+++ b/drivers/net/wireless/wl12xx/wl1271_io.h
@@ -144,10 +144,12 @@ static inline void wl1271_power_off(struct wl1271 *wl)
clear_bit(WL1271_FLAG_GPIO_POWER, wl-flags);
}
-static inline void wl1271_power_on(struct wl1271 *wl)
+static inline int wl1271_power_on(struct wl1271 *wl)
{
- wl-if_ops-power(wl, true);
- set_bit(WL1271_FLAG_GPIO_POWER, wl-flags);
+ int ret = wl-if_ops-power(wl, true);
+ if (ret == 0)
+ set_bit(WL1271_FLAG_GPIO_POWER, wl-flags);
+ return ret;
}
diff --git a/drivers/net/wireless/wl12xx/wl1271_main.c
b/drivers/net/wireless/wl12xx/wl1271_main.c
index b7d9137..6bd748e 100644
--- a/drivers/net/wireless/wl12xx/wl1271_main.c
+++ b/drivers/net/wireless/wl12xx/wl1271_main.c
@@ -620,7 +620,9 @@ static int wl1271_chip_wakeup(struct wl1271 *wl)
int ret = 0;
msleep(WL1271_PRE_POWER_ON_SLEEP);
- wl1271_power_on(wl);
+ ret = wl1271_power_on(wl);
+ if (ret 0)
+ goto out;
msleep(WL1271_POWER_ON_SLEEP);
wl1271_io_reset(wl);
wl1271_io_init(wl);
diff --git a/drivers/net/wireless/wl12xx/wl1271_sdio.c
b/drivers/net/wireless/wl12xx/wl1271_sdio.c
index 9903ae9..571c6b9 100644
--- a/drivers/net/wireless/wl12xx/wl1271_sdio.c
+++ b/drivers/net/wireless/wl12xx/wl1271_sdio.c
@@ -144,7 +144,7 @@ static void wl1271_sdio_raw_write(struct wl1271 *wl, int
addr, void *buf,
}
-static void wl1271_sdio_set_power(struct wl1271 *wl, bool enable)
+static int wl1271_sdio_set_power(struct wl1271 *wl, bool enable)
{
struct sdio_func *func = wl_to_func(wl);
@@ -159,6 +159,8 @@ static void wl1271_sdio_set_power(struct wl1271 *wl, bool
enable)
sdio_disable_func(func);
sdio_release_host(func);
}
+
+ return 0;
}
static struct wl1271_if_operations sdio_ops = {
diff --git a/drivers/net/wireless/wl12xx/wl1271_spi.c
b/drivers/net/wireless/wl12xx/wl1271_spi.c
index e866049..85a167f 100644
--- a/drivers/net/wireless/wl12xx/wl1271_spi.c
+++ b/drivers/net/wireless/wl12xx/wl1271_spi.c
@@ -313,10 +313,12 @@ static irqreturn_t wl1271_irq(int irq, void *cookie)
return IRQ_HANDLED;
}
-static void wl1271_spi_set_power(struct wl1271 *wl, bool enable)
+static int wl1271_spi_set_power(struct wl1271 *wl, bool enable)
{
if (wl-set_power)
wl-set_power(enable);
+
+ return 0;
}
static struct wl1271_if_operations spi_ops = {
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 08/20] wireless: wl1271: take irq info from private board data
Remove the hard coded irq information, and instead take
the irq information from the board private data
which is supplied by the sdio function.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
drivers/net/wireless/wl12xx/wl1271_sdio.c | 14 --
1 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/wl12xx/wl1271_sdio.c
b/drivers/net/wireless/wl12xx/wl1271_sdio.c
index 571c6b9..75901a6 100644
--- a/drivers/net/wireless/wl12xx/wl1271_sdio.c
+++ b/drivers/net/wireless/wl12xx/wl1271_sdio.c
@@ -28,15 +28,14 @@
#include linux/mmc/sdio_func.h
#include linux/mmc/sdio_ids.h
#include linux/mmc/card.h
+#include linux/mmc/host.h
+#include linux/wl12xx.h
#include plat/gpio.h
#include wl1271.h
#include wl12xx_80211.h
#include wl1271_io.h
-
-#define RX71_WL1271_IRQ_GPIO 42
-
static const struct sdio_device_id wl1271_devices[] = {
{ SDIO_DEVICE(SDIO_VENDOR_ID_TI, SDIO_DEVICE_ID_TI_WL1271) },
{}
@@ -178,6 +177,7 @@ static int __devinit wl1271_probe(struct sdio_func *func,
const struct sdio_device_id *id)
{
struct ieee80211_hw *hw;
+ struct wl12xx_platform_data *wlan_data;
struct wl1271 *wl;
int ret;
@@ -197,9 +197,11 @@ static int __devinit wl1271_probe(struct sdio_func *func,
/* Grab access to FN0 for ELP reg. */
func-card-quirks |= MMC_QUIRK_LENIENT_FN0;
- wl-irq = gpio_to_irq(RX71_WL1271_IRQ_GPIO);
- if (wl-irq 0) {
- ret = wl-irq;
+ wlan_data = mmc_get_embedded_data(func-card-host);
+ if (wlan_data wlan_data-irq)
+ wl-irq = wlan_data-irq;
+ else {
+ ret = -EINVAL;
wl1271_error(could not get irq!);
goto out_free;
}
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 10/20] omap: zoom: add fixed regulator device for wlan
Add a fixed regulator vmmc device to enable power control
of the wl1271 wlan device.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
arch/arm/mach-omap2/board-zoom-peripherals.c | 34 ++
1 files changed, 34 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-zoom-peripherals.c
b/arch/arm/mach-omap2/board-zoom-peripherals.c
index 6b39849..2fc0f4a 100644
--- a/arch/arm/mach-omap2/board-zoom-peripherals.c
+++ b/arch/arm/mach-omap2/board-zoom-peripherals.c
@@ -16,6 +16,7 @@
#include linux/gpio.h
#include linux/i2c/twl.h
#include linux/regulator/machine.h
+#include linux/regulator/fixed.h
#include asm/mach-types.h
#include asm/mach/arch.h
@@ -27,6 +28,8 @@
#include mux.h
#include hsmmc.h
+#define OMAP_ZOOM_WLAN_PMENA_GPIO (101)
+
/* Zoom2 has Qwerty keyboard*/
static int board_keymap[] = {
KEY(0, 0, KEY_E),
@@ -106,6 +109,10 @@ static struct regulator_consumer_supply zoom_vmmc2_supply
= {
.supply = vmmc,
};
+static struct regulator_consumer_supply zoom_vmmc3_supply = {
+ .supply = vmmc,
+};
+
/* VMMC1 for OMAP VDD_MMC1 (i/o) and MMC1 card */
static struct regulator_init_data zoom_vmmc1 = {
.constraints = {
@@ -151,6 +158,32 @@ static struct regulator_init_data zoom_vsim = {
.consumer_supplies = zoom_vsim_supply,
};
+static struct regulator_init_data zoom_vmmc3 = {
+ .constraints = {
+ .valid_ops_mask = REGULATOR_CHANGE_STATUS,
+ },
+ .num_consumer_supplies = 1,
+ .consumer_supplies = zoom_vmmc3_supply,
+};
+
+static struct fixed_voltage_config zoom_vwlan = {
+ .supply_name = vwl1271,
+ .microvolts = 180, /* 1.8V */
+ .gpio = OMAP_ZOOM_WLAN_PMENA_GPIO,
+ .startup_delay = 7, /* 70msec */
+ .enable_high = 1,
+ .enabled_at_boot = 0,
+ .init_data = zoom_vmmc3,
+};
+
+static struct platform_device omap_vwlan_device = {
+ .name = reg-fixed-voltage,
+ .id = 1,
+ .dev = {
+ .platform_data = zoom_vwlan,
+ },
+};
+
static struct omap2_hsmmc_info mmc[] __initdata = {
{
.name = external,
@@ -280,6 +313,7 @@ static void enable_board_wakeup_source(void)
void __init zoom_peripherals_init(void)
{
omap_i2c_init();
+ platform_device_register(omap_vwlan_device);
usb_musb_init(musb_board_data);
enable_board_wakeup_source();
}
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 11/20] omap: hsmmc: support mmc3 regulator power control
Prepare for mmc3 regulator power control by splitting the power
control functions of mmc2 and mmc3, and expecting mmc3 to have
a single, dedicated, regulator support.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
arch/arm/mach-omap2/hsmmc.c | 10 --
drivers/mmc/host/omap_hsmmc.c | 67
2 files changed, 66 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-omap2/hsmmc.c b/arch/arm/mach-omap2/hsmmc.c
index 1ef54b0..5d3d789 100644
--- a/arch/arm/mach-omap2/hsmmc.c
+++ b/arch/arm/mach-omap2/hsmmc.c
@@ -174,7 +174,7 @@ static void omap4_hsmmc1_after_set_reg(struct device *dev,
int slot,
}
}
-static void hsmmc23_before_set_reg(struct device *dev, int slot,
+static void hsmmc2_before_set_reg(struct device *dev, int slot,
int power_on, int vdd)
{
struct omap_mmc_platform_data *mmc = dev-platform_data;
@@ -325,14 +325,16 @@ void __init omap2_hsmmc_init(struct omap2_hsmmc_info
*controllers)
c-transceiver = 1;
if (c-transceiver c-wires 4)
c-wires = 4;
- /* FALLTHROUGH */
- case 3:
if (mmc-slots[0].features HSMMC_HAS_PBIAS) {
/* off-chip level shifting, or none */
- mmc-slots[0].before_set_reg =
hsmmc23_before_set_reg;
+ mmc-slots[0].before_set_reg =
hsmmc2_before_set_reg;
mmc-slots[0].after_set_reg = NULL;
}
break;
+ case 3:
+ mmc-slots[0].before_set_reg = NULL;
+ mmc-slots[0].after_set_reg = NULL;
+ break;
default:
pr_err(MMC%d configuration not supported!\n, c-mmc);
kfree(mmc);
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index b032828..4c5a669 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -258,7 +258,7 @@ static int omap_hsmmc_1_set_power(struct device *dev, int
slot, int power_on,
return ret;
}
-static int omap_hsmmc_23_set_power(struct device *dev, int slot, int power_on,
+static int omap_hsmmc_2_set_power(struct device *dev, int slot, int power_on,
int vdd)
{
struct omap_hsmmc_host *host =
@@ -309,6 +309,31 @@ static int omap_hsmmc_23_set_power(struct device *dev, int
slot, int power_on,
return ret;
}
+static int omap_hsmmc_3_set_power(struct device *dev, int slot, int power_on,
+ int vdd)
+{
+ struct omap_hsmmc_host *host =
+ platform_get_drvdata(to_platform_device(dev));
+ int ret = 0;
+
+ if (power_on) {
+ ret = mmc_regulator_set_ocr(host-vcc, vdd);
+ /* Enable interface voltage rail, if needed */
+ if (ret == 0 host-vcc) {
+ ret = regulator_enable(host-vcc);
+ if (ret 0)
+ ret = mmc_regulator_set_ocr(host-vcc, 0);
+ }
+ } else {
+ if (host-vcc)
+ ret = regulator_disable(host-vcc);
+ if (ret == 0)
+ ret = mmc_regulator_set_ocr(host-vcc, 0);
+ }
+
+ return ret;
+}
+
static int omap_hsmmc_1_set_sleep(struct device *dev, int slot, int sleep,
int vdd, int cardsleep)
{
@@ -319,7 +344,7 @@ static int omap_hsmmc_1_set_sleep(struct device *dev, int
slot, int sleep,
return regulator_set_mode(host-vcc, mode);
}
-static int omap_hsmmc_23_set_sleep(struct device *dev, int slot, int sleep,
+static int omap_hsmmc_2_set_sleep(struct device *dev, int slot, int sleep,
int vdd, int cardsleep)
{
struct omap_hsmmc_host *host =
@@ -358,6 +383,31 @@ static int omap_hsmmc_23_set_sleep(struct device *dev, int
slot, int sleep,
return regulator_enable(host-vcc_aux);
}
+static int omap_hsmmc_3_set_sleep(struct device *dev, int slot, int sleep,
+ int vdd, int cardsleep)
+{
+ struct omap_hsmmc_host *host =
+ platform_get_drvdata(to_platform_device(dev));
+ int err = 0;
+
+ /*
+* If we don't see a Vcc regulator, assume it's a fixed
+* voltage always-on regulator.
+*/
+ if (!host-vcc)
+ return 0;
+
+ if (cardsleep) {
+ /* VCC can be turned off if card is asleep */
+ if (sleep)
+ err = mmc_regulator_set_ocr(host-vcc, 0);
+ else
+ err = mmc_regulator_set_ocr(host-vcc, vdd);
+ }
+
+ return err;
+}
+
static int omap_hsmmc_reg_get
[PATCH v2 13/20] omap: zoom: add mmc3/wl1271 device support
Add MMC3 support on ZOOM, which has the wl1271 device hardwired to.
The wl1271 is a 4-wire, 1.8V, embedded SDIO WLAN device with an
external IRQ line, and power-controlled by a GPIO-based fixed regulator.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
arch/arm/mach-omap2/board-zoom-peripherals.c | 19 +++
1 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-zoom-peripherals.c
b/arch/arm/mach-omap2/board-zoom-peripherals.c
index 2fc0f4a..3230801 100644
--- a/arch/arm/mach-omap2/board-zoom-peripherals.c
+++ b/arch/arm/mach-omap2/board-zoom-peripherals.c
@@ -17,6 +17,8 @@
#include linux/i2c/twl.h
#include linux/regulator/machine.h
#include linux/regulator/fixed.h
+#include linux/mmc/host.h
+#include linux/wl12xx.h
#include asm/mach-types.h
#include asm/mach/arch.h
@@ -29,6 +31,7 @@
#include hsmmc.h
#define OMAP_ZOOM_WLAN_PMENA_GPIO (101)
+#define OMAP_ZOOM_WLAN_IRQ_GPIO(162)
/* Zoom2 has Qwerty keyboard*/
static int board_keymap[] = {
@@ -184,6 +187,12 @@ static struct platform_device omap_vwlan_device = {
},
};
+struct wl12xx_platform_data omap_zoom_wlan_data = {
+ .irq = OMAP_GPIO_IRQ(OMAP_ZOOM_WLAN_IRQ_GPIO),
+ /* ZOOM ref clock is 26 MHz */
+ .board_ref_clock = 1,
+};
+
static struct omap2_hsmmc_info mmc[] __initdata = {
{
.name = external,
@@ -201,6 +210,15 @@ static struct omap2_hsmmc_info mmc[] __initdata = {
.nonremovable = true,
.power_saving = true,
},
+ {
+ .name = wl1271,
+ .mmc= 3,
+ .wires = 4,
+ .gpio_wp= -EINVAL,
+ .gpio_cd= -EINVAL,
+ .ocr_mask = MMC_VDD_165_195,
+ .priv_data = omap_zoom_wlan_data,
+ },
{} /* Terminator */
};
@@ -217,6 +235,7 @@ static int zoom_twl_gpio_setup(struct device *dev,
zoom_vmmc1_supply.dev = mmc[0].dev;
zoom_vsim_supply.dev = mmc[0].dev;
zoom_vmmc2_supply.dev = mmc[1].dev;
+ zoom_vmmc3_supply.dev = mmc[2].dev;
return 0;
}
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 12/20] omap: hsmmc: allow board-specific settings of private mmc data
Allow board-specific settings of private mmc data, in order to
allow embedded SDIO devices to communicate board-specific parameters
to the SDIO function driver (e.g., the external IRQ line of the wl1271).
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
arch/arm/mach-omap2/hsmmc.c |2 ++
arch/arm/mach-omap2/hsmmc.h |1 +
arch/arm/plat-omap/include/plat/mmc.h |2 ++
drivers/mmc/host/omap_hsmmc.c |2 ++
4 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/hsmmc.c b/arch/arm/mach-omap2/hsmmc.c
index 5d3d789..f06ddd2 100644
--- a/arch/arm/mach-omap2/hsmmc.c
+++ b/arch/arm/mach-omap2/hsmmc.c
@@ -284,6 +284,8 @@ void __init omap2_hsmmc_init(struct omap2_hsmmc_info
*controllers)
if (c-vcc_aux_disable_is_sleep)
mmc-slots[0].vcc_aux_disable_is_sleep = 1;
+ mmc-slots[0].priv_data = c-priv_data;
+
/* NOTE: MMC slots should have a Vcc regulator set up.
* This may be from a TWL4030-family chip, another
* controllable regulator, or a fixed supply.
diff --git a/arch/arm/mach-omap2/hsmmc.h b/arch/arm/mach-omap2/hsmmc.h
index 36f0ba8..434a3ed 100644
--- a/arch/arm/mach-omap2/hsmmc.h
+++ b/arch/arm/mach-omap2/hsmmc.h
@@ -23,6 +23,7 @@ struct omap2_hsmmc_info {
int ocr_mask; /* temporary HACK */
/* Remux (pad configuation) when powering on/off */
void (*remux)(struct device *dev, int slot, int power_on);
+ void*priv_data; /* private data to SDIO function driver */
};
#if defined(CONFIG_MMC_OMAP_HS) || defined(CONFIG_MMC_OMAP_HS_MODULE)
diff --git a/arch/arm/plat-omap/include/plat/mmc.h
b/arch/arm/plat-omap/include/plat/mmc.h
index c835f1e..9db1617 100644
--- a/arch/arm/plat-omap/include/plat/mmc.h
+++ b/arch/arm/plat-omap/include/plat/mmc.h
@@ -140,6 +140,8 @@ struct omap_mmc_platform_data {
unsigned int ban_openended:1;
+ /* card private data that should be used by function driver */
+ void *priv_data;
} slots[OMAP_MMC_MAX_SLOTS];
};
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 4c5a669..4ac548e 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -2157,6 +2157,8 @@ static int __init omap_hsmmc_probe(struct platform_device
*pdev)
if (mmc_slot(host).nonremovable)
mmc-caps |= MMC_CAP_NONREMOVABLE;
+ mmc_set_embedded_data(mmc, mmc_slot(host).priv_data);
+
omap_hsmmc_conf_bus_power(host);
/* Select DMA lines */
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 14/20] mmc: sdio: fully reconfigure oldcard on resume
On resume, let mmc_sdio_init_card go all the way, instead of skipping the reconfiguration of the card's speed and width. This is needed to ensure cards wake up with their clock reconfigured (otherwise it's kept low). This patch also removes the explicit bus width reconfiguration on resume, since now this is part of mmc_sdio_init_card. Signed-off-by: Ohad Ben-Cohen o...@wizery.com --- drivers/mmc/core/sdio.c |4 1 files changed, 0 insertions(+), 4 deletions(-) diff --git a/drivers/mmc/core/sdio.c b/drivers/mmc/core/sdio.c index b9dee28..645f173 100644 --- a/drivers/mmc/core/sdio.c +++ b/drivers/mmc/core/sdio.c @@ -344,7 +344,6 @@ static int mmc_sdio_init_card(struct mmc_host *host, u32 ocr, goto err; } card = oldcard; - return 0; } /* @@ -487,9 +486,6 @@ static int mmc_sdio_resume(struct mmc_host *host) mmc_claim_host(host); err = mmc_sdio_init_card(host, host-ocr, host-card, (host-pm_flags MMC_PM_KEEP_POWER)); - if (!err) - /* We may have switched to 1-bit mode during suspend. */ - err = sdio_enable_wide(host-card); if (!err host-sdio_irqs) mmc_signal_sdio_irq(host); mmc_release_host(host); -- 1.7.0.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 15/20] mmc: sdio: verify existence of resume handler
Before invoking a card's resume handler, verify one exists.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
drivers/mmc/core/sdio.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/core/sdio.c b/drivers/mmc/core/sdio.c
index 645f173..37739f5 100644
--- a/drivers/mmc/core/sdio.c
+++ b/drivers/mmc/core/sdio.c
@@ -504,7 +504,9 @@ static int mmc_sdio_resume(struct mmc_host *host)
struct sdio_func *func = host-card-sdio_func[i];
if (func sdio_func_present(func) func-dev.driver) {
const struct dev_pm_ops *pmops = func-dev.driver-pm;
- err = pmops-resume(func-dev);
+
+ if (pmops pmops-resume)
+ err = pmops-resume(func-dev);
}
}
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 16/20] mmc: introduce API to control the card's power
Introduce the sdio_claim_power/sdio_release_power API
(with correspoding mmc_claim_power/mmc_release_power)
that controls the power of the card. A reference count
scheme is employed, to allow SDIO function voting.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
drivers/mmc/core/bus.c|3 ++
drivers/mmc/core/core.c | 50 +
drivers/mmc/core/sdio.c |5
drivers/mmc/core/sdio_io.c| 50 +
include/linux/mmc/card.h |2 +
include/linux/mmc/host.h |2 +
include/linux/mmc/sdio_func.h |3 ++
7 files changed, 115 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/core/bus.c b/drivers/mmc/core/bus.c
index 49d9dca..33151d5 100644
--- a/drivers/mmc/core/bus.c
+++ b/drivers/mmc/core/bus.c
@@ -17,6 +17,7 @@
#include linux/mmc/card.h
#include linux/mmc/host.h
+#include asm/atomic.h
#include core.h
#include sdio_cis.h
@@ -207,6 +208,8 @@ struct mmc_card *mmc_alloc_card(struct mmc_host *host,
struct device_type *type)
card-host = host;
+ atomic_set(card-power_claims, 0);
+
device_initialize(card-dev);
card-dev.parent = mmc_classdev(host);
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 569e94d..ca5e3bf 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -1334,6 +1334,56 @@ EXPORT_SYMBOL(mmc_resume_host);
#endif
+/**
+ * mmc_release_power - remove power from the card
+ * @host: mmc host
+ */
+int mmc_release_power(struct mmc_host *host)
+{
+ int err = 0;
+
+ mmc_bus_get(host);
+ if (host-bus_ops !host-bus_dead) {
+ if (host-bus_ops-suspend)
+ err = host-bus_ops-suspend(host);
+ /* it's ok not to have a suspend handler */
+ err = err == -ENOSYS ? 0 : err;
+ }
+ mmc_bus_put(host);
+
+ if (!err)
+ mmc_power_off(host);
+
+ return err;
+}
+EXPORT_SYMBOL_GPL(mmc_release_power);
+
+/*
+ * mmc_claim_power - power up card
+ * @host: mmc host
+ */
+int mmc_claim_power(struct mmc_host *host)
+{
+ int err = 0;
+
+ mmc_bus_get(host);
+
+ mmc_power_up(host);
+ mmc_select_voltage(host, host-ocr);
+
+ BUG_ON(!host-bus_ops-resume);
+ err = host-bus_ops-resume(host);
+ if (err) {
+ printk(KERN_WARNING %s: error %d during resume
+ (card was removed?)\n,
+ mmc_hostname(host), err);
+ }
+ mmc_bus_put(host);
+
+ return err;
+}
+EXPORT_SYMBOL_GPL(mmc_claim_power);
+
static int __init mmc_init(void)
{
int ret;
diff --git a/drivers/mmc/core/sdio.c b/drivers/mmc/core/sdio.c
index 37739f5..79e6fa1 100644
--- a/drivers/mmc/core/sdio.c
+++ b/drivers/mmc/core/sdio.c
@@ -15,6 +15,7 @@
#include linux/mmc/card.h
#include linux/mmc/sdio.h
#include linux/mmc/sdio_func.h
+#include asm/atomic.h
#include core.h
#include bus.h
@@ -72,6 +73,10 @@ static int sdio_init_func(struct mmc_card *card, unsigned
int fn)
card-sdio_func[fn - 1] = func;
+ /* For each SDIO function initialized, increase the power claim
+* reference count of the card */
+ atomic_inc(card-power_claims);
+
return 0;
fail:
diff --git a/drivers/mmc/core/sdio_io.c b/drivers/mmc/core/sdio_io.c
index 0f687cd..28ebc16 100644
--- a/drivers/mmc/core/sdio_io.c
+++ b/drivers/mmc/core/sdio_io.c
@@ -17,6 +17,56 @@
#include sdio_ops.h
/**
+ * sdio_release_power - allow to release power of a certain SDIO function
+ * @func: SDIO function that is accessed
+ *
+ * Indicate to the core SDIO layer that we're not requiring that the
+ * function remain powered. If all functions for the card are in the
+ * same no power state, then the host controller can remove power from
+ * the card. Note: the function driver must preserve hardware states if
+ * necessary.
+ */
+int sdio_release_power(struct sdio_func *func)
+{
+ int ret = 0;
+ BUG_ON(!func);
+ BUG_ON(!func-card);
+
+ if (atomic_dec_and_test(func-card-power_claims))
+ ret = mmc_release_power(func-card-host);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(sdio_release_power);
+
+/*
+ * sdio_claim_power - request power for a certain SDIO function
+ * @func: SDIO function that is accessed
+ *
+ * Indicate to the core SDIO layer that we want power back for this
+ * SDIO function. The power may or may not actually have been removed
+ * since last call to sdio_release_power(), so the function driver must
+ * not assume any preserved state at the hardware level and re-perform
+ * all the necessary hardware config. This function returns 0 when
+ * power is actually restored, or some error code if this cannot be
+ * achieved. One error reason might be that the card
[PATCH v2 20/20] wireless: wl1271: call SDIO claim/release power API
call SDIO claim/release power API to turn the wl1271
power on and off
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
drivers/net/wireless/wl12xx/wl1271_sdio.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/wl12xx/wl1271_sdio.c
b/drivers/net/wireless/wl12xx/wl1271_sdio.c
index 5967718..a7e9ace 100644
--- a/drivers/net/wireless/wl12xx/wl1271_sdio.c
+++ b/drivers/net/wireless/wl12xx/wl1271_sdio.c
@@ -152,11 +152,13 @@ static int wl1271_sdio_set_power(struct wl1271 *wl, bool
enable)
* alive.
*/
if (enable) {
+ sdio_claim_power(func);
sdio_claim_host(func);
sdio_enable_func(func);
} else {
sdio_disable_func(func);
sdio_release_host(func);
+ sdio_release_power(func);
}
return 0;
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 18/20] mmc: sdio: enable a default power off mode of the card
Add support for an SDIO device to stay powered off even without
the presence of an SDIO function driver. A host should explicitly
ask for it by means of MMC_CAP_DONT_POWER_CARD, and the SDIO
function driver should know it needs to call sdio_claim_power
before accessing the device.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
drivers/mmc/core/sdio.c | 15 +--
include/linux/mmc/host.h |1 +
2 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/core/sdio.c b/drivers/mmc/core/sdio.c
index 5c0fbfa..164353f 100644
--- a/drivers/mmc/core/sdio.c
+++ b/drivers/mmc/core/sdio.c
@@ -80,8 +80,9 @@ static int sdio_init_func(struct mmc_card *card, unsigned int
fn)
return ret;
/* For each SDIO function initialized, increase the power claim
-* reference count of the card */
- atomic_inc(card-power_claims);
+* reference count of the card, unless explicitly requested not to */
+ if (!(card-host-caps MMC_CAP_DONT_POWER_CARD))
+ atomic_inc(card-power_claims);
return 0;
@@ -607,6 +608,16 @@ int mmc_attach_sdio(struct mmc_host *host, u32 ocr)
mmc_release_host(host);
/*
+* If power is not required for this card, power it off.
+* The sdio function will need to call sdio_claim_power.
+*/
+ if (!atomic_read(card-power_claims)) {
+ pr_info(%s: power is not claimed, releasing\n,
+ mmc_hostname(host));
+ mmc_release_power(host);
+ }
+
+ /*
* First add the card to the driver model...
*/
err = mmc_add_card(host-card);
diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
index 3675d58..756cf38 100644
--- a/include/linux/mmc/host.h
+++ b/include/linux/mmc/host.h
@@ -155,6 +155,7 @@ struct mmc_host {
#define MMC_CAP_DISABLE(1 7)/* Can the host be
disabled */
#define MMC_CAP_NONREMOVABLE (1 8)/* Nonremovable e.g. eMMC */
#define MMC_CAP_WAIT_WHILE_BUSY(1 9)/* Waits while card is
busy */
+#define MMC_CAP_DONT_POWER_CARD(1 10) /* Keep the card
powered off */
mmc_pm_flag_t pm_caps;/* supported pm features */
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 19/20] omap: zoom: keep the MMC3 wl1271 device powered off
Keep the MMC3 wl1271 WLAN device powered off until its
SDIO function driver requests otherwise.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
arch/arm/mach-omap2/board-zoom-peripherals.c |1 +
arch/arm/mach-omap2/hsmmc.c |3 +++
arch/arm/mach-omap2/hsmmc.h |1 +
arch/arm/plat-omap/include/plat/mmc.h|3 +++
drivers/mmc/host/omap_hsmmc.c|3 +++
5 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-zoom-peripherals.c
b/arch/arm/mach-omap2/board-zoom-peripherals.c
index 3230801..3ab9125 100644
--- a/arch/arm/mach-omap2/board-zoom-peripherals.c
+++ b/arch/arm/mach-omap2/board-zoom-peripherals.c
@@ -217,6 +217,7 @@ static struct omap2_hsmmc_info mmc[] __initdata = {
.gpio_wp= -EINVAL,
.gpio_cd= -EINVAL,
.ocr_mask = MMC_VDD_165_195,
+ .dont_power_card = true,
.priv_data = omap_zoom_wlan_data,
},
{} /* Terminator */
diff --git a/arch/arm/mach-omap2/hsmmc.c b/arch/arm/mach-omap2/hsmmc.c
index f06ddd2..24c4144 100644
--- a/arch/arm/mach-omap2/hsmmc.c
+++ b/arch/arm/mach-omap2/hsmmc.c
@@ -284,6 +284,9 @@ void __init omap2_hsmmc_init(struct omap2_hsmmc_info
*controllers)
if (c-vcc_aux_disable_is_sleep)
mmc-slots[0].vcc_aux_disable_is_sleep = 1;
+ if (c-dont_power_card)
+ mmc-slots[0].dont_power_card = 1;
+
mmc-slots[0].priv_data = c-priv_data;
/* NOTE: MMC slots should have a Vcc regulator set up.
diff --git a/arch/arm/mach-omap2/hsmmc.h b/arch/arm/mach-omap2/hsmmc.h
index 434a3ed..e200786 100644
--- a/arch/arm/mach-omap2/hsmmc.h
+++ b/arch/arm/mach-omap2/hsmmc.h
@@ -23,6 +23,7 @@ struct omap2_hsmmc_info {
int ocr_mask; /* temporary HACK */
/* Remux (pad configuation) when powering on/off */
void (*remux)(struct device *dev, int slot, int power_on);
+ booldont_power_card;/* keep card power off at boot (default is n)*/
void*priv_data; /* private data to SDIO function driver */
};
diff --git a/arch/arm/plat-omap/include/plat/mmc.h
b/arch/arm/plat-omap/include/plat/mmc.h
index 9db1617..d042494 100644
--- a/arch/arm/plat-omap/include/plat/mmc.h
+++ b/arch/arm/plat-omap/include/plat/mmc.h
@@ -140,6 +140,9 @@ struct omap_mmc_platform_data {
unsigned int ban_openended:1;
+ /* keep this card powered off at boot (default is n) */
+ unsigned int dont_power_card:1;
+
/* card private data that should be used by function driver */
void *priv_data;
} slots[OMAP_MMC_MAX_SLOTS];
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 4ac548e..4fb6634 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -2157,6 +2157,9 @@ static int __init omap_hsmmc_probe(struct platform_device
*pdev)
if (mmc_slot(host).nonremovable)
mmc-caps |= MMC_CAP_NONREMOVABLE;
+ if (mmc_slot(host).dont_power_card)
+ mmc-caps |= MMC_CAP_DONT_POWER_CARD;
+
mmc_set_embedded_data(mmc, mmc_slot(host).priv_data);
omap_hsmmc_conf_bus_power(host);
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/15] wireless: wl1271: introduce platform device support
Hi Roger, On Fri, Jul 9, 2010 at 11:12 AM, Roger Quadros roger.quad...@nokia.com wrote: You are already creating a new platform device for wl1271_sdio just to pass platform_data With the new approach, I can remove this platform device altogether, and completely rely on the sdio function device for driver probing (as it was before). I just need to add this little support of delivering small bits of platform data - the mechanism should be simple and generic, and would considerably simplify the driver. I think this case is specific to wl1271. Yes, it is. There's an hw issue with the wl1271's in-band interrupt, so we can't use it (the issue is fixed in the wl1281 btw). But we also have to deliver the reference clock info to the driver, which is board-specific data, and would be relevant to all wl12xx devices. Thanks, Ohad. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/15] wireless: wl1271: introduce platform device support
Hi Nicolas and Roger, On Tue, Jul 6, 2010 at 8:42 PM, Nicolas Pitre n...@fluxnic.net wrote: On Tue, 6 Jul 2010, Roger Quadros wrote: If the Power enable GPIO can be treated as SDIO slot supply (i.e. vmmc), then the SDIO/MMC core should tackle it, just like it deals with supply for slots with removable cards. ... Another function pair would be needed instead, which would do almost like the suspend/resume code is already doing. Something like: Thanks a lot for your review and comments, and for taking the time to present your approach. I like it ! It'd allow us to lose the software (or fake if you want ;) card detect mechanism, which is something that should have been added to each platform we wanted to support. We would only need to make it possible to deliver board-specific data to the function driver (e.g., in the case of the wl1271, we need irq and board_ref_clock data). That would require some board-level platform-data configuration, which will be specific to the controller to which the device is hardwired to. This data should propagate through the host controller to the SDIO core so it would eventually be accessible by the function driver (e.g. via func-dev.pdata). We'll adapt and post follow-up patches. Thanks again, Ohad. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 06/15] omap zoom2: wlan board muxing
On Thu, Jul 8, 2010 at 12:45 PM, Tony Lindgren t...@atomide.com wrote:
* Ghorai, Sukumar s-gho...@ti.com [100708 06:34]:
@@ -71,6 +71,21 @@ static struct twl4030_platform_data zoom2_twldata = {
#ifdef CONFIG_OMAP_MUX
static struct omap_board_mux board_mux[] __initdata = {
+#ifdef CONFIG_OMAP_ZOOM_WLAN
[Ghorai] This is zoom board specific file, So why need this additional flag?
Good point, the ifdef is unnecessary in for both zoom2 and zoom3.
Will update in my queue to remove the ifdefs.
Thanks a lot, Tony.
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 15/15] omap: zoom: enable WLAN device
On Thu, Jul 8, 2010 at 6:39 AM, Ghorai, Sukumar s-gho...@ti.com wrote: [Ghorai] In general we can avoid OMAP_ZOOM_WLAN and MMC_EMBEDDED_SDIO as kconfig option. 1st one is board specific and 2nd one could be generic sdio code. As I mentioned in other patch too. Thanks, will get rid of the extra config options. -- 1.7.0.4 -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/11] staging: ti dspbridge: enable driver building
On Wed, Jul 7, 2010 at 12:31 PM, Felipe Contreras felipe.contre...@gmail.com wrote: On Tue, Jul 6, 2010 at 6:52 PM, Omar Ramirez Luna omar.rami...@ti.com wrote: at that point *you* wanted your patches not to be included if the last one wasn't merged in. Not without the copyright update patch. ... So. Would you care to give a reason why my contributions don't deserve a copyright? Disclaimer: I am not a lawyer, and I speak only for myself in this post, and doesn't represent TI in anyway. AFAICT, you get copyright for every kernel change you submit and is accepted. Even if you just contribute whitespace cleanups, you get the copyright to those cleanups (not to suggest this was the sole contribution here). The copyright assignment is per the actual git commit itself, obviously, and it doesn't apply for the rest of the code in those files you edited. There are some exceptions, but they are not applicable here: - Usually when you get paid for the work, the employer keeps the copyright of the patch, not the author. - There are some projects where you have to relinquish the copyright in order for the patch to be accepted. This is how FSF (Free Software Foundation) projects work (e.g. gcc), but not the Linux kernel (which is not a FSF project). As I mentioned, I don't think these exceptions apply in this case, and AFAICT, Felipe - you inherently get the copyright for the changes that your accepted patches introduce. So it all boils down to the semantic question whether to edit the header file, adding new copyright lines, or not. Felipe, I think your contributions are important and helpful, and I would personally be happy if you continue to do them. I personally don't think that adding an explicit copyright line to the header should be important, because you get your copyright anyway. The exact change, to which you get copyright on, is kept in the git history, and will not likely to go away. I think this is pretty satisfying, and as a result, you don't see people(/companies) changing copyright headers when they submit kernel patches that edit existing files. The only thing I am not sure about, and that may be a concern to TI, is whether adding a copyright line in the header might actually give copyright ownership for the complete file. If this is true, I can understand why TI might not be so keen in adding copyright owners to the file header, without explicitly specifying what is the copyright about (not to suggest any opinion of TI on the matter, I speak only for myself). Again: I am not a lawyer, and I speak only for myself in this post, and doesn't represent TI in anyway. Thanks, Ohad. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/15] wireless: wl1271: introduce platform device support
Hi Roger, On Tue, Jul 6, 2010 at 11:53 AM, Roger Quadros roger.quad...@nokia.com wrote: Could you please explain why you need to do this? To minimize power consumption when the wlan device is not in use, we would like to keep the device powered off as long as the interface is down, and only power it on when the user brings up the interface. Whenever the chip is powered on, it must be initialized and reconfigured by mmc_attach_sdio, and the wl1271 driver have to wait for that phase to successfully complete (essentially waiting for the sdio_driver's probe function to be called). To make sure this SDIO init step occurs correctly every time we toggle the device's power back on, and to prevent potential races, we also have to make sure that the sdio function is removed every time we power off the chip (the driver waits for the sdio_driver's remove function to be called). That's why we let the mmc layer think that the card is removed: physically it is still there, but for all practical purposes it is really removed, because once you power off the chip, you must reinitialize it again next time you power it on, as if the card was really removed and re-inserted. Thanks, Ohad. br, -roger -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/15] omap: hsmmc: add virtual card detect support
Hi Nicolas, On Tue, Jul 6, 2010 at 4:45 AM, Nicolas Pitre n...@fluxnic.net wrote: On Tue, 6 Jul 2010, Ohad Ben-Cohen wrote: From: Ohad Ben-Cohen oh...@ti.com Add support for software emulation of card detect events. This is required for specific controllers that are hard wired with embedded SDIO devices (such as TI's wl1271 WLAN device). Why? Many instances of hardwired SDIO based WLAN devices do exist already, and they don't need extra card detect events to be generated. The core MMC code already triggers a probe for cards whenever a new host controller is registered. We prefer not to power up the chip as early as boot time; instead, we would like to have it powered off until the wlan interface is brought up, power it on when the interface is brought up, and power it off again as soon as the interface is brought down again (to minimize power consumption when the wlan is not in use). For that we can't rely on the probing done when the controller is registered, we want to have a mechanism to allow dynamic detection and removal of the card. Note: the wl1271 device does support standard card detection, but AFAIK there's a limitation to use that with the specific omap controller the device is hardwired to. I will try to get more info about that, but probably Madhu can comment on that better. Board-specific configuration is required to enable this software card detect control. Could you elaborate please? Please check out the last patch - that patch is doing that configuration. In essence, this virtual card detect mechanism is enabled only for specific controllers which we know there's an embedded sdio device hardwired to. This knowledge is board-specific, and that's why we enable this mechanism in the board files, per a specific mmc controller. Thanks, Ohad. Nicolas -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/15] omap: hsmmc: add virtual card detect support
On Tue, Jul 6, 2010 at 1:22 PM, Ohad Ben-Cohen o...@wizery.com wrote: Note: the wl1271 device does support standard card detection, but AFAIK there's a limitation to use that with the specific omap controller the device is hardwired to. I will try to get more info about that, but probably Madhu can comment on that better. Some correction and additional info: The wl1271 device has an issue which makes the standard card detect mechanism irrelevant: it is always up, even if the power enable gpio input of the device is down (the power enable input does not supply the power to the chip, it's just logical digital high/low input upon which the device reacts). That's why we must use software control for emulating card detect with that device. In addition, as far as I could find out, the card detect mechanism on the ZOOM is implemented by mechanical means, and thus is not relevant for hardwired embedded SDIO devices (I'm not even sure card detect is supported for the 3rd mmc controller). -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/15] omap: hsmmc: add virtual card detect support
On Tue, Jul 6, 2010 at 2:02 PM, Roger Quadros roger.quad...@nokia.com wrote: On 07/06/2010 01:22 PM, ext Ohad Ben-Cohen wrote: We prefer not to power up the chip as early as boot time; instead, we Why? Let's say you boot your device but never use WLAN. In this scenario, we prefer the wl1271 device to stay powered off to minimize power consumption. This way we will power on the wl1271 device only when the user actually turns WLAN on. The function driver should power it down later if required. no? Care to explain this ? I'm not sure I'm following: the sdio function is added and the sdio driver is probed only after you power on the wl1271 device and let the mmc layer initialize and configure it. Why would you want to do that if WLAN is disabled (i.e. user didn't turn wlan on) ? If it was powered OFF then how did the wlan interface come into picture? As soon as you insmod wl1271 and wl1271_sdio, you will have a wlan interface (which is still down). At this point the wl1271 device is still powered off and not consuming power. If the user chooses to enable wlan (i.e. ifconfig wlan0 up), the chip is powered on, it is initialized and configured by the mmc layer, and then it can be used for WLAN activities. I agree, we some how need to power down the card when not in use in the right way. In this patchset proposal, as soon as the user disables wlan (i.e. ifconfig wlan0 down), the wl1271 device is powered off, and the corresponding sdio function is removed. Thanks, Ohad. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/15] wireless: wl1271: introduce platform device support
Hi Roger, On Tue, Jul 6, 2010 at 1:35 PM, Roger Quadros roger.quad...@nokia.com wrote: My point is that shouldn't this be handled by SDIO core? Care to explain what you mean / give a code example ? If there are no users for the SDIO function and the card, doesn't the SDIO core power down the slot and take care of re-initialization when it is powered up? You need card detect events in order to trigger card sdio function initialization and removals. Please share any alternative approach you may be thinking on. Thanks, Ohad. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/15] omap: hsmmc: add virtual card detect support
On Tue, Jul 6, 2010 at 3:39 PM, Roger Quadros roger.quad...@nokia.com wrote: Just to clarify, is the wl1271 device always powered on the board? Yes. And this GPIO power enable (OMAP_ZOOM_WLAN_PMENA_GPIO) is used to gate this supply internally? Yes. It's a digital input that the chip does not draw current from (well, only a very minimal one). and what do these do ? set_bit(WL1271_FLAG_GPIO_POWER, wl-flags); clear_bit(WL1271_FLAG_GPIO_POWER, wl-flags); This is an internal driver bit that maintains the power state of the chip. AFAICT, it does not do anything. The only place I can see it is being used is in a debugfs entry. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 14/15] omap: zoom: add WLAN device
Hi Roger,
On Tue, Jul 6, 2010 at 3:33 PM, Roger Quadros roger.quad...@nokia.com wrote:
+static void omap_zoom_wlan_power(bool enable)
+{
+ int val = enable ? 1 : 0;
+
+ pr_info(%s: set power %d\n, __func__, val);
+
+ gpio_set_value(OMAP_ZOOM_WLAN_PMENA_GPIO, val);
+}
Can we consider that OMAP_ZOOM_WLAN_PMENA_GPIO is equivalent to vmmc supply
or equivalent to supply voltage to the SDIO card?
Not really, this gpio does not supply power to the chip. It's only a
digital indication that instructs the chip to go into on or off mode.
Thanks,
Ohad.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 04/15] mmc: support embedded data field in mmc_host
On Tue, Jul 6, 2010 at 6:49 PM, Grazvydas Ignotas nota...@gmail.com wrote: Hm, do we really need a Kconfig option just for a single pointer? It only saves sizeof(void *) bytes per host, but adds rather confusing config option for users and some ifdef complexity. No strong feelings about it, I can remove that if preferred. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 00/15] wlan+omap+mmc: out-of-the-box WLAN support for ZOOM2/3
From: Ohad Ben-Cohen oh...@ti.com The ZOOM2/3 boards include TI's wl1271 wlan sdio device, hardwired to the 3rd mmc controller. These patches add support for WLAN on the ZOOM2/3 boards using only mainline components (most notably mac80211 and wl1271). Patches were tested on both ZOOM2 and ZOOM3. In short, these patches add software control for emulating card detect events, add board configurations to support the wl1271 device, and update the wl1271 driver to make use of these new mechanisms. Software card detect emulation is based on Android's EMBEDDED_SDIO patch by San Mehat s...@google.com (thanks, San!). These patches span over several differnt subsystems, but since they are highly dependent on each other, it is preferrable to pull them all together into a single tree (once approved). Patches are available at: git://wizery.com/pub/linux-2.6.git wl1271 And will also be sent as a follow-on to this message to the omap, mmc, arm and wireless mailing lists. Patches are based on mainline 2.6.35-rc4, but can easily be applied on wireless-testing (with two minor conflicts). If desired, I can rebase to wireless-testing and resend. Note: last missing part for full mainline community support of the wl1271 on ZOOM is the firmware, and for that there is already on-going TI work to provide it in linux-firmware. Hopefully that would be resolved soon. Thanks, Ohad Ben-Cohen (15): sdio: add TI + wl1271 ids wireless: wl1271: remove SDIO IDs from driver omap: mmc: prepare for software card detect support mmc: support embedded data field in mmc_host omap: hsmmc: add virtual card detect support omap zoom2: wlan board muxing omap zoom3: wlan board muxing wireless: wl1271: make wl12xx.h common to both spi and sdio wireless: wl12xx: support pdata SDIO handlers wireless: wl1271: support return value for the set power func wireless: wl1271: introduce platform device support wireless: wl1271: take irq info from platform data wireless: wl1271: make ref_clock configurable by board omap: zoom: add WLAN device omap: zoom: enable WLAN device arch/arm/mach-omap2/Kconfig |5 + arch/arm/mach-omap2/Makefile |1 + arch/arm/mach-omap2/board-zoom-peripherals.c | 15 ++ arch/arm/mach-omap2/board-zoom-wlan.c | 129 arch/arm/mach-omap2/board-zoom2.c | 15 ++ arch/arm/mach-omap2/board-zoom3.c | 15 ++ arch/arm/mach-omap2/hsmmc.c |4 + arch/arm/mach-omap2/hsmmc.h |5 + arch/arm/mach-omap2/include/mach/board-zoom.h |5 + arch/arm/plat-omap/include/plat/mmc.h |5 + drivers/mmc/core/Kconfig |8 + drivers/mmc/host/omap_hsmmc.c | 37 +- drivers/net/wireless/wl12xx/Kconfig |1 + drivers/net/wireless/wl12xx/wl1251_sdio.c |2 +- drivers/net/wireless/wl12xx/wl1251_spi.c |2 +- drivers/net/wireless/wl12xx/wl1271.h |8 +- drivers/net/wireless/wl12xx/wl1271_boot.c | 13 +- drivers/net/wireless/wl12xx/wl1271_boot.h |1 - drivers/net/wireless/wl12xx/wl1271_io.h |8 +- drivers/net/wireless/wl12xx/wl1271_main.c |4 +- drivers/net/wireless/wl12xx/wl1271_sdio.c | 204 +++-- drivers/net/wireless/wl12xx/wl1271_spi.c |8 +- include/linux/mmc/host.h | 16 ++ include/linux/mmc/sdio_ids.h |3 + include/linux/spi/wl12xx.h| 34 include/linux/wl12xx.h| 37 + 26 files changed, 486 insertions(+), 99 deletions(-) create mode 100644 arch/arm/mach-omap2/board-zoom-wlan.c delete mode 100644 include/linux/spi/wl12xx.h create mode 100644 include/linux/wl12xx.h -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 01/15] sdio: add TI + wl1271 ids
From: Ohad Ben-Cohen oh...@ti.com Add SDIO IDs for TI and for TI's wl1271 wlan device. Signed-off-by: Ohad Ben-Cohen oh...@ti.com --- include/linux/mmc/sdio_ids.h |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/include/linux/mmc/sdio_ids.h b/include/linux/mmc/sdio_ids.h index 33b2ea0..0d313c6 100644 --- a/include/linux/mmc/sdio_ids.h +++ b/include/linux/mmc/sdio_ids.h @@ -43,4 +43,7 @@ #define SDIO_DEVICE_ID_SIANO_NOVA_A0 0x1100 #define SDIO_DEVICE_ID_SIANO_STELLAR 0x5347 +#define SDIO_VENDOR_ID_TI 0x0097 +#define SDIO_DEVICE_ID_TI_WL1271 0x4076 + #endif -- 1.7.0.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 02/15] wireless: wl1271: remove SDIO IDs from driver
From: Ohad Ben-Cohen oh...@ti.com
Remove SDIO IDs from the driver code since now it is
included in linux/mmc/sdio_ids.h.
Signed-off-by: Ohad Ben-Cohen oh...@ti.com
---
drivers/net/wireless/wl12xx/wl1271_sdio.c |8
1 files changed, 0 insertions(+), 8 deletions(-)
diff --git a/drivers/net/wireless/wl12xx/wl1271_sdio.c
b/drivers/net/wireless/wl12xx/wl1271_sdio.c
index d3d6f30..9903ae9 100644
--- a/drivers/net/wireless/wl12xx/wl1271_sdio.c
+++ b/drivers/net/wireless/wl12xx/wl1271_sdio.c
@@ -37,14 +37,6 @@
#define RX71_WL1271_IRQ_GPIO 42
-#ifndef SDIO_VENDOR_ID_TI
-#define SDIO_VENDOR_ID_TI 0x0097
-#endif
-
-#ifndef SDIO_DEVICE_ID_TI_WL1271
-#define SDIO_DEVICE_ID_TI_WL1271 0x4076
-#endif
-
static const struct sdio_device_id wl1271_devices[] = {
{ SDIO_DEVICE(SDIO_VENDOR_ID_TI, SDIO_DEVICE_ID_TI_WL1271) },
{}
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 03/15] omap: mmc: prepare for software card detect support
From: Ohad Ben-Cohen oh...@ti.com
Make it possible for board files to give the
host controller two handlers needed for emulating
card detect events in software:
* The virtual_get_cd handler will allow the host
controller to query the status of the software
card detect (for the given controller/slot).
* The register_embedded_control will allow the host
controller to register handlers that will be used by
board devices to:
1. trigger a software card detect event
2. set private data (e.g. device context) that can later
be used by an sdio function driver
Signed-off-by: Ohad Ben-Cohen oh...@ti.com
---
arch/arm/mach-omap2/hsmmc.c |4
arch/arm/mach-omap2/hsmmc.h |5 +
arch/arm/plat-omap/include/plat/mmc.h |5 +
3 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/hsmmc.c b/arch/arm/mach-omap2/hsmmc.c
index 1ef54b0..1361128 100644
--- a/arch/arm/mach-omap2/hsmmc.c
+++ b/arch/arm/mach-omap2/hsmmc.c
@@ -269,6 +269,10 @@ void __init omap2_hsmmc_init(struct omap2_hsmmc_info
*controllers)
mmc-slots[0].remux = c-remux;
+ mmc-slots[0].register_embedded_control =
+ c-register_embedded_control;
+ mmc-slots[0].virtual_get_cd = c-virtual_get_cd;
+
if (c-cover_only)
mmc-slots[0].cover = 1;
diff --git a/arch/arm/mach-omap2/hsmmc.h b/arch/arm/mach-omap2/hsmmc.h
index 36f0ba8..dc12c90 100644
--- a/arch/arm/mach-omap2/hsmmc.h
+++ b/arch/arm/mach-omap2/hsmmc.h
@@ -23,6 +23,11 @@ struct omap2_hsmmc_info {
int ocr_mask; /* temporary HACK */
/* Remux (pad configuation) when powering on/off */
void (*remux)(struct device *dev, int slot, int power_on);
+ /* following methods are for embedded sdio devices, e.g. wl1271 */
+ int (*register_embedded_control)(void *dev_id,
+ void (*set_virtual_cd)(void *dev_id, int card_present),
+ void (*set_embedded_data)(void *dev_id, void *priv));
+ int (*virtual_get_cd)(void);
};
#if defined(CONFIG_MMC_OMAP_HS) || defined(CONFIG_MMC_OMAP_HS_MODULE)
diff --git a/arch/arm/plat-omap/include/plat/mmc.h
b/arch/arm/plat-omap/include/plat/mmc.h
index c835f1e..0f5bf12 100644
--- a/arch/arm/plat-omap/include/plat/mmc.h
+++ b/arch/arm/plat-omap/include/plat/mmc.h
@@ -140,6 +140,11 @@ struct omap_mmc_platform_data {
unsigned int ban_openended:1;
+ /* Embedded SDIO devices control */
+ int (*register_embedded_control)(void *dev_id,
+ void (*set_virtual_cd)(void *dev_id, int card_present),
+ void (*set_embedded_data)(void *dev_id, void *priv));
+ int (*virtual_get_cd)(void);
} slots[OMAP_MMC_MAX_SLOTS];
};
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 04/15] mmc: support embedded data field in mmc_host
From: Ohad Ben-Cohen oh...@ti.com
Add support to set/get mmc_host private embedded
data.
This is needed to allow software to dynamically
create (and remove) SDIO functions which represents
embedded SDIO devices.
Typically, it will be used to set the context of
a driver that is creating a new SDIO function
(and would then expect to be able to get that context
back upon creation of the new sdio func).
Signed-off-by: Ohad Ben-Cohen oh...@ti.com
---
drivers/mmc/core/Kconfig |8
include/linux/mmc/host.h | 16
2 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/core/Kconfig b/drivers/mmc/core/Kconfig
index bb22ffd..ab27eb3 100644
--- a/drivers/mmc/core/Kconfig
+++ b/drivers/mmc/core/Kconfig
@@ -16,3 +16,11 @@ config MMC_UNSAFE_RESUME
This option sets a default which can be overridden by the
module parameter removable=0 or removable=1.
+
+config MMC_EMBEDDED_SDIO
+ boolean MMC embedded SDIO device support
+ help
+ If you say Y here, support will be added for embedded SDIO
+ devices (e.g. hardwired embedded WLAN SDIO devices).
+ Such devices require software support for emulating
+ card detect events.
diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
index f65913c..9a48486 100644
--- a/include/linux/mmc/host.h
+++ b/include/linux/mmc/host.h
@@ -209,6 +209,10 @@ struct mmc_host {
struct led_trigger *led; /* activity led */
#endif
+#ifdef CONFIG_MMC_EMBEDDED_SDIO
+ void*embedded_data;
+#endif
+
struct dentry *debugfs_root;
unsigned long private[0] cacheline_aligned;
@@ -264,5 +268,17 @@ static inline void mmc_set_disable_delay(struct mmc_host
*host,
host-disable_delay = disable_delay;
}
+#ifdef CONFIG_MMC_EMBEDDED_SDIO
+static inline void *mmc_get_embedded_data(struct mmc_host *host)
+{
+ return host-embedded_data;
+}
+
+static inline void mmc_set_embedded_data(struct mmc_host *host, void *data)
+{
+ host-embedded_data = data;
+}
+#endif
+
#endif
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 05/15] omap: hsmmc: add virtual card detect support
From: Ohad Ben-Cohen oh...@ti.com
Add support for software emulation of card detect
events.
This is required for specific controllers
that are hard wired with embedded SDIO devices
(such as TI's wl1271 WLAN device).
Board-specific configuration is required to
enable this software card detect control.
Based on Android's EMBEDDED SDIO patch by
San Mehat s...@android.com.
Signed-off-by: Ohad Ben-Cohen oh...@ti.com
---
drivers/mmc/host/omap_hsmmc.c | 37 -
1 files changed, 36 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index b032828..60694df 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1208,6 +1208,38 @@ static void omap_hsmmc_detect(struct work_struct *work)
mmc_detect_change(host-mmc, (HZ * 50) / 1000);
}
+#ifdef CONFIG_MMC_EMBEDDED_SDIO
+static void omap_hsmmc_set_embedded_data(void *dev_id, void *priv)
+{
+ struct omap_hsmmc_host *host = dev_id;
+ struct mmc_host *mmc = host-mmc;
+
+ mmc_set_embedded_data(mmc, priv);
+}
+
+static void omap_hsmmc_virtual_detect(void *dev_id, int carddetect)
+{
+ struct omap_hsmmc_host *host = dev_id;
+
+ printk(KERN_DEBUG %s: card detect %d\n, mmc_hostname(host-mmc),
+ carddetect);
+
+ sysfs_notify(host-mmc-class_dev.kobj, NULL, cover_switch);
+
+ if (carddetect)
+ mmc_detect_change(host-mmc, (HZ * 200) / 1000);
+ else
+ mmc_detect_change(host-mmc, (HZ * 50) / 1000);
+}
+#else
+static void omap_hsmmc_set_embedded_data(void *dev_id, void *priv)
+{
+}
+static void omap_hsmmc_virtual_detect(void *dev_id, int carddetect)
+{
+}
+#endif
+
/*
* ISR for handling card insertion and removal
*/
@@ -2170,7 +2202,10 @@ static int __init omap_hsmmc_probe(struct
platform_device *pdev)
Unable to grab MMC CD IRQ\n);
goto err_irq_cd;
}
- }
+ } else if (mmc_slot(host).register_embedded_control)
+ mmc_slot(host).register_embedded_control(host,
+ omap_hsmmc_virtual_detect,
+ omap_hsmmc_set_embedded_data);
omap_hsmmc_disable_irq(host);
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 06/15] omap zoom2: wlan board muxing
From: Ohad Ben-Cohen oh...@ti.com
Add board muxing to support the wlan wl1271 chip that is
hardwired to mmc2 (third mmc controller) on the ZOOM2.
Signed-off-by: Ohad Ben-Cohen oh...@ti.com
---
arch/arm/mach-omap2/board-zoom2.c | 15 +++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-zoom2.c
b/arch/arm/mach-omap2/board-zoom2.c
index 803ef14..00871be 100644
--- a/arch/arm/mach-omap2/board-zoom2.c
+++ b/arch/arm/mach-omap2/board-zoom2.c
@@ -71,6 +71,21 @@ static struct twl4030_platform_data zoom2_twldata = {
#ifdef CONFIG_OMAP_MUX
static struct omap_board_mux board_mux[] __initdata = {
+#ifdef CONFIG_OMAP_ZOOM_WLAN
+ /* WLAN IRQ - GPIO 162 */
+ OMAP3_MUX(MCBSP1_CLKX, OMAP_MUX_MODE4 | OMAP_PIN_INPUT_PULLUP),
+ /* WLAN POWER ENABLE - GPIO 101 */
+ OMAP3_MUX(CAM_D2, OMAP_MUX_MODE4 | OMAP_PIN_OUTPUT),
+ /* WLAN SDIO: MMC3 CMD */
+ OMAP3_MUX(MCSPI1_CS1, OMAP_MUX_MODE3 | OMAP_PIN_INPUT_PULLUP),
+ /* WLAN SDIO: MMC3 CLK */
+ OMAP3_MUX(ETK_CLK, OMAP_MUX_MODE2 | OMAP_PIN_INPUT_PULLUP),
+ /* WLAN SDIO: MMC3 DAT[0-3] */
+ OMAP3_MUX(ETK_D3, OMAP_MUX_MODE2 | OMAP_PIN_INPUT_PULLUP),
+ OMAP3_MUX(ETK_D4, OMAP_MUX_MODE2 | OMAP_PIN_INPUT_PULLUP),
+ OMAP3_MUX(ETK_D5, OMAP_MUX_MODE2 | OMAP_PIN_INPUT_PULLUP),
+ OMAP3_MUX(ETK_D6, OMAP_MUX_MODE2 | OMAP_PIN_INPUT_PULLUP),
+#endif
{ .reg_offset = OMAP_MUX_TERMINATOR },
};
#else
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 07/15] omap zoom3: wlan board muxing
From: Ohad Ben-Cohen oh...@ti.com
Add board muxing to support the wlan wl1271 chip that is
hardwired to mmc2 (third mmc controller) on the ZOOM3.
Signed-off-by: Ohad Ben-Cohen oh...@ti.com
---
arch/arm/mach-omap2/board-zoom3.c | 15 +++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-zoom3.c
b/arch/arm/mach-omap2/board-zoom3.c
index 3314704..0b62663 100644
--- a/arch/arm/mach-omap2/board-zoom3.c
+++ b/arch/arm/mach-omap2/board-zoom3.c
@@ -46,6 +46,21 @@ static void __init omap_zoom_init_irq(void)
#ifdef CONFIG_OMAP_MUX
static struct omap_board_mux board_mux[] __initdata = {
+#ifdef CONFIG_OMAP_ZOOM_WLAN
+ /* WLAN IRQ - GPIO 162 */
+ OMAP3_MUX(MCBSP1_CLKX, OMAP_MUX_MODE4 | OMAP_PIN_INPUT_PULLUP),
+ /* WLAN POWER ENABLE - GPIO 101 */
+ OMAP3_MUX(CAM_D2, OMAP_MUX_MODE4 | OMAP_PIN_OUTPUT),
+ /* WLAN SDIO: MMC3 CMD */
+ OMAP3_MUX(MCSPI1_CS1, OMAP_MUX_MODE3 | OMAP_PIN_INPUT_PULLUP),
+ /* WLAN SDIO: MMC3 CLK */
+ OMAP3_MUX(ETK_CLK, OMAP_MUX_MODE2 | OMAP_PIN_INPUT_PULLUP),
+ /* WLAN SDIO: MMC3 DAT[0-3] */
+ OMAP3_MUX(ETK_D3, OMAP_MUX_MODE2 | OMAP_PIN_INPUT_PULLUP),
+ OMAP3_MUX(ETK_D4, OMAP_MUX_MODE2 | OMAP_PIN_INPUT_PULLUP),
+ OMAP3_MUX(ETK_D5, OMAP_MUX_MODE2 | OMAP_PIN_INPUT_PULLUP),
+ OMAP3_MUX(ETK_D6, OMAP_MUX_MODE2 | OMAP_PIN_INPUT_PULLUP),
+#endif
{ .reg_offset = OMAP_MUX_TERMINATOR },
};
#else
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 08/15] wireless: wl1271: make wl12xx.h common to both spi and sdio
From: Ohad Ben-Cohen oh...@ti.com
Move wl12xx.h outside of the spi-specific location,
so it can be shared with both spi and sdio solutions.
Signed-off-by: Ohad Ben-Cohen oh...@ti.com
---
drivers/net/wireless/wl12xx/wl1251_sdio.c |2 +-
drivers/net/wireless/wl12xx/wl1251_spi.c |2 +-
drivers/net/wireless/wl12xx/wl1271_spi.c |2 +-
include/linux/spi/wl12xx.h| 34 -
include/linux/wl12xx.h| 34 +
5 files changed, 37 insertions(+), 37 deletions(-)
delete mode 100644 include/linux/spi/wl12xx.h
create mode 100644 include/linux/wl12xx.h
diff --git a/drivers/net/wireless/wl12xx/wl1251_sdio.c
b/drivers/net/wireless/wl12xx/wl1251_sdio.c
index c561332..416d5aa 100644
--- a/drivers/net/wireless/wl12xx/wl1251_sdio.c
+++ b/drivers/net/wireless/wl12xx/wl1251_sdio.c
@@ -24,7 +24,7 @@
#include linux/mmc/sdio_func.h
#include linux/mmc/sdio_ids.h
#include linux/platform_device.h
-#include linux/spi/wl12xx.h
+#include linux/wl12xx.h
#include linux/irq.h
#include wl1251.h
diff --git a/drivers/net/wireless/wl12xx/wl1251_spi.c
b/drivers/net/wireless/wl12xx/wl1251_spi.c
index e814742..4847b6a 100644
--- a/drivers/net/wireless/wl12xx/wl1251_spi.c
+++ b/drivers/net/wireless/wl12xx/wl1251_spi.c
@@ -26,7 +26,7 @@
#include linux/slab.h
#include linux/crc7.h
#include linux/spi/spi.h
-#include linux/spi/wl12xx.h
+#include linux/wl12xx.h
#include wl1251.h
#include wl1251_reg.h
diff --git a/drivers/net/wireless/wl12xx/wl1271_spi.c
b/drivers/net/wireless/wl12xx/wl1271_spi.c
index 5189b81..e866049 100644
--- a/drivers/net/wireless/wl12xx/wl1271_spi.c
+++ b/drivers/net/wireless/wl12xx/wl1271_spi.c
@@ -25,7 +25,7 @@
#include linux/module.h
#include linux/crc7.h
#include linux/spi/spi.h
-#include linux/spi/wl12xx.h
+#include linux/wl12xx.h
#include linux/slab.h
#include wl1271.h
diff --git a/include/linux/spi/wl12xx.h b/include/linux/spi/wl12xx.h
deleted file mode 100644
index a223ecb..000
--- a/include/linux/spi/wl12xx.h
+++ /dev/null
@@ -1,34 +0,0 @@
-/*
- * This file is part of wl12xx
- *
- * Copyright (C) 2009 Nokia Corporation
- *
- * Contact: Kalle Valo kalle.v...@nokia.com
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License
- * version 2 as published by the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful, but
- * WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
- * General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
- * 02110-1301 USA
- *
- */
-
-#ifndef _LINUX_SPI_WL12XX_H
-#define _LINUX_SPI_WL12XX_H
-
-struct wl12xx_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;
-};
-
-#endif
diff --git a/include/linux/wl12xx.h b/include/linux/wl12xx.h
new file mode 100644
index 000..137ac89
--- /dev/null
+++ b/include/linux/wl12xx.h
@@ -0,0 +1,34 @@
+/*
+ * This file is part of wl12xx
+ *
+ * Copyright (C) 2009 Nokia Corporation
+ *
+ * Contact: Kalle Valo kalle.v...@nokia.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ *
+ */
+
+#ifndef _LINUX_WL12XX_H
+#define _LINUX_WL12XX_H
+
+struct wl12xx_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;
+};
+
+#endif
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 09/15] wireless: wl12xx: support pdata SDIO handlers
From: Ohad Ben-Cohen oh...@ti.com
Make it possible for board code to send SDIO handlers to
the wl12xx driver.
These SDIO handlers are needed to allow software to trigger
card detect events for hard-wired SDIO devices such as the
wl1271 device.
Signed-off-by: Ohad Ben-Cohen oh...@ti.com
---
drivers/net/wireless/wl12xx/wl1271.h |4
include/linux/wl12xx.h |2 ++
2 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/wl12xx/wl1271.h
b/drivers/net/wireless/wl12xx/wl1271.h
index 6f1b6b5..fc4d122 100644
--- a/drivers/net/wireless/wl12xx/wl1271.h
+++ b/drivers/net/wireless/wl12xx/wl1271.h
@@ -356,6 +356,10 @@ struct wl1271 {
struct wl1271_if_operations *if_ops;
void (*set_power)(bool enable);
+ /* SDIO card detect emulation */
+ void (*set_carddetect)(bool card_present);
+ void (*set_embedded_data)(void *priv);
+
int irq;
spinlock_t wl_lock;
diff --git a/include/linux/wl12xx.h b/include/linux/wl12xx.h
index 137ac89..4106184 100644
--- a/include/linux/wl12xx.h
+++ b/include/linux/wl12xx.h
@@ -26,6 +26,8 @@
struct wl12xx_platform_data {
void (*set_power)(bool enable);
+ void (*set_carddetect)(bool card_present);
+ void (*set_embedded_data)(void *priv);
/* SDIO only: IRQ number if WLAN_IRQ line is used, 0 for SDIO IRQs */
int irq;
bool use_eeprom;
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 11/15] wireless: wl1271: introduce platform device support
From: Ohad Ben-Cohen oh...@ti.com
Introduce a platform device support which is decoupled
from the life cycle of the sdio function.
The platform device objective is to deliver board-specific
values (like irq, ref_clock, and software card-detect
emulation control).
The driver can then dynamically create (or destroy)
the sdio function whenever the wlan interface is
brought up (or down), as part of the power() operation.
Signed-off-by: Ohad Ben-Cohen oh...@ti.com
---
drivers/net/wireless/wl12xx/Kconfig |1 +
drivers/net/wireless/wl12xx/wl1271.h |1 +
drivers/net/wireless/wl12xx/wl1271_sdio.c | 185 +++--
3 files changed, 150 insertions(+), 37 deletions(-)
diff --git a/drivers/net/wireless/wl12xx/Kconfig
b/drivers/net/wireless/wl12xx/Kconfig
index 337fc7b..8fb7b5a 100644
--- a/drivers/net/wireless/wl12xx/Kconfig
+++ b/drivers/net/wireless/wl12xx/Kconfig
@@ -66,6 +66,7 @@ config WL1271_SPI
config WL1271_SDIO
tristate TI wl1271 SDIO support
depends on WL1271 MMC ARM
+ select MMC_EMBEDDED_SDIO
---help---
This module adds support for the SDIO interface of adapters using
TI wl1271 chipset. Select this if your platform is using
diff --git a/drivers/net/wireless/wl12xx/wl1271.h
b/drivers/net/wireless/wl12xx/wl1271.h
index 5250361..2df57cc 100644
--- a/drivers/net/wireless/wl12xx/wl1271.h
+++ b/drivers/net/wireless/wl12xx/wl1271.h
@@ -352,6 +352,7 @@ struct wl1271 {
bool mac80211_registered;
void *if_priv;
+ void *if_plat_priv;
struct wl1271_if_operations *if_ops;
diff --git a/drivers/net/wireless/wl12xx/wl1271_sdio.c
b/drivers/net/wireless/wl12xx/wl1271_sdio.c
index 571c6b9..96b8fc3 100644
--- a/drivers/net/wireless/wl12xx/wl1271_sdio.c
+++ b/drivers/net/wireless/wl12xx/wl1271_sdio.c
@@ -28,6 +28,10 @@
#include linux/mmc/sdio_func.h
#include linux/mmc/sdio_ids.h
#include linux/mmc/card.h
+#include linux/mmc/host.h
+#include linux/completion.h
+#include linux/wl12xx.h
+#include linux/platform_device.h
#include plat/gpio.h
#include wl1271.h
@@ -36,6 +40,7 @@
#define RX71_WL1271_IRQ_GPIO 42
+static DECLARE_COMPLETION(wl1271_sdio_ready);
static const struct sdio_device_id wl1271_devices[] = {
{ SDIO_DEVICE(SDIO_VENDOR_ID_TI, SDIO_DEVICE_ID_TI_WL1271) },
@@ -50,7 +55,9 @@ static inline struct sdio_func *wl_to_func(struct wl1271 *wl)
static struct device *wl1271_sdio_wl_to_dev(struct wl1271 *wl)
{
- return (wl_to_func(wl)-dev);
+ struct platform_device *pdev = wl-if_plat_priv;
+
+ return pdev-dev;
}
static irqreturn_t wl1271_irq(int irq, void *cookie)
@@ -146,21 +153,44 @@ static void wl1271_sdio_raw_write(struct wl1271 *wl, int
addr, void *buf,
static int wl1271_sdio_set_power(struct wl1271 *wl, bool enable)
{
- struct sdio_func *func = wl_to_func(wl);
+ int ret = 0, timeleft;
- /* Let the SDIO stack handle wlan_enable control, so we
-* keep host claimed while wlan is in use to keep wl1271
-* alive.
-*/
if (enable) {
- sdio_claim_host(func);
- sdio_enable_func(func);
+ /* save our wl struct as private mmc data */
+ wl-set_embedded_data(wl);
+
+ INIT_COMPLETION(wl1271_sdio_ready);
+ /* 1271 Power Up Sequence */
+ wl-set_power(true);
+ mdelay(15);
+ wl-set_power(false);
+ mdelay(1);
+ wl-set_power(true);
+ mdelay(70);
+
+ /* emulate card detect event */
+ wl-set_carddetect(true);
+
} else {
- sdio_disable_func(func);
- sdio_release_host(func);
+ wl-set_embedded_data(NULL);
+
+ INIT_COMPLETION(wl1271_sdio_ready);
+
+ wl-set_power(false);
+ mdelay(10);
+
+ wl-set_carddetect(false);
}
- return 0;
+ timeleft = wait_for_completion_interruptible_timeout(wl1271_sdio_ready,
+ msecs_to_jiffies(5000));
+ if (timeleft = 0) {
+ wl1271_error(%s: unsuccessful SDIO %s (%d), __func__,
+ enable ? init : deinit, timeleft);
+ ret = (timeleft == 0 ? -EAGAIN : timeleft);
+ }
+
+ return ret;
}
static struct wl1271_if_operations sdio_ops = {
@@ -174,30 +204,97 @@ static struct wl1271_if_operations sdio_ops = {
.disable_irq= wl1271_sdio_disable_interrupts
};
-static int __devinit wl1271_probe(struct sdio_func *func,
+static int wl1271_sdio_probe(struct sdio_func *func,
const struct sdio_device_id *id)
{
+ struct wl1271 *wl = mmc_get_embedded_data(func-card-host);
+
+ /* 2nd func is WLAN, make sure wl context is received */
+ if (func-num != 0x02 || !wl)
+ return -ENODEV
[PATCH 10/15] wireless: wl1271: support return value for the set power func
From: Ohad Ben-Cohen oh...@ti.com
Make it possible for the set power method to indicate a
success/failure return value. This is needed to support
more complex power on/off operations such as bringing up
(and down) sdio functions.
Signed-off-by: Ohad Ben-Cohen oh...@ti.com
---
drivers/net/wireless/wl12xx/wl1271.h |2 +-
drivers/net/wireless/wl12xx/wl1271_io.h |8 +---
drivers/net/wireless/wl12xx/wl1271_main.c |4 +++-
drivers/net/wireless/wl12xx/wl1271_sdio.c |4 +++-
drivers/net/wireless/wl12xx/wl1271_spi.c |4 +++-
5 files changed, 15 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wireless/wl12xx/wl1271.h
b/drivers/net/wireless/wl12xx/wl1271.h
index fc4d122..5250361 100644
--- a/drivers/net/wireless/wl12xx/wl1271.h
+++ b/drivers/net/wireless/wl12xx/wl1271.h
@@ -340,7 +340,7 @@ struct wl1271_if_operations {
bool fixed);
void (*reset)(struct wl1271 *wl);
void (*init)(struct wl1271 *wl);
- void (*power)(struct wl1271 *wl, bool enable);
+ int (*power)(struct wl1271 *wl, bool enable);
struct device* (*dev)(struct wl1271 *wl);
void (*enable_irq)(struct wl1271 *wl);
void (*disable_irq)(struct wl1271 *wl);
diff --git a/drivers/net/wireless/wl12xx/wl1271_io.h
b/drivers/net/wireless/wl12xx/wl1271_io.h
index bc806c7..4a5b92c 100644
--- a/drivers/net/wireless/wl12xx/wl1271_io.h
+++ b/drivers/net/wireless/wl12xx/wl1271_io.h
@@ -144,10 +144,12 @@ static inline void wl1271_power_off(struct wl1271 *wl)
clear_bit(WL1271_FLAG_GPIO_POWER, wl-flags);
}
-static inline void wl1271_power_on(struct wl1271 *wl)
+static inline int wl1271_power_on(struct wl1271 *wl)
{
- wl-if_ops-power(wl, true);
- set_bit(WL1271_FLAG_GPIO_POWER, wl-flags);
+ int ret = wl-if_ops-power(wl, true);
+ if (ret == 0)
+ set_bit(WL1271_FLAG_GPIO_POWER, wl-flags);
+ return ret;
}
diff --git a/drivers/net/wireless/wl12xx/wl1271_main.c
b/drivers/net/wireless/wl12xx/wl1271_main.c
index b7d9137..6bd748e 100644
--- a/drivers/net/wireless/wl12xx/wl1271_main.c
+++ b/drivers/net/wireless/wl12xx/wl1271_main.c
@@ -620,7 +620,9 @@ static int wl1271_chip_wakeup(struct wl1271 *wl)
int ret = 0;
msleep(WL1271_PRE_POWER_ON_SLEEP);
- wl1271_power_on(wl);
+ ret = wl1271_power_on(wl);
+ if (ret 0)
+ goto out;
msleep(WL1271_POWER_ON_SLEEP);
wl1271_io_reset(wl);
wl1271_io_init(wl);
diff --git a/drivers/net/wireless/wl12xx/wl1271_sdio.c
b/drivers/net/wireless/wl12xx/wl1271_sdio.c
index 9903ae9..571c6b9 100644
--- a/drivers/net/wireless/wl12xx/wl1271_sdio.c
+++ b/drivers/net/wireless/wl12xx/wl1271_sdio.c
@@ -144,7 +144,7 @@ static void wl1271_sdio_raw_write(struct wl1271 *wl, int
addr, void *buf,
}
-static void wl1271_sdio_set_power(struct wl1271 *wl, bool enable)
+static int wl1271_sdio_set_power(struct wl1271 *wl, bool enable)
{
struct sdio_func *func = wl_to_func(wl);
@@ -159,6 +159,8 @@ static void wl1271_sdio_set_power(struct wl1271 *wl, bool
enable)
sdio_disable_func(func);
sdio_release_host(func);
}
+
+ return 0;
}
static struct wl1271_if_operations sdio_ops = {
diff --git a/drivers/net/wireless/wl12xx/wl1271_spi.c
b/drivers/net/wireless/wl12xx/wl1271_spi.c
index e866049..85a167f 100644
--- a/drivers/net/wireless/wl12xx/wl1271_spi.c
+++ b/drivers/net/wireless/wl12xx/wl1271_spi.c
@@ -313,10 +313,12 @@ static irqreturn_t wl1271_irq(int irq, void *cookie)
return IRQ_HANDLED;
}
-static void wl1271_spi_set_power(struct wl1271 *wl, bool enable)
+static int wl1271_spi_set_power(struct wl1271 *wl, bool enable)
{
if (wl-set_power)
wl-set_power(enable);
+
+ return 0;
}
static struct wl1271_if_operations spi_ops = {
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 12/15] wireless: wl1271: take irq info from platform data
From: Ohad Ben-Cohen oh...@ti.com
Remove the hard coded irq information, and instead take
the irq information from the platform-specific data
which is supplied by the board device.
Signed-off-by: Ohad Ben-Cohen oh...@ti.com
---
drivers/net/wireless/wl12xx/wl1271_sdio.c |9 +++--
1 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/wl12xx/wl1271_sdio.c
b/drivers/net/wireless/wl12xx/wl1271_sdio.c
index 96b8fc3..0af0dce 100644
--- a/drivers/net/wireless/wl12xx/wl1271_sdio.c
+++ b/drivers/net/wireless/wl12xx/wl1271_sdio.c
@@ -38,8 +38,6 @@
#include wl12xx_80211.h
#include wl1271_io.h
-
-#define RX71_WL1271_IRQ_GPIO 42
static DECLARE_COMPLETION(wl1271_sdio_ready);
static const struct sdio_device_id wl1271_devices[] = {
@@ -286,8 +284,6 @@ static int wl1271_plat_probe(struct platform_device *pdev)
goto out_free;
}
- wl-irq = gpio_to_irq(RX71_WL1271_IRQ_GPIO);
-
wl-set_power = pdata-set_power;
if (!wl-set_power) {
wl1271_error(set power function missing in platform data);
@@ -295,9 +291,10 @@ static int wl1271_plat_probe(struct platform_device *pdev)
goto out_free;
}
+ wl-irq = pdata-irq;
if (wl-irq 0) {
- ret = wl-irq;
- wl1271_error(could not get irq!);
+ wl1271_error(irq missing in platform data);
+ ret = -ENODEV;
goto out_free;
}
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 13/15] wireless: wl1271: make ref_clock configurable by board
From: Ohad Ben-Cohen oh...@ti.com
The wl1271 device is using a reference clock that may change
between board to board.
Make the ref_clock parameter configurable by the board
files that set up the device, instead of having a hard coded
value in the driver source itself.
Signed-off-by: Ohad Ben-Cohen oh...@ti.com
---
drivers/net/wireless/wl12xx/wl1271.h |1 +
drivers/net/wireless/wl12xx/wl1271_boot.c | 13 +
drivers/net/wireless/wl12xx/wl1271_boot.h |1 -
drivers/net/wireless/wl12xx/wl1271_sdio.c |2 ++
drivers/net/wireless/wl12xx/wl1271_spi.c |2 ++
include/linux/wl12xx.h|1 +
6 files changed, 15 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/wl12xx/wl1271.h
b/drivers/net/wireless/wl12xx/wl1271.h
index 2df57cc..cb3126d 100644
--- a/drivers/net/wireless/wl12xx/wl1271.h
+++ b/drivers/net/wireless/wl12xx/wl1271.h
@@ -362,6 +362,7 @@ struct wl1271 {
void (*set_embedded_data)(void *priv);
int irq;
+ int ref_clock;
spinlock_t wl_lock;
diff --git a/drivers/net/wireless/wl12xx/wl1271_boot.c
b/drivers/net/wireless/wl12xx/wl1271_boot.c
index 1a36d8a..fa1b8b9 100644
--- a/drivers/net/wireless/wl12xx/wl1271_boot.c
+++ b/drivers/net/wireless/wl12xx/wl1271_boot.c
@@ -455,17 +455,22 @@ int wl1271_boot(struct wl1271 *wl)
{
int ret = 0;
u32 tmp, clk, pause;
+ int ref_clock = wl-ref_clock;
wl1271_boot_hw_version(wl);
- if (REF_CLOCK == 0 || REF_CLOCK == 2 || REF_CLOCK == 4)
+ if (ref_clock == 0 || ref_clock == 2 || ref_clock == 4)
/* ref clk: 19.2/38.4/38.4-XTAL */
clk = 0x3;
- else if (REF_CLOCK == 1 || REF_CLOCK == 3)
+ else if (ref_clock == 1 || ref_clock == 3)
/* ref clk: 26/52 */
clk = 0x5;
+ else {
+ ret = -EINVAL;
+ goto out;
+ }
- if (REF_CLOCK != 0) {
+ if (ref_clock != 0) {
u16 val;
/* Set clock type (open drain) */
val = wl1271_top_reg_read(wl, OCP_REG_CLK_TYPE);
@@ -514,7 +519,7 @@ int wl1271_boot(struct wl1271 *wl)
wl1271_debug(DEBUG_BOOT, clk2 0x%x, clk);
/* 2 */
- clk |= (REF_CLOCK 1) 4;
+ clk |= (ref_clock 1) 4;
wl1271_write32(wl, DRPW_SCRATCH_START, clk);
wl1271_set_partition(wl, part_table[PART_WORK]);
diff --git a/drivers/net/wireless/wl12xx/wl1271_boot.h
b/drivers/net/wireless/wl12xx/wl1271_boot.h
index f829699..f73b0b1 100644
--- a/drivers/net/wireless/wl12xx/wl1271_boot.h
+++ b/drivers/net/wireless/wl12xx/wl1271_boot.h
@@ -46,7 +46,6 @@ struct wl1271_static_data {
/* delay between retries */
#define INIT_LOOP_DELAY 50
-#define REF_CLOCK2
#define WU_COUNTER_PAUSE_VAL 0x3FF
#define WELP_ARM_COMMAND_VAL 0x4
diff --git a/drivers/net/wireless/wl12xx/wl1271_sdio.c
b/drivers/net/wireless/wl12xx/wl1271_sdio.c
index 0af0dce..4ed097f 100644
--- a/drivers/net/wireless/wl12xx/wl1271_sdio.c
+++ b/drivers/net/wireless/wl12xx/wl1271_sdio.c
@@ -270,6 +270,8 @@ static int wl1271_plat_probe(struct platform_device *pdev)
wl-if_plat_priv = pdev;
platform_set_drvdata(pdev, wl);
+ wl-ref_clock = pdata-board_ref_clock;
+
wl-set_embedded_data = pdata-set_embedded_data;
if (!wl-set_embedded_data) {
wl1271_error(set embedded_data func missing in platform data);
diff --git a/drivers/net/wireless/wl12xx/wl1271_spi.c
b/drivers/net/wireless/wl12xx/wl1271_spi.c
index 85a167f..2cb125b 100644
--- a/drivers/net/wireless/wl12xx/wl1271_spi.c
+++ b/drivers/net/wireless/wl12xx/wl1271_spi.c
@@ -373,6 +373,8 @@ static int __devinit wl1271_probe(struct spi_device *spi)
goto out_free;
}
+ wl-ref_clock = pdata-ref_clock;
+
wl-irq = spi-irq;
if (wl-irq 0) {
wl1271_error(irq missing in platform data);
diff --git a/include/linux/wl12xx.h b/include/linux/wl12xx.h
index 4106184..9053d9c 100644
--- a/include/linux/wl12xx.h
+++ b/include/linux/wl12xx.h
@@ -31,6 +31,7 @@ struct wl12xx_platform_data {
/* SDIO only: IRQ number if WLAN_IRQ line is used, 0 for SDIO IRQs */
int irq;
bool use_eeprom;
+ int board_ref_clock;
};
#endif
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 14/15] omap: zoom: add WLAN device
From: Ohad Ben-Cohen oh...@ti.com
Add WLAN platform device and control
functions (power and virtual card detect)
in order to allow software to control the
embedded SDIO WLAN device which resides on
the ZOOM board (TI's wl1271 device).
Based on Android's WLAN control functions by
San Mehat s...@android.com.
Signed-off-by: Ohad Ben-Cohen oh...@ti.com
---
arch/arm/mach-omap2/board-zoom-wlan.c | 129 +
arch/arm/mach-omap2/include/mach/board-zoom.h |5 +
2 files changed, 134 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/board-zoom-wlan.c
diff --git a/arch/arm/mach-omap2/board-zoom-wlan.c
b/arch/arm/mach-omap2/board-zoom-wlan.c
new file mode 100644
index 000..7ed5139
--- /dev/null
+++ b/arch/arm/mach-omap2/board-zoom-wlan.c
@@ -0,0 +1,129 @@
+/* mach-omap2/board-zoom-wlan.c
+ *
+ * Board support for wl1271 embedded SDIO device.
+ *
+ * Copyright (C) 2010 Texas Instruments, Inc.
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed as is without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include linux/kernel.h
+#include linux/init.h
+#include linux/platform_device.h
+#include linux/mmc/host.h
+#include linux/mmc/sdio_ids.h
+#include linux/err.h
+#include linux/gpio.h
+#include linux/wl12xx.h
+
+#include mux.h
+
+#ifdef CONFIG_OMAP_ZOOM_WLAN
+
+/* these are zoom-specific board numbers */
+#define OMAP_ZOOM_WLAN_PMENA_GPIO (101)
+#define OMAP_ZOOM_WLAN_IRQ_GPIO(162)
+
+/* wl1271 virtual 'card detect' status */
+static int omap_zoom_wlan_cd;
+static void (*wlan_set_virtual_cd)(void *dev_id, int card_present);
+static void (*wlan_set_data)(void *dev_id, void *priv);
+static void *wlan_host_devid;
+
+int omap_zoom_wlan_register_embedded_control(void *dev_id,
+ void (*set_virtual_cd)(void *dev_id, int card_present),
+ void (*set_data)(void *dev_id, void *priv))
+{
+ if (wlan_host_devid || wlan_set_virtual_cd || wlan_set_data)
+ return -EBUSY;
+
+ wlan_set_virtual_cd = set_virtual_cd;
+ wlan_set_data = set_data;
+ wlan_host_devid = dev_id;
+
+ return 0;
+}
+
+int omap_zoom_wlan_get_virtual_cd(void)
+{
+ return omap_zoom_wlan_cd;
+}
+
+static void omap_zoom_wlan_set_embedded_data(void *priv)
+{
+ if (wlan_set_data)
+ wlan_set_data(wlan_host_devid, priv);
+ else
+ pr_err(%s: host controller not registered yet\n, __func__);
+}
+
+static void omap_zoom_wlan_set_carddetect(bool card_present)
+{
+ omap_zoom_wlan_cd = card_present ? 1 : 0;
+
+ pr_info(%s: %d\n, __func__, omap_zoom_wlan_cd);
+
+ if (wlan_set_virtual_cd)
+ wlan_set_virtual_cd(wlan_host_devid, omap_zoom_wlan_cd);
+ else
+ pr_err(%s: host controller not registered yet\n, __func__);
+}
+
+static void omap_zoom_wlan_power(bool enable)
+{
+ int val = enable ? 1 : 0;
+
+ pr_info(%s: set power %d\n, __func__, val);
+
+ gpio_set_value(OMAP_ZOOM_WLAN_PMENA_GPIO, val);
+}
+
+struct wl12xx_platform_data omap_zoom_wlan_control = {
+ .set_power = omap_zoom_wlan_power,
+ .set_carddetect = omap_zoom_wlan_set_carddetect,
+ .set_embedded_data = omap_zoom_wlan_set_embedded_data,
+ /* ZOOM ref clock is 26 MHz */
+ .board_ref_clock = 1,
+ .irq = OMAP_GPIO_IRQ(OMAP_ZOOM_WLAN_IRQ_GPIO),
+};
+
+static struct platform_device omap_zoom_wlan_device = {
+ .name = wl1271_sdio,
+ .id = 1,
+ .dev = {
+ .platform_data = omap_zoom_wlan_control,
+ },
+};
+
+int __init omap_zoom_wlan_init(void)
+{
+ int ret;
+
+ ret = gpio_request(OMAP_ZOOM_WLAN_PMENA_GPIO, wlan_power);
+ if (ret 0) {
+ pr_err(%s: power gpio request failed: %d\n, __func__, ret);
+ return ret;
+ }
+
+ gpio_direction_output(OMAP_ZOOM_WLAN_PMENA_GPIO, 0);
+
+ ret = gpio_request(OMAP_ZOOM_WLAN_IRQ_GPIO, wlan_irq);
+ if (ret 0) {
+ pr_err(%s: gpio request failed: %d\n, __func__, ret);
+ return ret;
+ }
+ gpio_direction_input(OMAP_ZOOM_WLAN_IRQ_GPIO);
+
+ ret = platform_device_register(omap_zoom_wlan_device);
+
+ return ret;
+}
+
+#else
+int __init omap_zoom_wlan_init(void)
+{
+ return 0;
+}
+#endif /* CONFIG_OMAP_ZOOM_WLAN */
diff --git a/arch/arm/mach-omap2/include/mach/board-zoom.h
b/arch/arm/mach-omap2/include/mach/board-zoom.h
index c93b29e..61bbd81 100644
--- a/arch/arm/mach-omap2/include/mach/board-zoom.h
+++ b/arch/arm/mach-omap2/include/mach/board-zoom.h
@@ -3,3 +3,8 @@
*/
extern int __init zoom_debugboard_init(void);
extern void __init zoom_peripherals_init(void);
+int __init omap_zoom_wlan_init(void);
+int omap_zoom_wlan_register_embedded_control(void *dev_id,
+ void (*set_virtual_cd)(void *dev_id, int card_present
[PATCH 15/15] omap: zoom: enable WLAN device
From: Ohad Ben-Cohen oh...@ti.com
Make it possible to build and use TI's wl1271
device on the ZOOM boards.
The device is an embedded SDIO WLAN chip
that is hardwired to the 3rd mmc controller
of the ZOOM2/3 boards.
Signed-off-by: Ohad Ben-Cohen oh...@ti.com
---
arch/arm/mach-omap2/Kconfig |5 +
arch/arm/mach-omap2/Makefile |1 +
arch/arm/mach-omap2/board-zoom-peripherals.c | 15 +++
3 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index b31b6f1..7fee11b 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -131,6 +131,11 @@ config MACH_OMAP_ZOOM3
depends on ARCH_OMAP3
select OMAP_PACKAGE_CBP
+config OMAP_ZOOM_WLAN
+ bool OMAP Zoom board WLAN support
+ depends on MACH_OMAP_ZOOM2 || MACH_OMAP_ZOOM3
+ select MMC_EMBEDDED_SDIO
+
config MACH_CM_T35
bool CompuLab CM-T35 module
depends on ARCH_OMAP3
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index ea52b03..ac1bad9 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -129,6 +129,7 @@ obj-$(CONFIG_MACH_OMAP_ZOOM3) +=
board-zoom3.o \
board-zoom-peripherals.o \
hsmmc.o \
board-zoom-debugboard.o
+obj-y += board-zoom-wlan.o
obj-$(CONFIG_MACH_OMAP_3630SDP)+= board-3630sdp.o \
board-zoom-peripherals.o \
hsmmc.o
diff --git a/arch/arm/mach-omap2/board-zoom-peripherals.c
b/arch/arm/mach-omap2/board-zoom-peripherals.c
index 6b39849..3128cd4 100644
--- a/arch/arm/mach-omap2/board-zoom-peripherals.c
+++ b/arch/arm/mach-omap2/board-zoom-peripherals.c
@@ -16,11 +16,13 @@
#include linux/gpio.h
#include linux/i2c/twl.h
#include linux/regulator/machine.h
+#include linux/mmc/host.h
#include asm/mach-types.h
#include asm/mach/arch.h
#include asm/mach/map.h
+#include mach/board-zoom.h
#include plat/common.h
#include plat/usb.h
@@ -168,6 +170,18 @@ static struct omap2_hsmmc_info mmc[] __initdata = {
.nonremovable = true,
.power_saving = true,
},
+#ifdef CONFIG_OMAP_ZOOM_WLAN
+ {
+ .mmc= 3,
+ .wires = 4,
+ .gpio_cd= -EINVAL,
+ .gpio_wp= -EINVAL,
+ .register_embedded_control =
+ omap_zoom_wlan_register_embedded_control,
+ .virtual_get_cd = omap_zoom_wlan_get_virtual_cd,
+ .ocr_mask = MMC_VDD_165_195,
+ },
+#endif
{} /* Terminator */
};
@@ -282,4 +296,5 @@ void __init zoom_peripherals_init(void)
omap_i2c_init();
usb_musb_init(musb_board_data);
enable_board_wakeup_source();
+ omap_zoom_wlan_init();
}
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 1/6] omap: add iva2 hwmod support to omap3
On Fri, Jul 2, 2010 at 8:43 AM, Cousson, Benoit b-cous...@ti.com wrote:
On 7/2/2010 12:23 AM, Ohad Ben-Cohen wrote:
From: Ohad Ben-Cohenoh...@ti.com
Add preliminary iva2 hwmod support to omap3.
We do not include iva2_clk; that will be part of a separate
hwmod, which will be controlled by iommu.
I think Kevin already sent a hwmod for IVA2... one week ago:
Thanks. I somehow missed the bulk of those patches.
I will of course rebase omap3 remoteproc on top of that now.
[PATCH 13/13] OMAP3: hwmod data: add data for OMAP3 IVA2
Signed-off-by: Ohad Ben-Cohenoh...@ti.com
Signed-off-by: Hari Kanigerih-kanige...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_34xx.h | 23 +++
arch/arm/plat-omap/include/plat/omap_hwmod.h | 1 +
2 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_34xx.h
b/arch/arm/mach-omap2/omap_hwmod_34xx.h
index b6076b9..d363a95 100644
--- a/arch/arm/mach-omap2/omap_hwmod_34xx.h
+++ b/arch/arm/mach-omap2/omap_hwmod_34xx.h
@@ -22,6 +22,7 @@
#include prm-regbits-34xx.h
static struct omap_hwmod omap34xx_mpu_hwmod;
+static struct omap_hwmod omap34xx_iva2_hwmod;
static struct omap_hwmod omap34xx_l3_hwmod;
static struct omap_hwmod omap34xx_l4_core_hwmod;
static struct omap_hwmod omap34xx_l4_per_hwmod;
@@ -47,9 +48,17 @@ static struct omap_hwmod_ocp_if omap34xx_mpu__l3 = {
.user = OCP_USER_MPU,
};
+/* IVA2 - L3 interface */
+static struct omap_hwmod_ocp_if omap34xx_iva2__l3 = {
+ .master =omap34xx_iva2_hwmod,
+ .slave =omap34xx_l3_hwmod,
+ .user = OCP_USER_IVA2,
+};
+
/* Slave interfaces on the L3 interconnect */
static struct omap_hwmod_ocp_if *omap34xx_l3_slaves[] = {
omap34xx_mpu__l3,
+ omap34xx_iva2__l3,
};
/* Master interfaces on the L3 interconnect */
@@ -150,12 +159,26 @@ static struct omap_hwmod omap34xx_mpu_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
};
+/* Master interfaces on the IVA2 device */
+static struct omap_hwmod_ocp_if *omap34xx_iva2_masters[] = {
+ omap34xx_iva2__l3,
+};
+
+/* IVA2 */
+static struct omap_hwmod omap34xx_iva2_hwmod = {
+ .name = iva2_hwmod,
Should be iva only.
+ .masters = omap34xx_iva2_masters,
+ .masters_cnt = ARRAY_SIZE(omap34xx_iva2_masters),
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
+};
+
static __initdata struct omap_hwmod *omap34xx_hwmods[] = {
omap34xx_l3_hwmod,
omap34xx_l4_core_hwmod,
omap34xx_l4_per_hwmod,
omap34xx_l4_wkup_hwmod,
omap34xx_mpu_hwmod,
+ omap34xx_iva2_hwmod,
NULL,
};
diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h
b/arch/arm/plat-omap/include/plat/omap_hwmod.h
index 3393325..5e64992 100644
--- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
+++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
@@ -160,6 +160,7 @@ struct omap_hwmod_addr_space {
*/
#define OCP_USER_MPU (1 0)
#define OCP_USER_SDMA (1 1)
+#define OCP_USER_IVA2 (1 2)
Are you going to use that information somewhere?
In that case, you should populate the address space view from the DSP.
Benoit
/* omap_hwmod_ocp_if.flags bits */
#define OCPIF_HAS_IDLEST (1 0)
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] omap mailbox: extend API to take a callback param
Hi Hiroshi,
Please consider waiting with pulling of these three patches.
After discussions in l-o, we realized some more work is needed to
support OMAP4 multiple senders scenarios.
Such work can completely replace these 3 patches (retaining their
functionality but adding multiple senders/receivers support).
Thanks,
Ohad.
On Fri, Jul 2, 2010 at 3:05 PM, Hiroshi DOYU hiroshi.d...@nokia.com wrote:
From: ext Ohad Ben-Cohen o...@wizery.com
Let mailbox users set the callback pointer via the
omap_mbox_get API, instead of having users directly
manipulating the mailbox structures.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
Signed-off-by: Hiroshi DOYU hiroshi.d...@nokia.com
---
arch/arm/plat-omap/include/plat/mailbox.h | 2 +-
arch/arm/plat-omap/mailbox.c | 4 +++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/mailbox.h
b/arch/arm/plat-omap/include/plat/mailbox.h
index 9976565..0b45664 100644
--- a/arch/arm/plat-omap/include/plat/mailbox.h
+++ b/arch/arm/plat-omap/include/plat/mailbox.h
@@ -62,7 +62,7 @@ struct omap_mbox {
int omap_mbox_msg_send(struct omap_mbox *, mbox_msg_t msg);
void omap_mbox_init_seq(struct omap_mbox *);
-struct omap_mbox *omap_mbox_get(const char *);
+struct omap_mbox *omap_mbox_get(const char *name, int (*callback)(void *));
void omap_mbox_put(struct omap_mbox *);
int omap_mbox_register(struct device *parent, struct omap_mbox **);
diff --git a/arch/arm/plat-omap/mailbox.c b/arch/arm/plat-omap/mailbox.c
index d2fafb8..14b716d 100644
--- a/arch/arm/plat-omap/mailbox.c
+++ b/arch/arm/plat-omap/mailbox.c
@@ -305,7 +305,7 @@ static void omap_mbox_fini(struct omap_mbox *mbox)
}
}
-struct omap_mbox *omap_mbox_get(const char *name)
+struct omap_mbox *omap_mbox_get(const char *name, int (*callback)(void *))
{
struct omap_mbox *mbox;
int ret;
@@ -324,6 +324,8 @@ struct omap_mbox *omap_mbox_get(const char *name)
if (ret)
return ERR_PTR(-ENODEV);
+ mbox-rxq-callback = callback;
+
return mbox;
}
EXPORT_SYMBOL(omap_mbox_get);
--
1.7.1.rc2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] omap mailbox: extend API to take a callback param
On Fri, Jul 2, 2010 at 3:23 PM, Hiroshi DOYU hiroshi.d...@nokia.com wrote: It would be nice if you send patches to LOML and LAKML too for next time. Sure. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 0/6] Introducing OMAP Remote Processor module
From: Ohad Ben-Cohen oh...@ti.com This is a preliminary version of OMAP's remoteproc module, submitted for RFC purposes. The purpose of the remoteproc module is to decouple hw-specific code from generic IPC drivers (such as dspbridge and syslink), in order to eventually make those IPC drivers platform-independent. Currently the supported operations are starting and stopping the remote processor, but in the future additional functionality might be added. Both OMAP3 and OMAP4 are supported; OMAP3 supports the dsp remote processor, and OMAP4 supports ducati (tesla support is planned as well). The code was tested on both OMAP3 (using dspbridge) and OMAP4 (using syslink). The code is preliminary: we plan to add much more extensive hwmod support, ideally squashing as much hw-specific code as possible (including RST and PRCM manipulations). In addition, a rebase to recent code bases is needed. While dspbridge accesses remoteproc's interface via pdata pointers, syslink accesses it from user space, via character device interface, so both kernel and user space interfaces are supported. A few words on the char device interface: * Each remote processor is represented by a different character device: /dev/omap-rproc0, /dev/omap-rproc1, ... * A rproc character device can only be opened by a single user (e.g. the syslink daemon) * The start/stop/get_state functionality is exposed via ioctl's * We plan to add automatic stop() invokation in case the user closes the device after starting a remote processor (for resource cleanup purposes. Thus the user will be required to hold the device open as long as it lives). Thanks, Hari Kanigeri (1): omap: introduce OMAP4 remoteproc module Ohad Ben-Cohen (5): omap: add iva2 hwmod support to omap3 omap: introduce OMAP3 remoteproc module omap: introduce common remoteproc module omap: add remoteproc device(s) omap: enable remoteproc building arch/arm/mach-omap2/Makefile |6 + arch/arm/mach-omap2/devices.c| 86 +++ arch/arm/mach-omap2/omap_hwmod_34xx.h| 23 ++ arch/arm/mach-omap2/remoteproc3xxx.c | 226 ++ arch/arm/mach-omap2/remoteproc44xx.c | 196 arch/arm/plat-omap/Kconfig |7 + arch/arm/plat-omap/Makefile |1 + arch/arm/plat-omap/include/plat/omap_hwmod.h |1 + arch/arm/plat-omap/include/plat/remoteproc.h | 75 ++ arch/arm/plat-omap/remoteproc.c | 316 ++ 10 files changed, 937 insertions(+), 0 deletions(-) create mode 100644 arch/arm/mach-omap2/remoteproc3xxx.c create mode 100644 arch/arm/mach-omap2/remoteproc44xx.c create mode 100644 arch/arm/plat-omap/include/plat/remoteproc.h create mode 100644 arch/arm/plat-omap/remoteproc.c -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 1/6] omap: add iva2 hwmod support to omap3
From: Ohad Ben-Cohen oh...@ti.com
Add preliminary iva2 hwmod support to omap3.
We do not include iva2_clk; that will be part of a separate
hwmod, which will be controlled by iommu.
Signed-off-by: Ohad Ben-Cohen oh...@ti.com
Signed-off-by: Hari Kanigeri h-kanige...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_34xx.h| 23 +++
arch/arm/plat-omap/include/plat/omap_hwmod.h |1 +
2 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_34xx.h
b/arch/arm/mach-omap2/omap_hwmod_34xx.h
index b6076b9..d363a95 100644
--- a/arch/arm/mach-omap2/omap_hwmod_34xx.h
+++ b/arch/arm/mach-omap2/omap_hwmod_34xx.h
@@ -22,6 +22,7 @@
#include prm-regbits-34xx.h
static struct omap_hwmod omap34xx_mpu_hwmod;
+static struct omap_hwmod omap34xx_iva2_hwmod;
static struct omap_hwmod omap34xx_l3_hwmod;
static struct omap_hwmod omap34xx_l4_core_hwmod;
static struct omap_hwmod omap34xx_l4_per_hwmod;
@@ -47,9 +48,17 @@ static struct omap_hwmod_ocp_if omap34xx_mpu__l3 = {
.user = OCP_USER_MPU,
};
+/* IVA2 - L3 interface */
+static struct omap_hwmod_ocp_if omap34xx_iva2__l3 = {
+ .master = omap34xx_iva2_hwmod,
+ .slave = omap34xx_l3_hwmod,
+ .user = OCP_USER_IVA2,
+};
+
/* Slave interfaces on the L3 interconnect */
static struct omap_hwmod_ocp_if *omap34xx_l3_slaves[] = {
omap34xx_mpu__l3,
+ omap34xx_iva2__l3,
};
/* Master interfaces on the L3 interconnect */
@@ -150,12 +159,26 @@ static struct omap_hwmod omap34xx_mpu_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
};
+/* Master interfaces on the IVA2 device */
+static struct omap_hwmod_ocp_if *omap34xx_iva2_masters[] = {
+ omap34xx_iva2__l3,
+};
+
+/* IVA2 */
+static struct omap_hwmod omap34xx_iva2_hwmod = {
+ .name = iva2_hwmod,
+ .masters= omap34xx_iva2_masters,
+ .masters_cnt= ARRAY_SIZE(omap34xx_iva2_masters),
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
+};
+
static __initdata struct omap_hwmod *omap34xx_hwmods[] = {
omap34xx_l3_hwmod,
omap34xx_l4_core_hwmod,
omap34xx_l4_per_hwmod,
omap34xx_l4_wkup_hwmod,
omap34xx_mpu_hwmod,
+ omap34xx_iva2_hwmod,
NULL,
};
diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h
b/arch/arm/plat-omap/include/plat/omap_hwmod.h
index 3393325..5e64992 100644
--- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
+++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
@@ -160,6 +160,7 @@ struct omap_hwmod_addr_space {
*/
#define OCP_USER_MPU (1 0)
#define OCP_USER_SDMA (1 1)
+#define OCP_USER_IVA2 (1 2)
/* omap_hwmod_ocp_if.flags bits */
#define OCPIF_HAS_IDLEST (1 0)
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 2/6] omap: introduce OMAP3 remoteproc module
From: Ohad Ben-Cohen oh...@ti.com
Introduce OMAP3 remoteproc module which takes care of
machine-specific code required to start and stop
the DSP remote processor.
Signed-off-by: Ohad Ben-Cohen oh...@ti.com
Signed-off-by: Hari Kanigeri h-kanige...@ti.com
---
arch/arm/mach-omap2/remoteproc3xxx.c | 226 ++
1 files changed, 226 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/remoteproc3xxx.c
diff --git a/arch/arm/mach-omap2/remoteproc3xxx.c
b/arch/arm/mach-omap2/remoteproc3xxx.c
new file mode 100644
index 000..f86a333
--- /dev/null
+++ b/arch/arm/mach-omap2/remoteproc3xxx.c
@@ -0,0 +1,226 @@
+/*
+ * Remote Processor machine-specific module for OMAP3
+ *
+ * Copyright (C) 2010 Texas Instruments Inc.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ *
+ */
+
+/* this is needed for multi-omap support */
+#ifdef CONFIG_ARCH_OMAP3
+#include linux/kernel.h
+#include linux/delay.h
+#include linux/clk.h
+#include linux/err.h
+#include linux/platform_device.h
+#include linux/io.h
+#include linux/pm_runtime.h
+#include plat/remoteproc.h
+#include mach/irqs.h
+#include plat/omap_device.h
+#include plat/control.h
+#include plat/common.h
+#include plat/powerdomain.h
+#include plat/clockdomain.h
+#include asm/uaccess.h
+
+#include cm-regbits-34xx.h
+#include prm-regbits-34xx.h
+
+#define OMAP3_IVA2_BOOTADDR_MASK 0xFC00
+
+#define PRCM_PM_PWSTCTRL_IVA2_POWER_STATE_MASK (u32)(3)
+#define PRCM_PM_PWSTCTRL_IVA2_POWER_STATE_OFFSET (u32)(0)
+
+#define PRCM_PM_PWSTST_IVA2_InTransition_MASK (u32)(0x10)
+#define PRCM_PM_PWSTST_IVA2_InTransition_OFFSET(u32)(20)
+
+#define CM_CLKSTCTRL_IVA2_OFFSET (0)
+#define CM_CLKSTCTRL_IVA2_MASK (3)
+
+#define DSP_SYSC_DIRECTBOOT(0)
+#define DSP_SYSC_IDLEBOOT (1)
+#define DSP_SYSC_SELFLOOPBOOT (2)
+#define DSP_SYSC_USRBOOTSTRAP (3)
+#define DSP_SYSC_DEFAULTRESTORE(4)
+
+#ifdef CONFIG_BRIDGE_DEBUG
+static void omap3_rproc_dump_regs(struct device *dev)
+{
+ u32 temp;
+
+ temp = cm_read_mod_reg(OMAP3430_IVA2_MOD, CM_FCLKEN);
+ dev_info(dev, CM_FCLKEN_IVA2 = 0x%x \n, temp);
+ temp = cm_read_mod_reg(OMAP3430_IVA2_MOD, CM_ICLKEN1);
+ dev_info(dev, CM_ICLKEN1_IVA2 = 0x%x \n, temp);
+ temp = cm_read_mod_reg(OMAP3430_IVA2_MOD, CM_IDLEST);
+ dev_info(dev, CM_IDLEST_IVA2 = 0x%x \n, temp);
+ temp = cm_read_mod_reg(OMAP3430_IVA2_MOD, CM_CLKSTCTRL);
+ dev_info(dev, CM_CLKSTCTRL_IVA2 = 0x%x \n, temp);
+ temp = cm_read_mod_reg(OMAP3430_IVA2_MOD, OMAP3430_CM_CLKSTST);
+ dev_info(dev, CM_CLKSTST_IVA2 = 0x%x \n, temp);
+ temp = prm_read_mod_reg(OMAP3430_IVA2_MOD, RM_RSTCTRL);
+ dev_info(dev, RM_RSTCTRL_IVA2 = 0x%x \n, temp);
+ temp = prm_read_mod_reg(OMAP3430_IVA2_MOD, RM_RSTST);
+ dev_info(dev, RM_RSTST_IVA2 = 0x%x \n, temp);
+ temp = prm_read_mod_reg(OMAP3430_IVA2_MOD, PM_PWSTCTRL);
+ dev_info(dev, PM_PWSTCTRL_IVA2 = 0x%x \n, temp);
+ temp = prm_read_mod_reg(OMAP3430_IVA2_MOD, PM_PWSTST);
+ dev_info(dev, PM_PWSTST_IVA2 = 0x%x \n, temp);
+ temp = cm_read_mod_reg(CORE_MOD, CM_ICLKEN1);
+ dev_info(dev, CM_ICLKEN1_CORE = 0x%x \n, temp);
+}
+#else
+static void omap3_rproc_dump_regs(struct device *dev) { }
+#endif
+
+static int omap3_rproc_get_state(struct device *dev)
+{
+ u32 dsp_pwr_state;
+
+ dsp_pwr_state = prm_read_mod_reg(OMAP3430_IVA2_MOD, PM_PWSTST);
+
+ return dsp_pwr_state OMAP_POWERSTATEST_MASK;
+}
+
+static int omap3_rproc_start(struct device *dev, u32 start_addr)
+{
+ dev_info(dev, %s: set boot mode, addr: 0x%x\n, __func__, start_addr);
+
+ omap3_rproc_dump_regs(dev);
+
+ if (PWRDM_POWER_ON != omap3_rproc_get_state(dev)) {
+ /* IVA2 is not in ON state */
+ /* Read and set PM_PWSTCTRL_IVA2 to ON */
+ prm_rmw_mod_reg_bits(OMAP_POWERSTATEST_MASK, PWRDM_POWER_ON,
+ OMAP3430_IVA2_MOD, PM_PWSTCTRL);
+
+ /* Set the SW supervised state transition */
+ cm_write_mod_reg(OMAP34XX_CLKSTCTRL_FORCE_WAKEUP,
+ OMAP3430_IVA2_MOD, CM_CLKSTCTRL);
+
+ /* Wait until the state has moved to ON */
+ while
[RFC 3/6] omap: introduce OMAP4 remoteproc module
From: Hari Kanigeri h-kanige...@ti.com
Introduce OMAP4 machine-dependent module required
for starting and stopping the OMAP3 remote processors.
Signed-off-by: Hari Kanigeri h-kanige...@ti.com
Signed-off-by: Ohad Ben-Cohen oh...@ti.com
---
arch/arm/mach-omap2/remoteproc44xx.c | 196 ++
1 files changed, 196 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/remoteproc44xx.c
diff --git a/arch/arm/mach-omap2/remoteproc44xx.c
b/arch/arm/mach-omap2/remoteproc44xx.c
new file mode 100644
index 000..e240595
--- /dev/null
+++ b/arch/arm/mach-omap2/remoteproc44xx.c
@@ -0,0 +1,196 @@
+/*
+ * Remote Processor machine-specific module for OMAP4
+ *
+ * Copyright (C) 2010 Texas Instruments Inc.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ *
+ */
+/* this is needed for multi-omap support */
+#ifdef CONFIG_ARCH_OMAP4
+#include linux/kernel.h
+#include linux/delay.h
+#include linux/clk.h
+#include linux/err.h
+#include linux/platform_device.h
+#include linux/io.h
+#include linux/pm_runtime.h
+#include plat/remoteproc.h
+#include mach/irqs.h
+#include plat/omap_device.h
+
+#include cm.h
+#include prm.h
+
+#define RM_M3_RST1ST 0x1
+#define RM_M3_RST2ST 0x2
+#define RM_M3_RST3ST 0x4
+#define RM_M3_REL_RST1_MASK0x2
+#define RM_M3_REL_RST2_MASK0x0
+#define RM_M3_AST_RST1_MASK0x3
+#define RM_M3_AST_RST2_MASK0x2
+
+#define M3_CLK_MOD_MODE_HW_AUTO0x1
+#define M3_CLKTRCTRL_SW_WKUP 0x2
+#define M3_CLKTRCTRL_SW_SLEEP 0x1
+#define M3_CLKACTIVITY_MPU_M3_CLK 0x100
+
+static inline int omap4_rproc_get_state(struct omap_rproc *rproc)
+{
+ return rproc-state;
+}
+
+static inline int proc44x_sysm3_start(struct device *dev, u32 start_addr)
+{
+ u32 reg;
+ int counter = 10;
+
+ /* Module is managed automatically by HW */
+ cm_write_mod_reg(M3_CLK_MOD_MODE_HW_AUTO, OMAP4430_CM2_CORE_MOD,
+ OMAP4_CM_DUCATI_DUCATI_CLKCTRL_OFFSET);
+
+ /* Enable the M3 clock */
+ cm_write_mod_reg(M3_CLKTRCTRL_SW_WKUP, OMAP4430_CM2_CORE_MOD,
+ OMAP4_CM_DUCATI_CLKSTCTRL_OFFSET);
+ do {
+ reg = cm_read_mod_reg(OMAP4430_CM2_CORE_MOD,
+ OMAP4_CM_DUCATI_CLKSTCTRL_OFFSET);
+ if (reg M3_CLKACTIVITY_MPU_M3_CLK) {
+ dev_info(dev, M3 clock enabled:
+ OMAP4430_CM_DUCATI_CLKSTCTRL = 0x%x\n, reg);
+ break;
+ }
+ msleep(1);
+ } while (--counter);
+ if (counter == 0) {
+ dev_info(dev, FAILED TO ENABLE DUCATI M3 CLOCK !%x\n, reg);
+ return -EFAULT;
+ }
+
+ /* De-assert RST1, and clear the Reset status */
+ dev_info(dev, De-assert RST1\n);
+ prm_write_mod_reg(RM_M3_REL_RST1_MASK, OMAP4430_PRM_CORE_MOD,
+ OMAP4_RM_DUCATI_RSTCTRL_OFFSET);
+ while (!(prm_read_mod_reg(OMAP4430_PRM_CORE_MOD,
+ OMAP4_RM_DUCATI_RSTST_OFFSET) RM_M3_RST1ST))
+ ;
+ dev_info(dev, RST1 released!);
+
+ prm_write_mod_reg(RM_M3_RST1ST, OMAP4430_PRM_CORE_MOD,
+ OMAP4_RM_DUCATI_RSTST_OFFSET);
+
+ return 0;
+}
+
+static inline int proc44x_appm3_start(struct device *dev, u32 start_addr)
+{
+ /* De-assert RST2, and clear the Reset status */
+ dev_info(dev, De-assert RST2\n);
+ prm_write_mod_reg(RM_M3_REL_RST2_MASK, OMAP4430_PRM_CORE_MOD,
+ OMAP4_RM_DUCATI_RSTCTRL_OFFSET);
+
+ while (!(prm_read_mod_reg(OMAP4430_PRM_CORE_MOD,
+ OMAP4_RM_DUCATI_RSTST_OFFSET) RM_M3_RST2ST))
+ ;
+ dev_info(dev, RST2 released!);
+
+ prm_write_mod_reg(RM_M3_RST2ST, OMAP4430_PRM_CORE_MOD,
+ OMAP4_RM_DUCATI_RSTST_OFFSET);
+
+ return 0;
+}
+
+static inline int proc44x_sysm3_stop(struct device *dev)
+{
+ dev_info(dev, assert RST1\n);
+ prm_write_mod_reg(RM_M3_AST_RST1_MASK, OMAP4430_PRM_CORE_MOD
[RFC 4/6] omap: introduce common remoteproc module
From: Ohad Ben-Cohen oh...@ti.com
The OMAP remote processor module decouples
machine-specific code from TI's IPC
drivers (e.g. dspbridge and syslink).
While dspbridge calls the remoteproc handlers
from the kernel, syslink calls them from
user space. Hence remoteproc supports both
interfaces.
Signed-off-by: Ohad Ben-Cohen oh...@ti.com
Signed-off-by: Hari Kanigeri h-kanige...@ti.com
---
arch/arm/plat-omap/include/plat/remoteproc.h | 75 ++
arch/arm/plat-omap/remoteproc.c | 316 ++
2 files changed, 391 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/plat-omap/include/plat/remoteproc.h
create mode 100644 arch/arm/plat-omap/remoteproc.c
diff --git a/arch/arm/plat-omap/include/plat/remoteproc.h
b/arch/arm/plat-omap/include/plat/remoteproc.h
new file mode 100644
index 000..1cedd08
--- /dev/null
+++ b/arch/arm/plat-omap/include/plat/remoteproc.h
@@ -0,0 +1,75 @@
+/*
+ * OMAP Remote Processor driver
+ *
+ * Copyright (C) 2010 Texas Instruments Inc.
+ *
+ * Written by Ohad Ben-Cohen o...@wizery.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ *
+ */
+
+#ifndef REMOTEPROC_H
+#define REMOTEPROC_H
+
+#include linux/ioctl.h
+#include linux/cdev.h
+
+#define RPROC_IOC_MAGIC'P'
+
+#define RPROC_IOCSTART _IOW(RPROC_IOC_MAGIC, 1, int)
+#define RPROC_IOCSTOP _IO(RPROC_IOC_MAGIC, 2)
+#define RPROC_IOCGETSTATE _IOR(RPROC_IOC_MAGIC, 3, int)
+
+#define RPROC_IOC_MAXNR(3)
+
+struct omap_rproc;
+
+struct omap_rproc_ops {
+ int (*start)(struct device *dev, u32 start_addr);
+ int (*stop)(struct device *dev);
+ int (*get_state)(struct device *dev);
+};
+
+struct omap_rproc_clk_t {
+ void *clk_handle;
+ const char *dev_id;
+ const char *con_id;
+};
+
+struct omap_rproc_platform_data {
+ struct omap_rproc_ops *ops;
+ char *name;
+ char *oh_name;
+};
+
+struct omap_rproc {
+ struct device *dev;
+ struct cdev cdev;
+ atomic_t count;
+ int minor;
+};
+
+struct omap_rproc_start_args {
+ u32 start_addr;
+};
+
+struct omap_rproc_platform_data *omap3_get_rproc_data(void);
+int omap3_get_rproc_data_size(void);
+struct omap_rproc_platform_data *omap4_get_rproc_data(void);
+int omap4_get_rproc_data_size(void);
+int omap_get_num_of_remoteproc(void);
+
+#endif /* REMOTEPROC_H */
diff --git a/arch/arm/plat-omap/remoteproc.c b/arch/arm/plat-omap/remoteproc.c
new file mode 100644
index 000..7a9862e
--- /dev/null
+++ b/arch/arm/plat-omap/remoteproc.c
@@ -0,0 +1,316 @@
+/*
+ * OMAP Remote Processor driver
+ *
+ * Copyright (C) 2010 Texas Instruments Inc.
+ *
+ * Authors:
+ * Ohad Ben-Cohen o...@wizery.com
+ * Hari Kanigeri h-kanige...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ *
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/interrupt.h
+#include linux/device.h
+#include linux/delay.h
+#include linux/file.h
+#include linux/poll.h
+#include linux/mm.h
+#include linux/platform_device.h
+
+#include plat/remoteproc.h
+
+#define OMAP_RPROC_NAME omap-rproc
+
+static struct class *omap_rproc_class;
+static dev_t omap_rproc_dev;
+static atomic_t num_of_rprocs;
+
+static inline int rproc_start(struct omap_rproc *rproc, const void __user *arg)
+{
+ struct omap_rproc_platform_data *pdata;
+ struct omap_rproc_start_args start_args;
+
+ if (!rproc-dev)
+ return -EINVAL;
+
+ pdata = rproc-dev-platform_data;
+ if (!pdata-ops)
+ return -EINVAL;
+
+ if (copy_from_user(start_args, arg, sizeof(start_args)))
+ return -EFAULT;
+
+ return pdata-ops-start(rproc-dev, start_args.start_addr);
+}
+
+static inline int rproc_stop
[RFC 5/6] omap: add remoteproc device(s)
From: Ohad Ben-Cohen oh...@ti.com
Add an omap_device for each remote processor on the system
Signed-off-by: Ohad Ben-Cohen oh...@ti.com
Signed-off-by: Hari Kanigeri h-kanige...@ti.com
---
arch/arm/mach-omap2/devices.c | 86 +
1 files changed, 86 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 18ad931..d365db6 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -15,6 +15,7 @@
#include linux/platform_device.h
#include linux/io.h
#include linux/clk.h
+#include linux/err.h
#include mach/hardware.h
#include asm/mach-types.h
@@ -26,9 +27,13 @@
#include plat/mux.h
#include mach/gpio.h
#include plat/mmc.h
+#include plat/remoteproc.h
#include mux.h
+#include plat/omap_device.h
+#include plat/omap_hwmod.h
+
#if defined(CONFIG_VIDEO_OMAP2) || defined(CONFIG_VIDEO_OMAP2_MODULE)
static struct resource cam_resources[] = {
@@ -136,6 +141,86 @@ static inline void omap_init_camera(void)
}
#endif
+#if defined(CONFIG_OMAP_REMOTE_PROC) || defined(CONFIG_OMAP_REMOTE_PROC_MODULE)
+static struct omap_device_pm_latency omap_rproc_latency[] = {
+ {
+ .deactivate_func = omap_device_idle_hwmods,
+ .activate_func = omap_device_enable_hwmods,
+ .deactivate_lat = 1,
+ .activate_lat = 1,
+ },
+};
+
+static struct omap_rproc_platform_data *omap_get_remoteproc_data(void)
+{
+ struct omap_rproc_platform_data *rproc_data = NULL;
+
+ if (cpu_is_omap3430() || cpu_is_omap3630())
+ rproc_data = omap3_get_rproc_data();
+ else if (cpu_is_omap44xx())
+ rproc_data = omap4_get_rproc_data();
+ else
+ pr_err(%s: platform not supported\n, __func__);
+
+ return rproc_data;
+}
+
+int omap_get_num_of_remoteproc(void)
+{
+ int num = -1;
+
+ if (cpu_is_omap3430() || cpu_is_omap3630())
+ num = omap3_get_rproc_data_size();
+ else if (cpu_is_omap44xx())
+ num = omap4_get_rproc_data_size();
+ else
+ pr_err(%s: platform not supported\n, __func__);
+
+ return num;
+}
+EXPORT_SYMBOL(omap_get_num_of_remoteproc);
+
+static inline void omap_init_rproc(void)
+{
+ struct omap_hwmod *oh;
+ struct omap_device *od;
+ struct omap_device_pm_latency *ohl;
+ char *oh_name, *pdev_name;
+ int ohl_cnt = 0, i;
+ int rproc_data_size;
+ struct omap_rproc_platform_data *rproc_data;
+
+ pdev_name = omap-rproc;
+ ohl = omap_rproc_latency;
+ ohl_cnt = ARRAY_SIZE(omap_rproc_latency);
+
+ rproc_data = omap_get_remoteproc_data();
+ rproc_data_size = omap_get_num_of_remoteproc();
+ if (rproc_data == NULL || rproc_data_size = 0) {
+ pr_err(%s: platform not supported\n, __func__);
+ return;
+ }
+
+ for (i = 0; i rproc_data_size; i++) {
+ oh_name = rproc_data[i].oh_name;
+ oh = omap_hwmod_lookup(oh_name);
+ if (!oh) {
+ pr_err(%s: could not look up %s\n, __func__, oh_name);
+ continue;
+ }
+
+ od = omap_device_build(pdev_name, i, oh,
+ rproc_data[i],
+ sizeof(struct omap_rproc_platform_data),
+ ohl, ohl_cnt);
+ WARN(IS_ERR(od), Could not build omap_device for %s %s\n,
+ pdev_name, oh_name);
+ }
+}
+#else
+static inline void omap_init_rproc(void) { }
+#endif /* CONFIG_OMAP_REMOTE_PROC */
+
#if defined(CONFIG_OMAP_MBOX_FWK) || defined(CONFIG_OMAP_MBOX_FWK_MODULE)
#define MBOX_REG_SIZE 0x120
@@ -773,6 +858,7 @@ static int __init omap2_init_devices(void)
omap_hsmmc_reset();
omap_init_camera();
omap_init_mbox();
+ omap_init_rproc();
omap_init_mcspi();
omap_hdq_init();
omap_init_sti();
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 6/6] omap: enable remoteproc building
From: Ohad Ben-Cohen oh...@ti.com Make it possible to build omap's remoteproc module Signed-off-by: Ohad Ben-Cohen oh...@ti.com Signed-off-by: Hari Kanigeri h-kanige...@ti.com --- arch/arm/mach-omap2/Makefile |6 ++ arch/arm/plat-omap/Kconfig |7 +++ arch/arm/plat-omap/Makefile |1 + 3 files changed, 14 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index 307f8b0..edb65b3 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -59,6 +59,12 @@ obj-$(CONFIG_OMAP3_EMU) += emu.o obj-$(CONFIG_OMAP_MBOX_FWK)+= mailbox_mach.o mailbox_mach-objs := mailbox.o +ifneq ($(CONFIG_OMAP_REMOTE_PROC),) +obj-$(CONFIG_ARCH_OMAP2) += remoteproc24xx.o +obj-$(CONFIG_ARCH_OMAP3) += remoteproc3xxx.o +obj-$(CONFIG_ARCH_OMAP4) += remoteproc44xx.o +endif + iommu-y+= iommu2.o iommu-$(CONFIG_ARCH_OMAP3) += omap3-iommu.o diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig index e2ea04a..e7d7372 100644 --- a/arch/arm/plat-omap/Kconfig +++ b/arch/arm/plat-omap/Kconfig @@ -96,6 +96,13 @@ config OMAP_MBOX_FWK Say Y here if you want to use OMAP Mailbox framework support for DSP, IVA1.0 and IVA2 in OMAP1/2/3. +config OMAP_REMOTE_PROC + bool Remote Processor framework support + depends on ARCH_OMAP + help + Say Y here if you want to use OMAP Remote Processor framework + support for DSP, Tesla and/or Ducati (OMAP3/4). + config OMAP_IOMMU tristate diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile index 98f0191..bacb5c3 100644 --- a/arch/arm/plat-omap/Makefile +++ b/arch/arm/plat-omap/Makefile @@ -29,5 +29,6 @@ obj-y += $(i2c-omap-m) $(i2c-omap-y) # OMAP mailbox framework obj-$(CONFIG_OMAP_MBOX_FWK) += mailbox.o +obj-$(CONFIG_OMAP_REMOTE_PROC) += remoteproc.o obj-$(CONFIG_OMAP_PM_NOOP) += omap-pm-noop.o \ No newline at end of file -- 1.7.0.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] omap mailbox: extend API to take a callback param
On Fri, Jun 25, 2010 at 3:52 AM, Kanigeri, Hari h-kanige...@ti.com wrote: I don't know what PCMIIW stands for :) please correct me if I'm wrong :) It looks like the variable mbox_configured that was added previously doesn't cover all the issues. It covers the shutdown issue with reference counting but as you mentioned that it poses an issue at startup as the RX interrupt for the second mbox instance doesn't get enabled. yeah. -- Even though this might not be relevant to mbox_configured issue, this looks like a nice feature to add. So this means we are going to support multiple writers to mailbox instance? yes, multiple writers, but also it will allow multiple readers. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 06/11] staging: ti dspbridge: add generic utilities
On Wed, Jun 23, 2010 at 6:43 PM, Andy Shevchenko andy.shevche...@gmail.com wrote: ... I could prepare patch in standard form, if you want to That could be great, thanks ! -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 11/11] staging: ti dspbridge: enable driver building
From: Omar Ramirez Luna omar.rami...@ti.com Add Kconfig + Makefile for TI's DSP Bridge driver and expose it to the staging menu. For now, have tidspbridge depend on ARCH_OMAP3. That dependency should be relaxed as soon as required cleanups are applied. Signed-off-by: Omar Ramirez Luna omar.rami...@ti.com Signed-off-by: Kanigeri, Hari h-kanige...@ti.com Signed-off-by: Ameya Palande ameya.pala...@nokia.com Signed-off-by: Guzman Lugo, Fernando fernando.l...@ti.com Signed-off-by: Hebbar, Shivananda x0heb...@ti.com Signed-off-by: Ramos Falcon, Ernesto erne...@ti.com Signed-off-by: Felipe Contreras felipe.contre...@gmail.com Signed-off-by: Anna, Suman s-a...@ti.com Signed-off-by: Gupta, Ramesh grgu...@ti.com Signed-off-by: Gomez Castellanos, Ivan ivan.go...@ti.com Signed-off-by: Andy Shevchenko ext-andriy.shevche...@nokia.com Signed-off-by: Armando Uribe De Leon x0095...@ti.com Signed-off-by: Deepak Chitriki deepak.chitr...@ti.com Signed-off-by: Menon, Nishanth n...@ti.com Signed-off-by: Phil Carmody ext-phil.2.carm...@nokia.com Signed-off-by: Ohad Ben-Cohen o...@wizery.com --- drivers/staging/Kconfig |2 + drivers/staging/Makefile |1 + drivers/staging/tidspbridge/Kconfig | 88 ++ drivers/staging/tidspbridge/Makefile | 34 + 4 files changed, 125 insertions(+), 0 deletions(-) create mode 100644 drivers/staging/tidspbridge/Kconfig create mode 100644 drivers/staging/tidspbridge/Makefile diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig index cdd3ea3..ce1dfa8 100644 --- a/drivers/staging/Kconfig +++ b/drivers/staging/Kconfig @@ -151,5 +151,7 @@ source drivers/staging/msm/Kconfig source drivers/staging/easycap/Kconfig +source drivers/staging/tidspbridge/Kconfig + endif # !STAGING_EXCLUDE_BUILD endif # STAGING diff --git a/drivers/staging/Makefile b/drivers/staging/Makefile index beceaff..7849818 100644 --- a/drivers/staging/Makefile +++ b/drivers/staging/Makefile @@ -56,3 +56,4 @@ obj-$(CONFIG_FB_XGI) += xgifb/ obj-$(CONFIG_TOUCHSCREEN_MRSTOUCH) += mrst-touchscreen/ obj-$(CONFIG_MSM_STAGING) += msm/ obj-$(CONFIG_EASYCAP) += easycap/ +obj-$(CONFIG_TIDSPBRIDGE) += tidspbridge/ diff --git a/drivers/staging/tidspbridge/Kconfig b/drivers/staging/tidspbridge/Kconfig new file mode 100644 index 000..45372cd --- /dev/null +++ b/drivers/staging/tidspbridge/Kconfig @@ -0,0 +1,88 @@ +# +# DSP Bridge Driver Support +# + +menuconfig TIDSPBRIDGE + tristate DSP Bridge driver + depends on ARCH_OMAP3 + select OMAP_MBOX_FWK + help + DSP/BIOS Bridge is designed for platforms that contain a GPP and + one or more attached DSPs. The GPP is considered the master or + host processor, and the attached DSPs are processing resources + that can be utilized by applications and drivers running on the GPP. + + This driver depends on OMAP Mailbox (OMAP_MBOX_FWK). + +config BRIDGE_DVFS + bool Enable Bridge Dynamic Voltage and Frequency Scaling (DVFS) + depends on TIDSPBRIDGE OMAP_PM_SRF CPU_FREQ + default n + help + DVFS allows DSP Bridge to initiate the operating point change to + scale the chip voltage and frequency in order to match the + performance and power consumption to the current processing + requirements. + +config BRIDGE_MEMPOOL_SIZE + hex Physical memory pool size (Byte) + depends on TIDSPBRIDGE + default 0x60 + help + Allocate specified size of memory at booting time to avoid allocation + failure under heavy memory fragmentation after some use time. + +config BRIDGE_DEBUG + bool DSP Bridge Debug Support + depends on TIDSPBRIDGE + help + Say Y to enable Bridge debugging capabilities + +config BRIDGE_RECOVERY + bool DSP Recovery Support + depends on TIDSPBRIDGE + help + In case of DSP fatal error, BRIDGE driver will try to + recover itself. + +config BRIDGE_CACHE_LINE_CHECK + bool Check buffers to be 128 byte aligned + depends on TIDSPBRIDGE + default n + help + When the DSP processes data, the DSP cache controller loads 128-Byte + chunks (lines) from SDRAM and writes the data back in 128-Byte chunks. + If a DMM buffer does not start and end on a 128-Byte boundary, the data + preceding the start address (SA) from the 128-Byte boundary to the SA + and the data at addresses trailing the end address (EA) from the EA to + the next 128-Byte boundary will be loaded and written back as well. + This can lead to heap corruption. Say Y, to enforce the check for 128 + byte alignment, buffers failing this check will be rejected. + +config BRIDGE_WDT3 + bool Enable WDT3 interruptions + depends on TIDSPBRIDGE + default n + help + WTD3 is managed by DSP and once
Re: [PATCH 3/4] omap mailbox: remove mbox_configured scheme
On Thu, Jun 24, 2010 at 6:10 PM, Kanigeri, Hari h-kanige...@ti.com wrote: Ohad, mbox_configured is global and therefore does not support concurrent usage of multiple mailbox instances. -- Why do you say that it doesn't support concurrent usage of multiple mailbox instances ? If you take example of OMAP4, we have 2 mailbox instances, one talking to DSP and other to Ducati and they should be supported concurrently. Interesting. was this actually tested and found working ? AFAICT (I don't have OMAP4, this is just by looking at the code) this doesn't work: mbox_configured will prevent omap2_mbox_startup from being invoked more than once. This means that omap2_mbox_enable_irq(mbox, IRQ_RX) will only be called once too, which seems like a problem if you want to start receiving RX interrupts from both mbox instances at the same time. To fix that I guess we should decouple the RX interrupt enabling from the mbox startup function. I can write something, but I'd need your help to test it on OMAP4 :) If you remove the mbox_configured variable, then the mailbox module would shut down once the first instance calls the omap_mbox_put function. Also interesting point. So you use mbox_configures as a reference counter to allow concurrent multiple senders to the same mbox instance. I will update the previous patch (that introduced the atomic_t reference counter) to reflect this use case, thanks! Thank you, Best regards, Hari -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] omap mailbox: extend API to take a callback param
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Ohad Ben-Cohen Sent: Tuesday, June 22, 2010 7:12 PM To: linux-omap@vger.kernel.org Cc: Hiroshi Doyu; Ramirez Luna, Omar; Ohad Ben-Cohen Subject: [PATCH 1/4] omap mailbox: extend API to take a callback param Let mailbox users set the callback pointer via the omap_mbox_get API, instead of having users directly manipulating the mailbox structures. On Thu, Jun 24, 2010 at 6:02 PM, Kanigeri, Hari h-kanige...@ti.com wrote: Looks good. PCMIIW: from your other mail, I now understand that on OMAP4 you call omap_mbox_get several times to allow several concurrent mbox senders. If that's the case, this new API concept is a bit broken: it should allow several senders to call it, but will only support a single rx callback (probably by ignoring NULL callbacks, but that's not really safe). We have two options here: 1. do not extend omap_mbox_get to get a callback. instead, add a new API that explicitely sets the callback pointer. 2. do extend omap_mbox_get to get a callback, but then employ something like a notifier chain of callbacks, essentially supporting multiple callbacks. this will allow a more flexible API, something that Hiroshi also wanted. I like (2) better. What do you think ? Thanks, Ohad. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 00/11] staging: add ti dspbridge driver
Add TI's DSP Bridge driver to the staging area. TI's DSP Bridge driver supplies a direct link between host applications and DSP tasks running on a remote processor. Please pull from: git://wizery.com/pub/tidspbridge.git for-greg The patches will be sent as a follow-on to this message to lkml and l-o for people to see. The patches are the result of a staging relocation and a linux-next rebase of 85343cd5491260881b34ab7bb7cdc8fdeef078e4 at git://dev.omapzoom.org/pub/scm/tidspbridge/kernel-dspbridge.git dspbridge For more information about TI's DSP Bridge, check out the submitted documentation and also: http://omapzoom.org/gf/project/omapbridge/docman/?subdir=3 The DSP/Bridge project wish to thank all of its contributors; current bridge driver is the result of the work of all of them. The following is an alphabetical order of all contributors (that we know of. If by any chance we forgot to mention anyone, please let us know, thanks!): Suman Anna Sripal Bagadia Felipe Balbi Ohad Ben-Cohen Phil Carmody Deepak Chitriki Felipe Contreras Hiroshi Doyu Seth Forshee Ivan Gomez Castellanos Mark Grosen Ramesh Gupta G Fernando Guzman Lugo Axel Haslam Janet Head Shivananda Hebbar Hari Kanigeri Tony Lindgren Antonio Luna Hari Nagalla Nishanth Menon Ameya Palande Vijay Pasam Gilbert Pitney Omar Ramirez Luna Ernesto Ramos Chris Ring Larry Schiefer Rebecca Schultz Zavin Bhavin Shah Andy Shevchenko Jeff Taylor Roman Tereshonkov Armando Uribe de Leon Nischal Varide Wenbiao Wang Thanks, Ohad Ben-Cohen (1): staging: ti dspbridge: add TODO file Omar Ramirez Luna (10): staging: ti dspbridge: add driver documentation staging: ti dspbridge: add core driver sources staging: ti dspbridge: add platform manager code staging: ti dspbridge: add resource manager staging: ti dspbridge: add MMU support staging: ti dspbridge: add generic utilities staging: ti dspbridge: add services staging: ti dspbridge: add DOFF binaries loader staging: ti dspbridge: add header files staging: ti dspbridge: enable driver building drivers/staging/Kconfig|2 + drivers/staging/Makefile |1 + .../staging/tidspbridge/Documentation/CONTRIBUTORS | 82 + drivers/staging/tidspbridge/Documentation/README | 70 + .../staging/tidspbridge/Documentation/error-codes | 157 + drivers/staging/tidspbridge/Kconfig| 88 + drivers/staging/tidspbridge/Makefile | 34 + drivers/staging/tidspbridge/TODO | 18 + drivers/staging/tidspbridge/core/_cmm.h| 45 + drivers/staging/tidspbridge/core/_deh.h| 35 + drivers/staging/tidspbridge/core/_msg_sm.h | 142 + drivers/staging/tidspbridge/core/_tiomap.h | 377 +++ drivers/staging/tidspbridge/core/_tiomap_pwr.h | 85 + drivers/staging/tidspbridge/core/chnl_sm.c | 1015 ++ drivers/staging/tidspbridge/core/dsp-clock.c | 421 +++ drivers/staging/tidspbridge/core/io_sm.c | 2410 +++ drivers/staging/tidspbridge/core/mmu_fault.c | 139 + drivers/staging/tidspbridge/core/mmu_fault.h | 36 + drivers/staging/tidspbridge/core/msg_sm.c | 673 drivers/staging/tidspbridge/core/tiomap3430.c | 1887 drivers/staging/tidspbridge/core/tiomap3430_pwr.c | 604 drivers/staging/tidspbridge/core/tiomap_io.c | 458 +++ drivers/staging/tidspbridge/core/tiomap_io.h | 104 + drivers/staging/tidspbridge/core/ue_deh.c | 303 ++ drivers/staging/tidspbridge/core/wdt.c | 150 + drivers/staging/tidspbridge/dynload/cload.c| 1960 .../staging/tidspbridge/dynload/dload_internal.h | 351 +++ drivers/staging/tidspbridge/dynload/doff.h | 344 +++ drivers/staging/tidspbridge/dynload/getsection.c | 416 +++ drivers/staging/tidspbridge/dynload/header.h | 55 + drivers/staging/tidspbridge/dynload/module_list.h | 159 + drivers/staging/tidspbridge/dynload/params.h | 226 ++ drivers/staging/tidspbridge/dynload/reloc.c| 484 +++ drivers/staging/tidspbridge/dynload/reloc_table.h | 102 + .../tidspbridge/dynload/reloc_table_c6000.c| 257 ++ drivers/staging/tidspbridge/dynload/tramp.c| 1143 +++ .../tidspbridge/dynload/tramp_table_c6000.c| 164 + drivers/staging/tidspbridge/gen/gb.c | 167 + drivers/staging/tidspbridge/gen/gh.c | 213 ++ drivers/staging/tidspbridge/gen/gs.c | 89 + drivers/staging/tidspbridge/gen/uuidutil.c | 223 ++ drivers/staging/tidspbridge/hw/EasiGlobal.h| 41 + drivers/staging
[PATCH 01/11] staging: ti dspbridge: add driver documentation
From: Omar Ramirez Luna omar.rami...@ti.com Add a README with a general overview of TI's DSP Bridge driver, a short explanations of how error codes are currently used, and a CONTRIBUTORS file with all past present contributors. For additional information about TI's DSP Bridge, check out http://omapzoom.org/gf/project/omapbridge/docman/?subdir=3 Note: if by any chance we forgot to mention any contributor, please let us know and we will fix that. Signed-off-by: Omar Ramirez Luna omar.rami...@ti.com Signed-off-by: Kanigeri, Hari h-kanige...@ti.com Signed-off-by: Ameya Palande ameya.pala...@nokia.com Signed-off-by: Guzman Lugo, Fernando fernando.l...@ti.com Signed-off-by: Hebbar, Shivananda x0heb...@ti.com Signed-off-by: Ramos Falcon, Ernesto erne...@ti.com Signed-off-by: Felipe Contreras felipe.contre...@gmail.com Signed-off-by: Anna, Suman s-a...@ti.com Signed-off-by: Gupta, Ramesh grgu...@ti.com Signed-off-by: Gomez Castellanos, Ivan ivan.go...@ti.com Signed-off-by: Andy Shevchenko ext-andriy.shevche...@nokia.com Signed-off-by: Armando Uribe De Leon x0095...@ti.com Signed-off-by: Deepak Chitriki deepak.chitr...@ti.com Signed-off-by: Menon, Nishanth n...@ti.com Signed-off-by: Phil Carmody ext-phil.2.carm...@nokia.com Signed-off-by: Ohad Ben-Cohen o...@wizery.com --- .../staging/tidspbridge/Documentation/CONTRIBUTORS | 82 ++ drivers/staging/tidspbridge/Documentation/README | 70 + .../staging/tidspbridge/Documentation/error-codes | 157 3 files changed, 309 insertions(+), 0 deletions(-) create mode 100644 drivers/staging/tidspbridge/Documentation/CONTRIBUTORS create mode 100644 drivers/staging/tidspbridge/Documentation/README create mode 100644 drivers/staging/tidspbridge/Documentation/error-codes diff --git a/drivers/staging/tidspbridge/Documentation/CONTRIBUTORS b/drivers/staging/tidspbridge/Documentation/CONTRIBUTORS new file mode 100644 index 000..b40e7a6 --- /dev/null +++ b/drivers/staging/tidspbridge/Documentation/CONTRIBUTORS @@ -0,0 +1,82 @@ +TI DSP/Bridge Driver - Contributors File + +The DSP/Bridge project wish to thank all of its contributors, current bridge +driver is the result of the work of all of them. If any name is accidentally +omitted, let us know by sending a mail to omar.rami...@ti.com or +x095...@ti.com. + +Please keep the following list in alphabetical order. + + Suman Anna + Sripal Bagadia + Felipe Balbi + Ohad Ben-Cohen + Phil Carmody + Deepak Chitriki + Felipe Contreras + Hiroshi Doyu + Seth Forshee + Ivan Gomez Castellanos + Mark Grosen + Ramesh Gupta G + Fernando Guzman Lugo + Axel Haslam + Janet Head + Shivananda Hebbar + Hari Kanigeri + Tony Lindgren + Antonio Luna + Hari Nagalla + Nishanth Menon + Ameya Palande + Vijay Pasam + Gilbert Pitney + Omar Ramirez Luna + Ernesto Ramos + Chris Ring + Larry Schiefer + Rebecca Schultz Zavin + Bhavin Shah + Andy Shevchenko + Jeff Taylor + Roman Tereshonkov + Armando Uribe de Leon + Nischal Varide + Wenbiao Wang + + + +The following list was taken from file Revision History, if you recognize your +alias or did any contribution to the project please let us now, so we can +proper credit your work. + + ag + ap + cc + db + dh4 + dr + hp + jg + kc + kln + kw + ge + gv + map + mf + mk + mr + nn + rajesh + rg + rr + rt + sb + sg + sh + sp + srid + swa + vp + ww diff --git a/drivers/staging/tidspbridge/Documentation/README b/drivers/staging/tidspbridge/Documentation/README new file mode 100644 index 000..df6d371 --- /dev/null +++ b/drivers/staging/tidspbridge/Documentation/README @@ -0,0 +1,70 @@ +Linux DSP/BIOS Bridge release + +DSP/BIOS Bridge overview + + +DSP/BIOS Bridge is designed for platforms that contain a GPP and one or more +attached DSPs. The GPP is considered the master or host processor, and the +attached DSPs are processing resources that can be utilized by applications +and drivers running on the GPP. + +The abstraction that DSP/BIOS Bridge supplies, is a direct link between a GPP +program and a DSP task. This communication link is partitioned into two +types of sub-links: messaging (short, fixed-length packets) and data +streaming (multiple, large buffers). Each sub-link operates independently, +and features in-order delivery of data, meaning that messages are delivered +in the order they were submitted to the message link, and stream buffers are +delivered in the order they were submitted to the stream link. + +In addition, a GPP client can specify what inputs and outputs a DSP task +uses. DSP tasks typically use message
[PATCH 05/11] staging: ti dspbridge: add MMU support
From: Omar Ramirez Luna omar.rami...@ti.com Add TI's DSP Bridge MMU support Signed-off-by: Omar Ramirez Luna omar.rami...@ti.com Signed-off-by: Kanigeri, Hari h-kanige...@ti.com Signed-off-by: Ameya Palande ameya.pala...@nokia.com Signed-off-by: Guzman Lugo, Fernando fernando.l...@ti.com Signed-off-by: Hebbar, Shivananda x0heb...@ti.com Signed-off-by: Ramos Falcon, Ernesto erne...@ti.com Signed-off-by: Felipe Contreras felipe.contre...@gmail.com Signed-off-by: Anna, Suman s-a...@ti.com Signed-off-by: Gupta, Ramesh grgu...@ti.com Signed-off-by: Gomez Castellanos, Ivan ivan.go...@ti.com Signed-off-by: Andy Shevchenko ext-andriy.shevche...@nokia.com Signed-off-by: Armando Uribe De Leon x0095...@ti.com Signed-off-by: Deepak Chitriki deepak.chitr...@ti.com Signed-off-by: Menon, Nishanth n...@ti.com Signed-off-by: Phil Carmody ext-phil.2.carm...@nokia.com Signed-off-by: Ohad Ben-Cohen o...@wizery.com --- drivers/staging/tidspbridge/hw/EasiGlobal.h | 41 ++ drivers/staging/tidspbridge/hw/GlobalTypes.h | 308 ++ drivers/staging/tidspbridge/hw/MMUAccInt.h | 76 drivers/staging/tidspbridge/hw/MMURegAcM.h | 226 ++ drivers/staging/tidspbridge/hw/hw_defs.h | 60 +++ drivers/staging/tidspbridge/hw/hw_mmu.c | 587 ++ drivers/staging/tidspbridge/hw/hw_mmu.h | 161 +++ 7 files changed, 1459 insertions(+), 0 deletions(-) create mode 100644 drivers/staging/tidspbridge/hw/EasiGlobal.h create mode 100644 drivers/staging/tidspbridge/hw/GlobalTypes.h create mode 100644 drivers/staging/tidspbridge/hw/MMUAccInt.h create mode 100644 drivers/staging/tidspbridge/hw/MMURegAcM.h create mode 100644 drivers/staging/tidspbridge/hw/hw_defs.h create mode 100644 drivers/staging/tidspbridge/hw/hw_mmu.c create mode 100644 drivers/staging/tidspbridge/hw/hw_mmu.h diff --git a/drivers/staging/tidspbridge/hw/EasiGlobal.h b/drivers/staging/tidspbridge/hw/EasiGlobal.h new file mode 100644 index 000..9b45aa7 --- /dev/null +++ b/drivers/staging/tidspbridge/hw/EasiGlobal.h @@ -0,0 +1,41 @@ +/* + * EasiGlobal.h + * + * DSP-BIOS Bridge driver support functions for TI OMAP processors. + * + * Copyright (C) 2007 Texas Instruments, Inc. + * + * This package is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * THIS PACKAGE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR + * IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED + * WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE. + */ + +#ifndef _EASIGLOBAL_H +#define _EASIGLOBAL_H +#include linux/types.h + +/* + * DEFINE:READ_ONLY, WRITE_ONLY READ_WRITE + * + * DESCRIPTION: Defines used to describe register types for EASI-checker tests. + */ + +#define READ_ONLY1 +#define WRITE_ONLY 2 +#define READ_WRITE 3 + +/* + * MACRO:_DEBUG_LEVEL1_EASI + * + * DESCRIPTION: A MACRO which can be used to indicate that a particular beach + * register access function was called. + * + * NOTE: We currently dont use this functionality. + */ +#define _DEBUG_LEVEL1_EASI(easiNum) ((void)0) + +#endif /* _EASIGLOBAL_H */ diff --git a/drivers/staging/tidspbridge/hw/GlobalTypes.h b/drivers/staging/tidspbridge/hw/GlobalTypes.h new file mode 100644 index 000..9b55150 --- /dev/null +++ b/drivers/staging/tidspbridge/hw/GlobalTypes.h @@ -0,0 +1,308 @@ +/* + * GlobalTypes.h + * + * DSP-BIOS Bridge driver support functions for TI OMAP processors. + * + * Global HW definitions + * + * Copyright (C) 2007 Texas Instruments, Inc. + * + * This package is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * THIS PACKAGE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR + * IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED + * WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE. + */ + +#ifndef _GLOBALTYPES_H +#define _GLOBALTYPES_H + +/* + * Definition: TRUE, FALSE + * + * DESCRIPTION: Boolean Definitions + */ +#ifndef TRUE +#define FALSE 0 +#define TRUE (!(FALSE)) +#endif + +/* + * Definition: NULL + * + * DESCRIPTION: Invalid pointer + */ +#ifndef NULL +#define NULL (void *)0 +#endif + +/* + * Definition: RET_CODE_BASE + * + * DESCRIPTION: Base value for return code offsets + */ +#define RET_CODE_BASE 0 + +/* + * Definition: *BIT_OFFSET + * + * DESCRIPTION: offset in bytes from start of 32-bit word. + */ +#define LOWER16BIT_OFFSET0 +#define UPPER16BIT_OFFSET2 + +#define LOWER8BIT_OFFSET 0 +#define LOWER_MIDDLE8BIT_OFFSET1 +#define UPPER_MIDDLE8BIT_OFFSET2 +#define UPPER8BIT_OFFSET 3 + +#define LOWER8BIT_OF16_OFFSET 0 +#define UPPER8BIT_OF16_OFFSET 1 + +/* + * Definition: *BIT_SHIFT + * + * DESCRIPTION: offset in bits from
[PATCH 07/11] staging: ti dspbridge: add services
From: Omar Ramirez Luna omar.rami...@ti.com
Add TI's DSP Bridge driver services code
Signed-off-by: Omar Ramirez Luna omar.rami...@ti.com
Signed-off-by: Kanigeri, Hari h-kanige...@ti.com
Signed-off-by: Ameya Palande ameya.pala...@nokia.com
Signed-off-by: Guzman Lugo, Fernando fernando.l...@ti.com
Signed-off-by: Hebbar, Shivananda x0heb...@ti.com
Signed-off-by: Ramos Falcon, Ernesto erne...@ti.com
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
Signed-off-by: Anna, Suman s-a...@ti.com
Signed-off-by: Gupta, Ramesh grgu...@ti.com
Signed-off-by: Gomez Castellanos, Ivan ivan.go...@ti.com
Signed-off-by: Andy Shevchenko ext-andriy.shevche...@nokia.com
Signed-off-by: Armando Uribe De Leon x0095...@ti.com
Signed-off-by: Deepak Chitriki deepak.chitr...@ti.com
Signed-off-by: Menon, Nishanth n...@ti.com
Signed-off-by: Phil Carmody ext-phil.2.carm...@nokia.com
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
drivers/staging/tidspbridge/services/cfg.c | 253 +++
drivers/staging/tidspbridge/services/ntfy.c | 31 +++
drivers/staging/tidspbridge/services/services.c | 69 ++
drivers/staging/tidspbridge/services/sync.c | 104 +
4 files changed, 457 insertions(+), 0 deletions(-)
create mode 100644 drivers/staging/tidspbridge/services/cfg.c
create mode 100644 drivers/staging/tidspbridge/services/ntfy.c
create mode 100644 drivers/staging/tidspbridge/services/services.c
create mode 100644 drivers/staging/tidspbridge/services/sync.c
diff --git a/drivers/staging/tidspbridge/services/cfg.c
b/drivers/staging/tidspbridge/services/cfg.c
new file mode 100644
index 000..8ae64f4
--- /dev/null
+++ b/drivers/staging/tidspbridge/services/cfg.c
@@ -0,0 +1,253 @@
+/*
+ * cfg.c
+ *
+ * DSP-BIOS Bridge driver support functions for TI OMAP processors.
+ *
+ * Implementation of platform specific config services.
+ *
+ * Copyright (C) 2005-2006 Texas Instruments, Inc.
+ *
+ * This package is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * THIS PACKAGE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR
+ * IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
+ * WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.
+ */
+
+/* --- DSP/BIOS Bridge */
+#include dspbridge/std.h
+#include dspbridge/dbdefs.h
+
+/* --- Trace Debug */
+#include dspbridge/dbc.h
+
+/* --- OS Adaptation Layer */
+
+/* --- This */
+#include dspbridge/cfg.h
+#include dspbridge/drv.h
+
+struct drv_ext {
+ struct list_head link;
+ char sz_string[MAXREGPATHLENGTH];
+};
+
+/*
+ * cfg_exit
+ * Purpose:
+ * Discontinue usage of the CFG module.
+ */
+void cfg_exit(void)
+{
+ /* Do nothing */
+}
+
+/*
+ * cfg_get_auto_start
+ * Purpose:
+ * Retreive the autostart mask, if any, for this board.
+ */
+int cfg_get_auto_start(struct cfg_devnode *dev_node_obj,
+ OUT u32 *pdwAutoStart)
+{
+ int status = 0;
+ u32 dw_buf_size;
+ struct drv_data *drv_datap = dev_get_drvdata(bridge);
+
+ dw_buf_size = sizeof(*pdwAutoStart);
+ if (!dev_node_obj)
+ status = -EFAULT;
+ if (!pdwAutoStart || !drv_datap)
+ status = -EFAULT;
+ if (DSP_SUCCEEDED(status))
+ *pdwAutoStart = (drv_datap-base_img) ? 1 : 0;
+
+ DBC_ENSURE((status == 0
+ (*pdwAutoStart == 0 || *pdwAutoStart == 1))
+ || status != 0);
+ return status;
+}
+
+/*
+ * cfg_get_dev_object
+ * Purpose:
+ * Retrieve the Device Object handle for a given devnode.
+ */
+int cfg_get_dev_object(struct cfg_devnode *dev_node_obj,
+ OUT u32 *pdwValue)
+{
+ int status = 0;
+ u32 dw_buf_size;
+ struct drv_data *drv_datap = dev_get_drvdata(bridge);
+
+ if (!drv_datap)
+ status = -EPERM;
+
+ if (!dev_node_obj)
+ status = -EFAULT;
+
+ if (!pdwValue)
+ status = -EFAULT;
+
+ dw_buf_size = sizeof(pdwValue);
+ if (DSP_SUCCEEDED(status)) {
+
+ /* check the device string and then store dev object */
+ if (!
+ (strcmp
+((char *)((struct drv_ext *)dev_node_obj)-sz_string,
+ TIOMAP1510)))
+ *pdwValue = (u32)drv_datap-dev_object;
+ }
+ if (DSP_FAILED(status))
+ pr_err(%s: Failed, status 0x%x\n, __func__, status);
+ return status;
+}
+
+/*
+ * cfg_get_exec_file
+ * Purpose:
+ * Retreive the default executable, if any, for this board.
+ */
+int cfg_get_exec_file(struct cfg_devnode *dev_node_obj
[PATCH 06/11] staging: ti dspbridge: add generic utilities
From: Omar Ramirez Luna omar.rami...@ti.com
Add TI's DSP Bridge generic utilities driver sources
Signed-off-by: Omar Ramirez Luna omar.rami...@ti.com
Signed-off-by: Kanigeri, Hari h-kanige...@ti.com
Signed-off-by: Ameya Palande ameya.pala...@nokia.com
Signed-off-by: Guzman Lugo, Fernando fernando.l...@ti.com
Signed-off-by: Hebbar, Shivananda x0heb...@ti.com
Signed-off-by: Ramos Falcon, Ernesto erne...@ti.com
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
Signed-off-by: Anna, Suman s-a...@ti.com
Signed-off-by: Gupta, Ramesh grgu...@ti.com
Signed-off-by: Gomez Castellanos, Ivan ivan.go...@ti.com
Signed-off-by: Andy Shevchenko ext-andriy.shevche...@nokia.com
Signed-off-by: Armando Uribe De Leon x0095...@ti.com
Signed-off-by: Deepak Chitriki deepak.chitr...@ti.com
Signed-off-by: Menon, Nishanth n...@ti.com
Signed-off-by: Phil Carmody ext-phil.2.carm...@nokia.com
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
drivers/staging/tidspbridge/gen/gb.c | 167 +
drivers/staging/tidspbridge/gen/gh.c | 213 ++
drivers/staging/tidspbridge/gen/gs.c | 89 +++
drivers/staging/tidspbridge/gen/uuidutil.c | 223
4 files changed, 692 insertions(+), 0 deletions(-)
create mode 100644 drivers/staging/tidspbridge/gen/gb.c
create mode 100644 drivers/staging/tidspbridge/gen/gh.c
create mode 100644 drivers/staging/tidspbridge/gen/gs.c
create mode 100644 drivers/staging/tidspbridge/gen/uuidutil.c
diff --git a/drivers/staging/tidspbridge/gen/gb.c
b/drivers/staging/tidspbridge/gen/gb.c
new file mode 100644
index 000..f1a9dd3
--- /dev/null
+++ b/drivers/staging/tidspbridge/gen/gb.c
@@ -0,0 +1,167 @@
+/*
+ * gb.c
+ *
+ * DSP-BIOS Bridge driver support functions for TI OMAP processors.
+ *
+ * Generic bitmap operations.
+ *
+ * Copyright (C) 2005-2006 Texas Instruments, Inc.
+ *
+ * This package is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * THIS PACKAGE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR
+ * IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
+ * WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.
+ */
+
+/* --- DSP/BIOS Bridge */
+#include dspbridge/std.h
+#include linux/types.h
+/* --- This */
+#include dspbridge/gs.h
+#include dspbridge/gb.h
+
+struct gb_t_map {
+ u32 len;
+ u32 wcnt;
+ u32 *words;
+};
+
+/*
+ * gb_clear
+ * purpose:
+ * Clears a bit in the bit map.
+ */
+
+void gb_clear(struct gb_t_map *map, u32 bitn)
+{
+ u32 mask;
+
+ mask = 1L (bitn % BITS_PER_LONG);
+ map-words[bitn / BITS_PER_LONG] = ~mask;
+}
+
+/*
+ * gb_create
+ * purpose:
+ * Creates a bit map.
+ */
+
+struct gb_t_map *gb_create(u32 len)
+{
+ struct gb_t_map *map;
+ u32 i;
+ map = (struct gb_t_map *)gs_alloc(sizeof(struct gb_t_map));
+ if (map != NULL) {
+ map-len = len;
+ map-wcnt = len / BITS_PER_LONG + 1;
+ map-words = (u32 *) gs_alloc(map-wcnt * sizeof(u32));
+ if (map-words != NULL) {
+ for (i = 0; i map-wcnt; i++)
+ map-words[i] = 0L;
+
+ } else {
+ gs_frees(map, sizeof(struct gb_t_map));
+ map = NULL;
+ }
+ }
+
+ return map;
+}
+
+/*
+ * gb_delete
+ * purpose:
+ * Frees a bit map.
+ */
+
+void gb_delete(struct gb_t_map *map)
+{
+ gs_frees(map-words, map-wcnt * sizeof(u32));
+ gs_frees(map, sizeof(struct gb_t_map));
+}
+
+/*
+ * gb_findandset
+ * purpose:
+ * Finds a free bit and sets it.
+ */
+u32 gb_findandset(struct gb_t_map *map)
+{
+ u32 bitn;
+
+ bitn = gb_minclear(map);
+
+ if (bitn != GB_NOBITS)
+ gb_set(map, bitn);
+
+ return bitn;
+}
+
+/*
+ * gb_minclear
+ * purpose:
+ * returns the location of the first unset bit in the bit map.
+ */
+u32 gb_minclear(struct gb_t_map *map)
+{
+ u32 bit_location = 0;
+ u32 bit_acc = 0;
+ u32 i;
+ u32 bit;
+ u32 *word;
+
+ for (word = map-words, i = 0; i map-wcnt; word++, i++) {
+ if (~*word) {
+ for (bit = 0; bit BITS_PER_LONG; bit++, bit_acc++) {
+ if (bit_acc == map-len)
+ return GB_NOBITS;
+
+ if (~*word (1L bit)) {
+ bit_location = i * BITS_PER_LONG + bit;
+ return bit_location;
+ }
+
+ }
+ } else
[PATCH 10/11] staging: ti dspbridge: add TODO file
Add a general cleaning roadmap TODO file to TI's DSP Bridge staging driver. Signed-off-by: Ohad Ben-Cohen o...@wizery.com --- I can also be reached at ohadb at ti dot com drivers/staging/tidspbridge/TODO | 18 ++ 1 files changed, 18 insertions(+), 0 deletions(-) create mode 100644 drivers/staging/tidspbridge/TODO diff --git a/drivers/staging/tidspbridge/TODO b/drivers/staging/tidspbridge/TODO new file mode 100644 index 000..54f4a29 --- /dev/null +++ b/drivers/staging/tidspbridge/TODO @@ -0,0 +1,18 @@ +* Migrate to (and if necessary, extend) existing upstream code such as + iommu, wdt, mcbsp, gptimers +* Decouple hardware-specific code (e.g. bridge_brd_start/stop/delete/monitor) +* DOFF binary loader: consider pushing to user space. at the very least + eliminate the direct filesystem access +* Eliminate general services and libraries - use or extend existing kernel + libraries instead (e.g. gcf/lcm in nldr.c, global helpers in gen/) +* Eliminate direct manipulation of OMAP_SYSC_BASE +* Eliminate list.h : seem like a redundant wrapper to existing kernel lists +* Eliminate DSP_SUCCEEDED macros and their imposed redundant indentations + (adopt the kernel way of checking for return values) +* Audit interfaces exposed to user space +* Audit and clean up header files folder +* Use kernel coding style +* checkpatch.pl fixes + +Please send any patches to Greg Kroah-Hartman g...@kroah.com +and Omar Ramirez Luna omar.rami...@ti.com. -- 1.7.0.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 11/11] staging: ti dspbridge: enable driver building
From: Omar Ramirez Luna omar.rami...@ti.com Add Kconfig + Makefile for TI's DSP Bridge driver and expose it to the staging menu. Signed-off-by: Omar Ramirez Luna omar.rami...@ti.com Signed-off-by: Kanigeri, Hari h-kanige...@ti.com Signed-off-by: Ameya Palande ameya.pala...@nokia.com Signed-off-by: Guzman Lugo, Fernando fernando.l...@ti.com Signed-off-by: Hebbar, Shivananda x0heb...@ti.com Signed-off-by: Ramos Falcon, Ernesto erne...@ti.com Signed-off-by: Felipe Contreras felipe.contre...@gmail.com Signed-off-by: Anna, Suman s-a...@ti.com Signed-off-by: Gupta, Ramesh grgu...@ti.com Signed-off-by: Gomez Castellanos, Ivan ivan.go...@ti.com Signed-off-by: Andy Shevchenko ext-andriy.shevche...@nokia.com Signed-off-by: Armando Uribe De Leon x0095...@ti.com Signed-off-by: Deepak Chitriki deepak.chitr...@ti.com Signed-off-by: Menon, Nishanth n...@ti.com Signed-off-by: Phil Carmody ext-phil.2.carm...@nokia.com Signed-off-by: Ohad Ben-Cohen o...@wizery.com --- drivers/staging/Kconfig |2 + drivers/staging/Makefile |1 + drivers/staging/tidspbridge/Kconfig | 88 ++ drivers/staging/tidspbridge/Makefile | 34 + 4 files changed, 125 insertions(+), 0 deletions(-) create mode 100644 drivers/staging/tidspbridge/Kconfig create mode 100644 drivers/staging/tidspbridge/Makefile diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig index cdd3ea3..ce1dfa8 100644 --- a/drivers/staging/Kconfig +++ b/drivers/staging/Kconfig @@ -151,5 +151,7 @@ source drivers/staging/msm/Kconfig source drivers/staging/easycap/Kconfig +source drivers/staging/tidspbridge/Kconfig + endif # !STAGING_EXCLUDE_BUILD endif # STAGING diff --git a/drivers/staging/Makefile b/drivers/staging/Makefile index beceaff..7849818 100644 --- a/drivers/staging/Makefile +++ b/drivers/staging/Makefile @@ -56,3 +56,4 @@ obj-$(CONFIG_FB_XGI) += xgifb/ obj-$(CONFIG_TOUCHSCREEN_MRSTOUCH) += mrst-touchscreen/ obj-$(CONFIG_MSM_STAGING) += msm/ obj-$(CONFIG_EASYCAP) += easycap/ +obj-$(CONFIG_TIDSPBRIDGE) += tidspbridge/ diff --git a/drivers/staging/tidspbridge/Kconfig b/drivers/staging/tidspbridge/Kconfig new file mode 100644 index 000..37fa2b1 --- /dev/null +++ b/drivers/staging/tidspbridge/Kconfig @@ -0,0 +1,88 @@ +# +# DSP Bridge Driver Support +# + +menuconfig TIDSPBRIDGE + tristate DSP Bridge driver + default n + select OMAP_MBOX_FWK + help + DSP/BIOS Bridge is designed for platforms that contain a GPP and + one or more attached DSPs. The GPP is considered the master or + host processor, and the attached DSPs are processing resources + that can be utilized by applications and drivers running on the GPP. + + This driver depends on OMAP Mailbox (OMAP_MBOX_FWK). + +config BRIDGE_DVFS + bool Enable Bridge Dynamic Voltage and Frequency Scaling (DVFS) + depends on TIDSPBRIDGE OMAP_PM_SRF CPU_FREQ + default n + help + DVFS allows DSP Bridge to initiate the operating point change to + scale the chip voltage and frequency in order to match the + performance and power consumption to the current processing + requirements. + +config BRIDGE_MEMPOOL_SIZE + hex Physical memory pool size (Byte) + depends on TIDSPBRIDGE + default 0x60 + help + Allocate specified size of memory at booting time to avoid allocation + failure under heavy memory fragmentation after some use time. + +config BRIDGE_DEBUG + bool DSP Bridge Debug Support + depends on TIDSPBRIDGE + help + Say Y to enable Bridge debugging capabilities + +config BRIDGE_RECOVERY + bool DSP Recovery Support + depends on TIDSPBRIDGE + help + In case of DSP fatal error, BRIDGE driver will try to + recover itself. + +config BRIDGE_CACHE_LINE_CHECK + bool Check buffers to be 128 byte aligned + depends on TIDSPBRIDGE + default n + help + When the DSP processes data, the DSP cache controller loads 128-Byte + chunks (lines) from SDRAM and writes the data back in 128-Byte chunks. + If a DMM buffer does not start and end on a 128-Byte boundary, the data + preceding the start address (SA) from the 128-Byte boundary to the SA + and the data at addresses trailing the end address (EA) from the EA to + the next 128-Byte boundary will be loaded and written back as well. + This can lead to heap corruption. Say Y, to enforce the check for 128 + byte alignment, buffers failing this check will be rejected. + +config BRIDGE_WDT3 + bool Enable WDT3 interruptions + depends on TIDSPBRIDGE + default n + help + WTD3 is managed by DSP and once it is enabled, DSP side bridge is in + charge of refreshing the timer before overflow, if the DSP hangs MPU + will caught
[PATCH 1/4] omap mailbox: extend API to take a callback param
Let mailbox users set the callback pointer via the
omap_mbox_get API, instead of having users directly
manipulating the mailbox structures.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
I can also be contacted at ohadb at ti dot com
arch/arm/plat-omap/include/plat/mailbox.h |2 +-
arch/arm/plat-omap/mailbox.c |4 +++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/mailbox.h
b/arch/arm/plat-omap/include/plat/mailbox.h
index 9976565..0b45664 100644
--- a/arch/arm/plat-omap/include/plat/mailbox.h
+++ b/arch/arm/plat-omap/include/plat/mailbox.h
@@ -62,7 +62,7 @@ struct omap_mbox {
int omap_mbox_msg_send(struct omap_mbox *, mbox_msg_t msg);
void omap_mbox_init_seq(struct omap_mbox *);
-struct omap_mbox *omap_mbox_get(const char *);
+struct omap_mbox *omap_mbox_get(const char *name, int (*callback)(void *));
void omap_mbox_put(struct omap_mbox *);
int omap_mbox_register(struct device *parent, struct omap_mbox **);
diff --git a/arch/arm/plat-omap/mailbox.c b/arch/arm/plat-omap/mailbox.c
index d2fafb8..14b716d 100644
--- a/arch/arm/plat-omap/mailbox.c
+++ b/arch/arm/plat-omap/mailbox.c
@@ -305,7 +305,7 @@ static void omap_mbox_fini(struct omap_mbox *mbox)
}
}
-struct omap_mbox *omap_mbox_get(const char *name)
+struct omap_mbox *omap_mbox_get(const char *name, int (*callback)(void *))
{
struct omap_mbox *mbox;
int ret;
@@ -324,6 +324,8 @@ struct omap_mbox *omap_mbox_get(const char *name)
if (ret)
return ERR_PTR(-ENODEV);
+ mbox-rxq-callback = callback;
+
return mbox;
}
EXPORT_SYMBOL(omap_mbox_get);
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] omap mailbox: prevent multiple concurrent receivers race
We currently maintain only a single mailbox receiver callback.
To prevent multiple receivers race scenarios (in which receivers
will end up overwriting each other's callback pointers), we make
sure that mailbox instances cannot be taken by more than
one receiver at the same time.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
I can also be contacted at ohadb at ti dot com
arch/arm/plat-omap/include/plat/mailbox.h |1 +
arch/arm/plat-omap/mailbox.c | 12 +++-
2 files changed, 12 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/mailbox.h
b/arch/arm/plat-omap/include/plat/mailbox.h
index 0b45664..5df35b4 100644
--- a/arch/arm/plat-omap/include/plat/mailbox.h
+++ b/arch/arm/plat-omap/include/plat/mailbox.h
@@ -57,6 +57,7 @@ struct omap_mbox {
struct omap_mbox_ops*ops;
struct device *dev;
void*priv;
+ atomic_tcount;
};
int omap_mbox_msg_send(struct omap_mbox *, mbox_msg_t msg);
diff --git a/arch/arm/plat-omap/mailbox.c b/arch/arm/plat-omap/mailbox.c
index 14b716d..aafa63f 100644
--- a/arch/arm/plat-omap/mailbox.c
+++ b/arch/arm/plat-omap/mailbox.c
@@ -320,9 +320,17 @@ struct omap_mbox *omap_mbox_get(const char *name, int
(*callback)(void *))
if (!mbox)
return ERR_PTR(-ENOENT);
+ if (atomic_inc_return(mbox-count) 1) {
+ pr_err(%s: mbox %s already in use\n, __func__, name);
+ atomic_dec(mbox-count);
+ return ERR_PTR(-EBUSY);
+ }
+
ret = omap_mbox_startup(mbox);
- if (ret)
+ if (ret) {
+ atomic_dec(mbox-count);
return ERR_PTR(-ENODEV);
+ }
mbox-rxq-callback = callback;
@@ -333,6 +341,7 @@ EXPORT_SYMBOL(omap_mbox_get);
void omap_mbox_put(struct omap_mbox *mbox)
{
omap_mbox_fini(mbox);
+ atomic_dec(mbox-count);
}
EXPORT_SYMBOL(omap_mbox_put);
@@ -349,6 +358,7 @@ int omap_mbox_register(struct device *parent, struct
omap_mbox **list)
for (i = 0; mboxes[i]; i++) {
struct omap_mbox *mbox = mboxes[i];
+ atomic_set(mbox-count, 0);
mbox-dev = device_create(omap_mbox_class,
parent, 0, mbox, %s, mbox-name);
if (IS_ERR(mbox-dev)) {
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] omap mailbox: remove mbox_configured scheme
mbox_configured is global and therefore does not support
concurrent usage of multiple mailbox instances.
Instead of fixing this, we can just eliminate mbox_configured
(and its locking) entirely, since any given mailbox instance
can only be taken by a single receiver now.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
I can also be contacted at ohadb at ti dot com
arch/arm/plat-omap/mailbox.c | 24
1 files changed, 4 insertions(+), 20 deletions(-)
diff --git a/arch/arm/plat-omap/mailbox.c b/arch/arm/plat-omap/mailbox.c
index aafa63f..6a9dfe5 100644
--- a/arch/arm/plat-omap/mailbox.c
+++ b/arch/arm/plat-omap/mailbox.c
@@ -35,9 +35,6 @@ static struct workqueue_struct *mboxd;
static struct omap_mbox **mboxes;
static bool rq_full;
-static int mbox_configured;
-static DEFINE_MUTEX(mbox_configured_lock);
-
static unsigned int mbox_kfifo_size = CONFIG_OMAP_MBOX_KFIFO_SIZE;
module_param(mbox_kfifo_size, uint, S_IRUGO);
MODULE_PARM_DESC(mbox_kfifo_size, Size of omap's mailbox kfifo (bytes));
@@ -240,16 +237,9 @@ static int omap_mbox_startup(struct omap_mbox *mbox)
struct omap_mbox_queue *mq;
if (mbox-ops-startup) {
- mutex_lock(mbox_configured_lock);
- if (!mbox_configured)
- ret = mbox-ops-startup(mbox);
-
- if (ret) {
- mutex_unlock(mbox_configured_lock);
+ ret = mbox-ops-startup(mbox);
+ if (ret)
return ret;
- }
- mbox_configured++;
- mutex_unlock(mbox_configured_lock);
}
ret = request_irq(mbox-irq, mbox_interrupt, IRQF_SHARED,
@@ -295,14 +285,8 @@ static void omap_mbox_fini(struct omap_mbox *mbox)
mbox_queue_free(mbox-txq);
mbox_queue_free(mbox-rxq);
- if (mbox-ops-shutdown) {
- mutex_lock(mbox_configured_lock);
- if (mbox_configured 0)
- mbox_configured--;
- if (!mbox_configured)
- mbox-ops-shutdown(mbox);
- mutex_unlock(mbox_configured_lock);
- }
+ if (mbox-ops-shutdown)
+ mbox-ops-shutdown(mbox);
}
struct omap_mbox *omap_mbox_get(const char *name, int (*callback)(void *))
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] dspbridge: use mailbox API to set rx callback
use mailbox API to set rx callback
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
I can also be contacted at ohadb at ti dot com
drivers/dsp/bridge/core/tiomap3430.c |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/drivers/dsp/bridge/core/tiomap3430.c
b/drivers/dsp/bridge/core/tiomap3430.c
index 35c6678..1190c79 100644
--- a/drivers/dsp/bridge/core/tiomap3430.c
+++ b/drivers/dsp/bridge/core/tiomap3430.c
@@ -555,7 +555,7 @@ static int bridge_brd_start(struct bridge_dev_context
*hDevContext,
* Enable Mailbox events and also drain any pending
* stale messages.
*/
- dev_context-mbox = omap_mbox_get(dsp);
+ dev_context-mbox = omap_mbox_get(dsp, (int (*)(void
*))io_mbox_msg);
if (IS_ERR(dev_context-mbox)) {
dev_context-mbox = NULL;
pr_err(%s: Failed to get dsp mailbox handle\n,
@@ -565,8 +565,6 @@ static int bridge_brd_start(struct bridge_dev_context
*hDevContext,
}
if (DSP_SUCCEEDED(status)) {
- dev_context-mbox-rxq-callback = (int (*)(void *))io_mbox_msg;
-
/*PM_IVA2GRPSEL_PER = 0xC0;*/
temp = (u32) *((reg_uword32 *)
((u32) (resources-dw_per_pm_base) + 0xA8));
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 4/4] omap: mailbox: convert block api to kfifo
On Wed, Jun 16, 2010 at 8:50 AM, Hiroshi DOYU hiroshi.d...@nokia.com wrote: From: ext Ohad Ben-Cohen o...@wizery.com Thanks, I'll prepare them and resubmit You can use the following branch which has accumulateed unmerged mailbox patches. git://gitorious.org/~doyu/lk/mainline.git v2.6.35-rc3-mailbox Done. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mailbox: change full flag per mailbox queue instead of global
On Mon, Jun 14, 2010 at 11:51 AM, Fernando Guzman Lugo x0095...@ti.com wrote:
As pointed by Ben Ohand, the variable rq_full flag is a global
variable, so if there are multiple mailbox users there will be
conflics. Now there is a full flag per mailbox queue.
Reported-by: Ohad Ben-Cohen o...@wizery.com
Signed-off-by: Fernando Guzman Lugo x0095...@ti.com
---
arch/arm/plat-omap/include/plat/mailbox.h | 1 +
arch/arm/plat-omap/mailbox.c | 7 +++
2 files changed, 4 insertions(+), 4 deletions(-)
Thanks, Fernando, it looks good !
Since the original patch wasn't merged yet, it might make more sense
to squash it with this fix into a single patch, instead of introducing
this fix as a new patch. what do you think ?
diff --git a/arch/arm/plat-omap/include/plat/mailbox.h
b/arch/arm/plat-omap/include/plat/mailbox.h
index 729166b..a6144b8 100644
--- a/arch/arm/plat-omap/include/plat/mailbox.h
+++ b/arch/arm/plat-omap/include/plat/mailbox.h
@@ -47,6 +47,7 @@ struct omap_mbox_queue {
struct tasklet_struct tasklet;
int (*callback)(void *);
struct omap_mbox *mbox;
+ bool full;
};
struct omap_mbox {
diff --git a/arch/arm/plat-omap/mailbox.c b/arch/arm/plat-omap/mailbox.c
index 8d86b0b..a1e274e 100644
--- a/arch/arm/plat-omap/mailbox.c
+++ b/arch/arm/plat-omap/mailbox.c
@@ -30,7 +30,6 @@
static struct omap_mbox *mboxes;
static DEFINE_RWLOCK(mboxes_lock);
-static bool rq_full;
static int mbox_configured;
static DEFINE_MUTEX(mbox_configured_lock);
@@ -140,9 +139,9 @@ static void mbox_rx_work(struct work_struct *work)
while (1) {
spin_lock_irqsave(q-queue_lock, flags);
rq = blk_fetch_request(q);
- if (rq_full) {
+ if (mbox-rxq-full) {
omap_mbox_enable_irq(mbox, IRQ_RX);
- rq_full = false;
+ mbox-rxq-full = false;
}
spin_unlock_irqrestore(q-queue_lock, flags);
if (!rq)
@@ -183,7 +182,7 @@ static void __mbox_rx_interrupt(struct omap_mbox *mbox)
rq = blk_get_request(q, WRITE, GFP_ATOMIC);
if (unlikely(!rq)) {
omap_mbox_disable_irq(mbox, IRQ_RX);
- rq_full = true;
+ mbox-rxq-full = true;
goto nomem;
}
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 4/4] omap: mailbox: convert block api to kfifo
On Tue, Jun 15, 2010 at 3:04 AM, Hiroshi DOYU hiroshi.d...@nokia.com wrote: Fair enough. Thanks, I'll prepare them and resubmit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
