omap cpufreq driver in multi-platform kernels

[nm@ti.com (Nishanth Menon)]

On 11:38-20130327, Rob Herring wrote:
> On 03/27/2013 08:32 AM, Nishanth Menon wrote:
> > On 02:23-20130327, Paul Walmsley wrote:
> >> Hi
> >>
> >> On Tue, 26 Mar 2013, Rob Herring wrote:
> >>
> >>> The omap cpufreq driver causes problems in multi-platform kernels
> >>> because it unconditionally registers with the cpufreq core and does not
> >>> check sufficiently that it is running on an omap platform. So on a
> >>> kernel with highbank and omap drivers booted on highbank, the
> >>> cpufreq-cpu0 driver fails to init. Any suggestions for how to fix? For
> >>> DT this could just be several of_machine_is_compatible checks, but I'm
> >>> not really sure for non-DT. Converting the driver to a platform driver
> >>> would be another option.
> >>
> >> We could move the
> >>
> >> 	mpu_clk = clk_get(NULL, "cpufreq_ck");
> >>
> >> down to omap_cpufreq_init(), and bail out early if the clock alias doesn't 
> >> exist.  (Presumably we'd also want to change the clock role name if we did 
> >> that, to something like "omap_cpufreq_ck".)
> >>
> >> Experimental patch follows, comments welcome.
> > We should deprecate usage on omap-cpufreq driver eventually, instead go
> > towards embracing the SoC generic implementation of cpufreq-cpu0 driver
> > IMHO.
> > http://marc.info/?l=linux-omap&m=136371580826031&w=2
> > is the series to support cpufreq_cpu0 driver in DT based boot.
> > Would you think this approach is sane? 
> 
> That only solves the problem for DT, but not non-DT. My understanding is
> non-DT omap platforms will be around for some time.
> 
Yes, that is true. There are multiple parts of the problem:
part #1: DT boot:
https://patchwork.kernel.org/patch/2303471/ prevents omap-cpufreq from
interfering in DT enabled boot. (seeing DT entries for highbank it
probably might help in the specific platform)
part #2: non DT boot:
you would not have cpu DT nodes in the system. So, cpufreq-cpu0 wont come
into play[1]
Now the conflict between omap-cpufreq Vs non-dt platform cpufreq driver:
other than registering an dummy device and moving omap_cpufreq_init to
it (similar to what was done in cpufreq-cpu0[2]) I dont see how we can
continue to keep multiple platforms sane in mult-arch non-dt boot.

[1] https://patchwork.kernel.org/patch/2351601/
[2] https://patchwork.kernel.org/patch/2067751/
-- 
Regards,
Nishanth Menon