From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Boyd Subject: Re: [PATCH 00/14] cpufreq: cpu0: Extend support beyond CPU0, V2 Date: Wed, 09 Jul 2014 10:41:35 -0700 Message-ID: <53BD7ECF.8010408@codeaurora.org> References: <53B4B0B3.9080000@codeaurora.org> <20140703221609.11380.6884@quantum> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Return-path: 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 In-Reply-To: Sender: linux-arm-msm-owner@vger.kernel.org List-Id: linux-arm-msm@vger.kernel.org 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 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