Re: intel_turbo_max_3 non-modularity

[Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>]

Hi Jean,


[...]

> > 
> By the way, is there any fundamental reason why intel_pstate could
> not
> be modularized? Or was it just another instance of needing functions
> which were not exported yet? I know that the intel_pstate driver is
> widely used nowadays, but still, this is a CPU-specific driver that
> not all x86 users need, and it isn't slim. It would be nice to be
> able
> to build it as a module too.
> 
I wish it can be a module. The problem is the race between acpi-cpufreq 
and intel_pstate when built as modules. Since every distribution will
have both of these configs set.
Based on the load order any of this driver can load as cpufreq scaling
driver. We want intel_pstate should be tried first and if can't be
supported then acpi-cpufreq should be used.

There are two PM trace event this depends on, which require built in
but that can be solved.

So if anybody has suggestion on how to solve this, this can be done.

Thanks,
Srinivas