RE: ia64 acpi-cpufreq driver

From: Pallipadi, Venkatesh <>
Date: 2006-11-02 05:30:21

>-----Original Message-----
>From: Bjorn Helgaas [] 
>Sent: Thursday, October 26, 2006 8:30 AM
>To: Pallipadi, Venkatesh
>Subject: Re: ia64 acpi-cpufreq driver
>> I think having 
>> separate code, even if there is some amount of duplication 
>is there, is
>> better in this case. The reasons:
>> - i386 acpi-cpufreq code has support for both IO port and FFH. Please
>> refer to arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c in 
>> which is a lot different from current git.
>> - FFH in i386 works in a different way from IPF. Specifically,
>> PERF_STATUS is just a register read, and hardware 
>performance feedback
>> is by using different APERF/MPERF MSR. But, in IPF it is done through
>> passing a different type parameter to same PAL_GET_PSTATE 
>calls (will be
>> adding this to IPF driver soon).
>Well, of course FFH would be *implemented* differently on x86
>than ia64!  But the layout of the FFH address space, which
>essentially determines the semantics of FFH, should be the
>same for all architectures (though somebody seems to have
>forgotten to specify that layout).

What I meant is, way FFH address space is defined and used is not
same across i386 and ia64. Specifically, FFH is only used in definition
_PCT status and control objects and a FFH driver can be useful there.
Hardware feedback of current/average frequency over a period of time 
(which does not have FFH object in ACPI) can also use some interface 
which overlap with interface that FFH driver is using. In the sense that
There is no clear distinction on the scope of this FFH driver.
Also i386 uses FFH for both C-states and P-states where as IA64 uses it
only for P-states today.

All this issues can be resolved once we have a definition of this FFH
I guess we need to revisit once we have the FFH related documentation
for IA64
(which should happen soon).

But, having seen the undue complications we are having in i386 world
different drivers (SYSTEM_IO and FFH drivers) and stuff my feeling at
point is, it will just add more overhead due to abstraction than the
commonality in code that it is going to bring. I mean, all the cpufreq
ACPI code are already getting shared across architectures today. So,
thing this new abstraction is going to make common across archs is
registering and deregistering with ACPI and cpufreq.

To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
the body of a message to
More majordomo info at
Received on Thu Nov 02 05:31:09 2006

This archive was generated by hypermail 2.1.8 : 2006-11-02 05:31:34 EST