Re: [PATCH 00/10] OMAP3: SR: Fixes in Smartreflex driver
Hi, On Friday 24 April 2009 15:09:29 Kevin Hilman wrote: Nayak, Rajendra rna...@ti.com writes: -Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Thursday, April 23, 2009 1:35 AM To: Nayak, Rajendra Cc: linux-omap Subject: Re: [PATCH 00/10] OMAP3: SR: Fixes in Smartreflex driver Nayak, Rajendra rna...@ti.com writes: Re-sending this patch-set with some mailer issues resolved. They now apply cleanly with a git-am/git-apply. Hi, This series fixes a set of defects/issues in Smartreflex driver. SR autocompensation is now functional and is validated with these patches on a ES3.1 based SDP with the N values in Efuse. The patches also make the Smartreflex driver independent of SRF by using the OMAP PM apis instead of calls to SRF. Patches apply on top of the latest pm branch from Kevin's pm tree. git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-om ap-pm.git Rajendra, This series seems to boot on SDP and Beagle but I recetly tried on RX51 and it hangs in omap3_sr_init(). Using Lauterbach, I tracked it to hang in sr_configure_vp() at this PRM write to the PRM_VP1_VLIMITTO register: prm_write_mod_reg(PRM_VP1_VLIMITTO_VDDMAX | PRM_VP1_VLIMITTO_VDDMIN | PRM_VP1_VLIMITTO_TIMEOUT, OMAP3430_GR_MOD, OMAP3_PRM_VP1_VLIMITTO_OFFSET); Should these min/max/timeout values be board specific? Kevin, These values I remember we got from the SiVal team here at TI, I don't think they are board specific. I can check up more on that from them. Btw, does the hang happen only with my patchset applied, because the patchset does not change any of these values. Yes, backing out your latest series results in a booting kernel. Using the latest SR patches on Beagleboard results in a booting kernel. BUT the problem is a board freeze when switching between OPPs. After a few transitions the board hangs. Regards, Jean Kevin -- 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: Card detect IRQ errors
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Grazvydas Ignotas Sent: Monday, April 27, 2009 2:43 PM To: linux-omap@vger.kernel.org Cc: David Brownell Subject: Card detect IRQ errors With current l-o head when I insert or remove SD card I'm getting this: [ 20.733489] [ cut here ] [ 20.738159] WARNING: at kernel/irq/handle.c:366 handle_IRQ_event+0x4c/0x14c() [ 20.745330] BUG: IRQ handler called from non-hardirq context!Modules linked in: [ 20.752685] [8002b388] (unwind_backtrace+0x0/0xdc) from [80048128] (warn_slowpath+0x64/0x88) [ 20.761596] [80048128] (warn_slowpath+0x64/0x88) from [8006a80c] (handle_IRQ_event+0x4c/0x14c) [ 20.770629] [8006a80c] (handle_IRQ_event+0x4c/0x14c) from [8006bde8] (handle_edge_irq+0x10c/0x14c) [ 20.780029] [8006bde8] (handle_edge_irq+0x10c/0x14c) from [801862a8] (handle_twl4030_sih+0x9c/0xd0) [ 20.789520] [801862a8] (handle_twl4030_sih+0x9c/0xd0) from [801861b0] (twl4030_irq_thread+0x108/0x164) [ 20.799255] [801861b0] (twl4030_irq_thread+0x108/0x164) from [80059708] (kthread+0x54/0x80) [ 20.808044] [80059708] (kthread+0x54/0x80) from [8004ab68] (do_exit+0x0/0x56c) [ 20.815704] [8004ab68] (do_exit+0x0/0x56c) from [8ecf0ae0] (0x8ecf0ae0) [ 20.822753] ---[ end trace 2ca2d8ba630dd6b5 ]--- [ 20.869415] mmc0: card 8001 removed Has anyone else seen this? Me too. Was just about to report it. I get this with a 3430 SDP and mainline kernel. No MMC card inserted. - Anand -- 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: [rft/rfc/patch-v2.6.29-rc5+ 00/23] ehci cleanup series
On Mon, Feb 23, 2009 at 9:55 PM, Felipe Balbi m...@felipebalbi.com wrote: Hi all, Please give the following patches a good test. I don't have hw to test them so any comments will be really welcome. We still have lots to do before getting this driver upstream, let's try to keep track of our TODO list and get this driver in mainline for 2.6.31 merge window (2.6.30 is too close already). Let's not try to push this driver until ES2.x and ES3.x are fully supported, that will probably have to be done by an omap_rev check in ehci-omap driver, also, this driver doesn't really enumerate any attached devices, but that's old problem as Tony told me off list. Anyways, I guess this driver is finally walking. Me and Anand (and anyone interested) will be discussing how to get EHCI and OHCI working fine, I'm guessing we won't have really big issues with OHCI but you never know. Any news on this? Hope this hasn't been abandoned. -- 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: [rft/rfc/patch-v2.6.29-rc5+ 00/23] ehci cleanup series
On Mon, Apr 27, 2009 at 11:18:32AM +0200, ext Grazvydas Ignotas wrote: On Mon, Feb 23, 2009 at 9:55 PM, Felipe Balbi m...@felipebalbi.com wrote: Hi all, Please give the following patches a good test. I don't have hw to test them so any comments will be really welcome. We still have lots to do before getting this driver upstream, let's try to keep track of our TODO list and get this driver in mainline for 2.6.31 merge window (2.6.30 is too close already). Let's not try to push this driver until ES2.x and ES3.x are fully supported, that will probably have to be done by an omap_rev check in ehci-omap driver, also, this driver doesn't really enumerate any attached devices, but that's old problem as Tony told me off list. Anyways, I guess this driver is finally walking. Me and Anand (and anyone interested) will be discussing how to get EHCI and OHCI working fine, I'm guessing we won't have really big issues with OHCI but you never know. Any news on this? Hope this hasn't been abandoned. Quite busy with some nokia stuff, but I'll get back to this maybe next week. -- balbi -- 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: Card detect IRQ errors
On Monday 27 April 2009, Grazvydas Ignotas wrote: With current l-o head when I insert or remove SD card I'm getting this: [ 20.733489] [ cut here ] [ 20.738159] WARNING: at kernel/irq/handle.c:366 handle_IRQ_event+0x4c/0x14c() [ 20.745330] BUG: IRQ handler called from non-hardirq context!Modules linked in: ... [ 20.822753] ---[ end trace 2ca2d8ba630dd6b5 ]--- [ 20.869415] mmc0: card 8001 removed Has anyone else seen this? Regresssion caused by 044d408409cc4e1bc75c886e27ca85c270db104c. Notice the message is internally broken, too -- no newline. Try reverting that, things will still behave just fine. -- 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
Card detect IRQ errors
With current l-o head when I insert or remove SD card I'm getting this: [ 20.733489] [ cut here ] [ 20.738159] WARNING: at kernel/irq/handle.c:366 handle_IRQ_event+0x4c/0x14c() [ 20.745330] BUG: IRQ handler called from non-hardirq context!Modules linked in: [ 20.752685] [8002b388] (unwind_backtrace+0x0/0xdc) from [80048128] (warn_slowpath+0x64/0x88) [ 20.761596] [80048128] (warn_slowpath+0x64/0x88) from [8006a80c] (handle_IRQ_event+0x4c/0x14c) [ 20.770629] [8006a80c] (handle_IRQ_event+0x4c/0x14c) from [8006bde8] (handle_edge_irq+0x10c/0x14c) [ 20.780029] [8006bde8] (handle_edge_irq+0x10c/0x14c) from [801862a8] (handle_twl4030_sih+0x9c/0xd0) [ 20.789520] [801862a8] (handle_twl4030_sih+0x9c/0xd0) from [801861b0] (twl4030_irq_thread+0x108/0x164) [ 20.799255] [801861b0] (twl4030_irq_thread+0x108/0x164) from [80059708] (kthread+0x54/0x80) [ 20.808044] [80059708] (kthread+0x54/0x80) from [8004ab68] (do_exit+0x0/0x56c) [ 20.815704] [8004ab68] (do_exit+0x0/0x56c) from [8ecf0ae0] (0x8ecf0ae0) [ 20.822753] ---[ end trace 2ca2d8ba630dd6b5 ]--- [ 20.869415] mmc0: card 8001 removed Has anyone else seen this? -- 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
How to add kernel level battery support for the Overo TI OMAP 3503 platform
Hi, Has anybody successfully added kernel level battery support for the Overo TI OMAP 3503 platform? I want to populate the /sys/class/power_supply folder with ac and battery objects. Right now the /sys/class/power_supply folder is empty for me. Best regards, Elvis -- 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] regulator core: fix double-free in regulator_register() error path
On Sat, 2009-04-25 at 05:28 -0600, Paul Walmsley wrote: During regulator registration, any error after device_register() will cause a double-free on the struct regulator_dev 'rdev'. The bug is in drivers/regulator/core.c:regulator_register(): ... scrub: device_unregister(rdev-dev); clean: kfree(rdev); --- rdev = ERR_PTR(ret); goto out; ... device_unregister() calls regulator_dev_release() which frees rdev. The subsequent kfree corrupts memory and causes some OMAP3 systems to oops on boot in regulator_get(). Applies against 2.6.30-rc3. Signed-off-by: Paul Walmsley p...@pwsan.com --- drivers/regulator/core.c |4 1 files changed, 4 insertions(+), 0 deletions(-) Applied. Thanks Liam -- 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] I2C: OMAP: spurious IRQ fixes
Hello, Paul Walmsley wrote: It seems to work: under constant I2C load, no spurious IRQ messages showed up after several hours of testing. (Without these patches, spurious IRQs usually show up in a few minutes.) Some of the code has also been cleaned up. Any feedback on how this series works for others is appreciated. Tested on N800, Beagle and 3430SDP. With these patches I'm getting receive overruns quite easily on rx51 when doing large reads from TWL4030 RTC. A. -- 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 for supporting multiple PMICs
-Original Message-
From: Tony Lindgren [mailto:t...@atomide.com]
Sent: Wednesday, April 22, 2009 2:00 AM
To: Aggarwal, Anuj
Cc: linux-omap@vger.kernel.org; Premi, Sanjeev; Pillai, Manikandan
Subject: Re: RFC for supporting multiple PMICs
* Aggarwal, Anuj anuj.aggar...@ti.com [090420 10:52]:
All,
Based on our understanding/experiences till so far, we suggest the
following:
a) Remove all the PMIC-board related stuff from the EVM specific file (
like board-omap3evm.c) and keep it in a separate file (board-omap3evm-
pmic.c). All platform related Inits should be done here.
b) PMIC initialization and other PMIC specific routines (enable/disable,
get/set voltage/current) should be done in the PMIC specific file like
drivers/regulator/pmic.c
c) Probing for PMIC during runtime could be done in either of the ways
specified in the attached sample template.
d) Generic wrappers should be provided to have a consistent interface
for accessing PMIC registers and to use its supported features.
Please find attached the sample implementation of the things mentioned
above and provide your feedback.
To me it sounds like the regulator fwk should be able to take care of
most of these issues, see what David Brownell did with the twl4030 driver.
If the same board has different PMIC options, you should be able to compile
them all in, and then probe for the connected PMIC.
So you could have something like this in your board-*.c file:
[Aggarwal, Anuj] These PMICs can be used beyond OMAP as well. Hence,
I was proposing a generic file - instead of tying with board-*.c file(s).
But, if we want to keep the changes specific to OMAP3 only, then we can
still create a generic pmic.c|h file in mach-omap2 to consolidate all PMIC
related functions.
Otherwise, we can leave status quo.
#ifdef CONFIG_TWL4030_CORE
static struct regulator_init_data twl4030_vaux1 = {
...
};
static int __init pmic_twl4030_init(void)
{
/* Initialize things here */
}
#else
#define twl4030_vaux1 NULL
static inline int pmic_twl4030_init(void)
{
}
#endif
#ifdef CONFIG_SOME_OTHER_PMIC
static struct regulator_init_data some_other_pmic_vaux1 = {
...
};
static int __init pmic_some_other_init(void)
{
/* Initialize things here */
}
#else
#define some_other_pmic_vaux1 NULL
static inline int pmic_some_other_init(void)
#endif
...
Then just call all the PMIC inits in your board init, or later if
needed for I2C probing of the chips.
[Aggarwal, Anuj] Same pmic.c file will also have one pmic_init()
which will detect the PMIC present and initialize it appropriately.
It will be called by omap3_evm_init() or any other evm-init
function.
Regards,
Tony
Thanks and Regards,
Anuj Aggarwal
Platform Support Products
Texas Instruments Incorporated
Content-Description: board-omap3evm-pmic.c
/*
* linux/arch/arm/mach-omap2/board-omap3evm-pmic.c
*
* Copyright (C) 2009 Texas Instruments Incorporated
*
* tbd copyright
*/
#include linux/kernel.h
#include linux/init.h
#include linux/platform_device.h
#include linux/i2c/twl4030.h
#include linux/i2c/tps6535x.h
/* --- other generic headers --- */
/*
*
* If we are okay with controlled ifdef in this file then we can follow
* the scheme below...
*
*/
#ifdef CONFIG_TWL4030_CORE
/*
* Definitions specific to TWL4030
*/
#endif /* CONFIG_TWL4030_CORE */
#ifdef CONFIG_PMIC_TPS62350
/*
* Definitions specific to TPS62350
*/
#endif /* CONFIG_PMIC_TPS62350 */
#ifdef CONFIG_PMIC_TPS65023
/*
* Definitions specific to TPS65023
*/
#endif /* CONFIG_PMIC_TPS65023 */
int omap3_evm_pmic_init()
{
#ifdef CONFIG_TWL4030_CORE
/* do stuff specific to TWL4030 */
#elif CONFIG_PMIC_TPS62350
/* do stuff specific to TPS62350 */
#elif CONFIG_PMIC_TPS65023
/* do stuff specific to TPS65023 */
#endif
}
/*
=
*
* If we would like to run same image on multiple OMAP3EVMs and don't
really
* care about the image size, then we can follow the scheme below...
*
* Though there is still an open question of how to detect PMIC at runtime?
*
=
*/
/*
* Definitions specific to TWL4030
*/
/*
* Definitions specific to TPS62350
*/
/*
* Definitions specific to TPS65023
*/
static int flag_pmic_twl4030 = 0;
static int flag_pmic_tps6235x = 0;
static int flag_pmic_tps65023 = 0;
/*
* Detect the current PMIC
* Set one of the flags
*/
static inline int detect_pmic()
{
/* How? Any suggestions?? */
}
static inline int use_pmic_twl4030()
{
return flag_pmic_twl4030;
}
static inline int use_pmic_tps6235x()
{
return
RE: [PATCH 00/10] OMAP3: SR: Fixes in Smartreflex driver
-Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Saturday, April 25, 2009 4:21 AM To: Roger Quadros Cc: Nayak, Rajendra; linux-omap Subject: Re: [PATCH 00/10] OMAP3: SR: Fixes in Smartreflex driver Roger Quadros ext-roger.quad...@nokia.com writes: ext Kevin Hilman wrote: [...] Rajendra, This series seems to boot on SDP and Beagle but I recetly tried on RX51 and it hangs in omap3_sr_init(). Using Lauterbach, I tracked it to hang in sr_configure_vp() at this PRM write to the PRM_VP1_VLIMITTO register: prm_write_mod_reg(PRM_VP1_VLIMITTO_VDDMAX | PRM_VP1_VLIMITTO_VDDMIN | PRM_VP1_VLIMITTO_TIMEOUT, OMAP3430_GR_MOD, OMAP3_PRM_VP1_VLIMITTO_OFFSET); Should these min/max/timeout values be board specific? [...] It runs on rx51 if we set CONFIG_OMAP_PM_SRF instead of CONFIG_OMAP_PM_NOOP. Should Smartreflex option be dependent or independent of the CONFIG_OMAP_PM_??? setting? I see the same thing on SDP as well as RX51. It looks like the new SR code assumes a range of OPPs, but when OMAP_PM_NONE is enabled, the omap_pm_vddX_get_opp() calls always return zero. In the mpu_opps array, the first entry is all zeros, resulting in a zero VSEL which is then used to (re)program the VP. The SR code should probably be a bit smarter about checking for valid values. Kevin, I'll send in a patch to fix that. thanks, Rajendra -- 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] OMAP: PM: make mach/pm.h OMAP1-specific
Paul Walmsley p...@pwsan.com writes:
mach/pm.h is almost completely OMAP1-specific. Move it to plat-omap1 and
remove the unused OMAP2xxx-specific defines. Many files included mach/pm.h
but did not actually use any symbols; remove those #includes. Any
definitions needed for OMAP2/3 have been moved to mach-omap2/pm.h.
Boot-tested on OMAP3 Beagle as of the 16-April PM branch.
Signed-off-by: Paul Walmsley p...@pwsan.com
Thanks, pushing to PM branch.
Kevin
---
arch/arm/mach-omap1/pm.c | 11 +++--
.../{plat-omap/include/mach = mach-omap1}/pm.h| 46
+++-
arch/arm/mach-omap1/serial.c |3 -
arch/arm/mach-omap1/sleep.S|2 +-
arch/arm/mach-omap2/board-n800-usb.c |3 +-
arch/arm/mach-omap2/cpuidle34xx.c |1 -
arch/arm/mach-omap2/pm.c |1 -
arch/arm/mach-omap2/pm.h | 24 ++
arch/arm/mach-omap2/pm24xx.c |1 -
arch/arm/mach-omap2/pm34xx.c |1 -
arch/arm/mach-omap2/sleep24xx.S|1 -
arch/arm/mach-omap2/sleep34xx.S|1 -
arch/arm/mach-omap2/usb-ehci.c |1 -
arch/arm/mach-omap2/usb-musb.c |1 -
arch/arm/plat-omap/common.c|1 -
drivers/bluetooth/hci_h4p/core.c |1 -
drivers/mtd/onenand/omap2.c|1 -
17 files changed, 40 insertions(+), 60 deletions(-)
rename arch/arm/{plat-omap/include/mach = mach-omap1}/pm.h (86%)
diff --git a/arch/arm/mach-omap1/pm.c b/arch/arm/mach-omap1/pm.c
index 9774c1f..5218943 100644
--- a/arch/arm/mach-omap1/pm.c
+++ b/arch/arm/mach-omap1/pm.c
@@ -53,11 +53,12 @@
#include mach/clock.h
#include mach/sram.h
#include mach/tc.h
-#include mach/pm.h
#include mach/mux.h
#include mach/dma.h
#include mach/dmtimer.h
+#include pm.h
+
static unsigned int arm_sleep_save[ARM_SLEEP_SAVE_SIZE];
static unsigned short dsp_sleep_save[DSP_SLEEP_SAVE_SIZE];
static unsigned short ulpd_sleep_save[ULPD_SLEEP_SAVE_SIZE];
@@ -101,7 +102,7 @@ static void (*omap_sram_suspend)(unsigned long r0,
unsigned long r1) = NULL;
* going idle we continue to do idle even if we get
* a clock tick interrupt . .
*/
-void omap_pm_idle(void)
+void omap1_pm_idle(void)
{
extern __u32 arm_idlect1_mask;
__u32 use_idlect1 = arm_idlect1_mask;
@@ -222,7 +223,7 @@ static void omap_pm_wakeup_setup(void)
#define EN_APICK 6 /* ARM_IDLECT2 */
#define DSP_EN 1 /* ARM_RSTCT1 */
-void omap_pm_suspend(void)
+void omap1_pm_suspend(void)
{
unsigned long arg0 = 0, arg1 = 0;
@@ -610,7 +611,7 @@ static int omap_pm_enter(suspend_state_t state)
{
case PM_SUSPEND_STANDBY:
case PM_SUSPEND_MEM:
- omap_pm_suspend();
+ omap1_pm_suspend();
break;
default:
return -EINVAL;
@@ -683,7 +684,7 @@ static int __init omap_pm_init(void)
return -ENODEV;
}
- pm_idle = omap_pm_idle;
+ pm_idle = omap1_pm_idle;
if (cpu_is_omap730())
setup_irq(INT_730_WAKE_UP_REQ, omap_wakeup_irq);
diff --git a/arch/arm/plat-omap/include/mach/pm.h b/arch/arm/mach-omap1/pm.h
similarity index 86%
rename from arch/arm/plat-omap/include/mach/pm.h
rename to arch/arm/mach-omap1/pm.h
index 4bf1138..9ed5e2c 100644
--- a/arch/arm/plat-omap/include/mach/pm.h
+++ b/arch/arm/mach-omap1/pm.h
@@ -1,7 +1,7 @@
/*
- * arch/arm/plat-omap/include/mach/pm.h
+ * arch/arm/mach-omap1/pm.h
*
- * Header file for OMAP Power Management Routines
+ * Header file for OMAP1 Power Management Routines
*
* Author: MontaVista Software, Inc.
* supp...@mvista.com
@@ -31,8 +31,8 @@
* 675 Mass Ave, Cambridge, MA 02139, USA.
*/
-#ifndef __ASM_ARCH_OMAP_PM_H
-#define __ASM_ARCH_OMAP_PM_H
+#ifndef __ARCH_ARM_MACH_OMAP1_PM_H
+#define __ARCH_ARM_MACH_OMAP1_PM_H
/*
*
@@ -106,9 +106,7 @@
#if !defined(CONFIG_ARCH_OMAP730) \
!defined(CONFIG_ARCH_OMAP15XX) \
- !defined(CONFIG_ARCH_OMAP16XX) \
- !defined(CONFIG_ARCH_OMAP24XX) \
- !defined(CONFIG_ARCH_OMAP34XX)
+ !defined(CONFIG_ARCH_OMAP16XX)
#warning Power management for this processor not implemented yet
#endif
@@ -121,52 +119,22 @@ extern struct kset power_subsys;
extern void prevent_idle_sleep(void);
extern void allow_idle_sleep(void);
-/**
- * clk_deny_idle - Prevents the clock from being idled during MPU idle
- * @clk: clock signal handle
- */
-void clk_deny_idle(struct clk *clk);
+extern void omap1_pm_idle(void);
+extern void omap1_pm_suspend(void);
-/**
- * clk_allow_idle - Counters
[PATCH] OMAP3: PM: Ensure PRCM interrupts are cleared at boot
Pending bits in IRQSTATUS can prevent the system from hitting retention. The PRCM interrupt handler takes care of clearing the IRQSTATUS bits, but any pending bits before first suspend or idle may prevent the system from hitting retention. Ensure they are cleared during PRCM setup. Signed-off-by: Kevin Hilman khil...@deeprootsystems.com --- Applies to current PM branch. arch/arm/mach-omap2/pm34xx.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c index 7a561db..d7b6596 100644 --- a/arch/arm/mach-omap2/pm34xx.c +++ b/arch/arm/mach-omap2/pm34xx.c @@ -854,6 +854,9 @@ static void __init prcm_setup_regs(void) prm_write_mod_reg(OMAP3430_IO_EN | OMAP3430_WKUP_EN, OCP_MOD, OMAP2_PRM_IRQENABLE_MPU_OFFSET); + /* Clear any pending PRCM interrupts */ + prm_write_mod_reg(0, OCP_MOD, OMAP2_PRM_IRQSTATUS_MPU_OFFSET); + omap3_iva_idle(); } -- 1.6.2.2 -- 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
OMAP35x GP TIMER as a wakeup trigger
Greetings, I need to implement a timer as a wake up trigger while my custom board is in the suspended state. I read in the TRM that all of the GPTIMERs have the capability of generating a wake up interrupt. I'm using the 2.6.28-rc8 PM Kernel which contains the patch to enable all the GPTIMERS as wake up sources. Could someone familiar with this scheme quickly elaborate all the steps that I need to go through to get the system to come out of suspend purely on the timer? Is it is just enough to setup the timer correctly, enable the interrupt in the appropriate register and assume that the PM layer will get the interrupt and do the right thing, or is there more that I have to do? Also, as as additional thing, if the PM layer handles the interrupt and begins the wake-up process, if I could know where that specifically happens, that'd be great since I need to know that the wake-up process is being triggered by the GPTIMER as opposed to the other wakeup triggers and deal with that differently. Regards -- Ashwin -- 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: OMAP35x GP TIMER as a wakeup trigger
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Ashwin Bihari Sent: Monday, April 27, 2009 9:20 PM To: linux-omap@vger.kernel.org Mailing List Subject: OMAP35x GP TIMER as a wakeup trigger Greetings, I need to implement a timer as a wake up trigger while my custom board is in the suspended state. I read in the TRM that all of the GPTIMERs have the capability of generating a wake up interrupt. I'm using the 2.6.28-rc8 PM Kernel which contains the patch to enable all the GPTIMERS as wake up sources. Are you refering to the suspend state coming from: echo mem /sys/power/state OR One of the idle states C0-C6? To understand the wakeup sequence from suspend; take a look at: arch/arm/mach-omap2/serial.c ...esp the IOPAD configuration. You will have to do something similar. ~sanjeev Could someone familiar with this scheme quickly elaborate all the steps that I need to go through to get the system to come out of suspend purely on the timer? Is it is just enough to setup the timer correctly, enable the interrupt in the appropriate register and assume that the PM layer will get the interrupt and do the right thing, or is there more that I have to do? Also, as as additional thing, if the PM layer handles the interrupt and begins the wake-up process, if I could know where that specifically happens, that'd be great since I need to know that the wake-up process is being triggered by the GPTIMER as opposed to the other wakeup triggers and deal with that differently. Regards -- Ashwin -- 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
[PATCH 1/2] OMAP3: PM: Don't do unnecessary searches in omap_sr_vdd*_autocomp_store
From: Phil Carmody ext-phil.2.carm...@nokia.com
When setting to 0, we don't need to do searches for the resource by
its name. In the case where we do search, handle the error condition
cleanly.
Signed-off-by: Phil Carmody ext-phil.2.carm...@nokia.com
---
arch/arm/mach-omap2/smartreflex.c | 24
1 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index ae5c336..ce7d436 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -744,7 +744,6 @@ static ssize_t omap_sr_vdd1_autocomp_store(struct kobject
*kobj,
struct kobj_attribute *attr,
const char *buf, size_t n)
{
- u32 current_vdd1opp_no;
unsigned short value;
if (sscanf(buf, %hu, value) != 1 || (value 1)) {
@@ -752,13 +751,14 @@ static ssize_t omap_sr_vdd1_autocomp_store(struct kobject
*kobj,
return -EINVAL;
}
- current_vdd1opp_no = omap_pm_vdd1_get_opp();
-
- if (value == 0)
+ if (value == 0) {
sr_stop_vddautocomap(SR1);
- else
+ } else {
+ u32 current_vdd1opp_no = omap_pm_vdd1_get_opp();
+ if (IS_ERR_VALUE(current_vdd1opp_no))
+ return -ENODEV;
sr_start_vddautocomap(SR1, current_vdd1opp_no);
-
+ }
return n;
}
@@ -782,7 +782,6 @@ static ssize_t omap_sr_vdd2_autocomp_store(struct kobject
*kobj,
struct kobj_attribute *attr,
const char *buf, size_t n)
{
- u32 current_vdd2opp_no;
unsigned short value;
if (sscanf(buf, %hu, value) != 1 || (value 1)) {
@@ -790,13 +789,14 @@ static ssize_t omap_sr_vdd2_autocomp_store(struct kobject
*kobj,
return -EINVAL;
}
- current_vdd2opp_no = omap_pm_vdd2_get_opp();
-
- if (value == 0)
+ if (value == 0) {
sr_stop_vddautocomap(SR2);
- else
+ } else {
+ u32 current_vdd2opp_no = omap_pm_vdd2_get_opp();
+ if (IS_ERR_VALUE(current_vdd2opp_no))
+ return -ENODEV;
sr_start_vddautocomap(SR2, current_vdd2opp_no);
-
+ }
return n;
}
--
1.5.4.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
[PATCH 0/2] OMAP3: PM: More pedantic parameter and error checking in smartreflex
A couple of simple patches to improve error handling in smartreflex. The first has a practical benefit of avoiding a string-based search in situtations where the result wouldn't be needed. The second is simple paranoia. -- 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: OMAP35x GP TIMER as a wakeup trigger
On Mon, Apr 27, 2009 at 12:08 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 Ashwin Bihari Sent: Monday, April 27, 2009 9:20 PM To: linux-omap@vger.kernel.org Mailing List Subject: OMAP35x GP TIMER as a wakeup trigger Greetings, I need to implement a timer as a wake up trigger while my custom board is in the suspended state. I read in the TRM that all of the GPTIMERs have the capability of generating a wake up interrupt. I'm using the 2.6.28-rc8 PM Kernel which contains the patch to enable all the GPTIMERS as wake up sources. Are you refering to the suspend state coming from: echo mem /sys/power/state OR One of the idle states C0-C6? To understand the wakeup sequence from suspend; take a look at: arch/arm/mach-omap2/serial.c ...esp the IOPAD configuration. You will have to do something similar. ~sanjeev Sanjeev, I was talking about the former (echo mem /sys/power/state) and I will take a look at the serial.c file and might return with more questions. :) Regards -- Ashwin -- 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: OMAP35x GP TIMER as a wakeup trigger
Ashwin, Please see below: Could someone familiar with this scheme quickly elaborate all the steps that I need to go through to get the system to come out of suspend purely on the timer? Is it is just enough to setup the timer correctly, enable the interrupt in the appropriate register and assume that the PM layer will get the interrupt and do the right thing, or is there more that I have to do? [Romit] Already this is being done during the CPU Idle path. Yes you need to program the GPT 1 into oneshot mode with expiry time as appropriate. Also set the CM_CLKSEL_WKUP.CLKSEL_GPT1 to sys_32K clock. PM_MPUGRPSEL_WKUP.GRPSEL_GPT1, PM_WKEN_WKUP.EN_GPT1 should be set. Also, as as additional thing, if the PM layer handles the interrupt and begins the wake-up process, if I could know where that specifically happens, that'd be great since I need to know that the wake-up process is being triggered by the GPTIMER as opposed to the other wakeup triggers and deal with that differently. [Romit] prcm_interrupt_handler. Look for PM_WKST_WKUP. Thanks, -Romit -- 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] Allow OMAP3 GPIO wakeup from power off.
This patch configures the wakeup padconf registers to reflect the sysfs
power/wakeup settings. This allows a GPIO to wake the processor from
off mode.
Signed-off-by: Russ Dill russ.d...@gmail.com
---
arch/arm/plat-omap/gpio.c | 58 ++--
1 files changed, 39 insertions(+), 19 deletions(-)
diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c
index 64852db..3b2054b 100644
--- a/arch/arm/plat-omap/gpio.c
+++ b/arch/arm/plat-omap/gpio.c
@@ -277,7 +277,14 @@ static const struct gpio_pad_range gpio_pads_config[] = {
{ 170, 182, 0x1c6 },
{ 0, 0, 0x1e0 },
{ 186, 186, 0x1e2 },
+ { 187, 187, 0x238 },
+ { 32, 32, 0x23a },
{ 12, 29, 0x5d8 },
+ { 1, 1, 0xa06 },
+ { 30, 30, 0xa08 },
+ { 2, 10, 0xa0a },
+ { 11, 11, 0xa24 },
+ { 31, 31, 0xa26 },
};
/* GPIO - PAD config mapping for OMAP3 */
@@ -289,7 +296,8 @@ struct gpio_pad {
#define OMAP34XX_GPIO_AMT (32 * OMAP34XX_NR_GPIOS)
-struct gpio_pad *gpio_pads;
+static struct gpio_pad *gpio_pads;
+static u16 gpio_pad_map[OMAP34XX_GPIO_AMT];
#endif
static struct gpio_bank *gpio_bank;
@@ -1353,32 +1361,21 @@ static int __init omap3_gpio_pads_init(void)
{
int i, j, min, max, gpio_amt;
u16 offset;
- u16 *gpio_pad_map;
gpio_amt = 0;
- gpio_pad_map = kzalloc(sizeof(u16) * OMAP34XX_GPIO_AMT, GFP_KERNEL);
- if (gpio_pad_map == NULL) {
- printk(KERN_ERR FATAL: Failed to allocate gpio_pad_map\n);
- return -ENOMEM;
- }
-
for (i = 0; i ARRAY_SIZE(gpio_pads_config); i++) {
min = gpio_pads_config[i].min;
max = gpio_pads_config[i].max;
offset = gpio_pads_config[i].offset;
for (j = min; j = max; j++) {
- /*
-* Check if pad has been configured as GPIO.
-* First module (gpio 0...31) is ignored as it is
-* in wakeup domain and does not need special
-* handling during off mode.
-*/
- if (j 31 (omap_ctrl_readw(offset)
+ /* Check if pad has been configured as GPIO. */
+ if ((omap_ctrl_readw(offset)
OMAP34XX_MUX_MODE7) == OMAP34XX_MUX_MODE4) {
gpio_pad_map[j] = offset;
- gpio_amt++;
+ if (j 31)
+ gpio_amt++;
}
offset += 2;
}
@@ -1388,20 +1385,23 @@ static int __init omap3_gpio_pads_init(void)
if (gpio_pads == NULL) {
printk(KERN_ERR FATAL: Failed to allocate gpio_pads\n);
- kfree(gpio_pad_map);
return -ENOMEM;
}
gpio_amt = 0;
for (i = 0; i OMAP34XX_GPIO_AMT; i++) {
- if (gpio_pad_map[i] != 0) {
+ /*
+* First module (gpio 0...31) is ignored as it is
+* in wakeup domain and does not need special
+* handling during off mode.
+*/
+ if (gpio_pad_map[i] i 31) {
gpio_pads[gpio_amt].gpio = i;
gpio_pads[gpio_amt].offset = gpio_pad_map[i];
gpio_amt++;
}
}
gpio_pads[gpio_amt].gpio = -1;
- kfree(gpio_pad_map);
return 0;
}
late_initcall(omap3_gpio_pads_init);
@@ -1676,6 +1676,26 @@ static int omap_gpio_suspend(struct sys_device *dev,
pm_message_t mesg)
__raw_writel(0x, wake_clear);
__raw_writel(bank-suspend_wakeup, wake_set);
spin_unlock_irqrestore(bank-lock, flags);
+
+#ifdef CONFIG_ARCH_OMAP34XX
+ if (bank-method == METHOD_GPIO_24XX) {
+ int j;
+ for (j = 0; j 32; j++) {
+ int offset = gpio_pad_map[j + i * 32];
+ u16 v;
+
+ if (!offset)
+ continue;
+
+ v = omap_ctrl_readw(offset);
+ if (bank-suspend_wakeup (1 j))
+ v |= OMAP3_PADCONF_WAKEUPENABLE0;
+ else
+ v = ~OMAP3_PADCONF_WAKEUPENABLE0;
+ omap_ctrl_writew(v, offset);
+ }
+ }
+#endif
}
return 0;
--
1.6.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] Allow disabling wakeup for serial ports, including during off mode.
This patch causes the OMAP uarts to honor the sysfs power/wakeup file for
IOPADs. Before the OMAP was always woken up from off mode on a rs232 signal
change.
This patch also creates a different platform device for each serial
port so that the wakeup properties can be control per port.
The patch is not in a complete state, but for my testing it was necessary
to disable rs232 wakeup as allowing the signals to float in off mode by
powering off the level converters was causing a wakeup event.
---
arch/arm/mach-omap2/serial.c | 165 --
1 files changed, 126 insertions(+), 39 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 0762165..95b047a 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -49,6 +49,7 @@ struct omap_uart_state {
struct plat_serial8250_port *p;
struct list_head node;
+ struct platform_device pdev;
#if defined(CONFIG_ARCH_OMAP3) defined(CONFIG_PM)
int context_valid;
@@ -63,10 +64,9 @@ struct omap_uart_state {
#endif
};
-static struct omap_uart_state omap_uart[OMAP_MAX_NR_PORTS];
static LIST_HEAD(uart_list);
-static struct plat_serial8250_port serial_platform_data[] = {
+static struct plat_serial8250_port serial_platform_data0[] = {
{
.membase= IO_ADDRESS(OMAP_UART1_BASE),
.mapbase= OMAP_UART1_BASE,
@@ -76,6 +76,12 @@ static struct plat_serial8250_port serial_platform_data[] = {
.regshift = 2,
.uartclk= OMAP24XX_BASE_BAUD * 16,
}, {
+ .flags = 0
+ }
+};
+
+static struct plat_serial8250_port serial_platform_data1[] = {
+ {
.membase= IO_ADDRESS(OMAP_UART2_BASE),
.mapbase= OMAP_UART2_BASE,
.irq= 73,
@@ -84,6 +90,12 @@ static struct plat_serial8250_port serial_platform_data[] = {
.regshift = 2,
.uartclk= OMAP24XX_BASE_BAUD * 16,
}, {
+ .flags = 0
+ }
+};
+
+static struct plat_serial8250_port serial_platform_data2[] = {
+ {
.membase= IO_ADDRESS(OMAP_UART3_BASE),
.mapbase= OMAP_UART3_BASE,
.irq= 74,
@@ -197,6 +209,40 @@ static inline void omap_uart_save_context(struct
omap_uart_state *uart) {}
static inline void omap_uart_restore_context(struct omap_uart_state *uart) {}
#endif /* CONFIG_ARCH_OMAP3 */
+static void omap_uart_enable_wakeup(struct omap_uart_state *uart)
+{
+ /* Set wake-enable bit */
+ if (uart-wk_en uart-wk_mask) {
+ u32 v = __raw_readl(uart-wk_en);
+ v |= uart-wk_mask;
+ __raw_writel(v, uart-wk_en);
+ }
+
+ /* Ensure IOPAD wake-enables are set */
+ if (cpu_is_omap34xx() uart-padconf) {
+ u16 v = omap_ctrl_readw(uart-padconf);
+ v |= OMAP3_PADCONF_WAKEUPENABLE0;
+ omap_ctrl_writew(v, uart-padconf);
+ }
+}
+
+static void omap_uart_disable_wakeup(struct omap_uart_state *uart)
+{
+ /* Clear wake-enable bit */
+ if (uart-wk_en uart-wk_mask) {
+ u32 v = __raw_readl(uart-wk_en);
+ v = ~uart-wk_mask;
+ __raw_writel(v, uart-wk_en);
+ }
+
+ /* Ensure IOPAD wake-enables are cleared */
+ if (cpu_is_omap34xx() uart-padconf) {
+ u16 v = omap_ctrl_readw(uart-padconf);
+ v = ~OMAP3_PADCONF_WAKEUPENABLE0;
+ omap_ctrl_writew(v, uart-padconf);
+ }
+}
+
static void omap_uart_smart_idle_enable(struct omap_uart_state *uart,
int enable)
{
@@ -220,6 +266,11 @@ static inline void omap_uart_restore(struct
omap_uart_state *uart)
static inline void omap_uart_disable_clocks(struct omap_uart_state *uart)
{
+ if (device_may_wakeup(uart-pdev.dev))
+ omap_uart_enable_wakeup(uart);
+ else
+ omap_uart_disable_wakeup(uart);
+
if (!uart-clocked)
return;
@@ -290,6 +341,7 @@ void omap_uart_resume_idle(int num)
if (__raw_readl(uart-wk_st) uart-wk_mask)
omap_uart_block_sleep(uart);
+ omap_uart_enable_wakeup(uart);
return;
}
}
@@ -300,6 +352,7 @@ void omap_uart_prepare_suspend(void)
struct omap_uart_state *uart;
list_for_each_entry(uart, uart_list, node) {
+ omap_uart_enable_wakeup(uart);
omap_uart_allow_sleep(uart);
}
}
@@ -343,16 +396,13 @@ static irqreturn_t omap_uart_interrupt(int irq, void
*dev_id)
return IRQ_NONE;
}
-static u32 sleep_timeout = DEFAULT_TIMEOUT;
-
static void omap_uart_idle_init(struct omap_uart_state *uart)
{
-
Re: No 2.6.29 omap tag?
* Kalle Valo kalle.v...@iki.fi [090425 09:01]: Felipe Contreras felipe.contre...@gmail.com writes: Hi, Hello, Is there a reason why there is no v2.6.29-omap1 tag? I don't know. But at least there's a branch named omap-2.6.29 and I used that. Added v2.6.29-omap1 tag now. 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: OMAP35x GP TIMER as a wakeup trigger
Ashwin Bihari abih...@gmail.com writes:
I need to implement a timer as a wake up trigger while my custom board
is in the suspended state. I read in the TRM that all of the GPTIMERs
have the capability of generating a wake up interrupt. I'm using the
2.6.28-rc8 PM Kernel which contains the patch to enable all the
GPTIMERS as wake up sources.
Try the patch below on the current PM branch. I use this for
debugging PM code when no other wakeup sources (keypad, UART, etc. are
working.)
Kevin
From bf81b7cce8967a425f1aa3d73782c1eb0367ce1a Mon Sep 17 00:00:00 2001
From: Kevin Hilman khil...@deeprootsystems.com
Date: Fri, 24 Apr 2009 16:13:47 -0700
Subject: [PATCH] OMAP3: PM: Add feature to wake from suspend on timer
If a non-zero value is written to /sys/power/wakeup_timer_seconds,
A timer wakeup event will wake the system and resume after the
configured number of seconds.
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/pm.c | 15 +--
arch/arm/mach-omap2/pm.h |3 +++
arch/arm/mach-omap2/pm34xx.c | 22 ++
arch/arm/mach-omap2/timer-gp.c |2 ++
4 files changed, 40 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index 50d95cd..dde0af3 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -42,6 +42,7 @@ unsigned short enable_dyn_sleep;
unsigned short clocks_off_while_idle;
unsigned short enable_off_mode;
unsigned short voltage_off_while_idle;
+unsigned short wakeup_timer_seconds;
atomic_t sleep_block = ATOMIC_INIT(0);
static ssize_t idle_show(struct kobject *, struct kobj_attribute *, char *);
@@ -76,6 +77,9 @@ static struct kobj_attribute vdd2_lock_attr =
#endif
+static struct kobj_attribute wakeup_timer_seconds_attr =
+ __ATTR(wakeup_timer_seconds, 0644, idle_show, idle_store);
+
static ssize_t idle_show(struct kobject *kobj, struct kobj_attribute *attr,
char *buf)
{
@@ -87,6 +91,8 @@ static ssize_t idle_show(struct kobject *kobj, struct
kobj_attribute *attr,
return sprintf(buf, %hu\n, enable_off_mode);
else if (attr == voltage_off_while_idle_attr)
return sprintf(buf, %hu\n, voltage_off_while_idle);
+ else if (attr == wakeup_timer_seconds_attr)
+ return sprintf(buf, %hu\n, wakeup_timer_seconds);
else
return -EINVAL;
}
@@ -96,8 +102,7 @@ static ssize_t idle_store(struct kobject *kobj, struct
kobj_attribute *attr,
{
unsigned short value;
- if (sscanf(buf, %hu, value) != 1 ||
- (value != 0 value != 1)) {
+ if (sscanf(buf, %hu, value) != 1) {
printk(KERN_ERR idle_store: Invalid value\n);
return -EINVAL;
}
@@ -109,6 +114,8 @@ static ssize_t idle_store(struct kobject *kobj, struct
kobj_attribute *attr,
} else if (attr == enable_off_mode_attr) {
enable_off_mode = value;
omap3_pm_off_mode_enable(enable_off_mode);
+ } else if (attr == wakeup_timer_seconds_attr) {
+ wakeup_timer_seconds = value;
} else if (attr == voltage_off_while_idle_attr) {
voltage_off_while_idle = value;
if (voltage_off_while_idle)
@@ -255,6 +262,10 @@ static int __init omap_pm_init(void)
printk(KERN_ERR sysfs_create_file failed: %d\n, error);
return error;
}
+ error = sysfs_create_file(power_kobj,
+ wakeup_timer_seconds_attr.attr);
+ if (error)
+ printk(KERN_ERR sysfs_create_file failed: %d\n, error);
#ifdef CONFIG_OMAP_PM_SRF
error = sysfs_create_file(power_kobj,
vdd1_opp_attr.attr);
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index 942a990..66effed 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -30,6 +30,9 @@ extern unsigned short voltage_off_while_idle;
extern atomic_t sleep_block;
extern void *omap3_secure_ram_storage;
+extern unsigned short wakeup_timer_seconds;
+extern struct omap_dm_timer *gptimer_wakeup;
+
extern void omap2_block_sleep(void);
extern void omap2_allow_sleep(void);
#ifdef CONFIG_ARCH_OMAP3
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index d8795b5..3f41417 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -26,6 +26,7 @@
#include linux/module.h
#include linux/list.h
#include linux/err.h
+#include linux/clk.h
#include mach/gpio.h
#include mach/sram.h
@@ -41,6 +42,8 @@
#include mach/dma.h
#include mach/gpmc.h
#include mach/dma.h
+#include mach/dmtimer.h
+
#include asm/tlbflush.h
#include cm.h
@@ -552,6 +555,22 @@ out:
static void (*saved_idle)(void);
static suspend_state_t suspend_state;
+static void omap2_pm_wakeup_on_timer(u32 seconds)
+{
+ u32 tick_rate, cycles;
+
+ if (!seconds)
+
[APPLIED] [PATCH] OMAP2 H4: fix build by removing IRDA support
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Initial commit ID (Likely to change): 5905102dbeebe4d733b646caad5eced616b9d65a PatchWorks http://patchwork.kernel.org/patch/19961/ Git http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=5905102dbeebe4d733b646caad5eced616b9d65a -- 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] OMAP: pandora: setup regulator framework for MMC
On Sunday 26 April 2009, Grazvydas Ignotas wrote:
Setup regulators for MMC1 and MMC2 to get those SD slots
working again.
Signed-off-by: Grazvydas Ignotas nota...@gmail.com
Acked-by: David Brownell dbrown...@users.sourceforge.net
CC: David Brownell davi...@pacbell.net
---
arch/arm/mach-omap2/board-omap3pandora.c | 45
++
1 files changed, 45 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3pandora.c
b/arch/arm/mach-omap2/board-omap3pandora.c
index c67f62f..c525b16 100644
--- a/arch/arm/mach-omap2/board-omap3pandora.c
+++ b/arch/arm/mach-omap2/board-omap3pandora.c
@@ -27,6 +27,7 @@
#include linux/spi/spi.h
#include linux/spi/ads7846.h
+#include linux/regulator/machine.h
#include linux/i2c/twl4030.h
#include linux/mtd/mtd.h
@@ -171,6 +172,14 @@ static struct omap_uart_config omap3pandora_uart_config
__initdata = {
.enabled_uarts = (1 2), /* UART3 */
};
+static struct regulator_consumer_supply pandora_vmmc1_supply = {
+ .supply = vmmc,
+};
+
+static struct regulator_consumer_supply pandora_vmmc2_supply = {
+ .supply = vmmc,
+};
+
static int omap3pandora_twl_gpio_setup(struct device *dev,
unsigned gpio, unsigned ngpio)
{
@@ -179,6 +188,10 @@ static int omap3pandora_twl_gpio_setup(struct device
*dev,
omap3pandora_mmc[1].gpio_cd = gpio + 1;
twl4030_mmc_init(omap3pandora_mmc);
+ /* link regulators to MMC adapters */
+ pandora_vmmc1_supply.dev = omap3pandora_mmc[0].dev;
+ pandora_vmmc2_supply.dev = omap3pandora_mmc[1].dev;
+
return 0;
}
@@ -189,6 +202,36 @@ static struct twl4030_gpio_platform_data
omap3pandora_gpio_data = {
.setup = omap3pandora_twl_gpio_setup,
};
+/* VMMC1 for MMC1 pins CMD, CLK, DAT0..DAT3 (20 mA, plus card == max 220 mA)
*/
+static struct regulator_init_data pandora_vmmc1 = {
+ .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 = pandora_vmmc1_supply,
+};
+
+/* VMMC2 for MMC2 pins CMD, CLK, DAT0..DAT3 (max 100 mA) */
+static struct regulator_init_data pandora_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 = pandora_vmmc2_supply,
+};
+
static struct twl4030_usb_data omap3pandora_usb_data = {
.usb_mode = T2_USB_MODE_ULPI,
};
@@ -198,6 +241,8 @@ static struct twl4030_platform_data omap3pandora_twldata
= {
.irq_end= TWL4030_IRQ_END,
.gpio = omap3pandora_gpio_data,
.usb= omap3pandora_usb_data,
+ .vmmc1 = pandora_vmmc1,
+ .vmmc2 = pandora_vmmc2,
};
static struct i2c_board_info __initdata omap3pandora_i2c_boardinfo[] = {
--
1.5.6.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] regulator core: fix double-free in regulator_register() error path
On Saturday 25 April 2009, Paul Walmsley wrote: device_unregister() calls regulator_dev_release() which frees rdev. The subsequent kfree corrupts memory and causes some OMAP3 systems to oops on boot in regulator_get(). For the 3430SDP users out there, this patch also fixes the boot hang after regulator_init_complete: incomplete constraints, leaving VAUX3 on on that device. For the record, that incomplete constraints message is bogus. On that board, VAUX3 has a complete set of constraints: it may only emit 2.8V. What it lacks is something entirely different: driver support for the LCD which uses the regulator framework, instead of just bypassing it and talking directly to the PMIC. By the time it gets there, the LCD has probably been turned on. Mark and/or Liam ... you might want to fix that diagnostic, to avoid leading more developers astray! -- 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] [Patch 0/2] Proposal for changes to TWL4030/TWL5030 framework for integrating the new TWL6030 chip
Hi folks, We have a new TWL6030 chip that is coming in. In brief, the following are the changes w.r.t. TWL5030: 0. This is the companion chip for OMAP4430. 1. Unlike in TWL5030, audio and power chips are going to be separate chips as TWL6030 and TWL6031. 2. Keypad and GPIO features are no more present in TWL6030 (the power companion chip). They all move into OMAP. 4. Register and module base names/addresses changes (as expected from 2). 5. Changes in interrupt framework: - No more PIH and SIH - 3 ISRs INT_STS_A, INT_STS_B and INT_STS_C at 3 consecutive address locations (that will allow an I2C burst read). 6. The modules that are inherited from TWL5030 to TWL6030 remain same (like RTC, BCI) except MADC with some minor changes making it a General Purpose ADC (GPADC). I'd like to propose a new generic framework that will incorporate TWL4030/TWL5030 and TWL6030 functionalities/changes seamlessly. Proposal 1. Rename all registers/functions etc. from twl4030/TWL4030 to twl/TWL. - This would allow unchanged modules (like RTC) to work in the same way, transparent to whether it is part of TWL4030 or TWL6030. 2. Have a new twl.c file, that will define functions like - twl_i2c_write - twl_i2c_write_u8 - twl_i2c_read - twl_i2c_read_u8 - twl_init - twl_exit - twl_probe - twl_remove These functions implement the functionalities common to both TWL4030 and TWL6030, doing away with the need to have a copy of these functions in two places. 3. twl4030-core.c and twl4030-irq.c files will define functions that changes between TWL4030 and TWL6030, like: - add_children(): We do not need keypad and GPIO; MADC changes to GPADC in case of TWL6030. - twl_irq_thread() twl4030-irq.c: We have new registers to read interrupts from. No more PIH and SIH. So the core loop that dispatches the interrupt changes. We can also use an I2C burst read to get 3 interrupt registers in one shot for TWL6030. 4. New twl6030-core.c and twl6030-irq.c that implements the TWL6030 counter parts of functions applicable in (3). 5. A config option will determine whether TWL4030 or TWL6030 will be compiled as a part of the kernel. NB: == Please note that the patches are for RFC, and they might not even compile properly. These are draft patches to convey the idea across. So please ignore styling and formatting errors. -- With Regards, Jagadeesh Bhaskar P Some men see things as they are and say why - I dream things that never were and say why not. - George Bernard Shaw -- 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] [Patch 2/2] Proposal for changes to TWL4030/TWL5030 framework for integrating the new TWL6030 chip
This patch:
- Creates a new file twl.c
- Segregates functions common between TWL4030 and TWL6030 and moves
them from twl4030-core.cinto twl.c
Index: linux-omap-2.6/drivers/mfd/twl.c
===
--- /dev/null
+++ linux-omap-2.6/drivers/mfd/twl.c
@@ -0,0 +1,279 @@
+/*
+ * twl.c - driver for TWL device
+ *
+ * Copyright (C) 2005-2009 Texas Instruments, Inc.
+ *
+ * Modifications to defer interrupt handling to a kernel thread:
+ * Copyright (C) 2006 MontaVista Software, Inc.
+ *
+ * Based on tlv320aic23.c:
+ * Copyright (c) by Kai Svahn kai.sv...@nokia.com
+ *
+ * Code cleanup and modifications to IRQ handler.
+ * by syed khasim x0kha...@ti.com
+ *
+ * Moved twl generic code from twl4030-core.c to twl.c
+ * - Jagadeesh Pakaravoor j-pakarav...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * 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., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+
+
+/*--*/
+
+/* Exported Functions */
+
+/**
+ * twl_i2c_write - Writes a n bit register in TWL
+ * @mod_no: module number
+ * @value: an array of num_bytes+1 containing data to write
+ * @reg: register address (just offset will do)
+ * @num_bytes: number of bytes to transfer
+ *
+ * IMPORTANT: for 'value' parameter: Allocate value num_bytes+1 and
+ * valid data starts at Offset 1.
+ *
+ * Returns the result of operation - 0 is success
+ */
+int twl_i2c_write(u8 mod_no, u8 *value, u8 reg, unsigned num_bytes)
+{
+ int ret;
+ int sid;
+ struct twl_client *twl;
+ struct i2c_msg *msg;
+
+ if (unlikely(mod_no TWL_MODULE_LAST)) {
+ pr_err(%s: invalid module number %d\n, DRIVER_NAME, mod_no);
+ return -EPERM;
+ }
+ sid = twl_map[mod_no].sid;
+ twl = twl_modules[sid];
+
+ if (unlikely(!inuse)) {
+ pr_err(%s: client %d is not initialized\n, DRIVER_NAME, sid);
+ return -EPERM;
+ }
+ mutex_lock(twl-xfer_lock);
+ /*
+* [MSG1]: fill the register address data
+* fill the data Tx buffer
+*/
+ msg = twl-xfer_msg[0];
+ msg-addr = twl-address;
+ msg-len = num_bytes + 1;
+ msg-flags = 0;
+ msg-buf = value;
+ /* over write the first byte of buffer with the register address */
+ *value = twl_map[mod_no].base + reg;
+ ret = i2c_transfer(twl-client-adapter, twl-xfer_msg, 1);
+ mutex_unlock(twl-xfer_lock);
+
+ /* i2cTransfer returns num messages.translate it pls.. */
+ if (ret = 0)
+ ret = 0;
+ return ret;
+}
+EXPORT_SYMBOL(twl_i2c_write);
+
+/**
+ * twl_i2c_read - Reads a n bit register in TWL
+ * @mod_no: module number
+ * @value: an array of num_bytes containing data to be read
+ * @reg: register address (just offset will do)
+ * @num_bytes: number of bytes to transfer
+ *
+ * Returns result of operation - num_bytes is success else failure.
+ */
+int twl_i2c_read(u8 mod_no, u8 *value, u8 reg, unsigned num_bytes)
+{
+ int ret;
+ u8 val;
+ int sid;
+ struct twl_client *twl;
+ struct i2c_msg *msg;
+
+ if (unlikely(mod_no TWL_MODULE_LAST)) {
+ pr_err(%s: invalid module number %d\n, DRIVER_NAME, mod_no);
+ return -EPERM;
+ }
+ sid = twl_map[mod_no].sid;
+ twl = twl_modules[sid];
+
+ if (unlikely(!inuse)) {
+ pr_err(%s: client %d is not initialized\n, DRIVER_NAME, sid);
+ return -EPERM;
+ }
+ mutex_lock(twl-xfer_lock);
+ /* [MSG1] fill the register address data */
+ msg = twl-xfer_msg[0];
+ msg-addr = twl-address;
+ msg-len = 1;
+ msg-flags = 0; /* Read the register value */
+ val = twl_map[mod_no].base + reg;
+ msg-buf = val;
+ /* [MSG2] fill the data rx buffer */
+ msg = twl-xfer_msg[1];
+ msg-addr = twl-address;
+ msg-flags = I2C_M_RD; /* Read the register value */
+ msg-len = num_bytes; /* only n bytes */
+ msg-buf = value;
+ ret = i2c_transfer(twl-client-adapter, twl-xfer_msg, 2);
+ mutex_unlock(twl-xfer_lock);
+
+ /* i2cTransfer returns num messages.translate it pls.. */
+ if (ret = 0)
+ ret = 0;
+ return ret;
+}
