Alchemy power managment code.

Alchemy power managment code.

[Ralf Baechle]

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 ...

FW: Alchemy power managment code.

[Nico Coesel]

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: linux-mips-bounce@linux-mips.org 
> [mailto:linux-mips-bounce@linux-mips.org] Namens Ralf Baechle
> Verzonden: donderdag 13 maart 2008 14:56
> Aan: linux-mips@linux-mips.org
> 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 ...
> 
> 

FW: Alchemy power managment code.

[Nico Coesel]

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: linux-mips-bounce@linux-mips.org 
> [mailto:linux-mips-bounce@linux-mips.org] Namens Ralf Baechle
> Verzonden: donderdag 13 maart 2008 14:56
> Aan: linux-mips@linux-mips.org
> 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 ...
> 
> 

Re: FW: Alchemy power managment code.

[Sergei Shtylyov]

Hello.

Nico Coesel wrote:

> 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).

    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

Re: FW: Alchemy power managment code.

[Sergei Shtylyov]

Hello.

Nico Coesel wrote:

> 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 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

Re: FW: Alchemy power managment code.

[Sergei Shtylyov]

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

Re: FW: Alchemy power managment code.

[Sergei Shtylyov]

Hello all.

Nico Coesel wrote:

> 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).

    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.

> Nico Coesel 

WBR, Sergei

Re: FW: Alchemy power managment code.

[Ralf Baechle]

On Mon, Mar 24, 2008 at 05:31:39PM +0300, Sergei Shtylyov 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?

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

Re: FW: Alchemy power managment code.

[Ralf Baechle]

On Wed, Mar 26, 2008 at 07:31:55PM +0300, Sergei Shtylyov wrote:

>> 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).
>
>    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.

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

  Ralf

Re: FW: Alchemy power managment code.

[Sergei Shtylyov]

Hello.

Ralf Baechle 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?

> 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 ...

    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().

>   Ralf

WBR, Sergei

Re: FW: Alchemy power managment code.

[Sergei Shtylyov]

Ralf Baechle wrote:

>>>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).

>>   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.

> Anybody interested in reviewing these patches and polishing them to be
> 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...

>   Ralf

WBR, Sergei

Re: FW: Alchemy power managment code.

[Ralf Baechle]

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

>    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().

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

  Ralf

Re: Alchemy power managment code.

[Atsushi Nemoto]

On Fri, 28 Mar 2008 14:36:08 +0300, Sergei Shtylyov <sshtylyov@ru.mvista.com> wrote:
> > 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 ...
> 
>     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().

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

Re: Alchemy power managment code.

[Sergei Shtylyov]

Hello.

Atsushi Nemoto wrote:

>>>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 ...

>>    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().

> 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,

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

> 	.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);

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

> 	clocksource_register(cs);
> }

WBR, Sergei

RE: Alchemy power managment code.

[Nico Coesel]

> -----Oorspronkelijk bericht-----
> Van: Sergei Shtylyov [mailto:sshtylyov@ru.mvista.com] 
> Verzonden: vrijdag 28 maart 2008 16:15
> Aan: Atsushi Nemoto
> CC: ralf@linux-mips.org; linux-mips@linux-mips.org; Nico Coesel
> Onderwerp: Re: Alchemy power managment code.
> 
> Hello.
> 
> Atsushi Nemoto wrote:
> 
> >>>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 ...
> 
> >>    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().
> 
> > 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,
> 
>     Rating should be greater than that of CP0 counter...
> 
> > 	.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);
> 
>     Not really, it's clocked by 32768 Hz input, so probably 
> not very good as a clocksource.

Why not? If a 32768Hz watch crystal is connected then you'll have a
stable clocksource. IIRC watch crystals are more precise than the
crystals used to generate the core frequency.
 
Nico Coesel

RE: Alchemy power managment code.

[Nico Coesel]

> -----Oorspronkelijk bericht-----
> Van: Sergei Shtylyov [mailto:sshtylyov@ru.mvista.com] 
> Verzonden: vrijdag 28 maart 2008 16:15
> Aan: Atsushi Nemoto
> CC: ralf@linux-mips.org; linux-mips@linux-mips.org; Nico Coesel
> Onderwerp: Re: Alchemy power managment code.
> 
> Hello.
> 
> Atsushi Nemoto wrote:
> 
> >>>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 ...
> 
> >>    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().
> 
> > 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,
> 
>     Rating should be greater than that of CP0 counter...
> 
> > 	.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);
> 
>     Not really, it's clocked by 32768 Hz input, so probably 
> not very good as a clocksource.

Why not? If a 32768Hz watch crystal is connected then you'll have a
stable clocksource. IIRC watch crystals are more precise than the
crystals used to generate the core frequency.
 
Nico Coesel

Re: Alchemy power managment code.

[Sergei Shtylyov]

Nico Coesel wrote:

>>>>>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 ...

>>>>   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().

>>>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,

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

>>>	.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);

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

> Why not? If a 32768Hz watch crystal is connected then you'll have a
> stable clocksource. IIRC watch crystals are more precise than the
> crystals used to generate the core frequency.

    32 KHz is too low a frequency. The same goes about using TOY as a 
clockevent -- HRT boasts microsecond resoultion which TOY can't provide.

> Nico Coesel

WBR, Sergei