Frequency (cpu speed) control on AU1100

Frequency (cpu speed) control on AU1100

[Bob Lees]

Hi All

I am working on an AU1100 board (Aurora) from DSP Design and want to control 
the processor cpu speed, as in CPU_FREQ, type control.  I suspect I am 
missing something somewhere, but I can't find any references to cpu speed 
control for the MIPS processors, specically the au1x range.

Any clues?

Thanks

Bob
-- 
Bob Lees
Diamond Consulting Services Ltd
Aylesbury, Bucks, HP17 8UG
Phone: +44 (0) 1296 747667
Fax: +44 (0) 1296 747557
email: bob@diamond.demon.co.uk

Re: Frequency (cpu speed) control on AU1100

[Pete Popov]

Bob Lees wrote:

>Hi All
>
>I am working on an AU1100 board (Aurora) from DSP Design and want to control 
>the processor cpu speed, as in CPU_FREQ, type control.  I suspect I am 
>missing something somewhere, but I can't find any references to cpu speed 
>control for the MIPS processors, specically the au1x range.
>
>Any clues?
>  
>
I assume you mean dynamically? Or at boot time only?

There is an Au1x power management implementation that I haven't tested 
in a while. It allows you to scale the frequency using sysctl, if I 
remember correctly.

Pete

Re: Frequency (cpu speed) control on AU1100

[Dan Malek]

Bob Lees wrote:

 > ....I suspect I am
> missing something somewhere, but I can't find any references to cpu speed 
> control for the MIPS processors, specically the au1x range.

The Au1xxx has a PLL that multiplies the incoming 12 MHz clock up to the
internal frequency.  Just be aware there are lots of peripheral clocks
and bus clocks derived from this internal frequency.  There is code
in the kernel power management to allow changing the frequency during
operation of Linux, but I don't know how well it works today as I have
not tested that for quite some time.

Thanks.


	-- Dan

Re: Frequency (cpu speed) control on AU1100

[Bob Lees]

On Tuesday 30 March 2004 22:56, Dan Malek wrote:
> Bob Lees wrote:
>  > ....I suspect I am
> >
> > missing something somewhere, but I can't find any references to cpu speed
> > control for the MIPS processors, specically the au1x range.
>
> The Au1xxx has a PLL that multiplies the incoming 12 MHz clock up to the
> internal frequency.  Just be aware there are lots of peripheral clocks
> and bus clocks derived from this internal frequency.  There is code
> in the kernel power management to allow changing the frequency during
> operation of Linux, but I don't know how well it works today as I have
> not tested that for quite some time.
>
> Thanks.
> 	-- Dan

Thanks Dan & Pete for the prompt response.  

I have tried the /proc/sys/pm/freq interface and by putting a bogomips calc 
into power.c, it appears to indicate a change in core frequency.  I think 
your caution may be well founded as I got input overruns on the serial 
console when I took the speed down to 84MHz, good character recognition 
though, so it was an input buffer speed issue.

Also I can see an approx 40-50mA change in current from 84 to 396MHz which 
indicates something is changing.  Supply is at 5 volts thru a simple switcher 
down to 3.3 volts on the Aurora board.  This is with nothing else running and 
an nfs filesystem.  As part of monitoring current I am seeing an anomoly: 
namely after boot is complete and system is quiesent, at apparently 396MHz, 
the current is 200mA, now after playing with the freq control the current at 
396MHz stabalises at around 250mA.  Verrry strange - any thoughts??

On another topic, what state is the IRDA driver in?  This is building from the 
patched 2.4.25 kernel on your site Dan.  And a big thank you for this source 
of a patched kernel and build tools.

Bob

Re: Frequency (cpu speed) control on AU1100

[Pete Popov]

Bob Lees wrote:

>On Tuesday 30 March 2004 22:56, Dan Malek wrote:
>  
>
>>Bob Lees wrote:
>> > ....I suspect I am
>>    
>>
>>>missing something somewhere, but I can't find any references to cpu speed
>>>control for the MIPS processors, specically the au1x range.
>>>      
>>>
>>The Au1xxx has a PLL that multiplies the incoming 12 MHz clock up to the
>>internal frequency.  Just be aware there are lots of peripheral clocks
>>and bus clocks derived from this internal frequency.  There is code
>>in the kernel power management to allow changing the frequency during
>>operation of Linux, but I don't know how well it works today as I have
>>not tested that for quite some time.
>>
>>Thanks.
>>	-- Dan
>>    
>>
>
>Thanks Dan & Pete for the prompt response.  
>
>I have tried the /proc/sys/pm/freq interface and by putting a bogomips calc 
>into power.c, it appears to indicate a change in core frequency.  I think 
>your caution may be well founded as I got input overruns on the serial 
>console when I took the speed down to 84MHz, good character recognition 
>though, so it was an input buffer speed issue.
>
>Also I can see an approx 40-50mA change in current from 84 to 396MHz which 
>indicates something is changing.  Supply is at 5 volts thru a simple switcher 
>down to 3.3 volts on the Aurora board.  This is with nothing else running and 
>an nfs filesystem.  As part of monitoring current I am seeing an anomoly: 
>namely after boot is complete and system is quiesent, at apparently 396MHz, 
>the current is 200mA, now after playing with the freq control the current at 
>396MHz stabalises at around 250mA.  Verrry strange - any thoughts??
>  
>
Is the 250mA after you've done a new power cycle, which doesn't make 
sense, or after you scale down to 84 and back up to 396MHz?

