Currently, the spinlock in DaVinci clock framework is being
used to:

1) Protect clock structure variables usecount and rate against
concurrent modification.

2) Protect against simultaneous PSC enables/disables ie.
serialize davinci_psc_config().

3) Serialize clk_set_rate():
	i.	Prevent simultaneous setting of clock rates
	ii.	Ensure clock list remains sane during rate
		propagation (also in clk_set_parent).

Remove the spinlock usage in clock framework by:

1) Making clock rate and usecount as atomic variables.

2) Making davinci_psc_config() protect itself instead of
relying on serialization by caller.

3) (i) Allowing the clk->set_rate to serialize itself. There
should be no need to serialize all clock rate settings.
Currently the only user of rate setting is cpufreq driver on
DA850. cpufreq naturally serializes the calls to set CPU rate.
Also, there appears no need to lock IRQs during CPU rate
transtitions. If required, IRQs can be locked in the actual
set_rate function.

3) (ii) Use the mutex already in place for serialzing clock list
manipulation for serializing clock rate propagation as well.

Apart from the general benefit of reducing locking granurlarity,
the main motivation behind this change is to enable usage of
clock framework for off-chip clock synthesizers. One such
synthesizer, CDCE949, is present on DM6467 EVM. Access to the
synthesizer happens through I2C bus - accessing which can lead to
CPU sleep. Having IRQs locked in clk_set_rate prevents the
clk->set_rate function from sleeping.
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>