Hi,
I am always sceptical when manufactueres won't release the source code for their drivers, or when they won't document the hardware suffciently for someone else to write drivers. It seems likely to me that in many of these cases, features which are claimed for the hardware concerned are actually implemented in the driver and the manufacturer would rather you didn't know that.
Anyway, back to the problem at hand....
The first thing I would try doing is to use modprobe to load the ft.o module rather than insmod. Modprobe will examine the dependancies of the module your are trying to load and load any modules it depends on first. You could then use lsmod to what else it did load.
If that doesn't work I would try running depmod in case it didn't get run after the kernel was build and maybe the dependancy info it generates was out of date. Then try modprobe again.
If it still doesn't work then it sounds like ft.o depends on something obscure - you have obviously selected all the modules you think it could need but that obviously isn't enough.
One approach would be to take one of the unresolved symbols and grep the whole kernel source tree to find which module(s) implements it and then check if the module is being included in the build. Repeat this process until it will load.
Another possibility would be to be sparing in what you included hard linked into the kernel, but build absolutely everything else as modules - it will take longer to compile but depmod should be able to find the dependancies and modprobe should load the modules. Your /lib/modules directory will take more space than selecting just the modules you want, but as the redundant ones won't get loaded into memory it won't hurt performance.
Hope this helps. Steve.