>-----Original Message----- >From: Bjorn Helgaas [mailto:bjorn.helgaas@xxxxxx] >Sent: Thursday, October 26, 2006 8:30 AM >To: Pallipadi, Venkatesh >Cc: linux-acpi@xxxxxxxxxxxxxxx; linux-ia64@xxxxxxxxxxxxxxx >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 >2.6.19-rc2-mm2, >> 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 totally same across i386 and ia64. Specifically, FFH is only used in definition of _PCT status and control objects and a FFH driver can be useful there. But, 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 scope. 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 with different drivers (SYSTEM_IO and FFH drivers) and stuff my feeling at this 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 and ACPI code are already getting shared across architectures today. So, only thing this new abstraction is going to make common across archs is registering and deregistering with ACPI and cpufreq. Thanks, Venki - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
