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

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.

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

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