Hi Kevin,
On 10:53-20130327, Kevin Hilman wrote:

Nishanth Menon [off-list ref] writes:

quoted

On 11:38-20130327, Rob Herring wrote:

quoted

On 03/27/2013 08:32 AM, Nishanth Menon wrote:

quoted

On 02:23-20130327, Paul Walmsley wrote:

quoted

Hi

On Tue, 26 Mar 2013, Rob Herring wrote:

quoted

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