* S3C6410 power management support status
@ 2010-04-29 12:45 Yauhen Kharuzhy
2010-04-29 12:58 ` tommy.hong
` (2 more replies)
0 siblings, 3 replies; 12+ messages in thread
From: Yauhen Kharuzhy @ 2010-04-29 12:45 UTC (permalink / raw)
To: linux-arm-kernel
Hi.
Can anybody explain current status of S3C6410 power management support
in mainline? Suspend-to-RAM looks completely broken in the current
Linus's git tree.
--
Yauhen Kharuzhy jekhor _at_ gmail.com
JID: jek at jabber.ru
A: No
Q: Should I quote below my post?
^ permalink raw reply [flat|nested] 12+ messages in thread* S3C6410 power management support status 2010-04-29 12:45 S3C6410 power management support status Yauhen Kharuzhy @ 2010-04-29 12:58 ` tommy.hong 2010-05-04 0:26 ` Ben Dooks 2010-04-29 14:00 ` Mark Brown 2010-05-04 0:24 ` Ben Dooks 2 siblings, 1 reply; 12+ messages in thread From: tommy.hong @ 2010-04-29 12:58 UTC (permalink / raw) To: linux-arm-kernel hi,Sir.Please fix VFP Bug,who is exsited in Samsung 2.6.24.2 BSP relative. arch/arm/kerne/entry-armv.S (2.6.24.2 BSP) B.R Tommy 2010/4/29 Yauhen Kharuzhy <yauhen.kharuzhy@promwad.com> > Hi. > > Can anybody explain current status of S3C6410 power management support > in mainline? Suspend-to-RAM looks completely broken in the current > Linus's git tree. > > > -- > Yauhen Kharuzhy jekhor _at_ gmail.com > JID: jek at jabber.ru > > A: No > Q: Should I quote below my post? > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel at lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > -- concentrate for work && keep calm and carry on,Achievement provides the only real pleasure in life! -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20100429/d63a4be0/attachment-0001.htm> -------------- next part -------------- A non-text attachment was scrubbed... Name: entry-armv.S Type: application/octet-stream Size: 27895 bytes Desc: not available URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20100429/d63a4be0/attachment-0001.obj> ^ permalink raw reply [flat|nested] 12+ messages in thread
* S3C6410 power management support status 2010-04-29 12:58 ` tommy.hong @ 2010-05-04 0:26 ` Ben Dooks 0 siblings, 0 replies; 12+ messages in thread From: Ben Dooks @ 2010-05-04 0:26 UTC (permalink / raw) To: linux-arm-kernel On Thu, Apr 29, 2010 at 08:58:53PM +0800, tommy.hong wrote: > hi,Sir.Please fix VFP Bug,who is exsited in Samsung 2.6.24.2 BSP relative. > > arch/arm/kerne/entry-armv.S (2.6.24.2 BSP) This isn't the samsung-inhouse kernel support list. I don't think many people here actually care about non-mainline kernels. Secondly, please don't tag new threads onto previous postings about a different subject. -- Ben Q: What's a light-year? A: One-third less calories than a regular year. ^ permalink raw reply [flat|nested] 12+ messages in thread
* S3C6410 power management support status 2010-04-29 12:45 S3C6410 power management support status Yauhen Kharuzhy 2010-04-29 12:58 ` tommy.hong @ 2010-04-29 14:00 ` Mark Brown 2010-04-29 14:52 ` Yauhen Kharuzhy 2010-05-04 0:24 ` Ben Dooks 2 siblings, 1 reply; 12+ messages in thread From: Mark Brown @ 2010-04-29 14:00 UTC (permalink / raw) To: linux-arm-kernel On Thu, Apr 29, 2010 at 03:45:09PM +0300, Yauhen Kharuzhy wrote: > Can anybody explain current status of S3C6410 power management support > in mainline? Suspend-to-RAM looks completely broken in the current > Linus's git tree. What problems are you experiencing? ^ permalink raw reply [flat|nested] 12+ messages in thread
* S3C6410 power management support status 2010-04-29 14:00 ` Mark Brown @ 2010-04-29 14:52 ` Yauhen Kharuzhy 2010-05-04 0:29 ` Ben Dooks 0 siblings, 1 reply; 12+ messages in thread From: Yauhen Kharuzhy @ 2010-04-29 14:52 UTC (permalink / raw) To: linux-arm-kernel On Thu, Apr 29, 2010 at 03:00:51PM +0100, Mark Brown wrote: > On Thu, Apr 29, 2010 at 03:45:09PM +0300, Yauhen Kharuzhy wrote: > > > Can anybody explain current status of S3C6410 power management support > > in mainline? Suspend-to-RAM looks completely broken in the current > > Linus's git tree. > > What problems are you experiencing? 1. I enabled RTC driver for S3C6410 (it is cannot be enabled without modification of Kconfig) and CONFIG_SUSPEND. 2. echo +10 > /sys/class/rtc0/wakealarm && echo mem > /sys/power/state. System didn't go to sleep with messages: --- s3c_pm_enter(3) s3c_pm_enter: No wake-up sources! s3c_pm_enter: Aborting sleep --- This is caused by following code: --- #define any_allowed(mask, allow) (((mask) & (allow)) != (allow)) if (!any_allowed(s3c_irqwake_intmask, s3c_irqwake_intallow) && !any_allowed(s3c_irqwake_eintmask, s3c_irqwake_eintallow)) { printk(KERN_ERR "%s: No wake-up sources!\n", __func__); printk(KERN_ERR "%s: Aborting sleep\n", __func__); return -EINVAL; } --- But s3c_irqwake_intallow is defined in arch/arm/mach-s3c64xx/include/mach/pm-core.h --- /* make these defines, we currently do not have any need to change * the IRQ wake controls depending on the CPU we are running on */ #define s3c_irqwake_eintallow ((1 << 28) - 1) #define s3c_irqwake_intallow (0) --- -- Yauhen Kharuzhy ----------------------------------------------------------- Promwad Innovation Company 22, Olshevskogo St. Office 809 220073, Minsk, Belarus Phone/Fax: +375 (17) 312-1246 E-mail: yauhen.kharuzhy@promwad.com Skype: jekhor Web: www.promwad.com ^ permalink raw reply [flat|nested] 12+ messages in thread
* S3C6410 power management support status 2010-04-29 14:52 ` Yauhen Kharuzhy @ 2010-05-04 0:29 ` Ben Dooks 0 siblings, 0 replies; 12+ messages in thread From: Ben Dooks @ 2010-05-04 0:29 UTC (permalink / raw) To: linux-arm-kernel On Thu, Apr 29, 2010 at 05:52:57PM +0300, Yauhen Kharuzhy wrote: > On Thu, Apr 29, 2010 at 03:00:51PM +0100, Mark Brown wrote: > > On Thu, Apr 29, 2010 at 03:45:09PM +0300, Yauhen Kharuzhy wrote: > > > > > Can anybody explain current status of S3C6410 power management support > > > in mainline? Suspend-to-RAM looks completely broken in the current > > > Linus's git tree. > > > > What problems are you experiencing? > > 1. I enabled RTC driver for S3C6410 (it is cannot be enabled without > modification of Kconfig) and CONFIG_SUSPEND. > 2. echo +10 > /sys/class/rtc0/wakealarm && echo mem > /sys/power/state. > > System didn't go to sleep with messages: > > --- > s3c_pm_enter(3) > s3c_pm_enter: No wake-up sources! > s3c_pm_enter: Aborting sleep > --- Ok, this is interesting, the system shouldn't have allowed the RTC as a wakeup soruce as the core currently doesn't deal with 64XX non-EINT sources. However, at-least the core code did the right thing and refused to go to sleep. I will look into the RTC/non-EINT wakeup sources for these SoCs today and see if the changes are easy enough to make. > This is caused by following code: > --- > #define any_allowed(mask, allow) (((mask) & (allow)) != (allow)) > > if (!any_allowed(s3c_irqwake_intmask, s3c_irqwake_intallow) && > !any_allowed(s3c_irqwake_eintmask, s3c_irqwake_eintallow)) { > printk(KERN_ERR "%s: No wake-up sources!\n", __func__); > printk(KERN_ERR "%s: Aborting sleep\n", __func__); > return -EINVAL; > } > --- > > But s3c_irqwake_intallow is defined in arch/arm/mach-s3c64xx/include/mach/pm-core.h > > --- > /* make these defines, we currently do not have any need to change > * the IRQ wake controls depending on the CPU we are running on */ > > #define s3c_irqwake_eintallow ((1 << 28) - 1) > #define s3c_irqwake_intallow (0) > --- They'll get changed once we have support for the non-eint sources. -- Ben Q: What's a light-year? A: One-third less calories than a regular year. ^ permalink raw reply [flat|nested] 12+ messages in thread
* S3C6410 power management support status 2010-04-29 12:45 S3C6410 power management support status Yauhen Kharuzhy 2010-04-29 12:58 ` tommy.hong 2010-04-29 14:00 ` Mark Brown @ 2010-05-04 0:24 ` Ben Dooks 2010-05-06 14:49 ` Yauhen Kharuzhy 2 siblings, 1 reply; 12+ messages in thread From: Ben Dooks @ 2010-05-04 0:24 UTC (permalink / raw) To: linux-arm-kernel On Thu, Apr 29, 2010 at 03:45:09PM +0300, Yauhen Kharuzhy wrote: > Hi. > > Can anybody explain current status of S3C6410 power management support > in mainline? Suspend-to-RAM looks completely broken in the current > Linus's git tree. I'd prefer if you didn't make sweeping accusations about the state of a given piece of the kernel without having a good look first. From reading your second post, it seems that what is actually the problem is that the 64XX support only currently handles wakeup configurations from the EINT pins. -- Ben Q: What's a light-year? A: One-third less calories than a regular year. ^ permalink raw reply [flat|nested] 12+ messages in thread
* S3C6410 power management support status 2010-05-04 0:24 ` Ben Dooks @ 2010-05-06 14:49 ` Yauhen Kharuzhy 2010-05-10 0:58 ` Ben Dooks 2010-05-10 2:35 ` Ben Dooks 0 siblings, 2 replies; 12+ messages in thread From: Yauhen Kharuzhy @ 2010-05-06 14:49 UTC (permalink / raw) To: linux-arm-kernel On Tue, May 04, 2010 at 01:24:20AM +0100, Ben Dooks wrote: > On Thu, Apr 29, 2010 at 03:45:09PM +0300, Yauhen Kharuzhy wrote: > > Hi. > > > > Can anybody explain current status of S3C6410 power management support > > in mainline? Suspend-to-RAM looks completely broken in the current > > Linus's git tree. > > I'd prefer if you didn't make sweeping accusations about the state of > a given piece of the kernel without having a good look first. From reading > your second post, it seems that what is actually the problem is that the > 64XX support only currently handles wakeup configurations from the EINT > pins. I am sorry for my hasty opinion about StR. But we have checked Suspend-to-RAM at our (custom, not SMDK) board just now and it is not works with EINT too. Kernel goes to sleep and never return. We found that XPWRRGTON pin isn't changed at sleep instruction execution so CPU don't go to sleep state. If anybody can say something about reasons of this, please say. Can anybody check suspend mode with SMDK6410 and confirm that StR works on it? If it works, we will stop to ask stupid questions and will find our hardware bugs :) Below is log of sleeping procedure: ----------------------------------------------------------------------- /sys/power # echo mem > state s3c64xx_irq_pm_suspend: suspending IRQs saved f4500280 value 000003ff saved f4500900 value 00400000 saved f4500904 value 00000000 saved f4500910 value 00000000 saved f4500914 value 00000000 saved f4500918 value 00000000 saved f450091c value 00000000 saved f4500920 value 0ffff7ff saved f4300044 value 00000210 s3c_pm_enter(3) s3c_sleep_save_phys=0x503cac18 GPA: save 00000000,22222222,0000007a,00002955 GPB: save 00000000,02212222,0000007b,00002955 GPC: save 00000000,11331000,00000010,00005055 GPD: save 00000000,00000000,00000000,00000155 GPE: save 00000000,00000000,00000000,00000155 GPF: save 50000000,00008000,55555555,00000000 GPG: save 00000000,03222222,0000003e,00002000 GPH: save 33222222,00000033,000003fe,00000000 GPI: save aaaaaaaa,00000000,00000000,00000000 GPJ: save 00aaaaaa,00000f00,00000000,00000000 GPK: save 22222222,22222222,00000000,55555555 GPL: save 12121122,02222211,0000038c,15555555 GPM: save 00000000,00222222,0000001f,000002aa GPN: save 55940454,0000f81a,55955555,00000000 GPO: save aaaaaaaa,0000003f,00000000,00000000 GPP: save 2aaaaaaa,000038e7,1011aaa0,00000000 GPQ: save 0002aaaa,00000018,00000000,00000000 UART[0]: ULCON=0007, UCON=0785, UFCON=0011, UBRDIV=0000 UART[1]: ULCON=002b, UCON=0385, UFCON=0011, UBRDIV=0003 UART[2]: ULCON=0003, UCON=0385, UFCON=0011, UBRDIV=001f UART[3]: ULCON=0007, UCON=0785, UFCON=0011, UBRDIV=0000 saved f4100100 value 04000000 saved f4100104 value 00000000 saved f4100108 value 00000000 saved f45001a0 value ffcd1501 saved f45001b0 value 00000000 saved f45001b4 value 00000000 saved f45001c0 value 00000000 saved f45001c4 value 00000000 saved f45001c8 value 00000000 saved f4100000 value 0000ffff saved f4100004 value 0000ffff saved f4100008 value 0000ffff saved f410001c value 00000007 saved f4100020 value 01043310 saved f4100024 value 00000000 saved f4100028 value 00000000 saved f410002c value 00000000 saved f4100030 value fffffff7 saved f4100034 value fb9e6fff saved f4100038 value c73fffff saved f410003c value ffffffff saved f4100018 value 00000000 saved f4100014 value 00200203 saved f45001d0 value 10555551 saved f45001d4 value 00555555 sleep: irq wakeup masks: ffffffff,fffff7ff ------------------------------------------------------------------------------ -- Yauhen Kharuzhy ----------------------------------------------------------- Promwad Innovation Company 22, Olshevskogo St. Office 809 220073, Minsk, Belarus Phone/Fax: +375 (17) 312-1246 E-mail: yauhen.kharuzhy at promwad.com Skype: jekhor Web: www.promwad.com ^ permalink raw reply [flat|nested] 12+ messages in thread
* S3C6410 power management support status 2010-05-06 14:49 ` Yauhen Kharuzhy @ 2010-05-10 0:58 ` Ben Dooks 2010-05-10 2:35 ` Ben Dooks 1 sibling, 0 replies; 12+ messages in thread From: Ben Dooks @ 2010-05-10 0:58 UTC (permalink / raw) To: linux-arm-kernel On Thu, May 06, 2010 at 05:49:55PM +0300, Yauhen Kharuzhy wrote: > On Tue, May 04, 2010 at 01:24:20AM +0100, Ben Dooks wrote: > > On Thu, Apr 29, 2010 at 03:45:09PM +0300, Yauhen Kharuzhy wrote: > > > Hi. > > > > > > Can anybody explain current status of S3C6410 power management support > > > in mainline? Suspend-to-RAM looks completely broken in the current > > > Linus's git tree. > > > > I'd prefer if you didn't make sweeping accusations about the state of > > a given piece of the kernel without having a good look first. From reading > > your second post, it seems that what is actually the problem is that the > > 64XX support only currently handles wakeup configurations from the EINT > > pins. > > I am sorry for my hasty opinion about StR. > > But we have checked Suspend-to-RAM at our (custom, not SMDK) board just now > and it is not works with EINT too. Kernel goes to sleep and never > return. We found that XPWRRGTON pin isn't > changed at sleep instruction execution so CPU don't go to sleep state. If anybody > can say something about reasons of this, please say. Hmm, this is interesting if as your log says it should have managed to get through to the point it wants to go to sleep. > Can anybody check suspend mode with SMDK6410 and confirm that StR works > on it? If it works, we will stop to ask stupid questions and will find > our hardware bugs :) I'll run the latest -rc through a smdk6410 today and see what happens. It worked last tiem it was tested, but that was a couple of kernel revisions ago and something may have gotten borked since then. > Below is log of sleeping procedure: > ----------------------------------------------------------------------- > /sys/power # echo mem > state > s3c64xx_irq_pm_suspend: suspending IRQs > saved f4500280 value 000003ff > saved f4500900 value 00400000 > saved f4500904 value 00000000 > saved f4500910 value 00000000 > saved f4500914 value 00000000 > saved f4500918 value 00000000 > saved f450091c value 00000000 > saved f4500920 value 0ffff7ff > saved f4300044 value 00000210 > s3c_pm_enter(3) > s3c_sleep_save_phys=0x503cac18 > GPA: save 00000000,22222222,0000007a,00002955 > GPB: save 00000000,02212222,0000007b,00002955 > GPC: save 00000000,11331000,00000010,00005055 > GPD: save 00000000,00000000,00000000,00000155 > GPE: save 00000000,00000000,00000000,00000155 > GPF: save 50000000,00008000,55555555,00000000 > GPG: save 00000000,03222222,0000003e,00002000 > GPH: save 33222222,00000033,000003fe,00000000 > GPI: save aaaaaaaa,00000000,00000000,00000000 > GPJ: save 00aaaaaa,00000f00,00000000,00000000 > GPK: save 22222222,22222222,00000000,55555555 > GPL: save 12121122,02222211,0000038c,15555555 > GPM: save 00000000,00222222,0000001f,000002aa > GPN: save 55940454,0000f81a,55955555,00000000 > GPO: save aaaaaaaa,0000003f,00000000,00000000 > GPP: save 2aaaaaaa,000038e7,1011aaa0,00000000 > GPQ: save 0002aaaa,00000018,00000000,00000000 > UART[0]: ULCON=0007, UCON=0785, UFCON=0011, UBRDIV=0000 > UART[1]: ULCON=002b, UCON=0385, UFCON=0011, UBRDIV=0003 > UART[2]: ULCON=0003, UCON=0385, UFCON=0011, UBRDIV=001f > UART[3]: ULCON=0007, UCON=0785, UFCON=0011, UBRDIV=0000 > saved f4100100 value 04000000 > saved f4100104 value 00000000 > saved f4100108 value 00000000 > saved f45001a0 value ffcd1501 > saved f45001b0 value 00000000 > saved f45001b4 value 00000000 > saved f45001c0 value 00000000 > saved f45001c4 value 00000000 > saved f45001c8 value 00000000 > saved f4100000 value 0000ffff > saved f4100004 value 0000ffff > saved f4100008 value 0000ffff > saved f410001c value 00000007 > saved f4100020 value 01043310 > saved f4100024 value 00000000 > saved f4100028 value 00000000 > saved f410002c value 00000000 > saved f4100030 value fffffff7 > saved f4100034 value fb9e6fff > saved f4100038 value c73fffff > saved f410003c value ffffffff > saved f4100018 value 00000000 > saved f4100014 value 00200203 > saved f45001d0 value 10555551 > saved f45001d4 value 00555555 > sleep: irq wakeup masks: ffffffff,fffff7ff -- Ben Q: What's a light-year? A: One-third less calories than a regular year. ^ permalink raw reply [flat|nested] 12+ messages in thread
* S3C6410 power management support status 2010-05-06 14:49 ` Yauhen Kharuzhy 2010-05-10 0:58 ` Ben Dooks @ 2010-05-10 2:35 ` Ben Dooks 2010-05-10 14:27 ` Yauhen Kharuzhy 1 sibling, 1 reply; 12+ messages in thread From: Ben Dooks @ 2010-05-10 2:35 UTC (permalink / raw) To: linux-arm-kernel On Thu, May 06, 2010 at 05:49:55PM +0300, Yauhen Kharuzhy wrote: > On Tue, May 04, 2010 at 01:24:20AM +0100, Ben Dooks wrote: > > On Thu, Apr 29, 2010 at 03:45:09PM +0300, Yauhen Kharuzhy wrote: > > > Hi. > > > > > > Can anybody explain current status of S3C6410 power management support > > > in mainline? Suspend-to-RAM looks completely broken in the current > > > Linus's git tree. > > > > I'd prefer if you didn't make sweeping accusations about the state of > > a given piece of the kernel without having a good look first. From reading > > your second post, it seems that what is actually the problem is that the > > 64XX support only currently handles wakeup configurations from the EINT > > pins. > > I am sorry for my hasty opinion about StR. > > But we have checked Suspend-to-RAM at our (custom, not SMDK) board just now > and it is not works with EINT too. Kernel goes to sleep and never > return. We found that XPWRRGTON pin isn't > changed at sleep instruction execution so CPU don't go to sleep state. If anybody > can say something about reasons of this, please say. Just tested 2.6.34-rc6-git and it works on the SMDK6410 with the addition of the gpio buttons for EINT9..11, and it worked. Can post the patches or git tree if you like. > Can anybody check suspend mode with SMDK6410 and confirm that StR works > on it? If it works, we will stop to ask stupid questions and will find > our hardware bugs :) It does seem to work on this SMDK, and the XPWRTGON line on TP7 definetly goes low during sleep. Note, not sure if I will post the buttons patches as the SMDK's single buttons share interrupts with the LAN and other devices, making them rather useless (my SMDK6410 has EINT10 held permanently active by the unused network devices...) > Below is log of sleeping procedure: > ----------------------------------------------------------------------- > /sys/power # echo mem > state > s3c64xx_irq_pm_suspend: suspending IRQs > saved f4500280 value 000003ff > saved f4500900 value 00400000 > saved f4500904 value 00000000 > saved f4500910 value 00000000 > saved f4500914 value 00000000 > saved f4500918 value 00000000 > saved f450091c value 00000000 > saved f4500920 value 0ffff7ff > saved f4300044 value 00000210 > s3c_pm_enter(3) > s3c_sleep_save_phys=0x503cac18 > GPA: save 00000000,22222222,0000007a,00002955 > GPB: save 00000000,02212222,0000007b,00002955 > GPC: save 00000000,11331000,00000010,00005055 > GPD: save 00000000,00000000,00000000,00000155 > GPE: save 00000000,00000000,00000000,00000155 > GPF: save 50000000,00008000,55555555,00000000 > GPG: save 00000000,03222222,0000003e,00002000 > GPH: save 33222222,00000033,000003fe,00000000 > GPI: save aaaaaaaa,00000000,00000000,00000000 > GPJ: save 00aaaaaa,00000f00,00000000,00000000 > GPK: save 22222222,22222222,00000000,55555555 > GPL: save 12121122,02222211,0000038c,15555555 > GPM: save 00000000,00222222,0000001f,000002aa > GPN: save 55940454,0000f81a,55955555,00000000 > GPO: save aaaaaaaa,0000003f,00000000,00000000 > GPP: save 2aaaaaaa,000038e7,1011aaa0,00000000 > GPQ: save 0002aaaa,00000018,00000000,00000000 > UART[0]: ULCON=0007, UCON=0785, UFCON=0011, UBRDIV=0000 > UART[1]: ULCON=002b, UCON=0385, UFCON=0011, UBRDIV=0003 > UART[2]: ULCON=0003, UCON=0385, UFCON=0011, UBRDIV=001f > UART[3]: ULCON=0007, UCON=0785, UFCON=0011, UBRDIV=0000 > saved f4100100 value 04000000 > saved f4100104 value 00000000 > saved f4100108 value 00000000 > saved f45001a0 value ffcd1501 > saved f45001b0 value 00000000 > saved f45001b4 value 00000000 > saved f45001c0 value 00000000 > saved f45001c4 value 00000000 > saved f45001c8 value 00000000 > saved f4100000 value 0000ffff > saved f4100004 value 0000ffff > saved f4100008 value 0000ffff > saved f410001c value 00000007 > saved f4100020 value 01043310 > saved f4100024 value 00000000 > saved f4100028 value 00000000 > saved f410002c value 00000000 > saved f4100030 value fffffff7 > saved f4100034 value fb9e6fff > saved f4100038 value c73fffff > saved f410003c value ffffffff > saved f4100018 value 00000000 > saved f4100014 value 00200203 > saved f45001d0 value 10555551 > saved f45001d4 value 00555555 > sleep: irq wakeup masks: ffffffff,fffff7ff > ------------------------------------------------------------------------------ > > -- > Yauhen Kharuzhy > ----------------------------------------------------------- > Promwad Innovation Company > 22, Olshevskogo St. > Office 809 > 220073, Minsk, Belarus > Phone/Fax: +375 (17) 312-1246 > E-mail: yauhen.kharuzhy at promwad.com > Skype: jekhor > Web: www.promwad.com > -- > To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in > the body of a message to majordomo at vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- -- Ben Q: What's a light-year? A: One-third less calories than a regular year. ^ permalink raw reply [flat|nested] 12+ messages in thread
* S3C6410 power management support status 2010-05-10 2:35 ` Ben Dooks @ 2010-05-10 14:27 ` Yauhen Kharuzhy 2010-05-11 0:20 ` Ben Dooks 0 siblings, 1 reply; 12+ messages in thread From: Yauhen Kharuzhy @ 2010-05-10 14:27 UTC (permalink / raw) To: linux-arm-kernel On Mon, May 10, 2010 at 03:35:37AM +0100, Ben Dooks wrote: > > Can anybody check suspend mode with SMDK6410 and confirm that StR works > > on it? If it works, we will stop to ask stupid questions and will find > > our hardware bugs :) > > It does seem to work on this SMDK, and the XPWRTGON line on TP7 definetly > goes low during sleep. > > Note, not sure if I will post the buttons patches as the SMDK's single > buttons share interrupts with the LAN and other devices, making them > rather useless (my SMDK6410 has EINT10 held permanently active by the > unused network devices...) Thanks for your help. Last question: which U-Boot (or another bootloader) you use? -- Yauhen Kharuzhy jekhor _at_ gmail.com JID: jek at jabber.ru A: No Q: Should I quote below my post? ^ permalink raw reply [flat|nested] 12+ messages in thread
* S3C6410 power management support status 2010-05-10 14:27 ` Yauhen Kharuzhy @ 2010-05-11 0:20 ` Ben Dooks 0 siblings, 0 replies; 12+ messages in thread From: Ben Dooks @ 2010-05-11 0:20 UTC (permalink / raw) To: linux-arm-kernel On Mon, May 10, 2010 at 05:27:22PM +0300, Yauhen Kharuzhy wrote: > On Mon, May 10, 2010 at 03:35:37AM +0100, Ben Dooks wrote: > > > Can anybody check suspend mode with SMDK6410 and confirm that StR works > > > on it? If it works, we will stop to ask stupid questions and will find > > > our hardware bugs :) > > > > It does seem to work on this SMDK, and the XPWRTGON line on TP7 definetly > > goes low during sleep. > > > > Note, not sure if I will post the buttons patches as the SMDK's single > > buttons share interrupts with the LAN and other devices, making them > > rather useless (my SMDK6410 has EINT10 held permanently active by the > > unused network devices...) > > Thanks for your help. Last question: which U-Boot (or another > bootloader) you use? The uboot supplied on this SMDK. -- Ben Q: What's a light-year? A: One-third less calories than a regular year. ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2010-05-11 0:20 UTC | newest] Thread overview: 12+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2010-04-29 12:45 S3C6410 power management support status Yauhen Kharuzhy 2010-04-29 12:58 ` tommy.hong 2010-05-04 0:26 ` Ben Dooks 2010-04-29 14:00 ` Mark Brown 2010-04-29 14:52 ` Yauhen Kharuzhy 2010-05-04 0:29 ` Ben Dooks 2010-05-04 0:24 ` Ben Dooks 2010-05-06 14:49 ` Yauhen Kharuzhy 2010-05-10 0:58 ` Ben Dooks 2010-05-10 2:35 ` Ben Dooks 2010-05-10 14:27 ` Yauhen Kharuzhy 2010-05-11 0:20 ` Ben Dooks
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).