On Thu, Jul 17, 2003 at 01:57:21AM +0100, Miguel Sousa Filipe wrote:
> > CC arch/ppc/platforms/pmac_nvram.o
> > CC arch/ppc/platforms/pmac_cpufreq.o
> >arch/ppc/platforms/pmac_cpufreq.c: In function `do_set_cpu_speed':
> >arch/ppc/platforms/pmac_cpufreq.c:179: `CPUFREQ_ALL_CPUS' undeclared
> >(first use in this function)
> >arch/ppc/platforms/pmac_cpufreq.c:179: (Each undeclared identifier is
> >reported only once
> >arch/ppc/platforms/pmac_cpufreq.c:179: for each function it appears in.)
> >make[1]: *** [arch/ppc/platforms/pmac_cpufreq.o] Error 1
> >make: *** [arch/ppc/platforms] Error 2
> >
This means that the driver hasn't been updated for the new cpufreq API changes.
CPUFREQ_ALL_CPUS is deprecated, as is the /proc interface (which is what
proc_intf.c references), since now the sysfs interface is preferred.
The pmac_cpufreq.c driver will likely need to be updated a bit (which may
already be done in the LinuxPPC trees) in order to build or function.
Notably, the verify stuff needs to be changed around quite a bit, since instead
of doing the range validation and wrapping to cpufreq_verify_within_limits(), a
frequency table is built up instead and subsequently passed through
cpufreq_frequency_table_verify(). Take a look at some of the existing cpufreq
drivers that are up-to-date for ideas on how to do this (most of the i386 ones,
the SuperH one, and probably others).
As such, you can either look at updating the driver (if this hasn't already
been done by the LinuxPPC folk), or you can just not build it in. Probably no
good things will happen if you hack it to the point of building and then
attempt to use it.
This archive was generated by hypermail 2b29 : Wed Jul 23 2003 - 22:00:27 EST