Hi Gautham,
> 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
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 th
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.
>
> F
On Thu, Mar 27, 2014 at 03:37:22PM +0530, Viresh Kumar wrote:
> CPUFreq core doesn't control value of .driver_data and this field is
> completely
> driver specific. This can contain any value and not only indexes. For most of
> the drivers, which aren't using this field, its value is zero. So, pr
On 03/27/2014 03:37 PM, Viresh Kumar wrote:
> CPUFreq core doesn't control value of .driver_data and this field is
> completely
> driver specific. This can contain any value and not only indexes. For most of
> the drivers, which aren't using this field, its value is zero. So, printing
> this
> fr
CPUFreq core doesn't control value of .driver_data and this field is completely
driver specific. This can contain any value and not only indexes. For most of
the drivers, which aren't using this field, its value is zero. So, printing this
from core doesn't make any sense. Don't print it.
Signed-of
6 matches
Mail list logo
