[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] Is: drivers/cpufreq/cpufreq-xen.c Was:Re: [PATCH 2 of 2] linux-xencommons: Load processor-passthru



>>> On 06.03.12 at 18:40, Konrad Rzeszutek Wilk <konrad@xxxxxxxxxx> wrote:
>>> Both of them (acpi-cpufreq.c and powernow-k8.c) have a symbol
>>> dependency on drivers/acpi/processor.c
>>
>> But them being 'm' or 'y' shouldn't matter in the end.
> 
> I thought you were saying it matters - as it should be done around the
> same time as cpufreq drivers were loaded?

Depends on how you interpret "matters": You should not introduce a
requirement for these to be set to 'y'. And I was hinting at the fact that
when they're 'm', a distro may load them much later than the
processor driver (SuSE for instance generally loads the processor
driver from initrd, but cpufreq post-boot (when the selected run level's
scripts get executed).

>>> For a), this would mean some form of unregistering the existing
>>> cpufreq scaling drivers.The reason
>>
>> Or loading before them (and not depending on them), thus
>> preventing them from loading successfully.
> 
> I think what you are suggesting is that to write a driver in 
> drivers/cpufreq/
> that gets either started before the other ones (if built-in) or if as
> a module gets
> loaded from xencommons. That driver would then make the call
> to acpi_processor_preregister_performance(),
> acpi_processor_register_performance() and acpi_processor_notify_smm().
> It would function as a cpufreq-scaling driver but
> in reality all calls to it from cpufreq gov-* drivers would end up with nop.

Yes, that's the option I would expect to be the least cumbersome one
if you want to go the cpufreq driver route. I'd personally prefer the
processor-extcntl logic to be ported over into ACPI's processor driver,
and suppress the loading of cpufreq drivers altogether (unless
"cpufreq=dom0" was given on the Xen command line, an option the
introduction of which I always considered bogus).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.