RE: [PATCH 2/7] 34XX: PM: Workaround to enable autoidle for clocks and plls
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jouni Hogander
Sent: Wednesday, June 25, 2008 2:44 PM
To: linux-omap@vger.kernel.org
Subject: [PATCH 2/7] 34XX: PM: Workaround to enable autoidle
for clocks and plls
This workaround enables autoidle for interface clocks and plls. Also
automatic control of external oscillator through sys_clkreq is
enabled. I think these should be done by clockfw.
Signed-off-by: Jouni Hogander [EMAIL PROTECTED]
---
arch/arm/mach-omap2/pm34xx.c | 120
++
1 files changed, 120 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c
b/arch/arm/mach-omap2/pm34xx.c
index c7493f5..2dccd0b 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -332,6 +332,126 @@ static struct platform_suspend_ops
omap_pm_ops = {
static void __init prcm_setup_regs(void)
{
+ /* XXX Enable interface clock autoidle for all modules. This
+ * should be done by clockfw */
+ cm_write_mod_reg(
+ OMAP3430ES2_AUTO_MMC3 |
+ OMAP3430ES2_AUTO_ICR |
+ OMAP3430_AUTO_AES2 |
+ OMAP3430_AUTO_SHA12 |
+ OMAP3430_AUTO_DES2 |
+ OMAP3430_AUTO_MMC2 |
+ OMAP3430_AUTO_MMC1 |
+ OMAP3430_AUTO_MSPRO |
+ OMAP3430_AUTO_HDQ |
+ OMAP3430_AUTO_MCSPI4 |
+ OMAP3430_AUTO_MCSPI3 |
+ OMAP3430_AUTO_MCSPI2 |
+ OMAP3430_AUTO_MCSPI1 |
+ OMAP3430_AUTO_I2C3 |
+ OMAP3430_AUTO_I2C2 |
+ OMAP3430_AUTO_I2C1 |
+ OMAP3430_AUTO_UART2 |
+ OMAP3430_AUTO_UART1 |
+ OMAP3430_AUTO_GPT11 |
+ OMAP3430_AUTO_GPT10 |
+ OMAP3430_AUTO_MCBSP5 |
+ OMAP3430_AUTO_MCBSP1 |
+ OMAP3430ES1_AUTO_FAC | /* This is es1 only */
+ OMAP3430_AUTO_MAILBOXES |
+ OMAP3430_AUTO_OMAPCTRL |
+ OMAP3430ES1_AUTO_FSHOSTUSB |
+ OMAP3430_AUTO_HSOTGUSB |
+ OMAP3430ES1_AUTO_D2D | /* This is es1 only */
+ OMAP3430_AUTO_SSI,
+ CORE_MOD, CM_AUTOIDLE1);
+
+ cm_write_mod_reg(
+ OMAP3430_AUTO_PKA |
+ OMAP3430_AUTO_AES1 |
+ OMAP3430_AUTO_RNG |
+ OMAP3430_AUTO_SHA11 |
+ OMAP3430_AUTO_DES1,
+ CORE_MOD, CM_AUTOIDLE2);
+
+ if (is_sil_rev_greater_than(OMAP3430_REV_ES1_0)) {
+ cm_write_mod_reg(
+ OMAP3430ES2_AUTO_USBTLL,
+ CORE_MOD, CM_AUTOIDLE3);
+ }
+
+ cm_write_mod_reg(
+ OMAP3430_AUTO_WDT2 |
+ OMAP3430_AUTO_WDT1 |
+ OMAP3430_AUTO_GPIO1 |
+ OMAP3430_AUTO_32KSYNC |
+ OMAP3430_AUTO_GPT12 |
+ OMAP3430_AUTO_GPT1 ,
+ WKUP_MOD, CM_AUTOIDLE);
+
+ cm_write_mod_reg(
+ OMAP3430_AUTO_DSS,
+ OMAP3430_DSS_MOD,
+ CM_AUTOIDLE);
+
+ cm_write_mod_reg(
+ OMAP3430_AUTO_CAM,
+ OMAP3430_CAM_MOD,
+ CM_AUTOIDLE);
+
+ cm_write_mod_reg(
+ OMAP3430_AUTO_GPIO6 |
+ OMAP3430_AUTO_GPIO5 |
+ OMAP3430_AUTO_GPIO4 |
+ OMAP3430_AUTO_GPIO3 |
+ OMAP3430_AUTO_GPIO2 |
+ OMAP3430_AUTO_WDT3 |
+ OMAP3430_AUTO_UART3 |
+ OMAP3430_AUTO_GPT9 |
+ OMAP3430_AUTO_GPT8 |
+ OMAP3430_AUTO_GPT7 |
+ OMAP3430_AUTO_GPT6 |
+ OMAP3430_AUTO_GPT5 |
+ OMAP3430_AUTO_GPT4 |
+ OMAP3430_AUTO_GPT3 |
+ OMAP3430_AUTO_GPT2 |
+ OMAP3430_AUTO_MCBSP4 |
+ OMAP3430_AUTO_MCBSP3 |
+ OMAP3430_AUTO_MCBSP2,
+ OMAP3430_PER_MOD,
+ CM_AUTOIDLE);
+
+ if (is_sil_rev_greater_than(OMAP3430_REV_ES1_0)) {
+ cm_write_mod_reg(
+ OMAP3430ES2_AUTO_USBHOST,
+ OMAP3430ES2_USBHOST_MOD,
+ CM_AUTOIDLE);
+ }
+
+ /* XXX Set all plls to autoidle. This is needed until
autoidle is
+ * enabled by clockfw */
+ cm_write_mod_reg(1 OMAP3430_CLKTRCTRL_IVA2_SHIFT,
+ OMAP3430_IVA2_MOD,
+ CM_AUTOIDLE2);
+ cm_write_mod_reg(1 OMAP3430_AUTO_MPU_DPLL_SHIFT,
+ MPU_MOD,
+ CM_AUTOIDLE2);
+ cm_write_mod_reg((1 OMAP3430_AUTO_PERIPH_DPLL_SHIFT) |
+ (1 OMAP3430_AUTO_CORE_DPLL_SHIFT),
+ PLL_MOD,
+ CM_AUTOIDLE);
+ cm_write_mod_reg(1 OMAP3430ES2_AUTO_PERIPH2_DPLL_SHIFT,
+ PLL_MOD,
+ CM_AUTOIDLE2);
+
+ /* XXX Enable control of expternal oscillator
Re: N810 power problems, bootloader upgrade, won't boot
On Thu, 26 Jun 2008 18:13:59 -0500, green [EMAIL PROTECTED] wrote: I've been having power problems with my N810. These problems appear on startup (see three links below) and are supposedly fix by a bootloader upgrade, so I upgraded using the Maemo Diablo Fiasco image RX-44_DIABLO_4.2008.23-14_PR_COMBINED_MR0_ARM.bin. Perhaps this has fixed the problem, but it has caused another: now the N810 won't boot with the kernels I build, nor will it boot with the zImage-n8x0-2008-05-15 test kernel that Tony Lindgren provided recently. By not booting I mean that I see the NOKIA splash screen only; nothing else happens. Any ideas what I need to do? I'd rather not downgrade because of problems I've had with the device suddenly powering off when idle [3]. Diablo releases are using the oficial Machine ID for n810 hw, so the hack in mach-types is not needed anymore. -- Best Regards, Felipe Balbi http://blog.felipebalbi.com [EMAIL PROTECTED] -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/02] OMAP3 CPUidle driver
ext Kevin Hilman [EMAIL PROTECTED] writes: [EMAIL PROTECTED] (Högander Jouni) writes: ext Kevin Hilman [EMAIL PROTECTED] writes: [EMAIL PROTECTED] (Högander Jouni) writes: ext Kevin Hilman [EMAIL PROTECTED] writes: Rajendra Nayak [EMAIL PROTECTED] writes: Rajendra Nayak [EMAIL PROTECTED] writes: This patch adds the OMAP3 cpuidle driver. Irq enable/disable is done in the core cpuidle driver before it queries the governor for the next state. Can you explain why you need the IRQ/FIQ disable added to cpuidle_idle_call() This was done to prevent any interrupts firing in between a cpuidle_curr_governor-select() and target_state-enter(). I understand that, but I still don't understand exactly what you're trying to prevent. Did you have a specific bug that this prevented? An interrupt in between could end up with a previously selected state to be programmed. Remember that this function _is_ the idle loop, meaning when this runs nothing else is happening. After the select, if other system activity has happened (e.g. and interrupt, or thread wakeup etc.), it will run before the target_state-enter() because of the check for need_resched(). What happens if this interrupt, or thread wakeup causes change on latency requirements? Then we are entering sleep state which was selected using wrong latency requirement data. If a thread is awoken by an interrupt, then need_resched() will be true, and the idle loop will exit without trying to enter the idle state. Even in that case there is still period in idle loop, were it is possible that latency requirement changes and cpuidle doesn't know this on frist enter state. This is after need_resched. I don't know this area too good, but isn't it also possible that interrupt which is handled, has caused latency requirement change and there is no NEED_RESCHED flag set? IMHO, these things should be handled on a per-driver/subsystem basis, not by a global interrupt lock. I agree this, but probably this is just a hole in my knowledge. I mean I can't figure out what is reliable way to check wether sleep state needs to be reselected. Leaving interrupts enabled makes it worse, because then it is possible that idle loop is suspended in the middle of the loop and we don't know that this happened. Remember that this patchset is still missing a very important piece which is the omap3_idle_bm_check(). This is an of how these special cases are handled. For example, if an interrupt fires which triggers driver activity, this function is supposed to look for clock activity and potentially adjust the depth of sleep that can be entered. Well again latency constraint might change and there is no clock activity. My personal opinion is just that idle loop from selection of a sleep state to exiting it, should be atomic. If an interrupt fires in the middle of the loop then the state of the system is not same as it was in the time of the state selection. In this case loop should be exited. When there is again idle time and idle loop is entered, I think it should be always restarted from the selection. Any suggestions on a better way to handle this? Just drop the IRQ/FIQ disables altogether. At least these are needed at some point in idle loop. Otherwise we might stepout from idle and sram in a point where it is not acceptable. Agreed, interrupt enable/disable is needed in the idle loop, but not in the CPUidle code. The current OMAP idle loop code (omap2_pm_idle) already does this, but the CPUidle enter state hook does not. The omap3_enter_idle() function should be the one who enables/disables interrupts. At a minimulm, the omap_sram_idle should be called with interrupts disabled. If done this way, it should be checked that target state is still valid before entering omap_sram_idle. How could CPUidle enter state know wether it is still valid? Again, this is the job of the OMAP specific idle loop, not the global CPUidle code. For example, the current idle loop simply does: if (omap_irq_pending()) goto out; so it doesn't enter idle if there's an interrupt pending. So, I'm not arguing that your concerns aren't valid, because indeed they are valid corner cases. I'm just arguing that these special cases should be handled in the OMAP code, not the global CPUidle code. Kevin -- Jouni Högander -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[Resending PATCH 2/2] ARM: OMAP2: RTC board specific code: rebased
This patch adds rtc-twl4030 driver specific code.
Signed-off-by: Girish S G [EMAIL PROTECTED]
---
arch/arm/configs/omap_3430sdp_defconfig | 17
arch/arm/mach-omap2/board-3430sdp.c | 64
2 files changed, 80 insertions(+), 1 deletion(-)
Index: linux-omap-2.6/arch/arm/configs/omap_3430sdp_defconfig
===
--- linux-omap-2.6.orig/arch/arm/configs/omap_3430sdp_defconfig 2008-06-26
17:24:52.0 +0530
+++ linux-omap-2.6/arch/arm/configs/omap_3430sdp_defconfig 2008-06-27
15:40:56.0 +0530
@@ -1061,8 +1061,23 @@
CONFIG_MMC_OMAP_HS=y
# CONFIG_MMC_SPI is not set
# CONFIG_NEW_LEDS is not set
+
+#
+# RTC interface
+#
CONFIG_RTC_LIB=y
-# CONFIG_RTC_CLASS is not set
+CONFIG_RTC_CLASS=y
+CONFIG_RTC_HCTOSYS=y
+CONFIG_RTC_HCTOSYS_DEVICE=rtc0
+CONFIG_RTC_INTF_SYSFS=y
+CONFIG_RTC_INTF_PROC=y
+CONFIG_RTC_INTF_DEV=y
+
+#
+# I2C RTC driver
+#
+CONFIG_RTC_DRV_TWL4030=y
+
# CONFIG_UIO is not set
#
Index: linux-omap-2.6/arch/arm/mach-omap2/board-3430sdp.c
===
--- linux-omap-2.6.orig/arch/arm/mach-omap2/board-3430sdp.c 2008-06-26
17:24:52.0 +0530
+++ linux-omap-2.6/arch/arm/mach-omap2/board-3430sdp.c 2008-06-27
15:49:37.0 +0530
@@ -40,9 +40,11 @@
#include asm/arch/keypad.h
#include asm/arch/dma.h
#include asm/arch/gpmc.h
+#include linux/i2c/twl4030-rtc.h
#include asm/io.h
#include asm/delay.h
+#include asm/arch/control.h
#defineSDP3430_SMC91X_CS 3
@@ -50,6 +52,8 @@
#define ENABLE_VAUX3_DEV_GRP 0x20
+#define TWL4030_MSECURE_GPIO 22
+
static struct resource sdp3430_smc91x_resources[] = {
[0] = {
.start = OMAP34XX_ETHR_START,
@@ -122,6 +126,63 @@
static int ts_gpio;
+#ifdef CONFIG_RTC_DRV_TWL4030
+static int twl4030_rtc_init(void)
+{
+ int ret = 0;
+
+ /* 3430ES2.0 doesn't have msecure/gpio-22 line connected to T2 */
+ if (is_device_type_gp() is_sil_rev_less_than(OMAP3430_REV_ES2_0)) {
+ u32 msecure_pad_config_reg = omap_ctrl_base_get() + 0xA3C;
+ int mux_mask = 0x04;
+ u16 tmp;
+
+ ret = omap_request_gpio(TWL4030_MSECURE_GPIO);
+ if (ret 0) {
+ printk(KERN_ERR twl4030_rtc_init: can't
+ reserve GPIO:%d !\n, TWL4030_MSECURE_GPIO);
+ goto out;
+ }
+ /*
+* TWL4030 will be in secure mode if msecure line from OMAP
+* is low. Make msecure line high in order to change the
+* TWL4030 RTC time and calender registers.
+*/
+ omap_set_gpio_direction(TWL4030_MSECURE_GPIO, 0);
+
+ tmp = omap_readw(msecure_pad_config_reg);
+ tmp = 0xF8; /* To enable mux mode 03/04 = GPIO_RTC */
+ tmp |= mux_mask;/* To enable mux mode 03/04 = GPIO_RTC */
+ omap_writew(tmp, msecure_pad_config_reg);
+
+ omap_set_gpio_dataout(TWL4030_MSECURE_GPIO, 1);
+ }
+out:
+ return ret;
+}
+
+static void twl4030_rtc_exit(void)
+{
+ if (is_device_type_gp()
+ is_sil_rev_less_than(OMAP3430_REV_ES2_0)) {
+ omap_free_gpio(TWL4030_MSECURE_GPIO);
+ }
+}
+
+static struct twl4030rtc_platform_data sdp3430_twl4030rtc_data = {
+ .init = twl4030_rtc_init,
+ .exit = twl4030_rtc_exit,
+};
+
+static struct platform_device sdp3430_twl4030rtc_device = {
+ .name = twl4030_rtc,
+ .id = -1,
+ .dev = {
+ .platform_data = sdp3430_twl4030rtc_data,
+ },
+};
+#endif
+
/**
* @brief ads7846_dev_init : Requests sets GPIO line for pen-irq
*
@@ -212,6 +273,9 @@
sdp3430_smc91x_device,
sdp3430_kp_device,
sdp3430_lcd_device,
+#ifdef CONFIG_RTC_DRV_TWL4030
+ sdp3430_twl4030rtc_device,
+#endif
};
static inline void __init sdp3430_init_smc91x(void)
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: FW: [PATCH 00/05] 34XX cpu idle patches - core off
On Fri, Jun 27, 2008 at 05:27:48PM +0530, ext Rajendra Nayak wrote: Hi Peter, I have the CORE off working on top of Jouni's latest patch set posted on l-o. 2 issues which I saw due to which CORE OFF was broken 1) Control module registers were redefined with the same name in control.h while my patches defined them in cpuidle34xx.h. In control.h they were just offsets and in cpuidle34xx.h they were defined as physical address. While saving the control module context, the offset was getting passed to omap_readl resulting in a crash. 2) GPIO clocks disable was moved into SRAM code in Jouni's patch, which would not get executed in OFF path. Thanks. I'm testing them now. 013-TIPATCH-fix-core-off.patch patches include/asm/arch/control.h which doesn't exist on a non-configured kernel. It's better to have the patch modify include/asm-arm/arch-omap/control.h. Cheers, Peter. -- goa is a state of mind -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3] ARM: OMAP3: Fix warnings in clock34xx.h
Fix warnings arch/arm/mach-omap2/clock34xx.h:178: warning: initialization makes pointer from integer without a cast arch/arm/mach-omap2/clock34xx.h:204: warning: initialization makes pointer from integer without a cast arch/arm/mach-omap2/clock34xx.h:229: warning: initialization makes pointer from integer without a cast Signed-off-by: Dirk Behme [EMAIL PROTECTED] Subject: ARM: OMAP3: Fix warnings in clock34xx.h From: Dirk Behme [EMAIL PROTECTED] Fix warnings arch/arm/mach-omap2/clock34xx.h:178: warning: initialization makes pointer from integer without a cast arch/arm/mach-omap2/clock34xx.h:204: warning: initialization makes pointer from integer without a cast arch/arm/mach-omap2/clock34xx.h:229: warning: initialization makes pointer from integer without a cast Signed-off-by: Dirk Behme [EMAIL PROTECTED] --- Changes in V3: Update to recent git. Index: linux-beagle/arch/arm/mach-omap2/clock34xx.h === --- linux-beagle.orig/arch/arm/mach-omap2/clock34xx.h +++ linux-beagle/arch/arm/mach-omap2/clock34xx.h @@ -53,14 +53,17 @@ static int omap3_noncore_dpll_set_rate(s #define DPLL_LOW_POWER_BYPASS 0x5 #define DPLL_LOCKED0x7 +#define _OMAP34XX_PRM_REGADDR(module, reg) \ + ((__force void __iomem *)(OMAP34XX_PRM_REGADDR((module), (reg + #define OMAP3430_PRM_CLKSRC_CTRL \ - OMAP34XX_PRM_REGADDR(OMAP3430_GR_MOD, 0x0070) + _OMAP34XX_PRM_REGADDR(OMAP3430_GR_MOD, OMAP3_PRM_CLKSRC_CTRL_OFFSET) #define OMAP3430_PRM_CLKSEL\ - OMAP34XX_PRM_REGADDR(OMAP3430_CCR_MOD, OMAP3_PRM_CLKSEL_OFFSET) + _OMAP34XX_PRM_REGADDR(OMAP3430_CCR_MOD, OMAP3_PRM_CLKSEL_OFFSET) #define OMAP3430_PRM_CLKOUT_CTRL \ - OMAP34XX_PRM_REGADDR(OMAP3430_CCR_MOD, OMAP3_PRM_CLKOUT_CTRL_OFFSET) + _OMAP34XX_PRM_REGADDR(OMAP3430_CCR_MOD, OMAP3_PRM_CLKOUT_CTRL_OFFSET) /* PRM CLOCKS */
Re: N810 power problems, bootloader upgrade, won't boot
On Fri, 2008.06.27, 179, Tony Lindgren wrote: * green [EMAIL PROTECTED] [080627 02:14]: I've been having power problems with my N810. These problems appear on startup (see three links below) and are supposedly fix by a bootloader upgrade, so I upgraded using the Maemo Diablo Fiasco image RX-44_DIABLO_4.2008.23-14_PR_COMBINED_MR0_ARM.bin. Perhaps this has fixed the problem, but it has caused another: now the N810 won't boot with the kernels I build, nor will it boot with the zImage-n8x0-2008-05-15 test kernel that Tony Lindgren provided recently. By not booting I mean that I see the NOKIA splash screen only; nothing else happens. Any ideas what I need to do? I'd rather not downgrade because of problems I've had with the device suddenly powering off when idle [3]. You need to leave out the machine id hack patch now, that's no longer needed as the diablo image seems to use the official machine id. Okay, that works. I should have thought of that myself. Thanks! signature.asc Description: Digital signature
gpio bug for 34xx
Hi,
I was just debugging some hang and noticed that the WAKEUPEN bits of gpio banks
was cleared out unexpectedly when doing a post mordem.
The array in 1466 will almost be certainly wrong on an OMAP3. It's probably a
bit off for OMAP2 for that matter. Things which are not wake up capable from
RET or OFF still can wake you up from a domain in INACTIVE mode.
1464 #if defined(CONFIG_ARCH_OMAP24XX) || defined(CONFIG_ARCH_OMAP34XX)
1465 if (bank-method == METHOD_GPIO_24XX) {
1466 static const u32 non_wakeup_gpios[] = {
1467 0xe203ffc0, 0x08700040
Regards,
Richard W.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
