From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ryan Underwood Subject: Re: writing a cpufreq driver Date: Thu, 21 Sep 2006 15:08:51 -0500 Message-ID: <20060921200851.GF2364@dbz.icequake.net> References: <20060921184833.GC1216@dbz.icequake.net> <20060921193141.GE17065@redhat.com> Reply-To: nemesis@icequake.net Mime-Version: 1.0 Return-path: Content-Disposition: inline In-Reply-To: <20060921193141.GE17065@redhat.com> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: cpufreq-bounces@lists.linux.org.uk Errors-To: cpufreq-bounces+glkc-cpufreq=gmane.org+glkc-cpufreq=gmane.org@lists.linux.org.uk Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Dave Jones Cc: Cpufreq@lists.linux.org.uk, nemesis@icequake.net On Thu, Sep 21, 2006 at 03:31:41PM -0400, Dave Jones wrote: > > > > 1. The first time cpufreq changes speed, I get the whole "Losing some > > ticks... checking if CPU frequency changed." then eventually "Losing too > > many ticks!" and timer switches to PIT. This does not happen when I use > > the /dev/toshiba driver to change speeds from userspace. Not sure what > > is going on here... SMI handler latency is between 6 and 7 ms. > > Is loops_per_jiffy being correctly scaled on a speed transition? No, because only the firmware knows what the real CPU speeds are. How would I deal with this? > > 2. The current CPU frequency is stored in NVRAM by the SMI handler. > > Wow, that's umm, crap :-} Yup > > Unfortunately, this means if cpufreq throttles the CPU and the system is > > then rebooted, the boot process is exceedingly slow. Is there some sane > > way to hook into the shutdown process to restore the appropriate values, > > or is this something I have to live with? > > See register_reboot_notifier() That should do it. Thanks! -- Ryan Underwood,