>On another topic, what state is the IRDA driver in?  
>
It works. Check out the IrDA readme on 
linux-mips.org:/pub/linux/mips/people/ppopov/2.4. I've tested two boards 
back to back using the network layer at FIR speeds, and a board to palm 
pilot using SIR. It's all in the readme.

>This is building from the 
>patched 2.4.25 kernel on your site Dan.  And a big thank you for this source 
>of a patched kernel and build tools.
>  
>

Pete

Re: Frequency (cpu speed) control on AU1100

[Dan Malek]

Bob Lees wrote:

> Also I can see an approx 40-50mA change in current from 84 to 396MHz which 
> indicates something is changing. 

Uh oh.....You are looking for power saving by dynamically slowing the
processor?  Just enable CONFIG_PM and let it enter its low power wait
at idle.  Certainly the easiest way to save power.  Also, power management
is a whole system design consideration.  Unless you are using an x86
processor, the peripheral logic in a system is going to be much more
of a power mangement problem than the processor.  Low voltage power
conversion and LCD backlights are the killers, not the processor.
If you are using things like Ethernet PHYs in the product, take a close
look at how they can be used in power saving modes.  The AMD PHYs
are particularly good at this, others may be as well, and do the same
kind of analysis for all of the parts on the board.

If you are changing the processor speed, you are going to have to
look carefully how it affects the system bus and the SDRAM timing.
The list goes on.....effective power management is tedious and
challenging...been there, done that quite a bit with this
particular processor.  It's very system dependent.  The stuff in
the Linux kernel is a good starting point, but everything from
the applications to the additions you will have to make in the
kernel are going to be required.

Have fun!


	-- Dan

Re: Frequency (cpu speed) control on AU1100

[Bob Lees]

On Tuesday 30 March 2004 23:48, Pete Popov wrote:
> Bob Lees wrote:
> >On Tuesday 30 March 2004 22:56, Dan Malek wrote:
> >>Bob Lees wrote:
> >> > ....I suspect I am
> >>>
> >>>missing something somewhere, but I can't find any references to cpu
> >>> speed control for the MIPS processors, specically the au1x range.
> >>
> >>The Au1xxx has a PLL that multiplies the incoming 12 MHz clock up to the
> >>internal frequency.  Just be aware there are lots of peripheral clocks
> >>and bus clocks derived from this internal frequency.  There is code
> >>in the kernel power management to allow changing the frequency during
> >>operation of Linux, but I don't know how well it works today as I have
> >>not tested that for quite some time.
> >>
> >>Thanks.
> >>	-- Dan
> >
> >Thanks Dan & Pete for the prompt response.
> >
> >I have tried the /proc/sys/pm/freq interface and by putting a bogomips
> > calc into power.c, it appears to indicate a change in core frequency.  I
> > think your caution may be well founded as I got input overruns on the
> > serial console when I took the speed down to 84MHz, good character
> > recognition though, so it was an input buffer speed issue.
> >
> >Also I can see an approx 40-50mA change in current from 84 to 396MHz which
> >indicates something is changing.  Supply is at 5 volts thru a simple
> > switcher down to 3.3 volts on the Aurora board.  This is with nothing
> > else running and an nfs filesystem.  As part of monitoring current I am
> > seeing an anomoly: namely after boot is complete and system is quiesent,
> > at apparently 396MHz, the current is 200mA, now after playing with the
> > freq control the current at 396MHz stabalises at around 250mA.  Verrry
> > strange - any thoughts??
>
> Is the 250mA after you've done a new power cycle, which doesn't make
> sense, or after you scale down to 84 and back up to 396MHz?

After I scale down to 84 and back up to 396MHz.  Having seen Dan's comments 
which I largely agree with I may not play with the speed after all!!  Having 
said that I would like to find out why we are seeing this behaviour.  It 
could well be that the frequency switching is disrupting one of the clocks 
and/or the PM which is running on power up.

We already recognise that the peripherals play as much if not a greater part 
in the overall power consumption.

>
> >On another topic, what state is the IRDA driver in?
>
> It works. Check out the IrDA readme on
> linux-mips.org:/pub/linux/mips/people/ppopov/2.4. I've tested two boards
> back to back using the network layer at FIR speeds, and a board to palm
> pilot using SIR. It's all in the readme.

OK I have this and will have a play.
>
> >This is building from the
> >patched 2.4.25 kernel on your site Dan.  And a big thank you for this
> > source of a patched kernel and build tools.
>
> Pete

Bob