RE: PM branch rebased to 2.6.29... for real this time
> -Original Message- > From: Kevin Hilman [mailto:khil...@deeprootsystems.com] > Sent: Thursday, April 02, 2009 9:37 PM > To: Kim Kyuwon > Cc: Premi, Sanjeev; linux-omap@vger.kernel.org; Nayak, Rajendra > Subject: Re: PM branch rebased to 2.6.29... for real this time > > Yes, this locking problem requires Rajendra's patchset which > needs to be > updated for the PM branch. I will send the updated patch set on the latest PM branch maybe later today. > > Kevin > > Kim Kyuwon wrote: > > Hi Kevin, Sanjeev, > > > > I'm having the same problem. > > > > when clk_set_rate() is invoked in omap_cpu_init() as shown below: > > > > clk_set_rate(mpu_clk, policy->cpuinfo.max_freq * 1000); > > > > It acquires the clocks mutex by the next statement. > > > > mutex_lock(&clocks_mutex); > > > > But after invoking arch_clock->clk_set_rate() in the middle of > > clk_set_rate(), clock_set_rate() is invoked again. So > deadlock occurs > > due to mutex_lock() in clock_set_rate(). > > > > I think setting the default governor can not help this deadlock. > > > > Regards, > > Kyuwon > > > > On Thu, Apr 2, 2009 at 3:46 AM, Kevin Hilman > > wrote: > >> "Premi, Sanjeev" writes: > >> > >> [...] > >> > >>>> Sounds to me like CPUfreq is changing frequencies during > bootup. Did > >>>> you select ondemand as the default CPUfreq governor? > >>> [sp] Yes. This is what I feel too. Only I was not clear > why the process > >>> gets stuck at WFI. Haven't been able to debug further. So far... > >>> > >>>> If so, can you try with performance as the default governor. > >>> [sp] It was performance governor only. > >>> > >>>> If you're already using performance, then u-boot is > setting a slower > >>>> speed and CPUfreq may decide to change it during boot. > >>> [sp] That is the case. > >>> > >> Can you try setting the default governor to userspace so > that no DVFS > >> changes will happen during boot? > >> > >> Kevin > >> -- > >> To unsubscribe from this list: send the line "unsubscribe > linux-omap" in > >> the body of a message to majord...@vger.kernel.org > >> More majordomo info at http://vger.kernel.org/majordomo-info.html > >> > > > > > > > > > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PM branch rebased to 2.6.29... for real this time
Yes, this locking problem requires Rajendra's patchset which needs to be updated for the PM branch. Kevin Kim Kyuwon wrote: Hi Kevin, Sanjeev, I'm having the same problem. when clk_set_rate() is invoked in omap_cpu_init() as shown below: clk_set_rate(mpu_clk, policy->cpuinfo.max_freq * 1000); It acquires the clocks mutex by the next statement. mutex_lock(&clocks_mutex); But after invoking arch_clock->clk_set_rate() in the middle of clk_set_rate(), clock_set_rate() is invoked again. So deadlock occurs due to mutex_lock() in clock_set_rate(). I think setting the default governor can not help this deadlock. Regards, Kyuwon On Thu, Apr 2, 2009 at 3:46 AM, Kevin Hilman wrote: "Premi, Sanjeev" writes: [...] Sounds to me like CPUfreq is changing frequencies during bootup. Did you select ondemand as the default CPUfreq governor? [sp] Yes. This is what I feel too. Only I was not clear why the process gets stuck at WFI. Haven't been able to debug further. So far... If so, can you try with performance as the default governor. [sp] It was performance governor only. If you're already using performance, then u-boot is setting a slower speed and CPUfreq may decide to change it during boot. [sp] That is the case. Can you try setting the default governor to userspace so that no DVFS changes will happen during boot? Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PM branch rebased to 2.6.29... for real this time
Hi Kevin, Sanjeev, I'm having the same problem. when clk_set_rate() is invoked in omap_cpu_init() as shown below: clk_set_rate(mpu_clk, policy->cpuinfo.max_freq * 1000); It acquires the clocks mutex by the next statement. mutex_lock(&clocks_mutex); But after invoking arch_clock->clk_set_rate() in the middle of clk_set_rate(), clock_set_rate() is invoked again. So deadlock occurs due to mutex_lock() in clock_set_rate(). I think setting the default governor can not help this deadlock. Regards, Kyuwon On Thu, Apr 2, 2009 at 3:46 AM, Kevin Hilman wrote: > "Premi, Sanjeev" writes: > > [...] > >>> Sounds to me like CPUfreq is changing frequencies during bootup. Did >>> you select ondemand as the default CPUfreq governor? >> >> [sp] Yes. This is what I feel too. Only I was not clear why the process >> gets stuck at WFI. Haven't been able to debug further. So far... >> >>> If so, can you try with performance as the default governor. >> >> [sp] It was performance governor only. >> >>> If you're already using performance, then u-boot is setting a slower >>> speed and CPUfreq may decide to change it during boot. >> >> [sp] That is the case. >> > > Can you try setting the default governor to userspace so that no DVFS > changes will happen during boot? > > Kevin > -- > To unsubscribe from this list: send the line "unsubscribe linux-omap" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- 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: PM branch rebased to 2.6.29... for real this time
"Premi, Sanjeev" writes: [...] >> Sounds to me like CPUfreq is changing frequencies during bootup. Did >> you select ondemand as the default CPUfreq governor? > > [sp] Yes. This is what I feel too. Only I was not clear why the process > gets stuck at WFI. Haven't been able to debug further. So far... > >> If so, can you try with performance as the default governor. > > [sp] It was performance governor only. > >> If you're already using performance, then u-boot is setting a slower >> speed and CPUfreq may decide to change it during boot. > > [sp] That is the case. > Can you try setting the default governor to userspace so that no DVFS changes will happen during boot? Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: PM branch rebased to 2.6.29... for real this time
> -Original Message- > From: Kevin Hilman [mailto:khil...@deeprootsystems.com] > Sent: Wednesday, April 01, 2009 10:42 AM > To: Premi, Sanjeev > Cc: linux-omap@vger.kernel.org; Nayak, Rajendra > Subject: Re: PM branch rebased to 2.6.29... for real this time > > "Premi, Sanjeev" writes: > > >> -Original Message- > >> From: linux-omap-ow...@vger.kernel.org > >> [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Kevin Hilman > >> Sent: Thursday, March 26, 2009 4:26 AM > >> To: linux-omap@vger.kernel.org > >> Subject: PM branch rebased to 2.6.29... for real this time > >> > >> Hello, > >> > >> The previous rebase was actually to 2.6.29-rc8. Now that 2.6.29 is > >> out, I've rebased the PM brach onto linux-omap HEAD just after the > >> 2.6.29 merge. > >> > >> Minimal retention and off-mode on Beagle and RX51. > > > > Another problem that I found on OMAP3EVM: > > > > When I compiled in CPUidle and CPUfreq (over omap3_evm_defconfig), > > the kernel did not boot-up. The last few statements are: > > There are known problems with CPUfreq on top of the new clock > notifiers series. > > I am waiting for Rajendra to re-send his series which removes the virt > clocks on top of the latest PM branch. > > > <3>clock: dpll5_ck failed transition to 'locked' > > clock: dpll5_ck failed transition to 'locked' > > <6>Disabling unused clock "dpll4_m6x2_ck" > > Disabling unused clock "dpll4_m6x2_ck" > > <6>Disabling unused clock "dpll3_m3x2_ck" > > Disabling unused clock "dpll3_m3x2_ck" > > <6>Disabling unused clock "sys_clkout1" > > Disabling unused clock "sys_clkout1" > > > > The PC is at the WFI statement. > > > > Tried other combinations as well: > > > > 1) only CPUidle enabled - okay. > > 2) only CPUfreq enabled - not okay. > > > > Sounds to me like CPUfreq is changing frequencies during bootup. Did > you select ondemand as the default CPUfreq governor? [sp] Yes. This is what I feel too. Only I was not clear why the process gets stuck at WFI. Haven't been able to debug further. So far... > If so, can you try with performance as the default governor. [sp] It was performance governor only. > If you're already using performance, then u-boot is setting a slower > speed and CPUfreq may decide to change it during boot. [sp] That is the case. > If so, can you > try the userspace governor as the default governor. This should > prevent any automatic CPUFreq changes during bootup. > > Kevin > > > > > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PM branch rebased to 2.6.29... for real this time
"Premi, Sanjeev" writes: >> -Original Message- >> From: linux-omap-ow...@vger.kernel.org >> [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Kevin Hilman >> Sent: Thursday, March 26, 2009 4:26 AM >> To: linux-omap@vger.kernel.org >> Subject: PM branch rebased to 2.6.29... for real this time >> >> Hello, >> >> The previous rebase was actually to 2.6.29-rc8. Now that 2.6.29 is >> out, I've rebased the PM brach onto linux-omap HEAD just after the >> 2.6.29 merge. >> >> Minimal retention and off-mode on Beagle and RX51. > > Another problem that I found on OMAP3EVM: > > When I compiled in CPUidle and CPUfreq (over omap3_evm_defconfig), > the kernel did not boot-up. The last few statements are: There are known problems with CPUfreq on top of the new clock notifiers series. I am waiting for Rajendra to re-send his series which removes the virt clocks on top of the latest PM branch. > <3>clock: dpll5_ck failed transition to 'locked' > clock: dpll5_ck failed transition to 'locked' > <6>Disabling unused clock "dpll4_m6x2_ck" > Disabling unused clock "dpll4_m6x2_ck" > <6>Disabling unused clock "dpll3_m3x2_ck" > Disabling unused clock "dpll3_m3x2_ck" > <6>Disabling unused clock "sys_clkout1" > Disabling unused clock "sys_clkout1" > > The PC is at the WFI statement. > > Tried other combinations as well: > > 1) only CPUidle enabled - okay. > 2) only CPUfreq enabled - not okay. > Sounds to me like CPUfreq is changing frequencies during bootup. Did you select ondemand as the default CPUfreq governor? If so, can you try with performance as the default governor. If you're already using performance, then u-boot is setting a slower speed and CPUfreq may decide to change it during boot. If so, can you try the userspace governor as the default governor. This should prevent any automatic CPUFreq changes during bootup. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PM branch rebased to 2.6.29
Russ Dill writes: [...] > > r...@beagleboard:/sys/power# echo 1 > clocks_off_while_idle > r...@beagleboard:/sys/power# echo 1 > enable_off_mode > r...@beagleboard:/sys/power# echo 1 > voltage_off_while_idle > r...@beagleboard:/sys/power# echo mem > state > PM: Syncing filesystems ... done. > Freezing user space processes ... (elapsed 0.00 seconds) done. > Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done. > Suspending console(s) (use no_console_suspend to debug) > omapfb omapfb: timeout waiting for FRAME DONE > Successfully put all powerdomains to target state > Restarting tasks ... done. > > Neato :) This is still with all the user processes running an with a > NAND filesystem. I'm still getting rather high ~8...@5v power > consumption, so I'll need to further investigate what rails the > twl4030 is actually turning off. Great! glad it worked for you. The kernel has some work to do to be sure that *everything* is properly init'd to allow proper idle states. Until then, unfortunately we have to rely on more gentle bootloaders. And FWIW, on my Beagle, I've never seen < 80mA either, but I haven't done any further digging. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PM branch rebased to 2.6.29
On Tue, Mar 31, 2009 at 4:33 PM, Kevin Hilman wrote: > Russ Dill writes: > >>> Russ, >>> >>> With the dump below, what was the output after you resumed? Which >>> powerdomains did not hit their target state? It looks like PER and >>> CORE did not hit target state. >> >> yes, yes, and yes. >> >>> Also, you didn't mention what hardware you're using or your .config or >>> your bootloader etc. All of these play an important role. >> >> Beagleboard B7, X-Loader 1.41, U-Boot 1.3.3 > > Not familiar with the all u-boot versions for this board, but is this > u-boot out of Steve Sakoman's tree? I had lots of problems with the > TI bootloader leaving Beagle in a strange state and switched to using > the one from Steve's tree. I have X-Loader 1.41 and: > > U-Boot 2009.01-rc1-00067-g8c6db17 (Jan 15 2009 - 16:31:00) I've updated: U-Boot 2009.01-dirty (Feb 19 2009 - 12:22:31) >>> >>> Here is at least one problem. >>> >>> Offset 0x40 is CM_CLKSEL_WKUP, and bit 0 shows which clock is the >>> source clock for GPTIMER1. Here, bit 0 is 1 which means SYS_CLK >>> is used as the timer source. >>> >>> Based on this, you must have: >>> >>> System Type --> TI OMAP Implementations --> System Timer >>> >>> set to 'MPU timer'. Please change to 32k timer. Using MPU timer will >>> keep timers not in WKUP powerdomain (which is all of them except GPT1) >>> running across suspend, preventing PER from hitting RET. >>> >>> Using the 32k timer only uses GPT1 and sources it from the 32k clock, both >>> of which are in the WKUP powerdomain. >> >> Nope, I have the following kernel message: >> >> OMAP clockevent source: GPTIMER12 at 32768 Hz >> >> and the following Kconfig options (also see the attached .config) > > Right, I forgot Beagle is using GPT12, not GPT1. nevermind. > >> Texas Instruments X-Loader 1.41 >> Starting OS Bootloader... >> >> >> U-Boot 1.3.3 (Jul 10 2008 - 16:33:09) > > First recommendation is to upgrade your bootloder: > > http://elinux.org/BeagleBoard#U-Boot > > The earlier bootloaders seem to be blindly enabling reserved bits in > some of the PM registers which can leave the chip in an undefined > state. > >> OMAP3530-GP rev 2, CPU-OPP2 L3-165MHz >> OMAP3 Beagle Board + LPDDR/NAND >> DRAM: 128 MB >> NAND: 256 MiB >> In: serial >> Out: serial >> Err: serial >> Audio Tone on Speakers ... complete >> Hit any key to stop autoboot: 0 >> >> NAND read: device 0 offset 0x28, size 0x40 >> 4194304 bytes read: OK >> ## Booting kernel from Legacy Image at 8000 ... >> Image Name: Linux-2.6.29-omap1-pm >> Image Type: ARM Linux Kernel Image (uncompressed) >> Data Size: 1476992 Bytes = 1.4 MB >> Load Address: 80008000 >> Entry Point: 80008000 >> Verifying Checksum ... OK >> Loading Kernel Image ... OK >> OK >> >> Starting kernel ... >> >> Uncompressing >> Linux >> done, booting the kern. >> Linux version 2.6.29-omap1-pm (r...@russ-laptop) (gcc version 4.3.1 >> (GCC) ) #47 PREEMPT Tue Mar 31 14:13:51 MST 2009 >> CPU: ARMv7 Processor [411fc083] revision 3 (ARMv7), cr=10c5387f >> CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache >> Machine: OMAP3 Beagle Board >> Memory policy: ECC disabled, Data cache writeback >> OMAP3430 ES3.0 >> SRAM: Mapped pa 0x4020 to va 0xd700 size: 0x10 >> Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32512 >> Kernel command line: console=ttyS2,115200n8 root=/dev/mtdblock4 >> rootfstype=jffs2 rw g_ether.host_addr=B6:A3:A1:7D:8F:F0 >> omapfb.mode=dvi:126 >> Unknown boot option `g_ether.host_addr=B6:A3:A1:7D:8F:F0': ignoring >> Unknown boot option `omapfb.mode=dvi:1280x720M-16': ignoring >> Clocking rate (Crystal/DPLL/ARM core): 26.0/332/500 MHz >> Reprogramming SDRC >> GPMC revision 5.0 >> IRQ: Found an INTC at 0xd820 (revision 4.0) with 96 interrupts >> Total of 96 interrupts on 1 active controller >> OMAP34xx GPIO hardware version 2.5 >> PID hash table entries: 512 (order: 9, 2048 bytes) >> OMAP clockevent source: GPTIMER12 at 32768 Hz >> 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 = 128MB total >> Memory: 126648KB available (2692K code, 299K data, 96K init) >> Calibrating delay loop... 491.57 BogoMIPS (lpj=1921024) >> Mount-cache hash table entries: 512 >> CPU: Testing write buffer coherency: ok >> net_namespace: 544 bytes >> regulator: core version 0.5 >> NET: Registered protocol family 16 >> Found NAND on CS0 >> Registering NAND on CS0 >> OMAP DMA hardware revision 4.0 >> bio: create slab at 0 >> i2c_omap i2c_omap.1: bus 1 rev3.12 at 2600 kHz >> twl4030: PIH (irq 7) chaining IRQs 368..375 >> twl4030: power (irq 373) chaining IRQs 376..383 >> twl4030: gpio (irq 368) chaining IRQs 384..401 >> beagle_twl_gpio_setup:145 >> twl4030_mmc_init:324 >> twl4030_mmc_
Re: PM branch rebased to 2.6.29
Russ Dill writes: >> Russ, >> >> With the dump below, what was the output after you resumed? Which >> powerdomains did not hit their target state? It looks like PER and >> CORE did not hit target state. > > yes, yes, and yes. > >> Also, you didn't mention what hardware you're using or your .config or >> your bootloader etc. All of these play an important role. > > Beagleboard B7, X-Loader 1.41, U-Boot 1.3.3 Not familiar with the all u-boot versions for this board, but is this u-boot out of Steve Sakoman's tree? I had lots of problems with the TI bootloader leaving Beagle in a strange state and switched to using the one from Steve's tree. I have X-Loader 1.41 and: U-Boot 2009.01-rc1-00067-g8c6db17 (Jan 15 2009 - 16:31:00) >> >> Here is at least one problem. >> >> Offset 0x40 is CM_CLKSEL_WKUP, and bit 0 shows which clock is the >> source clock for GPTIMER1. Here, bit 0 is 1 which means SYS_CLK >> is used as the timer source. >> >> Based on this, you must have: >> >> System Type --> TI OMAP Implementations --> System Timer >> >> set to 'MPU timer'. Please change to 32k timer. Using MPU timer will >> keep timers not in WKUP powerdomain (which is all of them except GPT1) >> running across suspend, preventing PER from hitting RET. >> >> Using the 32k timer only uses GPT1 and sources it from the 32k clock, both >> of which are in the WKUP powerdomain. > > Nope, I have the following kernel message: > > OMAP clockevent source: GPTIMER12 at 32768 Hz > > and the following Kconfig options (also see the attached .config) Right, I forgot Beagle is using GPT12, not GPT1. nevermind. > Texas Instruments X-Loader 1.41 > Starting OS Bootloader... > > > U-Boot 1.3.3 (Jul 10 2008 - 16:33:09) First recommendation is to upgrade your bootloder: http://elinux.org/BeagleBoard#U-Boot The earlier bootloaders seem to be blindly enabling reserved bits in some of the PM registers which can leave the chip in an undefined state. > OMAP3530-GP rev 2, CPU-OPP2 L3-165MHz > OMAP3 Beagle Board + LPDDR/NAND > DRAM: 128 MB > NAND: 256 MiB > In:serial > Out: serial > Err: serial > Audio Tone on Speakers ... complete > Hit any key to stop autoboot: 0 > > NAND read: device 0 offset 0x28, size 0x40 > 4194304 bytes read: OK > ## Booting kernel from Legacy Image at 8000 ... >Image Name: Linux-2.6.29-omap1-pm >Image Type: ARM Linux Kernel Image (uncompressed) >Data Size:1476992 Bytes = 1.4 MB >Load Address: 80008000 >Entry Point: 80008000 >Verifying Checksum ... OK >Loading Kernel Image ... OK > OK > > Starting kernel ... > > Uncompressing > Linux > done, booting the kern. > Linux version 2.6.29-omap1-pm (r...@russ-laptop) (gcc version 4.3.1 > (GCC) ) #47 PREEMPT Tue Mar 31 14:13:51 MST 2009 > CPU: ARMv7 Processor [411fc083] revision 3 (ARMv7), cr=10c5387f > CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache > Machine: OMAP3 Beagle Board > Memory policy: ECC disabled, Data cache writeback > OMAP3430 ES3.0 > SRAM: Mapped pa 0x4020 to va 0xd700 size: 0x10 > Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32512 > Kernel command line: console=ttyS2,115200n8 root=/dev/mtdblock4 > rootfstype=jffs2 rw g_ether.host_addr=B6:A3:A1:7D:8F:F0 > omapfb.mode=dvi:126 > Unknown boot option `g_ether.host_addr=B6:A3:A1:7D:8F:F0': ignoring > Unknown boot option `omapfb.mode=dvi:1280x720M-16': ignoring > Clocking rate (Crystal/DPLL/ARM core): 26.0/332/500 MHz > Reprogramming SDRC > GPMC revision 5.0 > IRQ: Found an INTC at 0xd820 (revision 4.0) with 96 interrupts > Total of 96 interrupts on 1 active controller > OMAP34xx GPIO hardware version 2.5 > PID hash table entries: 512 (order: 9, 2048 bytes) > OMAP clockevent source: GPTIMER12 at 32768 Hz > 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 = 128MB total > Memory: 126648KB available (2692K code, 299K data, 96K init) > Calibrating delay loop... 491.57 BogoMIPS (lpj=1921024) > Mount-cache hash table entries: 512 > CPU: Testing write buffer coherency: ok > net_namespace: 544 bytes > regulator: core version 0.5 > NET: Registered protocol family 16 > Found NAND on CS0 > Registering NAND on CS0 > OMAP DMA hardware revision 4.0 > bio: create slab at 0 > i2c_omap i2c_omap.1: bus 1 rev3.12 at 2600 kHz > twl4030: PIH (irq 7) chaining IRQs 368..375 > twl4030: power (irq 373) chaining IRQs 376..383 > twl4030: gpio (irq 368) chaining IRQs 384..401 > beagle_twl_gpio_setup:145 > twl4030_mmc_init:324 > twl4030_mmc_init:339 > regulator: VMMC1: 1850 <--> 3150 mV normal standby > regulator: VDAC: 1800 mV normal standby > regulator: VUSB1V5: 1500 <--> 0 mV normal standby > regulator: VUSB1V8: 1800 <--> 0 mV normal standby > regulator: VUSB3V1: 3100
Re: PM branch rebased to 2.6.29
Russ Dill writes: > On Mon, Mar 30, 2009 at 11:43 AM, Kevin Hilman > wrote: >> Russ Dill writes: >> >>> On Mon, Mar 30, 2009 at 3:08 AM, Premi, Sanjeev wrote: >> [...] I had found that two drivers that could prevent clocks_off are USB and DSS because of the way they use clk_enable(). Can you try building without theses drivers just for verification? >>> >>> Building without dss makes things worse: >>> >>> Powerdomain (dss_pwrdm) didn't enter target state 0 >>> >>> Maybe by looking at what the dss driver is doing I can get core and >>> per to turn off. >> >> Russ, >> >> Can you try with the latest HEAD of PM branch. After suspend/resume, >> do >> >> # cat /debug/pm_debug/registers/1 >> >> and post results to list. We can then see the exact state of PM >> registers before going into WFI. Russ, With the dump below, what was the output after you resumed? Which powerdomains did not hit their target state? It looks like PER and CORE did not hit target state. Also, you didn't mention what hardware you're using or your .config or your bootloader etc. All of these play an important role. > r...@beagleboard:/sys# cat /debug/pm_debug/registers/1 > MOD: CM_IVA2 (48014000) > 04 => 0037 20 => 0001 34 => 0001 40 => 0009680c > 44 => 0001 48 => 0003 > MOD: CM_OCP (48004800) > 00 => 0010 10 => 0001 > MOD: CM_MPU (48004900) > 04 => 0037 24 => 0001 34 => 0001 40 => 0011f40c > 44 => 0001 48 => 0003 4c => 0001 > MOD: CM_CORE (48004a00) > 10 => 0042 20 => ffbd 24 => 001f 28 => 000d > 30 => fed9 34 => 001f 38 => 000c 40 => 030a > 48 => 003f 4c => 0003 > MOD: CM_SGX (48004b00) > 20 => 0001 48 => 0003 > MOD: CM_WKUP (48004c00) > 10 => 000e 20 => 02f1 30 => 003f 40 => 0015 Here is at least one problem. Offset 0x40 is CM_CLKSEL_WKUP, and bit 0 shows which clock is the source clock for GPTIMER1. Here, bit 0 is 1 which means SYS_CLK is used as the timer source. Based on this, you must have: System Type --> TI OMAP Implementations --> System Timer set to 'MPU timer'. Please change to 32k timer. Using MPU timer will keep timers not in WKUP powerdomain (which is all of them except GPT1) running across suspend, preventing PER from hitting RET. Using the 32k timer only uses GPT1 and sources it from the 32k clock, both of which are in the WKUP powerdomain. > MOD: CM_CCR (48004d00) > 00 => f8311037 04 => 0017 20 => 0201 30 => 0009 > 34 => 0001 40 => 094c0c00 44 => 0001b00c 48 => 0009 > 50 => 0001 70 => 0003 > MOD: CM_DSS (48004e00) > 20 => 0003 30 => 0001 40 => 1006 48 => 0003 > MOD: CM_CAM (48004f00) > 20 => 0001 30 => 0001 40 => 0004 48 => 0003 > MOD: CM_PER (48005000) > 10 => 0003e000 20 => 1fff 30 => 0003 40 => 00ff > 44 => 0006 48 => 0003 4c => 0001 > MOD: CM_EMU (48005100) > 40 => 03020a50 48 => 0002 4c => 0001 > MOD: CM_NEON (48005300) > 48 => 0003 > MOD: CM_USB (48005400) > 20 => 0003 30 => 0001 48 => 0003 > MOD: PRM_IVA2 (48316000) > 50 => 0007 e0 => 00ff0f04 f8 => 0007 > MOD: PRM_OCP (48306800) > 04 => 0010 14 => 0001 1c => 0201 > MOD: PRM_MPU (48306900) > 58 => 0005 d4 => 0012 e0 => 00030104 e4 => 00c7 > e8 => 00c7 > MOD: PRM_CORE (48306a00) > 58 => 0301 a0 => c33ffe18 a4 => c33ffe18 a8 => c33ffe18 > e0 => 000f0304 e4 => 00f7 e8 => 00f7 f0 => 0004 > f4 => 0004 f8 => 0004 > MOD: PRM_SGX (48306b00) > e0 => 00030104 > MOD: PRM_WKUP (48306c00) > a0 => 010b a4 => 010b > MOD: PRM_CCR (48306d00) > 40 => 0003 > MOD: PRM_DSS (48306e00) > 58 => 0005 a0 => 0001 e0 => 00030104 > MOD: PRM_CAM (48306f00) > 58 => 0001 e0 => 00030104 > MOD: PRM_PER (48307000) > 58 => 0001 a0 => 0003efff a4 => 0003efff a8 => 0003efff > c8 => 0007 e0 => 00030104 e4 => 0007 e8 => 0007 > MOD: PRM_EMU (48307100) > 58 => 0005 e4 => 0103 > MOD: PRM_GLBL (48307200) > 20 => 00120012 24 => 0001 2c => 301e1e30 30 => 2c1e1e2c > 34 => 0012 38 => 0018 54 => 1006 58 => 0001 > 60 => 000e 64 => 0050 70 => 0088 90 => 0fff0fff > 94 => 00ff 98 => 00ff 9c => 0002 a0 => 00ff > c4 => 0001 e4 => 0001 > MOD: PRM_NEON (48307300) > 58 => 0005 c8 => 0002 e0 => 0004 e4 => 0003 > e8 => 0003 > MOD: PRM_USB (48307400) > 58 => 0001 a0 => 0001 a4 => 0001 a8 => 0001 > e0 => 00030104 > > >> Also, post dump of >> > > r...@beagleboard:/sys# cat /debug/pm_debug/count > usbhost_pwrdm (OFF),OFF:1,RET:1,INA:0,ON:1 > sgx_pwrdm (OFF),OFF:1,RET:0,INA:0,ON:1 > per_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1 > dss_pwrdm (ON),OFF:2,RET:0,INA:0,ON:3 > cam_pwrdm (OFF),OFF:1,RET
RE: PM branch rebased to 2.6.29... for real this time
> -Original Message- > From: linux-omap-ow...@vger.kernel.org > [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Kevin Hilman > Sent: Thursday, March 26, 2009 4:26 AM > To: linux-omap@vger.kernel.org > Subject: PM branch rebased to 2.6.29... for real this time > > Hello, > > The previous rebase was actually to 2.6.29-rc8. Now that 2.6.29 is > out, I've rebased the PM brach onto linux-omap HEAD just after the > 2.6.29 merge. > > Minimal retention and off-mode on Beagle and RX51. Another problem that I found on OMAP3EVM: When I compiled in CPUidle and CPUfreq (over omap3_evm_defconfig), the kernel did not boot-up. The last few statements are: <3>clock: dpll5_ck failed transition to 'locked' clock: dpll5_ck failed transition to 'locked' <6>Disabling unused clock "dpll4_m6x2_ck" Disabling unused clock "dpll4_m6x2_ck" <6>Disabling unused clock "dpll3_m3x2_ck" Disabling unused clock "dpll3_m3x2_ck" <6>Disabling unused clock "sys_clkout1" Disabling unused clock "sys_clkout1" The PC is at the WFI statement. Tried other combinations as well: 1) only CPUidle enabled - okay. 2) only CPUfreq enabled - not okay. Best regards, Sanjeev > > Kevin > -- > To unsubscribe from this list: send the line "unsubscribe > linux-omap" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PM branch rebased to 2.6.29
BTW, the 9 clocks active on per are:
gpio{2-6}_ick
per_l4_ick
uart3_ick
uart3_fck
per_48m_fck
During sleep, I get (for the per_clkdm only):
clockdomain: clkdm per_clkdm: removing clk uart3_ick
clockdomain: clkdm per_clkdm: removing clk per_48m_fck
clockdomain: clkdm per_clkdm: removing clk uart3_fck
clockdomain: clkdm per_clkdm: adding clk uart3_ick
clockdomain: clkdm per_clkdm: adding clk uart3_fck
clockdomain: clkdm per_clkdm: adding clk per_48m_fck
So it looks like to me that the per_clkdm isn't shutting down because
of per_l4_ick and the gpio interface clocks.
On Mon, Mar 30, 2009 at 4:01 PM, Russ Dill wrote:
> On Mon, Mar 30, 2009 at 11:43 AM, Kevin Hilman
> wrote:
>> Russ Dill writes:
>>
>>> On Mon, Mar 30, 2009 at 3:08 AM, Premi, Sanjeev wrote:
>> [...]
I had found that two drivers that could prevent clocks_off are
USB and DSS because of the way they use clk_enable().
Can you try building without theses drivers just for verification?
>>>
>>> Building without dss makes things worse:
>>>
>>> Powerdomain (dss_pwrdm) didn't enter target state 0
>>>
>>> Maybe by looking at what the dss driver is doing I can get core and
>>> per to turn off.
>>
>> Russ,
>>
>> Can you try with the latest HEAD of PM branch. After suspend/resume,
>> do
>>
>> # cat /debug/pm_debug/registers/1
>>
>> and post results to list. We can then see the exact state of PM
>> registers before going into WFI.
>
> r...@beagleboard:/sys# cat /debug/pm_debug/registers/1
> MOD: CM_IVA2 (48014000)
> 04 => 0037 20 => 0001 34 => 0001 40 => 0009680c
> 44 => 0001 48 => 0003
> MOD: CM_OCP (48004800)
> 00 => 0010 10 => 0001
> MOD: CM_MPU (48004900)
> 04 => 0037 24 => 0001 34 => 0001 40 => 0011f40c
> 44 => 0001 48 => 0003 4c => 0001
> MOD: CM_CORE (48004a00)
> 10 => 0042 20 => ffbd 24 => 001f 28 => 000d
> 30 => fed9 34 => 001f 38 => 000c 40 => 030a
> 48 => 003f 4c => 0003
> MOD: CM_SGX (48004b00)
> 20 => 0001 48 => 0003
> MOD: CM_WKUP (48004c00)
> 10 => 000e 20 => 02f1 30 => 003f 40 => 0015
> MOD: CM_CCR (48004d00)
> 00 => f8311037 04 => 0017 20 => 0201 30 => 0009
> 34 => 0001 40 => 094c0c00 44 => 0001b00c 48 => 0009
> 50 => 0001 70 => 0003
> MOD: CM_DSS (48004e00)
> 20 => 0003 30 => 0001 40 => 1006 48 => 0003
> MOD: CM_CAM (48004f00)
> 20 => 0001 30 => 0001 40 => 0004 48 => 0003
> MOD: CM_PER (48005000)
> 10 => 0003e000 20 => 1fff 30 => 0003 40 => 00ff
> 44 => 0006 48 => 0003 4c => 0001
> MOD: CM_EMU (48005100)
> 40 => 03020a50 48 => 0002 4c => 0001
> MOD: CM_NEON (48005300)
> 48 => 0003
> MOD: CM_USB (48005400)
> 20 => 0003 30 => 0001 48 => 0003
> MOD: PRM_IVA2 (48316000)
> 50 => 0007 e0 => 00ff0f04 f8 => 0007
> MOD: PRM_OCP (48306800)
> 04 => 0010 14 => 0001 1c => 0201
> MOD: PRM_MPU (48306900)
> 58 => 0005 d4 => 0012 e0 => 00030104 e4 => 00c7
> e8 => 00c7
> MOD: PRM_CORE (48306a00)
> 58 => 0301 a0 => c33ffe18 a4 => c33ffe18 a8 => c33ffe18
> e0 => 000f0304 e4 => 00f7 e8 => 00f7 f0 => 0004
> f4 => 0004 f8 => 0004
> MOD: PRM_SGX (48306b00)
> e0 => 00030104
> MOD: PRM_WKUP (48306c00)
> a0 => 010b a4 => 010b
> MOD: PRM_CCR (48306d00)
> 40 => 0003
> MOD: PRM_DSS (48306e00)
> 58 => 0005 a0 => 0001 e0 => 00030104
> MOD: PRM_CAM (48306f00)
> 58 => 0001 e0 => 00030104
> MOD: PRM_PER (48307000)
> 58 => 0001 a0 => 0003efff a4 => 0003efff a8 => 0003efff
> c8 => 0007 e0 => 00030104 e4 => 0007 e8 => 0007
> MOD: PRM_EMU (48307100)
> 58 => 0005 e4 => 0103
> MOD: PRM_GLBL (48307200)
> 20 => 00120012 24 => 0001 2c => 301e1e30 30 => 2c1e1e2c
> 34 => 0012 38 => 0018 54 => 1006 58 => 0001
> 60 => 000e 64 => 0050 70 => 0088 90 => 0fff0fff
> 94 => 00ff 98 => 00ff 9c => 0002 a0 => 00ff
> c4 => 0001 e4 => 0001
> MOD: PRM_NEON (48307300)
> 58 => 0005 c8 => 0002 e0 => 0004 e4 => 0003
> e8 => 0003
> MOD: PRM_USB (48307400)
> 58 => 0001 a0 => 0001 a4 => 0001 a8 => 0001
> e0 => 00030104
>
>
>> Also, post dump of
>>
>
> r...@beagleboard:/sys# cat /debug/pm_debug/count
> usbhost_pwrdm (OFF),OFF:1,RET:1,INA:0,ON:1
> sgx_pwrdm (OFF),OFF:1,RET:0,INA:0,ON:1
> per_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1
> dss_pwrdm (ON),OFF:2,RET:0,INA:0,ON:3
> cam_pwrdm (OFF),OFF:1,RET:1,INA:0,ON:1
> core_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1
> neon_pwrdm (ON),OFF:2,RET:0,INA:14100,ON:14103
> mpu_pwrdm (ON),OFF:2,RET:0,INA:14100,ON:14103
> iva2_pwrdm (OFF),OFF:1,RET:1,INA:0,ON:1
> per_clkdm->per_pwrdm (9)
> usbhost_clkdm->usbhost_pwrdm (0)
> cam_clkdm->cam_pwrdm (0)
> dss_clkdm->dss_pwrdm (2)
> core_l4_clkdm->core_pwrdm (8)
Re: PM branch rebased to 2.6.29
On Mon, Mar 30, 2009 at 11:43 AM, Kevin Hilman wrote: > Russ Dill writes: > >> On Mon, Mar 30, 2009 at 3:08 AM, Premi, Sanjeev wrote: > [...] >>> >>> I had found that two drivers that could prevent clocks_off are >>> USB and DSS because of the way they use clk_enable(). >>> >>> Can you try building without theses drivers just for verification? >>> >> >> Building without dss makes things worse: >> >> Powerdomain (dss_pwrdm) didn't enter target state 0 >> >> Maybe by looking at what the dss driver is doing I can get core and >> per to turn off. > > Russ, > > Can you try with the latest HEAD of PM branch. After suspend/resume, > do > > # cat /debug/pm_debug/registers/1 > > and post results to list. We can then see the exact state of PM > registers before going into WFI. r...@beagleboard:/sys# cat /debug/pm_debug/registers/1 MOD: CM_IVA2 (48014000) 04 => 0037 20 => 0001 34 => 0001 40 => 0009680c 44 => 0001 48 => 0003 MOD: CM_OCP (48004800) 00 => 0010 10 => 0001 MOD: CM_MPU (48004900) 04 => 0037 24 => 0001 34 => 0001 40 => 0011f40c 44 => 0001 48 => 0003 4c => 0001 MOD: CM_CORE (48004a00) 10 => 0042 20 => ffbd 24 => 001f 28 => 000d 30 => fed9 34 => 001f 38 => 000c 40 => 030a 48 => 003f 4c => 0003 MOD: CM_SGX (48004b00) 20 => 0001 48 => 0003 MOD: CM_WKUP (48004c00) 10 => 000e 20 => 02f1 30 => 003f 40 => 0015 MOD: CM_CCR (48004d00) 00 => f8311037 04 => 0017 20 => 0201 30 => 0009 34 => 0001 40 => 094c0c00 44 => 0001b00c 48 => 0009 50 => 0001 70 => 0003 MOD: CM_DSS (48004e00) 20 => 0003 30 => 0001 40 => 1006 48 => 0003 MOD: CM_CAM (48004f00) 20 => 0001 30 => 0001 40 => 0004 48 => 0003 MOD: CM_PER (48005000) 10 => 0003e000 20 => 1fff 30 => 0003 40 => 00ff 44 => 0006 48 => 0003 4c => 0001 MOD: CM_EMU (48005100) 40 => 03020a50 48 => 0002 4c => 0001 MOD: CM_NEON (48005300) 48 => 0003 MOD: CM_USB (48005400) 20 => 0003 30 => 0001 48 => 0003 MOD: PRM_IVA2 (48316000) 50 => 0007 e0 => 00ff0f04 f8 => 0007 MOD: PRM_OCP (48306800) 04 => 0010 14 => 0001 1c => 0201 MOD: PRM_MPU (48306900) 58 => 0005 d4 => 0012 e0 => 00030104 e4 => 00c7 e8 => 00c7 MOD: PRM_CORE (48306a00) 58 => 0301 a0 => c33ffe18 a4 => c33ffe18 a8 => c33ffe18 e0 => 000f0304 e4 => 00f7 e8 => 00f7 f0 => 0004 f4 => 0004 f8 => 0004 MOD: PRM_SGX (48306b00) e0 => 00030104 MOD: PRM_WKUP (48306c00) a0 => 010b a4 => 010b MOD: PRM_CCR (48306d00) 40 => 0003 MOD: PRM_DSS (48306e00) 58 => 0005 a0 => 0001 e0 => 00030104 MOD: PRM_CAM (48306f00) 58 => 0001 e0 => 00030104 MOD: PRM_PER (48307000) 58 => 0001 a0 => 0003efff a4 => 0003efff a8 => 0003efff c8 => 0007 e0 => 00030104 e4 => 0007 e8 => 0007 MOD: PRM_EMU (48307100) 58 => 0005 e4 => 0103 MOD: PRM_GLBL (48307200) 20 => 00120012 24 => 0001 2c => 301e1e30 30 => 2c1e1e2c 34 => 0012 38 => 0018 54 => 1006 58 => 0001 60 => 000e 64 => 0050 70 => 0088 90 => 0fff0fff 94 => 00ff 98 => 00ff 9c => 0002 a0 => 00ff c4 => 0001 e4 => 0001 MOD: PRM_NEON (48307300) 58 => 0005 c8 => 0002 e0 => 0004 e4 => 0003 e8 => 0003 MOD: PRM_USB (48307400) 58 => 0001 a0 => 0001 a4 => 0001 a8 => 0001 e0 => 00030104 > Also, post dump of > r...@beagleboard:/sys# cat /debug/pm_debug/count usbhost_pwrdm (OFF),OFF:1,RET:1,INA:0,ON:1 sgx_pwrdm (OFF),OFF:1,RET:0,INA:0,ON:1 per_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1 dss_pwrdm (ON),OFF:2,RET:0,INA:0,ON:3 cam_pwrdm (OFF),OFF:1,RET:1,INA:0,ON:1 core_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1 neon_pwrdm (ON),OFF:2,RET:0,INA:14100,ON:14103 mpu_pwrdm (ON),OFF:2,RET:0,INA:14100,ON:14103 iva2_pwrdm (OFF),OFF:1,RET:1,INA:0,ON:1 per_clkdm->per_pwrdm (9) usbhost_clkdm->usbhost_pwrdm (0) cam_clkdm->cam_pwrdm (0) dss_clkdm->dss_pwrdm (2) core_l4_clkdm->core_pwrdm (8) core_l3_clkdm->core_pwrdm (4) d2d_clkdm->core_pwrdm (0) sgx_clkdm->sgx_pwrdm (0) iva2_clkdm->iva2_pwrdm (0) neon_clkdm->neon_pwrdm (0) mpu_clkdm->mpu_pwrdm (0) virt_opp_clkdm->wkup_pwrdm (0) prm_clkdm->wkup_pwrdm (10) cm_clkdm->core_pwrdm (3) > Thanks, > > Kevin > > > > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PM branch rebased to 2.6.29
Russ Dill writes: > On Mon, Mar 30, 2009 at 3:08 AM, Premi, Sanjeev wrote: [...] >> >> I had found that two drivers that could prevent clocks_off are >> USB and DSS because of the way they use clk_enable(). >> >> Can you try building without theses drivers just for verification? >> > > Building without dss makes things worse: > > Powerdomain (dss_pwrdm) didn't enter target state 0 > > Maybe by looking at what the dss driver is doing I can get core and > per to turn off. Russ, Can you try with the latest HEAD of PM branch. After suspend/resume, do # cat /debug/pm_debug/registers/1 and post results to list. We can then see the exact state of PM registers before going into WFI. Also, post dump of # cat /debug/pm_debug/count Thanks, Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PM branch rebased to 2.6.29
On Mon, 2009-03-30 at 10:57 -0700, Kevin Hilman wrote: > Russ Dill writes: > > > On Mon, Mar 30, 2009 at 3:08 AM, Premi, Sanjeev wrote: > [...] > > >> I had found that two drivers that could prevent clocks_off are > >> USB and DSS because of the way they use clk_enable(). > >> > >> Can you try building without theses drivers just for verification? > >> > > > > Building without dss makes things worse: > > > > Powerdomain (dss_pwrdm) didn't enter target state 0 > > > > Maybe by looking at what the dss driver is doing I can get core and > > per to turn off. > > Peter, > > Have you tried with the debug patch I sent? If you can test with that > patch, and send the output, I can tell you what is preventing you from > hitting RET. No, not yet. After comments by Kevin and others regarding my DPLL setting being wrong from u-boot, I'm currently trying to bring up u-boot from the Beagle on the LV SOM. Then I can get the timings for the SDRC correct, and then work on getting the lates PM rebase (2.6.29) to boot. When I tried it with my current u-boot (based on 1.1.4 labrador), it would sporadically hang in rtc_hctosys and other functions that tried to talk to the twl4030 via i2c... I'm running into problems with u-boot (cloned the Beagle config) where I2C to setup power domains fails after the first write (bus gets stuck busy). > FWIW, the latest HEAD of the PM branch has that debug patch included. > > After doing the suspend/resume, just > > # cat /debug/pm_debug/registers/1 > > and attach the output. > > Kevin > -- Peter Barada -- 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: PM branch rebased to 2.6.29
Russ Dill writes: > On Mon, Mar 30, 2009 at 3:08 AM, Premi, Sanjeev wrote: [...] >> I had found that two drivers that could prevent clocks_off are >> USB and DSS because of the way they use clk_enable(). >> >> Can you try building without theses drivers just for verification? >> > > Building without dss makes things worse: > > Powerdomain (dss_pwrdm) didn't enter target state 0 > > Maybe by looking at what the dss driver is doing I can get core and > per to turn off. Peter, Have you tried with the debug patch I sent? If you can test with that patch, and send the output, I can tell you what is preventing you from hitting RET. FWIW, the latest HEAD of the PM branch has that debug patch included. After doing the suspend/resume, just # cat /debug/pm_debug/registers/1 and attach the output. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PM branch rebased to 2.6.29
On Mon, Mar 30, 2009 at 3:08 AM, Premi, Sanjeev wrote: >> -Original Message- >> From: linux-omap-ow...@vger.kernel.org >> [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Russ Dill >> Sent: Saturday, March 28, 2009 2:21 AM >> To: Kevin Hilman >> Cc: Peter Barada; linux-omap@vger.kernel.org >> Subject: Re: PM branch rebased to 2.6.29 >> >> On Tue, Mar 24, 2009 at 1:21 PM, Kevin Hilman >> wrote: >> > Peter Barada wrote: >> >> >> >> On Tue, 2009-03-24 at 11:08 -0700, Kevin Hilman wrote: >> >>> >> >>> Peter Barada writes: >> >>> >> >>>> On Tue, 2009-03-17 at 22:21 -0700, Kevin Hilman wrote: >> >>>>> >> >>>>> FYI... >> >>>>> The PM branch has now been rebased to today's >> linux-omap HEAD which is >> >>>>> based on v2.6.29-rc8. The previous PM branch has been >> renamed to >> >>>>> pm-2.6.28. Depending on when you look, Tony's >> linux-omap tree may not >> >>>>> (yet) have the latest PM branch. If not, you can use >> my PM tree[1] >> >>>>> directly. Also, pm-2.6.28 will only be available on my tree. >> >>>>> >> >>>>> Tested on OMAP3 Beagle and RX51 and was able to hit RET >> and OFF in >> >>>>> suspend and in PM idle with minimal kernel. No testing >> yet done for >> >>>>> CPUidle or DVFS. Please test on your hardware and >> submit results to >> >>>>> the list. Thanks. >> >>>> >> >>>> Kevin, did you build/test with >> >>>> the /arc/arm/config/omap3_beagle_defconfig, and >> >>>> arc/arm/configs/rx51_defconfig or some other >> config(could you send it to >> >>>> me if it isn't in the PM tree)? >> >>> >> >>> I started with the ones in the tree, but I disable most >> of the drivers >> >>> and turn on some debugging features. Attached is the one >> I used for >> >>> beagle. >> >>> [...] >> >> >> >> Hmm, I modified your config to add smc911x support so I can have an >> >> nfsroot, added selector/code for my board(based on >> omap3beagle.c) and >> >> brought it up on my hardware, but I'm not sure if its >> working correctly. >> >> It does look to pause in the suspend sate, and comes out >> when I hit a >> >> key on the console, but the messages don't look quite right as >> >> core_pwrdm and per_pwrdm state they didn't go into state 1 >> (full log >> >> attached): >> >> >> >> omap3530# echo mem > /sys/power/state >> >> PM: Syncing filesystems ... done. >> >> PM: Preparing system for mem sleep >> >> Freezing user space processes ... (elapsed 0.00 seconds) done. >> >> Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done. >> >> PM: Entering mem sleep >> >> Powerdomain (core_pwrdm) didn't enter target state 1 >> >> Powerdomain (per_pwrdm) didn't enter target state 1 >> >> Could not enter target state in pm_suspend >> >> eth0: smc911x_reset timeout waiting for PM restore >> >> >> >> eth0: link down >> >> PM: Finishing wakeup. >> >> Restarting tasks ... done. >> >> omap3530# omap3530# eth0: link up, 100Mbps, full-duplex, lpa 0x45E1 >> >> >> >> >> >> Is this expected? >> >> >> > >> > Yes, you haven't allowed the UART clocks to go off during >> idle/suspend and >> > there are UARTs in both CORE and PER. >> > >> > Try this before going into suspend: >> > >> > echo 1 > /sys/power/clocks_off_while_idle >> > >> > This will allow UART clocks to be disabled on suspend, and >> also allow them >> > to be disabled after 5 seconds of UART inactivity allowing >> retention in idle >> > as well. >> > > > I had found that two drivers that could prevent clocks_off are > USB and DSS because of the way they use clk_enable(). > > Can you try building without theses drivers just for verification? > Building without dss makes things worse: Powerdomain (dss_pwrdm) didn't enter target state 0 Maybe by looking at what the dss driver is doing I can get core and per to turn off. -- 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: PM branch rebased to 2.6.29
> -Original Message- > From: linux-omap-ow...@vger.kernel.org > [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Koen Kooi > Sent: Monday, March 30, 2009 4:12 PM > To: linux-omap@vger.kernel.org Mailing List > Subject: Re: PM branch rebased to 2.6.29 > > Op 30 mrt 2009, om 12:08 heeft Premi, Sanjeev het volgende geschreven: > > > I had found that two drivers that could prevent clocks_off are > > USB and DSS because of the way they use clk_enable(). > > How does DSS2 behave in that regard, and is there any effort > in fixing > the MUSB and EHCI drivers? The problem has already been fixed in DSS2. Vaibhav had discussed it a few weeks back on the list. I am aware of the effory for USB, EHCI effort... but not the timelines. ~sanjeev > > regards, > > Koen > -- 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: PM branch rebased to 2.6.29
Op 30 mrt 2009, om 12:08 heeft Premi, Sanjeev het volgende geschreven: I had found that two drivers that could prevent clocks_off are USB and DSS because of the way they use clk_enable(). How does DSS2 behave in that regard, and is there any effort in fixing the MUSB and EHCI drivers? regards, Koen PGP.sig Description: Dit deel van het bericht is digitaal ondertekend
RE: PM branch rebased to 2.6.29
> -Original Message- > From: linux-omap-ow...@vger.kernel.org > [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Russ Dill > Sent: Saturday, March 28, 2009 2:21 AM > To: Kevin Hilman > Cc: Peter Barada; linux-omap@vger.kernel.org > Subject: Re: PM branch rebased to 2.6.29 > > On Tue, Mar 24, 2009 at 1:21 PM, Kevin Hilman > wrote: > > Peter Barada wrote: > >> > >> On Tue, 2009-03-24 at 11:08 -0700, Kevin Hilman wrote: > >>> > >>> Peter Barada writes: > >>> > >>>> On Tue, 2009-03-17 at 22:21 -0700, Kevin Hilman wrote: > >>>>> > >>>>> FYI... > >>>>> The PM branch has now been rebased to today's > linux-omap HEAD which is > >>>>> based on v2.6.29-rc8. The previous PM branch has been > renamed to > >>>>> pm-2.6.28. Depending on when you look, Tony's > linux-omap tree may not > >>>>> (yet) have the latest PM branch. If not, you can use > my PM tree[1] > >>>>> directly. Also, pm-2.6.28 will only be available on my tree. > >>>>> > >>>>> Tested on OMAP3 Beagle and RX51 and was able to hit RET > and OFF in > >>>>> suspend and in PM idle with minimal kernel. No testing > yet done for > >>>>> CPUidle or DVFS. Please test on your hardware and > submit results to > >>>>> the list. Thanks. > >>>> > >>>> Kevin, did you build/test with > >>>> the /arc/arm/config/omap3_beagle_defconfig, and > >>>> arc/arm/configs/rx51_defconfig or some other > config(could you send it to > >>>> me if it isn't in the PM tree)? > >>> > >>> I started with the ones in the tree, but I disable most > of the drivers > >>> and turn on some debugging features. Attached is the one > I used for > >>> beagle. > >>> [...] > >> > >> Hmm, I modified your config to add smc911x support so I can have an > >> nfsroot, added selector/code for my board(based on > omap3beagle.c) and > >> brought it up on my hardware, but I'm not sure if its > working correctly. > >> It does look to pause in the suspend sate, and comes out > when I hit a > >> key on the console, but the messages don't look quite right as > >> core_pwrdm and per_pwrdm state they didn't go into state 1 > (full log > >> attached): > >> > >> omap3530# echo mem > /sys/power/state > >> PM: Syncing filesystems ... done. > >> PM: Preparing system for mem sleep > >> Freezing user space processes ... (elapsed 0.00 seconds) done. > >> Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done. > >> PM: Entering mem sleep > >> Powerdomain (core_pwrdm) didn't enter target state 1 > >> Powerdomain (per_pwrdm) didn't enter target state 1 > >> Could not enter target state in pm_suspend > >> eth0: smc911x_reset timeout waiting for PM restore > >> > >> eth0: link down > >> PM: Finishing wakeup. > >> Restarting tasks ... done. > >> omap3530# omap3530# eth0: link up, 100Mbps, full-duplex, lpa 0x45E1 > >> > >> > >> Is this expected? > >> > > > > Yes, you haven't allowed the UART clocks to go off during > idle/suspend and > > there are UARTs in both CORE and PER. > > > > Try this before going into suspend: > > > > echo 1 > /sys/power/clocks_off_while_idle > > > > This will allow UART clocks to be disabled on suspend, and > also allow them > > to be disabled after 5 seconds of UART inactivity allowing > retention in idle > > as well. > > I had found that two drivers that could prevent clocks_off are USB and DSS because of the way they use clk_enable(). Can you try building without theses drivers just for verification? Best regards, Sanjeev > > I'm having the same problem, and setting clocks_off_while_idle doesn't > help. I was initially suspicious that the bits in PM_WKEN1_CORE and > PM_WKEN3_CORE needed to be cleared (for core), but using devmem2 to > clear them didn't help. > > For the purposes that I'm using my board for, I need to get everything > into the lowest power consumption possible while sleeping. eg, > everything in off mode but the WKUP domain. > -- > To unsubscribe from this list: send the line "unsubscribe > linux-omap" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PM branch rebased to 2.6.29
On Tue, Mar 24, 2009 at 1:21 PM, Kevin Hilman wrote: > Peter Barada wrote: >> >> On Tue, 2009-03-24 at 11:08 -0700, Kevin Hilman wrote: >>> >>> Peter Barada writes: >>> On Tue, 2009-03-17 at 22:21 -0700, Kevin Hilman wrote: > > FYI... > The PM branch has now been rebased to today's linux-omap HEAD which is > based on v2.6.29-rc8. The previous PM branch has been renamed to > pm-2.6.28. Depending on when you look, Tony's linux-omap tree may not > (yet) have the latest PM branch. If not, you can use my PM tree[1] > directly. Also, pm-2.6.28 will only be available on my tree. > > Tested on OMAP3 Beagle and RX51 and was able to hit RET and OFF in > suspend and in PM idle with minimal kernel. No testing yet done for > CPUidle or DVFS. Please test on your hardware and submit results to > the list. Thanks. Kevin, did you build/test with the /arc/arm/config/omap3_beagle_defconfig, and arc/arm/configs/rx51_defconfig or some other config(could you send it to me if it isn't in the PM tree)? >>> >>> I started with the ones in the tree, but I disable most of the drivers >>> and turn on some debugging features. Attached is the one I used for >>> beagle. >>> [...] >> >> Hmm, I modified your config to add smc911x support so I can have an >> nfsroot, added selector/code for my board(based on omap3beagle.c) and >> brought it up on my hardware, but I'm not sure if its working correctly. >> It does look to pause in the suspend sate, and comes out when I hit a >> key on the console, but the messages don't look quite right as >> core_pwrdm and per_pwrdm state they didn't go into state 1 (full log >> attached): >> >> omap3530# echo mem > /sys/power/state >> PM: Syncing filesystems ... done. >> PM: Preparing system for mem sleep >> Freezing user space processes ... (elapsed 0.00 seconds) done. >> Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done. >> PM: Entering mem sleep >> Powerdomain (core_pwrdm) didn't enter target state 1 >> Powerdomain (per_pwrdm) didn't enter target state 1 >> Could not enter target state in pm_suspend >> eth0: smc911x_reset timeout waiting for PM restore >> >> eth0: link down >> PM: Finishing wakeup. >> Restarting tasks ... done. >> omap3530# omap3530# eth0: link up, 100Mbps, full-duplex, lpa 0x45E1 >> >> >> Is this expected? >> > > Yes, you haven't allowed the UART clocks to go off during idle/suspend and > there are UARTs in both CORE and PER. > > Try this before going into suspend: > > echo 1 > /sys/power/clocks_off_while_idle > > This will allow UART clocks to be disabled on suspend, and also allow them > to be disabled after 5 seconds of UART inactivity allowing retention in idle > as well. > I'm having the same problem, and setting clocks_off_while_idle doesn't help. I was initially suspicious that the bits in PM_WKEN1_CORE and PM_WKEN3_CORE needed to be cleared (for core), but using devmem2 to clear them didn't help. For the purposes that I'm using my board for, I need to get everything into the lowest power consumption possible while sleeping. eg, everything in off mode but the WKUP domain. -- 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: PM branch rebased to 2.6.29
Jean Pihet writes: > Hi, > > I am having a crash with the latest 2.6.29 pm branch with CPU_FREQ enabled. > It > looks like clk_set_rate is called recursively, thus deadlocking on the mutex. > > Any idea why this worked fine on 2.6.29-rc8 pm? One of the differences is the new clock notifier patches, which may have changed the locking, but I haven't dug into this yet so I don't know if it's a bug in the clock locking or in CPUfreq locking. Kevin > Here is the dump excerpt: > ... > Disabling unused clock "sys_clkout1" > BUG: scheduling while atomic: swapper/1/0x0002 > Modules linked in: > [] (dump_stack+0x0/0x14) from [] > (__schedule_bug+0x54/0x60) > [] (__schedule_bug+0x0/0x60) from [] (schedule+0x78/0x2bc) > r4:c781c000 > [] (schedule+0x0/0x2bc) from [] > (__mutex_lock_slowpath+0x174/0x290) > [] (__mutex_lock_slowpath+0x0/0x290) from [] > (mutex_lock+0x28/0x30) > [] (mutex_lock+0x0/0x30) from [] (clk_set_rate+0x2c/0xec) > r4:c03ced20 > [] (clk_set_rate+0x0/0xec) from [] > (omap3_select_table_rate+0xd0/0x168) > r6:0004 r5:c03fd474 r4:c03d426c > [] (omap3_select_table_rate+0x0/0x168) from [] > (omap2_clk_set_rate+0x20/0x24) > r6:6013 r5:20c85580 r4:c03ce41c > [] (omap2_clk_set_rate+0x0/0x24) from [] > (clk_set_rate+0x88/0xec) > [] (clk_set_rate+0x0/0xec) from [] > (omap_cpu_init+0xc8/0x108) > r6:c03f4b20 r5:c03fddac r4:c7be9be0 > [] (omap_cpu_init+0x0/0x108) from [] > (cpufreq_add_dev+0x120/0x300) > r5:c7be9be0 r4: > [] (cpufreq_add_dev+0x0/0x300) from [] > (sysdev_driver_register+0xb4/0x124) > r8: r7: r6:c03f4b20 r5:c03ef708 r4:c03fc95c > [] (sysdev_driver_register+0x0/0x124) from [] > (cpufreq_register_driver+0x98/0x104) > r6: r5:c041efac r4:c03d541c > [] (cpufreq_register_driver+0x0/0x104) from [] > (omap_cpufreq_init+0x14/0x1c) > r5:c00266fc r4:c03fc080 > [] (omap_cpufreq_init+0x0/0x1c) from [] > (__exception_text_end+0x54/0x188) > [] (__exception_text_end+0x0/0x188) from [] > (kernel_init+0x74/0xdc) > [] (kernel_init+0x0/0xdc) from [] (do_exit+0x0/0x6b8) > r5: r4: > > Regards, > Jean > > On Wednesday 18 March 2009 06:21:09 Kevin Hilman wrote: >> FYI... >> >> The PM branch has now been rebased to today's linux-omap HEAD which is >> based on v2.6.29-rc8. The previous PM branch has been renamed to >> pm-2.6.28. Depending on when you look, Tony's linux-omap tree may not >> (yet) have the latest PM branch. If not, you can use my PM tree[1] >> directly. Also, pm-2.6.28 will only be available on my tree. >> >> Tested on OMAP3 Beagle and RX51 and was able to hit RET and OFF in >> suspend and in PM idle with minimal kernel. No testing yet done for >> CPUidle or DVFS. Please test on your hardware and submit results to >> the list. Thanks. >> >> Kevin >> >> -- >> >> Misc. conflicts/issues resolved after rebase: >> >> - no longer safe to use getnstimeofday() in suspend path since timekeeping >> subsystem is also suspended in the suspend path. PM debug timing has >> been converted to use sched_clock() which is 32k sync-timer based. >> >> - Update board-rx51.c to use common OMAP3 OPPs >> >> Known issues: >> >> - Beagle: MMC: off-mode needs work in MMC driver, so if you hit off >> and have a rootfs on MMC, you're dead. >> >> - Beagle: MMC regulator: unbalanced disables. This happens on boot >> and during suspend/resume. I don't think this is related to the PM >> branch, but is probably in linux-omap HEAD also, but didn't test. >> >> Linux version 2.6.29-rc8-omap1-arm-omap3beagle-default-05653-gd803372-dirty >> (khil...@vence) (gcc version 4.3.2 (Sourcery G++ Lite 2008q3-66) ) #4 >> PREEMPT Tue Mar 17 21:38:09 PDT 2009 [...] >> i2c_omap i2c_omap.1: bus 1 rev3.12 at 2600 kHz >> twl4030: PIH (irq 7) chaining IRQs 368..375 >> twl4030: power (irq 373) chaining IRQs 376..383 >> twl4030: gpio (irq 368) chaining IRQs 384..401 >> beagle_twl_gpio_setup:145 >> twl4030_mmc_init:303 >> twl4030_mmc_init:318 >> regulator: VMMC1: 1850 <--> 3150 mV normal standby >> regulator: VDAC: 1800 mV normal standby >> regulator: VUSB1V5: 1500 <--> 0 mV normal standby >> regulator: VUSB1V8: 1800 <--> 0 mV normal standby >> regulator: VUSB3V1: 3100 <--> 0 mV normal standby >> regulator: VSIM: 1800 <--> 3000 mV normal standby >> [...] >> mmci-omap-hs mmci-omap-hs.0: Failed to get debounce clock >> [ cut here ] >> WARNING: at >> /net/home/khilman/work/kernel/omap/pm/drivers/regulator/core.c:1216 >> regulator_disable+0x64/0x90() unbalanced disables for supply >> mmci-omap-hs.0-vmmc >> Modules linked in: >> [] (dump_stack+0x0/0x14) from [] >> (warn_slowpath+0x6c/0x88) [] (warn_slowpath+0x0/0x88) from >> [] (regulator_disable+0x64/0x90) r3:c79dc2a0 r2:c03390cb >> r7:c78e8c20 r6:c78aac38 r5:c78e8c20 r4:fffb >> [] (regulator_disable+0x0/0x90) from [] >> (mmc_regulator_set_ocr+0xb0/0xcc) r7:c78e8c20 r6:0001 r5: >> r4: >> [] (mmc_regulator_set_ocr+0x0/0xcc) from [] >> (twl_mmc1_set_power+0xc0/0xec)
Re: PM branch rebased to 2.6.29
Hi, I am having a crash with the latest 2.6.29 pm branch with CPU_FREQ enabled. It looks like clk_set_rate is called recursively, thus deadlocking on the mutex. Any idea why this worked fine on 2.6.29-rc8 pm? Here is the dump excerpt: ... Disabling unused clock "sys_clkout1" BUG: scheduling while atomic: swapper/1/0x0002 Modules linked in: [] (dump_stack+0x0/0x14) from [] (__schedule_bug+0x54/0x60) [] (__schedule_bug+0x0/0x60) from [] (schedule+0x78/0x2bc) r4:c781c000 [] (schedule+0x0/0x2bc) from [] (__mutex_lock_slowpath+0x174/0x290) [] (__mutex_lock_slowpath+0x0/0x290) from [] (mutex_lock+0x28/0x30) [] (mutex_lock+0x0/0x30) from [] (clk_set_rate+0x2c/0xec) r4:c03ced20 [] (clk_set_rate+0x0/0xec) from [] (omap3_select_table_rate+0xd0/0x168) r6:0004 r5:c03fd474 r4:c03d426c [] (omap3_select_table_rate+0x0/0x168) from [] (omap2_clk_set_rate+0x20/0x24) r6:6013 r5:20c85580 r4:c03ce41c [] (omap2_clk_set_rate+0x0/0x24) from [] (clk_set_rate+0x88/0xec) [] (clk_set_rate+0x0/0xec) from [] (omap_cpu_init+0xc8/0x108) r6:c03f4b20 r5:c03fddac r4:c7be9be0 [] (omap_cpu_init+0x0/0x108) from [] (cpufreq_add_dev+0x120/0x300) r5:c7be9be0 r4: [] (cpufreq_add_dev+0x0/0x300) from [] (sysdev_driver_register+0xb4/0x124) r8: r7: r6:c03f4b20 r5:c03ef708 r4:c03fc95c [] (sysdev_driver_register+0x0/0x124) from [] (cpufreq_register_driver+0x98/0x104) r6: r5:c041efac r4:c03d541c [] (cpufreq_register_driver+0x0/0x104) from [] (omap_cpufreq_init+0x14/0x1c) r5:c00266fc r4:c03fc080 [] (omap_cpufreq_init+0x0/0x1c) from [] (__exception_text_end+0x54/0x188) [] (__exception_text_end+0x0/0x188) from [] (kernel_init+0x74/0xdc) [] (kernel_init+0x0/0xdc) from [] (do_exit+0x0/0x6b8) r5: r4: Regards, Jean On Wednesday 18 March 2009 06:21:09 Kevin Hilman wrote: > FYI... > > The PM branch has now been rebased to today's linux-omap HEAD which is > based on v2.6.29-rc8. The previous PM branch has been renamed to > pm-2.6.28. Depending on when you look, Tony's linux-omap tree may not > (yet) have the latest PM branch. If not, you can use my PM tree[1] > directly. Also, pm-2.6.28 will only be available on my tree. > > Tested on OMAP3 Beagle and RX51 and was able to hit RET and OFF in > suspend and in PM idle with minimal kernel. No testing yet done for > CPUidle or DVFS. Please test on your hardware and submit results to > the list. Thanks. > > Kevin > > -- > > Misc. conflicts/issues resolved after rebase: > > - no longer safe to use getnstimeofday() in suspend path since timekeeping > subsystem is also suspended in the suspend path. PM debug timing has > been converted to use sched_clock() which is 32k sync-timer based. > > - Update board-rx51.c to use common OMAP3 OPPs > > Known issues: > > - Beagle: MMC: off-mode needs work in MMC driver, so if you hit off > and have a rootfs on MMC, you're dead. > > - Beagle: MMC regulator: unbalanced disables. This happens on boot > and during suspend/resume. I don't think this is related to the PM > branch, but is probably in linux-omap HEAD also, but didn't test. > > Linux version 2.6.29-rc8-omap1-arm-omap3beagle-default-05653-gd803372-dirty > (khil...@vence) (gcc version 4.3.2 (Sourcery G++ Lite 2008q3-66) ) #4 > PREEMPT Tue Mar 17 21:38:09 PDT 2009 [...] > i2c_omap i2c_omap.1: bus 1 rev3.12 at 2600 kHz > twl4030: PIH (irq 7) chaining IRQs 368..375 > twl4030: power (irq 373) chaining IRQs 376..383 > twl4030: gpio (irq 368) chaining IRQs 384..401 > beagle_twl_gpio_setup:145 > twl4030_mmc_init:303 > twl4030_mmc_init:318 > regulator: VMMC1: 1850 <--> 3150 mV normal standby > regulator: VDAC: 1800 mV normal standby > regulator: VUSB1V5: 1500 <--> 0 mV normal standby > regulator: VUSB1V8: 1800 <--> 0 mV normal standby > regulator: VUSB3V1: 3100 <--> 0 mV normal standby > regulator: VSIM: 1800 <--> 3000 mV normal standby > [...] > mmci-omap-hs mmci-omap-hs.0: Failed to get debounce clock > [ cut here ] > WARNING: at > /net/home/khilman/work/kernel/omap/pm/drivers/regulator/core.c:1216 > regulator_disable+0x64/0x90() unbalanced disables for supply > mmci-omap-hs.0-vmmc > Modules linked in: > [] (dump_stack+0x0/0x14) from [] > (warn_slowpath+0x6c/0x88) [] (warn_slowpath+0x0/0x88) from > [] (regulator_disable+0x64/0x90) r3:c79dc2a0 r2:c03390cb > r7:c78e8c20 r6:c78aac38 r5:c78e8c20 r4:fffb > [] (regulator_disable+0x0/0x90) from [] > (mmc_regulator_set_ocr+0xb0/0xcc) r7:c78e8c20 r6:0001 r5: > r4: > [] (mmc_regulator_set_ocr+0x0/0xcc) from [] > (twl_mmc1_set_power+0xc0/0xec) r7:c784f538 r6: r5: > r4:c039185c > [] (twl_mmc1_set_power+0x0/0xec) from [] > (omap_mmc_set_ios+0x54/0x2b0) r7:c784f538 r6:c784f5c0 r5:c784f400 > r4:c7844380 > [] (omap_mmc_set_ios+0x0/0x2b0) from [] > (mmc_power_off+0x54/0x58) r7:c784f400 r6:c7910400 r5: r4:c784f400 > [] (mmc_power_off+0x0/0x58) from [] > (mmc_start_host+0x14/0x24) [] (mmc_start_host+0x0/0x24) from > [] (mmc_ad
PM branch rebased to 2.6.29... for real this time
Hello, The previous rebase was actually to 2.6.29-rc8. Now that 2.6.29 is out, I've rebased the PM brach onto linux-omap HEAD just after the 2.6.29 merge. Minimal retention and off-mode on Beagle and RX51. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PM branch rebased to 2.6.29
On Tue, 2009-03-24 at 13:21 -0700, Kevin Hilman wrote: > Peter Barada wrote: > > On Tue, 2009-03-24 at 11:08 -0700, Kevin Hilman wrote: > >> Peter Barada writes: > >> > >>> On Tue, 2009-03-17 at 22:21 -0700, Kevin Hilman wrote: > FYI... > > The PM branch has now been rebased to today's linux-omap HEAD which is > based on v2.6.29-rc8. The previous PM branch has been renamed to > pm-2.6.28. Depending on when you look, Tony's linux-omap tree may not > (yet) have the latest PM branch. If not, you can use my PM tree[1] > directly. Also, pm-2.6.28 will only be available on my tree. > > Tested on OMAP3 Beagle and RX51 and was able to hit RET and OFF in > suspend and in PM idle with minimal kernel. No testing yet done for > CPUidle or DVFS. Please test on your hardware and submit results to > the list. Thanks. > >>> Kevin, did you build/test with > >>> the /arc/arm/config/omap3_beagle_defconfig, and > >>> arc/arm/configs/rx51_defconfig or some other config(could you send it to > >>> me if it isn't in the PM tree)? > >> I started with the ones in the tree, but I disable most of the drivers > >> and turn on some debugging features. Attached is the one I used for > >> beagle. > >> [...] > > > > Hmm, I modified your config to add smc911x support so I can have an > > nfsroot, added selector/code for my board(based on omap3beagle.c) and > > brought it up on my hardware, but I'm not sure if its working correctly. > > It does look to pause in the suspend sate, and comes out when I hit a > > key on the console, but the messages don't look quite right as > > core_pwrdm and per_pwrdm state they didn't go into state 1 (full log > > attached): > > > > omap3530# echo mem > /sys/power/state > > PM: Syncing filesystems ... done. > > PM: Preparing system for mem sleep > > Freezing user space processes ... (elapsed 0.00 seconds) done. > > Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done. > > PM: Entering mem sleep > > Powerdomain (core_pwrdm) didn't enter target state 1 > > Powerdomain (per_pwrdm) didn't enter target state 1 > > Could not enter target state in pm_suspend > > eth0: smc911x_reset timeout waiting for PM restore > > > > eth0: link down > > PM: Finishing wakeup. > > Restarting tasks ... done. > > omap3530# > > omap3530# eth0: link up, 100Mbps, full-duplex, lpa 0x45E1 > > > > > > Is this expected? > > > > Yes, you haven't allowed the UART clocks to go off during idle/suspend > and there are UARTs in both CORE and PER. > > Try this before going into suspend: > >echo 1 > /sys/power/clocks_off_while_idle > > This will allow UART clocks to be disabled on suspend, and also allow > them to be disabled after 5 seconds of UART inactivity allowing > retention in idle as well. that Fixed PER, but CORE still says it couldn't go into state 1: omap3530# echo 1 > /sys/power/clocks_off_while_idle omap3530# echo mem > /sys/power/state PM: Syncing filesystems ... done. PM: Preparing system for mem sleep Freezing user space processes ... (elapsed 0.00 seconds) done. Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done. PM: Entering mem sleep Powerdomain (core_pwrdm) didn't enter target state 1 Could not enter target state in pm_suspend eth0: smc911x_reset timeout waiting for PM restore eth0: link down PM: Finishing wakeup. Restarting tasks ... done. omap3530# eth0: link up, 100Mbps, full-duplex, lpa 0x45E1 > > Kevin -- Peter Barada -- 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: PM branch rebased to 2.6.29
Peter Barada wrote: On Tue, 2009-03-24 at 11:08 -0700, Kevin Hilman wrote: Peter Barada writes: On Tue, 2009-03-17 at 22:21 -0700, Kevin Hilman wrote: FYI... The PM branch has now been rebased to today's linux-omap HEAD which is based on v2.6.29-rc8. The previous PM branch has been renamed to pm-2.6.28. Depending on when you look, Tony's linux-omap tree may not (yet) have the latest PM branch. If not, you can use my PM tree[1] directly. Also, pm-2.6.28 will only be available on my tree. Tested on OMAP3 Beagle and RX51 and was able to hit RET and OFF in suspend and in PM idle with minimal kernel. No testing yet done for CPUidle or DVFS. Please test on your hardware and submit results to the list. Thanks. Kevin, did you build/test with the /arc/arm/config/omap3_beagle_defconfig, and arc/arm/configs/rx51_defconfig or some other config(could you send it to me if it isn't in the PM tree)? I started with the ones in the tree, but I disable most of the drivers and turn on some debugging features. Attached is the one I used for beagle. [...] Hmm, I modified your config to add smc911x support so I can have an nfsroot, added selector/code for my board(based on omap3beagle.c) and brought it up on my hardware, but I'm not sure if its working correctly. It does look to pause in the suspend sate, and comes out when I hit a key on the console, but the messages don't look quite right as core_pwrdm and per_pwrdm state they didn't go into state 1 (full log attached): omap3530# echo mem > /sys/power/state PM: Syncing filesystems ... done. PM: Preparing system for mem sleep Freezing user space processes ... (elapsed 0.00 seconds) done. Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done. PM: Entering mem sleep Powerdomain (core_pwrdm) didn't enter target state 1 Powerdomain (per_pwrdm) didn't enter target state 1 Could not enter target state in pm_suspend eth0: smc911x_reset timeout waiting for PM restore eth0: link down PM: Finishing wakeup. Restarting tasks ... done. omap3530# omap3530# eth0: link up, 100Mbps, full-duplex, lpa 0x45E1 Is this expected? Yes, you haven't allowed the UART clocks to go off during idle/suspend and there are UARTs in both CORE and PER. Try this before going into suspend: echo 1 > /sys/power/clocks_off_while_idle This will allow UART clocks to be disabled on suspend, and also allow them to be disabled after 5 seconds of UART inactivity allowing retention in idle as well. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PM branch rebased to 2.6.29
On Tue, 2009-03-24 at 11:08 -0700, Kevin Hilman wrote: > Peter Barada writes: > > > On Tue, 2009-03-17 at 22:21 -0700, Kevin Hilman wrote: > >> FYI... > >> > >> The PM branch has now been rebased to today's linux-omap HEAD which is > >> based on v2.6.29-rc8. The previous PM branch has been renamed to > >> pm-2.6.28. Depending on when you look, Tony's linux-omap tree may not > >> (yet) have the latest PM branch. If not, you can use my PM tree[1] > >> directly. Also, pm-2.6.28 will only be available on my tree. > >> > >> Tested on OMAP3 Beagle and RX51 and was able to hit RET and OFF in > >> suspend and in PM idle with minimal kernel. No testing yet done for > >> CPUidle or DVFS. Please test on your hardware and submit results to > >> the list. Thanks. > > > > Kevin, did you build/test with > > the /arc/arm/config/omap3_beagle_defconfig, and > > arc/arm/configs/rx51_defconfig or some other config(could you send it to > > me if it isn't in the PM tree)? > > I started with the ones in the tree, but I disable most of the drivers > and turn on some debugging features. Attached is the one I used for > beagle. > [...] Hmm, I modified your config to add smc911x support so I can have an nfsroot, added selector/code for my board(based on omap3beagle.c) and brought it up on my hardware, but I'm not sure if its working correctly. It does look to pause in the suspend sate, and comes out when I hit a key on the console, but the messages don't look quite right as core_pwrdm and per_pwrdm state they didn't go into state 1 (full log attached): omap3530# echo mem > /sys/power/state PM: Syncing filesystems ... done. PM: Preparing system for mem sleep Freezing user space processes ... (elapsed 0.00 seconds) done. Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done. PM: Entering mem sleep Powerdomain (core_pwrdm) didn't enter target state 1 Powerdomain (per_pwrdm) didn't enter target state 1 Could not enter target state in pm_suspend eth0: smc911x_reset timeout waiting for PM restore eth0: link down PM: Finishing wakeup. Restarting tasks ... done. omap3530# omap3530# eth0: link up, 100Mbps, full-duplex, lpa 0x45E1 Is this expected? -- Peter Barada NoLo Version : 2.4.6-OMAP3503 0001 NoLo Build : LPD386 Tue Nov 25 15:00:19 CST 2008 NoLo Compiler: gcc version 4.2.1 Image type : Elf Boot Device : NAND * LogicLoader (c) Copyright 2002-2008, Logic Product Development, Inc. All Rights Reserved. Version 2.4.6-OMAP3503 0001 * losh> ifconfig sm0 /dev/config losh> load elf /tftp/192.168.3.5:u-boot loading from /tftp/192.168.3.5:u-boot: . ELF section 0: download address: 0x80208000 load address: 0x80e8 loaded 140108 @ 0x80e8 Ram ...done file loaded losh> exec U-Boot 1.1.4 (Mar 13 2009 - 16:32:42) OMAP3430-GP rev 2, CPU-OPP2 L3-133MHz OMAP3430LV_SOM 0.1 Version + mDDR (Boot NAND) DRAM: 128 MB FLASH: initialize in sync mode NAND: 256 MiB Read production data: done Part Number : 1010194 Model Name : SOMOMAP3530-10-1672IFCR-A Serial Number: 3408M03305 In:serial Out: serial Err: serial Hit any key to stop autoboot: 6 0 => boot DRIVER_VERSION : 101, DATECODE : 092706 LAN9x18 (0x9211) detected. start Auto negotiation... (take ~2sec) Auto negotiation complete, 100BaseTX, full duplex TFTP from server 192.168.3.5; our IP address is 192.168.3.11 Filename 'uImage'. Load address: 0x8100 Loading: *# # # # # done Bytes transferred = 1806408 (1b9048 hex) ## Booting image at 8100 ... Image Name: Linux-2.6.29-rc8-omap1 Image Type: ARM Linux Kernel Image (uncompressed) Data Size:1806344 Bytes = 1.7 MB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK OK Starting kernel ... Uncompressing Linux done, booting the kernel. Linux version 2.6.29-rc8-omap1 (pe...@blackhole) (gcc version 4.1.2) #5 PREEMPT Tue Mar 24 15:49:34 EDT 2009 CPU: ARMv7 Processor [411fc082] revision 2 (ARMv7), cr=10c5387f CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache Machine: OMAP OMAP3530LV_SOM board Memory policy: ECC disabled, Data cache writeback On node 0 totalpages: 32768 free_area_init_node: node 0, pgdat c038f5dc, node_mem_map c03b9000 Normal zone: 256 pages used for memmap Normal zone: 0 pages
Re: PM branch rebased to 2.6.29
Peter Barada writes: > On Tue, 2009-03-17 at 22:21 -0700, Kevin Hilman wrote: >> FYI... >> >> The PM branch has now been rebased to today's linux-omap HEAD which is >> based on v2.6.29-rc8. The previous PM branch has been renamed to >> pm-2.6.28. Depending on when you look, Tony's linux-omap tree may not >> (yet) have the latest PM branch. If not, you can use my PM tree[1] >> directly. Also, pm-2.6.28 will only be available on my tree. >> >> Tested on OMAP3 Beagle and RX51 and was able to hit RET and OFF in >> suspend and in PM idle with minimal kernel. No testing yet done for >> CPUidle or DVFS. Please test on your hardware and submit results to >> the list. Thanks. > > Kevin, did you build/test with > the /arc/arm/config/omap3_beagle_defconfig, and > arc/arm/configs/rx51_defconfig or some other config(could you send it to > me if it isn't in the PM tree)? I started with the ones in the tree, but I disable most of the drivers and turn on some debugging features. Attached is the one I used for beagle. Kevin > I'm trying to bring up your PM branch > on my OMAP3530_LV_SOM, using LDP as a starting point, and it goes into > retention but doesn't come back out, and rather than thrash on the LDP > defconfig, start with a config/code that is known to work. I'm also > resnapping to commit c3127068... to jump to the latest from your tree > and start my port over. I have to get suspend/resume working first > before I start working in all the drivers, and check that suspend/resume > works for each functional addition... > > Thanks in advance! > [...] # # Automatically generated make config: don't edit # Linux kernel version: 2.6.28-omap1 # Tue Mar 24 09:07:57 2009 # CONFIG_ARM=y CONFIG_SYS_SUPPORTS_APM_EMULATION=y CONFIG_GENERIC_GPIO=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_MMU=y # CONFIG_NO_IOPORT is not set CONFIG_GENERIC_HARDIRQS=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_TRACE_IRQFLAGS_SUPPORT=y CONFIG_HARDIRQS_SW_RESEND=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_RWSEM_GENERIC_SPINLOCK=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_GENERIC_HARDIRQS_NO__DO_IRQ=y CONFIG_VECTORS_BASE=0x CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y # CONFIG_POSIX_MQUEUE is not set CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set # CONFIG_TASKSTATS is not set # CONFIG_AUDIT is not set # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=14 # CONFIG_CGROUPS is not set CONFIG_GROUP_SCHED=y CONFIG_FAIR_GROUP_SCHED=y # CONFIG_RT_GROUP_SCHED is not set CONFIG_USER_SCHED=y # CONFIG_CGROUP_SCHED is not set CONFIG_SYSFS_DEPRECATED=y CONFIG_SYSFS_DEPRECATED_V2=y # CONFIG_RELAY is not set # CONFIG_NAMESPACES is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y CONFIG_EMBEDDED=y CONFIG_UID16=y # CONFIG_SYSCTL_SYSCALL is not set CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set CONFIG_KALLSYMS_EXTRA_PASS=y CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_COMPAT_BRK=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_AIO=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLAB=y # CONFIG_SLUB is not set # CONFIG_SLOB is not set # CONFIG_PROFILING is not set # CONFIG_MARKERS is not set CONFIG_HAVE_OPROFILE=y # CONFIG_KPROBES is not set CONFIG_HAVE_KPROBES=y CONFIG_HAVE_KRETPROBES=y CONFIG_HAVE_CLK=y CONFIG_HAVE_GENERIC_DMA_COHERENT=y CONFIG_SLABINFO=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 CONFIG_MODULES=y # CONFIG_MODULE_FORCE_LOAD is not set CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set CONFIG_MODVERSIONS=y CONFIG_MODULE_SRCVERSION_ALL=y CONFIG_KMOD=y CONFIG_BLOCK=y # CONFIG_LBD is not set # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_LSF is not set # CONFIG_BLK_DEV_BSG is not set # CONFIG_BLK_DEV_INTEGRITY is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y CONFIG_DEFAULT_AS=y # CONFIG_DEFAULT_DEADLINE is not set # CONFIG_DEFAULT_CFQ is not set # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="anticipatory" CONFIG_CLASSIC_RCU=y CONFIG_FREEZER=y # # System Type # # CONFIG_ARCH_AAEC2000 is not set # CONFIG_ARCH_INTEGRATOR is not set # CONFIG_ARCH_REALVIEW is not set # CONFIG_ARCH_VERSATILE is not set # CONFIG_ARCH_AT91 is not set # CONFIG_ARCH_CLPS7500 is not set # CONFIG_ARCH_CLPS711X is not set # CONFIG_ARCH_EBSA110 is not set # CONFIG_ARCH_EP93XX is not set # CONFIG_ARCH_FOOTBRIDGE is not set # CONFIG_ARCH_NETX is not set # CONFIG_AR
Re: PM branch rebased to 2.6.29
On Tue, 2009-03-17 at 22:21 -0700, Kevin Hilman wrote: > FYI... > > The PM branch has now been rebased to today's linux-omap HEAD which is > based on v2.6.29-rc8. The previous PM branch has been renamed to > pm-2.6.28. Depending on when you look, Tony's linux-omap tree may not > (yet) have the latest PM branch. If not, you can use my PM tree[1] > directly. Also, pm-2.6.28 will only be available on my tree. > > Tested on OMAP3 Beagle and RX51 and was able to hit RET and OFF in > suspend and in PM idle with minimal kernel. No testing yet done for > CPUidle or DVFS. Please test on your hardware and submit results to > the list. Thanks. Kevin, did you build/test with the /arc/arm/config/omap3_beagle_defconfig, and arc/arm/configs/rx51_defconfig or some other config(could you send it to me if it isn't in the PM tree)? I'm trying to bring up your PM branch on my OMAP3530_LV_SOM, using LDP as a starting point, and it goes into retention but doesn't come back out, and rather than thrash on the LDP defconfig, start with a config/code that is known to work. I'm also resnapping to commit c3127068... to jump to the latest from your tree and start my port over. I have to get suspend/resume working first before I start working in all the drivers, and check that suspend/resume works for each functional addition... Thanks in advance! > Kevin > > -- > > Misc. conflicts/issues resolved after rebase: > > - no longer safe to use getnstimeofday() in suspend path since timekeeping > subsystem is also suspended in the suspend path. PM debug timing has > been converted to use sched_clock() which is 32k sync-timer based. > > - Update board-rx51.c to use common OMAP3 OPPs > > Known issues: > > - Beagle: MMC: off-mode needs work in MMC driver, so if you hit off > and have a rootfs on MMC, you're dead. > > - Beagle: MMC regulator: unbalanced disables. This happens on boot > and during suspend/resume. I don't think this is related to the PM > branch, but is probably in linux-omap HEAD also, but didn't test. > > Linux version 2.6.29-rc8-omap1-arm-omap3beagle-default-05653-gd803372-dirty > (khil...@vence) (gcc version 4.3.2 (Sourcery G++ Lite 2008q3-66) ) #4 PREEMPT > Tue Mar 17 21:38:09 PDT 2009 > [...] > i2c_omap i2c_omap.1: bus 1 rev3.12 at 2600 kHz > twl4030: PIH (irq 7) chaining IRQs 368..375 > twl4030: power (irq 373) chaining IRQs 376..383 > twl4030: gpio (irq 368) chaining IRQs 384..401 > beagle_twl_gpio_setup:145 > twl4030_mmc_init:303 > twl4030_mmc_init:318 > regulator: VMMC1: 1850 <--> 3150 mV normal standby > regulator: VDAC: 1800 mV normal standby > regulator: VUSB1V5: 1500 <--> 0 mV normal standby > regulator: VUSB1V8: 1800 <--> 0 mV normal standby > regulator: VUSB3V1: 3100 <--> 0 mV normal standby > regulator: VSIM: 1800 <--> 3000 mV normal standby > [...] > mmci-omap-hs mmci-omap-hs.0: Failed to get debounce clock > [ cut here ] > WARNING: at > /net/home/khilman/work/kernel/omap/pm/drivers/regulator/core.c:1216 > regulator_disable+0x64/0x90() > unbalanced disables for supply mmci-omap-hs.0-vmmc > Modules linked in: > [] (dump_stack+0x0/0x14) from [] (warn_slowpath+0x6c/0x88) > [] (warn_slowpath+0x0/0x88) from [] > (regulator_disable+0x64/0x90) > r3:c79dc2a0 r2:c03390cb > r7:c78e8c20 r6:c78aac38 r5:c78e8c20 r4:fffb > [] (regulator_disable+0x0/0x90) from [] > (mmc_regulator_set_ocr+0xb0/0xcc) > r7:c78e8c20 r6:0001 r5: r4: > [] (mmc_regulator_set_ocr+0x0/0xcc) from [] > (twl_mmc1_set_power+0xc0/0xec) > r7:c784f538 r6: r5: r4:c039185c > [] (twl_mmc1_set_power+0x0/0xec) from [] > (omap_mmc_set_ios+0x54/0x2b0) > r7:c784f538 r6:c784f5c0 r5:c784f400 r4:c7844380 > [] (omap_mmc_set_ios+0x0/0x2b0) from [] > (mmc_power_off+0x54/0x58) > r7:c784f400 r6:c7910400 r5: r4:c784f400 > [] (mmc_power_off+0x0/0x58) from [] > (mmc_start_host+0x14/0x24) > [] (mmc_start_host+0x0/0x24) from [] > (mmc_add_host+0x58/0x64) > r5: r4:c784f400 > [] (mmc_add_host+0x0/0x64) from [] > (omap_mmc_probe+0x3d0/0x548) > r5:c784f5c0 r4: > [] (omap_mmc_probe+0x0/0x548) from [] > (platform_drv_probe+0x20/0x24) > [] (platform_drv_probe+0x0/0x24) from [] > (driver_probe_device+0xd4/0x180) > [] (driver_probe_device+0x0/0x180) from [] > (__driver_attach+0x68/0x8c) > r7:c789d140 r6:c038ada4 r5:c7910490 r4:c7910408 > [] (__driver_attach+0x0/0x8c) from [] > (bus_for_each_dev+0x4c/0x80) > r7:c789d140 r6:c038ada4 r5:c01dc7ec r4: > [] (bus_for_each_dev+0x0/0x80) from [] > (driver_attach+0x20/0x28) > r6:c038ada4 r5: r4: > [] (driver_attach+0x0/0x28) from [] > (bus_add_driver+0xa8/0x210) > [] (bus_add_driver+0x0/0x210) from [] > (driver_register+0x98/0x120) > r8:0001 r7:c001e814 r6:c038ada4 r5: r4:c0024a44 > [] (driver_register+0x0/0x120) from [] > (platform_driver_register+0x6c/0x88) > r9: r8:0001 r7:c001e814 r6: r5: > r4:c0024a44 > [] (platform_driver_reg
Re: PM branch rebased to 2.6.29
On Friday 20 March 2009, David Brownell wrote: > I may just prepare an mmc-twl4030 patch with ugly workarounds, > since I'm getting the strong feeling that it'll take forever > to get the regulator framework fixed in that area. I just sent that ... -- 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: PM branch rebased to 2.6.29
* Tony Lindgren [090320 12:56]: > * David Brownell [090320 12:46]: > > On Friday 20 March 2009, Tony Lindgren wrote: > > > * David Brownell [090319 15:27]: > > > > > > > > * Least hassle ... I think all these should merge to the > > > >linux-omap tree in any case (and thence linux-pm): > > > > > > > > http://marc.info/?l=linux-omap&m=123699264117846&w=2 > > > > http://marc.info/?l=linux-omap&m=123699340818395&w=2 > > > > http://marc.info/?l=linux-omap&m=123705919713239&w=2 > > > > > > Pushed these. That way we'll end up with a working > > > 2.6.29-omap1 :) > > > > I approve that message. ;) > > > > > > > Dave, got a version of the third patch above against the > > > mainline kernel? That could be added to the omap3-boards > > > queue for the upcoming merge window. > > > > That patch was a bit messy ... combined the VPLL2 bits, > > and the twl4030-power bits. The former can go to mainline, > > but only after the regulator framework updates for VPLL2; > > I'll make such a patch. The latter needs twl4030-power to > > get to mainline ... > > OK & thanks. > > > > > The second fix -- in some flavor -- is IMO still needed, > > > > since the first fix is just avoiding regulator framework > > > > bugs. > > > > > > To me it sounds like the regulator framework should eventually > > > handle the regulators left on by the bootloader. Just let me > > > know if some other patches are needed to l-o tree meanwhile. > > > > I may just prepare an mmc-twl4030 patch with ugly workarounds, > > since I'm getting the strong feeling that it'll take forever > > to get the regulator framework fixed in that area. > > > > Meanwhile, I suggest merging the updated version of the Overo > > patch, as sent by Steve. > > That should be now applied, looks like the MMC is still not > working though. Heh, user error.. I was missing CONFIG_REGULATOR in my .config. Works now. Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PM branch rebased to 2.6.29
* David Brownell [090320 12:46]: > On Friday 20 March 2009, Tony Lindgren wrote: > > * David Brownell [090319 15:27]: > > > > > > * Least hassle ... I think all these should merge to the > > >linux-omap tree in any case (and thence linux-pm): > > > > > > http://marc.info/?l=linux-omap&m=123699264117846&w=2 > > > http://marc.info/?l=linux-omap&m=123699340818395&w=2 > > > http://marc.info/?l=linux-omap&m=123705919713239&w=2 > > > > Pushed these. That way we'll end up with a working > > 2.6.29-omap1 :) > > I approve that message. ;) > > > > Dave, got a version of the third patch above against the > > mainline kernel? That could be added to the omap3-boards > > queue for the upcoming merge window. > > That patch was a bit messy ... combined the VPLL2 bits, > and the twl4030-power bits. The former can go to mainline, > but only after the regulator framework updates for VPLL2; > I'll make such a patch. The latter needs twl4030-power to > get to mainline ... OK & thanks. > > > The second fix -- in some flavor -- is IMO still needed, > > > since the first fix is just avoiding regulator framework > > > bugs. > > > > To me it sounds like the regulator framework should eventually > > handle the regulators left on by the bootloader. Just let me > > know if some other patches are needed to l-o tree meanwhile. > > I may just prepare an mmc-twl4030 patch with ugly workarounds, > since I'm getting the strong feeling that it'll take forever > to get the regulator framework fixed in that area. > > Meanwhile, I suggest merging the updated version of the Overo > patch, as sent by Steve. That should be now applied, looks like the MMC is still not working though. Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PM branch rebased to 2.6.29
On Friday 20 March 2009, Tony Lindgren wrote: > * David Brownell [090319 15:27]: > > > > * Least hassle ... I think all these should merge to the > >linux-omap tree in any case (and thence linux-pm): > > > > http://marc.info/?l=linux-omap&m=123699264117846&w=2 > > http://marc.info/?l=linux-omap&m=123699340818395&w=2 > > http://marc.info/?l=linux-omap&m=123705919713239&w=2 > > Pushed these. That way we'll end up with a working > 2.6.29-omap1 :) I approve that message. ;) > Dave, got a version of the third patch above against the > mainline kernel? That could be added to the omap3-boards > queue for the upcoming merge window. That patch was a bit messy ... combined the VPLL2 bits, and the twl4030-power bits. The former can go to mainline, but only after the regulator framework updates for VPLL2; I'll make such a patch. The latter needs twl4030-power to get to mainline ... > > The second fix -- in some flavor -- is IMO still needed, > > since the first fix is just avoiding regulator framework > > bugs. > > To me it sounds like the regulator framework should eventually > handle the regulators left on by the bootloader. Just let me > know if some other patches are needed to l-o tree meanwhile. I may just prepare an mmc-twl4030 patch with ugly workarounds, since I'm getting the strong feeling that it'll take forever to get the regulator framework fixed in that area. Meanwhile, I suggest merging the updated version of the Overo patch, as sent by Steve. - Dave -- 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: PM branch rebased to 2.6.29
* David Brownell [090319 15:27]: > On Tuesday 17 March 2009, Kevin Hilman wrote: > > - Beagle: MMC regulator: unbalanced disables. This happens on boot > > and during suspend/resume. I don't think this is related to the PM > > branch, but is probably in linux-omap HEAD also, but didn't test. > > It is. Other boards may see that too. Two fixes: > > * Least hassle ... I think all these should merge to the >linux-omap tree in any case (and thence linux-pm): > > http://marc.info/?l=linux-omap&m=123699264117846&w=2 > http://marc.info/?l=linux-omap&m=123699340818395&w=2 > http://marc.info/?l=linux-omap&m=123705919713239&w=2 Pushed these. That way we'll end up with a working 2.6.29-omap1 :) Dave, got a version of the third patch above against the mainline kernel? That could be added to the omap3-boards queue for the upcoming merge window. > * Or there are a number of regulator-framework patches >floating around, all of which fix the bug there... > > The root cause of this is that u-boot leaves VMMC1 active, > and the regulator framework doesn't cope with that yet. > The stackdump is basically caused by self-inconsistencies > in that framework. > > The first fix lets the twl4030-power driver (not yet on > track for mainline merge) undo that, so the regulator > framework will no longer be confused. That presumes a > bunch of board-specific patches fix that issue. (As > well as setting up other power resources, e.g. so that > CLKREQ behaves, which is the real goal of that patch.) > > The second fix -- in some flavor -- is IMO still needed, > since the first fix is just avoiding regulator framework > bugs. To me it sounds like the regulator framework should eventually handle the regulators left on by the bootloader. Just let me know if some other patches are needed to l-o tree meanwhile. Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PM branch rebased to 2.6.29
On Tuesday 17 March 2009, Kevin Hilman wrote: > - Beagle: MMC regulator: unbalanced disables. This happens on boot > and during suspend/resume. I don't think this is related to the PM > branch, but is probably in linux-omap HEAD also, but didn't test. It is. Other boards may see that too. Two fixes: * Least hassle ... I think all these should merge to the linux-omap tree in any case (and thence linux-pm): http://marc.info/?l=linux-omap&m=123699264117846&w=2 http://marc.info/?l=linux-omap&m=123699340818395&w=2 http://marc.info/?l=linux-omap&m=123705919713239&w=2 * Or there are a number of regulator-framework patches floating around, all of which fix the bug there... The root cause of this is that u-boot leaves VMMC1 active, and the regulator framework doesn't cope with that yet. The stackdump is basically caused by self-inconsistencies in that framework. The first fix lets the twl4030-power driver (not yet on track for mainline merge) undo that, so the regulator framework will no longer be confused. That presumes a bunch of board-specific patches fix that issue. (As well as setting up other power resources, e.g. so that CLKREQ behaves, which is the real goal of that patch.) The second fix -- in some flavor -- is IMO still needed, since the first fix is just avoiding regulator framework bugs. -- 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: PM branch rebased to 2.6.29
Artem Bityutskiy writes: > Kevin Hilman wrote: >> FYI... >> >> The PM branch has now been rebased to today's linux-omap HEAD which is >> based on v2.6.29-rc8. The previous PM branch has been renamed to >> pm-2.6.28. Depending on when you look, Tony's linux-omap tree may not >> (yet) have the latest PM branch. If not, you can use my PM tree[1] >> directly. Also, pm-2.6.28 will only be available on my tree. > > Sorry for ignorance, but in your PM tree the latest stuff is in > the pm branch, right? > Yes. The master branch of my tree just tracks linux-omap. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PM branch rebased to 2.6.29
Kevin Hilman wrote: FYI... The PM branch has now been rebased to today's linux-omap HEAD which is based on v2.6.29-rc8. The previous PM branch has been renamed to pm-2.6.28. Depending on when you look, Tony's linux-omap tree may not (yet) have the latest PM branch. If not, you can use my PM tree[1] directly. Also, pm-2.6.28 will only be available on my tree. Sorry for ignorance, but in your PM tree the latest stuff is in the pm branch, right? -- Best Regards, Artem Bityutskiy (Артём Битюцкий) -- 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 branch rebased to 2.6.29
FYI... The PM branch has now been rebased to today's linux-omap HEAD which is based on v2.6.29-rc8. The previous PM branch has been renamed to pm-2.6.28. Depending on when you look, Tony's linux-omap tree may not (yet) have the latest PM branch. If not, you can use my PM tree[1] directly. Also, pm-2.6.28 will only be available on my tree. Tested on OMAP3 Beagle and RX51 and was able to hit RET and OFF in suspend and in PM idle with minimal kernel. No testing yet done for CPUidle or DVFS. Please test on your hardware and submit results to the list. Thanks. Kevin -- Misc. conflicts/issues resolved after rebase: - no longer safe to use getnstimeofday() in suspend path since timekeeping subsystem is also suspended in the suspend path. PM debug timing has been converted to use sched_clock() which is 32k sync-timer based. - Update board-rx51.c to use common OMAP3 OPPs Known issues: - Beagle: MMC: off-mode needs work in MMC driver, so if you hit off and have a rootfs on MMC, you're dead. - Beagle: MMC regulator: unbalanced disables. This happens on boot and during suspend/resume. I don't think this is related to the PM branch, but is probably in linux-omap HEAD also, but didn't test. Linux version 2.6.29-rc8-omap1-arm-omap3beagle-default-05653-gd803372-dirty (khil...@vence) (gcc version 4.3.2 (Sourcery G++ Lite 2008q3-66) ) #4 PREEMPT Tue Mar 17 21:38:09 PDT 2009 [...] i2c_omap i2c_omap.1: bus 1 rev3.12 at 2600 kHz twl4030: PIH (irq 7) chaining IRQs 368..375 twl4030: power (irq 373) chaining IRQs 376..383 twl4030: gpio (irq 368) chaining IRQs 384..401 beagle_twl_gpio_setup:145 twl4030_mmc_init:303 twl4030_mmc_init:318 regulator: VMMC1: 1850 <--> 3150 mV normal standby regulator: VDAC: 1800 mV normal standby regulator: VUSB1V5: 1500 <--> 0 mV normal standby regulator: VUSB1V8: 1800 <--> 0 mV normal standby regulator: VUSB3V1: 3100 <--> 0 mV normal standby regulator: VSIM: 1800 <--> 3000 mV normal standby [...] mmci-omap-hs mmci-omap-hs.0: Failed to get debounce clock [ cut here ] WARNING: at /net/home/khilman/work/kernel/omap/pm/drivers/regulator/core.c:1216 regulator_disable+0x64/0x90() unbalanced disables for supply mmci-omap-hs.0-vmmc Modules linked in: [] (dump_stack+0x0/0x14) from [] (warn_slowpath+0x6c/0x88) [] (warn_slowpath+0x0/0x88) from [] (regulator_disable+0x64/0x90) r3:c79dc2a0 r2:c03390cb r7:c78e8c20 r6:c78aac38 r5:c78e8c20 r4:fffb [] (regulator_disable+0x0/0x90) from [] (mmc_regulator_set_ocr+0xb0/0xcc) r7:c78e8c20 r6:0001 r5: r4: [] (mmc_regulator_set_ocr+0x0/0xcc) from [] (twl_mmc1_set_power+0xc0/0xec) r7:c784f538 r6: r5: r4:c039185c [] (twl_mmc1_set_power+0x0/0xec) from [] (omap_mmc_set_ios+0x54/0x2b0) r7:c784f538 r6:c784f5c0 r5:c784f400 r4:c7844380 [] (omap_mmc_set_ios+0x0/0x2b0) from [] (mmc_power_off+0x54/0x58) r7:c784f400 r6:c7910400 r5: r4:c784f400 [] (mmc_power_off+0x0/0x58) from [] (mmc_start_host+0x14/0x24) [] (mmc_start_host+0x0/0x24) from [] (mmc_add_host+0x58/0x64) r5: r4:c784f400 [] (mmc_add_host+0x0/0x64) from [] (omap_mmc_probe+0x3d0/0x548) r5:c784f5c0 r4: [] (omap_mmc_probe+0x0/0x548) from [] (platform_drv_probe+0x20/0x24) [] (platform_drv_probe+0x0/0x24) from [] (driver_probe_device+0xd4/0x180) [] (driver_probe_device+0x0/0x180) from [] (__driver_attach+0x68/0x8c) r7:c789d140 r6:c038ada4 r5:c7910490 r4:c7910408 [] (__driver_attach+0x0/0x8c) from [] (bus_for_each_dev+0x4c/0x80) r7:c789d140 r6:c038ada4 r5:c01dc7ec r4: [] (bus_for_each_dev+0x0/0x80) from [] (driver_attach+0x20/0x28) r6:c038ada4 r5: r4: [] (driver_attach+0x0/0x28) from [] (bus_add_driver+0xa8/0x210) [] (bus_add_driver+0x0/0x210) from [] (driver_register+0x98/0x120) r8:0001 r7:c001e814 r6:c038ada4 r5: r4:c0024a44 [] (driver_register+0x0/0x120) from [] (platform_driver_register+0x6c/0x88) r9: r8:0001 r7:c001e814 r6: r5: r4:c0024a44 [] (platform_driver_register+0x0/0x88) from [] (omap_mmc_init+0x14/0x1c) [] (omap_mmc_init+0x0/0x1c) from [] (do_one_initcall+0x5c/0x19c) [] (do_one_initcall+0x0/0x19c) from [] (kernel_init+0x84/0xf8) r8: r7: r6: r5: r4:c0024a44 [] (kernel_init+0x0/0xf8) from [] (do_exit+0x0/0x764) r4: ---[ end trace e339700732a37a4d ]--- [.../ (none):~# echo 1 > /sys/power/clocks_off_while_idle (none):~# echo mem > /sys/power/state PM: Syncing filesystems ... done. Freezing user space processes ... (elapsed 0.00 seconds) done. Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done. Suspending console(s) (use no_console_suspend to debug) [ cut here ] WARNING: at /net/home/khilman/work/kernel/omap/pm/drivers/regulator/core.c:1216 regulator_disable+0x64/0x90() unbalanced disables for supply mmci-omap-hs.0-vmmc Modules linked in: [] (dump_stack+0x0/0x14) from [] (warn_slowpath+0x6c/0x88) [] (warn_slowpath+0x0/0x88) from
