> Yes. As it is today, acpi-cpufreq contains FFH driver functionality > in itself. It calls acpi and cpufreq arch-independent interfaces but > implements FFH internally. > > By, FFH driver do you mean to handle FFH related functions only for > P-states or something that can handle all FFH functions (like C-states, > etc). > I don't see any other kernel part/or driver will use this particular > PAL_GET_PSTATE and PAL_SET_PSTATE intefaces. So, my feeling is we don't > need a separate FFH driver. The only reason I can think of to have a separate FFH driver would be that we could potentially combine parts of the x86 acpi-cpufreq and the ia64 acpi-cpufreq. I didn't look closely, but the x86 and ia64 acpi-cpufreq drivers looked pretty different, even apart from the FFH stuff, so maybe that wouldn't be feasible. Bjorn - 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
