On 17/06/2015 15:54, Jan Beulich wrote:
> >>> On 16.06.15 at 09:09, <wei.w.w...@intel.com> wrote:
> > On 15/06/2015 20:37, Jan Beulich wrote:
> >> >>> On 15.06.15 at 14:28, <wei.w.w...@intel.com> wrote:
> >> > On 15/06/2015 17:15, Jan Beulich wrote:
> >> >> >>> On 15.06.15 at 02:30, <wei.w.w...@intel.com> wrote:
> >> >> > We actually want it be intel_pstate specific. If maintainers
> >> >> > agree, I think renaming it to intel_pstate_policy is a good option.
> >> >>
> >> >> No, this name is just ugly. If you need driver specific data, have
> >> >> a void
> >> > pointer
> >> >> in the generic structure; the driver can then allocate memory to
> >> >> be pointed to by that, and can store there whatever private data it
> needs.
> >> >
> >> > OK. I plan to make the following changes:
> >> >
> >> > 1) in cpufreq_policy, add a field - void *private_data;
> >> >
> >> >
> >> > 2) add a new structure:
> >> > struct intel_pstate_policy {
> >> > unsigned int policy;
> >> > }
> >>
> >> struct intel_pstate_private or struct intel_pstate_data please.
> >>
> >
> > "struct perf_limits" is currently used only by intel_pstate, should we
> > also move it to the intel_pstate_private struct, instead of the
> cpufreq_policy?
>
> Yes of course - anything private to the driver should go there.
Just realized that " struct perf_limits " will also need to be used in the
common code (e.g. set max_perf_pct in pmstat.c), so I plan to keep it in the
cpufreq_policy struct. Please let me know if you have a different opinion.
Best,
Wei
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
