Quoting Viresh Kumar (2014-09-10 03:49:25)
> On 10 September 2014 15:11, Thomas Petazzoni
> <thomas.petazzoni@xxxxxxxxxxxxxxxxxx> wrote:
> > diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
> > index 138336b..fa35601 100644
> > --- a/include/linux/cpufreq.h
> > +++ b/include/linux/cpufreq.h
> > @@ -218,7 +218,7 @@ __ATTR(_name, 0644, show_##_name, store_##_name)
> >
> > struct cpufreq_driver {
> > char name[CPUFREQ_NAME_LEN];
> > - u8 flags;
> > + unsigned int flags;
> >
> > /* needed by all drivers */
> > int (*init) (struct cpufreq_policy *policy);
> > @@ -308,10 +308,13 @@ struct cpufreq_driver {
> > */
> > #define CPUFREQ_NEED_INITIAL_FREQ_CHECK (1 << 5)
> >
> > +#define CPUFREQ_DRIVER_FLAGS_MASK (0xFFFF0000)
>
> The flags field is used today to pass on information to cpufreq core and
> I believe it better stays that way only. Also all these changes might later
> be reverted and so we better don't change usage of variables..
I have another use case for exposing driver flags and I have created a
similar patch to this locally in my git tree.
Basically some cpufreq drivers may block or sleep during their
.set_target callback, and others will not. E.g. the former case is the
common pattern to use the clock framework and the regulator framework,
both of which hold mutexes and may have slow operations and the latter
case is more like the Intel P-state driver with just some register
writes.
For the energy-aware scheduling work it is desirable to know if the
cpufreq driver can do a "fast" transition of it might sleep, since that
affects whether we adjust the cpu frequency from the scheduler context
of whether need to put new work on the workqueue (e.g. waking up a
kthread dedicated to calling .set_target).
Regards,
Mike
>
> Instead of this add a "void *driver_data" field in this structure and fill that
> with your structure. This can be later used for other purposes as well..
>
> Also this will just add few more bytes to the cpufreq-driver structure which
> wouldn't have many instances in a compiled kernel, and so space isn't a
> problem..
>
> Otherwise things looked good to me in your complete series..
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
