From mboxrd@z Thu Jan 1 00:00:00 1970 From: Santosh Shilimkar Subject: Re: [PATCH 07/14] cpufreq: cpu0: OPPs can be populated at runtime Date: Thu, 10 Jul 2014 09:31:30 -0400 Message-ID: <53BE95B2.50606@ti.com> References: <1ba7771e910084cd0820c19ca5994fe1b3d6451d.1404231535.git.viresh.kumar@linaro.org> <53BD5564.2060704@ti.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Return-path: Received: from devils.ext.ti.com ([198.47.26.153]:52998 "EHLO devils.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753425AbaGJNbv (ORCPT ); Thu, 10 Jul 2014 09:31:51 -0400 In-Reply-To: Sender: linux-arm-msm-owner@vger.kernel.org List-Id: linux-arm-msm@vger.kernel.org To: Nishanth Menon , Viresh Kumar , Tony Lindgren Cc: "Rafael J. Wysocki" , Shawn Guo , Lists linaro-kernel , "linux-pm@vger.kernel.org" , "linux-arm-msm@vger.kernel.org" , Tomasz Figa , Stephen Boyd , Linux Kernel Mailing List , Thomas P Abraham , Arvind Chauhan , Sachin Kamat , Dave Gerlach , linux-omap On Thursday 10 July 2014 08:39 AM, Nishanth Menon wrote: > On Thu, Jul 10, 2014 at 6:19 AM, Viresh Kumar wrote: >> On 9 July 2014 20:14, Santosh Shilimkar wrote: >>> Assuming you are updating bidnings as suggested by Stephen, >>> patch looks good to me. >>> Acked-by: Santosh Shilimkar >> >> Why do you still have a separate cpufreq driver for omap? >> Would this patch help getting that out? >> >> I see this for omap: >> >> static inline void omap_init_cpufreq(void) >> { >> struct platform_device_info devinfo = { }; >> >> if (!of_have_populated_dt()) >> devinfo.name = "omap-cpufreq"; >> else >> devinfo.name = "cpufreq-generic"; >> platform_device_register_full(&devinfo); >> } >> >> and it makes me believe that you were just waiting for this patch? > > Sorry, am away on vacation and slow on emails. The plan was to kill > omap cpufreq once all platforms convert to device tree only boot. Only > platform left is OMAP3 based platforms - though the date for removing > non-dt support has changed a couple of kernel revisions - but we > should be able to remove that entire file with this change. > > We will need this support to go with the solution recommended for opp > modifier series[1] - where platform code will populate or add OPPs > based on "speed grade" sample detection. > Yep. Last time I blocked the series because all the DT conversions were not done. Considering now the cpufreq-generic can work on non DT platforms, I am ok to remove the omap-cpufreq. Regards, Santosh