[PATCH 0/2] igepv2: Enable WiFi and Heartbeat LED
Some patches for the IGEPv2 board to enable WiFi and Heartbeat LED. Patches are completely contained within board configuration file. Anders Hedlund (1): IGEPv2: Added WIFI support Jonas Zetterberg (1): IGEPv2: Use Red Led1 as Heartbeat if configured arch/arm/mach-omap2/board-igep0020.c | 68 +- 1 files changed, 67 insertions(+), 1 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
[PATCH 1/2] IGEPv2: Added WIFI support
Enabled VMMC2 LDO voltage regulator on TWL4030.
Added GPIO's (power down and reset) for WIFI chip.
Signed-off-by: Anders Hedlund anders.j.hedl...@gmail.com
Signed-off-by: Jonas Zetterberg j...@jozz.se
---
arch/arm/mach-omap2/board-igep0020.c | 40
++
1 files changed, 40 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-igep0020.c b/arch/arm/mach-omap2/board-igep0020.c
index 721a1f6..00ea2d6 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -42,6 +42,8 @@
#define IGEP2_GPIO_LED0_GREEN 27
#define IGEP2_GPIO_LED1_RED 28
#define IGEP2_GPIO_DVI_PUP 170
+#define IGEP2_GPIO_WIFI_NPD 94
+#define IGEP2_GPIO_WIFI_NRESET 95
#if defined(CONFIG_MTD_ONENAND_OMAP2) || \
defined(CONFIG_MTD_ONENAND_OMAP2_MODULE)
@@ -209,6 +211,10 @@ static struct regulator_consumer_supply igep2_vmmc1_supply = {
.supply = vmmc,
};
+static struct regulator_consumer_supply igep2_vmmc2_supply = {
+ .supply = vmmc,
+};
+
/* VMMC1 for OMAP VDD_MMC1 (i/o) and MMC1 card */
static struct regulator_init_data igep2_vmmc1 = {
.constraints = {
@@ -224,6 +230,21 @@ static struct regulator_init_data igep2_vmmc1 = {
.consumer_supplies = igep2_vmmc1_supply,
};
+/* VMMC2 for OMAP VDD_MMC2 (i/o) and MMC2 WIFI */
+static struct regulator_init_data igep2_vmmc2 = {
+ .constraints = {
+ .min_uV = 185,
+ .max_uV = 315,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_STANDBY,
+ .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE
+ | REGULATOR_CHANGE_MODE
+ | REGULATOR_CHANGE_STATUS,
+ },
+ .num_consumer_supplies = 1,
+ .consumer_supplies = igep2_vmmc2_supply,
+};
+
static struct omap2_hsmmc_info mmc[] = {
{
.mmc = 1,
@@ -251,6 +272,7 @@ static int igep2_twl_gpio_setup(struct device *dev,
* regulators will be set up only *after* we return.
*/
igep2_vmmc1_supply.dev = mmc[0].dev;
+ igep2_vmmc2_supply.dev = mmc[1].dev;
return 0;
};
@@ -364,6 +386,7 @@ static struct twl4030_platform_data igep2_twldata = {
.codec = igep2_codec_data,
.gpio = igep2_gpio_data,
.vmmc1 = igep2_vmmc1,
+ .vmmc2 = igep2_vmmc2,
.vpll2 = igep2_vpll2,
};
@@ -446,6 +469,23 @@ static void __init igep2_init(void)
gpio_set_value(IGEP2_GPIO_LED1_RED, 0);
} else
pr_warning(IGEP v2: Could not obtain gpio GPIO_LED1_RED\n);
+
+ /* GPIO W-LAN + Bluetooth combo module */
+ if ((gpio_request(IGEP2_GPIO_WIFI_NPD, GPIO_WIFI_NPD) == 0)
+ (gpio_direction_output(IGEP2_GPIO_WIFI_NPD, 1) == 0)) {
+ gpio_export(IGEP2_GPIO_WIFI_NPD, 0);
+/* gpio_set_value(IGEP2_GPIO_WIFI_NPD, 0); */
+ } else
+ pr_warning(IGEP v2: Could not obtain gpio GPIO_WIFI_NPD\n);
+
+ if ((gpio_request(IGEP2_GPIO_WIFI_NRESET, GPIO_WIFI_NRESET) == 0)
+ (gpio_direction_output(IGEP2_GPIO_WIFI_NRESET, 1) == 0)) {
+ gpio_export(IGEP2_GPIO_WIFI_NRESET, 0);
+ gpio_set_value(IGEP2_GPIO_WIFI_NRESET, 0);
+ udelay(10);
+ gpio_set_value(IGEP2_GPIO_WIFI_NRESET, 1);
+ } else
+ pr_warning(IGEP v2: Could not obtain gpio GPIO_WIFI_NRESET\n);
}
static void __init igep2_map_io(void)
[PATCH 2/2] IGEPv2: Use Red Led1 as Heartbeat if configured
If not configured it will be exported as normal GPIO led.
Signed-off-by: Jonas Zetterberg j...@jozz.se
---
arch/arm/mach-omap2/board-igep0020.c | 30 --
1 files changed, 28 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/board-igep0020.c b/arch/arm/mach-omap2/board-igep0020.c
index 00ea2d6..9958987 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -16,6 +16,7 @@
#include linux/clk.h
#include linux/io.h
#include linux/gpio.h
+#include linux/leds.h
#include linux/interrupt.h
#include linux/regulator/machine.h
@@ -354,9 +355,34 @@ static void __init igep2_display_init(void)
gpio_direction_output(IGEP2_GPIO_DVI_PUP, 1))
pr_err(IGEP v2: Could not obtain gpio GPIO_DVI_PUP\n);
}
+#ifdef CONFIG_LEDS_TRIGGERS
+static struct gpio_led gpio_leds[] = {
+ {
+ .name = GPIO_LED1_RED,
+ .default_trigger = heartbeat,
+ .gpio = IGEP2_GPIO_LED1_RED,
+ },
+};
+
+static struct gpio_led_platform_data gpio_leds_info = {
+ .leds = gpio_leds,
+ .num_leds = ARRAY_SIZE(gpio_leds),
+};
+
+static struct platform_device leds_gpio = {
+ .name = leds-gpio,
+ .id = -1,
+ .dev= {
+ .platform_data = gpio_leds_info,
+ },
+};
+#endif
static struct platform_device *igep2_devices[] __initdata = {
igep2_dss_device,
+#ifdef CONFIG_LEDS_TRIGGERS
+ leds_gpio,
+#endif
};
static void __init igep2_init_irq(void)
@@ -462,14 +488,14 @@ static void __init igep2_init(void)
gpio_set_value(IGEP2_GPIO_LED0_GREEN, 0);
} else
pr_warning(IGEP v2: Could not obtain gpio GPIO_LED0_GREEN\n);
-
+#ifndef CONFIG_LEDS_TRIGGERS
if ((gpio_request(IGEP2_GPIO_LED1_RED, GPIO_LED1_RED) == 0)
(gpio_direction_output(IGEP2_GPIO_LED1_RED, 1) == 0)) {
gpio_export(IGEP2_GPIO_LED1_RED, 0);
gpio_set_value(IGEP2_GPIO_LED1_RED, 0);
} else
pr_warning(IGEP v2: Could not obtain gpio GPIO_LED1_RED\n);
-
+#endif
/* GPIO W-LAN + Bluetooth combo module */
if ((gpio_request(IGEP2_GPIO_WIFI_NPD, GPIO_WIFI_NPD) == 0)
(gpio_direction_output(IGEP2_GPIO_WIFI_NPD, 1) == 0)) {
Which ARM toolchain for OMAP35x?
What's a known good toolcahin for linux-omap development? I'm currently using CodeSroucery 2009q1-203 and wondering if there's a better toolchain or if people have had problems using the the 2009q1-203 toolchain. Thanks in advance! -- 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 0/4 RFC]OMAP:GPIO: Make GPIO an early init device
On Fri, 12 Feb 2010, Paul Walmsley wrote: On Fri, 12 Feb 2010, Varadarajan, Charulatha wrote: OMAP: Convert GPIO into a early driver The above patch appears to be missing. Could you please re-send? This patch was too big for the mailing list, so it's been posted here: http://www.pwsan.com/omap/patches/gpio/0002-OMAP-GPIO-split-omap1-and-omap2.patch - Paul -- 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 0/2 RFC]OMAP3430: hwmod FW for GPIO
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Paul Walmsley Sent: Saturday, February 13, 2010 3:31 AM To: Varadarajan, Charulatha Cc: linux-omap@vger.kernel.org; t...@atomide.com; khil...@deeprootsystems.com Subject: Re: [PATCH 0/2 RFC]OMAP3430: hwmod FW for GPIO By the way: On Fri, 12 Feb 2010, Varadarajan, Charulatha wrote: They are boot tested on SDP 3430 and compile tested for OMAP 2420 and 2430. This part is really offensively misleading. It does not matter whether the code has been compile-tested on OMAP24xx if it could never actually run on OMAP24xx. Charu, You can mention explicitely in the cover letter that these patches would break omap2 functionality, since no hwmod struct's are added for omap2. I agree with Paul that saying they are compile tested might mislead someone in believing that these patches are tested on omap2. regards, Rajendra - Paul -- 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: Moving board patches from DSS2 to linux-omap
On Sat, 2010-02-13 at 11:43 +0100, ext Hiremath, Vaibhav wrote: -Original Message- From: Hiremath, Vaibhav Sent: Saturday, February 13, 2010 4:04 PM To: 'Tomi Valkeinen'; ext Tony Lindgren Cc: ext Mike Rapoport; linux-omap@vger.kernel.org Subject: RE: Moving board patches from DSS2 to linux-omap -Original Message- From: Tomi Valkeinen [mailto:tomi.valkei...@nokia.com] Sent: Friday, February 12, 2010 4:14 PM To: ext Tony Lindgren Cc: ext Mike Rapoport; Hiremath, Vaibhav; linux- o...@vger.kernel.org Subject: Re: Moving board patches from DSS2 to linux-omap On Thu, 2010-02-11 at 19:52 +0100, ext Tony Lindgren wrote: * Tomi Valkeinen tomi.valkei...@nokia.com [100211 03:59]: On Thu, 2010-02-11 at 12:50 +0100, ext Mike Rapoport wrote: Tomi Valkeinen wrote: Hi, As discussed previously, board file changes in DSS2 tree cause conflicts with linux-omap easily. There are currently three board file patches in DSS2's for-next branch: 722a97e4594b2041bbf18d95a913ba6dfaca87f2 omap3: cm-t35: add DSS2 display support 7a56267e775e469c64521179ccc958c8bb661dbf OMAP: AM3517: Enable DSS2 for AM3517EVM board 40e4e67c6dabcb9897b6823cce2297d6c3e78bbd OMAP: Enable DSS2 for OMAP3EVM board The problem here is of course that DSS2 tree may contain unmerged panel drivers, and those board file changes try to use these new panel drivers. OK, Tomi, can you please set up a banch against mainline -rc7 with whatever board-*.c dss2 patches you want me to pull? I'll pull them into omap-for-linus, and rebase omap for-next on those. Here: git://gitorious.org/linux-omap-dss2/linux.git for-tony I removed the defconfig changes from the patches, and compile tested. I'll add the defconfig changes as separate patches in my tree, and I'll push them to Linus only after the board changes from Tony's tree have gone through. [Hiremath, Vaibhav] Tomi, I have pulled in for-tony branch and validated it on OAMP3EVM (with omap3_defconfig) and AM3517EVM without any issues. [Hiremath, Vaibhav] Missed to mention one point, Tomi, Probably you have not merged sharp LQ043T1DG01 panel support patch required for AM3517? Can you merge that patch also? I have that patch in my tree. It's been there for some time. Perhaps I forgot to email back about that... Do you need any help here? Do you want me to separate defconfig patches for you? I separated the defconfig change from the board file changes, and made separate patches from them. They are in my master branch, and they apply cleanly, so I think everything is fine. Tomi -- 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/17] OMAP DSS2 model restructuring
On Sat, 2010-02-13 at 16:34 +0100, ext Grazvydas Ignotas wrote: On Mon, Feb 8, 2010 at 5:57 PM, Tomi Valkeinen tomi.valkei...@nokia.com wrote: Here are a bunch of patches that change the DSS2 driver's driver model a bit. This change was triggered by trying to support new hardware, and realizing that the current model just won't work. Currently the omapdss driver is in control of most aspects of the DSS, and omapdss calls necessary functions in display drivers. I made it that way to keep the display drivers simple, and I, naively, thought that it will work because the display panels are using standard bus interfaces and thus will be very similar. I was so wrong =). This patch set moves the control to the display driver. The display driver then calls omapdss functions to perform whatever deed is needed at that time. This will make display drivers slightly more complex, but it will be easier to control the hardware properly with strange or complex display devices. As a simple example, let's look at the update function. Currently user space app issues OMAPFB_UPDATE_WINDOW ioctl, and omapfb driver then calls update() in corresponding dss device struct, which goes to omapdss. omapdss will configure the update, calling the panel driver if needed. After these patches, omapfb will call update() in the panel driver. The panel driver will then call functions in omapdss to setup the update, start the update, and the panel driver will eventually get a callback informing that the update is done. These patches are still under work, but my basic tests on 3430SDP board seems to work ok. The patches can also be found from http://gitorious.org/linux-omap-dss2/linux work branch Tested those along with the other series, seems to work fine on pandora too. Panel callbacks like set_mirror also work now, thanks. Tested-by: Grazvydas Ignotas nota...@gmail.com Ok, thanks! Tomi -- 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
