Re: Alchemy power managment code.

[Sergei Shtylyov <sshtylyov@ru.mvista.com>]

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