FW: Alchemy power managment code.

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.

[Nico Coesel]

> -----Oorspronkelijk bericht-----
> Van: Sergei Shtylyov [mailto:sshtylyov@ru.mvista.com] 
> Verzonden: woensdag 26 maart 2008 17:32
> Aan: Nico Coesel
> CC: linux-mips@linux-mips.org
> Onderwerp: Re: FW: Alchemy power managment code.
> 
> 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.
> 

Sergei,
Is there a reason why these patches didn't make it into the official
kernel? IIRC Rodolfo has been quite active on this mailing list.

Nico Coesel

RE: FW: Alchemy power managment code.

[Nico Coesel]

> -----Oorspronkelijk bericht-----
> Van: Sergei Shtylyov [mailto:sshtylyov@ru.mvista.com] 
> Verzonden: woensdag 26 maart 2008 17:32
> Aan: Nico Coesel
> CC: linux-mips@linux-mips.org
> Onderwerp: Re: FW: Alchemy power managment code.
> 
> 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.
> 

Sergei,
Is there a reason why these patches didn't make it into the official
kernel? IIRC Rodolfo has been quite active on this mailing list.

Nico Coesel

Re: FW: Alchemy power managment code.

[Sergei Shtylyov]

Nico Coesel wrote:

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

> Sergei,
> Is there a reason why these patches didn't make it into the official
> kernel? IIRC Rodolfo has been quite active on this mailing list.

    Keywords are "on this mailing list" -- most of his patches were for other 
mailing lists (e.g. he did much to support PM in the peripheral drivers but 
never pushed that stuff to the respective maintainers AFAIK). He just wasn't 
consistent about the upstream submission.

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

[Ralf Baechle]

On Thu, Mar 27, 2008 at 02:46:50PM +0100, Nico Coesel wrote:

> >     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.
> > 
> 
> Sergei,
> Is there a reason why these patches didn't make it into the official
> kernel? IIRC Rodolfo has been quite active on this mailing list.

At times it simply takes nagging me :)

  Ralf

RE: FW: Alchemy power managment code.

[Nico Coesel]

> -----Oorspronkelijk bericht-----
> Van: Ralf Baechle [mailto:ralf@linux-mips.org] 
> Verzonden: donderdag 27 maart 2008 23:33
> Aan: Sergei Shtylyov
> CC: Nico Coesel; linux-mips@linux-mips.org
> Onderwerp: Re: FW: Alchemy power managment code.
> 
> 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

I guess I will have to, but it will probably be somewhere near the end
of April. Also, I'm leaning towards only fixing the TOY timer during
sleep so the clock keeps running. IMHO this should be standard behaviour
which does not depend on power management.

Are diffs against 2.6.24 any good to you guys? The timer stuff Sergei
seems to be working on right now also sounds interesting. Perhaps I'll
patch my kernel with the timer patches from Sergei and apply (some of)
Rodolfo's patches afterwards. I assume there will be quite some overlap
in these patches.

Nico Coesel
 

RE: FW: Alchemy power managment code.

[Nico Coesel]

> -----Oorspronkelijk bericht-----
> Van: Ralf Baechle [mailto:ralf@linux-mips.org] 
> Verzonden: donderdag 27 maart 2008 23:33
> Aan: Sergei Shtylyov
> CC: Nico Coesel; linux-mips@linux-mips.org
> Onderwerp: Re: FW: Alchemy power managment code.
> 
> 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

I guess I will have to, but it will probably be somewhere near the end
of April. Also, I'm leaning towards only fixing the TOY timer during
sleep so the clock keeps running. IMHO this should be standard behaviour
which does not depend on power management.

Are diffs against 2.6.24 any good to you guys? The timer stuff Sergei
seems to be working on right now also sounds interesting. Perhaps I'll
patch my kernel with the timer patches from Sergei and apply (some of)
Rodolfo's patches afterwards. I assume there will be quite some overlap
in these patches.

Nico Coesel
 

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