Power domain addition.

Power domain addition.

[Woodruff, Richard]

Tony,

> Or put clock related PRCM registers to clock.c, power domain related
> registers to pm-domain.c and so on. I have pm-domain.c somewhat ready
> here and will push it as soon as I can.

I thought I might try this out quickly to see if anything obvious was
wrong with the flow.

I was surprised to find that when enabling power management the code
infinite loops in calling into SRAM to do an idle-wfi.  It appears that
somehow the mapped SRAM does not have execute permission.  The pm code
calls to SRAM and takes an exception, which resets (but not enough to
execute) and restarts the fault, ... back to the exception.

How did you test the code which was put in?  I'm not sure if this is a
timing thing which I hit or it wasn't tested against the latest kernel
which comes with a git pull.

Regards,
Richard W.

RE: Power domain addition.

[Woodruff, Richard]

[-- Attachment #1: Type: text/plain, Size: 2964 bytes --]


Tony,

Ok, by changing the size (1MB) and the type (MT_MEMORY) of the SRAM it
now boots again with power enabled.  Apparently you must be developing
on an older version of the kernel than is in git.  It seems MT_DEVICE
results in a no execute mapping.  Giving it a try before committing
would have saved some time.

Getting into the code a bit I see at few simple errors straight off.

-- The clearing of PM_WKST1_CORE, PM_WKS2_CORE, PM_WKST_WKUP need to
have 1's written to clear bits not 0's.  This will defeat your sleep
right out.  The code in our example clearly does this.

-- The code is doing debug printks after knocking out the uart clocks,
this is strange.  I see that prior to attempted sleep that the UART3
Iclk is enabled.  Was this left on for printing purposed?  I don't
believe with the uart on the 48mhz can shut down, you never know when a
start bit from someone else is coming in...

-- It doesn't seem like a proper wake up event path is being setup.  The
PRCM side enables are being done but not at the module levels.  After I
hacked the code a bit I was able to put the MPU into retention/clockstop
but it would not wake up as no wakeup route was completely enabled.
Modules meaning function level registers like GPIO and interrupt
controller need to be setup also.

-- By connecting with a emulator I was able to wake back up and
continue.  I added the debug /proc/pwr24xx file from my code and it was
apparent that the DSP moved from OFF back to the ON state.  It is likely
not set up correctly.

-- In the example code I use the full auto method, I don't see auto
state settings being done here (CM_CLKSTCTRL_CORE for instance)...

I didn't go though the code in detail just traced though it.  Sticking
to the format of the working code I supplied would make it much easier
for me to give comments. It seems several more bits are necessary before
it will begin to work in this code tree.  As it was I spent a couple
hours making this boot and tracing it.  No more time to spend now.

Regards,
Richard W.


> Tony,
> 
> > Or put clock related PRCM registers to clock.c, power domain related
> > registers to pm-domain.c and so on. I have pm-domain.c somewhat
ready
> > here and will push it as soon as I can.
> 
> I thought I might try this out quickly to see if anything obvious was
> wrong with the flow.
> 
> I was surprised to find that when enabling power management the code
> infinite loops in calling into SRAM to do an idle-wfi.  It appears
that
> somehow the mapped SRAM does not have execute permission.  The pm code
> calls to SRAM and takes an exception, which resets (but not enough to
> execute) and restarts the fault, ... back to the exception.
> 
> How did you test the code which was put in?  I'm not sure if this is a
> timing thing which I hit or it wasn't tested against the latest kernel
> which comes with a git pull.
> 
> Regards,
> Richard W.

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Power domain addition.

[Tony Lindgren]

Hi,

* Woodruff, Richard <r-woodruff2@ti.com> [060614 12:53]:
> 
> Tony,
> 
> Ok, by changing the size (1MB) and the type (MT_MEMORY) of the SRAM it
> now boots again with power enabled.  Apparently you must be developing
> on an older version of the kernel than is in git.  It seems MT_DEVICE
> results in a no execute mapping.  Giving it a try before committing
> would have saved some time.

Sorry, yes, I was working on it with some earlier kernel and am in
process of updating things.

Do you have a patch for your changes?
 
> Getting into the code a bit I see at few simple errors straight off.
> 
> -- The clearing of PM_WKST1_CORE, PM_WKS2_CORE, PM_WKST_WKUP need to
> have 1's written to clear bits not 0's.  This will defeat your sleep
> right out.  The code in our example clearly does this.

OK, thanks for noticing that, that's one step closer then.
 
> -- The code is doing debug printks after knocking out the uart clocks,
> this is strange.  I see that prior to attempted sleep that the UART3
> Iclk is enabled.  Was this left on for printing purposed?  I don't
> believe with the uart on the 48mhz can shut down, you never know when a
> start bit from someone else is coming in...

That should be fixed too.
 
> -- It doesn't seem like a proper wake up event path is being setup.  The
> PRCM side enables are being done but not at the module levels.  After I
> hacked the code a bit I was able to put the MPU into retention/clockstop
> but it would not wake up as no wakeup route was completely enabled.
> Modules meaning function level registers like GPIO and interrupt
> controller need to be setup also.

Hmmm, at least GPIO wake-up should work. I'll have to check if that
patch is missing something.
 
> -- By connecting with a emulator I was able to wake back up and
> continue.  I added the debug /proc/pwr24xx file from my code and it was
> apparent that the DSP moved from OFF back to the ON state.  It is likely
> not set up correctly.

Yes, currently you need to suspend DSP with a user space tool :(

I'd recommend leaving DSP out from Kconfig for now. The PM init
turns off DSP and IVA.
 
> -- In the example code I use the full auto method, I don't see auto
> state settings being done here (CM_CLKSTCTRL_CORE for instance)...

That might explain why the core retention does not happen.
 
> I didn't go though the code in detail just traced though it.  Sticking
> to the format of the working code I supplied would make it much easier
> for me to give comments. It seems several more bits are necessary before
> it will begin to work in this code tree.  As it was I spent a couple
> hours making this boot and tracing it.  No more time to spend now.

Thanks for taking a look at it. I tried to start with your code but it
was easier to start adding the components little by little.

Regards,

Tony

RE: Power domain addition.

[Amit Kucheria]

On Wed, 2006-06-14 at 14:52 -0500, ext Woodruff, Richard wrote:

> -- In the example code I use the full auto method, I don't see auto
> state settings being done here (CM_CLKSTCTRL_CORE for instance)...

Setting the AUTOSTAT_x bits in the CM_CLKSTCTRL_y registers to 1 is
_not_ setting it to full auto?

>From arch/arm/mach-omap2/pm-domain.c:

pmdomain_set_clock_autocontrol(AUTOSTAT_DSS | AUTOSTAT_L4 | AUTOSTAT_L3,
PM_CORE_OFFSET);

is supposed to to set it to full auto. If this is required to be 0
instead, then we have seriously misread that section of the TRM. :)

-- 
Amit Kucheria <amit.kucheria@nokia.com>
Nokia

RE: Power domain addition.

[Woodruff, Richard]

[-- Attachment #1: Type: text/plain, Size: 377 bytes --]


> Do you have a patch for your changes?

Just the hack I did for booting yesterday which is attached.  I tried
quickly to make a MT_MEMORY_COHERENT so it could use page tables not
just section entries but that required some changes elsewhere and I just
made it a section entry.

Also the USB msuspend signal is hooked up else you won't sleep.

Regards,
Richard W.

[-- Attachment #2: 242x-git-power_hack.diff --]
[-- Type: application/octet-stream, Size: 15862 bytes --]

diff -purN linux-omap/arch/arm/configs/omap_h4_2420_defconfig linux-omap-git/arch/arm/configs/omap_h4_2420_defconfig
--- linux-omap/arch/arm/configs/omap_h4_2420_defconfig	2006-06-14 09:55:00.000000000 -0500
+++ linux-omap-git/arch/arm/configs/omap_h4_2420_defconfig	2006-06-14 11:02:05.000000000 -0500
@@ -1,12 +1,14 @@
 #
 # Automatically generated make config: don't edit
-# Linux kernel version: 2.6.16-rc4-omap1
-# Wed Feb 22 02:25:55 2006
+# Linux kernel version: 2.6.17-rc6-omap1
+# Wed Jun 14 11:01:47 2006
 #
 CONFIG_ARM=y
 CONFIG_MMU=y
 CONFIG_RWSEM_GENERIC_SPINLOCK=y
+CONFIG_GENERIC_HWEIGHT=y
 CONFIG_GENERIC_CALIBRATE_DELAY=y
+CONFIG_VECTORS_BASE=0xffff0000
 
 #
 # Code maturity level options
@@ -28,6 +30,7 @@ CONFIG_BSD_PROCESS_ACCT=y
 CONFIG_SYSCTL=y
 # CONFIG_AUDIT is not set
 # CONFIG_IKCONFIG is not set
+# CONFIG_RELAY is not set
 CONFIG_INITRAMFS_SOURCE=""
 CONFIG_UID16=y
 CONFIG_CC_OPTIMIZE_FOR_SIZE=y
@@ -43,10 +46,6 @@ CONFIG_BASE_FULL=y
 CONFIG_FUTEX=y
 CONFIG_EPOLL=y
 CONFIG_SHMEM=y
-CONFIG_CC_ALIGN_FUNCTIONS=0
-CONFIG_CC_ALIGN_LABELS=0
-CONFIG_CC_ALIGN_LOOPS=0
-CONFIG_CC_ALIGN_JUMPS=0
 CONFIG_SLAB=y
 # CONFIG_TINY_SHMEM is not set
 CONFIG_BASE_SMALL=0
@@ -59,7 +58,6 @@ CONFIG_OBSOLETE_INTERMODULE=y
 CONFIG_MODULES=y
 CONFIG_MODULE_UNLOAD=y
 # CONFIG_MODULE_FORCE_UNLOAD is not set
-CONFIG_OBSOLETE_MODPARM=y
 CONFIG_MODVERSIONS=y
 CONFIG_MODULE_SRCVERSION_ALL=y
 CONFIG_KMOD=y
@@ -67,6 +65,7 @@ CONFIG_KMOD=y
 #
 # Block layer
 #
+# CONFIG_BLK_DEV_IO_TRACE is not set
 
 #
 # IO Schedulers
@@ -88,11 +87,13 @@ CONFIG_DEFAULT_IOSCHED="anticipatory"
 # CONFIG_ARCH_CLPS711X is not set
 # CONFIG_ARCH_CO285 is not set
 # CONFIG_ARCH_EBSA110 is not set
+# CONFIG_ARCH_EP93XX is not set
 # CONFIG_ARCH_FOOTBRIDGE is not set
 # CONFIG_ARCH_INTEGRATOR is not set
 # CONFIG_ARCH_IOP3XX is not set
 # CONFIG_ARCH_IXP4XX is not set
 # CONFIG_ARCH_IXP2000 is not set
+# CONFIG_ARCH_IXP23XX is not set
 # CONFIG_ARCH_L7200 is not set
 # CONFIG_ARCH_PXA is not set
 # CONFIG_ARCH_RPC is not set
@@ -128,6 +129,7 @@ CONFIG_OMAP_MUX_WARNINGS=y
 # CONFIG_OMAP_STI is not set
 CONFIG_OMAP_MPU_TIMER=y
 # CONFIG_OMAP_32K_TIMER is not set
+CONFIG_OMAP_DM_TIMER=y
 CONFIG_OMAP_LL_DEBUG_UART1=y
 # CONFIG_OMAP_LL_DEBUG_UART2 is not set
 # CONFIG_OMAP_LL_DEBUG_UART3 is not set
@@ -182,6 +184,7 @@ CONFIG_ARM_THUMB=y
 #
 # CONFIG_PREEMPT is not set
 # CONFIG_NO_IDLE_HZ is not set
+CONFIG_HZ=100
 # CONFIG_AEABI is not set
 # CONFIG_ARCH_DISCONTIGMEM_ENABLE is not set
 CONFIG_SELECT_MEMORY_MODEL=y
@@ -204,6 +207,11 @@ CONFIG_CMDLINE="root=/dev/ram0 rw consol
 # CONFIG_XIP_KERNEL is not set
 
 #
+# CPU Frequency scaling
+#
+# CONFIG_CPU_FREQ is not set
+
+#
 # Floating point emulation
 #
 
@@ -213,7 +221,7 @@ CONFIG_CMDLINE="root=/dev/ram0 rw consol
 CONFIG_FPE_NWFPE=y
 # CONFIG_FPE_NWFPE_XP is not set
 # CONFIG_FPE_FASTFPE is not set
-# CONFIG_VFP is not set
+CONFIG_VFP=y
 
 #
 # Userspace binary formats
@@ -226,7 +234,9 @@ CONFIG_BINFMT_MISC=y
 #
 # Power management options
 #
-# CONFIG_PM is not set
+CONFIG_PM=y
+CONFIG_PM_LEGACY=y
+# CONFIG_PM_DEBUG is not set
 # CONFIG_APM is not set
 
 #
@@ -259,12 +269,15 @@ CONFIG_IP_PNP_DHCP=y
 # CONFIG_INET_AH is not set
 # CONFIG_INET_ESP is not set
 # CONFIG_INET_IPCOMP is not set
+# CONFIG_INET_XFRM_TUNNEL is not set
 # CONFIG_INET_TUNNEL is not set
 CONFIG_INET_DIAG=y
 CONFIG_INET_TCP_DIAG=y
 # CONFIG_TCP_CONG_ADVANCED is not set
 CONFIG_TCP_CONG_BIC=y
 # CONFIG_IPV6 is not set
+# CONFIG_INET6_XFRM_TUNNEL is not set
+# CONFIG_INET6_TUNNEL is not set
 # CONFIG_NETFILTER is not set
 
 #
@@ -428,7 +441,6 @@ CONFIG_MTD_OMAP_NOR=y
 # CONFIG_MTD_SLRAM is not set
 # CONFIG_MTD_PHRAM is not set
 # CONFIG_MTD_MTDRAM is not set
-# CONFIG_MTD_BLKMTD is not set
 # CONFIG_MTD_BLOCK2MTD is not set
 
 #
@@ -633,7 +645,6 @@ CONFIG_WATCHDOG_NOWAYOUT=y
 CONFIG_OMAP_WATCHDOG=y
 # CONFIG_OMAP_RNG is not set
 # CONFIG_NVRAM is not set
-# CONFIG_RTC is not set
 # CONFIG_DTLK is not set
 # CONFIG_R3964 is not set
 
@@ -678,13 +689,11 @@ CONFIG_I2C_OMAP=y
 # CONFIG_SENSORS_PCF8574 is not set
 # CONFIG_SENSORS_PCA9539 is not set
 # CONFIG_SENSORS_PCF8591 is not set
-# CONFIG_SENSORS_RTC8564 is not set
 # CONFIG_TPS65010 is not set
 # CONFIG_SENSORS_TLV320AIC23 is not set
 CONFIG_GPIOEXPANDER_OMAP=y
 CONFIG_MENELAUS=y
 # CONFIG_SENSORS_MAX6875 is not set
-# CONFIG_RTC_X1205_I2C is not set
 # CONFIG_I2C_DEBUG_CORE is not set
 # CONFIG_I2C_DEBUG_ALGO is not set
 # CONFIG_I2C_DEBUG_BUS is not set
@@ -697,6 +706,11 @@ CONFIG_MENELAUS=y
 # CONFIG_SPI_MASTER is not set
 
 #
+# Dallas's 1-wire bus
+#
+# CONFIG_W1 is not set
+
+#
 # Hardware Monitoring support
 #
 # CONFIG_HWMON is not set
@@ -707,13 +721,23 @@ CONFIG_MENELAUS=y
 #
 
 #
-# Multimedia Capabilities Port drivers
+# LED devices
+#
+# CONFIG_NEW_LEDS is not set
+
+#
+# LED drivers
+#
+
+#
+# LED Triggers
 #
 
 #
 # Multimedia devices
 #
 # CONFIG_VIDEO_DEV is not set
+CONFIG_VIDEO_V4L2=y
 
 #
 # Digital Video Broadcasting Devices
@@ -728,6 +752,7 @@ CONFIG_FB=y
 # CONFIG_FB_CFB_COPYAREA is not set
 # CONFIG_FB_CFB_IMAGEBLIT is not set
 # CONFIG_FB_MACMODES is not set
+CONFIG_FB_FIRMWARE_EDID=y
 # CONFIG_FB_MODE_HELPERS is not set
 # CONFIG_FB_TILEBLITTING is not set
 # CONFIG_FB_S1D13XXX is not set
@@ -767,6 +792,7 @@ CONFIG_LOGO_LINUX_CLUT224=y
 #
 CONFIG_USB_ARCH_HAS_HCD=y
 CONFIG_USB_ARCH_HAS_OHCI=y
+# CONFIG_USB_ARCH_HAS_EHCI is not set
 # CONFIG_USB is not set
 
 #
@@ -784,11 +810,15 @@ CONFIG_USB_ARCH_HAS_OHCI=y
 CONFIG_MMC=y
 # CONFIG_MMC_DEBUG is not set
 CONFIG_MMC_BLOCK=y
-CONFIG_MMC_BLOCK_BROKEN_RFD=y
-CONFIG_MMC_BULKTRANSFER=y
 CONFIG_MMC_OMAP=y
 
 #
+# Real Time Clock
+#
+CONFIG_RTC_LIB=y
+# CONFIG_RTC_CLASS is not set
+
+#
 # Synchronous Serial Interfaces (SSI)
 #
 # CONFIG_OMAP_TSC2101 is not set
@@ -849,7 +879,6 @@ CONFIG_SYSFS=y
 CONFIG_TMPFS=y
 # CONFIG_HUGETLB_PAGE is not set
 CONFIG_RAMFS=y
-# CONFIG_RELAYFS_FS is not set
 # CONFIG_CONFIGFS_FS is not set
 
 #
@@ -991,6 +1020,7 @@ CONFIG_DEBUG_MUTEXES=y
 # CONFIG_DEBUG_FS is not set
 # CONFIG_DEBUG_VM is not set
 CONFIG_FRAME_POINTER=y
+# CONFIG_UNWIND_INFO is not set
 CONFIG_FORCED_INLINING=y
 # CONFIG_RCU_TORTURE_TEST is not set
 # CONFIG_DEBUG_USER is not set
diff -purN linux-omap/arch/arm/mach-omap2/irq.c linux-omap-git/arch/arm/mach-omap2/irq.c
--- linux-omap/arch/arm/mach-omap2/irq.c	2006-06-14 09:55:00.000000000 -0500
+++ linux-omap-git/arch/arm/mach-omap2/irq.c	2006-06-14 10:33:04.000000000 -0500
@@ -26,6 +26,11 @@
 #define INTC_MIR_CLEAR0	0x0088
 #define INTC_MIR_SET0	0x008c
 
+#define sync_p_port_write()	\
+	({ int dv = 0;	\
+		__asm__ __volatile__ ("mcr p15, 0, %0, c7, c10, 4" : : "r" (dv));	\
+	})
+
 /*
  * OMAP2 has a number of different interrupt controllers, each interrupt
  * controller is identified as its own "bank". Register definitions are
@@ -61,6 +66,7 @@ static struct omap_irq_bank {
 static void omap_ack_irq(unsigned int irq)
 {
 	omap_writel(0x1, irq_banks[0].base_reg + INTC_CONTROL);
+	sync_p_port_write();
 }
 
 static void omap_mask_irq(unsigned int irq)
@@ -74,6 +80,7 @@ static void omap_mask_irq(unsigned int i
 	}
 
 	omap_writel(1 << irq, irq_banks[0].base_reg + INTC_MIR_SET0 + offset);
+	sync_p_port_write();
 }
 
 static void omap_unmask_irq(unsigned int irq)
@@ -87,7 +94,8 @@ static void omap_unmask_irq(unsigned int
 	}
 
 	omap_writel(1 << irq, irq_banks[0].base_reg + INTC_MIR_CLEAR0 + offset);
-}
+	sync_p_port_write();
+ }
 
 static void omap_mask_ack_irq(unsigned int irq)
 {
diff -purN linux-omap/arch/arm/mach-omap2/pm.c linux-omap-git/arch/arm/mach-omap2/pm.c
--- linux-omap/arch/arm/mach-omap2/pm.c	2006-06-14 09:55:00.000000000 -0500
+++ linux-omap-git/arch/arm/mach-omap2/pm.c	2006-06-14 14:17:06.000000000 -0500
@@ -307,9 +307,9 @@ static int omap2_pm_suspend(void)
 	pmdomain_set_autoidle();
 
 	/* Clear old wake-up events */
-	PM_WKST1_CORE = 0;
-	PM_WKST2_CORE = 0;
-	PM_WKST_WKUP = 0;
+	PM_WKST1_CORE = 0xffffffff;  // need to be more careful, reserved bits can be evil
+	PM_WKST2_CORE = 0xffffffff;
+	PM_WKST_WKUP = 0xffffffff;
 
 	/* Enable wake-up events */
 	PM_WKEN1_CORE = (1 << 22) | (1 << 21);	/* UART1 & 2 */
@@ -324,7 +324,7 @@ static int omap2_pm_suspend(void)
 	CM_ICLKEN3_CORE = 0;
 	CM_ICLKEN4_CORE = 0;
 
-	omap2_pm_debug("Status before suspend");
+//	omap2_pm_debug("Status before suspend");
 
 	/* Must wait for serial buffers to clear */
 	mdelay(200);
@@ -406,3 +406,169 @@ int __init omap2_pm_init(void)
 }
 
 __initcall(omap2_pm_init);
+
+#include <linux/proc_fs.h>
+#include <linux/seq_file.h>
+
+static void *pwr24xx_start(struct seq_file *m, loff_t *pos)
+{
+	return *pos < 1 ? (void *)1 : NULL;
+}
+
+static void *pwr24xx_next(struct seq_file *m, void *v, loff_t *pos)
+{
+	++*pos;
+	return NULL;
+}
+
+static void pwr24xx_stop(struct seq_file *m, void *v)
+{
+}
+
+int pwr24xx_show(struct seq_file *m, void *vv)
+{
+	char *s[4] = {"ON ", "RET", "ERR", "OFF"};
+	char *r[2] = {"RUNNING", "IN RESET"};
+	u32 n, c, p, v, i;
+
+	/* Current power domain state: Previous  Current  Next */
+	seq_printf(m,"\nPower Domain states:\n");
+	seq_printf(m,"Domain: Previous  Currrent  Next\n");
+	n = PM_PWSTCTRL_MPU; c = p = PM_PWSTST_MPU; p >>= 4;
+	seq_printf(m,"MPU:    %s       %s       %s\n", s[p&3], s[c&3], s[n&3]);
+	n = PM_PWSTCTRL_DSP; c = p = PM_PWSTST_DSP; p >>= 4;
+	seq_printf(m,"DSP:    %s       %s       %s\n", s[p&3], s[c&3], s[n&3]);
+	n = PM_PWSTCTRL_GFX; c = p = PM_PWSTST_GFX; p >>= 4;
+	seq_printf(m,"GFX:    %s       %s       %s\n", s[p&3], s[c&3], s[n&3]);
+	n = PM_PWSTCTRL_CORE; c = p = PM_PWSTST_CORE; p >>= 4;
+	seq_printf(m,"COR:    %s       %s       %s\n", s[p&3], s[c&3], s[n&3]);
+	if(cpu_is_omap2430()){
+		n = PM_PWSTCTRL_MDM; c = p = PM_PWSTST_MDM; p >>= 4;
+		seq_printf(m,"MDM:    %s       %s       %s\n", s[p&3], s[c&3], s[n&3]);
+	}
+	seq_printf(m,"WKP:    %s       %s       %s\n\n", s[0], s[0], s[0]);
+
+	/* Reset state of domains */
+	seq_printf(m,"Domain Reset state:\n");
+	v = RM_RSTCTRL_DSP;
+	i = (1 && (v & 3));
+	seq_printf(m,"DSP: %s\n", r[i]);
+	if(cpu_is_omap2420()){
+		i = (1 && (v & (1 << 8)));
+		seq_printf(m,"IVA: %s\n", r[i]);
+	} else {
+		i = (1 && (RM_RSTCTRL_MDM & 3));
+		seq_printf(m,"MDM: %s\n", r[i]);
+	}
+	i = (1 && (RM_RSTCTRL_GFX & 1));
+	seq_printf(m,"GFX: %s\n\n", r[i]);
+
+	/* Clock states of domains */
+	seq_printf(m,"Device Clocks:\n");
+
+	// CM_IDLEST_GFX ADD
+
+	v = CM_ICLKEN1_CORE;
+	seq_printf(m,"CM_ICLKEN1_CORE:   0x%08x\n", v);
+	v = CM_FCLKEN1_CORE;
+	seq_printf(m,"CM_FCLKEN1_CORE:   0x%08x\n", v);
+	v = CM_AUTOIDLE1_CORE;
+	seq_printf(m,"CM_AUTOIDLE1_CORE: 0x%08x\n", v);
+	v = CM_IDLEST1_CORE;
+	seq_printf(m,"CM_IDLEST1_CORE:   0x%08x\n\n", v);
+
+	v = CM_ICLKEN2_CORE;
+	seq_printf(m,"CM_ICLKEN2_CORE:   0x%08x\n", v);
+	v = CM_FCLKEN2_CORE;
+	seq_printf(m,"CM_FCLKEN2_CORE:   0x%08x\n", v);
+	v = CM_AUTOIDLE1_CORE;
+	seq_printf(m,"CM_AUTOIDLE2_CORE: 0x%08x\n", v);
+	v = CM_IDLEST2_CORE;
+	seq_printf(m,"CM_IDLEST2_CORE:   0x%08x\n\n", v);
+
+	v = CM_ICLKEN1_CORE;
+	seq_printf(m,"CM_ICLKEN4_CORE:   0x%08x\n", v);
+	v = CM_AUTOIDLE4_CORE;
+	seq_printf(m,"CM_AUTOIDLE4_CORE: 0x%08x\n", v);
+	v = CM_IDLEST4_CORE;
+	seq_printf(m,"CM_IDLEST4_CORE:   0x%08x\n\n", v);
+
+	v = CM_ICLKEN_DSP;
+	seq_printf(m,"CM_ICLKEN_DSP:   0x%08x\n", v);
+	v = CM_FCLKEN_DSP;
+	seq_printf(m,"CM_FCLKEN_DSP:   0x%08x\n", v);
+	v = CM_AUTOIDLE_DSP;
+	seq_printf(m,"CM_AUTOIDLE_DSP: 0x%08x\n", v);
+	v = CM_IDLEST_DSP;
+	seq_printf(m,"CM_IDLEST_DSP:   0x%08x\n\n", v);
+
+	v = CM_ICLKEN_GFX;
+	seq_printf(m,"CM_ICLKEN_GFX:   0x%08x\n", v);
+	v = CM_FCLKEN_GFX;
+	seq_printf(m,"CM_FCLKEN_GFX:   0x%08x\n", v);
+	v = CM_IDLEST_GFX;
+	seq_printf(m,"CM_IDLEST_GFX:   0x%08x\n\n", v);
+
+	if(cpu_is_omap2430()){
+		v = CM_ICLKEN_MDM;
+		seq_printf(m,"CM_ICLKEN_MDM:   0x%08x\n", v);
+		v = CM_FCLKEN_MDM;
+		seq_printf(m,"CM_FCLKEN_MDM:   0x%08x\n", v);
+		v = CM_AUTOIDLE_MDM;
+		seq_printf(m,"CM_AUTOIDLE_MDM: 0x%08x\n", v);
+		v = CM_IDLEST_MDM;
+		seq_printf(m,"CM_IDLEST_MDM:   0x%08x\n\n", v);
+	}
+
+	v = CM_ICLKEN_WKUP;
+	seq_printf(m,"CM_ICLKEN_WKUP:   0x%08x\n", v);
+	v = CM_FCLKEN_WKUP;
+	seq_printf(m,"CM_FCLKEN_WKUP:   0x%08x\n", v);
+	v = CM_AUTOIDLE_WKUP;
+	seq_printf(m,"CM_AUTOIDLE_WKUP: 0x%08x\n", v);
+	v = CM_IDLEST_WKUP;
+	seq_printf(m,"CM_IDLEST_WKUP:   0x%08x\n\n", v);
+
+	v = CM_CLKEN_PLL;
+	seq_printf(m,"CM_CLKEN_PLL:    0x%08x\n", v);
+	v = CM_AUTOIDLE_PLL;
+	seq_printf(m,"CM_AUTOIDLE_PLL: 0x%08x\n", v);
+	v = CM_IDLEST_CKGEN;
+	seq_printf(m,"CM_IDLEST_CKGEN: 0x%08x\n\n", v);
+
+	return 0;
+}
+
+static struct seq_operations pwr24xx_op = {
+	.start =	pwr24xx_start,
+	.next =		pwr24xx_next,
+	.stop =		pwr24xx_stop,
+	.show =		pwr24xx_show
+};
+
+static int pwr24xx_open(struct inode *inode, struct file *file)
+{
+	return seq_open(file, &pwr24xx_op);
+}
+
+static struct file_operations proc_pwr24xx_operations = {
+	.open		= pwr24xx_open,
+	.read		= seq_read,
+	.llseek		= seq_lseek,
+	.release	= seq_release,
+};
+
+int __init omap_pwr24xx_init(void)
+{
+	struct proc_dir_entry *entry;
+
+	entry = create_proc_entry("pwromap24xx", 0, NULL);
+	if (entry)
+		entry->proc_fops = &proc_pwr24xx_operations;
+
+	return 0;
+
+}
+arch_initcall(omap_pwr24xx_init);
+
+
diff -purN linux-omap/arch/arm/mach-omap2/pm-domain.c linux-omap-git/arch/arm/mach-omap2/pm-domain.c
--- linux-omap/arch/arm/mach-omap2/pm-domain.c	2006-06-14 09:55:00.000000000 -0500
+++ linux-omap-git/arch/arm/mach-omap2/pm-domain.c	2006-06-14 14:34:03.000000000 -0500
@@ -19,6 +19,7 @@
 #include <linux/module.h>
 #include <linux/init.h>
 #include <linux/clk.h>
+#include <linux/delay.h>
 
 #include <asm/io.h>
 
@@ -240,12 +241,14 @@ void pmdomain_set_autoidle(void)
 	pmdomain_set_powerstate(FORCESTATE | POWERSTATE_OFF, PM_DSP_OFFSET);
 	pmdomain_set_powerstate(FORCESTATE | POWERSTATE_OFF, PM_GFX_OFFSET);
 
-#if 0
-	/* REVISIT: Internal USB needs special handling */
-	force_standby_usb();
-	if (cpu_is_omap2430())
-		force_hsmmc();
-	sdram_self_refresh_on_idle_req(1);
+#if 1
+ CM_FCLKEN2_CORE = 1;
+ CM_ICLKEN2_CORE = 1;
+ udelay(100);
+ CONTROL_DEVCONF |= 0x00008000;
+ CM_FCLKEN2_CORE = 0;
+ CM_ICLKEN2_CORE = 0;
+ 	//sdram_self_refresh_on_idle_req(1);
 #endif
 
 	/* Enable clock auto control for all domains.
diff -purN linux-omap/arch/arm/plat-omap/sram.c linux-omap-git/arch/arm/plat-omap/sram.c
--- linux-omap/arch/arm/plat-omap/sram.c	2006-06-14 13:21:08.000000000 -0500
+++ linux-omap-git/arch/arm/plat-omap/sram.c	2006-06-14 13:27:54.000000000 -0500
@@ -158,7 +158,7 @@ static struct map_desc omap_sram_io_desc
 	{	/* .length gets filled in at runtime */
 		.virtual	= OMAP1_SRAM_VA,
 		.pfn		= __phys_to_pfn(OMAP1_SRAM_PA),
-		.type		= MT_DEVICE
+		.type		= MT_MEMORY
 	}
 };
 
