From mboxrd@z Thu Jan 1 00:00:00 1970 From: Viresh Kumar Subject: Re: [PATCH 00/14] cpufreq: cpu0: Extend support beyond CPU0, V2 Date: Fri, 25 Jul 2014 20:04:17 +0530 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: devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Rob Herring Cc: "Rafael J. Wysocki" , Stephen Boyd , Rob Herring , Mike Turquette , Thomas Petazzoni , Nishanth Menon , Lists linaro-kernel , "linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "linux-arm-msm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , Tomasz Figa , Linux Kernel Mailing List , Michal Simek , "devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , Simon Horman , Thomas P Abraham , Kukjin Kim , Arvind Chauhan , Sachin Kamat List-Id: linux-arm-msm@vger.kernel.org On 25 July 2014 19:59, Rob Herring wrote: > 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 I agree.. > 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. Or because we are going to create platform devices for now, lets have some platform data for cpufreq-cpu0 ? > 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. I completely agree, but there are few points here which might make the red flag yellow if not green :) - I co-maintain this framework and so I do care about it :) - Even with the temporary stuff the solution wouldn't be complete for platforms with multiple clusters having separate clock lines. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760557AbaGYOeU (ORCPT ); Fri, 25 Jul 2014 10:34:20 -0400 Received: from mail-oa0-f44.google.com ([209.85.219.44]:36120 "EHLO mail-oa0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752332AbaGYOeR (ORCPT ); Fri, 25 Jul 2014 10:34:17 -0400 MIME-Version: 1.0 In-Reply-To: References: <20140717093518.486ac244@free-electrons.com> <2399813.Puj1SZWhCh@vostro.rjw.lan> Date: Fri, 25 Jul 2014 20:04:17 +0530 Message-ID: Subject: Re: [PATCH 00/14] cpufreq: cpu0: Extend support beyond CPU0, V2 From: Viresh Kumar To: Rob Herring 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 Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 25 July 2014 19:59, Rob Herring wrote: > 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 I agree.. > 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. Or because we are going to create platform devices for now, lets have some platform data for cpufreq-cpu0 ? > 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. I completely agree, but there are few points here which might make the red flag yellow if not green :) - I co-maintain this framework and so I do care about it :) - Even with the temporary stuff the solution wouldn't be complete for platforms with multiple clusters having separate clock lines.