From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rob Herring Subject: Re: [PATCH 00/14] cpufreq: cpu0: Extend support beyond CPU0, V2 Date: Fri, 25 Jul 2014 09:29:09 -0500 Message-ID: References: <20140717093518.486ac244@free-electrons.com> <2399813.Puj1SZWhCh@vostro.rjw.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Return-path: In-Reply-To: Sender: linux-pm-owner@vger.kernel.org To: Viresh Kumar Cc: "Rafael J. Wysocki" , Stephen Boyd , Rob Herring , Mike Turquette , Thomas Petazzoni , Nishanth Menon , Lists linaro-kernel , "linux-pm@vger.kernel.org" , "linux-arm-msm@vger.kernel.org" , Tomasz Figa , Linux Kernel Mailing List , Michal Simek , "devicetree@vger.kernel.org" , Simon Horman , Thomas P Abraham , Kukjin Kim , Arvind Chauhan , Sachin Kamat List-Id: linux-arm-msm@vger.kernel.org On Thu, Jul 24, 2014 at 5:48 AM, Viresh Kumar wrote: > On 18 July 2014 09:47, Viresh Kumar wrote: >>> Before I apply anything in this area, I need a clear statement from the ARM >>> people as a group on what the approach is going to be. > > @Rafael: The only patch which has blocked this set is: > > cpufreq: cpu0: Extend support beyond CPU0 > > This is about finding which CPUs share clock line.. > > Other patches are sort of independent of this one and cpufreq-cpu0 would > continue to work for existing platforms if we apply these patches. > > I was wondering if you would like to apply other patches leaving this one? > I will then rebase stuff again and send non-controversial patches for 3.17. > So, that we get something in 3.17 and the last change can be merged during > rc's as well once we finalize on bindings.. > >> Mike/Rob/Stephen: I believe Atleast three of you should express your views >> now :) > > Any idea on how can we get some temporary solution for 3.17 as we didn't > conclude anything yet on bindings ? A temporary solution would have to be NOT in DT because once you add something into DT you are stuck with it for some time. You could simply support independent clocks by looking at the platform type, but that is still risky since you may want to define the OPP in DT differently for the 2 cases. The other problem with temporary solutions is once they are accepted, people loose motivation to create the permanent solution. "Can you take this now and I'll fix the issues later" is a red flag to maintainers. Rob