Re: [PATCH 01/13] Revert ARM: OMAP: Mask interrupts when disabling interrupts, v2
On Fri, May 22, 2009 at 11:54 PM, Kevin Hilman khil...@deeprootsystems.com wrote: Kim Kyuwon q1@samsung.com writes: Kevin Hilman wrote: This reverts commit 5461af5af5c6a7fee78978aafe720541bf3a2f55. Adding a disable hook to the irq_chip is not the way to fix the problem being addressed by this patch. Instead, we need to fix support for [enable|disable]_irq_wake(). Agree with you if we can use disable_irq_wake for MPU Interrupt with not masking the IRQ. Can you explain how we can fix support for disable_irq_wake() for omap_irq_chip? Yes. The PRCM has a wake-enable per device bit that can be set (see PM_WKEN_pwrdm) to control device wakeup enables. PM_WKEN_pwrdm is not entirely matched to each MPU interrupt. If you want to use disable_irq_wake() with enabling PRCM_Interrupt, you should disable all PM_WKEN_pwrdm bits. And how can you make support of disable_irq_wake() for other MPU interrupts? But the implemenation of that should not hold up this revert because this patch breaks *all* wakeups since the PRCM interrupt itself is disabled in the suspend path. Yes, I saw the same problem. This is caused by resume_device_irqs() recently added by Rafael not by my patch. I'm asking him that he made a right decision. As a workaround for your USB problem that this patch was initially intended to fix you could manually disable USB OTG wakeups like this: wken = prm_read_mod_reg(CORE_MOD, PM_WKEN); wken = ~OMAP3430_EN_HSOTGUSB; prm_write_mod_reg(wken, CORE_MOD, PM_WKEN); Did you checked this masking prevent waking up from the interrupt of USB HOST? Regards, Kyuwon -- 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 01/13] Revert ARM: OMAP: Mask interrupts when disabling interrupts, v2
On Sat, May 23, 2009 at 3:16 AM, Kevin Hilman khil...@deeprootsystems.com wrote: Kim Kyuwon chamm...@gmail.com writes: On Fri, May 22, 2009 at 11:54 PM, Kevin Hilman khil...@deeprootsystems.com wrote: Kim Kyuwon q1@samsung.com writes: Kevin Hilman wrote: This reverts commit 5461af5af5c6a7fee78978aafe720541bf3a2f55. Adding a disable hook to the irq_chip is not the way to fix the problem being addressed by this patch. Instead, we need to fix support for [enable|disable]_irq_wake(). Agree with you if we can use disable_irq_wake for MPU Interrupt with not masking the IRQ. Can you explain how we can fix support for disable_irq_wake() for omap_irq_chip? Yes. The PRCM has a wake-enable per device bit that can be set (see PM_WKEN_pwrdm) to control device wakeup enables. PM_WKEN_pwrdm is not entirely matched to each MPU interrupt. Correct. This bit disables the module from generating any wakeup event to the PRCM. If you want to use disable_irq_wake() with enabling PRCM_Interrupt, you should disable all PM_WKEN_pwrdm bits. And how can you make support of disable_irq_wake() for other MPU interrupts? To control the ability of a module to wake the MPU directly, we would need to use the PM_MPUGRPSEL_pwrdm regs. Sorry but I can't believe until it is implemented in OMAP and I can confirm it. But the implemenation of that should not hold up this revert because this patch breaks *all* wakeups since the PRCM interrupt itself is disabled in the suspend path. Yes, I saw the same problem. This is caused by resume_device_irqs() recently added by Rafael not by my patch. The point is, with your patch applied, *all* OMAP wakeups are broken upstream. You're right, your patch didn't cause the broken wakeup problem by itself, but your patch on top of Rafael's in combination with the new lazy-disable support which are both already in mainline breaks *all* OMAP wakeup capabilities. Therefore it should be reverted and the OMAP specific IRQ wake support fixed. I am working on fixing the OMAP IRQ wake support, but I do not want that to hold up this series getting upstream. However, we don't know yet OMAP IRQ wake support is well implemented or not. I'm asking him that he made a right decision. Yes, we had a long discussion on that on linux-pm and I came to the conclusion that while his change was probably premature, it's the right decision and platforms with wakeup capabilities should use/fix their set_irq_wakeup() functionality. I know... I jumped into that discussion. But you insisted as following... -- Interrupt wakeups can be disabled at the PRCM level. Or more simply we can keep a mask of wakeup-enable interrupts and use that. I will experiment with getting disable_irq_wake() working. -- So I quited. But I think we should have this discussion again. As a workaround for your USB problem that this patch was initially intended to fix you could manually disable USB OTG wakeups like this: wken = prm_read_mod_reg(CORE_MOD, PM_WKEN); wken = ~OMAP3430_EN_HSOTGUSB; prm_write_mod_reg(wken, CORE_MOD, PM_WKEN); Did you checked this masking prevent waking up from the interrupt of USB HOST? No I did not test, nor was I able to reproduce your original problem since the description wasn't that clear to me. This will disable the USB OTG controller module from generating wakeups for any reason. If disabling the device wakeup in PM_WKEN is still resutling in interrupts, then the powerdomain with that device is most likely not in retention/off. I do know that disabling PM_WKEN for UARTs in the same powerdomain as USB OTG (CORE) will stop the UART from waking, and thus from generating interrupts, as long as the powerdomain has actually transitioned to retention/off. Re: USB HOST. The problem you reported in your original patch was that you were waking from IRQ 92, which is the USB OTG interrupt. If your problem is with USBHOST, that is in a different powerdomain. OK I will check it when I'm in my office. Now it's great weekend. Have a good weekend!. Regards, Kyuwon -- 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 01/13] Revert ARM: OMAP: Mask interrupts when disabling interrupts, v2
On Sat, May 23, 2009 at 8:22 AM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Fri, May 22, 2009 at 07:54:32AM -0700, Kevin Hilman wrote: But the implemenation of that should not hold up this revert because this patch breaks *all* wakeups since the PRCM interrupt itself is disabled in the suspend path. That is not mentioned in the patch description (and it should be). What this paragraph is saying is that this revert is most definitely fixing a regression. Any fix which causes other breakage is not a fix, and therefore this revert needs to go in no matter what. The problem is that this patch(which is written by me) was merged much earlier than Rafael's patch. So I think Rafael's patch causes other breakage. -- 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 -- Kyuwon (규원) -- 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 01/13] Revert ARM: OMAP: Mask interrupts when disabling interrupts, v2
Kevin Hilman wrote:
This reverts commit 5461af5af5c6a7fee78978aafe720541bf3a2f55.
Adding a disable hook to the irq_chip is not the way to fix the
problem being addressed by this patch. Instead, we need to fix
support for [enable|disable]_irq_wake().
Agree with you if we can use disable_irq_wake for MPU Interrupt with not
masking the IRQ. Can you explain how we can fix support for
disable_irq_wake() for omap_irq_chip?
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/irq.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/irq.c b/arch/arm/mach-omap2/irq.c
index 998c5c4..08a3b99 100644
--- a/arch/arm/mach-omap2/irq.c
+++ b/arch/arm/mach-omap2/irq.c
@@ -134,7 +134,6 @@ static struct irq_chip omap_irq_chip = {
.ack= omap_mask_ack_irq,
.mask = omap_mask_irq,
.unmask = omap_unmask_irq,
- .disable = omap_mask_irq,
};
static void __init omap_irq_bank_init_one(struct omap_irq_bank *bank)
--
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: UART: don't initialize membase and mapbase when its port is not enabled
Hi All,
We are using two UARTs port in OMAP3430 board shown as following
UART 1 - not used
UART 2 - BT
UART 3 - console (console=ttyS2,115200n8 in 'bootargs' of bootloader)
Because we are not using UART port 1, I configured our board file as following
735 static struct omap_uart_config omap3_boardname_uart_config __initdata = {
736 .enabled_uarts = ((1 1) | (1 2)),
737 };
However, I couldn't see any console message.
If I configured like
735 static struct omap_uart_config omap3_boardname_uart_config __initdata = {
736 .enabled_uarts = ((1 0) (1 1) | (1 2)),
737 };
I could see console messages. But I think this is not the real solution.
Is it correct to use ttyS2, if I use UART3 as console UART?
Anyway, I kept track of this problem and I'm sending the patch.
Please let me know your opinion about this patch.
---
From 88fc1f0872fd2c6ac42501027e5bf69156cce37f Mon Sep 17 00:00:00 2001
From: Kim Kyuwon q1@samsung.com
Date: Thu, 14 May 2009 17:05:35 +0900
Subject: [PATCH] OMAP: UART: don't initialize membase and mapbase when
its port is not enabled
If membase and mapbase are zero, its uart port which is registered to
serial8250(i.e serial8250_port[i]) is overridden, because the
serial8250_find_match_or_unsed() function consider this port as a
unused entry. This make the serial2850_console_setup function use
incorrect uart port, because co-index is used as the index of
serial8250_port. This patch prevent using wrong index of uart.
Signed-off-by: Kim Kyuwon q1@samsung.com
---
arch/arm/mach-omap2/serial.c |5 +
1 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 4dcf39c..01c2da7 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -118,11 +118,8 @@ void __init omap_serial_init(void)
for (i = 0; i OMAP_MAX_NR_PORTS; i++) {
struct plat_serial8250_port *p = serial_platform_data + i;
- if (!(info-enabled_uarts (1 i))) {
- p-membase = NULL;
- p-mapbase = 0;
+ if (!(info-enabled_uarts (1 i)))
continue;
- }
sprintf(name, uart%d_ick, i+1);
uart_ick[i] = clk_get(NULL, name);
--
1.5.2.5
--
Kyuwon (규원)
--
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: OMAP3: PM: Add the wakeup source driver, v4
Kevin Hilman writes: Kim Kyuwon chamm...@gmail.com writes: Hi Kevin, Could you please review this fourth version of OMAP wakeup source driver? Yes. I'm working through my backlog of PM branch submissions this week. I've been focusing on getting some of the PM branch reworked and rebased so I can start submitting upstream. I apologize for the delays, but the upstream work is currently higher priority than adding large new features to the PM branch. I agree. Thank you for your works about OMAP tree and OMAP PM brach! -- 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: OMAP3: PM: Add the wakeup source driver, v4
Hi Kevin,
Could you please review this fourth version of OMAP wakeup source driver?
Regards,
Kyuwon.
On Tue, May 5, 2009 at 6:13 PM, Kim Kyuwon q1@samsung.com wrote:
Sometimes, it is necessary to find out what does wake up my board from
suspend?. Notifying wake-up source feature may be used to blame unexpected
wake-up events which increase power consumption. And user mode applications
can act smartly according to the wake-up event from Suspend-to-RAM state to
minimize power consumption. Note that this driver can't inform wake-up events
from idle state. This driver uses sysfs interface to give information to user
mode applications like:
cat /sys/power/omap_resume_irq
cat /sys/power/omap_resume_event
This driver also provides the I/O pad wake-up source configuration. Specific
GPIO settings in the board file are:
/* I/O pad wakeup source configuration */
static struct iopad_wake boardname_iopad_wake[] = {
{
.mux_index = AE7_34XX_GPIO24,
.alias = KEY_PWRON,
},
{
.mux_index = ETK_D9_GPIO23,
.alias = USB_DETECT,
},
};
static struct omap_wake_platform_data boardname_wake_data = {
.iopad_wakes= boardname_iopad_wake,
.iopad_wake_num = ARRAY_SIZE(boardname_iopad_wake),
};
static struct platform_device boardname_wakeup = {
.name = omap-wake,
.id = -1,
.dev= {
.platform_data = boardname_wake_data,
},
};
The patch adds Kconfig options OMAP34xx wakeup source support under System
type-TI OMAP implementations menu.
Signed-off-by: Kim Kyuwon q1@samsung.com
---
arch/arm/mach-omap2/Makefile |1 +
arch/arm/mach-omap2/irq.c | 21 ++-
arch/arm/mach-omap2/omapdev-common.h |3 +
arch/arm/mach-omap2/omapdev3xxx.h | 63 +
arch/arm/mach-omap2/pm34xx.c | 13 +
arch/arm/mach-omap2/prcm-common.h |4 +
arch/arm/mach-omap2/prm-regbits-34xx.h|5 +
arch/arm/mach-omap2/wake34xx.c| 409
+
arch/arm/plat-omap/Kconfig|9 +
arch/arm/plat-omap/include/mach/irqs.h|4 +
arch/arm/plat-omap/include/mach/mux.h |3 +
arch/arm/plat-omap/include/mach/omapdev.h |3 +
arch/arm/plat-omap/include/mach/wake.h| 52
arch/arm/plat-omap/mux.c | 25 ++-
14 files changed, 605 insertions(+), 10 deletions(-)
create mode 100644 arch/arm/mach-omap2/wake34xx.c
create mode 100644 arch/arm/plat-omap/include/mach/wake.h
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index c58bab4..cfc5a13 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -25,6 +25,7 @@ obj-$(CONFIG_ARCH_OMAP2) += pm24xx.o
obj-$(CONFIG_ARCH_OMAP24XX)+= sleep24xx.o
obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o cpuidle34xx.o
obj-$(CONFIG_PM_DEBUG) += pm-debug.o
+obj-$(CONFIG_OMAP3_WAKE) += wake34xx.o
endif
# SmartReflex driver
diff --git a/arch/arm/mach-omap2/irq.c b/arch/arm/mach-omap2/irq.c
index 700fc3d..18ac725 100644
--- a/arch/arm/mach-omap2/irq.c
+++ b/arch/arm/mach-omap2/irq.c
@@ -33,9 +33,6 @@
#define INTC_MIR_SET0 0x008c
#define INTC_PENDING_IRQ0 0x0098
-/* Number of IRQ state bits in each MIR register */
-#define IRQ_BITS_PER_REG 32
-
/*
* OMAP2 has a number of different interrupt controllers, each interrupt
* controller is identified as its own bank. Register definitions are
@@ -193,6 +190,24 @@ int omap_irq_pending(void)
return 0;
}
+void omap_get_pending_irqs(u32 *pending_irqs, unsigned len)
+{
+ int i, j = 0;
+
+ for (i = 0; i ARRAY_SIZE(irq_banks); i++) {
+ struct omap_irq_bank *bank = irq_banks + i;
+ int irq;
+
+ for (irq = 0; irq bank-nr_irqs j len;
+ irq += IRQ_BITS_PER_REG) {
+ int offset = irq (~(IRQ_BITS_PER_REG - 1));
+
+ pending_irqs[j++] = intc_bank_read_reg(bank,
+ (INTC_PENDING_IRQ0 + offset));
+ }
+ }
+}
+
void __init omap_init_irq(void)
{
unsigned long nr_of_irqs = 0;
diff --git a/arch/arm/mach-omap2/omapdev-common.h
b/arch/arm/mach-omap2/omapdev-common.h
index a2d4855..57b9b0b 100644
--- a/arch/arm/mach-omap2/omapdev-common.h
+++ b/arch/arm/mach-omap2/omapdev-common.h
@@ -228,10 +228,13 @@ static struct omapdev *omapdevs[] = {
hsmmc2_3xxx_omapdev,
mcspi3_3xxx_omapdev,
gptimer1_3xxx_omapdev,
+ gptimer12_3xxx_omapdev,
prm_3xxx_omapdev,
cm_3xxx_omapdev
Re: PM: 4 Problems in OMAP3430 DVFS (SmartReflex, Cpufreq)
Hi Kevin, Tony, Paul and other experts. Woodruff, Richard wrote: From: Paul Walmsley [mailto:p...@pwsan.com] Sent: Thursday, April 23, 2009 3:53 AM To: Woodruff, Richard 4. Current PM code didn't enable the maximum clock (i.e. CPU: 600Mhz) according to the comment as below: /* Avoid registering the 120% Overdrive with CPUFreq */ prcm = mpu_opps + MAX_VDD1_OPP - 1; But in some cases, we should use 600Mhz for multimedia application. And, even thought we enable the maximum clock, CPU frequency seldom goes into maximum clock. I think we don't have to avoid registering the max OPP. Do you know if this restriction can be lifted now, i.e., can the silicon run at VDD1 OPP1 100% of the time and meet the device lifespan targets? So, there have been some characterization changes which give more leeway for software usage off overdrive. What you found before was guarantees against typical mobile usage for a few classes of devices. This was done using a mix of OPPs with the majority of active time in lower OPPs and inactive time in low idles (optimal usage for mix of typical operations, this is the way you would want to run ideally). Against this and many more variables, reliability data was validated and published. Recently there was some change to also measure active time at max overdrive for same usage mix. This resulted in still meeting lifetime goals for typical usage. This can translate to a smart phone maker of being able to use overdrive as they see fit and still have long life (assuming they can supply adequate power and still dissipate what ever additional heat there is). This is still not 100% of the time in active mode. What do you think of enabling to register the 120% Overdrive with CPUFreq in l-o tree?. Regard, Kyuwon I suspect TI will continue to create parts for certain markets when the need is there. The part might be nearly identical but the way it's rated (with chip binning and other tricks) will allow different guarantees. This fits well with mobile business customer needs. As an open source individual owner of a device, you might do things in a non-typical way. You are free to do this. Depending on which base chip variant you are using, its life may have some impact (or not). Your chip likely will still last many years. The phone or other device might die first. All that said, today personally, I feel much more comfortable exposing overdrives in the reference code. Mobile users and their devices which actually sleep at night should be pretty safe. Watch data sheets for details :) Regards, Richard W. -- 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] rtc: rtc-twl4030 don't mask alarm interrupts on suspend
Hi All,
This patch was originally sent to linux-omap mailing list.
(Please refer to http://markmail.org/thread/o643d7w224zo3i7n)
David Brownell said, if I've tested this:
Acked-by: David Brownell dbrown...@users.sourceforge.net
Of course, I've tested.
Regards,
Kyuwon
--
From: Kim Kyuwon q1@samsung.com
Subject: [PATCH] rtc: rtc-twl4030 don't mask alarm interrupts on suspend
This patch enables the alarm interrupt of TWL4030 RTC to wake up the
system from suspend. You can test this patch with following command.
# echo +10 /sys/class/rtc/rtc0/wakealarm; echo mem /sys/power/state;
Signed-off-by: Kim Kyuwon q1@samsung.com
---
drivers/rtc/rtc-twl4030.c |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/drivers/rtc/rtc-twl4030.c b/drivers/rtc/rtc-twl4030.c
index ad35f76..c185939 100644
--- a/drivers/rtc/rtc-twl4030.c
+++ b/drivers/rtc/rtc-twl4030.c
@@ -495,9 +495,7 @@ static int twl4030_rtc_suspend(struct platform_device
*pdev, pm_message_t state)
{
irqstat = rtc_irq_bits;
- /* REVISIT alarm may need to wake us from sleep */
- mask_rtc_irq_bit(BIT_RTC_INTERRUPTS_REG_IT_TIMER_M |
-BIT_RTC_INTERRUPTS_REG_IT_ALARM_M);
+ mask_rtc_irq_bit(BIT_RTC_INTERRUPTS_REG_IT_TIMER_M);
return 0;
}
--
1.5.2.5
--
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] Fix the size of twl4030 script
Hi All,
I sent this patch about 1 month ago.
Can anybody check I'm sending correct patch?
Thanks you!
Kyuwon.
2009/4/10 Kim Kyuwon chamm...@gmail.com:
The array size of wrst_seq is ARRAY_SIZE(wrst_seq)
Signed-off-by: Kim Kyuwon q1@samsung.com
---
arch/arm/mach-omap2/board-3430sdp.c |2 +-
arch/arm/mach-omap2/board-ldp.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index 03acac7..38550e2 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -473,7 +473,7 @@ static struct twl4030_ins wrst_seq[] __initdata = {
};
static struct twl4030_script wrst_script __initdata = {
.script = wrst_seq,
- .size = ARRAY_SIZE(wakeup_seq),
+ .size = ARRAY_SIZE(wrst_seq),
.flags = TRITON_WRST_SCRIPT,
};
diff --git a/arch/arm/mach-omap2/board-ldp.c b/arch/arm/mach-omap2/board-ldp.c
index 804fd8e..da814d7 100644
--- a/arch/arm/mach-omap2/board-ldp.c
+++ b/arch/arm/mach-omap2/board-ldp.c
@@ -450,7 +450,7 @@ static struct twl4030_ins wrst_seq[] __initdata = {
static struct twl4030_script wrst_script __initdata = {
.script = wrst_seq,
- .size = ARRAY_SIZE(wakeup_seq),
+ .size = ARRAY_SIZE(wrst_seq),
.flags = TRITON_WRST_SCRIPT,
};
--
1.5.2.5
--
Kyuwon (규원)
--
Kyuwon
--
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] PM: suspend_device_irqs(): don't disable wakeup IRQs
2009/5/7 Arve Hjønnevåg a...@android.com: 2009/5/6 Kim Kyuwon chamm...@gmail.com: 2009/5/7 Arve Hjønnevåg a...@android.com: On Wed, May 6, 2009 at 5:16 PM, Kevin Hilman khil...@deeprootsystems.com wrote: Rafael J. Wysocki r...@sisk.pl writes: On Wednesday 06 May 2009, Kevin Hilman wrote: Kevin Hilman khil...@deeprootsystems.com writes: There is at least one problem with that which is why Kyuwon Kim added the -disable hook to OMAP's irq_chip. The problem is with drivers that call disable_irq() in their suspend hook, usually done to prevent the device from waking the system since on OMAP, any IRQ can be configured to wake the system. This does not sound correct. disable_irq_wake should be used for this. A driver may need to mask its interrupt before suspending but this should not also disable it as a wakeup source. I wish I could use disable_irq_wake(), but it doesn't work in OMAP. This does not sound like a hardware problem. We may need advices of TI engineers. However, as far as I know, It is impossible to disable 'interrupt wake-up' with interrupt enabled. Because an interrupt itself generate a system wake-up event in OMAP3430 (Hardware level). -- Kyuwon -- Arve Hjønnevåg -- 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
OMAP3: PM: Add the wakeup source driver, v4
Sometimes, it is necessary to find out what does wake up my board from
suspend?. Notifying wake-up source feature may be used to blame unexpected
wake-up events which increase power consumption. And user mode applications can
act smartly according to the wake-up event from Suspend-to-RAM state to
minimize power consumption. Note that this driver can't inform wake-up events
from idle state. This driver uses sysfs interface to give information to user
mode applications like:
cat /sys/power/omap_resume_irq
cat /sys/power/omap_resume_event
This driver also provides the I/O pad wake-up source configuration. Specific
GPIO settings in the board file are:
/* I/O pad wakeup source configuration */
static struct iopad_wake boardname_iopad_wake[] = {
{
.mux_index = AE7_34XX_GPIO24,
.alias = KEY_PWRON,
},
{
.mux_index = ETK_D9_GPIO23,
.alias = USB_DETECT,
},
};
static struct omap_wake_platform_data boardname_wake_data = {
.iopad_wakes= boardname_iopad_wake,
.iopad_wake_num = ARRAY_SIZE(boardname_iopad_wake),
};
static struct platform_device boardname_wakeup = {
.name = omap-wake,
.id = -1,
.dev= {
.platform_data = boardname_wake_data,
},
};
The patch adds Kconfig options OMAP34xx wakeup source support under System
type-TI OMAP implementations menu.
Signed-off-by: Kim Kyuwon q1@samsung.com
---
arch/arm/mach-omap2/Makefile |1 +
arch/arm/mach-omap2/irq.c | 21 ++-
arch/arm/mach-omap2/omapdev-common.h |3 +
arch/arm/mach-omap2/omapdev3xxx.h | 63 +
arch/arm/mach-omap2/pm34xx.c | 13 +
arch/arm/mach-omap2/prcm-common.h |4 +
arch/arm/mach-omap2/prm-regbits-34xx.h|5 +
arch/arm/mach-omap2/wake34xx.c| 409 +
arch/arm/plat-omap/Kconfig|9 +
arch/arm/plat-omap/include/mach/irqs.h|4 +
arch/arm/plat-omap/include/mach/mux.h |3 +
arch/arm/plat-omap/include/mach/omapdev.h |3 +
arch/arm/plat-omap/include/mach/wake.h| 52
arch/arm/plat-omap/mux.c | 25 ++-
14 files changed, 605 insertions(+), 10 deletions(-)
create mode 100644 arch/arm/mach-omap2/wake34xx.c
create mode 100644 arch/arm/plat-omap/include/mach/wake.h
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index c58bab4..cfc5a13 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -25,6 +25,7 @@ obj-$(CONFIG_ARCH_OMAP2) += pm24xx.o
obj-$(CONFIG_ARCH_OMAP24XX)+= sleep24xx.o
obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o cpuidle34xx.o
obj-$(CONFIG_PM_DEBUG) += pm-debug.o
+obj-$(CONFIG_OMAP3_WAKE) += wake34xx.o
endif
# SmartReflex driver
diff --git a/arch/arm/mach-omap2/irq.c b/arch/arm/mach-omap2/irq.c
index 700fc3d..18ac725 100644
--- a/arch/arm/mach-omap2/irq.c
+++ b/arch/arm/mach-omap2/irq.c
@@ -33,9 +33,6 @@
#define INTC_MIR_SET0 0x008c
#define INTC_PENDING_IRQ0 0x0098
-/* Number of IRQ state bits in each MIR register */
-#define IRQ_BITS_PER_REG 32
-
/*
* OMAP2 has a number of different interrupt controllers, each interrupt
* controller is identified as its own bank. Register definitions are
@@ -193,6 +190,24 @@ int omap_irq_pending(void)
return 0;
}
+void omap_get_pending_irqs(u32 *pending_irqs, unsigned len)
+{
+ int i, j = 0;
+
+ for (i = 0; i ARRAY_SIZE(irq_banks); i++) {
+ struct omap_irq_bank *bank = irq_banks + i;
+ int irq;
+
+ for (irq = 0; irq bank-nr_irqs j len;
+ irq += IRQ_BITS_PER_REG) {
+ int offset = irq (~(IRQ_BITS_PER_REG - 1));
+
+ pending_irqs[j++] = intc_bank_read_reg(bank,
+ (INTC_PENDING_IRQ0 + offset));
+ }
+ }
+}
+
void __init omap_init_irq(void)
{
unsigned long nr_of_irqs = 0;
diff --git a/arch/arm/mach-omap2/omapdev-common.h
b/arch/arm/mach-omap2/omapdev-common.h
index a2d4855..57b9b0b 100644
--- a/arch/arm/mach-omap2/omapdev-common.h
+++ b/arch/arm/mach-omap2/omapdev-common.h
@@ -228,10 +228,13 @@ static struct omapdev *omapdevs[] = {
hsmmc2_3xxx_omapdev,
mcspi3_3xxx_omapdev,
gptimer1_3xxx_omapdev,
+ gptimer12_3xxx_omapdev,
prm_3xxx_omapdev,
cm_3xxx_omapdev,
omap_32ksynct_3xxx_omapdev,
gpio1_3xxx_omapdev,
+ io_3xxx_omapdev,
+ io_chain_3xxx_omapdev,
wdtimer2_3xxx_omapdev,
wdtimer1_3xxx_omapdev,
rng_3xxx_omapdev,
diff --git a/arch/arm/mach-omap2/omapdev3xxx.h
b/arch/arm/mach-omap2
Re: [PATCH] OMAP3: PM: Add the wakeup source driver, v3
On Thu, Apr 30, 2009 at 11:21 PM, Kevin Hilman khil...@deeprootsystems.com wrote: Also, I still think the WKST register reading should be done in the PRCM interrupt handler. In your previous attempt, you were seeing a bunch of non-device wakeup related interrupts. Can you try again with the attached patch (thanks to Paul Walmseley) which should help us debug why you were seeing spurious PRCM interrupts. First of all, sorry for giving you the wrong information in the previous mail. I found that we actually have configured GPTIMER12 as the system timer. And I tried with the attached patch, but I can't see any debug message. However even now, PRCM interrupt handler is invoked quite often due to the system timer. That's what I assumed was happening. As far as I know, after Peter's [OMAP3: PM: CPUidle: Add new lower-latency C1 state] patch is applied, the system is in 'wfi' state in every idle state. So whenever the system timer wake up the system from idle, I think PRCM interrupt occurs. Do you think still the WKST register should be read in the PRCM interrupt handler? ;) Yes. The WKST registers are already being read in the handler so they can be properly cleared. All you are adding is the saving of them. In addition, you should not enter idle between the time the system wakes from resume and your resume handler runs so you should be able to get the correct WKST values. OK, Your idea is more reasonable. I modified as you said. thanks. Also, I know we discussed this before, but I think the GPIO wakeup source stuff really belongs in a separate patch, and if you think it is still useful, and cannot be done by just enabling a GPIO IRQ from the board file, I suggest you propose a patch to the generic GPIO layer to add this interface. OK, I will remove this GPIO wakeup feature. But I want to know more detailed information about wakeup event . So, instead of using the GPIO wakeup, I'm planning using WAKEUPEVENT bit in CONTROL_PADCONF_x registers. That sounds OK. The current mux layer is lacking any knowledge of the wake bits in the PADCONF regs, so I'd be interested in any ideas you have of adding that support. I added my ideas about CONTROL_PADCONF_x into the new version of wake source driver. I will send it soon. Please review this new version again and feel free to give your opinion. Regards, Kyuwon (규원) -- 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] OMAP3: PM: Add the wakeup source driver, v3
Hi Kevin, Thank you for showing steady interest in this driver. On Tue, Apr 21, 2009 at 9:15 AM, Kevin Hilman khil...@deeprootsystems.com wrote: Hi Kyuwon, While I still like the concept of this driver, I'm still not quite happy about how it is implemented for various reasons. Most of which have to do with the fact that this driver does many things that really should be the job of other layers. In particular, the list of omap3_wake_events is a bit troubling. It really should be handled by the omapdev layer. You'll see that you are duplicating the data that is handled there. Rather, we should just extend the omapdev data to handle the wakeup events for that device. If you allow me to insert a new field whose name is mask in the omapdev struct, I think I can extend the omapdev to handle the wakeup events. Also, I still think the WKST register reading should be done in the PRCM interrupt handler. In your previous attempt, you were seeing a bunch of non-device wakeup related interrupts. Can you try again with the attached patch (thanks to Paul Walmseley) which should help us debug why you were seeing spurious PRCM interrupts. First of all, sorry for giving you the wrong information in the previous mail. I found that we actually have configured GPTIMER12 as the system timer. And I tried with the attached patch, but I can't see any debug message. However even now, PRCM interrupt handler is invoked quite often due to the system timer. As far as I know, after Peter's [OMAP3: PM: CPUidle: Add new lower-latency C1 state] patch is applied, the system is in 'wfi' state in every idle state. So whenever the system timer wake up the system from idle, I think PRCM interrupt occurs. Do you think still the WKST register should be read in the PRCM interrupt handler? ;) Also, I know we discussed this before, but I think the GPIO wakeup source stuff really belongs in a separate patch, and if you think it is still useful, and cannot be done by just enabling a GPIO IRQ from the board file, I suggest you propose a patch to the generic GPIO layer to add this interface. OK, I will remove this GPIO wakeup feature. But I want to know more detailed information about wakeup event . So, instead of using the GPIO wakeup, I'm planning using WAKEUPEVENT bit in CONTROL_PADCONF_x registers. diff --git a/arch/arm/mach-omap2/prcm-common.h b/arch/arm/mach-omap2/prcm-common.h index cb1ae84..1f340aa 100644 --- a/arch/arm/mach-omap2/prcm-common.h +++ b/arch/arm/mach-omap2/prcm-common.h @@ -273,6 +273,10 @@ #define OMAP3430_ST_D2D_SHIFT3 #define OMAP3430_ST_D2D_MASK (1 3) +/* PM_WKST3_CORE, CM_IDLEST3_CORE shared bits */ +#define OMAP3430_ST_USBTLL_SHIFT 2 +#define OMAP3430_ST_USBTLL_MASK (1 2) + /* CM_FCLKEN_WKUP, CM_ICLKEN_WKUP, PM_WKEN_WKUP shared bits */ #define OMAP3430_EN_GPIO1(1 3) #define OMAP3430_EN_GPIO1_SHIFT 3 diff --git a/arch/arm/mach-omap2/prm-regbits-34xx.h b/arch/arm/mach-omap2/prm-regbits-34xx.h index 06fee29..f0a6395 100644 --- a/arch/arm/mach-omap2/prm-regbits-34xx.h +++ b/arch/arm/mach-omap2/prm-regbits-34xx.h @@ -332,6 +332,8 @@ /* PM_IVA2GRPSEL1_CORE specific bits */ /* PM_WKST1_CORE specific bits */ +#define OMAP3430_ST_MMC3_SHIFT 30 +#define OMAP3430_ST_MMC3_MASK(1 30) /* PM_PWSTCTRL_CORE specific bits */ #define OMAP3430_MEM2ONSTATE_SHIFT 18 @@ -432,6 +434,9 @@ /* PM_PREPWSTST_PER specific bits */ +/* PM_WKST_USBHOST specific bits */ +#define OMAP3430_ST_USBHOST (1 0) + /* RM_RSTST_EMU specific bits */ All these new bit defines should all be 3430ES2_*. OK, I will fix it. Thanks Regards, Kyuwon -- 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
Question about OABI_COMPAT feature in do_signal() function
Hello Russell, It's an honor to mail you. I'm writing this mail to ask you about the OABI_COMPAT feature in do_signal() function. After freezing and thawing user processes for Suspend-To-Ram, I found that some user processes(e.g. daemon processes) make prefetch abort continuously. And finally, I found that the following code in do_signal() was the root cause: /* arch/arm/kernel/signal.c: near 677 line */ put_user(regs-ARM_pc, usp[0]); /* swi __NR_restart_syscall */ put_user(0xef00 | swival, usp[1]); /* ldr pc, [sp], #12 */ put_user(0xe49df00c, usp[2]); It seems that this code makes processes execute in stack area to re-enter kernel area. However, when PC is in stack area, I saw that it *continuously* make data abort exception. (Process stack area is in general non executable area) I'm using OMAP3430 board whose core is Cotex-A8 and with enabling both CONFIG_AEABI and CONFIG_OABI_COMPAT. Can I ask your comments or idea about this problem? Regards, Kyuwon (규원) -- 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
PM: 4 Problems in OMAP3430 DVFS (SmartReflex, Cpufreq)
Hi Kevin, Rajendra, and other OMAP experts, Lately I'm digging up OMAP3430-DVFS and I found 4 problems on top of PM branch. 1. Setting CPUFreq Governor to 'ondemand' turns off display system. I think the following codes in set_opp() of rescource34xx.c makes this problem. /* * For VDD1 OPP3 and above, make sure the interconnect * is at 100Mhz or above. * throughput in KiB/s for 100 Mhz = 100 * 1000 * 4. */ if (target_level = 3) resource_request(vdd2_opp, vdd2_dev, 40); else resource_release(vdd2_opp, vdd2_dev); I'm not sure this is the root cause. However, if I remove the above sentences, display system doesn't turn off. 2. [Trivial] Setting CPUFreq Governor to 'ondemand' makes warning message as below. SR1: VDD autocomp is not active SR2: VDD autocomp is not active These warning messages are removed, if I set sr_vdd1_autocomp and sr_vdd2_autocomp to 1. However, is these warning messages really needed? 3. OP(Operating Point) transition time is set to 10seconds in cpu-omap.c as follows: /* FIXME: what's the actual transition time? */ policy-cpuinfo.transition_latency = 10 * 1000 * 1000; The default sampling rate of CPUFreq is set to transition_latency, so it becomes 10 seconds! It's really too long for DVFS. I measured transition latency by myself using oscilloscope and it's about 150 ~ 200m seconds. I think TI engineers may know more accurate figure. I wish we could update transition latency as soon as possible. 4. Current PM code didn't enable the maximum clock (i.e. CPU: 600Mhz) according to the comment as below: /* Avoid registering the 120% Overdrive with CPUFreq */ prcm = mpu_opps + MAX_VDD1_OPP - 1; But in some cases, we should use 600Mhz for multimedia application. And, even thought we enable the maximum clock, CPU frequency seldom goes into maximum clock. I think we don't have to avoid registering the max OPP. In OMAP PM, there are a lot of part that only experts in TI or people with experience can handle. So I'm afraid to send new patch or fix previous PM codes. I hope we can discuss above issues a lot! Thank you. Kyuwon (규원) -- 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] OMAP3: PM: Add the wakeup source driver, v3
Hi Kevin,
Have you had chance to review this new version of wakeup driver? :)
Regards,
Kyuwon
On Fri, Apr 3, 2009 at 7:43 PM, Kim Kyuwon chamm...@gmail.com wrote:
Sometimes, it is necessary to find out what does wake up my board
from suspend?. Notifying wake-up source feature may be used to blame
unexpected wake-up events which increase power consumption. And user
mode applications can act smartly according to the wake-up event from
Suspend-to-RAM state to minimize power consumption. Note that this
driver can't inform wake-up events from idle state. This driver uses
sysfs interface to give information to user mode applications like:
cat /sys/power/omap_resume_irq
cat /sys/power/omap_resume_event
This driver also privides the unified GPIO wake-up source
configuration. specific GPIO settings in the board files are:
/* Wakeup source configuration */
static struct gpio_wake boardname_gpio_wake[] = {
{ 23, IRQF_TRIGGER_RISING,BT_WAKEUP,1},
{ 24, IRQF_TRIGGER_RISING,USB_DETECT, 1},
};
static struct omap_wake_platform_data boardname_wake_data = {
.gpio_wakes = boardname_gpio_wake,
.gpio_wake_num = ARRAY_SIZE(boardname_gpio_wake),
};
static struct platform_device boardname_wakeup = {
.name = omap-wake,
.id = -1,
.dev= {
.platform_data = boardname_wake_data,
},
};
The patch adds Kconfig options OMAP34xx wakeup source support under
System type-TI OMAP implementations menu.
Signed-off-by: Kim Kyuwon q1@samsung.com
---
arch/arm/mach-omap2/Makefile |1 +
arch/arm/mach-omap2/irq.c | 21 +-
arch/arm/mach-omap2/prcm-common.h |4 +
arch/arm/mach-omap2/prm-regbits-34xx.h |5 +
arch/arm/mach-omap2/wake34xx.c | 681
arch/arm/plat-omap/Kconfig |9 +
arch/arm/plat-omap/include/mach/irqs.h |4 +
arch/arm/plat-omap/include/mach/wake.h | 30 ++
8 files changed, 752 insertions(+), 3 deletions(-)
create mode 100644 arch/arm/mach-omap2/wake34xx.c
create mode 100644 arch/arm/plat-omap/include/mach/wake.h
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index e693efd..4d7dbca 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -25,6 +25,7 @@ obj-$(CONFIG_ARCH_OMAP2) += pm24xx.o
obj-$(CONFIG_ARCH_OMAP24XX)+= sleep24xx.o
obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o cpuidle34xx.o
obj-$(CONFIG_PM_DEBUG) += pm-debug.o
+obj-$(CONFIG_OMAP_WAKE)+= wake34xx.o
endif
# SmartReflex driver
diff --git a/arch/arm/mach-omap2/irq.c b/arch/arm/mach-omap2/irq.c
index 700fc3d..18ac725 100644
--- a/arch/arm/mach-omap2/irq.c
+++ b/arch/arm/mach-omap2/irq.c
@@ -33,9 +33,6 @@
#define INTC_MIR_SET0 0x008c
#define INTC_PENDING_IRQ0 0x0098
-/* Number of IRQ state bits in each MIR register */
-#define IRQ_BITS_PER_REG 32
-
/*
* OMAP2 has a number of different interrupt controllers, each interrupt
* controller is identified as its own bank. Register definitions are
@@ -193,6 +190,24 @@ int omap_irq_pending(void)
return 0;
}
+void omap_get_pending_irqs(u32 *pending_irqs, unsigned len)
+{
+ int i, j = 0;
+
+ for (i = 0; i ARRAY_SIZE(irq_banks); i++) {
+ struct omap_irq_bank *bank = irq_banks + i;
+ int irq;
+
+ for (irq = 0; irq bank-nr_irqs j len;
+ irq += IRQ_BITS_PER_REG) {
+ int offset = irq (~(IRQ_BITS_PER_REG - 1));
+
+ pending_irqs[j++] = intc_bank_read_reg(bank,
+ (INTC_PENDING_IRQ0 + offset));
+ }
+ }
+}
+
void __init omap_init_irq(void)
{
unsigned long nr_of_irqs = 0;
diff --git a/arch/arm/mach-omap2/prcm-common.h
b/arch/arm/mach-omap2/prcm-common.h
index cb1ae84..1f340aa 100644
--- a/arch/arm/mach-omap2/prcm-common.h
+++ b/arch/arm/mach-omap2/prcm-common.h
@@ -273,6 +273,10 @@
#define OMAP3430_ST_D2D_SHIFT 3
#define OMAP3430_ST_D2D_MASK (1 3)
+/* PM_WKST3_CORE, CM_IDLEST3_CORE shared bits */
+#define OMAP3430_ST_USBTLL_SHIFT 2
+#define OMAP3430_ST_USBTLL_MASK(1 2)
+
/* CM_FCLKEN_WKUP, CM_ICLKEN_WKUP, PM_WKEN_WKUP shared bits */
#define OMAP3430_EN_GPIO1 (1 3)
#define OMAP3430_EN_GPIO1_SHIFT3
diff --git a/arch/arm/mach-omap2/prm-regbits-34xx.h
b/arch/arm/mach-omap2/prm-regbits-34xx.h
index 06fee29..f0a6395 100644
--- a/arch/arm/mach-omap2/prm-regbits-34xx.h
+++ b/arch/arm/mach-omap2/prm-regbits-34xx.h
Re: [PATCH] OMAP3: PM: Add the wakeup source driver, v2
On Sun, Apr 5, 2009 at 5:22 AM, Paul Walmsley p...@pwsan.com wrote: On Sat, 4 Apr 2009, Kim Kyuwon wrote: No, I haven't configured GPTIMER12. And actually OMAP3430_ST_GPT12_MASK bit is reserved on OMAP3430 ES.1. This is another problem that I have to fix. Please see the OMAP34xx Multimedia High Security (HS) Device Silicon Revision 3.0 Security Addendum (SWPU119B) Table 3-244. Thanks again, Paul! Now I understand. - Paul Sincerely, Kyuwon -- 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] OMAP3: PM: Add the wakeup source driver, v2
*/
+ if (pm_wkst-core1) {
+ omap_wake_detect_core1(pm_wkst-core1, buf);
+ omap_wake_strncat(wake_event, buf, event_size - 1);
+ }
+ if (pm_wkst-core3) {
+ omap_wake_detect_core3(pm_wkst-core3, buf);
+ omap_wake_strncat(wake_event, buf, event_size - 1);
+ }
+
+ /* USBHOST */
+ if ((omap_rev() OMAP3430_REV_ES1_0) (pm_wkst-usbhost)) {
+ omap_wake_detect_usbhost(pm_wkst-usbhost, buf);
+ omap_wake_strncat(wake_event, buf, event_size - 1);
+ }
Here is where you would just walk the array of WKST/domain tuples.
OK.
snip
+
+static irqreturn_t omap_wake_detect_gpio(int irq, void *dev_id)
+{
+ omap_wake_strncat(wakeup_gpio, dev_id, sizeof(wakeup_gpio) - 1);
+
+ return IRQ_HANDLED;
+}
Again this is not a detect. How about omap_wake_gpio_interrupt()
OK. I used omap_wake_gpio_interrupt()
snip
+ sizeof(wakeup_irq), sizeof(wakeup_event));
+ printk(KERN_INFO OMAP resume IRQ: %s\n, wakeup_irq);
+ printk(KERN_INFO OMAP resume event: %s\n, wakeup_event);
pr_info(...)
OK. Thanks.
+config OMAP_WAKE
+ tristate OMAP34xx wakeup source support
+ depends on ARCH_OMAP34XX PM
+ default n
+ help
+ Select this option if you want to know what kind of wake-up event
+ wakes up your board from the low power mode. And this option
+ provides the unified GPIO wake-up source configuration.
+
Update this as well to say that it only affects wakeup from suspend.
OK. Thanks
snip
diff --git a/arch/arm/plat-omap/include/mach/pm.h
b/arch/arm/plat-omap/include/mach/pm.h
index 9df0175..b10f5b0 100644
--- a/arch/arm/plat-omap/include/mach/pm.h
+++ b/arch/arm/plat-omap/include/mach/pm.h
@@ -175,6 +175,16 @@ extern void omap_serial_wake_trigger(int enable);
#define omap_serial_wake_trigger(x) {}
#endif /* CONFIG_OMAP_SERIAL_WAKE */
+struct pm_wakeup_status {
+ u32 wkup;
+ u32 core1;
+ u32 core3;
+ u32 per;
+ u32 usbhost;
+};
+
+extern void omap3_get_wakeup_status(struct pm_wakeup_status **pm_wkst);
+
This should probably just go in wake34xx.h since this is all very
OMAP3 specific. pm.h is for OMAP1/2/3 common code.
Yes, I moved it to wake34xx.c
#define ARM_SAVE(x) arm_sleep_save[ARM_SLEEP_SAVE_##x] = omap_readl(x)
#define ARM_RESTORE(x) omap_writel((arm_sleep_save[ARM_SLEEP_SAVE_##x]),
(x))
#define ARM_SHOW(x) arm_sleep_save[ARM_SLEEP_SAVE_##x]
diff --git a/arch/arm/plat-omap/include/mach/wake.h
b/arch/arm/plat-omap/include/mach/wake.h
new file mode 100644
index 000..7da8ec8
--- /dev/null
+++ b/arch/arm/plat-omap/include/mach/wake.h
@@ -0,0 +1,30 @@
+/*
+ * wake.h
+ *
+ * Copyright (c) 2009 Samsung Eletronics
+ *
+ * Author: Kim Kyuwon q1@samsung.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.
+ *
+ */
+
+#ifndef _WAKE_H_
+#define _WAKE_H_
+
+struct gpio_wake {
+ unsigned intgpio;
+ unsigned long irqflag;
+ const char *name;
+ int request;
+};
+
+struct omap_wake_platform_data{
+ struct gpio_wake*gpio_wakes;
+ int gpio_wake_num;
+};
+
+#endif /* _WAKE_H_ */
+
Do you need this common wake.h here? Again, this dir is for common
code accoss OMAP1/2/3 and this code is pretty OMAP3 specific.
Yes, I think I want to locate 'wake.h' here, so that board files can
include 'wake.h'
(I'm considering extending this driver to take charge of the board
specific wake-up policy.)
But If you know the better location, please let me know.
Kevin
--
Kyuwon
--
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] OMAP3: PM: Add the wakeup source driver, v2
Hi Kevin,
Thanks for your prompt answer.
On Sat, Apr 4, 2009 at 1:12 AM, Kevin Hilman
khil...@deeprootsystems.com wrote:
Kim Kyuwon chamm...@gmail.com writes:
+
+void omap3_get_wakeup_status(struct pm_wakeup_status **pm_wkst)
+{
+ *pm_wkst = omap3_pm_wkst;
+}
+
Can you rename this to omap3_get_last_wake_state()
Actually, I removed this function and I didn't get the WKST registers
from the last PRCM interrupt in the new patch. Sorry that I don't
address your suggestion. But I found that the PRCM interrupt is being
generated in normal state on the latest PM branch and, from OMAP34XX
TRM (4.9 PRCM Interrupts), PRCM Interrupts can be generated in many
cases in addition to wake-up from suspend. So if my wakeup code gets
the WSKT values from PRCM interrupt, I think it could show the wrong
information.
What type of wrong information do you think you would get?
On our custom OMAP3430 ES3.1 board on which the latest PM branch
kernel is running, the PRCM interrupt is being generated about every
0.5 sec.(not exact) and 'OMAP3430_ST_GPT12_MASK' is set in the
PM_WKST_WKUP register.
FYI: When I wrongly configured the d2d_mstdby and d2d_swakeup pads,
PRCM interrupts was also generated (Refer to
http://markmail.org/thread/juardvjdvsrrqwuj)
After looking again, you are probably querying the WKST registers
too late. This version was not querying until someone dumped
the sysfs regs. In that case, some other idle event could have
changed the WKST regs.
What you should do is query the WKST regs in your early_resume hook
(the same place you query the pending IRQs.) This way you know
exactly when the WKST regs are taken.
However, my 'early_resume' hook is invoked before generating any
interrupt including PRCM interrupts, because IRQs are disabled by
arch_suspend_disablel_irqs() in that context.
But if I query the WKST regs in the 'resume' hook, I think another
PRCM interrupts can be generated.
Kevin
Best regards,
--
Kyuwon
--
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] OMAP3: PM: Add the wakeup source driver, v2
On Sat, Apr 4, 2009 at 9:20 AM, Kevin Hilman
khil...@deeprootsystems.com wrote:
Kim Kyuwon chamm...@gmail.com writes:
Hi Kevin,
Thanks for your prompt answer.
On Sat, Apr 4, 2009 at 1:12 AM, Kevin Hilman
khil...@deeprootsystems.com wrote:
Kim Kyuwon chamm...@gmail.com writes:
+
+void omap3_get_wakeup_status(struct pm_wakeup_status **pm_wkst)
+{
+ *pm_wkst = omap3_pm_wkst;
+}
+
Can you rename this to omap3_get_last_wake_state()
Actually, I removed this function and I didn't get the WKST registers
from the last PRCM interrupt in the new patch. Sorry that I don't
address your suggestion. But I found that the PRCM interrupt is being
generated in normal state on the latest PM branch and, from OMAP34XX
TRM (4.9 PRCM Interrupts), PRCM Interrupts can be generated in many
cases in addition to wake-up from suspend. So if my wakeup code gets
the WSKT values from PRCM interrupt, I think it could show the wrong
information.
What type of wrong information do you think you would get?
On our custom OMAP3430 ES3.1 board on which the latest PM branch
kernel is running, the PRCM interrupt is being generated about every
0.5 sec.(not exact) and 'OMAP3430_ST_GPT12_MASK' is set in the
PM_WKST_WKUP register.
Hmm, have you configured GPTIMER12 as the system timer?
No, I haven't configured GPTIMER12. And actually
OMAP3430_ST_GPT12_MASK bit is reserved on OMAP3430 ES.1.
This is another problem that I have to fix.
FYI: When I wrongly configured the d2d_mstdby and d2d_swakeup pads,
PRCM interrupts was also generated (Refer to
http://markmail.org/thread/juardvjdvsrrqwuj)
After looking again, you are probably querying the WKST registers
too late. This version was not querying until someone dumped
the sysfs regs. In that case, some other idle event could have
changed the WKST regs.
What you should do is query the WKST regs in your early_resume hook
(the same place you query the pending IRQs.) This way you know
exactly when the WKST regs are taken.
However, my 'early_resume' hook is invoked before generating any
interrupt including PRCM interrupts, because IRQs are disabled by
arch_suspend_disablel_irqs() in that context.
Ah, yes. You're right.
But if I query the WKST regs in the 'resume' hook, I think another
PRCM interrupts can be generated.
OK, I haven't yet looked closely at your latest version, but reading
the regs directly in the early_resume hook looks OK.
Thanks!
Kevin
--
Kyuwon
--
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] OMAP3 clock: Access only available clock bits
Hi Paul, On Sat, Mar 21, 2009 at 6:48 AM, Paul Walmsley p...@pwsan.com wrote: Hello Kyuwon, On Fri, 20 Mar 2009, Kim Kyuwon wrote: I found a problem on PM Branch with OMAP3430 ES3.1 Board when enabling OMAP_RESET_CLOCKS feature. In clk_disable_unsed() function, as soon as sad2d_ick is disabled, prcm interrupt is generated and its handler can't exit loop at next statement! while (prm_read_mod_reg(OCP_MOD, OMAP2_PRM_IRQSTATUS_MPU_OFFSET)); We encountered a similar problem a few months ago. The problem is probably the pad mux settings on the d2d_mstdby and d2d_swakeup pads. These are usually configured by the bootloader. My recollection is that they should be pulled up, but I don't recall for sure. Yes, we should have a patch in the PM branch to at least detect whether these pads are configured incorrectly... Thank you for letting me know the better solution. I confirmed that this problem can be fixed by configuring the d2d_mstdby and d2d_swakeup pads. (As you said, swakeup - pulled down mstdby - pulled up.) I also found that sad2d_ick is available only OMAP3430 ES1. I fixed this problem with below patch. Thanks for your patch, but, sad2d_ick is indeed present on ES2+. TI removed the documenation from the main TRM and moved it to the OMAP34xx Stacked Mode Addendum (SWCU048). Ill-advised, in my opinion! I have only the OMAP34xx ES3.0 Stacked Mode Addendum and I can see EN_SAD2D is available in this document. ES3.1 is maybe same. I think this patch is not needed anymore. Thank you so much for your help! Regards, Kyuwon -- 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: two fixes on PM branch
Hi! I'm sending two very small patches for PM branch arch/arm/mach-omap2/cpuidle34xx.c |2 -- arch/arm/mach-omap2/pm.c |1 + arch/arm/mach-omap2/pm34xx.c |5 ++--- arch/arm/mach-omap2/resource34xx.c |1 + 4 files changed, 4 insertions(+), 5 deletions(-) Regards, Kim Kyuwon -- 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: Fix compile error with 'CONFIG_OMAP_PM_SRF=y'
This patch fixes below compile error. The header file 'mach/omap34xx.h' declared all needed symbols. CC arch/arm/mach-omap2/pm.o CC arch/arm/mach-omap2/resource34xx.o arch/arm/mach-omap2/resource34xx.c: In function 'resource_access_opp_lock': arch/arm/mach-omap2/resource34xx.c:174: error: 'VDD1_OPP' undeclared (first use in this function) arch/arm/mach-omap2/resource34xx.c:177: error: 'VDD2_OPP' undeclared (first use in this function) arch/arm/mach-omap2/resource34xx.c:209: error: 'MAX_VDD1_OPP' undeclared (first use in this function) snip make[1]: *** [arch/arm/mach-omap2/resource34xx.o] Error 1 arch/arm/mach-omap2/pm.c: In function 'vdd_opp_show': arch/arm/mach-omap2/pm.c:140: error: 'VDD1_OPP' undeclared (first use in this function) arch/arm/mach-omap2/pm.c:140: error: (Each undeclared identifier is reported only once snip make[1]: *** [arch/arm/mach-omap2/pm.o] Error 1 Signed-off-by: Kim Kyuwon q1@samsung.com --- arch/arm/mach-omap2/pm.c |1 + arch/arm/mach-omap2/resource34xx.c |1 + 2 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c index e64a80e..c0f1ae8 100644 --- a/arch/arm/mach-omap2/pm.c +++ b/arch/arm/mach-omap2/pm.c @@ -34,6 +34,7 @@ #include mach/powerdomain.h #include mach/omapdev.h #include mach/resource.h +#include mach/omap34xx.h #include prm-regbits-34xx.h #include pm.h diff --git a/arch/arm/mach-omap2/resource34xx.c b/arch/arm/mach-omap2/resource34xx.c index 2328323..4db9289 100644 --- a/arch/arm/mach-omap2/resource34xx.c +++ b/arch/arm/mach-omap2/resource34xx.c @@ -20,6 +20,7 @@ #include linux/cpufreq.h #include mach/powerdomain.h #include mach/clockdomain.h +#include mach/omap34xx.h #include smartreflex.h #include resource34xx.h #include pm.h -- 1.5.2.5 -- Kim Kyuwon -- 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] OMAP3 clock: Access only available clock bits
Hi All,
I found a problem on PM Branch with OMAP3430 ES3.1 Board when enabling
OMAP_RESET_CLOCKS feature.
In clk_disable_unsed() function, as soon as sad2d_ick is disabled,
prcm interrupt is generated and its handler can't exit loop at next
statement!
while (prm_read_mod_reg(OCP_MOD, OMAP2_PRM_IRQSTATUS_MPU_OFFSET));
I also found that sad2d_ick is available only OMAP3430 ES1. I fixed
this problem with below patch.
Your better solutions or comments appreciated.
Sincerely,
Kyuwon
--
This patch prevents setting or clearing reserved bits of 'Clock Enable
Register', in the clk_disable_unused() function. Especially, this
patch prevents using the sad2d_ick which doesn't exist in OMAP3430
ES2+.
Signed-off-by: Kim Kyuwon q1@samsung.com
---
arch/arm/mach-omap2/clock34xx.h |2 +-
arch/arm/plat-omap/clock.c | 10 ++
2 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/clock34xx.h b/arch/arm/mach-omap2/clock34xx.h
index e0dd7f3..039f7dd 100644
--- a/arch/arm/mach-omap2/clock34xx.h
+++ b/arch/arm/mach-omap2/clock34xx.h
@@ -1279,7 +1279,7 @@ static struct clk sad2d_ick = {
.prcm_mod = CORE_MOD,
.enable_reg = CM_ICLKEN1,
.enable_bit = OMAP3430_EN_SAD2D_SHIFT,
- .flags = CLOCK_IN_OMAP343X,
+ .flags = CLOCK_IN_OMAP3430ES1,
.clkdm = { .name = d2d_clkdm },
.recalc = followparent_recalc,
};
diff --git a/arch/arm/plat-omap/clock.c b/arch/arm/plat-omap/clock.c
index 2eed047..b16c6c3 100644
--- a/arch/arm/plat-omap/clock.c
+++ b/arch/arm/plat-omap/clock.c
@@ -775,6 +775,16 @@ static int __init clk_disable_unused(void)
if (cpu_class_is_omap1() ck-enable_reg == 0)
continue;
+ if (cpu_is_omap34xx()) {
+ if ((omap_rev() == OMAP3430_REV_ES1_0)
+ (ck-flags CLOCK_IN_OMAP3430ES2))
+ continue;
+
+ /* In this case, board Rev. is greater then ES1 */
+ if (ck-flags CLOCK_IN_OMAP3430ES1)
+ continue;
+ }
+
spin_lock_irqsave(clockfw_lock, flags);
if (arch_clock-clk_disable_unused)
arch_clock-clk_disable_unused(ck);
--
1.5.2.5
--
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/1] OMAP3: PM: Add the wakeup source driver
On Wed, Mar 18, 2009 at 6:47 AM, Kevin Hilman
khil...@deeprootsystems.com wrote:
Kim Kyuwon chamm...@gmail.com writes:
Sometimes, it is necessary to find out what does wake up my board?.
Notifying wake-up source feature may be used to blame unexpected
wake-up events which increase power consumption. And user mode
applications can act smartly according to the wake-up event to
minimize power consumption.
Hi Kim,
This is a very useful feature, and something that's is lacking in the
current PM code. Thank you so much for this contribution.
Hi Kevin,
Thank you very much for your encouragement, comments and suggestions.
I tried to follow most of your suggestions, but I can miss something.
Please check my new patch again.
My answers are below and I'll send the new patch right away.
Currently this driver only works for wakeups from suspend. I think
the description should be updated to specify that this only affects
wakeups from susupend, and not wakeups from idle.
OK, I fixed it.
Speaking of which, have you considered extending it to handle wakeups
from idle? Currently tools like powertop give a pretty good idea as
to why the system is coming out of idle, so this may not be necessary,
but was just wondering if you had considered it.
I designed this driver only for wakeups from suspend, but thanks for
letting me know that.
More comments and suggestions on general organization below.
This driver uses sysfs interface to give
information to user mode applications like:
cat /sys/power/wakeup_irq
cat /sys/power/wakeup_event
If only suspend/resume is being handled, maybe 'resume' is a better
name than 'wakeup'. These would be better named:
/sys/power/omap_resume_irq
/sys/power/omap_resume_event
OK, I changed those. But I wish not to replace 'wake' or 'wakeup'
strings with 'resume' in other symbols and filenames.
This driver also privides the unified GPIO wake-up source
configuration. specific GPIO settings in the board files are:
/* Wakeup source configuration */
static struct gpio_wake boardname_gpio_wake[] = {
{ 23, IRQF_TRIGGER_RISING | IRQF_SHARED, BT_WAKEUP,1},
{ 24, IRQF_TRIGGER_RISING | IRQF_SHARED, USB_DETECT, 1},
};
Based on the way this works, I think the board code should not
be requird to set IRQF_SHARED. I think this should be explicitly
ORed in in the wake_suspend hook which requests the IRQ since this will
not work correctly without using IRQF_SHARED.
Thanks, I fixed it.
static struct omap_wake_platform_data boardname_wake_data = {
.qpio_wakes = boardname_gpio_wake,
.gpio_wake_num = ARRAY_SIZE(boardname_gpio_wake),
};
I assume that 'qpio' is a typo and should be gpio?
Oops, thanks, I fixed it.
Also, I'm not sure I agree with adding a generic GPIO wakeup
interface. I believe this should be done by the driver using the GPIO
itself. However, I can see this being useful to test external
wakeup events when no driver is present.
I agree with you that it's better that each driver configure GPIO
wakeup. But, as you said, GPIO wakeup interface in this driver is
useful when the specific driver doesn't exist.
Somewhat different topic: All OMAP boards on which l-o tree kernel is
running have the same wake-up source setup as written in the
prcm_setup_regs() and omap3_pm_init(). But I think this wake-up policy
is a board specific feature, so I wish this driver can take charge of
board specific wake-up configurations in the future. [So... I think
GPIO wakeup interface would become a part of it :)]
static struct platform_device boardname_wakeup = {
.name = omap-wake,
.id = -1,
.dev= {
.platform_data = boardname_wake_data,
},
};
Signed-off-by: Kim Kyuwon q1@samsung.com
---
arch/arm/mach-omap2/Makefile |1 +
arch/arm/mach-omap2/irq.c | 41 +++
arch/arm/mach-omap2/prcm-common.h |4 +
arch/arm/mach-omap2/prm-regbits-34xx.h |6 +
arch/arm/mach-omap2/wake34xx.c | 470
arch/arm/plat-omap/Kconfig |9 +
arch/arm/plat-omap/include/mach/irqs.h |1 +
arch/arm/plat-omap/include/mach/wake.h | 29 ++
8 files changed, 561 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/wake34xx.c
create mode 100644 arch/arm/plat-omap/include/mach/wake.h
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index ba65cab..1ab87e7 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -25,6 +25,7 @@ obj-$(CONFIG_ARCH_OMAP2)+= pm24xx.o
obj-$(CONFIG_ARCH_OMAP24XX) += sleep24xx.o
obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o
obj-$(CONFIG_PM_DEBUG) += pm-debug.o
+obj-$(CONFIG_OMAP_WAKE) += wake34xx.o
endif
# SmartReflex driver
[PATCH] OMAP3: PM: Add the wakeup source driver, v2
Sometimes, it is necessary to find out what does wake up my board
from suspend?. Notifying wake-up source feature may be used to blame
unexpected wake-up events which increase power consumption. And user
mode applications can act smartly according to the wake-up event from
Suspend-to-RAM state to minimize power consumption. Note that this
driver can't inform wake-up events from idle state. This driver uses
sysfs interface to give information to user mode applications like:
cat /sys/power/omap_resume_irq
cat /sys/power/omap_resume_event
This driver also privides the unified GPIO wake-up source
configuration. specific GPIO settings in the board files are:
/* Wakeup source configuration */
static struct gpio_wake boardname_gpio_wake[] = {
{ 23, IRQF_TRIGGER_RISING,BT_WAKEUP,1},
{ 24, IRQF_TRIGGER_RISING,USB_DETECT, 1},
};
static struct omap_wake_platform_data boardname_wake_data = {
.gpio_wakes = boardname_gpio_wake,
.gpio_wake_num = ARRAY_SIZE(boardname_gpio_wake),
};
static struct platform_device boardname_wakeup = {
.name = omap-wake,
.id = -1,
.dev= {
.platform_data = boardname_wake_data,
},
};
The patch adds Kconfig options OMAP34xx wakeup source support under
System type-TI OMAP implementations menu.
Signed-off-by: Kim Kyuwon q1@samsung.com
---
arch/arm/mach-omap2/Makefile |1 +
arch/arm/mach-omap2/irq.c | 21 +-
arch/arm/mach-omap2/pm34xx.c | 12 +
arch/arm/mach-omap2/prcm-common.h |4 +
arch/arm/mach-omap2/prm-regbits-34xx.h |6 +
arch/arm/mach-omap2/wake34xx.c | 539
arch/arm/plat-omap/Kconfig |9 +
arch/arm/plat-omap/include/mach/irqs.h |4 +
arch/arm/plat-omap/include/mach/pm.h | 10 +
arch/arm/plat-omap/include/mach/wake.h | 30 ++
10 files changed, 633 insertions(+), 3 deletions(-)
create mode 100644 arch/arm/mach-omap2/wake34xx.c
create mode 100644 arch/arm/plat-omap/include/mach/wake.h
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 16c6fb8..29ad0f1 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -25,6 +25,7 @@ obj-$(CONFIG_ARCH_OMAP2) += pm24xx.o
obj-$(CONFIG_ARCH_OMAP24XX)+= sleep24xx.o
obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o cpuidle34xx.o
obj-$(CONFIG_PM_DEBUG) += pm-debug.o
+obj-$(CONFIG_OMAP_WAKE)+= wake34xx.o
endif
# SmartReflex driver
diff --git a/arch/arm/mach-omap2/irq.c b/arch/arm/mach-omap2/irq.c
index be4b596..6da285e 100644
--- a/arch/arm/mach-omap2/irq.c
+++ b/arch/arm/mach-omap2/irq.c
@@ -33,9 +33,6 @@
#define INTC_MIR_SET0 0x008c
#define INTC_PENDING_IRQ0 0x0098
-/* Number of IRQ state bits in each MIR register */
-#define IRQ_BITS_PER_REG 32
-
/*
* OMAP2 has a number of different interrupt controllers, each interrupt
* controller is identified as its own bank. Register definitions are
@@ -193,6 +190,24 @@ int omap_irq_pending(void)
return 0;
}
+void omap_get_pending_irqs(u32 *pending_irqs, unsigned len)
+{
+ int i, idx = 0;
+
+ for (i = 0; i ARRAY_SIZE(irq_banks); i++) {
+ struct omap_irq_bank *bank = irq_banks + i;
+ int irq;
+
+ for (irq = 0; irq bank-nr_irqs idx len;
+ irq += IRQ_BITS_PER_REG) {
+ int offset = irq (~(IRQ_BITS_PER_REG - 1));
+
+ pending_irqs[idx++] = intc_bank_read_reg(bank,
+ (INTC_PENDING_IRQ0 + offset));
+ }
+ }
+}
+
void __init omap_init_irq(void)
{
unsigned long nr_of_irqs = 0;
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 9102cee..2d17906 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -91,6 +91,13 @@ static struct prm_setup_times prm_setup = {
.voltsetup2 = 0xff,
};
+static struct pm_wakeup_status omap3_pm_wkst;
+
+void omap3_get_wakeup_status(struct pm_wakeup_status **pm_wkst)
+{
+ *pm_wkst = omap3_pm_wkst;
+}
+
static inline void omap3_per_save_context(void)
{
omap3_gpio_save_context();
@@ -174,6 +181,7 @@ static irqreturn_t prcm_interrupt_handler (int
irq, void *dev_id)
/* WKUP */
wkst = prm_read_mod_reg(WKUP_MOD, PM_WKST);
+ omap3_pm_wkst.wkup = wkst;
if (wkst) {
iclk = cm_read_mod_reg(WKUP_MOD, CM_ICLKEN);
fclk = cm_read_mod_reg(WKUP_MOD, CM_FCLKEN);
@@ -187,6 +195,7 @@ static irqreturn_t prcm_interrupt_handler (int
irq, void *dev_id)
/* CORE */
wkst = prm_read_mod_reg(CORE_MOD, PM_WKST1);
+ omap3_pm_wkst.core1 = wkst;
if (wkst) {
iclk
[PATCH 0/3] OMAP3: PM: three fixes for OMAP3 CPU IDLE in PM branch
Hi, all I'm sending three small patches for OMAP3 CPU IDLE arch/arm/mach-omap2/cpuidle34xx.c |6 -- arch/arm/mach-omap2/pm34xx.c |5 +++-- 2 files changed, 7 insertions(+), 4 deletions(-) Your comments appreciated. Regards, Kim Kyuwon -- 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/3] OMAP3: PM: include 'mach/irqs.h'
This patch fixes this compile error CC arch/arm/mach-omap2/cpuidle34xx.o arch/arm/mach-omap2/cpuidle34xx.c:100: error: implicit declaration of function 'omap_irq_pending' make[1]: *** [arch/arm/mach-omap2/cpuidle34xx.o] Error 1 The omap_irq_pending() function is declared in 'arch/arm/plat-omap/include/mach/irqs.h' Signed-off-by: Kim Kyuwon q1@samsung.com --- arch/arm/mach-omap2/cpuidle34xx.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/cpuidle34xx.c b/arch/arm/mach-omap2/cpuidle34xx.c index 62fbb2e..5e50c46 100644 --- a/arch/arm/mach-omap2/cpuidle34xx.c +++ b/arch/arm/mach-omap2/cpuidle34xx.c @@ -28,6 +28,7 @@ #include mach/powerdomain.h #include mach/control.h #include mach/serial.h +#include mach/irqs.h #include pm.h -- 1.5.2.5 -- Kyuwon -- 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/3] OMAP3: PM: Remove double assignments of mpu_pd, core_pd
mpu_pd, core_pd is already assigned at the beginning of the omap3_idle_init() function. Signed-off-by: Kim Kyuwon q1@samsung.com --- arch/arm/mach-omap2/cpuidle34xx.c |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/cpuidle34xx.c b/arch/arm/mach-omap2/cpuidle34xx.c index 5e50c46..630108c 100644 --- a/arch/arm/mach-omap2/cpuidle34xx.c +++ b/arch/arm/mach-omap2/cpuidle34xx.c @@ -272,8 +272,6 @@ int omap3_idle_init(void) __func__); return -EIO; } - mpu_pd = pwrdm_lookup(mpu_pwrdm); - core_pd = pwrdm_lookup(core_pwrdm); return 0; } #endif /* CONFIG_CPU_IDLE */ -- 1.5.2.5 -- Kyuwon -- 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/3] OMAP3: PM: invoke omap_sram_idle() only when sleep_while_idle is enabled
If MPU goes to WFI in the idle thread, execution time becomes a bit
slow and the JTAG Debugger doesn't work. This patch is needed for
urgent works(e.g. booting and launching application) and debugging.
To enable sleep_while_idle mode, use below setting.
echo 1 /sys/power/sleep_while_idle
Signed-off-by: Kim Kyuwon q1@samsung.com
---
arch/arm/mach-omap2/cpuidle34xx.c |3 +++
arch/arm/mach-omap2/pm34xx.c |5 +++--
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/cpuidle34xx.c
index 630108c..1623c2f 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -87,6 +87,9 @@ static int omap3_enter_idle(struct cpuidle_device *dev,
local_irq_disable();
local_fiq_disable();
+ if (!enable_dyn_sleep)
+ goto return_sleep_time;
+
if (!enable_off_mode) {
if (mpu_state PWRDM_POWER_RET)
mpu_state = PWRDM_POWER_RET;
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 9102cee..402409c 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -484,8 +484,6 @@ static int omap3_fclks_active(void)
int omap3_can_sleep(void)
{
- if (!enable_dyn_sleep)
- return 0;
if (!omap_uart_can_sleep())
return 0;
if (omap3_fclks_active())
@@ -545,6 +543,9 @@ static void omap3_pm_idle(void)
local_irq_disable();
local_fiq_disable();
+ if (!enable_dyn_sleep)
+ goto out;
+
if (!omap3_can_sleep())
goto out;
--
1.5.2.5
--
Kyuwon
--
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 3/3] OMAP3: PM: invoke omap_sram_idle() only when sleep_while_idle is enabled
On Tue, Mar 17, 2009 at 11:53 PM, Kevin Hilman khil...@deeprootsystems.com wrote: Kim Kyuwon chamm...@gmail.com writes: If MPU goes to WFI in the idle thread, execution time becomes a bit slow and the JTAG Debugger doesn't work. This patch is needed for urgent works(e.g. booting and launching application) and debugging. Kim, Do you still need this patch when using the new lower-latency C1-state patch from Peter which I recently applied to the PM branch? With that patch, MPU and CORE stay ON, and the clkdomain is not allowed to idle so that the latency for C1 is on the order of a few usecs. No, I don't need this patch. I confirmed that JTAG debugger works with peter's patch, even though MPU goes to WFI. Thanks Keven, Peter! Kyuwon -- 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: About two patches that I sent recently.
Hi, Kevin
On Tue, Mar 10, 2009 at 2:21 AM, Kevin Hilman
khil...@deeprootsystems.com wrote:
Kim Kyuwon chamm...@gmail.com writes:
Hi, Kevin Hilman.
I'm sending this mail to tell you a few things about two recent
fetches that I sent.
1. [OMAP: GPIO: Remove enable_irq_wake() and disable_irq_wake() in
_set_gpio_wakeup() function]
I just found that you already sent the same patch in [OMAP2/3: GPIO:
remove recursion in IRQ wakeup path]. Sorry, I didn't know that. I
will cancel my patch. But can I know when your patch will be applied?
I need to update the description of mine and resend after
incorporating some review comments.
2. [OMAP3: PM: Add the wakeup source driver]
Would you please review this patch? If something is unclear or need to
change, please let me know. I would answer with please.
Yes, I will review this week.
Can I ask again when I can get your review? :)
And I'm resending the patch which is made for PM branch and added a
few trivial changes.
I really want to hear your opinion.
Thanks Regards,
--
Kyuwon
--
[PATCH] OMAP3: PM: Add the wakeup source driver
Sometimes, it is necessary to find out what does wake up my board?.
Notifying wake-up source feature may be used to blame unexpected
wake-up events which increase power consumption. And user mode
applications can act smartly according to the wake-up event to
minimize power consumption. This driver uses sysfs interface to give
information to user mode applications like:
cat /sys/power/wakeup_irq
cat /sys/power/wakeup_event
This driver also privides the unified GPIO wake-up source
configuration. specific GPIO settings in the board files are:
/* Wakeup source configuration */
static struct gpio_wake boardname_gpio_wake[] = {
{ 23, IRQF_TRIGGER_RISING | IRQF_SHARED, BT_WAKEUP,1},
{ 24, IRQF_TRIGGER_RISING | IRQF_SHARED, USB_DETECT, 1},
};
static struct omap_wake_platform_data boardname_wake_data = {
.qpio_wakes = boardname_gpio_wake,
.gpio_wake_num = ARRAY_SIZE(boardname_gpio_wake),
};
static struct platform_device boardname_wakeup = {
.name = omap-wake,
.id = -1,
.dev= {
.platform_data = boardname_wake_data,
},
};
The patch adds Kconfig options OMAP34xx wakeup source support under
System type-TI OMAP implementations menu.
Signed-off-by: Kim Kyuwon q1@samsung.com
---
arch/arm/mach-omap2/Makefile |1 +
arch/arm/mach-omap2/irq.c | 41 +++
arch/arm/mach-omap2/prcm-common.h |4 +
arch/arm/mach-omap2/prm-regbits-34xx.h |6 +
arch/arm/mach-omap2/wake34xx.c | 474
arch/arm/plat-omap/Kconfig |9 +
arch/arm/plat-omap/include/mach/irqs.h |1 +
arch/arm/plat-omap/include/mach/wake.h | 30 ++
8 files changed, 566 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/wake34xx.c
create mode 100644 arch/arm/plat-omap/include/mach/wake.h
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 16c6fb8..29ad0f1 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -25,6 +25,7 @@ obj-$(CONFIG_ARCH_OMAP2) += pm24xx.o
obj-$(CONFIG_ARCH_OMAP24XX)+= sleep24xx.o
obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o cpuidle34xx.o
obj-$(CONFIG_PM_DEBUG) += pm-debug.o
+obj-$(CONFIG_OMAP_WAKE)+= wake34xx.o
endif
# SmartReflex driver
diff --git a/arch/arm/mach-omap2/irq.c b/arch/arm/mach-omap2/irq.c
index be4b596..e3a2b53 100644
--- a/arch/arm/mach-omap2/irq.c
+++ b/arch/arm/mach-omap2/irq.c
@@ -193,6 +193,47 @@ int omap_irq_pending(void)
return 0;
}
+/*
+ * Get the first pending MPU IRQ number from 'irq_start'.
+ * If none, return -1.
+ */
+int omap_get_pending_mpu_irq(unsigned int irq_start)
+{
+ struct omap_irq_bank *bank = irq_banks;
+ int irq, bits_skip, bit_start;
+
+ if (irq_start = bank-nr_irqs)
+ return -1;
+
+ bits_skip = irq_start % IRQ_BITS_PER_REG;
+ bit_start = irq_start - bits_skip;
+
+ for (irq = bit_start; irq bank-nr_irqs; irq += IRQ_BITS_PER_REG) {
+ int ret, i, limit, offset = irq (~(IRQ_BITS_PER_REG - 1));
+
+ ret = intc_bank_read_reg(bank, (INTC_PENDING_IRQ0 + offset));
+ if (!ret)
+ continue;
+
+ limit = IRQ_BITS_PER_REG;
+
+ if (bit_start == irq) {
+ ret = bits_skip;
+ limit -= bits_skip;
+ } else
+ bits_skip = 0;
+
+ for (i = 0; i limit; i++) {
+ if (ret 0x1)
+ return irq + i + bits_skip;
+ else
+ ret = 1
Re: Setting individual GPIO registers
Hi, On Thu, Mar 5, 2009 at 12:41 AM, Premi, Sanjeev pr...@ti.com wrote: I am trying to get the wakeup event from touchscreen on omap3evm to bring the EVM out of suspend state. For my private testing, I have been updating individual registers bits in the GPIO registers from function ads7846_dev_init(). Ideally, I should be using standard GPIO APIs. However, most of the APIs are static within gpio.c How can I call functions like gpio_wake_enable(), gpio_unmask_irq() gpio_wake_enable: enable_irq_wake(gpio_to_irq(gpio #)); gpio_unmake_irq: request_irq(gpio_to_irq(gpio #), ...) or enable_irq(qpio_to_irq(gpio #)); OR Is there a function to access interface registers for GPIO banks? enable_irq_wake() and request_irq() would be enough. Somewhat related: I sent [OMAP wakeup source driver] a few days ago, so you can also use it. But you may need to configure 'struct gpio_wake' well and your 'irqflags' argument of irq_request(). Regards, -- Q1 -- 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/1] Regarding enable_irq_wake() and disable_irq_wake() functions
Hi,
The following patch was made to remove waning message below.
[ 755.708251] WARNING: at kernel/irq/manage.c:304 set_irq_wake+0x80/0xe4()
[ 755.708251] Unbalanced IRQ 29 wake disable
[ 755.708251] Modules linked in:
[ 755.708282] [c002efec] (dump_stack+0x0/0x14) from [c0057718]
(warn_slowpath+0x70/0x8c)
[ 755.708312] [c00576a8] (warn_slowpath+0x0/0x8c) from [c007e4c8]
(set_irq_wake+0x80/0xe4)
[ 755.708343] r3:001d r2:c0374eee
[ 755.708343] r7:8093 r6:001d r5: r4:c03d0184
[ 755.708374] [c007e448] (set_irq_wake+0x0/0xe4) from [c003cbe4]
(gpio_wake_enable+0xd8/0x114)
[ 755.708404] r9:ce7399b8 r8: r7: r6:0080 r5:6093
[ 755.708435] r4:c03cc998
[ 755.708435] [c003cb0c] (gpio_wake_enable+0x0/0x114) from
[c007e3b4] (set_irq_wake_real+0x38/0x3c)
[ 755.708465] r7:8013 r6:00b7 r5: r4:00b7
[ 755.708465] [c007e37c] (set_irq_wake_real+0x0/0x3c) from
[c007e4e8] (set_irq_wake+0xa0/0xe4)
First I tried to fix it by applying next patch, Because another GPIO
in same bank could enable or diable irq_wake twice in the original
code.
@@ -857,11 +857,13 @@ static int _set_gpio_wakeup(struct gpio_bank
*bank, int gpio, int enable)
}
spin_lock_irqsave(bank-lock, flags);
if (enable) {
+ if (!bank-suspend_wakeup)
+ enable_irq_wake(bank-irq);
bank-suspend_wakeup |= (1 gpio);
- enable_irq_wake(bank-irq);
} else {
- disable_irq_wake(bank-irq);
bank-suspend_wakeup = ~(1 gpio);
+ if (!bank-suspend_wakeup)
+ disable_irq_wake(bank-irq);
}
spin_unlock_irqrestore(bank-lock, flags);
return 0;
But this was not the real problem. Current enable_irq_wake and
disable_irq_wake isn't working correctly since the set_wake field of
omap_irq_chip is NULL.
Is these functions for the future implementation in OMAP?
Anyway..., I removed it in the following patch, and I think this work
can be done in other OMAP device driver which is using
enable_irq_wake() and something like that.
--
Q1
--
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/1] OMAP: GPIO: Remove enable_irq_wake() and disable_irq_wake() in _set_gpio_wakeup() function
Current omap_irq_chip variable (in arch/arm/mach-omap2/irq.c) doesn't
have set_wake function. So invoking enable_irq_wake() and
disable_irq_wake() for the MPU IRQs always returns -ENXIO and sometime
it generates warning message(Unbalanced IRQ %d wake disable). Actual
enabling and disable IRQ wakeup can be done by enable_irq() and
disable_irq().
Signed-off-by: Kim Kyuwon q1@samsung.com
---
arch/arm/plat-omap/gpio.c | 14 --
1 files changed, 4 insertions(+), 10 deletions(-)
diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c
index f856a90..798a8cd 100644
--- a/arch/arm/plat-omap/gpio.c
+++ b/arch/arm/plat-omap/gpio.c
@@ -837,13 +837,10 @@ static int _set_gpio_wakeup(struct gpio_bank
*bank, int gpio, int enable)
case METHOD_MPUIO:
case METHOD_GPIO_1610:
spin_lock_irqsave(bank-lock, flags);
- if (enable) {
+ if (enable)
bank-suspend_wakeup |= (1 gpio);
- enable_irq_wake(bank-irq);
- } else {
- disable_irq_wake(bank-irq);
+ else
bank-suspend_wakeup = ~(1 gpio);
- }
spin_unlock_irqrestore(bank-lock, flags);
return 0;
#endif
@@ -856,13 +853,10 @@ static int _set_gpio_wakeup(struct gpio_bank
*bank, int gpio, int enable)
return -EINVAL;
}
spin_lock_irqsave(bank-lock, flags);
- if (enable) {
+ if (enable)
bank-suspend_wakeup |= (1 gpio);
- enable_irq_wake(bank-irq);
- } else {
- disable_irq_wake(bank-irq);
+ else
bank-suspend_wakeup = ~(1 gpio);
- }
spin_unlock_irqrestore(bank-lock, flags);
return 0;
#endif
--
1.5.2.5
--
Q1
--
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/1] Regarding enable_irq_wake() and disable_irq_wake() functions
On Tue, Mar 3, 2009 at 11:02 AM, Kim Kyuwon chamm...@gmail.com wrote: Hi, But this was not the real problem. Current enable_irq_wake and disable_irq_wake isn't working correctly since the set_wake field of omap_irq_chip is NULL. Of course, thanks to Tony Lindgren's works, GPIO wake-up using enable_irq_wake() and disable_irq_wake() is nicely working. Is these functions for the future implementation in OMAP? Anyway..., I removed it in the following patch, and I think this work can be done in other OMAP device driver which is using enable_irq_wake() and something like that. -- Q1 -- Q1 -- 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
[RESEND][PATCH 1/2] usb: musb: fix the possible panic while resuming
While waking up, musb can cause a kernel panic. This patch is fixing
it by enabling the clock in the resume_early method.
Signed-off-by: Kim Kyuwon q1@samsung.com
---
drivers/usb/musb/musb_core.c |8 ++--
1 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 2cc34fa..6de2cb2 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -2169,16 +2169,13 @@ static int musb_suspend(struct platform_device
*pdev, pm_message_t message)
return 0;
}
-static int musb_resume(struct platform_device *pdev)
+static int musb_resume_early(struct platform_device *pdev)
{
- unsigned long flags;
struct musb *musb = dev_to_musb(pdev-dev);
if (!musb-clock)
return 0;
- spin_lock_irqsave(musb-lock, flags);
-
if (musb-set_clock)
musb-set_clock(musb-clock, 1);
else
@@ -2188,7 +2185,6 @@ static int musb_resume(struct platform_device *pdev)
* unless for some reason the whole soc powered down and we're
* not treating that as a whole-system restart (e.g. swsusp)
*/
- spin_unlock_irqrestore(musb-lock, flags);
return 0;
}
@@ -2206,7 +2202,7 @@ static struct platform_driver musb_driver = {
.remove = __devexit_p(musb_remove),
.shutdown = musb_shutdown,
.suspend= musb_suspend,
- .resume = musb_resume,
+ .resume_early = musb_resume_early,
};
/*-*/
--
1.5.2.5
--
Q1
--
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] MUSB and TWL4030-USB fixes
Hi, These fixes are the replacement of [ARM: OMAP: Disable USB interrupt in the musb_resume() function] and trying to following David Brownell's recommendation. Thanks, especially David. -- Kyuwon -- 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] usb: musb: fix the possible panic while resuming
From: Kim Kyuwon chamm...@gmail.com
While waking up, musb can cause a kernel panic. This patch is fixing
it by enabling the clock in the resume_early method.
Signed-off-by: Kim Kyuwon chamm...@gmail.com
---
drivers/usb/musb/musb_core.c | 21 +++--
1 files changed, 7 insertions(+), 14 deletions(-)
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 2cc34fa..ae76ad7 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -2141,16 +2141,13 @@ static int __devexit musb_remove(struct
platform_device *pdev)
#ifdef CONFIG_PM
-static int musb_suspend(struct platform_device *pdev, pm_message_t message)
+static int musb_suspend_late(struct platform_device *pdev, pm_message_t state)
{
- unsigned long flags;
- struct musb *musb = dev_to_musb(pdev-dev);
+ struct musb *musb = dev_to_musb(pdev-dev);
if (!musb-clock)
return 0;
- spin_lock_irqsave(musb-lock, flags);
-
if (is_peripheral_active(musb)) {
/* FIXME force disconnect unless we know USB will wake
* the system up quickly enough to respond ...
@@ -2165,20 +2162,17 @@ static int musb_suspend(struct platform_device
*pdev, pm_message_t message)
musb-set_clock(musb-clock, 0);
else
clk_disable(musb-clock);
- spin_unlock_irqrestore(musb-lock, flags);
+
return 0;
}
-static int musb_resume(struct platform_device *pdev)
+static int musb_resume_early(struct platform_device *pdev)
{
- unsigned long flags;
- struct musb *musb = dev_to_musb(pdev-dev);
+ struct musb *musb = dev_to_musb(pdev-dev);
if (!musb-clock)
return 0;
- spin_lock_irqsave(musb-lock, flags);
-
if (musb-set_clock)
musb-set_clock(musb-clock, 1);
else
@@ -2188,7 +2182,6 @@ static int musb_resume(struct platform_device *pdev)
* unless for some reason the whole soc powered down and we're
* not treating that as a whole-system restart (e.g. swsusp)
*/
- spin_unlock_irqrestore(musb-lock, flags);
return 0;
}
@@ -2205,8 +2198,8 @@ static struct platform_driver musb_driver = {
},
.remove = __devexit_p(musb_remove),
.shutdown = musb_shutdown,
- .suspend= musb_suspend,
- .resume = musb_resume,
+ .suspend_late = musb_suspend_late,
+ .resume_early = musb_resume_early,
};
/*-*/
--
1.5.2.5
--
Kyuwon
--
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/2] twl: usb: Add the resume() and suspend() methods to twl4030-usb.c
From: Minkyu Kang mk7.k...@samsung.com
The MPU module can be waked up by the unexpected USB
interrupt(HSUSB_MC_NINT). For instance, if the MUSB is working as
peripheral mode and connected to a host PC, it can never enter the low
power mode due to interrupts from the host PC. This patch added the
feature that a board specific file can determines that TWL4030
supplies the USB power or not in the low power mode. Disabling the USB
power may save the power consumption.
Signed-off-by: Minkyu Kang mk7.k...@samsung.com
Signed-off-by: Kim Kyuwon chamm...@gmail.com
---
drivers/usb/otg/twl4030-usb.c | 25 +
include/linux/i2c/twl4030.h |1 +
2 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/otg/twl4030-usb.c b/drivers/usb/otg/twl4030-usb.c
index 416e441..0d65a8d 100644
--- a/drivers/usb/otg/twl4030-usb.c
+++ b/drivers/usb/otg/twl4030-usb.c
@@ -256,6 +256,7 @@ struct twl4030_usb {
u8 linkstat;
u8 asleep;
boolirq_enabled;
+ boolsuspend_enabled;
};
/* internal define on top of container_of */
@@ -618,6 +619,7 @@ static int __init twl4030_usb_probe(struct
platform_device *pdev)
twl-otg.set_suspend= twl4030_set_suspend;
twl-usb_mode = pdata-usb_mode;
twl-asleep = 1;
+ twl-suspend_enabled= pdata-suspend_enabled;
/* init spinlock for workqueue */
spin_lock_init(twl-lock);
@@ -694,9 +696,32 @@ static int __exit twl4030_usb_remove(struct
platform_device *pdev)
return 0;
}
+int twl4030_usb_suspend(struct platform_device *pdev, pm_message_t state)
+{
+ struct twl4030_usb *twl = platform_get_drvdata(pdev);
+
+ if (!twl-suspend_enabled)
+ return 0;
+
+ twl-otg.set_suspend(twl-otg, 1);
+
+ return 0;
+}
+
+int twl4030_usb_resume(struct platform_device *pdev)
+{
+ struct twl4030_usb *twl = platform_get_drvdata(pdev);
+
+ twl-otg.set_suspend(twl-otg, 0);
+
+ return 0;
+}
+
static struct platform_driver twl4030_usb_driver = {
.probe = twl4030_usb_probe,
.remove = __exit_p(twl4030_usb_remove),
+ .suspend= twl4030_usb_suspend,
+ .resume = twl4030_usb_resume,
.driver = {
.name = twl4030_usb,
.owner = THIS_MODULE,
diff --git a/include/linux/i2c/twl4030.h b/include/linux/i2c/twl4030.h
index c89d33b..0b12509 100644
--- a/include/linux/i2c/twl4030.h
+++ b/include/linux/i2c/twl4030.h
@@ -325,6 +325,7 @@ enum twl4030_usb_mode {
struct twl4030_usb_data {
enum twl4030_usb_mode usb_mode;
+ bool suspend_enabled;
};
struct twl4030_ins {
--
1.5.2.5
--
Kyuwon
--
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/2] usb: musb: fix the possible panic while resuming
On Thu, Feb 26, 2009 at 9:13 AM, Felipe Balbi m...@felipebalbi.com wrote:
On Wed, Feb 25, 2009 at 08:53:00PM +0900, Kim Kyuwon wrote:
From: Kim Kyuwon chamm...@gmail.com
While waking up, musb can cause a kernel panic. This patch is fixing
it by enabling the clock in the resume_early method.
Signed-off-by: Kim Kyuwon chamm...@gmail.com
---
drivers/usb/musb/musb_core.c | 21 +++--
1 files changed, 7 insertions(+), 14 deletions(-)
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 2cc34fa..ae76ad7 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -2141,16 +2141,13 @@ static int __devexit musb_remove(struct
platform_device *pdev)
#ifdef CONFIG_PM
-static int musb_suspend(struct platform_device *pdev, pm_message_t message)
+static int musb_suspend_late(struct platform_device *pdev, pm_message_t
state)
{
- unsigned long flags;
- struct musb *musb = dev_to_musb(pdev-dev);
+ struct musb *musb = dev_to_musb(pdev-dev);
this hunk is unecessary, please revert. I'll also take a closer look
tomorrow, it's already really late and need some nap (as suggested by
greg, hehe :-p)
OK, but before I resend the patch, I have something to check again.
Now I know that, in addition to HSUSB_MC_NINT disabled by the previous
patch [ARM: OMAP: Disable USB interrupt in the musb_resume()
function], USBTLL_SWAKEUP and USBHOST_SWAKEUP can be also wake-up
source events to PRMC module. Sorry I didn't know that time. The
remote wake uses these two SWAKEUP. David, is my previous patch is
still NAK?
--
balbi
--
Q1
--
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/2] usb: musb: fix the possible panic while resuming
Hi, On Thu, Feb 26, 2009 at 3:37 PM, Gadiyar, Anand gadi...@ti.com wrote: snip Now I know that, in addition to HSUSB_MC_NINT disabled by the previous patch [ARM: OMAP: Disable USB interrupt in the musb_resume() function], USBTLL_SWAKEUP and USBHOST_SWAKEUP can be also wake-up source events to PRMC module. Sorry I didn't know that time. The remote wake uses these two SWAKEUP. David, is my previous patch is still NAK? USBTLL_SWAKEUP and USBHOST_SWAKEUP are not for MUSB. But they are used to wake up request. Can I ask what they are for? - Anand -- Q1 -- 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] ARM: OMAP: Disable USB interrupt in the musb_resume() function
Hi, On Sat, Feb 21, 2009 at 11:30 AM, David Brownell davi...@pacbell.net wrote: On Tuesday 03 February 2009, Kim Kyuwon wrote: USB should be suspended with interrupt disabled[1]. That text means that the sysdev.suspend() method is called with IRQs disabled ... just like suspend_late() methods do (now) for other busses. (There is no longer any point to using a sysdev; platform_device can now do everything sysdev can do.) I thought why the '/Documentation/power/devices.txt' mentioned 'disabling IRQs'. Let's look at the call-stack which is shown when the processor resumes from 'Sleep' state. suspend_devices_and_enter() -- suspend_enter() -- -- arch_suspend_disable_irqs() -- -- suspend_ops-enter() // Waking up from here -- -- arch_suspend_enable_irqs()// A -- -- Do someting.. -- device_resume() // B As I talked in the commit message, after invoking the arch_suspend_disable_irqs() function, some interrupt handlers would start to be invoked again. And most interrupt handlers access each peripheral controller register. However, each iclk, fclk and controller are disabled until the resume() functions are called in device_resume() function. Therefore, Not disabling IRQs can cause kernel panics. For instance, if an suspend function disable iclk, an IRQ handler that accesses controller register and invoked from A to B will make the data abort exception. Maybe all device driver doesn't need to disable IRQs while entering CPU sleep state but as you can see most devices that handle the peripheral controller should disable IRQs. If USB is suspended with interrupt enabled and connected to host PC, a kernel panic would occur When it wakes up. Because, after the arch_suspend_enable_irqs() function is called in the suspend_enter() function, USB Interrupt handler is called, even though USB controller is still not resumed! All devices are resumed after the device_resume() is called. This change seems pretty wrong. The first thing I noticed is that it could prevent remote wakeup from working. Assuming you actually observed this oops, the bug is more likely to be that it didn't enter the right kind of suspend mode. There are at least two types of suspend that a USB host should be prepared to handle: - OFF ... the lowest power mode, everything connected to the host gets logically disconnected. Wakeup involves complete re-enumeration. - SUSPEND ... with two variants, where remote wakeup is (a) enabled or (b) disabled, but the USB link enters the suspend state: VBUS supplied, with low current draw, and no SOFs get sent. In the wakeup-enabled case, an IRQ is often used as the wakeup trigger. I'm not entirely sure this driver handles suspend right.. Now, the actual details of how the USB controller, its transceiver, and other related hardware is configured... can vary a lot. Are you sure you haven't broken remote wakeup by doing this? Of course, this patch prevents remote wakeup, because I applied this patch to the 'SUSPEND' function. Suspend function is invoked to disable the USB from working not to enable the remote wakeup. The musb_suspend() function is already disabling the USB clock. That means that if generic_interrupt() is invoked from A to B, it also causes oops, so USB IRQ should be disabled. I think the 'remote wakeup' function is another issue and another feature. the current suspend function of musb driver doesn't consider the 'remote wakeup' enough. It can be added after my patch is applied. But there is one thing absolutely true, If the USB clock is disabled, IRQ should be disabled. This patch is just for the stable musb. Somewhat related: USB insertion and deletion can be configured as wake-source too. As you know it is different from USB interrupt. so I don't think waking up from the USB interrupt is still not critical :) - Dave -- Kyuwon -- 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: HSMMC: Initialize hsmmc controller registers when resuming
Hi,
On Sat, Feb 21, 2009 at 6:11 AM, David Brownell davi...@pacbell.net wrote:
On Friday 20 February 2009, Kim Kyuwon wrote:
+static void omap_hsmmc_init(struct mmc_omap_host *host)
+{
+ u32 hctl, capa, value;
+
+ /* Only MMC1 supports 3.0V */
+ if (host-id == OMAP_MMC1_DEVID) {
+ hctl = SDVS30;
Shouldn't it be remembering what voltage it was using,
and then restore that, instead of always making MMC1
restart at a 3.0V level? That's pretty awkward to test
unless you have a 1.8V-capable card in MMC1...
You are somewhat right, thank you.
But remebering what voltage it was using doesn't feasible to me,
because the card can be changed while in 'Sleep' state. I should have
inserted a function that detect the right voltage after intializing. I
will resend the patch later.
--
Kyuwon
--
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: HSMMC: Initialize hsmmc controller registers when resuming
Most registers lose its state when the processor wakes up from sleep state.
Thus registers should be initialized, when the processor wakes up. However the
current hsmmc 'resume' function doesn't consider this issue and finally makes
deadlock. So this patch fixes this problem.
Signed-off-by: Kim Kyuwon chamm...@gmail.com
---
drivers/mmc/host/omap_hsmmc.c | 155 +
1 files changed, 79 insertions(+), 76 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 56363c5..5a73fa6 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -55,6 +55,7 @@
#define VS30 (1 25)
#define SDVS18 (0x5 9)
#define SDVS30 (0x6 9)
+#define SDVS_MASK 0x0E00
#define SDVSCLR0xF1FF
#define SDVSDET0x0400
#define AUTOIDLE 0x1
@@ -861,6 +862,34 @@ static int omap_hsmmc_get_ro(struct mmc_host *mmc)
return pdata-slots[0].get_ro(host-dev, 0);
}
+static void omap_hsmmc_init(struct mmc_omap_host *host)
+{
+ u32 hctl, capa, value;
+
+ /* Only MMC1 supports 3.0V */
+ if (host-id == OMAP_MMC1_DEVID) {
+ hctl = SDVS30;
+ capa = VS30 | VS18;
+ } else {
+ hctl = SDVS18;
+ capa = VS18;
+ }
+
+ value = OMAP_HSMMC_READ(host-base, HCTL) ~SDVS_MASK;
+ OMAP_HSMMC_WRITE(host-base, HCTL, value | hctl);
+
+ value = OMAP_HSMMC_READ(host-base, CAPA);
+ OMAP_HSMMC_WRITE(host-base, CAPA, value | capa);
+
+ /* Set the controller to AUTO IDLE mode */
+ value = OMAP_HSMMC_READ(host-base, SYSCONFIG);
+ OMAP_HSMMC_WRITE(host-base, SYSCONFIG, value | AUTOIDLE);
+
+ /* Set SD bus power bit */
+ value = OMAP_HSMMC_READ(host-base, HCTL);
+ OMAP_HSMMC_WRITE(host-base, HCTL, value | SDBP);
+}
+
static struct mmc_host_ops mmc_omap_ops = {
.request = omap_mmc_request,
.set_ios = omap_mmc_set_ios,
@@ -876,7 +905,6 @@ static int __init omap_mmc_probe(struct
platform_device *pdev)
struct mmc_omap_host *host = NULL;
struct resource *res;
int ret = 0, irq;
- u32 hctl, capa;
if (pdata == NULL) {
dev_err(pdev-dev, Platform Data is missing\n);
@@ -981,28 +1009,7 @@ static int __init omap_mmc_probe(struct
platform_device *pdev)
if (pdata-slots[host-slot_id].wires = 4)
mmc-caps |= MMC_CAP_4_BIT_DATA;
- /* Only MMC1 supports 3.0V */
- if (host-id == OMAP_MMC1_DEVID) {
- hctl = SDVS30;
- capa = VS30 | VS18;
- } else {
- hctl = SDVS18;
- capa = VS18;
- }
-
- OMAP_HSMMC_WRITE(host-base, HCTL,
- OMAP_HSMMC_READ(host-base, HCTL) | hctl);
-
- OMAP_HSMMC_WRITE(host-base, CAPA,
- OMAP_HSMMC_READ(host-base, CAPA) | capa);
-
- /* Set the controller to AUTO IDLE mode */
- OMAP_HSMMC_WRITE(host-base, SYSCONFIG,
- OMAP_HSMMC_READ(host-base, SYSCONFIG) | AUTOIDLE);
-
- /* Set SD bus power bit */
- OMAP_HSMMC_WRITE(host-base, HCTL,
- OMAP_HSMMC_READ(host-base, HCTL) | SDBP);
+ omap_hsmmc_init(host);
/* Request IRQ for MMC operations */
ret = request_irq(host-irq, mmc_omap_irq, IRQF_DISABLED,
@@ -1127,41 +1134,38 @@ static int omap_mmc_suspend(struct
platform_device *pdev, pm_message_t state)
if (host host-suspended)
return 0;
- if (host) {
- ret = mmc_suspend_host(host-mmc, state);
- if (ret == 0) {
- host-suspended = 1;
-
- OMAP_HSMMC_WRITE(host-base, ISE, 0);
- OMAP_HSMMC_WRITE(host-base, IE, 0);
+ ret = mmc_suspend_host(host-mmc, state);
+ if (ret == 0) {
+ host-suspended = 1;
- if (host-pdata-suspend) {
- ret = host-pdata-suspend(pdev-dev,
- host-slot_id);
- if (ret)
- dev_dbg(mmc_dev(host-mmc),
- Unable to handle MMC board
-level suspend\n);
- }
+ OMAP_HSMMC_WRITE(host-base, ISE, 0);
+ OMAP_HSMMC_WRITE(host-base, IE, 0);
- if (!(OMAP_HSMMC_READ(host-base, HCTL) SDVSDET)) {
- OMAP_HSMMC_WRITE(host-base, HCTL,
- OMAP_HSMMC_READ(host-base, HCTL)
-SDVSCLR);
- OMAP_HSMMC_WRITE(host-base, HCTL,
- OMAP_HSMMC_READ
Re: [patch 2.6.29-rc3-omap-git] omap3: gpio pin config bugfixes
Hi,
On Mon, Feb 9, 2009 at 1:55 PM, David Brownell davi...@pacbell.net wrote:
From: David Brownell dbrown...@users.sourceforge.net
Bugfix several GPIO mux configurations which didn't enable the
input drivers, but weren't named as e.g. ..._GPIO141_OUT.
These bugs were added quite recently, for OMAP3 EVM support.
To help avoid such bugs in the future, update the comment to
clarify the rule: always use PIN_INPUT, unless the name uses
that name suffix, to be crystal-clear on the signal's use as
output-only.
(Also adds GPIO-63, for the EVM's MMC-1 writeprotect switch.
Presumably that works right...)
Signed-off-by: David Brownell dbrown...@users.sourceforge.net
---
arch/arm/mach-omap2/mux.c | 13 -
arch/arm/plat-omap/include/mach/mux.h |1 +
2 files changed, 9 insertions(+), 5 deletions(-)
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -453,6 +453,7 @@ MUX_CFG_34XX(AC1_3430_USB3FS_PHY_MM3_TX
/* 34XX GPIO - bidirectional, unless the name has an _OUT suffix.
+ * (Always specify PIN_INPUT, except for names suffixed by _OUT.)
* No internal pullup/pulldown without _UP or _DOWN suffix.
*/
MUX_CFG_34XX(AH8_34XX_GPIO29, 0x5fa,
@@ -460,17 +461,19 @@ MUX_CFG_34XX(AH8_34XX_GPIO29, 0x5fa,
MUX_CFG_34XX(J25_34XX_GPIO170, 0x1c6,
OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_INPUT)
MUX_CFG_34XX(AF26_34XX_GPIO0, 0x1e0,
- OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_OUTPUT)
+ OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_INPUT)
MUX_CFG_34XX(AF22_34XX_GPIO9, 0xa18,
- OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_OUTPUT)
+ OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_INPUT)
+MUX_CFG_34XX(L8_34XX_GPIO63, 0x0ce,
+ OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_INPUT)
MUX_CFG_34XX(AF6_34XX_GPIO140_UP, 0x16c,
OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_INPUT_PULLUP)
MUX_CFG_34XX(AE6_34XX_GPIO141, 0x16e,
- OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_OUTPUT)
+ OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_INPUT)
MUX_CFG_34XX(AF5_34XX_GPIO142, 0x170,
- OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_OUTPUT)
+ OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_INPUT)
MUX_CFG_34XX(AE5_34XX_GPIO143, 0x172,
- OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_OUTPUT)
+ OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_INPUT)
};
So the thing is, OMAP34XX_PIN_INPUT doens't mean input-only, but
input-and-output. And OMAP34XX_PIN_OUTPUT doen't mean output, but output-only.
Names of macros are really confusing me. Shouldn't we change names of these
macros first? For example,
OMAP34XX_PIN_INPUT - OMAP34XX_PIN_INPUT_EN
OMAP34XX_PIN_OUTPUT - OMAP34XX_PIN_OUTPUT_ONLY
--- a/arch/arm/plat-omap/include/mach/mux.h
+++ b/arch/arm/plat-omap/include/mach/mux.h
@@ -792,6 +792,7 @@ enum omap34xx_index {
J25_34XX_GPIO170,
AF26_34XX_GPIO0,
AF22_34XX_GPIO9,
+ L8_34XX_GPIO63,
AF6_34XX_GPIO140_UP,
AE6_34XX_GPIO141,
AF5_34XX_GPIO142,
--
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
--
Kim Kyuwon
--
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] ARM: OMAP: Disable USB interrupt in the musb_resume() function
On Wed, Feb 4, 2009 at 7:28 AM, Felipe Balbi m...@felipebalbi.com wrote: On Tue, Feb 03, 2009 at 12:42:36PM -0800, Tony Lindgren wrote: * Kim Kyuwon chamm...@gmail.com [090131 00:22]: USB should be suspended with interrupt disabled[1]. If USB is suspended with interrupt enabled and connected to host PC, a kernel panic would occur When it wakes up. Because, after the arch_suspend_enable_irqs() function is called in the suspend_enter() function, USB Interrupt handler is called, even though USB controller is still not resumed! All devices are resumed after the device_resume() is called. Please send the usb patches to the linux-...@vger.kernel.org list with linux-omap list Cc'd. and Cc me as well and David Brownell OK. I will resend this patch to the linux-...@vger.kernel.org list with CCing linux-omap list, Felipe Balbi and David Brownell -- balbi -- Kim Kyuwon -- 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] ARM: OMAP: Disable USB interrupt in the musb_resume() function
USB should be suspended with interrupt disabled[1]. If USB is suspended with
interrupt enabled and connected to host PC, a kernel panic would occur When
it wakes up. Because, after the arch_suspend_enable_irqs() function is called
in the suspend_enter() function, USB Interrupt handler is called, even though
USB controller is still not resumed! All devices are resumed after the
device_resume() is called.
[1] /Documentation/power/devices.txt: 412 line
Signed-off-by: Kim Kyuwon chamm...@gmail.com
---
drivers/usb/musb/musb_core.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 2cc34fa..0dfe15e 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -2151,6 +2151,8 @@ static int musb_suspend(struct platform_device
*pdev, pm_message_t message)
spin_lock_irqsave(musb-lock, flags);
+ disable_irq(musb-nIrq);
+
if (is_peripheral_active(musb)) {
/* FIXME force disconnect unless we know USB will wake
* the system up quickly enough to respond ...
@@ -2184,6 +2186,8 @@ static int musb_resume(struct platform_device *pdev)
else
clk_enable(musb-clock);
+ enable_irq(musb-nIrq);
+
/* for static cmos like DaVinci, register values were preserved
* unless for some reason the whole soc powered down and we're
* not treating that as a whole-system restart (e.g. swsusp)
--
Kim Kyuwon
--
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] ARM: OMAP: Disable USB interrupt in the musb_resume() function
USB should be suspended with interrupt disabled[1]. If USB is suspended with
interrupt enabled and connected to host PC, a kernel panic would occur When
it wakes up. Because, after the arch_suspend_enable_irqs() function is called
in the suspend_enter() function, USB Interrupt handler is called, even though
USB controller is still not resumed! All devices are resumed after the
device_resume() is called.
[1] /Documentation/power/devices.txt: 412 line
Signed-off-by: Kim Kyuwon chamm...@gmail.com
---
drivers/usb/musb/musb_core.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 2cc34fa..0dfe15e 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -2151,6 +2151,8 @@ static int musb_suspend(struct platform_device
*pdev, pm_message_t message)
spin_lock_irqsave(musb-lock, flags);
+ disable_irq(musb-nIrq);
+
if (is_peripheral_active(musb)) {
/* FIXME force disconnect unless we know USB will wake
* the system up quickly enough to respond ...
@@ -2184,6 +2186,8 @@ static int musb_resume(struct platform_device *pdev)
else
clk_enable(musb-clock);
+ enable_irq(musb-nIrq);
+
/* for static cmos like DaVinci, register values were preserved
* unless for some reason the whole soc powered down and we're
* not treating that as a whole-system restart (e.g. swsusp)
--
Kim Kyuwon
--
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
Fwd: Questions about masking interrupts when disabling interrupts
My Gmail account has some problems
I send again.
-- Forwarded message --
From: Kim Kyuwon chamm...@gmail.com
Date: 2009/1/8
Subject: Re: Questions about masking interrupts when disabling interrupts
To: Tony Lindgren t...@atomide.com
Cc: linux-omap@vger.kernel.org, 박경민 kyungmin.p...@samsung.com, 허성관
sk@samsung.com
Thanks Tony very much for your reply!
On Wed, Jan 7, 2009 at 10:05 PM, Tony Lindgren t...@atomide.com wrote:
* 김규원 chamm...@gmail.com [090106 04:59]:
Greetings,
I'm enabling the Suspend-to-RAM state in our new OMAP3 Board.
But I had some problems because of USB Interrupt.
Although I disabled USB interrupt by disable_irq() function while
entering the Suspend,
M_IRQ_92 irq continuously wake up the OMAP3430 Processor.
So, I fixed this problem as following patch.
My Questions are:
1. Could anyone suggest the better solution for this problem?
Maybe suspend the USΒ too? :)
I confirmed musb_suspend() function was invoked while entering Suspend-to-RAM
state. musb_suspend() didn't disable USB interrupt, but only USB clock. Devices
should be suspended with interrupts disabled
(/Documenttation/power/devices.txt - 412line)
So I modified musb_suspend() to disable USB interrupt
(I'm planning to send this patch very soon)
I even wrote 0 to PM_WKEN_USBHOST[EN_USBHOST] bit. But our OMAP3430 board
still have woken up by USB interrupt, because disable_irq() didn't mask the
interrupt.
2. If there is no better solution, can I be applied this patch to omap-tree?
The patch looks OK to me, assuming the default enable calls unmask?
Right, default_enable() function(kernel/irq/chip.c 222line) calls unmask
Regards,
Tony
Thank you!
commit bbb49321b161e6a9ff2b73326d4012d8eb8bbf23
Author: Kim Kyuwon chamm...@gmail.com
Date: Tue Jan 6 10:11:46 2009 +0900
ARM: OMAP3: Mask interrupts when disabling interrupts
By Ingo Molnar, interrupts are not masked by default.
(refer to 76d2160147f43f982dfe881404cfde9fd0a9da21)
But if interrupts are not masked, the processor can wake up while in
Suspend-to-RAM state by an external interrupt. For example, if an
OMAP3 board
is connected to Host PC by USB and entered to Suspend-to-RAM
state, it wake up
automatically by M_IRQ_92. The disable_irq() function can't disable the
interrupt in H/W level, So I modified arch/arm/mach-omap2/irq.c
Signed-off-by: Kim Kyuwon chamm...@gmail.com
diff --git a/arch/arm/mach-omap2/irq.c b/arch/arm/mach-omap2/irq.c
index 110acb9..b44dcae 100644
--- a/arch/arm/mach-omap2/irq.c
+++ b/arch/arm/mach-omap2/irq.c
@@ -123,6 +123,11 @@ static void omap_unmask_irq(unsigned int irq)
intc_bank_write_reg(1 irq, irq_banks[0], INTC_MIR_CLEAR0 + offset);
}
+static void omap_disable_irq(unsigned int irq)
+{
+ omap_mask_irq(irq);
+}
+
static void omap_mask_ack_irq(unsigned int irq)
{
omap_mask_irq(irq);
@@ -134,6 +139,7 @@ static struct irq_chip omap_irq_chip = {
.ack= omap_mask_ack_irq,
.mask = omap_mask_irq,
.unmask = omap_unmask_irq,
+ .disable = omap_disable_irq,
};
static void __init omap_irq_bank_init_one(struct omap_irq_bank *bank)
--
Kim Kyuwon
--
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
Regards,
--
Kim Kyuwon
--
Kim Kyuwon
