omap cpufreq driver in multi-platform kernels

[Nishanth Menon]

Hi Kevin,
On 10:53-20130327, Kevin Hilman wrote:
> Nishanth Menon <nm at ti.com> writes:
> 
> > 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/
> 
> I think the platform_device conversion is the way to go.  I think you
> should do that instead of PATCH 8/8 of your OMAP conversion to the
> generic driver[1].
Yep, thinking about this over lunch, I came to the same conclusion that
instead of checking on DT node existance, platform_device conversion
will solve both parts of the puzzle.
> 
> I'll have a closer look at that series also and comment there as well.
Thanks. I will hold off posting a v3 on my series till I hear more.

> 
> Kevin
> 
> [1] http://marc.info/?l=linux-omap&m=136371580826031&w=2

-- 
Regards,
Nishanth Menon