Re: 2.6.0-test1 doesn't compile on PPC iBook2.2

[Miguel Sousa Filipe <m3thos@netcabo.pt>]

Paul Mundt wrote:
> 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.
> 

Thanks for the feedback, where do i find the LinuxPPC 2.6.x tree?
Would like to have a look before everything else...


Miguel Sousa Filipe