Timer Interrupt

Timer Interrupt

[Bharathi Subramanian]

Hi all,

We are trying to implement the CPU Clock down feature for saving the 
power. In this process, Whenever the CPU is put in 1/2 Clock then the 
Timer interrupt is also getting delayed.

Later I found that CPU Counter is used to generate the timer intr. How 
to make the Timer interrupt to happen at every 10ms, even if the CPU 
is in 1/2, 1/4 or 1/8 of the original clock??

Processor: MIPS 4Kc 32B

Thanks :)
-- 
Bharathi S

Re: Timer Interrupt

[Bharathi Subramanian]

On Mon, 16 Jan 2006, Bharathi Subramanian wrote:

> We are trying to implement the CPU Clock down feature for saving the 
> power. In this process, Whenever the CPU is put in 1/2 Clock then the 
> Timer interrupt is also getting delayed.
> 
> Later I found that CPU Counter is used to generate the timer intr. How 
> to make the Timer interrupt to happen at every 10ms, even if the CPU 
> is in 1/2, 1/4 or 1/8 of the original clock??
> 
> Processor: MIPS 4Kc 32B
  Kernel   : 2.4.20

In mips_timer_ack() function, the new Compare reg value loaded. Here I 
tried to put new counter value based on the present cpu clock divder 
setting. But board is getting rebooted.

Is it the right way to handle this issue?? Anybody faced same 
condition, kindly share your exprience with me.

Thanks,
-- 
Bharathi S

Re: Timer Interrupt

[Bharathi Subramanian]

On Tue, 17 Jan 2006, Bharathi Subramanian wrote:

> On Mon, 16 Jan 2006, Bharathi Subramanian wrote:
> 
> > We are trying to implement the CPU Clock down feature for saving the 
> > power. In this process, Whenever the CPU is put in 1/2 Clock then the 
> > Timer interrupt is also getting delayed.
> > 
> > Later I found that CPU Counter is used to generate the timer intr. How 
> > to make the Timer interrupt to happen at every 10ms, even if the CPU 
> > is in 1/2, 1/4 or 1/8 of the original clock??
> > 
> > Processor: MIPS 4Kc 32B
>   Kernel   : 2.4.20 with RTLinux Patch
> 
> In mips_timer_ack() function, the new Compare reg value loaded. Here I 
> tried to put new counter value based on the present cpu clock divder 
> setting. But board is getting rebooted.
> 
> Is it the right way to handle this issue?? Anybody faced same
> condition, kindly share your exprience with me.

I read the Linux Porting guide by Junsun. In that,(s)he mention, "Some
CPUs may have a variable CPU frequency which makes CPU counter not
usable as a timer source". Does it mean that, we can't do the CPU
Clock down in MIPS Processor??

Kindly CC the reply.

Thanks :)
-- 
Bharathi S

Re: Timer Interrupt

[Kevin D. Kissell]

> On Tue, 17 Jan 2006, Bharathi Subramanian wrote:
> 
> > On Mon, 16 Jan 2006, Bharathi Subramanian wrote:
> > 
> > > We are trying to implement the CPU Clock down feature for saving the 
> > > power. In this process, Whenever the CPU is put in 1/2 Clock then the 
> > > Timer interrupt is also getting delayed.
> > > 
> > > Later I found that CPU Counter is used to generate the timer intr. How 
> > > to make the Timer interrupt to happen at every 10ms, even if the CPU 
> > > is in 1/2, 1/4 or 1/8 of the original clock??
> > > 
> > > Processor: MIPS 4Kc 32B
> >   Kernel   : 2.4.20 with RTLinux Patch
> > 
> > In mips_timer_ack() function, the new Compare reg value loaded. Here I 
> > tried to put new counter value based on the present cpu clock divder 
> > setting. But board is getting rebooted.
> > 
> > Is it the right way to handle this issue?? Anybody faced same
> > condition, kindly share your exprience with me.
> 
> I read the Linux Porting guide by Junsun. In that,(s)he mention, "Some
> CPUs may have a variable CPU frequency which makes CPU counter not
> usable as a timer source". Does it mean that, we can't do the CPU
> Clock down in MIPS Processor??

Some systems have variable CPU frequencies that are invisible to software,
in which case a CPU counter would not be very usefule as a timer source.
If your CPU clock mode is programmable, as it is on most MIPS systems
of which I'm aware, it just means that you have to keep your Count register
programming synchronized with the clock mode.

You were on the right track when you tried hacking mips_timer_ack(),
but note that both cycles_per_jiffy and mips_hpt_frequency end up being
used in Count-based time calculations.  If the board is rebooting when you
tested your mod, it's probably because there's an error or a typo in your code.

Note that just changing the Count register increment will result in some
small error each time the clock mode changes, because the new increment
won't take effect until the next interrupt goes off. which will be some random
interval after the CPU clock divisor has changed.  If that's a real issue, 
you can reduce the error to a few cycles if you really want to go to the
trouble of sampling the Count register and re-computing the Compare value
when you change the CPU clock mode.

        Regards,

        Kevin K.

Re: Timer Interrupt

[Bharathi Subramanian]

On Tue, 17 Jan 2006, Kevin D. Kissell wrote:

> > CPUs may have a variable CPU frequency which makes CPU counter not
> > usable as a timer source". Does it mean that, we can't do the CPU
> > Clock down in MIPS Processor??

> You were on the right track when you tried hacking mips_timer_ack(),
> but note that both cycles_per_jiffy and mips_hpt_frequency end up
> being used in Count-based time calculations.  If the board is
> rebooting when you tested your mod, it's probably because there's an
> error or a typo in your code.

