From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nishanth Menon Subject: Re: omap cpufreq driver in multi-platform kernels Date: Wed, 27 Mar 2013 12:02:21 -0500 Message-ID: <20130327170221.GA32231@kahuna> References: <5152503C.2050503@gmail.com> <20130327133220.GA30868@kahuna> <5153207A.4050109@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Return-path: Received: from arroyo.ext.ti.com ([192.94.94.40]:52665 "EHLO arroyo.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751128Ab3C0RC3 (ORCPT ); Wed, 27 Mar 2013 13:02:29 -0400 Content-Disposition: inline In-Reply-To: <5153207A.4050109@gmail.com> Sender: linux-pm-owner@vger.kernel.org List-Id: linux-pm@vger.kernel.org To: Rob Herring Cc: Paul Walmsley , Kevin Hilman , Tony Lindgren , "linux-arm-kernel@lists.infradead.org" , Shawn Guo , linux-pm@vger.kernel.org, Mark Langsdorf 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