linux-mips
[Top] [All Lists]

Re: FW: Alchemy power managment code.

To: Ralf Baechle <ralf@linux-mips.org>
Subject: Re: FW: Alchemy power managment code.
From: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Date: Fri, 28 Mar 2008 14:36:08 +0300
Cc: linux-mips@linux-mips.org, Nico Coesel <ncoesel@DEALogic.nl>
In-reply-to: <20080327223134.GA26997@linux-mips.org>
Organization: MontaVista Software Inc.
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <19CA9E279FDA5246B7D7A1C91A4AF7F40EF804@dealogicserver.DEALogic.nl> <47E7B970.30105@ru.mvista.com> <47E7BB4B.3080507@ru.mvista.com> <20080327223134.GA26997@linux-mips.org>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.2) Gecko/20040803
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

<Prev in Thread] Current Thread [Next in Thread>