S3C6410 power management support status

S3C6410 power management support status

[Yauhen Kharuzhy]

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?

S3C6410 power management support status

[tommy.hong]

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>

S3C6410 power management support status

[Mark Brown]

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?

S3C6410 power management support status

[Yauhen Kharuzhy]

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

S3C6410 power management support status

[Ben Dooks]

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.

S3C6410 power management support status

[Ben Dooks]

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.

S3C6410 power management support status

[Ben Dooks]

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.

S3C6410 power management support status

[Yauhen Kharuzhy]

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

S3C6410 power management support status

[Ben Dooks]

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.

S3C6410 power management support status

[Ben Dooks]

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.

S3C6410 power management support status

[Yauhen Kharuzhy]

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?

S3C6410 power management support status

[Ben Dooks]

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.