[PATCH 5/5] ARM: S5PV210: Initial CPUFREQ Support

On Fri, Jul 16, 2010 at 05:30:03PM +0900, MyungJoo Ham wrote:

On Fri, Jul 16, 2010 at 5:17 PM, Mark Brown

quoted

...the ramp times are usually vanishingly small so the overwhelming
majority of consumers probably don't care anyway. ?If it's a problem we
can add an interface which doesn't do the delay automatically but for
most users it's going to be simpler to just deal with it transparently.

It's about 30us in this driver (100MHz -> 1GHz), where we lost about
60000 instructions (2 instructions / cycle @ 100MHz, with default RAMP
UP of 10mV/us). However, let's assume that it's ok for now.

Is the ramp actually required for systems?  The obvious thought here is
that if the ramp time can be reduced or eliminated by configuring the
regulator it'd be better to do that.

quoted

Ah, OK. ?If other people use that sort of clocking scheme we will need
to come up with a reasonable way of coping with it, but let's save that
for when the problem arises.

Such people may use cpufreq_notify_transition(freq,
CPUFREQ_PRECHANGE/POSTCHANGE). Some display drivers have been using
this feature to adjust clock settings when APLL clock speed changes.
Sound drivers with CLK_OUT should've used that, too.

Depending on how the clocking is integrated it might need to be bound a
bit tighter to the CPU management code, though.  If it's supplying a
clock for the CPU then it may need the CPU to be quiesced before you can
alter the output.