@@ -185,8 +185,10 @@ void __init omap_map_sram(void)
 		omap_sram_io_desc[0].pfn = __phys_to_pfn(base);
 	}
 
-	omap_sram_io_desc[0].length = (omap_sram_size + PAGE_SIZE-1)/PAGE_SIZE;
-	omap_sram_io_desc[0].length *= PAGE_SIZE;
+//	omap_sram_io_desc[0].length = (omap_sram_size + PAGE_SIZE-1)/PAGE_SIZE;
+//	omap_sram_io_desc[0].length *= PAGE_SIZE;
+	omap_sram_io_desc[0].length = 1024*1024;  /* Make sure a section descritor is used */
+
 	iotable_init(omap_sram_io_desc, ARRAY_SIZE(omap_sram_io_desc));
 
 	printk(KERN_INFO "SRAM: Mapped pa 0x%08lx to va 0x%08lx size: 0x%lx\n",
diff -purN linux-omap/include/net/irda/irlmp.h linux-omap-git/include/net/irda/irlmp.h
--- linux-omap/include/net/irda/irlmp.h	2006-06-14 11:31:29.000000000 -0500
+++ linux-omap-git/include/net/irda/irlmp.h	2006-06-14 10:43:15.000000000 -0500
@@ -188,9 +188,11 @@ struct irlmp_cb {
 	hashbin_t *cachelog;	/* Current discovery log */
 
 	int running;
-	__u8 align;
-	__u16 align2;
-	__u16_host_order hints; /* Hint bits */
+
+	/* problem not GCC3.4 word aligned & causes alignment exception */
+	__u8 dummy;
+	__u16 dummy2;
+	__u16_host_order hints; /* Hint bits ? */
 };
 
 /* Prototype declarations */

[-- Attachment #3: Type: text/plain, Size: 0 bytes --]

Re: Power domain addition.

[Tony Lindgren]

* Woodruff, Richard <r-woodruff2@ti.com> [060615 16:14]:
> 
> > Do you have a patch for your changes?
> 
> Just the hack I did for booting yesterday which is attached.  I tried
> quickly to make a MT_MEMORY_COHERENT so it could use page tables not
> just section entries but that required some changes elsewhere and I just
> made it a section entry.

OK, I've pushed that chunk along with Komal's smc91x patches so H4 boots
and works with PM and cpufreq.
 
> Also the USB msuspend signal is hooked up else you won't sleep.

I'll take a look at the PM stuff soon once I have something else out of
the way.

Regards,

Tony

Re: Power domain addition.

[Komal Shah]

--- Tony Lindgren <tony@atomide.com> wrote:
> 
> OK, I've pushed that chunk along with Komal's smc91x patches so H4
> boots
> and works with PM and cpufreq.
>  

Well, I have tried the latest kernel, but with MT_MEMORY and no PM
support kernel stops here:

----------snip------------------
<5>Linux version 2.6.17-omap1-gea5858eb-dirty (komal@everest) (gcc
version 3.4.0
 20040409 (CodeSourcery ARM Q1A 2004)) #49 Wed Jun 21 23:43:30 IST 2006
CPU: Some Random V6 Processor [4107b362] revision 2 (ARMv6TEJ)
Machine: OMAP2420 H4 board
Memory policy: ECC disabled, Data cache writeback
<7>On node 0 totalpages: 32768
<7>  DMA zone: 32768 pages, LIFO batch:7
<6>OMAP2420
<4>BUG: map for 0x4020f000 at 0xd0000000 can not be mapped using pages,
ignoring
.
<6>SRAM: Mapped pa 0x4020f000 to va 0xd0000000 size: 0x100000
----------snip------------------

And with MT_DEVICE and PM support, it stops after IrDA driver
initialzing message:

----------snip------------------
Linux version 2.6.17-omap1-gea5858eb-dirty (komal@everest) (gcc version
3.4.0 20
040409 (CodeSourcery ARM Q1A 2004)) #52 Wed Jun 21 23:59:23 IST 2006
CPU: Some Random V6 Processor [4107b362] revision 2 (ARMv6TEJ)
Machine: OMAP2420 H4 board
Memory policy: ECC disabled, Data cache writeback
OMAP2420
SRAM: Mapped pa 0x4020f000 to va 0xd0000000 size: 0x100000
CPU0: D VIPT write-back cache
CPU0: I cache: 32768 bytes, associativity 4, 32 byte lines, 256 sets
CPU0: D cache: 32768 bytes, associativity 4, 32 byte lines, 256 sets
Built 1 zonelists
Kernel command line: console=ttyS0,115200n8 noinitrd root=/dev/nfs rw
nfsroot=10
.203.97.52:/pub/fs/git,rsize=1024,wsize=1024 init=/linuxrc ip=dhcp
Clocking rate (Crystal/DPLL/MPU): 12.0/600/300 MHz
clock.c: Enable for dpll_ck without enable code
GPMC revision 1.0
IRQ: Found an INTC at 0x480fe000 (revision 1.0) with 96 interrupts
Total of 96 interrupts on 1 active controller
OMAP24xx GPIO hardware version 1.5
Muxing M15_24XX_GPIO92 (0x4800010a): 0x03 -> 0x03
PID hash table entries: 1024 (order: 10, 4096 bytes)
Console: colour dummy device 80x30
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Memory: 128MB 0MB = 128MB total
Memory: 126848KB available (2308K code, 522K data, 108K init)
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
NET: Registered protocol family 16
Muxing K15_24XX_UART3_TX (0x48000118): 0x00 -> 0x00
Muxing K14_24XX_UART3_RX (0x48000119): 0x00 -> 0x00
Muxing M19_24XX_I2C1_SCL (0x48000111): 0x00 -> 0x00
Muxing L15_24XX_I2C1_SDA (0x48000112): 0x00 -> 0x00
Muxing T19_24XX_KBR0 (0x48000106): 0x0f -> 0x1b
Muxing R19_24XX_KBR1 (0x48000107): 0x0f -> 0x1b
Muxing V18_24XX_KBR2 (0x48000139): 0x07 -> 0x1b
Muxing M21_24XX_KBR3 (0x480000c9): 0x0f -> 0x1b
Muxing E5__24XX_KBR4 (0x48000138): 0x0f -> 0x1b
Muxing B3__24XX_KBR5 (0x48000030): 0x03 -> 0x1b
Muxing AA4_24XX_KBC2 (0x480000e7): 0x03 -> 0x03
Muxing B13_24XX_KBC6 (0x48000110): 0x03 -> 0x03
Muxing R20_24XX_KBC0 (0x48000108): 0x0f -> 0x03
Muxing M14_24XX_KBC1 (0x48000109): 0x1f -> 0x03
Muxing V17_24XX_KBC3 (0x48000135): 0x07 -> 0x03
Muxing P21_24XX_KBC4 (0x480000ca): 0x0f -> 0x03
Muxing L14_24XX_KBC5 (0x4800010f): 0x0f -> 0x03
OMAP DMA hardware revision 1.0
Initializing OMAP McBSP system
Muxing Y15_24XX_MCBSP2_CLKX (0x48000124): 0x0f -> 0x09
Muxing R14_24XX_MCBSP2_FSX (0x48000125): 0x0f -> 0x09
Muxing W15_24XX_MCBSP2_DR (0x48000126): 0x0f -> 0x09
Muxing V15_24XX_MCBSP2_DX (0x48000127): 0x0f -> 0x09
Muxing V14_24XX_GPIO117 (0x48000128): 0x0f -> 0x0b
Muxing W14_24XX_SYS_CLKOUT (0x48000137): 0x0f -> 0x18
omapdsp: unsupported omap architecture.
USB: No board-specific platform config found
i2c_omap i2c_omap.1: bus 0 rev3.1 at 100 kHz
NET: Registered protocol family 23
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 4096 (order: 2, 16384 bytes)
TCP bind hash table entries: 2048 (order: 1, 8192 bytes)
TCP: Hash tables configured (established 4096 bind 2048)
TCP reno registered
Power Management for TI OMAP.
NetWinder Floating Point Emulator V0.97 (double precision)
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
JFFS2 version 2.2. (NAND) (C) 2001-2003 Red Hat, Inc.
Initializing Cryptographic API
io scheduler noop registered
io scheduler anticipatory registered (default)
io scheduler deadline registered
io scheduler cfq registered
omapfb: configured for panel h4
omapfb-dispc: version 1.0
Console: switching to colour frame buffer device 30x40
omapfb: initialized vram=159744 pixclock 6250 kHz hfreq 18.3 kHz vfreq
58.6 Hz
OMAP Watchdog Timer: initial timeout 60 sec
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing
enabled
serial8250.0: ttyS0 at MMIO 0x4806a000 (irq = 72) is a ST16654
serial8250.0: ttyS1 at MMIO 0x4806c000 (irq = 73) is a ST16654
serial8250.0: ttyS2 at MMIO 0x4806e000 (irq = 74) is a ST16654
RAMDISK driver initialized: 16 RAM disks of 16384K size 1024 blocksize
loop: loaded (max 8 devices)
smc91x.c: v1.1, sep 22 2004 by Nicolas Pitre <nico@cam.org>
eth0: SMC91C94 (rev 9) at c8851300 IRQ 252 [nowait]
eth0: Ethernet addr: 00:50:c2:27:1e:ab
OMAP IrDA driver initializing

----------snip------------------

But with MT_DEVICE and no PM support kernel boots fine with NFS.


---Komal Shah
http://komalshah.blogspot.com/

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

RE: Power domain addition.

[Woodruff, Richard]

Yes, see below for the reasons.  I guess the basic point is it still
won't boot with out an Irda fix up.  I only highlighted the problem and
supplied a rough hack.  Whoever looks after Irda should get it fixed, or
have it removed from the default configuration.  It is possible its just
a compiler bug which then make it a little less clear.  The bug is from
a union structure of a u8 and u16 generating only byte aligned code
which is a no-no when used with a lrdh.

> Well, I have tried the latest kernel, but with MT_MEMORY and no PM
> support kernel stops here:
> 
> ----------snip------------------
> <5>Linux version 2.6.17-omap1-gea5858eb-dirty (komal@everest) (gcc
> version 3.4.0
>  20040409 (CodeSourcery ARM Q1A 2004)) #49 Wed Jun 21 23:43:30 IST
2006
> CPU: Some Random V6 Processor [4107b362] revision 2 (ARMv6TEJ)
> Machine: OMAP2420 H4 board
> Memory policy: ECC disabled, Data cache writeback
> <7>On node 0 totalpages: 32768
> <7>  DMA zone: 32768 pages, LIFO batch:7
> <6>OMAP2420
> <4>BUG: map for 0x4020f000 at 0xd0000000 can not be mapped using
pages,
> ignoring
> .
> <6>SRAM: Mapped pa 0x4020f000 to va 0xd0000000 size: 0x100000

This is because you can't just change MT_DEVICE to MT_MEMORY with out
changing the mapping size.  Templates are not given for PTE generation
only section entries.  That is why I changed the size to 1024*1024. As
indicated I tried a quick extension to make my own type but found it
must also change the code which sets the EXEC bit and didn't want to do
that, so just increased the to something which would generate what I
want.


> ----------snip------------------
> 
> And with MT_DEVICE and PM support, it stops after IrDA driver
> initialzing message:

This is due to the misalignment in the Irda structure.  Your root file
system must have a script which activates this path as mine does.

This is why I added the hack to the irlamp structure.  Else it would not
boot.

Regards,
Richard W.

RE: Power domain addition.

[Komal Shah]

--- "Woodruff, Richard" <r-woodruff2@ti.com> wrote:

> Yes, see below for the reasons.  I guess the basic point is it still
> won't boot with out an Irda fix up.  I only highlighted the problem
> and
> supplied a rough hack.  Whoever looks after Irda should get it fixed,
> or
> have it removed from the default configuration. 
> It is possible its
> just
> a compiler bug which then make it a little less clear.  The bug is
> from
> a union structure of a u8 and u16 generating only byte aligned code
> which is a no-no when used with a lrdh.

I can submit the patch for removing IrDA from the defconfig, but before
that I will build the latest omap git tree, with code-sourcery 2005Q1B
release and will see that it stops at the same point or not.

> 
> This is because you can't just change MT_DEVICE to MT_MEMORY with out
> changing the mapping size.  Templates are not given for PTE
> generation
> only section entries.  That is why I changed the size to 1024*1024.
> As
> indicated I tried a quick extension to make my own type but found it
> must also change the code which sets the EXEC bit and didn't want to
> do
> that, so just increased the to something which would generate what I
> want.

I had just compiled and boot the latest pull from omap git tree, and
_not_ changed anything, so mapping size was 1024*1024 as per that
commited patch. But I think you had tested that setup with power
management enabled, which works in my case except IrDA.

---Komal Shah
http://komalshah.blogspot.com/

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

RE: Power domain addition.

[Woodruff, Richard]

> > a union structure of a u8 and u16 generating only byte aligned code
> > which is a no-no when used with a lrdh.
> 
> I can submit the patch for removing IrDA from the defconfig, but
before
> that I will build the latest omap git tree, with code-sourcery 2005Q1B
> release and will see that it stops at the same point or not.

One other possible bit which I didn't look for was how the structure
base address was assigned.  If it was automatic or if some had manually
assigned a pointer. If it was automatic then its likely a compiler bug,
if someone just assigned it with out aligning it that would be something
which could be fixed in code.

rkw

Re: Power domain addition.

[Tony Lindgren]

[-- Attachment #1: Type: text/plain, Size: 1727 bytes --]

* Komal Shah <komal_shah802003@yahoo.com> [060621 08:14]:
> --- "Woodruff, Richard" <r-woodruff2@ti.com> wrote:
> 
> > Yes, see below for the reasons.  I guess the basic point is it still
> > won't boot with out an Irda fix up.  I only highlighted the problem
> > and
> > supplied a rough hack.  Whoever looks after Irda should get it fixed,
> > or
> > have it removed from the default configuration. 
> > It is possible its
> > just
> > a compiler bug which then make it a little less clear.  The bug is
> > from
> > a union structure of a u8 and u16 generating only byte aligned code
> > which is a no-no when used with a lrdh.
> 
> I can submit the patch for removing IrDA from the defconfig, but before
> that I will build the latest omap git tree, with code-sourcery 2005Q1B
> release and will see that it stops at the same point or not.
> 
> > 
> > This is because you can't just change MT_DEVICE to MT_MEMORY with out
> > changing the mapping size.  Templates are not given for PTE
> > generation
> > only section entries.  That is why I changed the size to 1024*1024.
> > As
> > indicated I tried a quick extension to make my own type but found it
> > must also change the code which sets the EXEC bit and didn't want to
> > do
> > that, so just increased the to something which would generate what I
> > want.
> 
> I had just compiled and boot the latest pull from omap git tree, and
> _not_ changed anything, so mapping size was 1024*1024 as per that
> commited patch. But I think you had tested that setup with power
> management enabled, which works in my case except IrDA.

Here's some stuff that was missing from my earlier patch. Still no
wake-up though. Oh well, have to look at it a bit later.

Regards,

Tony

[-- Attachment #2: patch-omap24xx-suspend-hacks --]
[-- Type: text/plain, Size: 2141 bytes --]

--- a/arch/arm/mach-omap2/sleep.S
+++ b/arch/arm/mach-omap2/sleep.S
@@ -30,6 +30,13 @@ #include <asm/arch/pm.h>
 #define A_32KSYNC_CR_V		IO_ADDRESS(OMAP_TIMER32K_BASE+0x10)
 #define A_PRCM_VOLTCTRL_V	IO_ADDRESS(OMAP24XX_PRCM_BASE+0x50)
 #define A_PRCM_CLKCFG_CTRL_V	IO_ADDRESS(OMAP24XX_PRCM_BASE+0x80)
+#define A_PM_PWSTCTR_MPU_V	IO_ADDRESS(OMAP24XX_PRCM_BASE+0x1e4)
+#define A_CM_FCLKEN1_CORE_V	IO_ADDRESS(OMAP24XX_PRCM_BASE+0x200)
+#define A_CM_FCLKEN2_CORE_V	IO_ADDRESS(OMAP24XX_PRCM_BASE+0x204)
+#define A_CM_ICLKEN1_CORE_V	IO_ADDRESS(OMAP24XX_PRCM_BASE+0x210)
+#define A_CM_ICLKEN2_CORE_V	IO_ADDRESS(OMAP24XX_PRCM_BASE+0x214)
+#define A_CM_ICLKEN3_CORE_V	IO_ADDRESS(OMAP24XX_PRCM_BASE+0x218)
+#define A_CM_ICLKEN4_CORE_V	IO_ADDRESS(OMAP24XX_PRCM_BASE+0x21c)
 #define A_CM_CLKEN_PLL_V	IO_ADDRESS(OMAP24XX_PRCM_BASE+0x500)
 #define A_CM_IDLEST_CKGEN_V	IO_ADDRESS(OMAP24XX_PRCM_BASE+0x520)
 #define A_CM_CLKSEL1_PLL_V	IO_ADDRESS(OMAP24XX_PRCM_BASE+0x540)
@@ -91,6 +98,12 @@ ENTRY(omap24xx_idle_loop_suspend_sz)
 ENTRY(omap24xx_cpu_suspend)
 	stmfd	sp!, {r0 - r12, lr}	@ save registers on stack
 	mov	r3, #0x0		@ clear for mrc call
+
+	ldr	r8, A_CM_FCLKEN2_CORE	@ addr of register to save
+	ldr	r9, [r8]		@ load value
+	str	r9, SAVE_REG1		@ save value
+	str	r3, [r8]		@ reset register
+
 	mcr	p15, 0, r3, c7, c10, 4	@ memory barrier, hope SDR/DDR finished
 	nop
 	nop
@@ -123,9 +136,18 @@ loop:
 loop2:
 	subs	r5, r5, #0x1
 	bne	loop2
+
+	ldr	r8, A_CM_FCLKEN2_CORE	@ addr of fck
+	ldr	r9, SAVE_REG1		@ load saved value
+	str	r9, [r8]		@ restore saved value
+
 	/* resume*/
 	ldmfd	sp!, {r0 - r12, pc}	@ restore regs and return
 
+SAVE_REG1:
+	.word 0x0
+A_CM_FCLKEN2_CORE:
+	.word A_CM_FCLKEN2_CORE_V
 A_SDRC_POWER:
 	.word A_SDRC_POWER_V
 A_SDRC0:
--- a/arch/arm/plat-omap/gpio.c
+++ b/arch/arm/plat-omap/gpio.c
@@ -1060,6 +1060,7 @@ #ifdef CONFIG_ARCH_OMAP24XX
 		if (bank->method == METHOD_GPIO_24XX) {
 			__raw_writel(0x00000000, bank->base + OMAP24XX_GPIO_IRQENABLE1);
 			__raw_writel(0xffffffff, bank->base + OMAP24XX_GPIO_IRQSTATUS1);
+			__raw_writel(0x00000014, bank->base + OMAP24XX_GPIO_SYSCONFIG);
 
 			gpio_count = 32;
 		}

[-- Attachment #3: Type: text/plain, Size: 0 bytes --]