San Mehat san@google.com writes:
Nice stuff.. what happened to get_apicid_base()? :)
linuxbios_ram.o(.text+0x7909): In function `smp_write_config_table': : undefined reference to `get_apicid_base'
An evolving understanding of what needs to happen.
We first replaced it in our tree with a function called max_lapicid() that worked by looking at the device tree to see which apicid's had already been used by the cpus.
For small cpu counts and small numbers of ioapics that worked well.
Then along came the observation that in all legacy apics and ioapics only id's 0-15 are valid. Currently most ioapics still have this limitation where the cpus can be assigned id's 0-255.
Currently this is a problem for boards like the island/aruma which have 14 io_apics and 4 cpus, or boards with 8 processor sockets which can hold dual-core cpus.
So it was realized that for a general purpose solution the cpus apicid must always be lifted. So we made the formula for the cpus apicid 0x10 + coreid*0x10 + nodeid. Which works consistently and should work for everyone. Unless someone has a buggy kernel which can't cope.
With all of the apicid's of the cpus above 16 max_lapicid() was redundant and actually strongly incorrect for using to compute the apicid_base, which we needed to place below 15. So we dropped the patch that fixed up all of the references to get_apicid_base, to max_lapicid instead.
It just became apparent that we needed to either not kill get_apicid_base or to have fixed up all of the references to apicid_base with something else.
The simple correct solution is to just hardcode apicid_base to 1, for the boards that use it.
The clean solution and probably what we want long term is a function that places the ioapics in the device tree and assigns them the lowest free ioapicid. That code could probably move out of the mother board files into the chipset specific code. One more step along the lines of clean interrupt handling.
Eric