From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sudeep Holla Subject: Re: [RFC V1 0/8] CPUFreq: create platform-dev for DT based cpufreq drivers Date: Mon, 01 Dec 2014 13:35:25 +0000 Message-ID: <547C6E9D.2090205@arm.com> References: <7885354.QleDlR7NUO@wuerfel> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Return-path: Received: from service87.mimecast.com ([91.220.42.44]:33512 "EHLO service87.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753407AbaLANfa convert rfc822-to-8bit (ORCPT ); Mon, 1 Dec 2014 08:35:30 -0500 In-Reply-To: Sender: linux-pm-owner@vger.kernel.org List-Id: linux-pm@vger.kernel.org To: Viresh Kumar , Arnd Bergmann Cc: Sudeep Holla , "linux-arm-kernel@lists.infradead.org" , Rafael Wysocki , Arnd Bergmann , "rob.herring@linaro.org" , "grant.likely@linaro.org" , Nishanth Menon , "devicetree@vger.kernel.org" , Abhilash Kesavan , Lists linaro-kernel , Thomas Abraham , "linux-pm@vger.kernel.org" , Catalin Marinas , Chander Kashyap , santosh shilimkar , Stephen Boyd , Lorenzo Pieralisi , Mike Turquette , "olof@lixom.net" On 01/12/14 13:29, Viresh Kumar wrote: > On 1 December 2014 at 18:24, Arnd Bergmann wrote: >> Thanks a lot for working on this, we really need to figure it out one day! > > :) > >> Your patches seem well-implemented, so if everybody thinks the general >> approach is the best solution, we should do that. From my point of view, >> there are two things I would do differently: >> >> - In the DT binding, I would strongly prefer anything but the root compatible >> property as the key for the new platforms. Clearly we have to keep using >> it for the backwards-compatibility case, as you do, but I think there >> are more appropriate places to put it. Sorting from most favorite to least >> favorite, my list would be: >> 1. a new property in /cpus/ >> 2. a new property each /cpus/cpu@... node. > > I did it this way earlier and named it dvfs-method but probably putting this > into the /cpus/ node is far better. But then Sudeep asked to utilize > compatible property only.. > > Are you fine with the name here? "dvfs-method" > That's right, I don't like driver specific method in the cpu node as you initially did. But if it's a property in the chosen node (where we usually put the Linux specific properties), I am fine with that as Arnd has illustrated in his patch. Regards, Sudeep From mboxrd@z Thu Jan 1 00:00:00 1970 From: sudeep.holla@arm.com (Sudeep Holla) Date: Mon, 01 Dec 2014 13:35:25 +0000 Subject: [RFC V1 0/8] CPUFreq: create platform-dev for DT based cpufreq drivers In-Reply-To: References: <7885354.QleDlR7NUO@wuerfel> Message-ID: <547C6E9D.2090205@arm.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 01/12/14 13:29, Viresh Kumar wrote: > On 1 December 2014 at 18:24, Arnd Bergmann wrote: >> Thanks a lot for working on this, we really need to figure it out one day! > > :) > >> Your patches seem well-implemented, so if everybody thinks the general >> approach is the best solution, we should do that. From my point of view, >> there are two things I would do differently: >> >> - In the DT binding, I would strongly prefer anything but the root compatible >> property as the key for the new platforms. Clearly we have to keep using >> it for the backwards-compatibility case, as you do, but I think there >> are more appropriate places to put it. Sorting from most favorite to least >> favorite, my list would be: >> 1. a new property in /cpus/ >> 2. a new property each /cpus/cpu at ... node. > > I did it this way earlier and named it dvfs-method but probably putting this > into the /cpus/ node is far better. But then Sudeep asked to utilize > compatible property only.. > > Are you fine with the name here? "dvfs-method" > That's right, I don't like driver specific method in the cpu node as you initially did. But if it's a property in the chosen node (where we usually put the Linux specific properties), I am fine with that as Arnd has illustrated in his patch. Regards, Sudeep