From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gautham R Shenoy Subject: Re: [PATCH] cpufreq: don't print value of .driver_data from core Date: Thu, 27 Mar 2014 16:56:03 +0530 Message-ID: <20140327112602.GD27777@in.ibm.com> References: <2490cd0aaeaaeb88131c8089d491c485f08da5da.1395914766.git.viresh.kumar@linaro.org> <20140327104842.GB27777@in.ibm.com> Reply-To: ego@linux.vnet.ibm.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from e36.co.us.ibm.com ([32.97.110.154]:55163 "EHLO e36.co.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755221AbaC0L0P (ORCPT ); Thu, 27 Mar 2014 07:26:15 -0400 Received: from /spool/local by e36.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 27 Mar 2014 05:26:15 -0600 Content-Disposition: inline In-Reply-To: Sender: linux-pm-owner@vger.kernel.org List-Id: linux-pm@vger.kernel.org To: Viresh Kumar Cc: "ego@linux.vnet.ibm.com" , "Rafael J. Wysocki" , Lists linaro-kernel , "cpufreq@vger.kernel.org" , "linux-pm@vger.kernel.org" , Linux Kernel Mailing List , "Srivatsa S. Bhat" , Vaidyanathan Srinivasan , Preeti U Murthy On Thu, Mar 27, 2014 at 04:29:37PM +0530, Viresh Kumar wrote: > On 27 March 2014 16:18, Gautham R Shenoy wrote: > > So after this patch, driver_data is only going to be used by drivers > > which want an "unsigned int" value to be saved along with the > > frequency in the frequency_table and for those who want to overload > > its interpretation to indicate BOOST. > > > > From the core's stand point, it is useful only for determining whether > > a frequency is BOOST frequency or not. > > Yes. > > > So, wouldn't it be logical to allow drivers maintain their own driver > > data since the core is anyway not interested in it, and change this > > .driver_data to "flags" or some such which can indicate boost ? > > We can add another field .flags in case Rafael doesn't accept the > other proposal I sent for fixing BOOST issue. Even with that patch, the .driver_data won't be opaque. And that's not good. Because, while some driver might not be explicitly setting the value of .driver_data to 0xABABABAB, it might want to store the value obtained at runtime into this field. And it could so happen that at runtime this value is 0xABABABAB. > > But the point behind keeping .driver_data field here was: many drivers > have some information attached to each frequency and they are closely > bound to each other. And so it made more sense to keep them together. > This is still used by many drivers and I wouldn't like them to maintain > separate arrays for keeping this information. They are so much bound > to the frequencies at the same index, that keeping them separately > wouldn't be a good idea. I understand this part. However there might be more data than an "unsigned int" that the drivers would like to be bound at the same index. Voltage information, for instance. > -- Thanks and Regards gautham.