On Thu, Mar 27, 2014 at 04:29:37PM +0530, Viresh Kumar wrote: > On 27 March 2014 16:18, Gautham R Shenoy <ego@xxxxxxxxxxxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe cpufreq" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
