From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Petazzoni Subject: Re: [PATCH 0/4] cpufreq-dt, platform_data based proposal Date: Wed, 10 Sep 2014 13:37:15 +0200 Message-ID: <20140910133715.4169ba29@free-electrons.com> References: <1410342112-13264-1-git-send-email-thomas.petazzoni@free-electrons.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Sender: linux-arm-msm-owner@vger.kernel.org To: Viresh Kumar Cc: Rafael Wysocki , Lists linaro-kernel , "linux-pm@vger.kernel.org" , Shawn Guo , Stephen Boyd , "linux-arm-msm@vger.kernel.org" , Sachin Kamat , Thomas Abraham , Tomasz Figa , Santosh Shilimkar , "pramod.gurav@smartplayin.com" , Rob Herring , Mike Turquette , Gregory Clement , Ezequiel Garcia , Tawfik Bayouk , Nadav Haklai , Lior Amsalem List-Id: linux-pm@vger.kernel.org Dear Viresh Kumar, On Wed, 10 Sep 2014 16:08:51 +0530, Viresh Kumar wrote: > Its not that we aren't accepting any drivers at all, but if we can reuse > existing infrastructure then we better use it for long term maintainability. Sure, but when "existing infrastructure" isn't ready to support a particular use case, and there seems to be no solution on which people are agreeing? > But there is another view here which Mike objected to, sometime back. > Its also not a good idea to push everything onto a virtual-cpu-clock > driver.. > > I had something in mind to get that fixed, but this thread hasn't allowed > me to work on that as it should be finished first. > > Probably we can add some callbacks to the cpufreq-cpu0 driver. For > example if somebody wants to do something crazy enough in their > ->target() routine then they can just register their callback and we > will call it instead of cpufreq-dt's target() routine.. > > That way we can still reuse the common part.. I personally don't think it would be a very good idea: in this case, you'd better do a complete cpufreq driver on its own. Doing subsystems in subsystems just for the sake of factorizing 10 lines of initialization seems a bit silly to me. > The platform-data solution is better than any other here :), and that > will get fixed once we get all this including which driver to probe from > DT.. Ok, I'll respin with a different solution than the flags. Thanks, Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com