Maybe. Started checking it by added few prink() to see the values of 
my_cycle_per_jiffy, cycles_per_jiffy and mips_hpt_frequency.

> Note that just changing the Count register increment will result in
> some small error each time the clock mode changes,

This is not an major probelm. But as you indicated, I will make some
modification in PMU driver to takecare the drift.

Thanks,
-- 
Bharathi S

Re: Timer Interrupt

[Bharathi Subramanian]

On Tue, 17 Jan 2006, Kevin D. Kissell wrote:

> You were on the right track when you tried hacking mips_timer_ack(),
> but note that both cycles_per_jiffy and mips_hpt_frequency end up
> being used in Count-based time calculations.

I fixed the CPU Clock down and Timer interrupt problem like this:

static void c0_timer_ack(void)
{
  int count;
 /* Bharathi: To maintain the Timer in clock down mode.
  * cpu_clk_change is set by PMU Driver */

 if(test_and_clear_bit(0, &cpu_clk_change))
 {
   READ_REG( PMU_CLKMODE, cpu_clk_div);
   /* Divide the orginal timer count */
   my_cycles_per_jiffy = cycles_per_jiffy >> (cpu_clk_divA);
 }
 /* Ack this timer interrupt and set the next one. */
 expirelo += my_cycles_per_jiffy;
 write_c0_compare(expirelo);

 /* Check to see if we have missed any timer interrupts. */
 count = read_c0_count();

 if ((count - expirelo) < 0x7fffffff) {
    expirelo = count + my_cycles_per_jiffy;
    write_c0_compare(expirelo);
 }
}

NOTE:

0. cpu_clk_change is global, static and exported to access in PMU Drv.

1. In time_init(), set my_cycles_per_jiffy = cycles_per_jiffy to
   handle initial state.

2. If needed, Change the SDRAM Refresh Rate during clk dwn.

3. Force few uSec delay after clock-up for smooth & stable transition.

4. I am NOT an expert in Kernel/MIPS. Feel free to correct me.

Kindly CC me.

Thanks :)
-- 
Bharathi S

/dev/cpuid or /proc/cpuinfo

[Philip Mucci]

Hello MIPSers,

In reference to the performance counting thread we had going earlier,
I've noticed a 'feature' I need out of MIPS/Linux that isn't currently
available. This has also recently come up on the oprofile list with one
of the oprofile/mips tools not being able to grab cpu Mhz
from /proc/cpuinfo because it's not there.

I have need to execute the mfc0 instruction on the config register and
grok the results to find out things like cache size etc. In addition, it
might be nice to also actually be able to find out the clock rate.
(Currently I grab BogoMIPS and punt.)

On the intel and PPC systems, I believe you can execute similar
instructions from user mode which makes things easy. However, of course
an MFC0 is a privileged instruction...meaning that if the value or
values aren't found in /proc/cpuinfo, I'm s.o.l.

What does the list think about this? Making a mips /dev/cpuid is a bit
gross but extending and grokking /proc/cpuinfo is perhaps grosser...and
many tools do just this (like PAPI and oprofile's opreport...)

Comments? I'm certainly willing to implement this, but I'd rather 'do it
right the first time' rather than get rotten vegetables thrown my way.

Phil

Re: /dev/cpuid or /proc/cpuinfo

[Ralf Baechle]

On Mon, Jan 30, 2006 at 06:54:29PM +0000, Philip Mucci wrote:

> In reference to the performance counting thread we had going earlier,
> I've noticed a 'feature' I need out of MIPS/Linux that isn't currently
> available. This has also recently come up on the oprofile list with one
> of the oprofile/mips tools not being able to grab cpu Mhz
> from /proc/cpuinfo because it's not there.

Surprise - the kernel doesn't actually have that information.  The closest
available would be the counting speed of the c0 count register which - if
something like that is available at all - could be calibrated against an
external counter to figure out the clock speed.  To complicate matters
not all processors have have a c0 counter, it's sometimes incrementing
every cycle but it might just as well counting at half the clock rate and
oh yes, more recently there is clock scaling.

> I have need to execute the mfc0 instruction on the config register and
> grok the results to find out things like cache size etc. In addition, it
> might be nice to also actually be able to find out the clock rate.
> (Currently I grab BogoMIPS and punt.)

Considering above complexities a BogoMIPS-based approach doesn't sound too
bad - but it has other problem to implement since it requires knowing the
exact execution timing.  A think that could be done is meassuring two
loops containing a different number of nops and use that to compute the
execution time for the loop closing branch.  Now knowing that based on
knowing the # of cycles per loop we can compute the clock speed - all it
takes is a timer running at a known speed.

A funny complexity is that some multiprocessor MIPS systems have processors
running at different speeds.  So knowing the clock rate doesn't make life
too much easier ;-)

> On the intel and PPC systems, I believe you can execute similar
> instructions from user mode which makes things easy. However, of course
> an MFC0 is a privileged instruction...meaning that if the value or
> values aren't found in /proc/cpuinfo, I'm s.o.l.

We have a long tradition of emulating instructions, could use that to
permit access to a bunch of cp0 registers from userland ;)

> What does the list think about this? Making a mips /dev/cpuid is a bit
> gross but extending and grokking /proc/cpuinfo is perhaps grosser...and
> many tools do just this (like PAPI and oprofile's opreport...)
> 
> Comments? I'm certainly willing to implement this, but I'd rather 'do it
> right the first time' rather than get rotten vegetables thrown my way.

/proc/cpuinfo is meant to have per processor information so I don't have
a problem with adding cache configuration information.  I was considering
to do so to make such information available for bug reports.

  Ralf