ACPI: cpufreq: Use platform devices to load ACPI PPC and PCC drivers
The acpi-cpufreq and pcc-cpufreq drivers are loaded through per-CPU module aliases. This can result in many unnecessary load requests during boot if another frequency module, such as intel_pstate, is already active. For instance, on a typical Intel system, one can observe that udev makes 2x#CPUs attempts to insert acpi_cpufreq and 1x#CPUs attempts for pcc_cpufreq. All these tries then fail if another frequency module is already registered. In the worst case, without the recent fix in commit 0254127a ("module: Don't wait for GOING modules"), these module loads occupied all udev workers and had their initialization attempts ran sequentially. Resolving all these loads then on some larger machines took too long, prevented other hardware from getting its drivers initialized and resulted in a failed boot. Discussion over these duplicate module requests ended up with a conclusion that only one load attempt should be ideally made. Both acpi-cpufreq and pcc-cpufreq drivers use platform firmware controls which are defined by ACPI. It is possible to treat these interfaces as platform devices. The patch extends the ACPI parsing logic to check the ACPI namespace if the PPC or PCC interface is present and creates a virtual platform device for each if it is available. The acpi-cpufreq and pcc-cpufreq drivers are then updated to map to these devices. This allows to try loading acpi-cpufreq and pcc-cpufreq only once during boot and only if a given interface is available in the firmware. Signed-off-by: Petr Pavlu <petr.pavlu@suse.com> [ rjw: whitespace and error message log level adjustments, subject edits ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Showing
Please register or sign in to comment