SPI communication is always made between one master and one or several slaves (which may later switch and become master(s)).

The master is the one who defines the clock speed. As long as the master isn't using too fast clock speed on the SPI interface (which is not the crystal frequency for the processor), the slave will follow along.

You have to figure out which side is master and which is slave.

Then you have to figure out how fast the MCP3909 may work.
And you have to figure out how fast the AT89S52 may work.

Note that it is trivial to implement a SPI master in software, i.e. even if the chip has no hardware support for SPI. All you need is an output pin for the clock signal, an optional outut pin for outgoing data and an optional input pin for incoming data. The other way is evilishly hard to do - a software slave will require that you either run the SPI interface at a crawl speed, or that the slave spends exactly all time (with interrupts disabled) focusing 100% on the SPI communication.

In the end, this is not a question of synchronizing any clocks. It is just a question of figuring out master and slave, and the fastest rate the master may run to let the slave manage to keep up.

But just so I understand: Exactly how do you think "QUERY" is a descriptive subject? How many do you think are able to guess that the thread will be about SPI or that one of the two chips don't have hardware support for SPI?