cpufreq: OMAP: instantiate omap-cpufreq as a platform_driver

As multi-platform build is being adopted by more and more ARM platforms,
initcall function should be used very carefully.  For example, when
CONFIG_ARM_OMAP2PLUS_CPUFREQ is built in the kernel, omap_cpufreq_init()
will be called on all the platforms to initialize omap-cpufreq driver.

Further, on OMAP, we now use Soc generic cpufreq-cpu0 driver using device
tree entries.  To allow cpufreq-cpu0 and omap-cpufreq drivers to co-exist
for OMAP in a single image, we need to ensure the following:
 1. With device tree boot, we use cpufreq-cpu0
 2. With non device tree boot, we use omap-cpufreq

In the case of (1), we will have cpu OPPs and regulator registered
as part of the device tree nodes, to ensure that omap-cpufreq
and cpufreq-cpu0 don't conflict in managing the frequency of the
same CPU, we should not permit omap-cpufreq to be probed.

In the case of (2), we will not have the cpufreq-cpu0 device, hence
only omap-cpufreq will be active.

To eliminate this undesired these effects, we change omap-cpufreq
driver to have it instantiated as a platform_driver and register
"omap-cpufreq" device only when booted without device tree nodes on
OMAP platforms.

This allows the following:
 a) Will only run on platforms that create the platform_device
    "omap-cpufreq".
 b) Since the platform_device is registered only when device tree nodes
    are *not* populated, omap-cpufreq driver does not conflict with
    the usage of cpufreq-cpu0 driver which is used on OMAP platforms when
    device tree nodes are present.

Inspired by commit 5553f9e2
(cpufreq: instantiate cpufreq-cpu0 as a platform_driver)

[robherring2@gmail.com: reported conflict of omap-cpufreq vs other
driver in an non-device tree supported boot]
Reported-by: Rob Herring <robherring2@gmail.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Kevin Hilman <khilman@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>