Subject: FW: Alchemy power managment code.

From: "Nico Coesel" <[email-masked]>
Date: Thu, 13 Mar 2008 17:16:37 +0100

Ralf,
Funny you ask because I tried this yesterday on a AU1100 system with the
2.6.24 kernel (from kernel.org). I'm afraid I must say the kernel
crashes when I enable power management. The reason I want to use power
management is because I need to send the CPU to sleep when the system
shuts down. I hacked power.c and reset.c a bit so au_sleep() is called
when the system is shut down. Perhaps someone can confirm the
powermanagement can be made to work with some fixes (it didn't work with
2.6.21-rc4 either).

The CPU frequency switching stuff isn't very usefull since it is
possible to derive various pheripheral frequencies from it. For
instance, on our board the LCD frequency is derived from the CPU
frequency. The auxilary frequency cannot by divided to provide the
refreshrate we need. So changing the CPU frequency would 'break' our LCD
display.

Nico Coesel 

> -----Oorspronkelijk bericht-----
> Van: [email-masked] 
> [mailto:[email-masked]] Namens Ralf Baechle
> Verzonden: donderdag 13 maart 2008 14:56
> Aan: [email-masked]
> Onderwerp: Alchemy power managment code.
> 
> The Alchemy code in arch/mips/au1000/common/power.c is one of the last

> remaining users of pm_send_all() which happens to be a nop call 
> because nothing registers callbacks with pm_register.  So the 
> pm_send_all() calls can be removed.
> 
> Which leaves pm_do_suspend with no sensible code, so it can be 
> removed.
> And ripped like this pm_do_sleep looks it it may well no longer be 
> functioning.
> 
> So, anybody still using that stuff, does it provide any useful 
> functionality?  Does the CPU frequency stuff actually work?
> 
>   Ralf
> 
> PS: You should hear the engine of my chainsaw warming up ...
> 
>

---

From: Sergei Shtylyov <[email-masked]>
Date: Thu, 13 Mar 2008 19:45:10 +0300

Hello.

> powermanagement can be made to work with some fixes (it didn't work with

    BTW, if you look at sleeper.S you'll find that save_and_sleep() trashes 
registers $1 and $2 because of reusing their stackframe slots to save Status 
and Context CP0 registers:

         sw      $1, PT_R1(sp)
         sw      $2, PT_R2(sp)

         mfc0    k0, CP0_STATUS
         sw      k0, 0x20(sp)		# equals PT_R2
         mfc0    k0, CP0_CONTEXT
         sw      k0, 0x1c(sp)		# equals PT_R1

> Nico Coesel 

WBR, Sergei

---

From: Sergei Shtylyov <[email-masked]>
Date: Mon, 24 Mar 2008 17:23:44 +0300

Hello.

> powermanagement can be made to work with some fixes (it didn't work with

    The TOY cpunter 0 clockevent driver is also need to be written for the 
recent kernel as CP0 timer stops ticking after wait insn is executed -- see 
arch/mips/au1000/common/time.c...

WBR, Sergei

---

From: Sergei Shtylyov <[email-masked]>
Date: Mon, 24 Mar 2008 17:31:39 +0300

I just wrote:

  >    The TOY cpunter 0 clockevent driver is also need to be written for
> the recent kernel as CP0 timer stops ticking after wait insn is executed 
> -- see arch/mips/au1000/common/time.c...

    And here's found another possible issue with Alchemy PM -- the CP0 counter 
counts at unpredictable frequency in idle state (after executing "wait"), so 
the MIPS clocksource will probably be unstable?

WBR, Sergei

---

From: Sergei Shtylyov <[email-masked]>
Date: Wed, 26 Mar 2008 19:31:55 +0300

Hello all.

> powermanagement can be made to work with some fixes (it didn't work with

    BTW, for anybody interested in Alchemy PM code, here's the interesting
link: [ftp|http]://ftp.enneenne.com/pub/misc/au1100-patches/linux/.
    It contains  a lot of unmerged PM patches by Rodolfo Giometti (and not
only that) from around 2.6.17 time.

WBR, Sergei

---

From: Ralf Baechle <[email-masked]>
Date: Thu, 27 Mar 2008 22:31:35 +0000

On Mon, Mar 24, 2008 at 05:31:39PM +0300, Sergei Shtylyov wrote:

>    And here's found another possible issue with Alchemy PM -- the CP0 
> counter counts at unpredictable frequency in idle state (after executing 
> "wait"), so the MIPS clocksource will probably be unstable?

Correct - and cevt-r4k won't be usable either.  I guess that means you
leave the user the choice between either these two or using wait.  Not
nice but ...

  Ralf

---

From: Ralf Baechle <[email-masked]>
Date: Thu, 27 Mar 2008 22:32:47 +0000

> only that) from around 2.6.17 time.

Anybody interested in reviewing these patches and polishing them to be
applied to a recent kernel?

  Ralf

---

From: Sergei Shtylyov <[email-masked]>
Date: Fri, 28 Mar 2008 14:36:08 +0300

Hello.

> leave the user the choice between either these two or using wait.  Not

    The Alchemy code doesn't even try to use CP0 counter when CONFIG_PM=y if 
you look into arch/mips/au1000/common/time.c... or at least it didn't before 
Atsushi removed do_fast_pm_gettimeoffset().

WBR, Sergei

---

From: Sergei Shtylyov <[email-masked]>
Date: Fri, 28 Mar 2008 14:39:58 +0300

> applied to a recent kernel?

    I am, at least to some extent. But I'm not sure I'll have enough time from 
now on. Should have started earlier...

WBR, Sergei

---

From: Ralf Baechle <[email-masked]>
Date: Fri, 28 Mar 2008 13:32:43 +0000

On Fri, Mar 28, 2008 at 02:36:08PM +0300, Sergei Shtylyov wrote:

> you look into arch/mips/au1000/common/time.c... or at least it didn't 
> before Atsushi removed do_fast_pm_gettimeoffset().

That decission is now done by the generic time.c based only on the
availability of a counter and the mfc0 $count bug.

  Ralf

---

From: Atsushi Nemoto <[email-masked]>
Date: Fri, 28 Mar 2008 23:25:27 +0900 (JST)

> Atsushi removed do_fast_pm_gettimeoffset().

Oh, yes. At that time I tried to implement clocksource drivers for
non-standard timers, but it seems I had missied Alchemy PM=y case.

The driver would be something like this?  Completely untested ;-)

static cycle_t au1000_hpt_read(void)
{
	return au_readl(SYS_TOYREAD);
}

struct clocksource au1000_clocksource = {
	.name	= "au1000-counter",
	.rating	= 200,
	.read	= au1000_hpt_read,
	.mask	= CLOCKSOURCE_MASK(32),
	.flags	= CLOCK_SOURCE_IS_CONTINUOUS,
};

void __init au1000_clocksource_init(unsinged long cpu_speed)
{
	struct clocksource *cs = &au1000_clocksource;

	clocksource_set_clock(cs, cpu_speed);
	clocksource_register(cs);
}

---
Atsushi Nemoto

---

From: Sergei Shtylyov <[email-masked]>
Date: Fri, 28 Mar 2008 18:14:36 +0300

Hello.

> 	.name	= "au1000-counter",

    Rating should be greater than that of CP0 counter...

> 	clocksource_set_clock(cs, cpu_speed);

    Not really, it's clocked by 32768 Hz input, so probably not very good as a 
clocksource.

WBR, Sergei