Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756537AbaGIRlk (ORCPT ); Wed, 9 Jul 2014 13:41:40 -0400 Received: from smtp.codeaurora.org ([198.145.11.231]:45352 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752746AbaGIRlh (ORCPT ); Wed, 9 Jul 2014 13:41:37 -0400 Message-ID: <53BD7ECF.8010408@codeaurora.org> Date: Wed, 09 Jul 2014 10:41:35 -0700 From: Stephen Boyd User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: Viresh Kumar CC: Mike Turquette , "Rafael J. Wysocki" , Lists linaro-kernel , "linux-pm@vger.kernel.org" , Arvind Chauhan , "linux-arm-msm@vger.kernel.org" , Sachin Kamat , Thomas P Abraham , Shawn Guo , Linux Kernel Mailing List , Nishanth Menon , Tomasz Figa , "devicetree@vger.kernel.org" , Kukjin Kim , Michal Simek , Rob Herring , Santosh Shilimkar , Simon Horman Subject: Re: [PATCH 00/14] cpufreq: cpu0: Extend support beyond CPU0, V2 References: <53B4B0B3.9080000@codeaurora.org> <20140703221609.11380.6884@quantum> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 07/07/14 21:50, Viresh Kumar wrote: > On 4 July 2014 09:51, Viresh Kumar wrote: >> Yeah, having something like what you suggested from DT is the perfect >> solution to get over this. The only reason why I am not touching that here >> is to not delay other patches just because of that. >> >> There are separate threads going on for that and probably somebody >> else was trying to push for that. >> >> That's it, nothing more. I would definitely like to use those bindings instead >> of the crazy routines we are trying here, once that is finalized :) > Do we have some kind of agreement for this temporary solution? Anyways > I will kick the other thread again to resolve the bindings soon. > > @Stephen: Do you still want find_rate_changer() stuff in this series only > and or this can go into 3.17 without anymore changes and lets finalize > the bindings Mike suggested and then update this code? > > Finding the rate change is not necessary for me. I don't imagine my code will be getting into 3.17 anyway though so I'm no in a rush to merge anything immediately. I still prefer the common clock framework API. If we go ahead with the find_rate_changer() stuff we've pretty well insulated this driver from any DTisms, which is nice. The only thing left would be transition-latency and voltage-tolerance, but those are already optional so you really don't need to even run on a DT enabled platform to use this code. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/